Principle #3: Use Architecture to describe the business, before and after projects.

“Architecture” is becoming a more widely used term associated with Information Technology. The number of adjectives applied to the term seems endless: “Technical Architecture”, “Systems Architecture”, “Business Systems Architecture”, “Enterprise Architecture”, and so on, so it must be important.

Why do we need Architecture?

Architecture is not an end in itself; Architecture exists because things need to be built.

Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.

Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.

Applied to IT, a component assembly approach is dominating the industry, from the OO approach of software development, to real-time use of defined services, as popularized by SOA. Specialized agent software is starting to assist in finding services and brokering between different services to perform transactions collaboratively.

For the average company using IT, architecture is needed because it needs focused IT functionality to deliver the highest current value, while trying hard to ensure that the function will work (“integrate”) with the next function that is needed.

It should be emphasized that this is Architecture for Information Systems.; there are methods and approaches being promoted for an overall “Business Architecture”, architecture for the whole business, not just IT.  Originating from IT circles, they often look like an IT/IS architecture, which can be confusing. The Architecture in this book is definitely about Information Technology and Systems.

The good news is that you do not need to invent an IT Architecture method for your company. Many authors and vendors have methods available already. When starting out, I recommend investigating/adopting the architecture that started it all, the “Zachman Framework” as developed and enhanced by John Zachman. He devised a matrix framework that cross-references core information concepts against the levels of abstraction that are used by different audiences and participants in delivery of Information Systems. See www.zifa.com ...

The key benefit of the framework is that it illustrates how information concepts can be transformed through the levels to produce operating components of the needed Information Systems.

Last two points on Zachman:

- The cross points of the Concept columns and Abstraction rows are called “Cells”; each cell will group the methods or documents (artifacts) that describe the content of the cell. Zachman does not specify what artifacts to use, or what methodologies to use to create the artifacts. The things in each cell on the diagram are just suggestions.
Keep this in mind for Principle #10.

- The Framework looks two-dimensional, but it is actually multi-dimensional when artifacts in one cell are cross-referenced to artifacts in other cells, the most obvious example is What vs. How, i.e., what function creates specific occurrences of data.

Remember, be sure to visit my bookstore at http://stores.lulu.com/dwwright99