The BTABoK and Agents

I have been getting a lot of questions lately about how architecture fits with agents, and honestly the questions are mostly the same question. Somebody has been told by a vendor that their platform now does architecture, or that agents will design the system, or that the architect role folds into platform engineering. And they want to know what I think. So here is what I think, in more detail than fits in a comment thread.

I have been building and deploying these things since 2001 when I put my first neural net into production, and I have spent the last two years running agents against the BTABoK, our own platform and real client engagements. I am not anti AI. I use it every day. But I have also spent 24 years interviewing architects in 50 or so countries about what actually goes wrong in business technology systems, and what goes wrong is almost never a lack of speed. It is a lack of decision quality, decision ownership and shared understanding. Agents make speed cheap. They make the other three things harder unless you set them up correctly.

My position is that the BTABoK is the best foundation currently available for using agents in architecture, strategy and delivery. Not because IASA built it, though I will get to that, but because of what it is and what everyone else isnt.

What an agent actually needs from us

Lets be practical about this. An agent is a very capable and very fast worker with no memory of your organization beyond what you give it, and no professional judgement beyond what it can imitate from its context. It will produce a business capability map, an ADR, a target state diagram or a migration plan in about 40 seconds. The output will look good. Whether it is right depends entirely on what it was reasoning against.

So the question for any organization is what body of knowledge sits underneath the model. What does the agent think a capability is? What does it think a quality attribute is? What does it consider a decision, and who does it think gets to make one? What does it know about your business model, your value streams, your existing systems, the tradeoffs you already made and cannot undo?

In most organizations I visit the answer is a mix of a vendor reference architecture, some Confluence pages from 2019, and whatever the model absorbed from the public internet. Which is to say, LinkedIn. We have spent 20 years complaining about the quality of architecture guidance online. Now we are about to automate it.

Why the frameworks you already have dont do this

There are roughly three places people go for architecture knowledge today and none of them work for this purpose.

The cloud vendor frameworks are product catalogs with pillars. They are quite good at describing how to deploy on that vendor. They say nothing about business models, value measurement, engagement, decision accountability or the competencies of the people involved. Go try to find a business capability or a strategy scorecard in a well architected framework. An agent reasoning against one of these becomes a very confident sales engineer. I have been kicked out of a leadership forum in Amsterdam for saying exactly this to the vendors in the room, so I do not expect them to agree with me.

The enterprise frameworks are better on strategy but they are process heavy, largely paywalled, and they stop at the diagram. They do not connect to delivery. They do not measure value after the fact. And they have no competency model or career path, so there is no notion of who is qualified to sign off on anything. An agent can read a process description but it cannot reason across a chain that isnt there.

And then there is the in house wiki. I have seen hundreds of these. They are almost always a snapshot of three or four architects opinions at a point in time, using terms that mean different things in different departments. Feeding that to an agent gives you an agent that argues with itself

What the BTABoK has that matters here

The BTABoK is the open Business Technology Architecture Body of Knowledge. IASA has been building it with thousands of practitioners for about 15 years. The knowledge itself is Creative Commons. You can read it, disagree with it, and argue with it without paying anyone. Whether you like it or not, that matters for agents because a closed framework under an agent is a vendor opinion and that comes with a license fee attached. I will be clear about what is and isnt free further down.

There are four things in it that I think make it the right foundation.

