Last week I absolutely astounded having read a project report for a follow on Enterprise Architecture engagement that a former colleague had undertaken after I had previously set up the Enterprise Framework and the strategic direction for engagement with the implementation projects.
It had been a total mystery why the Enterprise Architecture practice in the organisation not only failed to take off but imploded so badly that the very reputation of Enterprise Architecture as a business transformation and project support vehicle had been totally destroyed. If you spoke to anyone in the organisation about Enterprise Architecture you would meet the utmost derision. It was seen as a waste of time, space and potentially dangerous. This was time for a post-implementation analysis to find out the reasons for this disaster.
A little background:
The Director in charge of the organisation had originally engaged the Enterprise Architecture Project as a mechanism to identify interdependencies between systems and areas where projects were delivering the same functionality and the organisation was therefore not only paying twice but it was causing confusion and duplication in the application landscape. We mapped out a framework that illustrated how the organisation is constructed with its strategic goals, business activities, functions and the underlying applications/systems and bearers. “Finally”, said the Director, “I can see what my enterprise looks like.” The point was that the Project Support Office could now analyse the Enterprise to see how a project impacts other projects and systems in development and operations and identify where there are issues that a project has to watch and subscribe to (watch and brief).
As far as we were concerned, the Project Support Office were working with the Enterprise Architect’s Office to plan the evolution of the Enterprise. The Implementation and Delivery teams were engaged, they were finally given a Project Start Architecture, which provided them with a context in which they were going to start building their solutions and prepare them for their Architecture Design Review.
So what went wrong? Why did it all go so badly awry?
The problem was that the next phase of the project was headed by an Enterprise Architect who had all the qualifications of engineering, system engineering, architecture frameworks…. but absolutely no experience of operational or implementing systems in live enterprises. Consequently, the work undertaken was drawing up myriads of meta-models, concept models, ontologies, taxonomies and the end result?
While the report read like an academic document of some note, the Implementation and Delivery teams, Project Support Office and more importantly the Director saw that these diagrams did not address their key critical questions. It did not provide them with the framework to be able to analyse the root cause of issues, the disconnects or duplications or overlaps in system functionality.
The Director came to the conclusion that while the Enterprise Architecture approach initially showed promise, it delivered too little, had no prospects of delivering value, confused people, irritated people and was a huge waste of time.
The Enterprise Architect’s Office was disbanded, the Project Support Office was dissipated and so a total of 14 people were removed from their position and redeployed. The responsibility was given to the Implementation and Delivery Teams to work out their interdependencies themselves. The Director decided that they were better off going the way they were than by keeping 14 people diddling around with petty meta, meta, meta-models.
The Lessons Learned:
- Enterprise Architecture needs to be championed by a business user, with a clear understanding of the goals of the business user. Lose the championship and support of the business user and the Enterprise Architecture will not go anywhere;
- Produce useful artefacts that support decision makers and the wider community. If an Enterprise Archtiecture cannot be used, it will be discarded and disbanded.
- This is no time for pure academics – nobody is going to jump up and down with delight at being presented reams of meta models, ontologies and other indirect and obtuse products where the stakeholders can’t see any direct value.
- We need to think along the line of business value, what can we deliver, how can we exploit the models that we are deriving to support projects, decisions, to support transitions.
- We need to heed the warning not to create diagrams, models, drawings for our own benefit, we need to keep our minds on the meaning and support to the wider stakeholder community and to ensure that we have an absolute justification for each diagram developed.