Are You an Enterprise Architect? Really?

Principles and guidelines are not architecture, and if your main product is principles and guidelines, you’re not an architect.

There is this recurring theme of comparing enterprise architecture with city planning and other elements of the physical architecture world. This has bothered me for years, but it was only recently that I had an insight about what is at the root of my unease, and it is not so much the analogy itself, but the way the enterprise architecture orthodoxy positions itself in it.

What is Enterprise Architecture?

Enterprise architecture focuses on the evolution of the business-IT landscape above all else. This comes from one of the roots of enterprise architecture: the goal of fighting the chaos that can grow in enterprise landscapes, especially in IT. For example, IT was the original focus of the first Zachman framework. Another major and related goal is to get the best possible landscape for the business strategy, the alignment goal. But the anti-chaos goal was first, and it has strongly influenced our discipline. How do we prevent the natural growth of chaos if change initiatives are left to their own devices? Now, some enterprise architects may be forced to run from project to project, never being allowed to look at the enterprise level, but frankly, those organizations may employ ‘enterprise architects’, but they are not doing enterprise architecture.

Most organizations that actually do enterprise-level architecture follow a definition from ISO/IEC/IEEE 42010:2011:

Architecture: fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution

This widely used definition says two things. Architecture encompasses what is and how it should evolve. The ‘what is’ is not time-bound, by the way; it could apply to a ‘to be’ architecture as well. But the whole definition suggests that architecture begins with the current state. The second part of the definition is explicit. It says architecture is about the principles of design and evolution.

Architecture as Principles and Guidelines

These architecture principles must do two things: prevent the chaos and direct ourselves to a better world. Architecture is thus seen as something that limits the freedom of those that design the changes. In the Dutch enterprise architecture world, this is phrased as “kaderstellend voor ontwerp”, a phrase that translates a bit like “setting the boundaries for design”. All in all, the idea that architecture is mostly a set of rules, such as principles and guidelines, that govern design, and thus are not design itself, is embedded deeply in our discipline. Models, even those in a true enterprise architecture modelling language such as ArchiMate, are often not more than simple illustrations.

But if we go back to the world of cities and buildings, creating sets of rules is not what architects do at all. Architects in the real world make designs. Architects of the physical are designing practical structures, anything from bus shelters to large buildings, or even city plans. And in the case of buildings, their designs include significant details such as where the wall sockets are located, as these influence the usability of the building. It is as Le Corbusier said: “a house is a machine for living-in”.

In recent history, principles have been influential as guiding instruments for physical architecture, particularly just after World War II. It has not worked out well. In the world of cities and buildings, the principle-based rational and utopian city architectures — e.g., as put forward in the Athens Charter by the same Le Corbusier — has led to many urban disasters, such as crime-infested high-rise housing projects. The principles were arguably beautiful and logical, the result often was a disaster — a lesson for enterprise architecture if there ever was one. But even those principle-oriented architects of the physical did not just produce principles — the boundaries for design — they mostly produced actual designs that embedded those principles.

In the world of cities and houses there is one type of governance that actually does work via rules that set boundaries for design. Those rules are set by the government, and they implement societal values such as safety, environment, health, and access for the physically handicapped. These values are translated to building rules in a building decree. And the boundaries they describe are enforced by the building inspector. Architects are not building inspectors, but strangely enough, the role of governing design through rules, the role of building inspector, is the position into which many enterprise architects have maneuvered themselves. And their products reflect that. In some versions of templates for project start architectures, such as the current one from Sogeti’s DYA (note: used to be a working link, but link is now dead and it is hard to find DYA documentation so I’ll leave it at that), we see only principles and guidelines.

The Building Decree and the Building Inspector

When you are designing or building something physical, the building inspectors come along and see if the design of the architect, or the implementation by the contractor, is within those limits, thus protecting society against problems like a race to the bottom with respect to those values. As the whole set of these rules are often experienced as overzealous and impractical meddling with development freedom, building inspectors are not very popular. This unpopularity, by the way, mirrors why it is often so difficult for the business to truly value what the principle-oriented enterprise architects do. That is because the product of such enterprise architects sets up limitations for the contribution, but it is not a contribution to the solution itself. These ‘architects’ do not produce an architecture at all, they produce something resembling a mix between a building decree and the utopian principles of the modernist architects of the 1920s and ’30s. And to top it off, these ‘architects’ act as both lawmaker and inspector, which makes other stakeholders in the enterprise feel suspicious, and rightly so. So, the principle-oriented enterprise architects are not like architects in the physical world at all. They are more like a mix of utopian city planners — with principles, but without the plan — and building inspectors. They are also about as popular as the latter.

The mode of operation in enterprise architecture that overly uses principles and guidelines turns architecture into something that is not architecture at all. An architecture should not be a set of negative limitations or boundaries for design; it should positively describe what the solutions are to be. In other words, it should be a design. Not in all detail, of course, only relevant detail is to be added. The architect in the physical world does not describe the floor color. That is for the decorator, in Dutch called the ‘interior-architect’; my o my, how we love the status of the title ‘architect’.  The location of wall sockets is significant, though, and so it is described by a good architect. This architecture must conform to requirements such as the building decree, instead of being requirements. When the architecture for a project is completed, it must be clear for the builder what is to be built.

The Architecture and the Architect

An architecture must be a tangible contribution to the end result, instead of something of which the value is so far removed from the actual issues that nobody — except the enterprise architect — recognizes it as a constructive contribution. Rules in the physical architecture world, like building decrees or the utopian city-planning principles of Le Corbusier, do not lead to good designs by themselves. In the case of building decrees, they are generally expressions of the societal values behind them, often guarding minimum requirements against the cost- and time-saving pressures of the market. Rules, such as principles and guidelines, in enterprise architecture should be likewise. As Thomas Reid said, “The rules of navigation never navigated a ship. The rules of architecture never built a house”.

If we are to be enterprise architects, our main products should be actual designs that contribute directly to the results, instead of only setting limitations on the results. A design of a landscape to work towards, maybe. A design of the end result of a project, certainly. Note, this does not mean you are to be the ‘enterprise architect’ mentioned at the beginning, the one running from independent project to independent project and never taking the enterprise view. But how that works is beyond the scope of this column. The best way to describe such a design, by the way, is to base it on structured documentation, i.e., a model. The documented model of the enterprise architect is like the drawing of an architect of the physical. For enterprise architects, that generally means modelling in an enterprise architecture language like ArchiMate, which, even taking its imperfections into account, is currently the best option there is.

If your products, on the other hand, are made up mainly of limitations such as principles, guidelines, policies and such, the next time someone asks you what you do for a living, say that you are a ‘visionary enterprise inspector’, but please don’t say you are an enterprise architect.

Gerben Wierda

[This column has appeared in a slightly different form in my book:
Chess and the Art of Enterprise Architecture]

Next column in this series:  The (Forgotten) Other Half of SOA

[If you want to discuss my views with me: I will be speaking at the Gartner EA Summit 2015 London UK on May 20 2015 and the MBT-Congress in Houten NL (closing keynote) on May 21 2016]