Continued from:
3. Use Architecture to describe the business, before and after projects.
“Architecture” is becoming a more widely used term associated withInformation Technology. The number of adjectives applied to the termseems 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 ofan end product and how all the components are related and fit togetherto comprise the whole of the product.
Architecture is layered to capture and present information about theproduct to different audiences, from initial/high concept to detailedspecification.
Applied to IT, a component assembly approach is dominating theindustry, from the OO approach of software development, to real-timeuse of defined services, as popularized by SOA. Specialized agentsoftware is starting to assist in finding services and brokeringbetween different services to perform transactions collaboratively.
For the average company using IT, architecture is needed because itneeds 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 InformationSystems.; there are methods and approaches being promoted for anoverall “Business Architecture”, architecture for the whole business,not just IT. Originating from IT circles, they often look like anIT/IS architecture, which can be confusing. The Architecture in thisbook is definitely about Information Technology and Systems.
The good news is that you do not need to invent an IT Architecturemethod for your company. Many authors and vendors have methodsavailable already. When starting out, I recommendinvestigating/adopting the architecture that started it all, the“Zachman Framework” as developed and enhanced by John Zachman.
(see www.zifa.com for details)
He devised the illustrated matrix framework that cross-referencescore information concepts against the levels of abstraction that areused by different audiences and participants in delivery of InformationSystems.
The key benefit of the framework is that it illustrates howinformation concepts can be transformed through the levels to produceoperating components of the needed Information Systems.
Last two points on Zachman:
– The cross points of the Concept columns and Abstraction rows arecalled “Cells”; each cell will group the methods or documents(artifacts) that describe the content of the cell. Zachman does notspecify what artifacts to use, or what methodologies to use to createthe artifacts. The things in each cell on the diagram are justsuggestions. Keep this in mind for Principle #10.
– The Framework looks two-dimensional, but it is actuallymulti-dimensional when artifacts in one cell are cross-referenced toartifacts in other cells, the most obvious example is What vs. How,i.e., what function creates specific occurrences of data.