Context
Software architecture has been the subject of heated debate among engineers and IT managers for decades. Many works by great authors — Mark Richards, Sam Newman, Len Bass, George Fairbanks, Frederick Brooks Jr., among others — have helped shed light on this vast topic.
This review covers the first part of the book "The Software Architect Elevator" [1], written by Gregor Hohpe [2], who is also the author of the acclaimed EIP, "Enterprise Integration Patterns" [3], a catalog of essential patterns for integrating systems.
Part I – Architects
In this first part, the author lists the skills and traits that are desirable in a software architect, and what roles they should play within an organization: broad strategic vision, technical leadership, and being a good people manager. The author states that these professionals need to handle discussions that go beyond the purely technical, such as the situational context they're operating in and certain tacit assumptions, which sometimes hide fundamental contextual information, as well as establishing communication across different organizational levels.
Finding the right balance in design decisions, according to the established goals and principles, is essential — connecting software components so they can work together to achieve the expected outcome, all while managing complexity through governance techniques.
When it comes to communication, the author uses the metaphor of a building's elevator, connecting the lower floors — where systems engineers work on building and maintaining the business's software systems — to the upper floors, where the executives responsible for the business's high-level abstraction sit. This connection is represented by the metaphor of a building elevator. In this context, the architect's job is to move naturally between these floors without losing the essence of the message — in other words, adapting the language used to the specific needs of each audience.
In situations where there's resistance to the software architect's role in communicating across levels, the author argues that it's necessary to work at reducing that resistance. One way to do that is by getting the upper levels genuinely interested in and aware of the projects being carried out by engineering. It's also important to establish frequent feedback loops.
On the technical side, Hohpe describes how architects must ensure that the solutions being built preserve the balance and proportion of the original ideas. This same ability is mentioned by Frederick Brooks Jr. in his book "The Mythical Man-Month", where it's called "conceptual integrity." Brooks highlights how important it is for the architect to work at tying together the ideas that make up the system and preserving the cohesion of the whole.
An architect's experience across projects of different sizes is essential, giving them the sensitivity to spot opportunities for change that go beyond a system's expected functional requirements. These changes might include the need to support shifts in the volume of data being processed, environment changes when the system is moved to a new cloud provider, or the need to implement globalization features so the system becomes available in multiple languages.
Another important technical aspect is promoting the building of tools for building and shipping software to production, increasing the speed of delivering changes while also reducing the risk of errors from manual operations carried out by operations teams. A software architect must ensure their technical judgment stays free of bias, so they need to make sure they're in touch with other experts who can give them information that lets them see past the buzzwords and discern whether a solution is genuinely new, or just "cleverly reheated." This matters, because it curbs the temptation for an architect to stay comfortable with the same set of solutions, or to irrationally adopt new tools without good reasons to apply them.
According to the author, enterprise architecture is the logical organization of business processes and the IT infrastructure that supports them, bringing together the work of business and IT architects. There are various business-process mapping tools that architects use. According to Hohpe, architects should be cautious about using these tools as mere documentation, since the end product can become outdated the moment it's released. However, this static approach presents a recurring dilemma for architects, since it may not accurately reflect the constantly changing interactions within the business environment.
There are different levels of seniority for software architects, which, according to Hohpe, can be identified by applying the tripod of skill, impact, and leadership — where skill refers to the ability to solve real problems with the right tools; impact measures how the architect's skills benefit the company, helping it reach its strategic and market goals; and leadership, which determines the architect's ability to advance the state of their practice, sharing knowledge through talks, blogs, publications, and mentoring other professionals.
Finally, the ability to ask the right questions and identify who makes the decisions — and the motivations behind them — is an indispensable skill for a software architect.
Closing thoughts
The reflections Hohpe presents in this first part are essential for understanding the position the software architect occupies within the complex organizational ecosystem, which involves multiple stakeholder groups, going well beyond purely technical decisions related to engineering or operations.
That said, it's worth highlighting that communication and decision-making ability is the single most important factor for successful management, regardless of the area in question — whether to set a new direction or change the trajectory of a project that has drifted from its plan.