The discipline of software architecture, and the role of the software architect, remains somewhat nebulous after nearly 30 years of prominence. Its origins go back even further, and it derives from an straightforward analogy. That analogy is to the field of civil architecture. But, the closer we examine this analogy, the less it seems to hold up.
Considering Civil Architecture
Civil architecture is often conceived as a planning and design endeavor. However, it is easy to miss that the planning and design is not merely abstract. Varying levels of detail tend to be included in a set of architectural drawings. It is also not unusual for the architect to collaborate closely with civil engineers and others involved in construction. This leads to the work of the civil architect being nearly equal parts prescriptive and descriptive. I believe it is the assumed separation between the work of the civil architect and those doing the construction that leads our misunderstanding of this analogy.
Building Software
It can be easy to think that the construciton phase of software development is found in the writing of source code. But, that assumption is mistaken. In the essay “Programming Is an Act of Design” from 97 Things Every Software Architect Should Know, Einar Landre helpfully observes that “software development is a processes of discovery and learning, not a process of engineering and construction.”
I believe Landre goes on to correctly identify that the process of compiling and running the software is the most analogous to the construction phase of civil architecture. This means that the source code of software is not the output of construction, but is the design of the system; its blueprint. The source code is the architecture of the software system. The source code specifies the meaningful details, and the rest of the build process that is handled by the computer and other software does the construction. This means that what we tend to observe as the abstract work of the software architect is mere ideation, since it lacks any meaningful or useful specificity. Only the source code actually provides actionable and useful design detail.
Even in the architecting of interconnected systems, the high-level drawings of how we think things fit together are speculative. The actual configuration, customization, and programming of the details is the meaningful expression of design and architecture. Because, from those elements, the construction is then automated and any mistakes in the design laid down in configuration or code become effective.
Tendencies in Software Architecture
Many conceive of software architecture as being those processes of abstract design. While such ideation can be helpful and even necessary, they can not deliver value themselves. This misunderstanding of architecture strains both the anology to civil architecture, but also reduces the value of what such architects produce. Still others press for very fine minutia to be considered the concern of the software architect. While they are arguably doing better than the abstract architect, they may well err in wanting to dictate from afar in a way that undermines their credibility and even their ability to do well in their role.
Martin Fowler’s definition from “Who Needs an Architect?” is fairly well know:
Architecture is about the important stuff. Whatever that is.
And, while I love that defintion, I observe that many will quibble over its extent. We like to argue about what is or is not important. We seem to relish expanding the scope of what should be considered architecturally significant. But few will seriously consider the more practical advice Fowler gives later in the very same article:
I think that one of an architects most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs.
This advice is perhaps the most meaningful part of the article, with the possible exception of one other observation that Fowler makes and that I will come back to. How many of us believe that removing architecture is one of the most important things that an architect can do? I’ve seen too many aspiring architects, or folks in the role, that seem to think their most imporant task is to insert themselves into decision-making processes, and to concern themselves with the minutia of their team’s decisions. These sorts of tendencies to either be too abstract, or too expansionist are both serious errors.
Developers Are Architects
If we go back to Landre’s insights, we should easily recognize that with the source code as the real design document for a software system, every developer is an architect. That means an architect is only effective in their role to the extent that they are still an active developer working with their team. Writing source code is the valuable design work, so architects ought to be engaged in it. And, they ought to recognize that the other developers on their team are doing architectural work too. So, how can the architect do their work well? What should they be doing more of?
Architect Archetypes
It is at this point I want to consider the other observation that Martin Fowler makes in his article, “Who Needs an Architect.” He identifies two different archetypes for the role of software architect. The first is like the two errant approaches that I noted earlier, and Martin calls this archetype the Architectus Reloadus. He draws on the presentation of the character of The Architect from The Matrix Reloaded movie. This archetype is typified by two characteristics. First, they seek to be the person “who makes all the important decisions.” And, second, they often seek that end because they do not ”think that the team members are sufficiently skilled to make those decisions.”
In many cases this type of architect seeks to impose their will and sense of wisdom on their team by various means. Instead of being a partner and collaborator, they are, at best, a benevolent dictator. This archetype is both common and an anti-pattern, if we recognize that software architecture is about the code we write, not the decisions we make. This negative archetype is expressed when we see architects insisting on being involved with all technical planning decisions, heavy-handed code review, or dictating rather than collaborating with teams. The expression of our software in code can rarely be dictated effectively, and even less so when the ones dictating are not in the thick of the problems being solved.
This is where the other archetype that Fowler mentions comes in, the Architectus Oryzus. Fowler identifies the leading characteristic for this type of architect is that of “intense collaboration.” He gives the example for this type of architect pairing with a developer on their team, and calls out that their most important activity is mentoring so that the team can tackle complex issues themselves. the observation of the collaborative, mentoring, and guiding role of this type of architect then led to this perspective:
This leads to the satisfying rule of thumb that an architects value is inversely proportional to the number of decisions he or she makes.
Fowler even notes that the prevalence of the Architectus Reloadus type in the industry, circa 2003, was so common that he and other coworkers were uncomfortable with the very title architect. They searched for other and better descriptive titles. Even sixteen years later, I find that the title of architect does not sit well with me, much like it did not sit well with Fowler, et al. I’ve observed it being used in too many inconsistent and unhelpful ways, just like they had. But, I’m no closer to a wholly suitable replacement for the title, although I am actively searching for one.
Architect as Guide
I have consistently viewed the software architect role as one that involves teaching and advising. But, it was only recently that I fully appreciated the notion of the architect as guide. In re-reading Fowler’s article I was pleased to see him describe how he and his colleagues arrived at the same place I had. I have come to realize that the best way to teach is to work alongside those who want to learn. The best way to share advice is to also experience the conditions that are giving rise to the need for advice. And, the best way to shape software architecture is to enable more developers to think about the issues involved well.
Being an architect is not about making the important decisions. At best, that kind of architect is going to end up as a benevolent dictator. The best thing an architect can do is enable their team to make the important decisions themselves. Without that approach architects aren’t going to grow their team appropriately. The problems of accidental architecture and architectural erosion will persist under such a lackluster approach to architectural oversight.
But, if an architect is a true collaborator. Guiding their teams to know, understand, and make better decisions themselves. If that is the kind of architect we can strive for then our teams will thrive and grow. The architect is then an engineer of engineers, a developer of developers. The architect as a guide emphasizes trust, cooperation, shared experience, mutual growth, and respect. This is the model we ought to strive for.
Who Does Software Architecture?
Returning to the titular question of this post, I think the answer is straightforward: every developer does software architecture. So, what is the role of those given the title or responsibility of being the architect? They are a guide, a shepherd, a fellow developer helping other developers to make the best decisison they can, whether the architect is available or not. The software architect is another developer who recognizes the value in investing their energy into making every other developer they can better.
Top comments (0)