You already know the six pillars (subchapter 27.1) and the tool to evaluate yourself (subchapter 27.2). But the Well-Architected Framework only brings value if you truly apply it in your day-to-day work, not if you leave it as a document that gets reviewed once and then forgotten. In this subchapter, which closes Chapter 27, we’ll see how to integrate the framework in practice so it continuously improves your architectures.

The biggest mistake with the Well-Architected Framework is treating it as a box to check: you do a review once (maybe because someone asked for it), generate a report, and file it away forever. That’s not very useful, because:

• Architectures constantly change (you add features, grow, modify things).
• What was fine a year ago may no longer be fine (more users, new threats...).
• An improvement that is not implemented doesn’t improve anything.

The framework is valuable when it becomes a continuous practice, part of how you work, not an isolated task.

Analogy: applying the framework is like taking care of your health. Getting a medical checkup once in your life and forgetting about it won’t keep you healthy. What works is regular checkups + continuous healthy habits: regular checkups to detect problems in time, and good habits in your daily life. It’s the same with architecture: regular reviews (the tool) plus good practices incorporated into your way of working.

Apply the principles from the design phase, not when the system is already built. It’s much cheaper and easier to build well from the start than to fix things later. When you’re about to design something, review the six pillars as a guide for the questions you should ask yourself (how do I secure it? what happens if it fails? how much will it cost?...).

Schedule regular reviews (with the Well-Architected Tool, subchapter 27.2): for example, every so often or after major changes. This way you detect how your architecture has evolved and what new risks have appeared. A periodic review maintains quality over time.

A review may reveal many possible improvements. Don’t try to do them all at once (it’s overwhelming and unrealistic). Prioritize: tackle the high risks first (the most serious), and progressively improve the others. Remember the balance between pillars (subchapter 27.1): decide what matters most for your case.

The most powerful thing is for thinking about the six pillars to become part of how the team works, just as we saw with FinOps for costs (subchapter 25.5). When designing anything, the team should naturally ask about security, reliability, cost, etc. It’s not the responsibility of one person or a single review: it’s a shared mindset.

Don’t chase the “perfect” architecture (it doesn’t exist, remember the balance between pillars). Aim for continuous improvement: always being a little better than before. Every review that reduces a high risk is a win. It’s a journey, not a destination.

When applied well, the framework creates a cycle that improves your systems over time:

Each cycle leaves your architecture a little better: more secure, more reliable, more efficient.

Real-world example: a team decides to integrate the Well-Architected Framework into their way of working. They adopt three habits: (1) every new project starts with a review of the six pillars in the design phase; (2) they do a review with the tool every quarter and after every major change; (3) in each review, they tackle high risks first and record their progress. After a year, their systems are noticeably more robust and secure, and—most importantly—the team naturally thinks in these dimensions when designing. The framework stopped being a document and became their way of working. That’s the difference between knowing it and applying it.

• The biggest mistake is treating the framework as a one-time task; its value lies in applying it continuously. Like taking care of your health: regular checkups + continuous habits, not a single checkup.
• Keys to really applying it:
  • Start early (from the design phase), not at the end: building it right the first time is cheaper than rebuilding.
  • Make it periodic (regular reviews with the tool), not one-off: architectures evolve.
  • Prioritize risks (high first), don’t try to fix everything at once.
  • Make it part of team culture (a shared mindset, like FinOps), not just one person’s responsibility.
  • Aim for continuous improvement, not perfection (there’s no perfect architecture, only the one that fits your priorities).
• Applied this way, it creates a virtuous cycle (design → build → review → improve) that leaves your systems better with each cycle.

You’ve completed Chapter 27! You now know how to evaluate and improve architectures with the Well-Architected Framework. In Chapter 28 we’ll look at concrete and advanced architectures: serverless architectures at scale, where you’ll apply many of these principles to real designs.