I’ve been writing about architecture since 2018, back when it felt like a losing argument. The industry was moving toward speed, autonomy, and “just ship it.” Granted: microservices, serverless, and teams owning everything was exciting and architecture reviews were seen as bottlenecks, architects as relics of a waterfall era. If you talked about intentional design in certain circles, you could feel the eye rolls. Emerging architecture or bust.
Funny how that works. Six years and a few trillion parameters later, organizations are rediscovering that complex systems need someone thinking about how the pieces fit together. Distributed architectures, AI pipelines, multi-cloud environments, data platforms… the surface area of technical decisions has grown enormously, and the consequences of getting them wrong have grown with it.
So architecture is having a moment. Not because the idea is new, but because enough things broke.
What Broke
The last several years gave us a natural experiment in what happens when you optimize for speed and autonomy without a corresponding investment in structural thinking.
Cloud migration moved fast, and many organizations ended up with sprawling, poorly governed environments that made it difficult to track what was running or what it cost. Platform engineering helped, but even well-designed platforms leave the application and data architecture layers a free-for-all zone in most organizations.
AI made it worse. Or rather, AI made the existing problems visible in new ways. When a team builds an AI feature, they’re making decisions about data pipelines, model serving, integration patterns, security boundaries, and evaluation frameworks. Those decisions interact with each other and with the rest of the system in ways that aren’t obvious at the team level. A model that works in isolation can create downstream chaos when it’s connected to production data flows that were designed with different assumptions.
One healthcare services client spent four months building an AI-powered patient intake triage capability. The model performed well in testing. When they connected it to their actual clinical systems, it surfaced a problem nobody had anticipated: the patient data flowing into the model came from their EHR, a claims processing system, and a separate eligibility database, each updated on different schedules. The model treated them all as current. A patient could show as eligible in one system and terminated in another, and the model had no way to know which was right. The architecture of the data pipeline was technically correct but semantically wrong. No individual team had made a mistake. The mistake was that nobody had looked at the whole picture.
This kind of problem doesn’t get caught in a sprint review, you need someone whose job is to think across boundaries.
The Architect Rehabilitation
For a while, “architect” was almost a dirty word in agile circles. It conjured images of ivory tower designers producing PowerPoint blueprints disconnected from the reality of what teams were building. And to be sure, some of that reputation was earned. There were plenty of architecture practices that operated exactly that way, producing frameworks and reference models that nobody used because they were too abstract to be useful and too rigid to accommodate reality.
But. as it tends to do, the pendulum swung too far. In the rush to empower teams, some organizations eliminated meaningful architectural oversight entirely. Every team could choose their own database, their own messaging pattern, their own approach to handling failures. This worked when systems were relatively self-contained. It falls apart when those systems need to talk to each other, share data, and behave consistently under load.
Thankfully, the rehabilitation of the architecture role is different from the old ivory tower model. In the best cases, architects work across teams, identifying patterns and dependencies that are invisible at the team level. They make decisions about shared concerns like data flow, security boundaries, and integration contracts so that individual teams don’t have to reinvent those decisions independently. It comes back to the idea of intentional architecture over purely emerging architecture. We’re better off with enough architecture runway with forward thinking to prevent teams from building themselves into corners, without so much upfront design that you lose the ability to respond to change.
The AI Architecture Challenge
AI systems present a particular challenge because they blur boundaries that traditional architecture took for granted.
Applications, or even microservices, have relatively clear inputs and outputs. You know what data it reads, what data it writes, and what the expected behavior is. An AI system operates on probabilities, produces non-deterministic outputs, and often depends on data that changes continuously. The architecture has to account for things like model versioning, data drift, evaluation pipelines, and fallback behavior when the model is wrong. They force early decisions, because retrofitting them later is painful and expensive.
Most organizations haven’t figured out where AI architecture decisions should live. The data team understands the data. The ML engineers understand the models. The application teams understand the integration. But the architectural decisions span all three, and somebody needs to own the view across them. This is the same jurisdictional problem we saw with cloud adoption, and the organizations that solve it tend to be the ones that put someone in charge of the seams between teams.
One client addressed this by creating an “AI architecture guild,” a small group of senior engineers who reviewed every AI initiative for architectural coherence. They looked at data lineage, model lifecycle, integration patterns, and failure modes. Their mandate was narrow and specific: make sure the pieces fit together. The team added about two weeks to the start of each initiative, and the consensus after six months was that it saved them months of rework downstream. That’s a pretty pragmatic and low-friction approach to solve the problem.
Full Circle
The lesson, which shouldn’t need relearning but apparently does, is that complex systems require intentional design. Speed and autonomy are valuable, but they work best within a structure that keeps the overall system coherent. The teams that build the pieces need freedom. Someone still needs to care about how the pieces fit.
I wrote about creative plumbing in the past… the plumbing got a lot more creative.
