From the Mist

Introduction

Most people I work with think of architecture governance as something imposed upon the populace from above. They see architects operating from a kind of control tower: architectural guidelines and rules, constantly fighting to uphold the norms they themselves concocted.

I do not think that will work in the long run.

For me, architecture governance works much better when it self-organises from the roots. For that, a simple model has been created that I would like to share with you. Let me know if you think this might work for you.

Enterprise Architecture Repository

As you may have surmised, I am not a great fan (or believer) in top-down architecture. But I do think there is a great advantage in having something called an Architecture Repository. However you structure this repository, my preference is to have only one repository containing all architectural but also all solution building blocks. Probably you will have some kind of document management system as well, but if you do, please use the architecture repository as the central index, and not the other way around.

Anyway, the structure of the Enterprise Architecture Repository is a subject on its own. My current focus is on the fact that architecture work is structured in a unified way, using some kind of metamodel that makes sense for your organisation, whether it is Zachman, ArchiMate or TOGAF or something else.

Decision Log

An essential part in the strategy I propose is a thing called the Decision Log. This is a part of the Enterprise Architecture Repository where architectural decisions that are taken in the course of doing work are recorded. Entries in this log are reviewed in a structured way:

1. Peer review by a team member (a person directly working with the person logging the decision).
2. Peer review by a randomly selected member of another team. Not completely random, but the intent is to introduce a certain element of randomness and stochasticity in the selection.
3. Review by an architectural role.
4. End review on a random selection base by the enterprise architect.

Architectural Decisions

Step 1. Awareness: See

Everyone in any organisation, both on the floor as in all management structures, does architecture (see Everyone’s an Architect). The purpose of this first step is for all involved to realise:

1. What is architecture?
2. When do I make an architectural decision?

In order for that awareness to take form it is usually necessary to evangelise it: give presentations, tailored to the various audiences such as developers, sales people, managers. These presentations should not focus on IT alone. Architecture, especially from the perspective of Enterprise Architecture, involves all.

Step 2. Work with architecture: Do

As soon as people start to become aware of what architecture is and how it surfaces in their daily work, we are ready for the next step: what to do when I do something that touches on architecture?

As soon as that is the case you participate in a vital function of the organisation, called the Architecture Function. Just like for example in the human body, where we have functions like the circulatory function. This (architecture) function has always been there, it is just that now we want to work on making us aware of it and making it more explicit.

To make that possible you are asked for a specific behaviour. You do the same thing you did before, just slightly different. Below you will see a summary.

1. Is this decision I want/need to take an architecture decision (remember: in the previous step we worked on creating awareness of what this means). If yes, move on to step 2. If no, well just do your thing as you did before.
2. OK, we are dealing with an architectural decision. No need to panic, it sounds more … well, high-brow, than it is. We are going to document it. There is this thing called a Governance Log, within which lives another thing called a Decision Log. We document that we want to make an architectural decision: name, date, a short summary of the context.
3. Now that we have recorded the architectural decision or action in the Decision Log, we need to determine whether we actually can make the decision.
   Essential for a correct answer to this question is our own competence (architecture has to do with competence, experience, understanding, insight), and most importantly our ability to assess the level of our competence. Do we believe we can make the decision? Then by all means take it, and document the action in the Decision Log. Mark the decision as being taken. Now you should realise that you are responsible (subject-matter responsibility) for that decision!
   If we think we can not make the decision, for whatever reason, move on to 4.
4. The architectural decision is still waiting to be made, only you could not make it. Now’s the time to confer with your peers in order to gain more information. Maybe in that process you realise you are able to make the decision. Again, do so as described earlier: document in the Decision Log. Your participation in the architecture function is done for now and you can remove your architecture hat. But it can be that you see that you, even with the input from your peers, are still not able to make the decision. You log that, and move on to 5.
5. You are not able to make the decision. That means the architect’s hat on your head needs to find another head. That is what you need to do in this step. What is actually done in this step depends on the maturity of the architecture function in your organisation. It basically comes down to finding the most immediate responsible (subject-matter responsible role) person. Are you for example a developer in a scrum team, you may have a team member who is end-responsible for architectural stuff. This person now puts on the architect’s hat and she begins again with 1.
6. Architectural decisions that could not be made all eventually end up with the enterprise architect. But she will deal with it the exact same way, except when she cannot make the decision as well the decision moves outside the architecture function and becomes the responsibility of the board.

The picture above shows the basic steps in making architectural decisions.

The picture above shows the basic escalation path. What exactly the “next level” is depends on the maturity of the architecture process.

In summary: in this step we learn to put on the architecture hat, and how to act as an architect.

Step 3. Establish the architecture function: Build

In this step we work on establishing roles and responsibilities related to the architecture function. This might lead to the job function of Architect, but that is not what it is really about. It is more about the realisation of explicit roles. As we saw in the previous step, all of us play the role of an architect from time to time: when we need to make a decision that is marked as an architectural decision.

Working with scrum for example, we can establish one person as the end-responsible person within the team for architectural decisions. This role will need to be established on the various levels of the organisation, distinguishing the various architecture domains:

1. Business
2. Information
3. Application/Software/Data
4. Technical or infrastructure
5. Security

Step 4. Improvement: Learn

This step basically entails doing what is described above, and learn from it. To help us do so however, we need to explicitly revisit what and how things were done. This is called the Architecture Retrospective (borrowed from scrum). This might lead to an escalation structure as shown in the next picture.

This picture schematically depicts people making decisions marked as architectural, and how they “flow” through the organisation. It shows that architecture, to a great extent, “emerges” from the teams. And how some of it needs to flow up so to say, to make sure that the decision is actually made by the best person for that decision. It also uses the RACI model to separate two “kinds” of responsibility (see RACI for Enterprise Architecture).

However, the process is quite a bit different from what is generally meant by “governance”. I hope you, the reader, realise that there is even a fundamental difference. The process as depicted in this article is a grass-roots process. It empowers local decision-making, and the makers of those decisions. It leads to a continuous improvement process, where we know we can never make the best decision at any given moment in time, but we do know that the quality of those decisions will improve constantly. We do not create a process (as is often the case, alas) that runs down on itself, but we create a sustainable learning curve.

For example, the decisions are logged in the Decision Log. This log is reviewed by others. But the log is not meant to be used as an enforcement tool. It is the process in which it is used that should be central. This in itself is a subject for a separate article (read: Logging Architectural Decisions). Too often architecture is implemented top-down, creating an ever-growing distance between architects and developers (and we are not talking IT only here: any organisation develops itself in all its aspects). The spirit of this article and the process it describes is empowerment, agility, continuous learning and improvement.