Key Points These are some of the key points that are made in the body of the text. I put them here as an Executive Summary so no one would overlook them. | 1. | | Seven thousand years of human history would establish that the key to complexity and change is Architecture. If it (whatever it is) gets so complex that you can't remember everything all at the same time, you have to write it down (Architecture). Then, if you want to change it (whatever it is), you start with what you wrote down (Architecture), the baseline for managing change. The reasons for doing Enterprise Architecture are, in the Information Age, it is the Enterprise that is getting complex and the Enterprise that is changing. (In the Industrial Age, it was the Product that got complex and the Product that had to change.)
| | 2. | | The Framework for Enterprise Architecture (The Zachman Framework™) is a normalized schema, one (meta) fact in one place. That is what makes it a good analytical tool. Don't add or change the Rows or Columns or you will denormalize it and it will cease to be a good analytical tool. The Framework is a semantic structure. It implies nothing about implementation processes (methodologies) or tools whether they are top-down, bottom-up, left-to-right, right-to-left, or where to start.
| | 3. | | The Framework can be used to help you think about (analyze) any thing or any Enterprise or portion thereof. The broader you define the analytical target, the better leverage you are going to get on integration, reusability, interoperability, etc., etc but the more complex the analysis. Conversely, the narrower you draw the boundary of the analytical target, the simpler the analysis but the less leverage you are going to get on integration, reusability, interoperability, etc., etc. If you draw the boundary beyond your jurisdictional control, you can no longer declare the models, you will have to negotiate the models. If you draw the boundary more narrowly than your jurisdictional control, you will disintegrate your Enterprise, that is, you will build a legacy.
| | 4. | | Once you get data manufactured, that is, designed and implemented in a database, there is no way to change the meaning of the data. After-the-fact attempts to post-integrate are okay, but you can only integrate (interface) cosmetic anomalies. If you only want to change the name or format or, if you only care about an individual record and don't care about its structure (meaning), you are home free. But, it is like putting lipstick on a pig... you can make it look good. The only way to change the meaning is scrap and rework.
| | 5. | | You don't have to build out all of the models defined by The Framework, Enterprise-wide at excruciating level of detail before you can get to implementation. However, you have to remember that whatever slivers (vertical or horizontal) of whatever Cells you are not building (making explicit), you are making assumptions about, that is, you are assuming risk, risk of scrap and rework.
| | 6. | | You don't have to build Enterprise-wide models in order to implement but you'd better pay attention to Enterprise-wide models in Columns 1, 3 and 6 because after you get systems implemented (e.g. the legacy) and the data doesn't mean the same thing across the scope of the Enterprise, the network is fragile and costing a fortune to keep up 24 x 7 and the Objectives or Strategies (i.e. Business Rules) cannot be administered consistently across the Enterprise, Management is going to be frustrated. After the systems get implemented, the only way to fix these kinds of problems short of cosmetic interfacing is scrap and rework.
| | 7. | | If you are not observing the engineering design principles as related to the primitive Cell models, you are not going to realize the engineering design objectives of alignment, integration, reusability, interoperability, flexibility, reduced time-to-market, etc., etc., etc.
| | 8. | | Until you have some (primitive) models stored somewhere in such a fashion that you can find them and reuse their components, you are, by definition, making-to-order, a waterfall. It is only a matter of how wide or narrow the waterfall is and how many times you iterate through it enroute to implementation. That is, you are never going to appreciably reduce time-to-market until you have something in inventory before you get the order. In manufacturing, this would be called mass-customization, assemble-to-order.
| | 9. | | If you are not building (and storing, managing and changing) primitive models, you are not doing Architecture. You are doing implementations. | Early numbers indicate that conservatively, taking Enterprise Architecture based approaches as compared to the traditional application development approaches produces implementations 10 times cheaper and 6 times faster. This is not due to some kind of magic. It is simply because in employing Enterprise Architecture, the idea is to engineer the Enterprise first, before you manufacture it (implement) whereas traditionally, we manufactured the Enterprise (implemented) before we had it engineered (e.g. the legacy). © Copyright 2001-2006 John A. Zachman, Zachman International, Zachman Framework Associates, Metadata Systems Software Inc. All rights reserved.
|
