So as for renovations to an existing building, the construction industry has been completing successful projects for the last 100 years. They have accomplished this great feat by using a set of interconnected drawings with defined symbols to create a complete understanding of what is to be built. Even though the units are sometimes fuzzy (like a beam position is plus or minus six inches), the constructor(s) see’s what they are going to build in advance and knows’ the areas of issues just by looking at the drawings and their experience. Not just one role uses these diagrams, but all roles! The person who installs the foundation has probably never met the electrician, framer or plumber, but they all work in concert as if they were long-lost friends with a history of understanding each others trades…
We in IT have tried to work this way. This week I met with John Zachman, a pioneer in this space, who created a set of interconnected diagrams in the early 90’s that he used to create BI solutions. His ideas were revolutionary and had a great starting position, but did not included many of the areas that we would need to consider in an enterprise implementation that contained all four of the basic layers: Business Architecture, Information Architecture, Applications Architecture and Infrastructure Architecture. His updated solution is brilliant and works.
IBM purchased another solution which was Rational Rose but better known as implementing the Unified Modeling Language or UML – a set of interconnected diagrams but has been referred to as a framework. Here we go with the need for a single dictionary in IT, but we will hit this later.
Today, we are implementing BPM and SOA’s without a clue that the diagrams provide both the visibility into the solution as well as the traceability across the multiple layers of the architecture – just as the electrician, who is installing the light fixtures can look on the building diagram to see the stud position (and if it was installed correctly).
We need to consider enterprise architecture not as a hindrance, but as an asset to the IT organization and also to the business that we are enabling. For how can we align to the business needs if we do not understand the business architecture or the way the business in composed, organized, functions, processes and with what entities and attributes?
Actually I find architecting a new system to be the most rewarding phase of a project. Laying out data flows, partitioning into modules and and trying new ideas on paper affords the designer time to investigate new methodologies and technologies. A time to learn and burn.
The power of architecture is in the analysis of the requirement or problem through the data available about the requirement or problem. That statment is as true of an architecture for a house or an information system, or a major process improvement. Use the architecture data to analysis the present state to get to some desired or needed future state. You can use the pictures to make that task easier, but creating pictures without supporting data gets you nowhere.
John Zachman discovered a fast and efficient way to discover, organize and use data by filling in the blocks of his framework. It does work, works well, and, for those of us who have used it for years, expensive and complex new generation toolsets are not necessarily a good replacement.
John Tieso Arlington VA