Software architects are often seen as persons that live in an ivory tower. A person that shines his divine knowledge down upon the lesser developers. But that hardly gives architects the credit they deserve.

The picture of an ivory tower resident creates a lot of trouble. 

• Developers don’t trust the architect to act in their best interest and be relevant to them. 
• Management gets misleading information from the architect who doesn’t know what is going in the IT engine room. 

The software architect title describes a critical role for an organization’s coherence, tying together the penthouse and the engine room. But I haven’t met many architects who could put exact words on what an architect does. It becomes fluffy. 

Fluffy roles tend to become irrelevant because it makes it hard to understand what is part of the role and what isn’t.

In the book the software architect elevator Gregor Hohpe paints a clear picture of what a software architect does and how he should approach different aspects of the job. Virtually a 300-page job description! 

The Software Architect Elevator

It contains so much knowledge that it is going to take multiple reads to internalize it. I especially like how it paints a holistic view of an architect. From how to draw diagrams to organizational understanding, all with a technical backdrop.

I can’t recommend it enough if you are looking to understand what a software architect does.

Some of the insights I have found most useful or interesting are described here, but you should read the book to get all the gold nuggets. 

Why do we need architects at all?

The architect’s primary role is to be the coupling between the management penthouse and the engine room, hence the elevator analogy. 

The architects’ responsibility is to communicate with management, understand the strategy, ride the elevator to the engine room, and translate the strategy to software with the developers’ help. 

After understanding the options available, he rides the elevator back to the penthouse to share his findings and make decisions—all in an iterative process.

Why is it that we need architecture at all? The primary influence on our architecture is the rate of change. We need the architecture to be able to absorb the changes. And change is speeding up!

Consider if a system is static and 100% known we just need to make it work. Architecture doesn’t matter. But the more change we need to absorb, the better architecture we need.

We know that technology is moving rapidly, especially in areas like the cloud and frontend. It is essential to have good architecture to avoid getting stuck with decisions that we can’t change.

So what is architecture anyway?

A lot can be said about architecture on the code level, but architecture has a more overarching purpose. 

Tradeoffs govern everything we do. No decision is perfectly right or wrong. If we decide to use a particular database or use a special way of communication between services, one decision will make some decisions irrelevant and others impossible.

Most of the decisions are technical. But developers can’t evaluate the value of the impact alone. Since decisions have a business impact, they need input from the business to understand the right value. Decisions are possibilities.

The job of the architect is to translate the sometimes deeply technical options into business options. That can be more easily said than done.

You could think of an architect as having an options shop where management can overview the different decisions they have available, the cost, and the impact. 

All decisions are made only with the currently available knowledge we get wiser in the future. Because of that, we might find that a previous decision was wrong. A good architecture makes it cheap to reverse decisions.

Another aspect of architecture is to provide a framework for developers to work within. Giving everybody the freedom to do everything is not a place we want to be. It will require each team to reinvent everything, and there will not be any similarities between teams.

Instead, we want architecture to provide reasonable limits and decisions to help the teams focus on their work. Having limits doesn’t limit creativity. An artist can be creative by using an A4 paper, avoiding thinking about which size to pick. It is already predefined.

Communication is important

When communicating deeply technical things to capture the audience’s attention, we must focus on its outcome. 

We will not sell a box of lego by focusing on the bricks, but if we “show the kids the pirate ship” they will get as excited as we are.

I have often sat at a technical presentation with a PowerPoint show that dragged on and on about every little technical detail about a solution without showing the pirate ship first. 

Only in the end, when the audience has fallen asleep sometimes, a glimps of the pirate ship was shown. Be the architect that excites the audience first.

Showing the pirate ship has an additional benefit. It forces us to focus on the purpose of what the individual pieces are doing. A database doesn’t have a business purpose; it needs to be part of a larger whole to give meaning. 

Controlling the projects

Management sets the direction, and it trickles down the organization where it is carried out. This thinking imposes that the order is carried out right and understood. Sometimes that is an illusion. But why does it happen?

The gaps between each part create the illusion when they are ignored. There is a knowledge gap between what reality is and what we plan for. There is an alignment gap between a plan and the actions. And an effects gap between the effect we expect the actions to have and what happens.

To make the gaps smaller, they can’t be eliminated. We can do a few things smarter. Instead of giving direct orders, we can make a “mission command” to ensure the purpose of the mission is understood. It is the goal that is important, not the process. That makes it possible for the people executing an order to adjust as they learn.

One way to get control is by being agile. Many people don’t actually understand agile and mistake it for meaning fast and subtle. But agile is about hitting the right target by recalibrating often and embracing change instead of trying to predict it. 

An analogy is that it is fast to shoot at a target far away, but you are likely to miss where agile is more like a guided missile if used correctly. 

Moving from legacy to modern technology

Most large organizations are not created to change. Thus creating change in such an environment is challenging but rewarding. 

For architects to move the organization, all talents are needed.

• Understanding the organization
• Communicating to gain support
• Leadership skills to make the changes last.
• Technical skill to plan and implement how the tech and the organization change together.

It is a gordian knot of interdependencies that the architect must solve. And because the role of an architect is to tie together the management with the engine room, he is best positioned to solve it.

Summary

This small summary, which highlights some of the book’s topics, is just the tip of the iceberg. You should read it to gain the full benefit.