The practice of design is an honored activity. As the IT profession learned long ago, just building applications without a design or plan can lead to:

• Poor performance;
• Unstructured code issues; and
• Maintenance problems.

Thanks to Ed Yourdon and Tom DeMarco (and other early pioneers), we all learned about the need for structured design.

But is structured design enough? More specifically, should we be architects rather than designers?

First, let’s consider the difference between design and architecture. Design dictates that you define the requirements and follow them.  Architecture requires that you ask some basic questions before designing. Some of these questions include:

• Have we identified and defined all of the required components?
• Is there a better way to define and structure the problem? and
• Have we identified the correct sequencing of tasks?

For example, suppose a design is created to gather data from the web environment, executing transactions based on the data in the operational environment and then reporting on that activity. One way to accomplish the task is to create everything in a composite. The web environment does HTML processing. The data is then taken from the web and the transactions based on the data are processed. Consequently, the execution results are then given to a report writer.

Now all of this processing could have been done in a single application. The problem is that by doing all of the processing in a single application, that application would require a great deal of infrastructure. A much more rational approach—an architected approach—is to do part of the application in one place and another part of the application elsewhere. In other words, there is a web environment that already exists. Data can be gathered from the web environment. There is an operational environment. The transaction can be executed in the existing operational environment. There is a data warehouse environment. The reporting and other analysis can be completed in the data warehouse environment.

The designer looks at requirements for a specific project. The architect looks at ALL the requirements for ALL projects. The designer is concerned with the flow of data and the database design for a specific project. The architect is concerned with the flow of data and database design for all current and future projects. The designer looks at the response time for a specific project. The architect looks at response time for ALL the different components of the architecture.

Simply put, designers and architects do similar things, except the architect looks at all requirements, not just an immediate set of requirements. In contrast, the architect looks at infrastructure, encompassing entirely different and diverse sets of needs for the project.