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
trackback
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 |
Comments»
No comments yet — be the first.