What is architecture?

Whether we are talking about an enterprise or a system, we refer to something we call an “architecture.” Most of the time we are referring to some set of artifacts, usually models, diagrams, or spreadsheets, that describes the enterprise or the system. That set of artifacts is defined by the architecture framework we are using. But have you ever sat back and really thought about what an architecture is at its most basic and essential level? An architecture is not the set of artifacts—those are just the means of documenting the architecture. To make a complex architecture comprehensible enough to be useful, we need to focus on the ends—the real purpose for creating those artifacts. That will help focus the architecture effort and ensure it produces something of value.

Architecture complexity

The set of artifacts or the steps in the process that are defined by any given architecture framework are not the architecture; they are the means for thinking through and documenting the architecture. Most architecture frameworks are relatively complex things, with a number of aspects the architect is supposed to work through and a number of artifacts to create during the development process. The Zachman Framework has its rows and columns, The Open Group Architecture Framework has its pillars, The Department of Defense Architecture Framework has its views, and so on. Regardless of which framework you select, you are facing the prospect of producing a dozen or more interrelated artifacts if you follow that framework’s established methodology.

The output of this process is a set of artifacts and links among artifacts that can be difficult to understand for anyone who is new to the project. A detailed architecture of any moderately sized system is a complex thing, and the result of this complexity is an architecture priesthood. The architects go off to their work area and create these artifacts and their relationships, but the complexity of the resulting products is somewhere between intimidating and incomprehensible. The predicable result is that the architecture is often ignored, becoming nothing more than shelfware and consuming resources that do not seem to result in any measurable benefits. On the off chance anyone wants to make use of the architecture, they must consult the priesthood of architects, who seem to be the only ones capable of understanding what they have created.

An architecture that can only be used by architects is the equivalent of a self-licking ice cream cone: an interesting achievement from an academic point of view, but of no practical use. If we want to make architecture a useful, practical thing, then we need to go back to the beginning and think about what an architecture should do at its most basic.

Architecture simplified

I was recently discussing this topic with a developer friend who is somewhat skeptical of architecture but does have an interest in it (though he does not write much about architecture). We have spent a lot of time discussing how to make architecture useful.

To simplify architecture, we need to define what architecture is at its most fundamental level; we need to define the essence of architecture. And we need to define the use we want to make of an architecture.

Definition of architecture

At its most basic, architecture is an abstract description of a complex engineering design. This is true regardless of discipline. The building architect creates depictions of a structure, but those depictions do not specify the details of how structural members will be joined or how the site must be prepared. It defines how the building will look so the engineer can design structural details, so the owner will know what the building will look like, and so forth. By the same token, the architecture of an information system or an enterprise only needs to depict those things important to a particular user.

In summary, architecture explains design.

Purpose of architecture

Knowing what architecture is does not necessarily explain what architecture is used for. One problem with many architecture efforts is that they create a great many artifacts that are never used—a terrible waste of resources. To focus the architecture effort, we need to make sure we clearly define the purpose for which the architecture is being built. And no, “Because our policy requires us to create an architecture” is not a valid purpose.

The purpose of an architecture is to answer specific questions about a system or an enterprise. Most of the time, those questions are being asked by people who either lack the technical knowledge to understand the engineering design, or whose tasks and deadlines to not afford them the time necessary to understand the engineering design. For example, a program manager may need to know which commercial products are part of the final design and what functions they fulfill, but that doesn’t mean she is interested in the details of how the authentication module exchanges tokens with the database management system.

Other times, the questions being asked are of a more technical nature, and it is the development team that needs answers. In most cases, this will be when the system under development is doing something novel and no commonly understood patterns exist. Because the function is not a common one, there is some technical risk involved, and the development and decomposition of architecture products helps mitigate the technical risks inherent in the task. In essence, the architecture is helping developers answer the question, “How will we solve this problem?” Put another way, the architecture is a means for mitigating technical risk. However, keep in mind in the vast majority of cases this question will only arise in a research and development context. In any run-of-the-mill system, there are probably multiple implementations to reference and there is no technical risk. And there is no need to create an architecture view of a well-understood and previously addressed task.

The important thing about architecture views is that they should only be created to answer specific questions from relevant stakeholders. If you cannot articulate the question you are answering or you cannot identify a specific person who is asking for that information, then you should not be creating an architecture view.

We can summarize this concept by saying that the purpose of architecture is to provide fit-for-purpose depictions of the engineering design to meet the needs of specific stakeholders. An architecture view should only be created to address a specified need for one or more selected stakeholders.

When to do architecture

All of this is just a long-winded way of saying that there are only two reasons to create any architecture artifact: to explain an engineering design to a non-engineer, or to mitigate technical risk. If you are creating architecture artifacts that do not address one of those purposes, you are wasting resources.