The Responsible Architect

Dit artikel is de Engelse vertaling van “De verantwoordelijke architect”.

This article has appeared in an earlier form as a chapter in the Dutch book “Pak je kansen met architectuur”, (“Grab your opportunities with architecture”). This book has been compiled from contributions of speakers on the Dutch National Architecture Conference (Landelijk Architectuur Congres LAC) of 2010. The article positions architecture in organisations, especially that of enterprise architecture. For the Dutch version of this article, please go to De verantwoordelijke architect.

Enterprise Architecture as a shadow hierarchy

This article is an introduction to an enterprise architecture framework for the organisational embedding of architecture, inspired by the Trias Politica in the political order. This framework makes the successful implementation of architecture less dependent on individuals, good will, and coincidence. It is about embedding architecture within the organisation to make it an integral part of the life stream of the organisation, and empowering it to play an explicit role in the success of the organisation as a whole as opposed to incidental successes limited to isolated projects, often strongly related to individual heroes.

Rationale

Organisations choose to work with architecture because they think they can reach several goals with it. Architecture attempts to make the way organisations are structured explicit. In that process it often becomes clear that this very structure hampers the actual achievement of those goals. Enterprise (and ICT) architecture and its standard-bearers, the architects, have lost credibility partly because of that.

Most organisations have limited history working with architecture. In the construction world this historical experience exists to an extent (an architecture that has some similarities with enterprise architecture and business management) but cannot be regarded as analogous. The focus of the architect there is relatively more on esthetics, projects, and in those projects more heavily in the start-up phase.

This lack of history and heuristics, and the lessons that can be learned from it, is especially poignant in the way organisations try to introduce “working under architecture”: each his own way, often strongly coloured by the individual architect involved in the process, as well as his manager, usually the CIO. Architecture is often intimately associated with IT. In the case of enterprise architecture especially this can have a crippling effect on its effectiveness (power of execution): the business does not see it as within its ball-park.

Architecture in organisations should not just be applied in projects but in any organisational structure. When we try to delegate architecture away into projects too much we make a fundamental mistake. We can see this backfiring for example in the problematics surrounding the transfer of project results to the line, and how difficult it is to involve the line and service management at an early stage with these projects. Another area where enterprise architecture cannot fulfil its potential is at the strategic level.

Organisational development has focussed almost exclusively on processes in organisations. Management science is mostly about that, with questions such as what are the processes, how can they be streamlined better, have more control over them, and manage their risks? Those are the questions this approach focusses on.

Viewed from the strategic management level, these are understandable questions. The approach on the strategic level is less determined by the substantive position of the enterprise. An example: I once asked the CEO of a large insurance company what the purpose of the company was. The answer was revealing but also somewhat disconcerting: “The purpose of our company is making money.” An insurance company may profile itself to its customers for example as a partner in managing risk, or help create a feeling of greater security or whatever — the final drive on the strategic levels is about loss and profit, and creating value for shareholders. It is almost as if customers are not part of the equation.

This process approach seems to align best with the information needs on the strategic levels.

The purpose of architecture however is not maximising profit. It may be a secondary one of course, or an implicit one. In the end architecture has no reason of existence if it does not visibly contribute to it. The primary goal of architecture is defined variously as:

• “improve time-to-market, flexibility, agility”
• “improve the link between IT systems and their users”
• “improve the quality of solutions”
• “improve the alignment of solutions across projects”

A definition of architecture I would like to introduce in this article is:

“Architecture is a process responsible for securing and optimally employing substantive or subject-matter competences within the enterprise.”

Rob Vens

Note: I am wrestling with a good English word for the responsible, substantive, subject-matter expert role in organisations, as opposed to the executive (accountable) role. If you are a native English speaker you might help me out on this.

Architecture plays a role equivalent in the Trias Politica to the legislative branch. With this architecture positions itself close to the concept of the “learning organisation”. It also conforms to a generally felt need for a career growth path that does not necessarily lead to executive (managerial) functions.

