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.
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.
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:
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:
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.
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.
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.
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 decisionsThis role will need to be established on the various levels of the organisation, distinguishing the various architecture domains:
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 a 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, realises 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 of 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. 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.
Mediation, gespecialiseerd in zakelijke en ICT conflicten
Coaching van CIO's
Coaching van architecten (Enterprise, Business, ICT)
Trainingen op het gebied van Agile...