Architecture

Defining Architecture

There appear to be almost as many definitions of IT architecture as there are practicing architects. Most software architecture definitions cite a system’s elements and components plus their interrelationships. In my view, this covers only one aspect of architecture. First, IT architecture is much more than software architecture: unless you outsourced all your IT infrastructure into the public cloud, you need to architect networks, data centers, computing infrastructure, storage, and much more. Second, defining which “components” you are focusing on constitutes a significant aspect of architecture.

Architecture as a Function

In large enterprises, the word “architecture” tends to describe both the structure of technical systems and an organizational unit: “we are setting up enterprise architecture.” Most of my discussions on “architecture” focus on the system properties. For organizational aspects, I speak about “architects” - it’s based on humans, after all.

There Always is an Architecture

It’s worth pointing out that any system has an architecture, which puts statements like “we don’t have time for architecture” into a questionable light. It’s simply a matter of whether you consciously choose your architecture or whether you let it happen to you, with the latter invariably leading to the infamous Big Ball of Mud architecture, also referred to as Shanty Town. While that architecture does allow for rapid implementation without central planning or specialized skills, it also tends to ignore critical infrastructure aspects and doesn’t make for a great living environment. Fatalism isn’t a great enterprise architecture strategy, so I suggest you pick your architecture.

The Value of Architecture

Because there always is an architecture, an organization should be clear on what it expects from setting up an architecture function. Setting up an architecture team and then not letting them do their job, for example by routinely subjecting architecture decisions to management decisions, is actually worse than intentionally letting things drift into a “big ball of mud”: you pretend to define your architecture, but in reality you don’t. Worse yet, good architects don’t want to be in a place where architecture is seen as a form of corporate entertainment. If you don’t take architecture seriously, you won’t be able to attract and retain serious architects.

IT management often believes that “architecture” is a long-term investment that will only pay off far into the future. While this is true for some aspects, e.g. managed system evolution over time, architecture can also pay off in the short-term, e.g. when you can accommodate a customer requirement late in the development cycle, when you gain leverage in vendor negotiations because you avoided lock-in, or when you can easily migrate your systems to a new data center location. Good architecture can also make a team more productive by allowing concurrent development and testing of components. Generally, good architecture buys you flexibility. In a rapidly changing world, this seems like a smart investment.

As most upper management is well versed in financial models, I often describe investing in architecture as the equivalent to buying an option: an option gives the buyer the right, but not the obligation to execute on a contract, e.g. buying or selling a financial instrument, in the future. In IT architecture, the option allows you to make changes to the system design, the run-time platform, or functional capabilities. Just as in the financial world, options aren’t free - the ability to act on a contract in the future, when more information is available, has a value and therefore a price. I don’t think the Black-Scholes model accurately computes the value of large-scale IT architecture, but it makes apparent that architecture has a measurable value and can therefore demand a price.

Principles Drive Decisions

Architecture is a matter of trade-offs: there rarely is one single “best” architecture. Architects therefore must take the context into consideration when making architectural decisions and aim to achieve conceptual integrity, i.e. uniformity across system designs. This is best accomplished by selecting a well-defined set of architecture principles which are consistently applied to architectural decisions. Deriving these principles from a declared architecture strategy assures that the decisions support the strategy.

Vertical Cohesion

A good architecture is not only consistent across systems, but also considers all layers of a software and hardware stack. Investigating new types of scale-out compute hardware or software-defined networks is useful, but if all your applications are inflexible monoliths with hard-coded IP addresses you gain little. Architects therefore not only need to Ride the Elevator across the organization but also up and down the technology stack.

Architecting the Real World

The real world is full of architectures; not just building architectures, but also cities, corporate organizations, or political systems. The real world has to deal with many of the same issues faced by large enterprises lack of central governance, difficult to reverse decisions, complexity, constant evolution, slow feedback cycles. Architects should walk through the world with open eyes, always looking to learn from the architectures they encounter.

When defining architecture in large organizations, architects need to know more than how to draw UML diagrams. They need to:

• gain architecture insights while Waiting in the line at a Coffee Shop.
• tell whether Something Is Architecture in the first place.
• tackle complexity by Thinking in Systems.
• know that Configuration isn’t better than coding.
• hunt zombies so they Don’t have their brain eaten.
• navigate the IT landscape with an Undistorted world map.
• automate everything so that they Never have to send a human to do a machine’s job.
• think like software developers as Everything becomes software-defined.

Is this Architecture?

Look for decisions!

Part of my job as Chief Architect is to review and approve system architectures. When I ask teams to show me “their architecture”, I frequently don’t consider what I receive an architecture document. The counter-question “what do you expect?” isn’t so easy for me to answer: despite many formal definitions, it isn’t immediately clear what architecture is or whether a document really depicts an architecture. Too often we have to fall back to the “I know it when I see it” test famously applied to obscene material by the Supreme Court. We’d hope that identifying architecture is a more noble task than identifying obscene material, so let’s try a little harder. I am not a big believer in all-encompassing definitions but prefer to use lists of defining characteristics or tests that can be applied. One of my favorite tests for architecture documentation is whether it contains any non-trivial decisions and the rationale behind them.

Defining Software Architecture

Enough attempts at defining software architecture have been made that the Software Engineering Institute (SEI) maintains a reference page of software architecture definitions.

The most widely used definitions include the one from Garlan and Perry from 1995:

The structure of the components of a system, their interrelationships, and principles and guidelines governing their design and evolution over time

In 2000 the ANSI/IEEE Std 1471 chose the following definition: (adopted as ISO/IEC 42010 in 2007):

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution

The Open Group adopted a variation thereof for TOGAF:

The structure of the components, their interrelationships, and principles and guidelines governing their design and evolution over time

One of my personal favorites is from Desmond D’Souza’s and Alan Cameron Wills’ book¹:

Design decisions about any system that keep implementors and maintainers from exercising needless creativity

The key point here isn’t that architecture should dampen all creativity, but needless creativity, of which I witness ample amounts. It also highlights the importance of making decisions .

Architectural Decisions

These well-thought-out definitions aren’t easy to apply, though, when someone walks up with a PowerPoint slide showing boxes and lines, claiming “this is my system architecture”. The first test I tend to apply is whether the documentation contains meaningful decisions. After all, if no decisions needed to be made, why employ an architect and prepare architectural documentation?

Martin Fowler’s knack for explaining the essence of things using extremely simple examples motivated me to illustrate the “architectural decision test” with the simplest example I could think of, drawing from the (admittedly limping) analogy to building architecture. I even took it upon myself to supply the artwork to make sure things end up about as basic as one could wish for and to pay homage to Christopher Alexander’s Pattern Sketches².

Consider the drawing of a house on the left. It has many of the elements required by the popular definitions of systems architecture: we see the main components of the system (door, windows, roof) and their interrelationships (door and windows in the wall, roof on the top). We might be a tad thin, though, on principles governing its design, but we do notice that we have a single door that reaches the ground and multiple windows, which follows common building principles.

Yet, to build such a house I wouldn’t want to pay an architect. This house is “cookie-cutter”, meaning I don’t see any non-obvious decisions that an architect would have made. Consequently, I wouldn’t consider this architecture.

Let’s compare this to the sketch on the right-hand side. The sketch is equally simple and poorly drawn and the house is almost the same, except for the roof. This house has a steep roof and for a good reason: the house is designed for a cold climate where winters bring extensive snowfall. Snow is quite heavy and can easily overload the roof of the house. A steep roof allows the snow to slide off or be easily removed thanks to gravity, a pretty cheap and widely available resource. Additionally, an overhang prevents the sliding snow from piling up right in front of the windows.

To me, this is architecture: non-trivial decisions have been made and documented. The decisions are driven by the system context, in this case, the climate: it’s unlikely that the customer explicitly stated a requirement that the roof not be crushed. Additionally, the documentation highlights relevant decisions and omits unnecessary noise.

If you believe these architectural decisions were pretty obvious, let’s look at a very different house:

This house was designed for a different climate, a hot and sunny one, which allows the walls to be made out of glass as insulation against low temperatures is less of a concern. However, walls of glass have the problem that the sun heats up the building, making it feel more like a greenhouse than a residence. The solution? Extending the roof well beyond the glass walls keeps the interior in the shade, especially in summer when the sun is high in the sky. In the winter, when the sun is low on the horizon, the sun reaches through the windows and helps warm the building interior. Also, a flat roof with an overhang isn’t a problem in this climate. Again, the architecture is defined by a fairly simple, but fundamental decision documented in an easy-to-understand format that highlights the essence of the decision and the rationale behind it.

Fundamental Decisions Don’t Need to be Complicated

If you think the idea of building an overhanging roof isn’t all that original or significant, try buying one of the first homes to feature such a design, e.g. the Case Study House No 22 in Los Angeles by architect Pierre Koenig. It’s easily in the league of most recognized residential building in Los Angeles or beyond (aided by Julius Shulman’s iconic photograph) and surely isn’t for sale. You can tour it, though, if you sign up far in advance. Significant architecture decisions may look obvious in hindsight but that doesn’t diminish their value. No one is perfect, though: UCLA PhD students have measured that the overhang works better on the south-facing facade than west or east³.

Fit for Purpose

The simple house example also highlights another important property of architecture: rarely is an architecture simply “good” or “bad”. Rather, architecture is fit or unfit for purpose. A house with glass walls and a flat roof may be regarded as great architecture, but probably not in the Swiss Alps where it will collapse after a few winters or suffer from a leaking roof. It also doesn’t do much good near the equator where the sun’s path on the sky remains fairly constant throughout the year. In those regions, you are better off with thick walls, small windows, and lots of air conditioning.

Assessing the context and identifying implicit constraints or assumptions in proposed designs is an architect’s key responsibility. Sometimes, architects are described as the people dealing with non-functional requirements. I find that more often than not architects have to deal with non-requirements, implicit needs or assumptions that weren’t communicated at all.

Even the dreaded Big Ball of Mud can be “fit for purpose”, e.g. when you need to make a deadline at all cost and can’t care much about what happens afterwards. This may not be the context you wish for, but just like houses in some regions have to be earthquake proof, some architectures have to be management-proof.

Passing the Test

Having stretched the overused building architecture analogy one more time, how do we translate it back to software systems architecture? Systems architecture doesn’t have to be something terribly complicated. It must include, however, significant decisions that are well documented and are based on a clear rationale. The word “significant” may be open to some interpretation and depend on the level of sophistication of the organization, but “we separate front-end from back-end code” or “we use monitoring” surely have the ring of “my door reaches the ground so people can walk in” or “I put windows in the walls so light can enter”. Instead, when discussing architectures let’s talk about what isn’t obvious or something that involved heavy trade-offs. For example, “do you use a service layer and why?” (some people may find even this obvious) or “why do you use a session-oriented conversation protocol?”

It’s quite amazing how many “architecture documents” don’t pass this relatively simple test. I hope using the building analogy provides a simple and non-threatening way to provide feedback and to motivate architects to better document their designs and decisions.