Architecture often emphasises the quality of solutions, next to uniformity and consolidation (“scoping and guidelines/directives”) to reduce costs. This often leads to the picture of the architect as being a drag on everybody. If the focus on quality is too heavy, we get the ivory tower architects for whom it never is good enough, who only want the best (and most expensive). If the focus on uniformity is too heavy we get the “nuisance architect”, who everybody feels is a straitjacket stifling any progress and innovation. In fact keeping a positive image in the enterprise as an architect is a challenge in itself. Architecture becomes a nuisance very quickly. As soon as that is the case it becomes harder and harder for architecture to prove itself as an enabler, and taking immediate and effective action is needed because architecture is already inching to the abyss.

Within enterprises one process is usually well defined, despite the fact that this process is often not explicitly named. This process we call the executive process, equivalent to the executive branch in democratic states.

The executive process is well linked to roles and responsibilities in an executive hierarchy. It is usually closely followed in the so-called organisation chart.

Within this model everyone is hierarchically linked to a boss, and optionally is him/herself a boss to others. This connection is ruled by assessments and job evaluation conversations, and linked to a variety of management tools and models.

The executive process has a vested history. This process however begins to show sign of decay. In this context I do not intend to go deeply into that, but the cause of the growing problems with this model is that is decouples the how (process) too much from the what (domain). As if a manager determines the success of an enterprise, regardless of the branch of industry in which that person has made his track record. It has led to a complete explosion of the number of managers, and downgraded the attention as well as the respect for what is actually done by the enterprise, its primary production.

The life-blood of every organisation has been polluted by this. Organisations are suffering from fatty degeneration, and are constantly behind the facts, out of breath. I can remember the time the word “manager” in The Netherlands was not used, and was associated with America and a curious disease, called “managers disease”. Both were unknown in The Netherlands at the time. How striking!

Trias Politica in architecture

To put a stop to this we need the concept of architecture as a shadow hierarchy, a substantive hierarchy, equivalent to the legislative branch in the Trias Politica.

Political: Legislative power — Judiciary Power — Executive Power
Organisational: Substantive hierarchy — Steering structures — Executive hierarchy.

This substantive hierarchy is connected to its own process, differing from the executive process. That process is the architecture process or in short: architecture.

For the attentive reader it is clear we are speaking about enterprise architecture here, of which ICT architecture is but one aspect.

To execute the primary process we need expertise. Substantive competent persons, subject-matter experts in all relevant disciplines, determine success. Everyone involved in this primary process brings in his competence. While doing this decisions are made. With complex processes such as innovations of software development the number of decisions that are architectural decisions is greater than with relatively simple processes such as in the process industry.

An architectural decision is defined as a decision in a problem that is signified as a transitive property. That is to say: this decision has implications that reach further than the location in which it is taken. It is like a ripple effect, like throwing a stone in a pool, creating ripples that makes something topple in a completely different location. It differs from a design decision, in that architectural decision can have disastrous consequences while the original problem may have been solved by it. The operation was a success, the patient has perished.

Designing or setting up a substantive hierarchy should keep in mind three aspects:

1. integration with the executive hierarchy
2. guard the separation between the two
3. critically guard the quality of the architecture process itself

In fact we are talking about creating a separation of powers equivalent to the Trias Politica, that tried to realise similar goals. For Montesquieu, who laid the foundation for this concept that is at the root of all modern democracies, the young Dutch state and the Dutch Parliament (the States General) was a major inspiration.

For this it is necessary to make clear and unambiguous agreements on how this separation needs to be maintained.

With these agreements we can for example prevent that architect are given executive responsibilities, also calles accountability (item number two above) — this should be the prerogative of executives. Within projects for example this means that a department architect cannot tell a project architect that something cannot be done, because it runs counter to the corporate standards. What he can do it try to make compromises (Development Without Architecture, DYA), but if that fails he can only defend his case in a steering committee (second branch!). Ideally this committee also consists of people with roles differing from executive and substantive roles, but in practice it could consist of executive people. Organisations starting to apply the Trias Politica should focus first on evolving the first and third branch. Within a Prince2 structure for example this is called the Steering Committee. When the Trias Politica has been further evolved inside the enterprise this would be a different hierarchy, equivalent to the judiciary branch of government.

