Part II – Architecture
The many definitions of software architecture compiled by Carnegie Mellon University's Software Engineering Institute [1] suggest that the phrase has no obvious meaning when examined on its own. While the terms "architecture" and "software" each have precisely defined meanings, how they combine depends entirely on the specific context in which they're applied.
Gregor Hohpe argues that every piece of software has an architecture, even if it wasn't intentional. That architecture should drive the efficiency of engineering teams by enabling parallel development and evaluation of the components being built. He also argues that no architecture is perfect, and there's always a combination of trade-offs to weigh, with context being the organizing principle behind all of those decisions.
Software architecture documentation should capture the non-trivial decisions and always give the reader the reasoning behind each choice, along with the context that drove it. It should also emphasize what's essential, de-emphasize what's unnecessary, and describe the limitations of any architectural choice. It's essential to recognize that every important decision comes with trade-offs.
The author warns that decisions too costly to reverse later should be made early in the project, to avoid stalling progress by second-guessing every new element introduced. Quoting Martin Fowler, Hohpe explains that one of the crucial jobs of software architects is to remove irreversibility from software design through abstractions [2], patterns, and development paradigms, aiming to minimize irreversible decisions early in the process. If the engineering team's level of familiarity with the technologies involved isn't sufficient, it's possible to adopt an evolutionary architecture, one that develops as the team's understanding of those tools grows.
Software architecture covers more than components and how they relate to each other. It requires a systemic approach, emphasizing relationships and how each structure acts as a means to achieve a desired behavior. In that sense, techniques like negative feedback loops can be applied, acting as a form of self-regulation for systems through the relationships between the designed components. That focus on behavior should also show up in the documentation produced, where it should be the most relevant aspect, rather than static structures.
Taming legacy software is also a challenge in software architecture, and the key to avoiding obsolescence in these systems is keeping them agile. A system isn't agile if nobody can change it. That fear of change is justified when there's a lack of proper operating practices and techniques, a lack of useful metrics, and sporadic deployments. Fowler puts it this way: "if it hurts, do it more often" [3]. In that context, painful tasks should be performed frequently, so that automation becomes unavoidable.
For software architecture operating at large scale, the author stresses the need for broad automation — from bureaucratic processes like infrastructure request approvals, all the way to application deployment pipelines. Whatever can't be automated should be turned into a self-service system, simplifying routine, predictable activities. One possible strategy for automating this kind of system is building interfaces with validations built into the software development lifecycle, including the use of boilerplate code for new applications and infrastructure service configuration. Tacit knowledge should also be codified into scripts and tools, surfacing these processes and making knowledge transfer easier. Finally, automated systems for widely standardized, explicit processes make compliance audits easier.
Software architecture implies making design decisions to prevent developers from exercising unnecessary creativity. This means certain processes should be established up front and kept as standards, simplifying software operations and freeing up engineering teams to focus on what actually drives the company's business differentiation. Standardizing IT components simplifies operations, allows for economies of scale, and saves money thanks to greater purchasing power with vendors.
This standardization should be considered at two levels: the lower level, where the goal is to maximize reuse, since it's rarely what differentiates the company; and the upper level, made up of internally developed software, which provides the real value and competitive differentiation in the market. There's an element of conformity here, where few changes happen at the lower levels, making it easier to standardize around a common set of tools.
When drawing software architecture diagrams — whether using C4 models [4] or other graphical notations — the boxes representing components usually get the spotlight. However, from Hohpe's perspective, these diagrams should be designed with a focus on the functionality and relationships between those components, through the lines and arrows, in order to highlight the communication between the elements that make up the system at different levels. This approach leads to a clearer, more effective understanding of the software's architecture and its dynamics.
Finally, when adopting a set of technologies from a single vendor, it's crucial to question the boundaries of each tool and how they relate to the system as a whole. This makes it possible to establish the boundaries of the proposed solution and ensure a more effective approach to software architecture.
Closing thoughts
The difficulty in precisely defining software architecture comes from trying to tie it directly to software's most fundamental components, like data and code. While topics such as layered architecture, design patterns, and source-code design are related to software architecture, that association is only partly true. As noted, the strategies shaped by the context the software architect operates in are inseparable from the principles that guide the design, implementation, and evolution of these systems.
It's essential to establish the boundaries, responsibilities, and relationships of each component chosen to make up the architecture map, taking into account all the constraints imposed by the environment and the subject being observed, whose systemic representation will be built. In this way, software architecture goes beyond basic components and covers broader, more complex aspects, involving decisions and strategies specific to each context and project.
References
- What is your definition of software architecture? – Carnegie Mellon University
- Who Needs an Architect? – Martin Fowler
- Frequency Reduces Difficulty – Martin Fowler
- C4 Model – Simon Brown