We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.


Architecture versus Design

Originally published September 1, 2005

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.

  • Bill InmonBill Inmon

    Bill is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations.

    Editor's Note: More articles, resources and events are available in Bill's BeyeNETWORK Expert Channel. Be sure to visit today!

Recent articles by Bill Inmon



 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!