Towards continuous, executable enterprise architecture: a conversation with William El Kaïm
Interview for Boldo.io, conducted by Sylvain Melchior
Sylvain : William, thank you for your time. Before we get into the substance, could you trace for our readers the path that led you to enterprise architecture?
William : My career began in research. My thesis dealt with generating code from models. I then turned to software product lines, whose main idea is not to build a single piece of software, but a family of products that share a common core. You model that core and its points of variation, then generate the product tailored to each client. It is the direct continuation of my thesis: the models drive the generation. I went on to hold consulting roles (eight years at BCG) and enterprise architecture roles (Carlson Wagonlit Travel, Dalkia, Sanofi). More recently, I spent a few months at SAP LeanIX as a product expert, and today I am an enterprise architecture director at Pernod Ricard. One thread runs through it all: for years I have watched closely the tools of our profession and followed their evolution. That is what led me to create the EA Codex.
Sylvain : So you have observed the discipline from research, from the field, and from the tooling side. From that vantage point, which challenges strike you as the most defining today?
William : The first challenge concerns the very role of the architect. It remains poorly defined, and it varies a great deal with the maturity and the size of the organisation. Depending on the company, the talk is of IT architects, business architects, or hybrid profiles able to bridge the two. The second challenge lies with architecture teams that have never set out their objectives clearly; having failed to state them, they neither review nor measure them. After three or four years, the criticism flows freely, yet no one holds the factual ground on which to debate it calmly. The third challenge stems from the explosion in the number of projects, often poorly aligned with the application landscape. Data has already complicated the picture, and artificial intelligence will soon add a new layer. The interlocutors multiply, and the discussions run at several levels at once, from the enterprise to the region down to the team. Coordination becomes all the more delicate. And you still need constantly up-to-date knowledge, since one cannot decide on the strength of a portfolio that is already out of date. That is the whole point of a digital twin: a view of the portfolio refreshed almost in real time, which spares you from reasoning several months behind.
Sylvain : We met, as it happens, around a benchmark of architecture tools. How do you read the trajectory of that market?
William : I distinguish three approaches. The first, the market-tool approach, is to acquire an existing enterprise architecture tool and let your practice mature alongside it. The second, at the opposite end, is a matter of craftsmanship: you give up market tools to build your own solution, manage your own view of the information system and, increasingly, connect it to the development pipeline. The third, finally, brings together the tools known as AI-native or AI-first. There, artificial intelligence is not a layer laid over the existing system: it is the very foundation of the tool. It maps all the data, in every format, which makes it possible to build a system that does not merely describe the portfolio, but reasons and acts.
Sylvain : That leads naturally to your initiative, the EA Codex. Could you lay out its guiding idea?
William : The guiding idea fits in a single sentence: to move architecture from periodic, document-centred governance to a continuous, semantic, specification-driven and genuinely executable system. That is the whole subject of my book, AI-Augmented Enterprise Architecture. The chain unfolds from intent to decision, then to specification, to execution and at last to the feedback that nourishes the next cycle. Until now, the architect has remained confined to documentation and governance, never quite able to keep pace with the rhythm of change and projects. Artificial intelligence gave us the opening to build an executable system that drives the architect’s own process. I always sum that process up in four movements: understand, manage, govern, execute. Understand what you have, manage the portfolio, govern the standards and rules, then execute, since we stand ever closer to the code. Architecture then ceases to be a document: each decision, each standard, each specification becomes an object linked to the others in a graph. Some rules are written out plainly, as policy as code: code that checks on its own whether an element complies. For the cases that call for judgement, we let the AI reason. Fitness functions complete the picture: they are automated tests that validate the requirements, above all the non-functional ones. And those are precisely the ones most often neglected, even though they cause most incidents in production. Today, architecture tools barely manage this body of work; they merely describe the portfolio. Yet the moment you must absorb continuous change, the point is to enforce the rules in real time, not to audit them every couple of months.
Sylvain : If I follow you, this amounts to spreading the architecture rules into the very heart of design workflows and the CI/CD chain?
William : Exactly. Take the cloud first principle. In the old days, I would write a document explaining what it covers and why it matters, publish it on a SharePoint, and in the design authority simply tick “compliant” or “non-compliant”. In the EA Codex, the approach is far richer. You begin by describing the intent, then derive executable rules from it: if you mandate cloud first, then you must verify sovereignty, for there is a direct dependency between the two. The principle’s definition passes through a process much like the one that validates code, and it yields an evidence record. I automated that design authority with twelve agents: a solution architect, a data architect, a security architect, and so on. The day I submitted my cloud first principle, convinced it would sail through, it was blocked. I had forgotten both security and pharmacovigilance rules, and the security agent refused to let through a principle that carried not a single security rule. The cycle replays until every member validates, and you can set the dial anywhere from fully automated to fully human. The real difficulty arises when you write the rules. That is a different craft: you have to work out how to fetch the information from Boldo and decide precisely which rules to express. You turn into code what lived only in the experts’ heads. The exercise is demanding, but once carried through it becomes remarkably powerful: automated, reusable and secure, because no one can any longer claim they were unaware.
Sylvain : All of this augments the architect considerably. What room, then, is left for the human?
William : Their role will grow in weight and in interest. The architect’s misfortune, all too often, is to go unheard. When I was a consultant, I had a very simple test: ask the same question of two architects; if their answers diverge, it means they do not share the same codex. The project teams know this perfectly well, and pick the architect who gives the answer they hope for. Reaching a shared view is already a considerable gain. In concrete terms, that view is made of content, executable rules and a predefined, executable enterprise architecture process, gathered in the codex. Architects build it and evolve it together, and at last reason from the same reference. Within that process, each initiative follows a short cycle, the BMAD: Brief, Map, Act, Double-check. The more you automate it, the closer you get to a dark factory, where execution runs with almost no human intervention. The codex also gives them back precious time: instead of documenting for hours, they let the documentation generate itself. This interview, for instance, could be poured into the tool and enrich the knowledge base. The architect then ceases to be a gatekeeper and becomes the orchestrator of an end-to-end process. Many feel isolated; they do remarkable work, yet struggle to have its value recognised. When everything runs smoothly, no one says a word; at the first incident, they are the ones singled out.
Sylvain : You keep returning to two notions, fitness functions and the evidence record. Why do you place so much weight on them?
William : Because they are the two pillars of an architecture that can prove itself. The evidence record, first: every decision, every rule check leaves a timestamped trace, recording what was decided, on what basis and by whom. You no longer merely assert that a system complies, you provide the proof. This is essential for audit and regulatory compliance: months later, you can still retrieve why a given decision was made. The fitness function, next, is a decisive instrument: it is what carries us towards architecture as code and towards that non-functional dimension architects handle poorly, having never made it their core business. These functions can, moreover, be shared from one project to the next. They harden into rules: my system must be reliable, and one still has to define what “reliable” means. Once those rules are set, the design unifies very quickly and costs fall, since we stop reinventing, on every project, an architecture already proven.
Sylvain : Before we close, what news would you like to share for the months ahead?
William : I have put it all online, as open source: the book and the schema, with a first set of objects, are already available. I am also building a cockpit, an open-source, Git-native, database-free reference implementation. I use it to check that what I have in mind works. It shows the Codex as a map: architecture objects as nodes, their relationships as edges, and the four phases understand, manage, govern, execute as the through-line. On it you follow the two graphs, the agentic process that runs across them, and every decision leaves its evidence record. What I would love is for practitioners to take these ideas and extend their own tools with this codex, or for vendors like you to pick up a few of its concepts. We would then have a broader knowledge graph: on one side the real infrastructure and applications, on the other automated governance. For data products, for instance, standards already exist to describe a data product or a data contract; no need to reinvent the wheel. You just have to give architects tools that make these ideas concrete, because they will never have the time to build their own.
Sylvain : Among everything you describe, which capability should these tools, in your view, adopt first?
William : Without hesitation, the automated, agentic design authority. That is the building block every architecture tool should start to offer. One can begin modestly, with a handful of validated principles each generating its evidence record, then scale up from there. At its core, it is a process that runs across the two graphs, reasons and acts. AI will not replace architecture; it makes it explicit and mandatory. Every architectural decision must become an object one governs, not a mere sentence buried in a document. And an agent cannot make do with a prompt: it needs a contract. For what separates an application from an agent is that the agent decides and acts on its own; it falls to the architect to set what it is allowed to do, on pain of no longer knowing what it will do. This building block belongs to a wider logic, that of continuous architecture, with the continuous improvement that goes with it: each time we learn something, we spare ourselves from repeating the same mistake. Yet today’s tools excel at understand and manage, far less at govern and at its articulation with execute. That is exactly the gap the EA Codex fills, as an open layer those tools can adopt rather than each rewrite in its own corner. The day you connect all these elements, the tool changes scale, and it is not out of reach: in two or three weeks you can build a genuinely useful extension. A tool like Boldo strikes me as well placed for it, because it is lean while letting you create quickly. There remains the real question, that of value: why invest in executable architecture, over which scope, and for what return. If the capability comes with the tool, I do not hesitate; if I must code it myself, I think harder, for writing code also means creating debt.
Sylvain : Thank you very much, William, for your availability and for the richness of this exchange.
William : Thank you for the invitation; it was a real pleasure. The profession is expanding fast: architect positions are multiplying, and many solution architects will move towards enterprise architecture. That momentum will create value, but it also raises the bar: the architect will be asked to prove that value, not just claim it. And that is exactly where the profession remains fragile, because architects rarely justify their investments to their CIO. Hence the value of tools, even simple ones, that make that value visible and demonstrable. That, to my mind, is the right direction: turning every architectural decision into something you can show, measure and defend.
To discover the EA Codex and the book AI-Augmented Enterprise Architecture, visit the companion site https://eacodex.ai/. The object schema is open source on https://github.com/welkaim/ea-codex.
To find out more about Boldo, visit https://boldo.io.
