Large organizations have a lot of layers. From the C-Suite that is concerned about strategy and vision, to middle management who are executing on projects and programs, down to individual contributors working on project features. These layers provide a number of advantages, all derived from being able to better manage complexity. For example, layers provide a nice separation of concerns: as a software engineer, I don’t have to worry about tax codes and payroll because the finance department can take care of this. As an intern, I don’t need to worry about the global marketing strategy, I can just take care of implementing the widgets we need delivered to customers.
Large software systems are like large organizations, and we also use layers to deal with complexity.
We can solve any problem by introducing an extra level of indirection.
The Fundamental Theorem of Software Engineering — Andrew Koenig
While the fundamental theorem is meant in jest, like any good joke there is some truth to this — layers are useful! We don’t add them to a software system for fun, we add them to solve a problem and for the advantages they bring, like standardized interfaces and a clear separation of concerns that allow us to build a system in a modular way. Of course, there is no such thing as a free lunch. Layers come with downsides! Namely, layers increase overhead and add latency. Any time we information needs to move through the system, it needs to interact with the boundaries between each layer.
Notably, the benefits of layering are mostly structural and impact the static design of the system, while the drawbacks are mostly behavioural and impact the runtime performance of the system. This is, in fact, the ideal balance when you are dealing with a static system that does not care about runtime latencies. Unfortunately, in the software industry things are not slow moving — competitors, new technologies, and new development methodologies are constantly pushing the pace of development times and a software organization does care about latencies. And if you do care about latencies, then the drawbacks of a layered architecture become more important and threaten to outweigh the benefits.
How do we deal with this in a large organization? One approach is to flatten the architecture and reduce layering. While this can be done, it doesn’t fix everything, and can even make things worse. By flattening the organization you remove all of the benefits that layers provide — without clearly defined interfaces and the ability to isolate dependencies, we lose our ability to handle complexity.
A second approach — that doesn’t involve blowing up the entire organization — is to leverage architecture. Successful architecture in a modern enterprise acts as the connecting element throughout the organization by translating business goals and strategy into final resulting systems. Gregor Hohpe calls this riding the architect elevator. Rather than focusing on technical decisions alone, architects need to combine organizational and technical knowledge to cause change in the organization’s structure and processes as well as in the technical platform. To do so effectively, they must connect the penthouse, where the business strategy is defined, and the engine room, where the enabling technologies are implemented.
The value of the architects in this scenario should not be measured by how “high” they travel, but by how many floors they span. This is a common mistake in large organizations where the folks in the penthouse tend to see only the architects in the upper half and assume that they have more value. Conversely, many developers or technical architects consider “enterprise” architects less useful because they don’t code. This can be true in some cases – these architects enjoy life in the upper floors so much that they are not keen to take the elevator ever down again. But an “enterprise” architect who travels half way down the building to meet up with technical architects can have a significant value.
The Architect Elevator — Gregor Hohpe
This metaphor can also help us structure an architecture team. In many organizations, architecture is delivered from a central architecture team that is positioned close to the penthouse. This structure leads to a disconnect between the business strategy coming out of the penthouse and the technology innovation and project delivery coming from the engine room. A better model is to build a more vertical architecture team. One that includes architects and technical leaders from many different levels: enterprise architects, strategic architects, solution architects, and technology specialists. This structure covers all floors of an organization and ensures that each architect is part of the necessary connections and feedback loops to work throughout the organization.
With so much going on in the upper floors, some architects may wonder whether they should become organizational designers rather than technical architects. That would be putting the baby out with the bathwater, though. Designing and influencing the organization depends on a thorough understanding of software delivery and technology innovation. It’s the combination of technical acumen and organizational skill that makes modern architects valuable.
The Architect Elevator — Visiting the upper floors — Gregor Hohpe
Many architects feel that the upper floors are not accessible to them. Would a CEO or vice president really want to talk to them? More often than not, they do. Many penthouse members feel disconnected from the reality in their organization and are grateful if someone reaches out to them and speaks their language, while also having their feet firmly planted in the realities of the engine room.
So, keep riding the architect elevator, visit the upper floors, and don’t forget to come back down!