First, it is a connected chain from strategy to delivery. Business model to capabilities to value streams to objectives (https://education.iasaglobal.org/browse/btabok/3.2/core-site/core/concept/strategy) to architecture decisions to quality attributes and patterns to engagement and measured value (https://education.iasaglobal.org/browse/btabok/3.2/core-site/core/concept/engagement). Every one of those is a defined concept with a canvas. The canvases are structured. That is the point. An agent can fill one in, validate it, and link it to the one before and after. It can walk from why the company exists to which quality attribute got traded away last sprint and back again. Every other option I know of has a gap in that chain, usually right where the vendor product ends.

Second, decisions are the core artifact (https://education.iasaglobal.org/browse/btabok/3.2/core-site/core/concept/decisions). The BTABoK treats an architecture decision as the unit of architecture, with forces, tradeoffs, principles, quality attributes and an accountable owner attached. This becomes far more important with agents. An agent produces options and output at a rate no human can review line by line. The only thing that scales with that rate is decision density. Which decisions were made, by whom, against which forces, and what was given up. An agent that cannot express its work as a decision record with an owner is producing suggestions, and suggestions at scale are noise.

Third, views and viewpoints (https://education.iasaglobal.org/browse/btabok/3.2/core-site/core/concept/viewpoints). This is the one I see people miss most often and it may be the most important for agents. A viewpoint is a defined way of looking at a system for a particular set of stakeholders and concerns. Context, functional, information, deployment, security, operational and so on. Each one in the BTABoK carries its concerns as explicit questions, the stakeholders who care, the architect specialization who owns the answer, the model types and notations used to answer it, and the canvases that get produced. That is exactly the shape of instruction an agent needs. Ask a model for “the architecture” and you get a pretty box diagram that answers nothing. Ask it for the information viewpoint, concern by concern, and you get an entity model, an ownership matrix, a classification, the flows across the boundary, and a decision record for each place a tradeoff was made, in a notation a human reviewer already knows how to read. The viewpoint tells the agent which questions to answer, for whom, and in what form. Without that the agent decides for itself what matters, and I believe it will decide wrong.

Fourth, it has a competency model and a career path (https://education.iasaglobal.org/browse/btabok/3.2/core-site/core/concept/competency). This is the piece everyone leaves out. It takes between 5 and 8 years to produce a board certified professional level architect and roughly 8 to 10 or more for a distinguished one. Somebody with that background has to be able to look at what the agent proposed and accept it or reject it with reasons, and be accountable for having done so. If your agentic architecture setup has no way to say who is qualified to accept a decision, you have a huge mess.

How this works in practice

We run the BTABoK on an MCP connector today at mcp.iasaglobal.org. An agent can query concepts, competencies, canvases, viewpoints and patterns directly and use them as the definitions it reasons with. The connector, the structured canvases and the full agentic tooling come with IASA membership. The written body of knowledge stays open. That is how a non profit professional body pays for growing it and keeping it maintained. We use it ourselves for decision records, canvases and engagement material. The real experience is still pretty tough… but you know that kind of tough if you have ever learned programming… it works, just needs smoothing. The output still needs a working architect to review it, and I spend about as much time correcting generated architecture as I ever spent writing it. It is worth it because the corrected output is consistent, linked and reviewable in a way our hand written material never was. What Im finding is I iterate the idea in the chat. Then I approve it, then ask it to look for linking concepts in the solution… it wires it up in Ergane and then I fix it… Sometimes it is the opposite, I stay up late designing then ask for reviews and connections and what Im missing.

This set of designs and decisions came from one of those sessions… it is the board sharing yjs design… which provides board sharing and bidirectional event playback.. That was an exceptionally intense design session.

A quick note before I describe the platform. Some of you have seen it under the name Loom. We are renaming it Ergane. Two reasons. The practical one is that Loom is already a well known video product and we were tired of explaining that we are not them. The better one is that Ergane is the name the Greeks gave Athena in her role as patron of the people who actually make things, the weavers and builders and craftspeople, the working practitioners rather than the philosophers. Wisdom applied through skilled hands. That is what an architecture platform is for and it is a better description of what we are trying to build than a piece of weaving equipment. So, Ergane from here on.

Ergane is our platform on top of the BTABoK, with CODL for canvases and CALM for models. You dont need it to use the BTABoK with agents. The same context can live in decision records and models in your own repositories. What Ergane adds is that the context is governed. An agent proposes a change set, the change set is validated against the existing decisions and models, and nothing lands without a decision record and an owner. Platform engineering then distributes that context to teams and agent runtimes. And it is not only architects in that loop. The engineers who build and run the system are the other half of it. In every complex engineering field the architect and the engineer both sign, in that order, because the architect owns the decision and the engineer owns whether the thing as built actually meets it. Agents change the engineers day more than anyone elses. Most of the code, the infrastructure definitions, the pipelines and the tests will be agent generated within a few years. So the engineer stops being the person who types it and becomes the person who verifies that what was generated matches the decisions, the quality attributes and the viewpoint models it was supposed to implement. The BTABoK covers this side too. It has the engineering material, the patterns, the quality attribute scenarios and the delivery and engagement guidance written for the working team, not only for the architect, and the architect competencies in design, quality attributes and IT environment are the same language the engineer verifies against. Architecture supplies the governed context, platform engineering distributes it, agents reason against it and generate, engineers verify and accept the build, and an accountable architect signs the decisions. That is the whole model. Simple to say. Very very hard to do.

Take the Tinkleman coffee shop system we use in the BTABoK for teaching. Integration engine, serverless functions, domain services, a legacy data center with a php order management system, point of sale, a native and browser app. That is a 200 store coffee company, not a bank. Now ask what an agent needs to know before it can safely change any of it. The deployed context. The libraries and their versions. The decisions already made and why. The quality attributes that cannot move. Who owns each piece. The BTABoK is the only place I know where every one of those things has a defined home and a defined relationship to the others.

Who is in charge

Put those four things together and you get a loop. Architects author the BTABoK. It is written by working architects, corrected by working architects, and it changes when the profession learns something. Agents consume it, through the connector or however else you feed it to them, and come back with recommendations, options, drafts and change sets. Architects decide. Engineers verify what gets built. And what we learn from the build goes back into the body of knowledge, written by the same people.

That is the part I think matters most and the part almost nobody is talking about. Every vendor pitch for agentic architecture puts the vendor in charge of what the agent knows. The BTABoK puts the architects in charge. We write the knowledge our agents reason with. We hold the decisions. We sign. Nobody else is offering the profession that, and I dont think anybody else can, because you cannot buy a body of knowledge written by the profession from someone who is not the profession.

I should be clear about my own role in this, because people sometimes assume I decide what goes in the BTABoK. I dont, or not much. I believe the members should decide. What agents are allowed to do, what a decision record must contain, which viewpoints matter, what board certification requires. Those are the professions calls to make and they should be made by the people who do the work. My job, and IASAs job, is narrower and I think more important. It is to give architects a framework and an organization that answers to them, and not to a vendor, a cloud provider or a big tech platform with a model to sell. Every other body of architecture knowledge you will be offered in the next few years is going to be funded by someone whose interest is that you use their product. Ours is funded by membership, which means it is funded by you, which means it is accountable to you. That is the whole reason it exists.

The part where I have something to sell you

I run IASA. IASA sells training and certification to keep a non profit alive, so of course I think the BTABoK is the answer. Feel free to point this out in the comments 🙂 A chief architect at a large firm once told me, and this is a direct quote, “Im more of a marketer than a researcher.” I think about that line more than I would like to.

But the body of knowledge itself is open. You can read it, use it and hold your agents to it without talking to me or anyone at IASA. The full agentic use, the connector, Ergane, the structured artifacts, comes with membership, and membership costs a great deal less than one bad architecture decision made by an agent nobody was accountable for. If I am wrong it costs you a weekend and a membership fee. If I am right it is the difference between an architecture practice that gets faster and one that gets automated out of accountability while nobody was looking. And I have watched enough Crowdstrike style meltdowns to know which of those the board will ask about afterwards.