In Conversation with Simon Stone and Simon Barrows: Adventures in Architecture as Code
What happens when architecture stops being static documentation and starts becoming living, structured data?
Ahead of the Enterprise & Business Architecture Conference Europe 2026, we spoke with Simon Stone and Simon Barrows about the growing shift towards Architecture as Code, and why advances in AI are making it more achievable than ever before.
Q1. Your session focuses on Architecture as Code. Why is this approach becoming more relevant now, and what is driving its adoption?
Architecture-as-Diagrams has always carried fundamental weaknesses: subjectivity, imprecision, opacity, and disconnection from delivery, and the impact of these shortcomings grows as organisations operate at greater scale and speed. Architecture as Code isn’t a new concept: what has changed is the growth in AI capability, which now enables the extraction, standardisation, and joining of architecture data from multiple fragmented sources at a scale that was simply not feasible before. The combination of mounting urgency and a genuine new technical enabler means there has never been a better moment to embrace Architecture as Code.
Q2. Many organisations still rely on static diagrams. What are the key limitations of this approach, and how does Architecture as Code address them?
Static diagrams are inherently subjective: they reflect the perspective, bias and assumptions of their author, and this is magnified due to their interpretive consumption by readers. Furthermore, they drift from reality the moment they are created, because they cannot be automatically updated as systems evolve. Depending on the EA tooling in use, it’s likely that they will also lock architecture knowledge inside proprietary vendor tools, making it difficult to access for programmatic interrogation or to integrate with engineering pipelines.
Architecture as Code addresses each of these: all assets are expressed as version-controlled data with assertable tests that enforce consistency; diagrams are generated on demand from the live data model rather than maintained manually; and the architecture is fully transparent: i.e. the codified data is accessible by any consumer, whether human or agent.
Q3. Architecture as Code treats architecture as structured, version-controlled data. How does this change the role of the architect in practice?
The most immediate practical change is that architects need to be comfortable operating as an engineer, as well as a strategist: the operating practices and tooling associated with codified architecture are closely aligned with software development. The architect shifts from being a maker of diagrams to a steward of architecture data, ensuring both its quality and completeness, rather than producing static deliverables. This doesn’t mean that standard architecture skills are jettisoned: rather, they are manifested in different ways.
Whilst this is a change that some may not find easy, there are significant efficiency gains, whether it be for enterprise architects, domain architects, or solution architects. For example, automated diagramming from curated architecture data can reclaim weeks of effort previously spent building, updating, and aggregating diagrams. Governance shifts to a management-by-exception model, where automated tests handle routine design validation, and human review is reserved for the decisions that genuinely need expert input.
Q4. You highlight the importance of architecture data. What are the biggest challenges organisations face in getting this right?
The single largest challenge is the scale of the codification of legacy architecture “knowledge”. Large organisations will have accumulated a morass of fragmented, heterogeneous, and inconsistent documents and diagrams that must be converted into a single, referentially linked, coherent dataset of guaranteed quality. The practical complexity is compounded by the variety of data sources involved: APIs, spreadsheets, bespoke databases – linking them together requires good metadata on both sides, and AI can only help where that metadata exists. Critically, Architecture as Code cannot be a siloed initiative; it requires full organisational adoption, and attempting to build everything in one go is rarely worthwhile: an iterative, use-case-driven approach is essential.
Q5. How does Architecture as Code help improve alignment between business strategy, engineering and operations?
Enterprise architecture research consistently identifies alignment between IT systems, business processes, and technology investments as a primary driver of EA value; Architecture as Code provides the data foundation that makes that alignment transparent, auditable, and continuously maintained rather than periodically refreshed.
In general terms, a codified, interrogable architecture model makes it possible to assess the impact of strategic choices: one can ask arbitrary “what if” questions about technology or operating model changes. For example, architecture data enables costs and risk to be traced directly from the implementing applications and technologies to the business capabilities they serve, so technology investment decisions are grounded in empirical data rather than estimation.
On the engineering and operations side, Architecture as Code enables direct integration with delivery pipelines: codified architecture outputs can feed straight into the SDLC, removing ambiguity at the handover point and reducing delivery handover time.
Q6. AI is playing an increasing role in architecture. Where do you see it adding the most value within an Architecture as Code approach?
AI adds value in the data pipeline — extracting, standardising, and joining architecture data from mixed, heterogeneous sources at a scale no human team could achieve manually, provided that good metadata exists (in both datasets, where referential linking is to be done). Once the architecture is codified, AI enables natural language querying against the repository, making architecture insight accessible to non-specialist stakeholders for the first time and improving decision accuracy by replacing guesswork with empirical interrogation. At the governance layer, AI supports automated design validation and current-state analysis, shifting architects to a management-by-exception model where human review is reserved for genuinely complex decisions.
Q7. For organisations just starting out, what are the first practical steps they can take to begin adopting this approach?
The recommended starting point is a scoping exercise to identify which architecture use cases would deliver the highest return on the codification effort: what are the problems that need to be fixed? This will specify which data sources to prioritise, as well as what ‘good’ looks like for the organisation. A hands-on workshop follows, working directly against the organisation’s own architecture scenarios to establish credibility and build a realistic roadmap for iterative delivery. Avoid attempting to codify everything all at once: start with the most relevant data sources and a use case that will demonstrate early delivery of genuine value, then expand from there.
Simon Stone and Dr Simon Barrows will explore these ideas and practical examples further during their session, Adventures in Architecture as Code, at the Enterprise & Business Architecture Conference Europe 2026 in London this June.
Their session will examine the key building blocks of a modern Architecture as Code approach, the role of AI in architecture data management, and the practical realities of moving from static diagrams to continuously evolving architecture models.
If you are interested in enterprise architecture, AI-enabled governance, architecture data, or improving alignment between business strategy and technology delivery, this is a session not to miss.
📅 View the agenda:
https://irmuk-architecture-change-design.eventsair.site/
🎟 Secure your place:
https://irmuk.co.uk/tickets-eba-bct-sd-2026/
