Chris 
We all understand that good communication is critical to any productive collaboration. We also recognize the need for shared language or shared understanding. This is why, in an interview context, once we get beyond the introduction stage, one of the first questions I ask is: “What is Architecture?” or “What is the Architect Role?”. These are not trick questions. There exists a divergence of understanding of what the role involves, largely based on first-hand experience and local context. Thus, I find these questions to be good ice-breakers to see how closely a candidate and I align in our understanding of the role and its responsibilities, as this alignment is crucial for effective collaboration.
What is Architecture?
Even Martin Fowler, in his seminal whitepaper “Who Needs an Architect?,” refused to provide a definitive answer. Instead, he relied on Ralph Johnson’s famous definition from a post on the Extreme Programming mailing list:
“Architecture is about the important stuff. Whatever that is.” — Ralph Johnson
A similarly abstract definition comes from Edwin Marrima:
“Architecture is the stuff you can’t Google.” — Edwin Marrima
While perhaps a bit ‘tongue-in-cheek,’ these definitions contain hidden nuance. Architecture being about what is important alludes to the idea that it should focus on the most critical or costly questions. The notion that architecture is the stuff you cannot Google suggests that it deals with highly dynamic and contextual problems, unlike specific problems that others have already solved and documented.
These definitions highlight why providing a concise definition of architecture is such a challenge.
According to Wikipedia:
This is probably more in line with a typical concrete definition. However, any such ‘comprehensive’ definition quickly becomes outdated due to the dynamic nature of architecture. Is architecture exclusively concerned with fundamental structural choices? Does this hold in today’s industry, with, say, a DevOps-based project/company? What is the real cost of ‘costly changes’ when costs can be offset through technology? Should we fear change when working iteratively, making change a first-class citizen within one’s process?
The TOGAF framework provides a two-fold definition based on context:
“The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.”
“The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.”
— TOGAF Standard 9.2
Here, the idea of ‘design principles’ emerges. Clearly, describing or making decisions about an element’s structure is not sufficient; we need to discuss the governing principles on which it is based.
Finally, ISO/IEC/IEEE 42010:2022 provides a thorough but less concise definition:
“An architecture of an entity, expressed in one or more architecture descriptions (AD), assists in understanding the fundamental concepts or properties of the entity, pertaining to its structure, behavior, design and evolution, such as feasibility, utility and maintainability, and fundamental concepts for its development, operation, employment, external impacts, utilization, and decommissioning.”
— ISO/IEC/IEEE 42010:2022
Though comprehensive, this definition’s thoroughness makes it brittle; it will need constant updating as the duties, responsibilities, and concerns listed continue to shift and expand over time.
I will not attempt to provide my own definition, knowing it will be incomplete, likely contextual to my current experience, and even if correct, would quickly become outdated as architecture evolves.
Instead, we can perhaps start by agreeing on some possible tenets:
- No agreed-upon concise definition
- Massive in scope
- Continuously changing/expanding
- Operates in a rapidly evolving ecosystem
- Dynamic in nature
- Highly contextual
- Everything has a trade-off
Based on these tenets, we can describe our expectations for someone filling the architecture role. What responsibilities are attached to this role?
Join Me for the Next Post!
Thank you for reading! I hope this exploration of what architecture means has been insightful. In my next post, I’ll dive into the role of an architect and the varied expectations and responsibilities that come with it. Stay tuned and join me as we continue this journey into the world of architecture.
Don’t miss out! Follow me on socials for updates on the latest posts. See you soon!
Acknowledgments
This post takes inspiration from the book Fundamentals of Software Architecture: An Engineering Approach by Mark Richards and Neil Ford. I highly recommend it to anyone interested in the field.
Saucony Endorphin Speed 2 Review