IT Architecture Diagrams July 17, 2008
Posted by chriseaton in EA, IT Architecture, communications, methodology, methods.Tags: application, architecture, architecture diagrams, architecture overview diagrams, business, EA, IBM EA, integration, qualiware, technology
4 comments
we are coming to the second wave of a major project i am working on which is deploying to over seventy countries. I asked my architecture team to go an find out about the existing architecture of the next set of countries, and some bright spark asked what tool and standards we should use to document this.
For the wave 1 countries I invented an architecture diagramming standard using powerpoint *update* I have written a full detailed explaination of his notation -> here. The major thrust of the architecture work is integration oriented. I’m afraid UML is too detailed, and does not have constructs which show the logical flow – you have to go down to integration diagrams for this. In my mind UML diagrams = the domain of an application architect and possibly an integration architect. It is not the domain of an enterprise architect or even a chief architect.
I know from prior analysis that there isnt a standard for this higher level diagram. In IBM method terms this is called an Architecture Overview Diagram. In essence an Architecture Overview Diagram is a diagram which shows an architecture for a specific audiance and/or purpose. In my case the audience is other architects, with the purpose of talking about all of the significant components and all integration points within our direct control, and integrations with systems we have a dependency on; either to retrieve data from them or send our data to them.
In my model each major component is named on the diagram and uniquely numbered. a component could be something large like SAP, or even an abstraction and a collection of components – again SAP is like this, you have the GUI, the backend, you will probably bucket the database as SAP even though it isnt really SAP (in my case DB2).Or, it could be something very granular like a single service. The level of detail in the diagram is dependant on the audience, but none the less powerpoint is the tool of choice
IBM itself uses Qualiware to document its own ‘to be’ Enterprise Architecture. I am not keen on this tool personally. Maybe it isnt so much how the tool works perhaps it is the way we use it. I can argue that we mix business flows with integration flows and there is variation in the level of detail and what is shown amongst the various business units who document their as-is architectures.
In summary, there needs to be a standard for architecture charts. There needs to be a standard for enterprise architects, there needs to be a standard for chief architects, there needs to be a view for application/integration/infrastructure/network/data architects. It is astonishing that powerpoint is the major tool of choice. There needs to be referential integrity between these diagrams. Today this is manual, it is not enforced by the tooling.
is someone listening and fixing?
i can only hope!
TOGAF ADM / IBM Enterprise Architecture method comparison June 26, 2008
Posted by chriseaton in EA, IT Architecture, methodology, methods.Tags: EA, enterprise architecture, Enterprise Architecture methods, IBM EA, IBM Enterprise Architecture method, technology, TOGAF
2 comments
There was alot of interest in the IBM Enterprise Architect Method post so I am going to expand some more on it. Just to note there is a copyright on the IBM EA method so I cant post actual material unfortunately.
This is a comparison against the TOGAF ADM (the crop circle diagram) since i am thinking this is the framework most people will be familiar with, and the IBM EA Neighborhood model (often referred to as the cyclone diagram). The neighborhoods are akin to the phases in the TOGAF ADM.
| Togaf Phase | IBM EA Neighborhood |
| Architecture Vision – outlines the value of Enterprise Architecture | The is no direct comparable phase as such in the IBM EA method, but ’selling’ EA is recognized as a significant part of an EA practitioners job. By selling I dont mean selling with a view to signing contracts, I mean convincing everyone to ‘do’ EA takes buy in across an entire Enterprise, and that is a sizable task. |
| no direct comparison | Strategy – this is very new idea, but says that a organisation has top line strategy of what it wants to achieve, where it wants to be and how it thinks it can get there |
| Business Architecture | Business Architecture – very similar to the TOGAF definition, focuses on business processes independent of technology. Also focuses on organisation structures, business capabilities, business scenarios similar to TOGAF but business scenarios but not at the same level of depth. Also looks at other dimensions of the organization like Roles and Locations |
| Information Systems Architecture | Information systems Architecture – similar to the TOGAF definition focusing on the functional aspects of the current and to-be architecture |
| Technology Architecture | Technology Architecture -again very similar to the TOGAF definition, focusses on meeting non functional requirements like performance, availability, monitoring, disaster recovery, etc. This is my own opinion but i feel this is often treated in at an EA level as a commodity. |
| Opportunities and Solutions | no direct comparison |
| Migration planning | Wrapped into Governance |
| Implementation Governance | Governance – Governance should be articulated through a work product/deliverable (misleadingly) named the Application Management Framework. This defines four things. The to-be architecture, the roadmap and stageposts to the to-be architecture, the governance processes including frequency of architecture review boards, what is reviewed, when something needs to be reviewed, the roles and responsibilities of the Architecture team, and lastly a communication plan – I think this is an interesting placement of a communications plan and it is actually the most critical aspect in my opinion of the AMF. If no-one knows what your doing or why you may as well go home now… |
| Architecture Change Management | Covered within Governance |