IBM EA method and IT Inventories June 27, 2008
Posted by chriseaton in EA, IT Architecture, methodology, methods.Tags: application inventory, enterprise architecture, IBM Enterprise Architecture method, IT Architecture, IT inventory, technology
2 comments
I have been thinking some more on the difference between the IBM Enterprise Architecture method and TOGAF. In the IBM EA method there is an strong emphasis on maintaining an IT Inventory. This seems oddly absent from TOGAF altogether. An IT inventory maintains a record of what applications you have, what technology they run on, the functions they perform and often financial data is attached to them too.
Understanding what applications and IT you have today in some form is crucial to making decisions for many reasons – to understand total costs, to enable you to identify and sunset applications which perform duplicate function, to have a total picture of what applications you have in the first place, to identify other IT rationalisations like server consolidation.
In IBM internally the company wide application inventory is also used to track all IT projects both in flight to deliver something an upgrade to an existing application and projects which will deliver something entirely new. This is really the centerpiece to tracking projects and the current application inventory and scheduled upgrades it takes a more holistic view than just what is live now, you can also extrapolate what the application looked like in the past, and because it tracks in flight projects you can see what the inventory will look like in the future if all the project deliver on time.
I wonder why TOGAF has a gap here it is such a powerful tool for analysis and communications. The IBM solution is custom built, are there any software applications out there to maintain an IT inventory?
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 |
