The worst enterprise architecture anti-pattern of them all

In the world of real enterprises, enterprise architecture is a weak discipline. It doesn’t play a role of any real substance in most medium-large enterprises, which are exactly the enterprises that can profit most from its goals: the management of the total chaos that naturally occurs when change is not somehow controlled (See: Losing a Limpet – What happens when we don’t have Enterprise Architecture?).

Now, most enterprises are acutely aware of the chaos that they’re in (or will be in if they don’t take action). Hence, enterprise architecture is still somewhat on the mind of executives on a regular basis. But the way most enterprises go about creating that little bit of control to reign in the chaos has a deep flaw.

An example

Let’s start with a simple and familiar example. Suppose we have a semi-large enterprise with more than a thousand different applications in use at different business units or departments that make use of shared IT services. These units don’t all have their own infrastructure and IT operations, because that is extremely wasteful.

One of the ways in which enterprise can try to save expenses on that shared infrastructure is to standardize. Actually, there are more reasons to standardize than just cost cutting. For one, some choices may enable a situation that is much more robust under the inevitable uncertainty and change. As an example: we might want to be able to profit from cloud options as much as possible (even if some dreams of cloud advantages are myopic dreams), and for that we must make our landscape ready for such choices.

Now, let’s take a very typical architectural IT choice that an enterprise can make as a simplistic example. An enterprise may choose to employ virtualized hardware, which is managed by a hypervisor, on which an operating system — the supervisor — runs. This enables cost reductions by flexibly sharing hardware resources, and it makes at least the transition to one sort of cloud usage easier: the elastic use of infrastructure as a service, as these services are also virtualized.

Anyway, we assume our example enterprise wants virtualized hardware for some strategic/business reason. And how does the enterprise go about trying to get the organization to follow this beneficial choice? Well, what it generally does is set virtualized hardware as a horizontal standard for the IT organization to enforce. Virtualization is created as a goal for the IT organization, because the advantages of the choice are mainly realized by the IT organization’s operations.

Now suppose, one of the enterprise’s business units needs to run a certain commercial application or platform. The unit is suspicious of virtualization and sharing, as it sees it as a risk for performance. And rightly so, because contention is one of the main sources of performance problems. In fact, contention is probably the most difficult of all to fight. (See: The 5 Resource Bottle Necks In Big Data, Including The Intangible 5th, though with all the cloud solutions appearing, latency might become a good second). Anyway, the business unit may have (valid) reasons not to want this virtualization. But from an enterprise architecture perspective, the enterprise wants it. How is this managed?

Governance

Often, enterprises have some sort of overall IT board that has to support these standardization (design) decisions for the enterprise as a whole. The units are represented in that board, and they are supposed to accept the choices made there. So, on paper, they are committed. Now, let’s suppose that in our example case, the business unit is committed to virtualized hardware, because it has been agreed upon in some IT governance or architecture board, or even by the board of directors themselves.

But what happens in reality? Well, in reality, the people in the business unit are driven by their own business goals and they still have those legitimate concerns (like in our example: performance, or maybe the vendor of the application or platform refuses to provide support when the system is deployed on virtualized hardware). From the business unit’s perspective, getting the hardware virtualized is a goal of the IT organization, not their own goal. So, they are not really interested in it. In fact, they often even see it as opposition to their own business goals, not part of their goals. It’s not a goal, it’s a hindrance, a road block.

The effect? A conflict between the business and IT units will arise. This is actually a conflict between two (enterprise) goals: a unit-of-the-enterprise goal and an enterprise-as-a-whole goal, but it is not experienced that way. It is experienced as a ‘business’ goal versus an IT goal.

And if the enterprise-as-a-whole architecture goal of virtualized hardware isn’t achieved, who gets the blame? Which unit has performed poorly? The answer in this case is the IT unit. After all, they haven’t achieved their goal. They are too expensive, not agile, etc.

What has happened is that the board of the enterprise has given the IT unit the goal to steer the other units on this point. But nobody really experiences it as a ‘board’ goal.

