An Architect's Work is Never Done
Guiding the Evolution
Part of the From Patterns to Practice series
Introduction: The End of the Beginning
Congratulations. If you’ve followed this series, you’ve guided your team through a rigorous, data-informed process and chosen a foundational architectural style for CityPulse. You did the hard work of analysis and trade-offs. You made the big decision.
Now for the really hard part.
This post is the epilogue to our foundational series on decision-making, but it’s the prologue to the rest of your life as an architect. The biggest mistake a new architect can make is thinking their job ends when the decision is made. In reality, it has just begun. Your job now shifts from deciding the architecture to stewarding it as it moves from a diagram on a whiteboard to a living, breathing system in the real world.
The Epilogue: CityPulse, One Year Later
Let’s jump forward in time. It’s been a year since you chose an Event-Driven Architecture for CityPulse. The launch was a success—the system handled the big concert sales without breaking a sweat, and your company is growing fast. But your work is not over. New, messier challenges are emerging that were never in your original decision matrix:
- The Unexpected Feature: The CEO, thrilled with the success, now wants to add a complex “live video streaming” feature for events. Does this fit the current architecture, or does it require a completely new approach?
- The New Team: A new marketing team has been hired to build a data analytics service. They’re experts in Python and want to use a NoSQL database, which is totally different from your project’s established standards.
- The Hidden Cost: The development team is finding it hard to debug certain cross-service workflows in your event-driven system. The shortcuts they took to meet the original deadline are starting to cause friction and slow down new feature development.
These are not signs of failure. They are signs of success. A growing, evolving business will always place new pressures on its architecture.
The Architect’s Ongoing Responsibilities
Your role now is to guide the system through these new challenges. Here are the new hats you have to wear:
Guiding Evolution (The Unexpected Feature)
Your architecture must be able to evolve. When a major new feature like live-streaming comes along, you run the same decision-making process again, but with a critical new constraint: the existing system. You use your original ADRs to understand the ‘why’ behind your initial choices and analyze the new requirement. Does it fit as a new event-driven service? Or is it a fundamentally different problem that requires its own, separate architectural style? Your job is to guide this evolution, making sure it’s a conscious choice, not an accident.
Architectural Governance (The New Team)
Your job isn’t to be the “architecture police” and say “no” to every new idea. It’s to establish lightweight architectural governance. You don’t dictate the new team’s database choice, but you work with them to define the principles they must adhere to. For CityPulse, a key principle is asynchronous communication. You might create a fitness function—an automated test that runs in your CI/CD pipeline—that verifies that their new service communicates via events and doesn’t create synchronous, temporal coupling with the rest of the system. This provides freedom within a guiding framework.
Managing Technical Debt (The Hidden Cost)
Those shortcuts your team took to meet the deadline? That’s technical debt. It’s not a moral failing; it was a strategic business decision—you took on that debt to get to market faster. Your job now is to manage it. You work with the product manager to make this debt visible. You quantify its cost—“every new feature in the ticketing service takes 20% longer because of this issue”—and you get a “repayment” plan on the product roadmap, just like any other feature.
Architect's Log
This is the part of the job that no one talks about enough. It’s a constant process of negotiation, education, and stewardship. You’re part diplomat, part city planner, and part portfolio manager. The technical decisions are often the easy part; guiding the people and the process is the real, long-term challenge.Key Takeaways:
- The architect’s job is not just to make the initial decision, but to steward the architecture over its entire lifecycle.
- Key ongoing responsibilities include guiding evolution, establishing lightweight governance (like fitness functions), and strategically managing technical debt.
- The same tools you used to make the decision (ADRs, C4, etc.) are the tools you’ll use to guide its evolution.
Welcome to Season Two
This post marks the end of our foundational series on making a single, critical architectural decision. You’ve followed the complete, repeatable framework from a vague problem to a documented, data-informed choice.
But the story of CityPulse is just getting started. These new challenges—evolving the architecture for a new business need, governing a growing system, and managing the debt from our past decisions—are the bread and butter of an architect’s daily life. In Season Two of this series, we’ll dive into these real-world challenges, exploring how to manage technical debt, how to evolve your architecture to support brand-new business features, and how to maintain your architectural principles across a growing team. Join us as the story of CityPulse continues.
Further Reading
- Building Evolutionary Architectures by Neal Ford, Rebecca Parsons, and Patrick Kua. The definitive guide to creating architectures that can adapt to change, and the origin of the “Architectural Fitness Function” concept.
- My take on technical debt: Bad Code is not Tech Debt. This post argues that not all bad code is technical debt and explores the nuances of this common misconception.
