From AI Speed to Architecture Value: The Role of BTABoK
Article by Paul Preiss (Founder and CEO of IASA Global)
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.
And by agents, it means AI-powered systems that can do more than simply answer questions. They can actively perform architecture-related tasks, creating business capability maps, drafting architecture decision records, producing target-state diagrams, developing migration plans, reviewing designs, and generating recommendations at a speed that would be impossible for a human team to match.
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 isn't.
BTABoK (Business Technology Architecture Body of Knowledge) provides a structured body of knowledge that connects business strategy, capabilities, value streams and objectives with architecture decisions, quality attributes, patterns, delivery and ultimately measurable value. In short, agents provide the speed; BTABoK provides the structure and context; architects provide the judgement and accountability.
Read also: How AI Agents Will Redefine Enterprise Architecture in 2026
Let's 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.
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 isn't 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.
Read also: AI Architecture: Building the Foundation for Scalable Enterprise AI
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.
The rise of agents doesn't reduce the need for architecture capability. It changes where that capability creates value.
As agents become increasingly capable of producing models, documentation and architecture options, organisations need professionals who can provide context, challenge assumptions, evaluate trade-offs and remain accountable for the decisions being made.
ATD Solution supports organisations in developing these capabilities through architecture training and certification programmes, alongside consulting that help teams apply Business and Enterprise Architecture practices within real transformation initiatives.
The opportunity is therefore not simply to teach architects how to use AI. It is to build architecture teams capable of governing, directing and extracting value from AI-assisted architecture work.
Source: Article by Paul Preiss (Founder and CEO of IASA Global) on LinkedIn Newsletter.
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.
And by agents, it means AI-powered systems that can do more than simply answer questions. They can actively perform architecture-related tasks, creating business capability maps, drafting architecture decision records, producing target-state diagrams, developing migration plans, reviewing designs, and generating recommendations at a speed that would be impossible for a human team to match.
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 isn't.
BTABoK (Business Technology Architecture Body of Knowledge) provides a structured body of knowledge that connects business strategy, capabilities, value streams and objectives with architecture decisions, quality attributes, patterns, delivery and ultimately measurable value. In short, agents provide the speed; BTABoK provides the structure and context; architects provide the judgement and accountability.
Read also: How AI Agents Will Redefine Enterprise Architecture in 2026
What an agent actually needs from us
Let's 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 don't 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 isn't 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.
Read also: AI Architecture: Building the Foundation for Scalable Enterprise AI
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.
Building the human capability behind agentic architecture
The rise of agents doesn't reduce the need for architecture capability. It changes where that capability creates value.
As agents become increasingly capable of producing models, documentation and architecture options, organisations need professionals who can provide context, challenge assumptions, evaluate trade-offs and remain accountable for the decisions being made.
ATD Solution supports organisations in developing these capabilities through architecture training and certification programmes, alongside consulting that help teams apply Business and Enterprise Architecture practices within real transformation initiatives.
The opportunity is therefore not simply to teach architects how to use AI. It is to build architecture teams capable of governing, directing and extracting value from AI-assisted architecture work.
Source: Article by Paul Preiss (Founder and CEO of IASA Global) on LinkedIn Newsletter.