Following corporate standards should be of enterprise-wide importance and interest. If done correctly, the steering committee will contain a person championing that interest. It is his responsibility to defend that interest within the competing forces in which the steering committee has to operate.

Architects should never sit in a steering committee, at least not when we apply our framework — surely they have substantive, responsible, roles! However they should be consulted or heard when processes escalate, like expert witnesses in a court case.

So there is a hierarchy in the architecture branch of the Trias, but it distinguished itself fundamentally from the executive hierarchy in an important area: architects “higher” in the hierarchy do not decide about ones “lower”. The options open in the hierarchical architectural relationship are:

1. Top-down
2. Bottom-up
3. Attempt to create a workable concession following a consensus model (we have a nice Dutch word for that: “polderen“)
4. If necessary: escalate to the executive branch of the Trias

Beware of competitive attitudes with and between architects.

Organisations as a rule are far from democratic — they are actually more like mediaeval feudal structures. The proposed separation of powers can help to get internal processes that are stuck moving again. And as feudal countries, when moving to become democratic states, vastly increased their effectiveness and power, so will companies when they go through this transition.

For a successful securing of the architecture process within organisations an effective and supple cooperation with the executive process is essential (it is of course leading). Also clarity on the separation is of great importance. We have collected a large set of guidelines for that.

Building substantive competence

To build an architecture process is no easy task, to state the obvious. It turns out however that embedding the proposed framework in certain kinds of organisations works very well: those organisations attempting to become more agile (introducing agile processes, self-steering empowered teams). It helps in clearer control of projects, but also in transitioning projects to the line, for example alleviating the eternal conflicts surrounding the transition to maintenance and service management.

Within the architecture process we can see two movements, where the starting up (bootstrapping) of the architecture process initially is more important:

1. Bottom-up: expertise develops on the floor, and the architecture process facilitates the further development and embedding
2. Top-down: guidelines and scoping, but for example also including reference architectures and showcases (applications or business processes)

The guardians of the architecture process, the architects, should be continuously aware of the importance of both, and not make the all too common mistake of losing themselves in the second one.

Quality Assurance

Quality assurance of the architecture process (item three above) should help to avoid the recurring tendency of architects to navel-gaze.

An example is the (currently somewhat contained) explosion of architect roles with the Dutch tax department, where I heard a project architect sigh: “they do what they want, we don’t even look at their directives no more because they have no bearing on reality whatsoever…”.

To achieve quality we need a constant process of architectural reviews (with a lot of attention to peer-reviews). Periodically essential are external reviews and audits to prevent tunnel-vision. These internal as well as external quality processes should enable the role of the architectural branch as almost binding in their advisory role to management. The architects’ advice should be trusted. Give this audit process a lot of freedom: it is essential that it is as objective as possible.

A consequence of building a process this way needs explicit mentioning: the effect on the quality of executive management decisions. In organisations lacking an architecture process executives are chronically underinformed or even misinformed. They depend too much on the information provided by the management layers immediately below them, deeply coloured by political motivations. An executive in organisations with an established architecture process has more and higher quality information to help him or her in making the best decisions.

Established this way, enterprise architecture can become a pillar of success instead of a process slowing down to a halt in mire. And architects can finally do something useful instead of defending their right of existence.

Invitation

So far my experiences with applying this approach are very rewarding. I welcome any contributions on these ideas, and hope you will take the trouble to enter into a dialogue using the comment system below, and share your interest with the “Sharing” buttons below. Please do!

Reference Guide

• U. States, The Declaration of Independence, 1776. Dept. of state, 1911.
• R. Masterman, The Separation of Powers in the Contemporary Constitution: Judicial Competence and Independence in the United Kingdom. Cambridge University Press, 2010.

Related material

• The Accountability Trap: on the difference between accountability and responsibility.
• Grass-roots architecture governance
• The Architecture Process for Agile Organisations