How the Fall of Agile and the Rise of AI Are Reinstating the Most Important Role in Technology – The architecture profession has been in structural decline for fifteen years.
The Making of a Profession
I founded IASA Global more than twenty years ago because I had a problem I could not explain to anyone outside of architecture. The people doing the best work, the ones who actually delivered systems that held together under pressure, that scaled, that satisfied both the business and the technology teams, were not just good developers. They were not just good business analysts. They were something else. Something harder to name and much harder to grow.
We did thousands of surveys in those early years. We interviewed practitioners across industries, continents, and specializations. The pattern that emerged was consistent and, at the time, counterintuitive. Successful architects were part engineer, part business thinker, part human dynamics expert. Not sequentially. Simultaneously. The best of them could move from a conversation about return on investment with a CFO to a decision record on data partitioning with a development team and back again, in the same afternoon, without losing the thread of either.
That discovery became the foundation of the Business Technology Architecture Body of Knowledge (BTABoK), the only open-source body of knowledge built for all architects by practicing architects. It also became the basis of board certification through IASA, the CITA program, which remains one of the few architecture credentials that actually measures competency across all five of its pillars: business technology strategy, design, quality attributes, human dynamics, and IT environment.
Those five pillars emerged from evidence. The BTABoK skills inventory was assembled from the observed behaviors of people who were demonstrably excellent at the work. And the work was brutally demanding. Technology people generally do not want to learn business skills. Business people do not generally want to understand systems design at depth. People who genuinely bridge both are rare, take years to develop, and are costly to retain. This is why, for most of the early 2000s, the highly skilled architect was the most sought-after role in the technology marketplace. There were never enough of them.
The Decomposition
Then something shifted. Over roughly fifteen years, a combination of Agile adoption, cloud commoditization, and enterprise restructuring changed how organizations thought about delivery. The shift was not presented as a reduction in architecture capability. It was presented as a maturation of delivery. The argument was that if you structured the delivery team correctly, you could distribute architectural thinking across roles without needing someone who held all of it.
The result was the “three in a box” model and its many variations. One person represented the business need. One person held the deep technical implementation. One person managed the schedule and the change lifecycle. In the language of the moment, that was the product owner, the tech lead, and the scrum master or change lead. The architect, in this model, was a redundancy. An expensive generalist in a world that had discovered the efficiency of specialists.
To be fair, the model had a logic to it. For greenfield product development in organizations with stable business models and manageable technical complexity, it worked tolerably well. For a period. But there were costs being accumulated that were not showing up on any sprint velocity chart.
The product owner represented business need but rarely had the technical depth to make sound architectural tradeoffs. The tech lead held technical depth but often lacked the business context to understand which tradeoffs actually mattered to the organization. The change lead managed the lifecycle but had neither the business nor the technical authority to resolve the fundamental tensions between the other two. Each role was genuinely valuable. None of them was an architect. And in combination, they did not add up to one.
What disappeared in this restructuring was not a title. What disappeared was cross-domain judgment. The capacity to hold business outcomes, technical constraints, quality attributes, stakeholder dynamics, and long-term system health in a single coherent view, and to make decisions from that view. The BTABoK engagement modelhas described this capacity for years. We called it architecture decision-making. The market called it unnecessary. The market was wrong.
The Engineering That Was Not Engineering
A parallel shift occurred in how senior developers described themselves. As the architect role was decomposed and distributed, good developers began calling themselves engineers. The language was appealing. Engineering implies rigor, accountability, and professional standing. It implies an agreed body of practice and a measurable standard of competence. The problem is that in software, none of those implications have been formalized.
To be clear: I have enormous respect for the developers who do this work. I was one of them. The craft is genuinely difficult and the best practitioners are exceptional. But craft and engineering are not the same thing. No shared engineering credentialing system has emerged that distinguishes a senior developer from a software engineer in any way that is independent of employer preference. No professional body governs the title. No licensing body enforces its use. A developer who calls themselves a software engineer and a developer who does not are, in terms of any external accountability, indistinguishable.
This matters because the title “engineer” carries social weight that the title “developer” does not. It suggests a level of professional responsibility and independent judgment that most hiring organizations and most governments have accepted without requiring any evidence that the underlying competency exists. The BTABoK career pathway represents a more honest approach: measured competency at each level, independent of employer, verifiable by a professional body, and continuous across a career.
The Fall of Agile
Agile has lost significant momentum. This is not a controversial observation. It is a widely reported one, visible in the decline of Agile transformation programs, the contraction of the Agile consulting market, and an increasingly open conversation in the practitioner community about what Agile actually delivered against its original promise.
The lifecycle article I wrote earlier, Lifecycles Within Lifecycles, touches on this directly. The problem with Agile was never the original insight, which was genuinely valuable. Iterative development, close feedback loops, working software over documentation, these were real improvements over the waterfall pathologies they replaced. The problem was the institutionalization. Someone gave it religion. Turned a delivery lifecycle technique into a capital-A organizational belief system. And when something becomes a belief system, it becomes resistant to the evidence that contradicts it.
The evidence, accumulated over fifteen years, is substantial. Agile works well for certain kinds of problems: product development in mature domains, feature delivery in stable systems, incremental improvement in understood problem spaces. It works poorly for other kinds of problems: large-scale system integration, enterprise transformation, socially complex stakeholder environments, systems with serious quality attribute requirements, and any domain where the cost of getting it wrong is not recoverable in the next sprint.
More precisely, Agile, as practiced in most large organizations, treated architecture as a tax. A slowdown. A thing that governance people imposed on delivery teams who were trying to move fast. The consequences of that treatment are now accumulating in ways that are difficult to ignore. Technical debt has compounded to the point where many organizations cannot safely change the systems that run their businesses. The CrowdStrike outage of 2024 was a visible example of a much more widespread condition. Systems with kernel-level dependencies, no hardened deployment pipelines, no architectural accountability for quality attributes, because architecture was the thing that slowed you down.
The organizations that fared best through this period were not the ones that were most agile. They were the ones that maintained architectural discipline inside their agile delivery. That combination, disciplined architecture with iterative delivery, is precisely what the BTABoK describes as the architecture lifecycle. It is what many architects have argued for throughout this period, largely without success, because the narrative of agility was more commercially attractive than the narrative of rigor.
The Rise of AI Code Generation
At the same time that Agile is losing momentum, something else is happening that changes the market dynamics for technical professionals in ways we have not fully reckoned with. AI-driven code generation is advancing rapidly enough that the craftsperson model of software development, the model in which a skilled developer writes code line by line and the value of the individual is primarily their ability to produce working code, is under serious pressure.
I want to be precise about what I am claiming and what I am not. I am not claiming that developers will disappear. I am claiming that the value proposition of the developer who primarily crafts code, which is the majority of what the three-in-a-box model relies on from its tech lead, is being disrupted at a rate and scale that the market has not yet fully priced. This is changing the rhetoric and marketing around technical careers back to where it was pre-agile… architecture. Business context, cross-cutting engineering concerns (quality attributes) and deep long-term experience are becoming more discussed and more popular.
What AI code generation cannot do is decide what to build. It cannot weigh a business outcome against a quality attribute constraint and determine which tradeoff is acceptable given the organization’s risk appetite, technical debt profile, regulatory environment, and long-term strategy. It cannot hold a facilitated session with a CTO, a product director, and an infrastructure lead and emerge with an architecturally significant requirement that all three parties understand and agree to. It cannot produce an Architecture Decision Record that reflects genuine cross-domain judgment and will hold up under the scrutiny of a post-incident review.
These are architect competencies. They are precisely the competencies that were declared optional in the three-in-a-box model. They are precisely the competencies that the BTABoK skills inventory has measured and that CITA certification has validated for two decades. And they are precisely the capabilities that organizations are now discovering they cannot purchase from a code generation tool.
The Reinstatement
The architect is returning because the gap left by the decomposition is now painful enough to feel and the tools that were supposed to fill it are revealing their limits.
Consider what the current moment actually requires of a technology organization. AI tools are generating code at scale. That code has to fit into systems with real quality attribute requirements: performance, security, reliability, maintainability. Someone has to decide what to build before the AI builds it. Someone has to evaluate what was built against the criteria that matter. Someone has to own the decision record. Someone has to connect the technical choices to the business outcomes. Someone has to think about what this system looks like in five years and whether the choices being made today are recoverable.
That someone is the architect. Not the product owner, who is focused on the backlog. Not the tech lead, whose primary value is being disrupted by the same tools. Not the change lead, who is managing the delivery lifecycle. The architect. The one role in the delivery ecosystem that was specifically designed to hold all of these concerns simultaneously and make sound decisions across them.
The BTABoK competency model has described this role in detail for twenty years. The five pillars, business technology strategy, design, quality attributes, human dynamics, and IT environment, are not a wish list. They are a description of the cognitive and professional demands of the work. Every organization that is now discovering it needs architectural judgment is discovering the same five pillars, whether or not it is using that language.
For architects this means a switch back to building things. We have to come down from the lofty towers we erected and start realizing that delivery is the hardest part of strategy.
What This Means for the Profession
There are several things that follow from this analysis that I want to name directly, because they are not comfortable and they are not universally agreed upon even within the architecture community.
First, the scarcity of highly skilled architects has not gone away. It was temporarily masked by the decomposition model. It is now re-emerging. It takes between five to eight years to develop a board-certified professional-level architect under good conditions, and between eight and ten years to develop a distinguished architect. The BTABoK career pathway is explicit about this. There is no shortcut. There was no shortcut in 2002 and there is no shortcut in 2026. Organizations that want architectural capability need to start building it now, because they cannot hire their way to it quickly enough.
Second, the three-in-a-box model did not develop architects. It developed product owners, tech leads, and change leads. These are not bad roles. But the people in them have not been accumulating the cross-domain judgment that architects need. The development pipeline for the profession was effectively paused for fifteen years in many organizations. That pipeline needs to restart, and it needs to restart with a clear competency model, not with a vague expectation that senior developers will somehow develop business and human dynamics skills by proximity.
Third, the title problem must be resolved. Software engineer, solutions architect, principal engineer, staff engineer, distinguished engineer: these titles proliferate precisely because there is no external standard against which to measure them. The BTABoK and CITA certification exist to provide that standard. I will say what I have said for twenty years: a professional society that certifies competency independent of employer preference is not a nice-to-have for a mature profession. It is the definition of a mature profession. We are not there yet. We need to get there faster than we have been moving.
Fourth, AI code generation is an accelerant for architecture, not a replacement for it. The architect who understands how to direct AI tooling, how to evaluate its outputs against architectural criteria, how to structure the decision environment in which AI operates, and how to maintain the quality attribute profile of a system that is being built partly by machines, is more valuable than the architect who ignores these tools. The BTABoK will need to evolve to describe these capabilities explicitly. That work is underway.
Conclusion
Twenty years ago I believed that architecture was the most important role in technology. I was not able to prove it then to the satisfaction of many of the people I needed to convince. I believe I can prove it now, not through argument but through evidence.
The systems that were designed without architectural discipline are failing. The delivery models that declared architecture optional are being revisited. The market is discovering that code generation amplifies architectural decisions, good and bad, and that amplified bad decisions are very expensive. The roles that replaced the architect are proving insufficient on their own to the challenges that the next decade of technology will create.
The architect is not a historical artifact. The architect is the answer to a question that the technology industry keeps asking: who is responsible for the whole thing? Who holds the business outcome and the technical quality and the human dynamics and the long-term system health in a single coherent view, and who makes sound decisions from that view?
That is what architects do. It is what we have always done. It is what the BTABoK has described, measured, and certified for twenty years. And it is what the market, through the accumulated pressure of Agile fatigue and AI disruption, is now demanding again.
The architect is reborn. The question is whether the profession is ready to meet the moment.
References and Further Reading
• Preiss, P. — The No-IT Disaster (LinkedIn, 2024)
• Preiss, P. — Navigating a Socio-Technical Future (IASA, 2024)