Why do we need architecture for information systems?

David Wright

12 years ago

Actually, why do we need architecture for anything? Why don’t we just build stuff by starting and seeing how it goes? That probably worked OK for mud huts, but maybe not even then. Architecture is solution for dealing with things that did not get built right, and failed in some way: building falling down, killing inhabitants, bad stuff. Among other things, Architecture is a means of describing a complex end product in terms of its constituent parts and how they fit together.

My own first exposure to Architecture dates way back to about 1988, when I first learned about Information Engineering, as in the Information Engineering Methodology (IEM) then offered by James Martin & Associates. Its core was 3 layers of Architecture. First, Data and Function models made up the Information Architecture, describing the key concepts/entities of the business for which data was collected, and the functions that managed that data to be valid and useable. The catch-phrase was “Data + Function = Information”.

Next, analytical techniques like affinity analysis were used to partition the Information Architecture into distinct Business Areas, cohesive groupings of data and function that could be developed separately and then later integrated into a whole systems environment for the enterprise; this was the Business Systems Architecture. Further analysis of the operational needs of the Business Systems led to the definition of the Technical Architecture, detailing the physical environment needed to implement the business systems.

These architectures were not an end in themselves; they each played a role in leading to delivery of an integrated set of information systems meeting the needs of the business. The scope of these architectures was an enterprise, not one product or project. They showed that the systems of an enterprise supported different business areas, such that highly cohesive and de-coupled systems could be built, almost in parallel, and they would all work together as a portfolio of systems to support the information needs of the enterprise.

The architecture(s) of Information Engineering were a great discovery for me, but it became clear over time that they assumed, especially as automated by CASE tools, that other aspects of Systems would be handled outside their scope, such as user roles/security, or locations/networks.

In the same period of time, however, John Zachman was developing his own ideas on what architecture could do for information systems, which will be the subject of my next post.

Excerpted from “Cascade: Better practices for effective delivery of information systems in a multi-project environment”,
see more at http://www.amazon.com/-/e/B007YLUL7K#

…and more about me at www.about.me/dwwright99

David Wright

Dwwright99@hotmail.com