One may wonder why a board steers architecture that way in the first place. Why use the IT department to steer the other departments? And the answer may well be that it is a pattern that in several other cases works reasonably well. The board needs to enforce security, they need to be compliant with rules and regulations, they need their financial reporting to be in order and so forth. In all of these cases there may be some other — often staff — department that is able to ‘steer’ the units on behalf of the board. So, if it doesn’t work with architecture, why does it work in those cases?

The answer is simple. Try to answer the question: “who gets the blame when these goals are not achieved?” If a unit is not compliant with regulatory demands, who gets the blame? Well, when such goals (compliance, etc.) are not achieved, it is at first the board itself that gets into trouble with outside stakeholders. And the board does not like that very much. They don’t want to get into trouble with their ‘superiors’, be it shareholders/owners or regulators. So they pass the pressure on to the organization. But this is not the case when their architecture stinks. If the architecture is bad, nobody holds the board of the enterprise accountable. Nobody forces the board to have ‘good’ architecture. Architecture is almost invisible (which, by the way is a usable short definition of architecture: the “invisible but important” stuff).

Hence, the push to have good architecture fully comes from inside the organization. And that means that a board of an enterprise must have a will of steel to actually work under architecture. They don’t get help from the outside. They must choose it, sometimes against short term demands, even those from the all-important outside. And that is hard. By the way, this also explains why all research papers, books and articles that analyze success factors of enterprise architecture name “higher management support” as success factor number one. But that support is meaningless and has a short shelf life if enterprise architecture doesn’t work. Which it often doesn’t in the orthodox approaches.

I call this architecture governance pattern “steering via the underside” (in Dutch: “sturen onderlangs”) and it is, I think, the most important anti-pattern in enterprise architecture governance, because it makes enterprise architecture so very inconsequential. There is a better way.

Alignment for free

Now suppose that the board of the enterprise actually decides they want to architecturally control on the sea of change on which they float? Going back to our example: how do they make sure that the units actually choose virtualized hardware whenever possible?

What many have tried is give more power to the IT department, or have stricter controls, more principles and guidelines, reviews, gates, and so forth. All are ways in which the agility of the enterprise suffers, with nothing much to show for it. Because in the end: the immediate business goals almost always outweigh the long term architecture goals. So, these ways never last. What we need is more agility in architecture (especially now that agile change methods have become popular), not less.

My answer is that boards of enterprises should not give these IT architecture goals to the IT department, they must explicitly give them to the business units instead. And they must have the strength of conviction to actually hold those business units accountable for the IT goals, in the same way that they hold those units accountable to compliance with external demands, from owner/shareholder to regulator. The board of the enterprise must act as if it will hurt itself if the business units, departments, etc. do not achieve the organization-as-a-whole architecture goals.

Giving IT-architectural goals to the business instead of IT has the following effect: It puts the IT-department in the position that the business actually wants IT’s help to fulfill those goals. Business and IT department  automatically become aligned with respect to the enterprise-as-a-whole architectural choices. And suddenly business and IT need to cooperate: IT doesn’t fight the business on this (and vice versa), it supports business to reach the IT goal that the business has

Sideways-bottom-up

In short: architectural choices, even IT ones, are most easily achieved when the board of the enterprise makes sure its steers from the top down, and not through the intestines of the IT department. Steering via the underside is my number one anti-pattern in enterprise architecture governance. Or maybe tied for first place with architecture principles (see Architecture principles considered harmful).

Finally: the example was about IT, but it is true for other architectural choices as well. And of course, a board doesn’t need to steer on everything. There is much that can be left to the freedom of the units or departments. But there, where the enterprise wants or needs that control, where it has strategic goals (e.g. robustness under uncertainty, overall efficiency, integration, etc.) it should steer architecture like it does steer everything else: top-down (in a pragmatic way of course) directly via the business, and definitely not sideways-bottom-up via IT, as is still the case often today.

This article was published before on InfoWorld