Architecture and decision-making – cio.com

Over my 20+ years working in software architecture and engineering leadership, I have come to believe that architecture is far more than technology. It is in many ways a form of leadership. At the center of that leadership is the ability to make sound decisions in moments of uncertainty. High-quality decisions that balance what the design and team can do today with what the business will need tomorrow.
We often celebrate architectural knowledge, such as patterns, frameworks, abstractions and styles, all of which are essential. But in reality, the thing that separates good architects from great ones is not knowledge. It is judgment. Knowledge is essential; however, it is judgment that truly distinguishes outstanding architects.
I believe judgment was the quiet force behind every meaningful architectural decision that I’ve made. It has guided me to deal with uncertainty, to weigh trade-offs, to balance the ideal with the practical and to design for teams that are still growing into the systems when we are building. I’ve found knowledge helps one to understand what is possible and Judgment helps one to decide what is the right thing to do.
This idea is reinforced in many of the great books I’ve learned from, whether it’s The Hard Things About Hard Things by Ben Horowitz or Team of Teams by General Stanley McChrystal. These books talk about leading through uncertainty, making tough choices and guiding people through complexity. Interestingly, that’s also exactly what software architects do every day.
In this article, I will share what I’ve learned about how leadership, technology and product thinking come together to shape better decisions – and how I learned to navigate the messy reality of building software while keeping one eye on the horizon.
When I think about architecture, I don’t think about diagrams. I think about high-quality decisions. Architecture is ultimately about shaping systems that deliver value. You can create the most elegant system in the world, but if it doesn’t meet its delivery timelines or if it is too complex for the team to operate, or if it doesn’t actually solve the user’s problem, then it’s not good architecture.
My approach has always centred on building systems that achieve the right return on investment. ROI is not just about cost efficiency or saving money. Sometimes the best ROI comes from spending more upfront to create long-term leverage. Other times, ROI comes from choosing the simplest possible path to meet a pressing market deadline. The job of the architect is to weigh these forces not just theoretically but practically.
For me, architectural leadership is about helping teams navigate these decisions without getting trapped in the pursuit of perfection. It’s about understanding users, understanding business priorities and understanding the people who will build and operate the system. It requires the ability to communicate a vision, reduce uncertainty and guide teams through moments when we simply don’t have all the answers.
That’s why I say architecture leadership sits right at the intersection of three worlds: technology, product and people.
Uncertainty is something I’ve learned to live with as it’s a constant backdrop of architectural decision-making.  Rarely do I get perfect requirements. Rarely do I know exactly how a system will evolve or behave at scale. And yet, I still need to make decisions that feel concrete, meaningful and aligned with the future, even when the future is a bit blurry.
I often think about Napoleon’s line: “A leader is a dealer in hope.”  It’s a surprisingly accurate reflection of what software architects do. We bring clarity where things are messy. We can’t predict the future, but we must still articulate a path forward when ambiguity is high. And we do it not because we know everything, but because we can see just enough to guide the next few steps.
Some of the best leadership books I’ve read, like Richard Rumelt’s Good Strategy Bad Strategy and Schmidt’s Trillion Dollar Coach, prioritize judgment as a top leadership quality, one who can navigate ambiguity and make high-quality decisions based on gutsy judgment.  
Meanwhile, leading technical books from Martin Fowler and Bob Martin’s Clean Architecture prioritize knowledge and vocabulary to act on that judgment.
For me, the role of an architect is to operate in the space where these two worlds, knowledge and judgement, overlap.
Let me share a personal story that taught me the importance of architectural judgment more than any textbook ever could. It happened during a major data platform initiative that I was leading from the architecture front. We had a tight deadline, multiple data sources to onboard and a team that was still early in its journey with cloud-native data ingestion and distributed systems.
The long-term vision was clear in my head. We needed a generic ingestion framework built around an adapter pattern. In this model, each data source would plug into a common interface, giving us consistency, maintainability and the flexibility to evolve and scale over time. It was the right architecture for the future.
But the real question for me was it the right architecture for that moment?
In my view, the team was not yet ready to build such a framework. They needed real, hands-on experience with ingestion patterns, schema evolution, data quality issues and the messy operational challenges that only appear once real production traffic hits the system. If we pushed ahead prematurely, not only would we miss the deadline we would likely create abstractions that were elegant in theory but mismatched to reality.
So, it’s time for a pragmatic decision judgment call? Do we start with a managed ingestion service? Something reliable? Something we could operate easily? Something that delivered value quickly? It’s time for me to make a judgment call on whether to proceed with a cloud-native ingestion service or a generic ingestion framework. I decided to proceed with a cloud-native ingestion service. With this approach, it allowed us to ship on time, drastically reduce operational risk and gave the team space to build the foundational knowledge about large scale data ingestion service.
From the outside, the choice of proceeding with cloud-native data ingestion looked simple, maybe even ordinary. But internally, from a business perspective, it was a turning point. The team gained the confidence that comes from operating production data ingestion services. It allowed us to observe and learn what patterns we needed, what was working. What’s not working and more importantly, what patterns we don’t need. Of course, the big win was that we delivered business value immediately.
Fast forward to the following year. The team had grown. We had clear insights into performance bottlenecks, failure modes and necessary abstractions. With this experience, we revisited the long-term vision and built the generic ingestion framework we originally imagined. This time, the architecture almost designed itself. The adapter pattern made perfect sense, and the managed service became just one of the plug-in connectors behind the framework.
That decision started pragmatically, evolved strategically and remains one of the clearest examples of architectural judgment in my career. It was not just about technical correctness. It was about doing the right thing at the right time for the right reasons.
That experience reinforced something I firmly believe: Architecture is not about building the perfect system. It’s about making the right decisions based on the strengths that you have today from both a technical and a people perspective. While having a future state in mind, staying aligned with the future that will allow to evolve the architecture as you move toward.
Over the years, I’ve discovered that asking the right questions matters even more than trying to find the perfect answers. This idea is strongly reinforced by Srinath Perera in his work on software architecture and decision-making, where he points out that good questions force us to think, uncover details and reshape our understanding of the problem. I’ve always resonated with Srinath’s observation that questions ground us in concrete situations rather than abstract ideals because it’s often the pursuit of those ideals that leads projects into trouble. In my experience, these questions are not just diagnostic tools, they are catalysts for clarity. They help me scope a system, cut through noise and understand what truly matters in the moment.
The first question to consider is on timing. Timing is a decisive force in architecture. If you are racing to meet a product launch or capture a market opportunity, then simplicity and speed matter far more than creating the most elegant design. If you have more breathing room, can invest deeper in long-term foundations.
The second question is about team skill level. Architecture doesn’t live in PowerPoint. It lives in the hands of the engineers who build and operate the system. A design that is beyond the team’s current capability is not an architecture; it’s a liability. This doesn’t mean lowering standards it means aligning ambition with reality and growing the team along the way.
The third question is in relation to scaling and performance. Not every system needs millisecond latency or hyper-efficient throughput. But the ones that do require early architectural considerations. Misjudging this can turn into expensive rewrites or operational nightmares. Conversely, over-optimizing a system that doesn’t require it is wasted effort and cognitive load.
The fourth question is about future state architecture. Every architecture has a lifespan. If you expect to revisit the design in the near future, you can accept more shortcuts and tactical decisions. But if the system is expected to live for years, then foundational decisions like data models, domain boundaries and communication patterns will require greater care.
The final question is about hard architecture patterns or technology and how to address them early. Every system has one or two truly difficult challenges, whether it’s data consistency, security boundaries, real-time performance or scaling complexity. These hard problems should be tackled early, even if it means building prototypes or running parallel explorations. De-risking them can change the entire trajectory of the project.
These five questions help me to navigate uncertainty with clarity, while they echo many of the themes Srinath Perera outlines, particularly the idea that questions reshape our understanding; they’ve also evolved with my own experiences. They’ve become part of how I guide teams, evaluate trade-offs and build architectures that hold up in the real world.
Architecture is not the pursuit of perfection. It is the pursuit of appropriateness. Knowledge gives us options, but judgment helps us choose the right path for the moment we are in, the team we have and the product we are trying to build. The best architects bring together technology expertise, product intuition and leadership judgment into a single discipline.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
Kamal Sampathkumar is director of architecture at Workhuman, where he is responsible for leading data and governance function. He collaborates closely product and engineering teams to deliver scalable data solutions to internal users, enterprise customers and to power product analytics.

Previously, Kamal was a software architect at System Dynamics, a senior software engineer at both Connect Global Solutions and Mentec. His mission is to help organizations navigate complex technology and data challenges through strategy, architecture and engineering. Kamal specializes in modernizing platforms and delivering business impactful solutions with data, AI and cloud, driving organizations to innovate faster, scale globally and stay competitive.
Sponsored Links

source
This is a newsfeed from leading technology publications. No additional editorial review has been performed before posting.