#architecture #clarity #velocity #direction 

Day 1, not yet contracted.

Mr CIO calls me second time and tells me that Mrs IT Governance and Mr Lead Solution Architect have given very good feedback regarding our first meeting call. We had to do it remotely, but why not, cams were working and was safe – my home is my business castle.
In consequence, they would like to get started with me boosting Enterprise Architecture. So, we discuss some points relevant for my offer which I deliver at noon.

In the evening, I ask myself: “New clients, new situation, now where do we start?”.

Since architects are librarians too, I scan all I got. Best matches first. Slides. Questionnaires. What not. One of those slides contains a diagram from some tool, even better, start it, open the model, and holding my breath while faded memories are being recovered back into my 1st level brain cache.
There it is, the EA maturity model, gotcha. And better yet, it is just a puzzle piece of something even bigger – the EA handbook! I just love sustainability.

In the meantime, my brain floods itself with new questions and ideas: what about this agile transition, what about this different industry, what about mergers, what has been good, what can be improved, …

Let’s take a break. Back to that maturity model. I really like it because it has been so successful. It solved the issue of varying expectations and especially the expectation of reaching what I call level 5 in the very same year.

While there are many such maturity models around, let’s stick to this selected example. It makes things more clear.

Before we can reach level 5 Optimizing to the right we need to climb level 4 Quantitavely Managed. And before that, we need to climb level 3 Defined, level 2 Managed, and level 1 Initial far to the left if not yet already climbed. But, we can soften the climbing. I will come back to this later.

The title “Increase maturity by repeatedly …” tells everybody that we need to repeat. We repeatedly test promised benefits. Define a few objectives, work towards those, test promised benefits, report.
Repeat.

In addition, there are selected success factors. Theoretically, there may be more. But, let’s start somewhere and get commitment. We do not want ivory towers. Therefore, we build EA to the customer. It is OK to think big (remember level 5) as long as we start small and agile, step by step. EA itself is lame and its power only unfolds with integration into the organization and already established processes.
And please do not skip levels!
Now, if you take a closer look into adjacent levels you will recognize that some contained objectives are similar but not the same. There is step-wise improvement to repeating aspects.
E.g., we may learn that our application landscape is a little patchy. So, next level for this might be to close the gaps. And the level after that might be establishing a process that our application landscape remains “unpatchy”. You get the idea.

Let’s take a look at those *-annotations for selected objectives inside the levels. An objective is annotated with a ‘*’ if it shall be achieved by end of year (or any fitting end of time window).
What you may also have recognized is that beneath the levels there are some percentages given. Each percentage tells you how much of the level shall be achieved. Breaking the levels down into objectives for evolving aspects allows us to work on more than one level at the same time.
This is a very important aspect for the client and pays a lot into acceptance since we do not necessarily have to achieve one level completely before peeking into the next and the next after. It is not a computer game in the end, no final bosses to beat.
In this example you can easily see that the client wants to drive things along an up-to-date, consistent EA database being convinced that it might be the very basis for everything else regarding the EA discipline. That is clearly a data-driven approach. While the overall benefit of such a database might not be easy to measure, I at least and in retrospection of my work as project and application architect can savely say that it saves a lot of time and easily allows you to deliver your milestones. Why reinvent the wheel all the time?
There are many other approaches than this data-driven one in the given scenario. It is only one possible outcome in a multiverse of outcomes. The conclusion may be that the maturity model might be viewed as a loosely coupled matrix of objectives and provides a lot of options to choose from. Finally, options mostly are what architecture is all about.