Most people who have been part of an Enterprise Architecture initiative will at some time have suffered from the scenario of significant investment with no apparent return, where a team will decamp to document rich architectural assets that no-one outside the team finds out about or uses. This reinforces the perspective outlined by the old joke: “what’s the difference between the architect calling in sick and the cleaner calling in sick?” …. the answer, of course, is that someone eventually notices the cleaner is missing.
Unfortunately, this is often closer to reality than many in our profession would care to call.
My pragmatic antidote to this is to produce “just enough” architecture “just in time” – in other words, build out the estate of enterprise architecture assets in line with, but just ahead of, emerging project needs. A simple principle to articulate, but needs a level of groundwork to put into practice. Even in the best of worlds, it feels a little like the train chase scene in Ardmann’s The Wrong Trousers, where our hero is desperately trying to lay track in front of the model train he is riding, which is why it is key to have the right pre-requisites in place:
- An agreed framework to document the assets. The meta-model, or architecture-for-the-architecture and the tooling used needs to be agreed up-front by the team, or the wheels will rapidly come off the bus; a sprawl of ad-hoc assets might just as well be produced by disparate project teams themselves
- An agreed framework to govern the assets and the projects which will consume them. Without at least the basics of this in place, no progress at all will be made. The process of engaging with projects is the hinge on which a successful architecture turns. Key to this is early awareness of business demand; the exact process, or the level of architecture authority is secondary to being able to engage at the project inception point.
- An approach to prioritising the assets needed. There is rarely time to produce the breadth or depth of the assets you would like, so what does “just enough” look like? An approach I’ve used effectively is to create a use-case model for architecture, in other words, treat your Enterprise Architecture as any other systems, and take the time to understand the users’ requirements. Who are the actors that will interface with the architecture? What questions will they want answers to?
Each of these require further exploration in their own right, and of course assume the existence of an architecture team.