Architecture Characteristics: More Than Just SLAs

How characteristics emerge—and how to shape them with structure and metrics

If someone asks me, “What is an architectural characteristic?”, I usually go back to my favorite analogy—construction.

Let’s say you’re building a skyscraper on the beach. You'd better make sure it’s wind-resistant. You also need to consider the depth of the water table and the stability of the soil; otherwise, the building may slowly sink. To prevent that, you’d reinforce the foundation or drive piles (сваи) into the ground to anchor it.

But you wouldn't just say “the building is strong.” You’d define measurable values—like "resists winds up to 100 km/h" or *"foundation supports 10 tons per square meter."

These values become SLAs—service level agreements—and the things we measure (wind resistance, load-bearing strength) are your architecture characteristics.

---

What Is an Architecture Characteristic?

A characteristic is a measurable quality that tells you how a system behaves under certain conditions, internal or external.

In software, we care about things like:

• Performance – How fast the system responds.

• Scalability – How well it handles increased load.

• Availability – How often it stays up and running.

• Security – How well it protects data and access.

• Cost – How expensive it is to run and maintain.

These characteristics help us determine whether the system will hold up in real-life situations or collapse under pressure.

---

Cost: The Most Misunderstood Characteristic

Most people think cost means infrastructure or developer time. Some add maintenance. A few consider operational overhead, like manual processes. However, almost no one discusses the cost of change.

That’s where systems quietly become expensive. Every shortcut, every unaddressed complexity adds up and later slows everything down. Here’s where things get tricky.

Developers and architects often use terms like "technical debt" or "technical improvement" to justify fixing these issues. But the moment you say “technical”, the business tunes out. Why? Because it sounds disconnected from value.

So if you actually want these problems to get prioritized, here’s what works:

1. Document architectural decisions, especially the ones where trade-offs were made that increase future complexity. Use short ADRs—Architecture Decision Records—to note what was decided, why, and what risks were accepted.

2. Track business-relevant delivery metrics like:

   • Cycle time – How long it takes to deliver work once it starts

   • Time to market – How quickly new ideas reach production

Now give it a quarter or two.

If those metrics start to degrade, that’s your moment to speak up:

“Here’s why we’re slowing down. It’s because of the decisions and shortcuts we made earlier. Now we’re seeing the impact.”

But if the metrics stay healthy? Perhaps you just wanted to make the code more aesthetically pleasing. And in that case, maybe there’s no real problem to solve. It’s a good test: are you chasing a problem that the business can feel? Or just cleaning up for your own peace of mind?

Either way, the key is to tie architecture to outcomes. That’s how you earn trust—and influence what gets prioritized next.

---

Trade-Offs Are Inevitable

Every architectural characteristic comes at a cost. If you want ultra-high availability—say 99.99%—three availability zones likely won’t suffice. You’ll need:

• Two regions

• Load balancing between them

• Cross-region data sync

• And maybe even a disaster recovery setup

All of that adds complexity and expense.

That’s the architect’s job: to understand which characteristics matter most—and to propose solutions that meet them without breaking the budget.

---

How Characteristics Are Formed

So what determines how a system handles different architectural characteristics?

It’s a combination of two things:

1. The inherent characteristics of the individual elements – for example, the SLA of a single EC2 instance, how much load a database replica can handle, or how fast a queue processes messages.

2. The structure and relationships between those elements – how they are connected, distributed, and orchestrated.

Let’s take availability as an example. Spreading EC2 instances across three availability zones improves fault tolerance. But that’s not enough. You need a load balancer to route traffic, and that load balancer has its own availability limits, latency behavior, and cost. In this case, the overall system’s availability isn’t defined by any single component, but by how its individual characteristics combine and interact.

This is the essence of architecture: aligning component capabilities with system structure to meet a desired level of behavior.

The structure you choose becomes your architecture. And those foundational structures already have names—they're known as architecture styles, like:

• Layered or Modular Monolith vs Microservices

• Event-driven vs Orchestration-driven

Each of these styles has well-documented trade-offs. They shape how characteristics emerge at the system level, based on how the parts function and how they interact with one another.

I’ll dig into those styles and their implications in upcoming posts.

---

How Characteristics Are Measured

Once we understand what characteristics are and how they are formed, the next question is: how do we measure them?

Each characteristic can be measured using specific metrics, usually tied to the system’s behavior over time. For example:

• Performance can be measured using response time, throughput, or latency benchmarks.

• Availability is typically monitored as uptime percentage over a defined period (e.g., 99.9% monthly availability).

• Scalability can be evaluated by load tests and resource usage patterns under increasing demand.

• Security may include incident rate, vulnerability counts, and audit trail completeness.

• Cost can be tracked using both direct infrastructure spend and indirect indicators like engineer hours for manual maintenance.

What’s important is that these measurements are not theoretical. They must be monitored continuously through tools like:

• APM (Application Performance Monitoring) tools (e.g., Datadog, New Relic, Dynatrace)

• Cloud metrics dashboards (AWS CloudWatch, Azure Monitor, GCP Operations Suite)

• Custom dashboards integrated into delivery pipelines

You define these metrics early and review them regularly. If you're not monitoring it, you're not really designing for it.

---

Wrapping Up

Most people don’t care about architectural characteristics—until something cracks. But by then, fixing the cracks is often too expensive.

Our job as architects is to make sure things don’t fall apart. Or at the very least, make sure everyone understands what the consequences of today’s decisions might be tomorrow.

In the following articles, I’ll walk through common architectural styles and how they map to different characteristics and trade-offs.

That’s it for today. If you found this useful, leave a comment or subscribe so you don’t miss the next one.

See ya!

Want to learn more?

🎓 Check out the course: Modeling, Viewpoints, C4
🌐 Follow us on LinkedIn: Software Architecture Guild
📖 Explore the Free Guide: Jump to Website