Business Architecture Defines the Roles Your AI Team Actually Needs
TOGAF 10 provides the Business Architecture discipline. This article applies that discipline to AI talent planning; the five-stage capability-to-role framework presented here is an applied methodology, not a prescribed TOGAF method.
Why Enterprises Keep Hiring the Wrong AI Team
Most enterprises building an AI capability start with a job description, not a business problem. A CTO sees a competitor hire a "Head of AI," so the enterprise creates the same title. A Head of Data sees "Prompt Engineer" trending on LinkedIn, so three requisitions go out. Six months later, the team is staffed, the budget is spent, and the capability gap that started the whole effort is still open.
This happens because the hiring decision was never derived from the enterprise's own architecture. It was copied from someone else's org chart. A title that made sense for a hyperscaler solving a hyperscaler's problem gets imported into a mid-size bank, insurer, or manufacturer solving an entirely different set of problems.
Business Architecture exists to prevent exactly this failure. It gives enterprise architects, Heads of AI, and CTOs a disciplined way to trace every hire back to a specific capability gap, rather than to an industry trend. This article walks through that method using TOGAF 10's Phase B, validated against the current standard, and applies it directly to the question of what an AI team should actually look like.
The Core Argument
A role exists to close a capability gap. It does not exist because a title is fashionable.
When an enterprise hires based on fashionable titles, it accumulates skills that sound impressive on paper but do not connect to any specific business outcome. When an enterprise hires based on capability gaps, every role has a reason to exist, a boundary of accountability, and a measurable contribution to the target state.
This is not a philosophical distinction. It changes headcount, budget allocation, and the sequence in which people get hired. A capability-first enterprise might discover it needs a blended data-governance-and-MLOps skill set before it needs anything resembling a "Prompt Engineer." A title-first enterprise never asks that question, because the title arrived before the analysis did.
TOGAF 10 Phase B: The Discipline Behind the Method
Phase B of the TOGAF Architecture Development Method develops the Business Architecture that supports an agreed Architecture Vision. It describes how the enterprise's processes, people, organizational structures, and value streams need to operate to achieve stated business goals. This makes Phase B a natural architectural foundation for translating business ambition into organizational and capability requirements, which can subsequently inform AI talent and workforce planning.
The Phase B objectives, as defined in the standard, are worth stating precisely. Phase B develops the Target Business Architecture describing how the enterprise needs to operate to achieve its business goals and respond to the strategic drivers set out in the Architecture Vision. It also identifies candidate Architecture Roadmap components based on the gaps between the Baseline and Target Business Architectures.
Notice what those objectives do not say. They do not say "define job titles." They say define how the enterprise needs to operate, and identify the gaps between where it operates today and where it needs to operate tomorrow. Roles and titles are downstream artifacts of that gap, not the starting point.
The Steps That Matter for Talent Planning
TOGAF 10 lays out nine steps within Phase B. Of the Phase B activities, four are particularly relevant to the capability-to-role analysis developed in this article:
Develop Baseline Business Architecture Description. The enterprise documents the existing Business Architecture to the level necessary to support the Target Business Architecture, including relevant capabilities, organizational structures, functions, processes, and other business elements within scope. Existing skills and organizational responsibilities can then be examined where they are relevant to the capability assessment. Without this step, an enterprise cannot know what it already has, which means it cannot know what it is missing.
Develop Target Business Architecture Description. The enterprise articulates the business capabilities, organizational structure, and value streams required to achieve the Architecture Vision. This is where "AI-enabled customer service" or "AI-augmented underwriting" gets defined as a capability the business needs, rather than as a vague aspiration.
Perform Gap Analysis. The enterprise compares baseline against target and identifies precisely which capabilities are missing, partial, or misaligned. This gap analysis is the single most important artifact in the entire talent-planning exercise, because every role the enterprise eventually hires should trace back to a specific line in this analysis.
Define Candidate Roadmap Components. The enterprise translates each gap into a work package, and each work package carries implications for the people needed to deliver it. For the capability-to-role method developed in this article, candidate roadmap components are the point at which identified capability gaps begin to translate into implementation activities that may have organizational and staffing implications. This interpretation is an application of Phase B to AI talent planning, not a TOGAF-defined sequence for deriving roles.
I am applying Phase B to AI talent planning, rather than claiming TOGAF defines the above-mentioned four steps specifically as a talent-planning methodology.
The sequencing here is deliberate. In this capability-to-role method, roles are downstream consequences of the architectural analysis, not the starting point. An enterprise that starts by writing job descriptions has bypassed the architectural analysis that this capability-to-role method is designed to establish.
The Capability-to-Role Framework
Building on Phase B, the practical framework for deriving AI talent requirements has five stages. Each stage produces an artifact that feeds the next, and no stage should be skipped in the interest of speed.
Stage One: Build the Business Capability Map
A Business Capability describes what the enterprise does, expressed independently of how it does it or who does it. "Assess credit risk," "resolve customer complaints," and "forecast demand" are capabilities. They are stable descriptions that do not change even when the underlying technology or organizational structure changes around them.
For AI talent planning, the enterprise builds or extends its existing capability map and marks which capabilities are candidates for AI augmentation. This marking should come from the business strategy, not from the technology team's enthusiasm. A capability becomes an AI candidate because the Architecture Vision says the enterprise needs it to operate differently, not because a vendor demo looked impressive.
Stage Two: Define Baseline and Target States for Each Capability
For every capability marked as an AI candidate, the enterprise defines two states. The baseline state describes how the capability operates today, including the manual steps, the existing tools, and the people currently responsible. The target state describes how the capability needs to operate once AI augmentation is in place.
This stage forces precision that most AI strategy documents lack. "We want to use AI in underwriting" is not a target state. "Underwriting decisions for standard policies are generated by a model and reviewed by a human within four hours, with full audit trail" is a target state. Only the second version can be compared against a baseline to produce a meaningful gap.
Stage Three: Perform the Gap Analysis
With baseline and target states defined, the enterprise identifies exactly what is missing. Gaps typically fall into a small number of categories: missing data infrastructure, missing model development capacity, missing governance and risk controls, missing integration into existing business processes, and missing change management capacity to get the business to actually adopt the new way of working.
Each gap should be written as a capability statement, not a role statement. "The enterprise lacks the capacity to continuously monitor model performance in production" is a gap. "We need an MLOps Engineer" is a premature conclusion. The gap statement stays capability-focused so that the next stage can derive the right skill set rather than the first title that comes to mind.
Stage Four: Derive the Skill Profile
This is where the framework earns its value. For each gap, the enterprise asks a narrow question: what specific skills, in what combination, would close this gap? The answer is almost never a single, clean, industry-standard title. It is usually a blend.
A gap in "continuous monitoring of model performance in production" might require a skill profile combining software engineering discipline, statistical literacy, and familiarity with the enterprise's specific data pipelines. That blend might map to something called MLOps Engineer at one enterprise and to a Senior Data Engineer with an added responsibility at another. The skill profile is derived first. The label comes after.
This stage should also identify whether the gap can be closed through upskilling an existing employee, through a new hire, through a vendor relationship, or through a combination of the three. Business Architecture does not assume every gap requires new headcount. Many gaps are closed faster and more cheaply by extending an existing team member's remit.
Stage Five: Map to a Title, Last
Only after the skill profile is defined does the enterprise choose a title. The title should be chosen for internal clarity and external recruitability, not because it appeared in someone else's org chart. If "AI Solutions Engineer" is a clearer, more recruitable label than "Blended MLOps and Data Governance Specialist," the enterprise can use it, as long as the underlying skill profile stays tied to the capability gap it was derived from.
This ordering matters because it keeps the enterprise honest. A title chosen last, after four stages of analysis, is a title the enterprise can defend in a budget review. A title chosen first, before any analysis, is a title the enterprise is merely hoping will work out.
Organizational and skills considerations can emerge from Business Architecture, while it is important to make clear that the specific five-stage framework presented here is an applied methodology.
A Worked Example
Consider a mid-size regional bank pursuing AI-augmented customer service as part of its Architecture Vision.
Baseline capability. Customer service inquiries are handled entirely by human agents using a knowledge base search tool. Average resolution time is eleven minutes. No AI component exists in the workflow.
Target capability. A conversational AI system handles first-line triage and resolves routine inquiries without human involvement, escalating complex cases to human agents with full context already assembled. Target resolution time for AI-handled inquiries is under two minutes, with human-handled escalations resolved faster because agents no longer need to gather context manually.
Gap analysis. Three material gaps emerge. First, the bank has no infrastructure for deploying and orchestrating a conversational AI system against its existing customer data. Second, the bank has no process for reviewing AI-generated responses for regulatory compliance before they reach a customer. Third, the bank has no mechanism for retraining or tuning the system based on escalation patterns.
Skill profile derivation. The first gap points toward a blended skill profile combining AI orchestration, systems integration, and familiarity with the bank's core banking platform, closer to a Conversational AI Orchestration specialist than a generic Prompt Engineer. The second gap points toward a skill profile combining regulatory knowledge and AI output evaluation, which may not require a new hire at all if an existing compliance analyst can be upskilled. The third gap points toward a skill profile combining data analysis and model tuning, close to what the market calls an MLOps Engineer, but scoped narrowly to conversational systems rather than the bank's full model estate.
Title mapping. The bank ends up hiring one Conversational AI Orchestration Engineer, upskilling one existing Compliance Analyst with AI evaluation training, and hiring one part-time MLOps contractor scoped specifically to the conversational system. No "Head of AI" was needed for this particular capability gap, because the gap did not require enterprise-wide AI leadership. It required three specific, narrowly scoped skill profiles.
This is the outcome that title-first hiring almost never produces. A title-first approach would have posted for a Head of AI, a Prompt Engineer, and an MLOps Engineer, and would likely have ended up with capability overlap in some areas and capability gaps in others.
The Messy Reality Enterprises Must Accept
Capability gaps rarely map cleanly to a single role, and any article that pretends otherwise is overselling the framework. Real gaps are usually blended, and the resulting skill profiles cross the boundaries of conventional job families.
An enterprise pursuing AI-augmented underwriting will likely find that no single hire closes the gap. It will need a combination of data governance capacity, model development capacity, and change management capacity to get underwriters to actually trust and use the new system. These capacities might live in three different people, or they might live in one senior hybrid hire, depending on the enterprise's size and existing bench strength.
Business Architecture does not resolve this messiness. It surfaces it. That is precisely its value. An enterprise that sees the blended nature of its own gaps can make a deliberate choice about how to staff them. An enterprise that skips the analysis and hires against a generic title list never sees the blend at all, and ends up with three people who each own a third of the problem and none of whom own the whole of it.
The Title Inflation Problem
Enterprise AI hiring in 2026 suffers from significant title inflation. "AI Architect" is applied to roles ranging from genuine enterprise-wide AI strategy ownership to narrow prompt-tuning work. "Prompt Engineer" is applied to roles ranging from sophisticated context-engineering and evaluation work to what is, in practice, competent use of a chat interface.
This inflation is not merely a recruiting nuisance. It has real cost consequences. An enterprise that hires a highly compensated "AI Architect" to do narrow prompt-tuning work has overpaid for a capability gap that did not require that level of seniority. An enterprise that hires a junior "Prompt Engineer" to own enterprise-wide AI governance has under-resourced a capability gap that required far more authority and experience than the title implied.
Business Architecture corrects this by tying compensation and seniority decisions to the size and complexity of the actual capability gap, rather than to market title benchmarks that may not reflect what the gap requires. A gap that only affects one business process warrants a narrowly scoped, appropriately compensated hire. A gap that affects the enterprise's entire risk posture warrants a senior, well-resourced hire, regardless of what title the market happens to be using this quarter.
Governance: Who Owns This Decision
The capability-to-role framework only works if someone owns the discipline of running it. In most enterprises, this responsibility sits jointly between the Enterprise Architecture function and the Head of AI, with the CTO as the ultimate approver of resulting headcount and budget decisions.
The Enterprise Architecture function owns the capability map, the baseline and target state definitions, and the gap analysis. This is core Business Architecture work and should follow the same governance the enterprise already applies to any other Phase B deliverable, including formal stakeholder review before the gap analysis is finalized.
The Head of AI owns the translation from gap to skill profile, bringing technical judgment about what combination of skills actually closes a given gap. This translation should be documented and defensible, not intuitive, so that the reasoning survives personnel changes and budget scrutiny.
The CTO owns the final title mapping and the build-versus-buy-versus-upskill decision for each role, weighing the skill profile against the enterprise's existing bench, its recruiting capacity, and its appetite for contractor relationships versus permanent headcount.
Keeping these three responsibilities distinct, and keeping the sequence intact, prevents the most common failure mode: a CTO or Head of AI jumping straight to a title because a board member asked "do we have a Head of AI yet," without the underlying capability work ever having been done.
Conclusion: Let the Architecture Choose the Titles
An AI team built from a title list is a team built on borrowed assumptions. An AI team built from a capability gap analysis is a team the enterprise can actually defend, budget for, and hold accountable, because every role traces back to a specific piece of business architecture rather than to a trend.
TOGAF 10's Phase B already gives enterprises the discipline to do this correctly. Baseline the business capabilities. Define the target state the Architecture Vision demands. Perform the gap analysis rigorously. Derive skill profiles from the gaps, blended where the gaps demand blending. Only then choose the titles.
The objective is not to build an AI team that looks right on an organizational chart. The objective is to build the organizational capabilities required by the target business architecture. Once those capabilities and their gaps are understood, the required skills become clearer, the roles become easier to define, and the staffing decision becomes an architectural consequence rather than a reaction to market trends.
✍️ About the Author
Sanjoy Kumar Malik — Principal AI Architect, Enterprise AI Strategist, and Senior Engineering & Technology Leader with 20+ years of corporate IT experience and a broader 27+ year professional journey, spanning Enterprise Architecture, software architecture, cloud-native systems, engineering leadership, and AI architecture. He is a TOGAF 10 Certified Enterprise Architecture Practitioner and AWS Certified Solutions Architect – Professional.
Sanjoy focuses on translating business strategy and AI opportunity into coherent enterprise architecture and scalable engineering execution. He works at the intersection of business, technology, architecture, and AI, helping organizations establish the architectural foundations, technology capabilities, and engineering systems required to turn AI initiatives into production-grade, scalable, governed, and economically sustainable enterprise capabilities.
He is the creator of The 28-Category AI Architecture Decision Framework (28-CAADF), a systematic approach to making AI architecture decisions in an era where intelligence itself is becoming an architectural capability.