1. Introduction
This post is a reorganized version of the study notes I wrote after reading the introductory part of a book on software architecture. I went back, reread those notes, and shaped them into this article. The goal is not to add new claims, but to put the basic framework into a form I can actually explain.
When I look at the architecture diagrams of the systems I’m responsible for, I can follow the main elements and branches. But when someone asks, “Why this structure and design?”, I can’t quite put the intent and decisions into words.
In this post, I try to untangle that blockage by working through two questions in order:
- Question 1: What is software architecture?
I define architecture using four aspects—structure, architectural characteristics (the “-ilities”), architectural decisions, and design principles—and organize things in a way that explicitly says “architecture is more than just structure.” - Question 2: What is the role of a software architect?
I organize what is expected of architects into eight expectations and treat them, for now, as a provisional definition of what an architect does.
At the end, I then look at how software architecture and the practical work of software architects connect in the context of two “laws”: trade-offs and “why.”
For this post, I limit myself strictly to the scope of what I wrote in my study notes based on the introduction. Points I still can’t express in my own words will be left as TODOs at the end. Rather than pretending I understand more than I do, I want to make the boundary between what I can and cannot say explicit—and make that boundary itself part of this article.
2. Four Aspects of Software Architecture
In this section, I define software architecture using four aspects (structure / -ilities / decisions / design principles) and treat them as axes for explanation. What is expected of architects (their role and behavior) will be handled separately in Section 3, via the eight expectations.
The four aspects are:
- Structure: the shape (what exists and how it is connected)
- Architectural characteristics: the conditions for success (how the system needs to behave)
- Architectural decisions: the rules to be followed (what is allowed and what is not)
- Design principles: day-to-day guidance (preferred ways of doing things)
This is a meta-concept—a set of axes for “how to organize things”—that can be used across all the practical work of design, decision-making, and operational policy.
2.1 What “Structure” Means
By structure I mean things like the architecture style you’ve adopted; how the system is decomposed into modules, components, or services; and how layers, dependencies, and interfaces are connected.
2.2 What “Architectural Characteristics (-ilities)” Are
Architectural characteristics (architectural characteristics: the “-ilities”) are non-functional conditions for success. They are not the features themselves, but the properties that determine whether the system works well. These include quality attributes such as availability, performance, and security. Architectural characteristics sit on a different axis from functionality.
2.3 What “Architectural Decisions” Are
Architectural decisions are the rules and constraints that define how the system must be built—that is, what is allowed and what is not. These decisions should always be recorded together with their reasons (why the decision was made), for example in the form of ADRs. Deciding which layers are allowed to access the data layer directly is one example of an architectural decision.
2.4 What “Design Principles” Are
Design principles are guidelines that steer how the team implements the system. If architectural decisions are the rules that clearly define what is and is not allowed, design principles are what indicate how we prefer to implement things within those rules. For example, a policy like “for communication between services, favor asynchronous messaging over synchronous calls” would be a design principle.
2.5 How the Four Definitions Relate: Architecture Is More Than Structure
Architecture is not just a diagram of “boxes and lines.” It also includes how the parts relate to one another and the externally visible properties of those parts—for example, performance or behavior under failure. To really understand an architecture, you have to look not only at structure but at the other three aspects as well.
- Architectural characteristics (-ilities): what you choose to value as conditions for success
- Architectural decisions: what you allow, what you forbid, and why
- Design principles: which directions you consider desirable in day-to-day implementation
For example, saying “we use microservices” tells you something about structure. But by itself it doesn’t tell you which -ilities are being prioritized, what constraints exist, or what principles guide everyday design.
Each of the four aspects is a different viewpoint, but only when you put all four together do you get the full picture of an architecture. This is where I’ll stop for “What is software architecture?” In the next section, I’ll organize what is expected of software architects with respect to that architecture as eight expectations.
3. Eight Expectations for Software Architects
Defining the role of a software architect is difficult. In the literature, descriptions range from “expert programmer” to “the person responsible for a company’s technical strategy.” If you go searching for a perfect role definition, it’s easy to become more confused instead of less.
The authors I’m reading argue that, rather than trying to pin down the role itself, we should look at what is commonly expected of people in architect roles.
What they present is the following Eight Core Expectations. These are the expectations said to apply to architect roles regardless of differences in title or organizational context:
- Make architecture decisions
- Continually analyze the architecture
- Keep current with the latest trends
- Ensure compliance with decisions
- Have diverse exposure and experience
- Have business domain knowledge
- Possess interpersonal skills
- Understand and navigate politics
According to the authors, the first step toward being an effective and successful architect is to understand these expectations and practice them in everyday work. For now, I’m treating these eight expectations as a provisional definition of what a software architect does.
3.1 Make Architecture Decisions
“Making architecture decisions” means defining the important decisions that guide technology choices for a team, a department, or the entire organization. These decisions are expressed as constraints, rules, and design guidelines, and are not the same as personally picking every tool. That said, when protecting critical qualities such as scalability, performance, or reliability makes it necessary to standardize on a specific technology or pattern and lock it in, that standardization also counts as an architecture decision.
3.2 Continually Analyze the Architecture
“Continually analyzing the architecture” means regularly assessing the current architecture and technology environment, finding risks, bottlenecks, and signs of decay, and proposing the changes that are needed. This is what allows the system to stay aligned with business needs and key quality attributes over time.
3.3 Keep Current with the Latest Trends
“Keeping current with the latest trends” means continually tracking new technologies and industry movements, understanding and monitoring important changes that could affect your systems, and feeding those insights into architectural choices that remain reasonable over the long term.
3.4 Ensure Compliance with Decisions
“Ensuring compliance with decisions” means continually checking whether the architecture decisions and design guidelines you’ve defined, documented, and shared are actually being followed by development teams, correcting any deviations, and making sure the intended qualities—such as scalability, availability, and performance—are preserved.
3.5 Have Diverse Exposure and Experience
“Having diverse exposure and experience” means having hands-on experience with a wide range of technologies, frameworks, platforms, and runtime environments, understanding the strengths, weaknesses, and ways they can be combined, and being able to make decisions from that broad perspective rather than from a deep attachment to any single technology.
3.6 Have Business Domain Knowledge
“Having business domain knowledge” means understanding the core concepts, terminology, metrics, and business processes of the domain you work in and, on that basis, being able to design architectures that align with the organization’s goals. It also includes being able to discuss things with stakeholders in the language of that industry, not only in technical terms.
3.7 Possess Interpersonal Skills
“Possessing interpersonal skills” means having the ability to move architecture implementation and decision-making forward through people. Concretely, it means using communication, collaboration, facilitation, and leadership to align stakeholders, build trust, resolve conflicts, and help teams execute on the architectural direction.
3.8 Understand and Navigate Politics
“Understanding and navigating politics” means recognizing that architecture decisions affect costs, effort, and ways of working and will inevitably bring resistance and negotiation, then reading the power dynamics and interests in the organization and using influence, negotiation, and consensus-building to get those decisions accepted and carried through into execution.
3.9 Section 3 Summary
These eight points are the core expectations commonly placed on software architects. Understanding them and practicing them in everyday work is the first step toward being an effective, successful architect. For now, I’m using these eight expectations as a provisional definition of the software architect role.
In the next section, I’ll introduce two laws—trade-offs and “why”—as lenses for interpreting the software architecture and the architect’s work described so far.
4. Two Laws of Software Architecture: Trade-offs and “Why”
In Section 2, I organized software architecture into four aspects (structure / -ilities / decisions / design principles), and in Section 3, I reviewed the eight expectations placed on software architects. From here, I’ll introduce two laws as ways of looking at those when explaining, thinking about, and moving architecture forward.
4.1 First Law: Software Architecture Is All About Trade-offs
Every architecture decision involves trade-offs. There are no simple right-or-wrong answers, and there is no solution that is “always correct.”
4.2 Second Law: “Why” Matters Far More Than “How”
“Why (you did it that way)” is much more important than “how (you built it).” Design diagrams and system diagrams can show the “how,” but they cannot show the “why.” That’s why the reasons and assumptions behind architecture decisions, and the trade-offs involved, need to be made explicit and written down.
4.3 What the Two Laws Point To
These two laws provide ways to reframe architecture and the architect’s work in terms of trade-offs and “why.” They make it easier to organize a system’s structure and design in a way that covers not just the “shape” but also the intent behind it.
5. Conclusion
In this post, using the study notes I created from the introductory material on software architecture as a starting point, I worked through the following two questions in order:
- Question 1: What is software architecture?
- Question 2: What is the role of a software architect?
For Question 1, the provisional answer I arrived at here is this: by viewing software architecture through four aspects—structure, architectural characteristics (-ilities), architectural decisions, and design principles—you can at least explain the following points within a consistent framework:
- Structure: units of decomposition and how they are connected
- Architectural characteristics (-ilities): non-functional conditions for success
- Architectural decisions: constraints that allow or forbid things, and their trade-offs
- Design principles: guidelines for implementation decisions and how they relate to the decisions
For Question 2, my position in this post is that it’s more realistic to describe the role of a software architect in terms of eight expectations than to force a perfect definition. For now, I’m treating these eight expectations as a provisional definition of what a software architect does.
Finally, software architecture and the architect’s work can be reread in the context of the two laws. As the First Law says, architecture decisions always involve trade-offs, and there is no simple, universally correct answer. As the Second Law says, structure and design diagrams show the “how,” not the “why,” so the reasons and assumptions behind decisions, and the trade-offs involved, need to be made explicit and written down. These two laws provide a way to view the four aspects and eight expectations in terms of intent and judgment.
That said, this framework alone does not completely cover everything there is to say about architecture. Through the eight expectations for software architects, I’ve touched on external factors such as organizational, business, and political dynamics, but I haven’t gone as far as explaining how specific assumptions and constraints influence each individual architecture decision. The four aspects, eight expectations, and two laws discussed in this post form a minimum foundation—a starting point—for explaining architecture and the architect’s work without breaking down.
From here, I’d like to write out my own systems using this framework and separate the parts I can explain from the parts where I get stuck. The gap between those two will become my next set of architecture TODOs.
TODO
- Be able to write concrete examples of structure (architecture styles, examples of decomposition and connections) using my own systems.
- Write out my current system using this framework and separate the parts I can explain from the parts where I get stuck.
References
https://www.oreilly.com/library/view/fundamentals-of-software
Leave a comment