In this article
Summary
Software architecture is the high-level structure of a software system: the major parts it consists of, the responsibilities each part carries, and the dependencies that connect them. The decisions behind that structure determine how easily the system can change.
According to State of Software 2026, 50% of the code scores below our recommended architecture rating.
This article covers what software architecture is, how Software Improvement Group (SIG) measures architecture quality, how to visualize it, and why it matters, including what AI changes.
What is software architecture?
Software architecture describes how a system is organized at the highest level: which major parts exist, what each one is responsible for, and how they depend on one another. These structural decisions are costly to reverse once the system is built, so they set the limits on how fast and how safely a team can change it.
Every system has an architecture, whether anyone designed it or not. A team that never drew a diagram still has a structure, and it lives in the code: in how files are grouped, which parts call which, and where the data sits.
Textbooks and standards tend to start from structure. Bass, Clements, and Kazman, in the widely cited Software Architecture in Practice, define a system’s architecture as the set of structures needed to reason about it: the software elements, the relations among them, and the properties of both.
ISO/IEC/IEEE 42010 standardizes how architectures get described.
At the end of the day, a textbook definition is different from the effect it has on your business
Earlier this year, I sat down with someone who has a great way of looking at it. His name is Željko Obrenović, Chief Architect at AVIV Group, and on the SIGNAL podcast, I asked him to define software architecture.
He said: “The role of architecture is to limit needless creativity of people that are building and maintaining systems.”
Needless is the key word here. Creativity is necessary, but when you design a system, you want to avoid every team choosing its own language, patterns, and naming conventions.
A software system is complex enough as it is. It has many moving parts that must work together, and teams must be able to build on top of them in the future. Without a cohesive design that follows the same rules, things get messy quickly.
Let’s take a deeper look.
What are the fundamentals of software architecture?
Four building blocks make up the structure of most systems:
| Element | What it is | Example |
|---|---|---|
|
Components |
The major parts of a system, each with a defined responsibility. |
Customer accounts, payments, order management. |
|
Dependencies |
Places where one part relies on another to work. |
A payments component calling the accounts component. |
|
Interfaces |
The contracts through which parts communicate |
An API, a message format. |
|
Data stores |
Where the system keeps its state. |
A relational database, a cache. |
SIG’s benchmark spans more than 40,000 systems, 600 billion lines of code, and 300+ technologies, so our findings come from measured real-world software systems. In addition, our quality models are rooted in international standards.
According to our latest annual report, State of Software 2026, half of the code we analyzed last year scored below the recommended architecture quality level.
Which raises two fair questions: why does that matter, and scored on what exactly?
Let’s start with the latter.
How do we measure software architecture
There was no standardized approach in the industry to measuring architectural flexibility, so we used our extensive experience and expert domain knowledge to create the SIG Architecture Quality Model.
We define architecture quality as the degree to which an architecture is flexible and adaptable to change.
The basic idea comes down to how well you can understand the structure and interconnections within the system.
The SIG model scores five aspects of architecture, each reflecting how strongly that aspect affects the speed at which foundational changes can be made:
| Aspect | What it covers | Measured by the following properties |
|---|---|---|
|
Structure |
How well the codebase is organized into meaningful, bounded components |
Code breakdown, component cohesion, communication centralization |
|
Communication |
How manageable and well-encapsulated the dependencies between components are |
Component coupling, component adjacency, communication centralization, data coupling |
|
Data access |
How clearly data stores have owners instead of being shared across many components |
Component adjacency, communication centralization, data coupling |
|
Evolution |
How far changes can happen in isolation |
Code breakdown, component coupling, component cohesion, bounded evolution, component freshness |
|
Knowledge |
How widely technical knowledge is spread across developers |
Knowledge distribution, component freshness |
As you can see, each aspect is measured by a combination of properties. There are nine in total, which we measure in the source code and version-control history:
| Property | What it measures | Better when |
|---|---|---|
|
Code breakdown |
How well files are organized into components, rather than sitting loose in root directories |
Fewer loose files |
|
Component coupling |
Total incoming and outgoing dependencies between components |
Lower |
|
Component adjacency |
How many distinct other components a component interacts with |
Lower |
|
Component cohesion |
Whether a component’s internals mostly talk to each other |
Higher |
|
Communication centralization |
Share of a component’s code that has no direct cross-component dependencies |
Higher |
|
Data coupling |
How many components access the same data entities |
Lower |
|
Bounded evolution |
How often components change on the same day as other components |
Lower |
|
Knowledge distribution |
How many developers contribute significantly, relative to component size |
Higher |
|
Component freshness |
How actively a component is maintained |
Higher |
How to visualize software architecture
A great way to visualize software architecture is by creating an architecture diagram.
A software architecture diagram is a visual blueprint that maps out a system’s structure, components, and interactions.
Here’s an example of what a software architecture diagram looks like in Sigrid® Core.
Our platform shows a real-time as-is visualization of the architecture, so you know exactly how your systems are built.
On the side you can see the total score, and a break down of the rating per property.
Why does software architecture matter?
In that same podcast episode I mentioned earlier, Obrenović has a great analogy to explain why software architecture matters; he compared it to being able to play bass.
A friend of his, a guitarist, switched to bass when he formed a band. A good bass player connects the drums to the melody, and you hardly notice them. You just hear a band that sounds better. With a bad one, you hear disconnected instruments.
“The sound of architecture is that the whole organization sounds better,” he said. “It’s moving faster, smoother.”
You notice architecture when it fails, as friction. In his words, “any minor feature may require 20 teams to coordinate.”
So, to come back to the question, why does it matter?
Software architecture determines how fast and how safely a team can change a system.
In a well-structured system, a developer changes one part without surprises elsewhere. In a poorly structured one, every change turns into a search for side effects.
Our research shows the effect. In an analysis of 50 systems, teams resolved issues in systems with 4-star architecture quality in about 30% less time than in a market-average 3-star system, and in about half the time of a below-average 2-star system.
What about architectural debt?
Technical debt represents software quality issues that slow down future development.
It is the extra effort teams spend maintaining and changing software because earlier implementation choices were suboptimal.
There are different types of technical debt.
Architectural debt happens in the relationships between components: it affects how components are linked, how teams rely on each other’s work, and whether the software structure aligns with the original design intent.
This is exactly where AI’s capabilities fall short. AI coding tools and agents have a limited context window and typically lack domain knowledge.
This means that when making decisions, they do not consider your architecture and may try to fill in the gaps independently.
Architectural debt has existed long before AI, however what is changing is the speed at which this debt now accumulates.
Gartner® predicts that:
- by 2027 architectural debt will account for 80% of all technical debt.
- by 2028 AI will create more technical debt on architecture levels than it solves.
It starts with knowing whether the architecture you designed matches the one you built, and what to change to improve it.
If you don’t know how to get started, feel free to reach out, we can help.
About the author
Werner Heijstek
Werner Heijstek is the Chief Delivery Officer at Software Improvement Group and host of the SIGNAL podcast, a monthly show where we turn complex IT topics into business clarity.
See your architecture as-is
Frequently asked questions
Is software architecture the same as software design?
No. Architecture covers the structure of the whole system and the dependencies between its parts. Design covers how a single component works inside. Architectural decisions are costly to reverse, and design decisions are usually cheaper to change.
What is separation of concerns?
Separation of concerns is the principle of dividing a system so that each part handles one distinct responsibility. When concerns stay separate, a change to one responsibility touches one place, such as a tax rule that never requires reading code about emails.
What do high cohesion and low coupling mean?
High cohesion means the elements inside a component belong together. Low coupling means a component depends on few other components. Together they describe a structure where parts that change together live together, and independent parts stay apart.
Does every system have an architecture?
Yes. Every system has a structure, even if nobody designed or documented it. The real question is whether that structure matches what the team intended and still lets people change the system quickly.
How do you measure software architecture quality?
SIG’s Architecture Quality model rates a system from 1 to 5 stars. It scores five aspects, such as structure and knowledge, from nine properties measured in the source code and version-control history, and benchmarks the result against more than 40,000 systems.
Does AI reduce architectural debt?
Not by default. AI can help fix code-level debt such as duplication and complexity. Architectural debt needs whole-system context that AI tools generally lack, so agents working without that context tend to add to it.
AI agents optimize for the task in front of them, and a fix that works locally can break something system-wide.
However, Sigrid® Axis works with AI coding agents to produce secure, maintainable code that respects the architecture it lives in. Each check runs against the architecture of the individual system, repository, or component the agent is working in, not just an organization-wide set of rules.
Learn more about Sigrid Axis.