By Stuart Dee
Recently, the technology world has seen a clear resurgence in discussions around the power of the manifesto. We constantly debate the Agile Manifesto, whether it is still relevant, whether it is “dead”, or how its principles should evolve. This cultural energy has naturally spilled over into the Enterprise Architecture (EA) community, where calls for a similar, guiding EA manifesto are now common. You see numerous discussions floating around with eloquent principles and high-minded statements. But they all seem to lack one critical thing: the pragmatic and practical background to back them up.
The Problem with Manifestos
The truth is, while manifestos provide essential cultural inspiration, they are also prone to fundamental issues that render them ineffective in the trenches of daily work. The greatest paradox is that their power lies in their brevity, but their failure lies in their lack of context.
A manifesto, by design, champions an ideal. But in doing so, it often becomes a collection of high-level philosophical statements written by thought leaders removed from the gritty reality of project delivery. They create beautiful aspirations, like “Customer collaboration over contract negotiation”, but offer no pragmatic guidance for the architect tasked with choosing between a high-cost, high-compliance system and a quick, low-cost solution the business wants now.
Take one of the Agile Manifesto’s most celebrated principles: “Working software over comprehensive documentation.” On the surface, this sounds liberating, a rallying cry against bureaucratic overhead. But in practice, it has become a justification for chaos. Teams skip essential documentation entirely, leaving future maintainers to reverse-engineer systems from code alone. Security teams find themselves without threat models. Compliance officers scramble during audits. The principle was never meant to eliminate documentation; it was meant to prioritise delivering value. Yet without context, without the nuanced understanding of when and how much documentation is needed, the principle gets weaponised by those who simply do not want to write anything down.
This is the trap of brevity without context. “Working software over comprehensive documentation” becomes “no documentation ever.” “Responding to change over following a plan” becomes “no planning at all.” “Individuals and interactions over processes and tools” becomes an excuse to reject any structure whatsoever, even when structure would help.
This idealism quickly breeds dogmatism. Principles turn into rigid rules, and the spirit of the document is lost to the letter of the law. Instead of a guide, it becomes a measuring stick for judgement, contributing to the very bureaucratic friction architects are meant to alleviate. When a manifesto lacks the practical background, the ‘why’ rooted in real failure and success stories, it is just a set of ideals that wilts under the pressure of trade-offs and political realities.
The Agile Manifesto’s authors understood nuance. They knew that comprehensive documentation does have value, just not more value than working software. But that subtlety evaporates in transmission. What remains are commandments stripped of wisdom, principles without the experience that gave them meaning.
Beyond the Technical
The simple truth is that whilst many architects can define an architecture framework, few can effectively navigate the political landscape, manage crippling trade-offs, or articulate the business value of their decisions to a non-technical executive. The soft skills are what never get taught in certifications but can make or break careers.
Architecture is not just about technology. It encompasses strategic engagement, communication, risk management, and stakeholder management. This is the gap that most manifestos fail to address.
You can design the most elegant system imaginable, but if you cannot explain its value to the CFO, navigate the territorial disputes between departments, or build consensus amongst stakeholders with competing priorities, that design will remain theoretical. The best architecture is the one that gets built, and getting something built requires mastering the art of influence, the empathy to understand different stakeholder concerns, and the clarity to communicate your vision for impact.
These human elements matter far more than most technical decisions. Yet they receive barely a mention in manifesto-style documents, which tend to focus on abstract principles about technology and process whilst ignoring the messy reality of organisational dynamics.
What’s Missing: Context, Nuance, and the Messy Middle
What architects need is not another set of aspirational principles. What we need is guidance for the messy middle, the space between the ideal and the real, where trade-offs are unavoidable and perfect solutions do not exist.
We need frameworks that acknowledge that sometimes you do need comprehensive documentation, that sometimes following a plan is exactly what will save your project, that sometimes the right process or tool is more valuable than another meeting. We need principles grounded in lived experience, backed by real stories of failure and success that illuminate not just what to do, but when, why, and how.
This requires moving beyond the brevity that makes manifestos memorable and into the depth that makes them useful. It means accepting that complexity cannot always be reduced to soundbites, that context matters more than catchphrases, and that the wisdom of experience cannot be distilled into a handful of value statements.
The reality is that architecture work lives in the grey areas. It exists in the compromises between what is technically ideal and what is politically feasible. It thrives in the space where you must balance competing concerns from different stakeholders, each with legitimate needs. It succeeds when you can translate technical concepts into business language that resonates with decision-makers who control the budget.
None of this nuance survives the compression into manifesto format. The result is that architects are left with inspirational quotes but no roadmap for the actual work.
Stuart Dee is a seasoned Enterprise Architect and technology strategist with over two decades of experience leading digital transformation initiatives across global organisations. As a regular contributor to Architecture and Governance Magazine and QCguy, Stuart shares thought leadership on enterprise architecture frameworks, IT governance, and strategic technology execution. His publications reflect a deep commitment to advancing architecture excellence and aligning technology with business strategy. Stuart is an active member of professional communities, engaging with peers and industry leaders to promote best practices in organisational change and architectural innovation.