Recently I came across people telling me about this wonderful process and it’s related tools called Enterprise Architecture Management. The goal of EAM is to manage and document the architecture of IT applications in a more useful way.
Currently most architectural diagrams are created using drawing programs like Visio. More details can then usually be found in other documents. There is no way of getting information out of these kind of documents, so the main target is to make sure that the architectures are set up in a tool which has a database back end. In EAM you can then map business processes to applications (or their modules), define standards and portfolios and check their use etc.
After hearing (and seeing this) I thought: This how I understood the responsibility of a CMDB (or ITIL 3 compatible CMS). Bridging business need & process, across services and applications down to components that deliver these services. That is exactly what I target when setting up CMDBs for my customers. So what is the big difference? My (short) list up to now is:
- EAM is more abstract. It states architectures and not allways real implementations. You may see “Apache Web Server (2.2)” in EAM and you will see “fred.mycompany.com” / Apache Web Server (2.2.6) on Port 80 in the CMDB / CMS.
- CMDB is coming from the IT production side. So in real world politics, the creative designers and developers will not want tools from the dull production / operations. The prefer a fancy new thing for themselves.
- CMDB serves the production processes. EAM eases design phases.
- EAM systems are graphical and allow more intuitve editing of data, while CMDB is table / forms / scan centric and usually is not graphical at all.
So what does this tell us? Do we need EAM in my opinion? I believe it is important to support design and development of applications to reuse results from other teams, to be able to standardize and to have a through and living documentation of the architecture. So from this perspective EAM is a good thing.
BUT (there is always a but) if this is separated from the transition and operation we will continue to have different views of the world, we will not gain the full benefit and we will double the effort on documentation.
So who should lead, EAM or CMDB? Well in a good ITIL 3 Configuration Management System world, this should not matter too much. Transition and operation / production has strong need for architectural information and up to now the most difficult part in config management projects was getting this info. Maybe EAM will make this a little easier.
Another lesson should be learnt by the CMDB product manufacturers. They focus so strongly on discovery of all relevant information. This is just plain nonsense. The most interesting part of a CMDB is not scannable at all. To reduce a CMDB to a scanned repository is reducing a dinner to laying out the plates. The food on the plates is the real benefit of CMDBs and that is the higher levels of information. So they have to make sure, that entering business relevant information is easy and can be done in the architectural phase. Why not allow drawing CIs and dragging & dropping relationships and properties? There is quite some research in information presentation, so vendors go ahead and use it!
P.S.: I have been both on the creative and dull sides of IT. I enjoy both and I always suggest them to work closer together!