Observations and musings on Enterprise Architecture Tools
In my previous EA blog entry, I had written about contextualizing Infosys’ Enterprise Architecture survey findings. Since then I had an opportunity to observe and reflect on an aspect of the survey: adoption – and challenges - of Enterprise Architecture Tool at a Global 500 enterprise. To set the context for the discussion, a brief extract from the survey report as it pertains to adoption of EA tools:
- There is an increased adoption of EA tools, but there is no product which has managed to dominate the market
- The EA tools market is fragmented with the vast majority of respondents claiming to use general office and collaboration tools and drawing tools (e.g. Microsoft Visio) for Enterprise Architecture Modeling
 |  |
This should not surprise many of us in the industry!
During the past few years, I have worked with clients that have adopted Enterprise Architecture tools to varying degrees of success. Very few, at a considerable cost and effort, claim to achieve the utopian goal of mapping an enterprise architecture continuum in an ongoing basis (the stuff tool vendor case studies and marchitecture are made of). Why the high rate of dissatisfaction? Ask Enterprise Architects for a wish list in an EA tool and it could go somewhat like this:
- Create and manage models of the Enterprise Architecture
- Support Business Architecture requirements (BPMN, BPML etc)
- Maintain traceability among elements of the EA
- Publish standards and manage exceptions to standards
- Manage requirements
- Manage the existing portfolio of systems (the EA realized)
- Manage requests for architecture work
- Track changes to the Enterprise Architecture
- Communicate the Enterprise Architecture to multiple audiences
- Publish policies, principles, procedures and methods
- Report on the Enterprise Architecture to management
- Allow architects and managers to simulate the effects of change
Here one can easily see the makings of a Swiss Army Knife. And to think one of the key goals of Enterprise Architectures is to ensure K.I.S.S of an enterprise portfolio! The market demand being what it is (or I must say was), tool vendors have only been too happy to oblige; adding a few more bells and whistles to an already bulging requirements wish-list.
How do you ensure that an Enterprise Architecture tool that is designed to be a Swiss Army knife, and already licensed/procured by the organization be used efficiently for just a few key requirements? Well, this just creates opportunities for Enterprise architecture consultants, self included (Or in other words cost and effort that can be mitigated by restricting requirements to a few key areas)
Back to the case of the EA team at the Global 500 enterprise that I am working with. The client had already licensed an Enterprise Architecture tool (let`s call it Tool-A) and the EA team has been modelling with it sporadically. My charter was simple: observe and analyze usage of the tool and propose a way forward. After reviews, deliberations and interviews with stakeholders, I realized that the EA tool requirements were rather straightforward:
- Modelling logical views of a few architecturally significant areas of the Enterprise portfolio
- Modelling logical architecture to facilitate communication in transformational program/s
- Communicate the Enterprise Architecture to multiple audiences
The first two are candidates for the Tool-A and the third is best done by a simple intranet portal.
Just as we began getting warmed up on the modelling front, the team realized that another group of Business Analysts (Business Architects?) in the organization has already decided to leverage another tool (Tool-B). The primary intent of that exercise is to capture key as-is Business Processes. It is interesting that both Tool-A and Tool-B have the equivalent of swiss-army-knife-like capability (basic modelling, BPM, UML et al). That exercise is being supported by (yet) another group of consultants. And the saga continues (or should I say, has just begun)
I couldn’t agree more with Andrew Manning who blogged on EA tools here sometime ago
- Mohan
Ps: If you can’t read the text in the diagrams, you may download a copy of the survey report
Comments
The fragmentation experience you illustrate is, I would think, a common attribute of large, complex organizations. My association supports the enterprise architecture efforts in one of those, the Department of Defense. Its framework, the DoDAF, is viewed not as a modelling tool (there are many vendors of those) but as a guide for development of architecture from strategy through to capability. It is an example of what we refer to as effectiveness-centric architecture, one oriented to delivering the right capability. On the other hand, there is the Federal Enterprise Architecture, which is efficiency-centric as it is mostly concerned with managing investments in IT portfolios.
I'd be curious on your view of EA in the government context.
Posted by: Dave Chesebrough | May 6, 2009 08:03 PM
Dave, the context is in the form of Enterprise Tools, not Frameworks... I don't think anyone contests the importance of the EA Frameworks and Reference Models, however creating the outputs of these frameworks (i.e. artefacts) with the broad relational information which can be communicated to 'potentiallly' all in the enterprise (and some out of it) is the difficulty when it comes to tools - as well the conflict of multiple tools being used for similar if not same purpose between departments - as mentioned above.
I am currently struggling in an Organisation which has a tool which they believe will deliver EA outputs, however the vendor describes the tool as an IT Strategy Management tool which can give great reports dependant on the objects or details placed into it, however it lacks the full power of Modelling Process Diagrams. Therefore, my issue is, can we call this an EA tool if all we are reporting on is time and cost of programs, do we (as Architects) really need to place these objects into picture form?
Posted by: Curtis Johnson | May 8, 2009 01:45 AM