In software architecture, there are four dimensions. They are interconnected—think of a puzzle made up of small pieces. Each piece has a unique shape, and together they form a complete picture.

They are:

  1. Architecture characteristics
  2. Architecture decisions
  3. Logical components
  4. Architecture styles

In this part, we will talk about the first dimension: Architecture Characteristics.

Architecture Characteristics

Architecture characteristics form the foundation of a software system’s architecture. Without them, you cannot make good architecture decisions or analyze important trade-offs.

Think of it like choosing between two homes:

  • One home is very spacious, but it’s next to a noisy motorway.
  • The other home is in a quiet neighborhood, but it’s small.

Which characteristics matter more depends on you, space vs. quiet.

The same applies to software architecture. For example, when choosing a tech stack (Node.js vs. Go), you might ask:

  • Is performance a key concern from day one?
  • Or should we choose Node.js because it aligns well with the front end (e.g., React) and team skill sets?

I hope you now have a fair understanding of what software architecture is. Next, we should understand what architecture characteristics are.

In a bank, what characteristics can you think of?

  1. Auditability — Banks should be able to verify transactions.
  2. Data integrity — All financial transactions should be consistent and accurate.
  3. Security — Banks need strict security to protect financial data and transactions.
  4. Scalability — The system should support many concurrent users.
  5. Usability — Customers should be able to complete online transactions accurately and easily.

“-ilities” in architecture characteristics

There is something commonly referred to as the “ilities” in architecture characteristics:
Scalability Accessibility Observability
Availability Maintainability Testability
Interoperability Reusability Portability
Security Simplicity Feasibility
Stability Reliability Usability
Agility Integrity Performance
Traceability Localizability Auditability

As you can see, there are many , and this still isn’t a complete list. But there is a key rule when defining architecture characteristics:

“Limit characteristics to prevent overengineering.”

What this means is: a system can support many characteristics, but it shouldn’t try to optimize for everything. Almost every architecture characteristic adds complexity.

As software architects, we should aim to pick as few characteristics as possible, not as many as possible, because:

1) Impossible to standardize

Different organizations use different terms for the same characteristic. For example, performance and responsiveness can refer to similar behavior.

2) Synergistic

One architecture characteristic affects others (and domain concerns). For example, making a system more secure can negatively impact performance.

3) Overabundant

The list of possible architecture characteristics is huge, and new ones appear all the time.

In the next part, we will talk about:

  • Process architecture
  • Structural architecture
  • Operational architecture
  • Cross-cutting architecture