Where Architecture Actually Happens
Ask anyone outside technology what a software architect does, and you’ll get remarkably similar answers: “They design systems.” “They make technical decisions.” “They draw diagrams.” Sometimes even the unflattering “They just draw boxes.”
Ask most people inside technology – developers, product managers, even executives – and you’ll get slightly more sophisticated versions of the same thing: “They create reference architectures.” “They set technical direction.” “They evaluate and choose technologies.” And sometimes the unflattering – ranging from “they’re just a rubber stamp for governance” to “I don’t know what architects really do.”
Depending on who you ask – all of this is technically true. And all of it misses the point entirely.
After 25 years in the industry growing from a developer to an architect – delivering transformations across mainframe migrations to cloud transformations, from regulatory implementations to merger integrations, digital transformations to entire platform rearchitectures – I can tell you what architecture actually is: it’s the unglamorous, often invisible work of navigating organizational reality so that good technical decisions can actually become working systems.
This is what I’m writing about in “The Architect’s Mundane” – not the architecture people imagine, but the architecture that actually happens – the messy middle. Welcome!
The Perception
There’s a common perception about what architects do, and on paper it sounds entirely reasonable.
Architects sit in design sessions with whiteboards, drawing elegant solutions to complex technical problems. They evaluate technologies objectively, choosing the best tools for the job based on technical merit. They create comprehensive documentation – architecture diagrams, decision records, reference models – that development teams follow to build systems. They define patterns and standards. They review designs to ensure quality and consistency. They think strategically about the long-term technical direction while developers focus tactically on implementation.
It’s what the job descriptions say. What the architecture frameworks describe. What certifications test. What the career ladder expects.
And there’s also the less flattering perception. Architects are seen as blockers. Friction points in the workflow. Hoops that project managers have to jump through. Hurdles that engineers need to clear before they can actually get on with delivery. The people who slow things down with reviews, governance, and “architectural concerns” that feel disconnected from shipping.
None of this is wrong. None of this is entirely right either. And all of it entirely misses the point of whether architecture really works.
Architects don’t operate in clean design sessions with unlimited budgets and perfect alignment. We operate in organizations with legacy technology that can’t simply be replaced. Budget constraints that dictate what gets built when. Competing stakeholder priorities. Timeline pressures. Sudden and urgent asks from senior management. The need to balance short term tactical delivery decisions while driving long term strategy. And the persistent gap between what the business says it wants and what it actually needs when you dig deeper.
The reality is architects find solutions that can actually get built, actually get shipped, and actually deliver value – despite all the constraints, politics, legacy, and organizational dynamics standing in the way. And then spend most of our time navigating the messy middle to make it happen.
This gap between perception and reality is why architects are so often misunderstood and underappreciated. We’re judged against two impossible standards – either the ideal (clean technical decisions, comprehensive documentation, elegant architectures) or the obstacle (the people slowing down delivery). But we’re operating in the real – organizational politics, budget battles, legacy constraints, competing priorities, filling skill gaps in other roles and functions, sometimes filling skill gaps within the architecture function, the drive to define a better strategy for the future – all under relentless delivery pressure.
Navigating this reality is the job – just not the job that everyone expects architects to do.
The Messy Middle
So what do architects actually do?
Architects create strategy where none exists. The business decides they need to “modernize” something – domain, customer experience, platform – but nobody’s defined what that means or why it’s happening beyond competitive pressure or executive mandate. The job is to envision a future state that’s technically sound, politically palatable, and actually achievable with the budget and timeline that will inevitably be given.
Then architects need to sell that future. Because without executive buy-in, funding, and priority, brilliant strategy is just another set of slides that nobody implements. Building the case, understanding stakeholder perspectives and creating different narratives for different stakeholders, explaining why this matters.
Architects are creating roadmaps and driving sequencing decisions. Which capabilities get built first? What can wait? What dependencies will derail delivery if the order is wrong? Influencing stakeholder thinking – explaining why their tactical approach won’t work, why their timeline is unrealistic, why infrastructure needs to come before features. Driving key decisions across organizational boundaries, navigating competing political agendas from different parts of the business, and finding solutions that serve multiple stakeholders while serving none of them perfectly.
All of this happens while people are running in different directions. Teams make tactical decisions because they can’t wait for strategy. Solutions get defined without architects because someone needed to move fast. Project managers and business stakeholders act as proxy solution architects, convinced they know the technical approach better, and architects are managing their expectations while trying to pull back, slow down, block and introduce necessary friction – all the while trying to define the right architecture and sequence the right slices for delivery meeting the immediate business needs. The challenge isn’t just defining the right architecture – it’s getting everyone moving in roughly the same direction despite their competing priorities and timelines.
And then there’s the magic architects are expected to create from nothing. One-liner requirements: “We need real-time fraud detection.” No detailed business process flows. No articulation of how the finance product is supposed to work. No definition of what “real-time” even means. Every business now want AI in everything but can rarely articulate what use cases or what problems really need solving. Architects are expected to define a technical solution anyway – hunting down stakeholders, extracting requirements they didn’t know they had, and building a coherent picture from fragments.
Meanwhile, the organization keeps changing. Stakeholders move. Priorities shift. The team that was counted on gets reassigned. The executive sponsor who championed the work just left for another company. Constantly rebuilding relationships, re-selling the strategy, and adjusting plans to fit new realities.
Through all of this chaos, architects are the technology stewards. While everyone else is focused on their immediate needs and tactical wins, architects are the ones responsible for the integrity of the estate. Pushing back on decisions that solve today’s problem but create tomorrow’s crisis. Managing technical debt. Ensuring today decisions don’t push the organization into architectural corners. Future-proofing while being told they’re overthinking it, they’re being too slow or are building golden Ferraris. Protecting the long-term health of the technology landscape while surrounded by swirls of distracting agendas, competing priorities, and relentless pressure to just ship something now.
And all of this happens under timeline pressure the business won’t negotiate, with capacity pressure because there are never enough architects, while building capacity within teams because junior architects need mentoring and upskilling, and fighting to get more capacity because every function is competing for the same scarce budget and headcount.
Oh, and one more thing: architects need buy-in from parties who have no accountability for the solution or for the delivery or for the technology direction. The security team who can veto but not build. The operations team who will inherit what gets created but weren’t consulted during design. The audit and compliance teams who will judge the work against standards that didn’t exist when it started. Getting their buy-in isn’t optional – without it, nothing ships.
This is the messy middle.
It’s not the clean work of designing elegant solutions. It’s navigating organizational reality so that good technical decisions can actually become working systems. Creating clarity from ambiguity. Building alignment across competing agendas. Making pragmatic tradeoffs under pressure. Sequencing work so teams can build incrementally. Stewarding technology for the long term while everyone else optimizes for the short term. Fighting for resources. Managing constant change. And somehow, despite all of this, shipping transformations that actually work.
The frameworks don’t teach this. The certifications don’t test it. The job descriptions don’t mention it.
But this is where architecture actually happens.
Welcome to The Architect’s Mundane
This is why I’m writing this newsletter.
The everyday reality of doing this work – the organizational dynamics, technical decisions, leadership challenges, and mundane choices that compound into major outcomes – deserve honest reflection, not polished case studies that sanitize the complexity.
In future editions, I’ll explore what I’m actually seeing, learning, and wrestling with. The organizational navigation and political realities of shipping architecture. Domain-driven design and event-driven systems – not the theory, but the practice. AI adoption beyond the hype. Leadership challenges of building and mentoring teams. Strategic thinking about technology stewardship. The gap between architecture frameworks and actual execution. Reflections on transformations, observations about the industry, lessons from the work.
Some editions will be frustrations. Some will be aha moments. Some will simply be learnings. All will be honest reflections on the everyday mundane work of architecture, leadership, and execution.
I’ll endeavor to publish weekly on Friday evenings. Not polished advice or prescriptive frameworks – just what I’m actually seeing, learning, and wrestling with. I don’t have all the answers. I’m just reflecting on 25 years of navigating this work and curious to hear your experiences too.
Welcome to The Architect’s Mundane.
