What the Business Architect Role Actually Is: Findings from 161 Verified Job Postings

Most answers to "what is a business architect" come from one of two places: a vendor selling architecture software, or a certification body selling a credential. Neither reads a job posting.

This report does. Every finding below comes from individually reading and coding 161 recent Business Architect postings, worldwide, against a fixed schema, then comparing them to a control sample of 94 postings across six adjacent roles (Business Analyst, Enterprise Architect, Solution Architect, Process Architect, Transformation Lead, Product Manager) coded the same way. Nobody else answering this question has this. That's not a boast, it's a gap: the field's own institutions define the role by framework or credential; this is the first attempt to define it by what employers actually ask for, at scale.

The Business Architect: What the Role Is, What It Isn't, and What It's Becoming makes the fuller argument this data supports. This report is the evidence; that deeper dive is what it means.

The five findings that matter most

1. Enterprise Architect and Business Architect job postings ask for almost the same things on governance and planning, but diverge sharply on the discipline's own signature work. Capability modelling (what an organisation can do) and value-stream design (the end-to-end flow that delivers value to a customer) are what still separate the two roles. Everywhere else, postings for the two roles increasingly overlap.
2. Frameworks are named far more often than they're required. TOGAF is mentioned in 45% of postings but explicitly required in only one in seven. BIZBOK, the discipline's own purpose-built framework, is named less than TOGAF is, and required even less often. A credential signals familiarity to an employer; it isn't what gets someone hired.
3. The soft-skill profile in postings is specific, not the standard senior-role checklist. Business Architect job postings lead on facilitation and collaboration, but name influence and persuasion at about half the rate Enterprise Architect and Solution Architect postings do. That's a gap in the words postings use, not in what Business Architect practitioners can actually do.
4. The role's own stated purpose, connecting strategy to delivered value, is barely visible in how it's actually hired for. Under one in ten Business Architect postings ask for anything resembling benefits realization: tracking whether the value promised actually showed up. Most employers aren't hiring for the one thing that would prove the role delivered.
5. Compensation runs higher than the adjacent-role pool overall, but that average hides real spread. Two roles (Solution Architect, Process Architect) appear to out-earn the Business Architect median, on samples of just six and four disclosed salaries, respectively; Business Analyst pays the least of any role sampled.

What the Business Architect role actually asks for

Ranked by how often each area shows up in a Business Architect posting (n=161):

Strategy and transformation top the list, but they'd top it for almost every senior role sampled, so that ranking alone doesn't say anything specific about the Business Architect discipline. Stakeholder management is the more telling field: the single most commonly named area among those that actually vary from role to role, ahead of governance, roadmapping, or any named certification. Capability modelling, target operating model (TOM) design, and value-stream design, the Business Architect's own signature deliverables, sit in the 37–49% range: common, but far from universal. And benefits realization, the part of the job that closes the loop back to purpose, is close to absent.

One row runs against expectation, given how central AI has become to how organisations plan their own future: AI/automation, at 29.8%, is mentioned less often in Business Architect postings than in the pooled adjacent-role sample (50.0%). Capability modelling and value-stream design, the discipline's own signature work, are arguably exactly what an organisation needs most while it works out how to deploy AI responsibly, so a lower AI/automation mention rate looks like the Business Architect role sitting out its own moment. However, compared against what those adjacent postings actually are, Solution Architect and Product Manager roles that are often building AI products directly, the gap looks more like a side effect of which roles are in the comparison group: those roles are literally building AI systems, while the Business Architect discipline treats AI as one of several strategic shifts it exists to translate into capability and operating-model change, not a line item named in the posting itself.

How the Business Architect role compares to six adjacent roles

The comparison between the Business Architect role and other roles isolates two different kinds of content, since blending them into one score flattens the actual finding:

• Architecture-general: governance, roadmapping, and enterprise-architecture-named content. Vocabulary that tracks senior architecture and planning work broadly, not the Business Architect discipline specifically.
• BIZBOK-specific: capability modelling, target operating model design, and value-stream design. The fields where the discipline's own signature shows up.

Two things jump out from this comparison. Enterprise Architect postings don't just match Business Architect postings on general architecture and planning content (x-axis), they exceed them, driven by governance and roadmapping. But on the fields that actually define the Business Architecture discipline (y-axis), capability modelling, TOM, and value streams, Enterprise Architect's content collapses to half the BA benchmark. Solution Architect postings show almost the mirror image: close to Business Architect on general architecture content, but the lowest BIZBOK-specific score of any architect role sampled, essentially zero.

Business Analyst postings are the clearest negative result in the entire study. Zero measurable overlap with Business Architecture on the fields that define it. The career pathway between the two roles is real: several employers explicitly accept business-analysis experience as a qualifying route in, but the two roles do different work once someone is in the seat. Whoever coined "business architecture is just an evolution of business analysis" wasn't reading postings.

Read together: the Business Architecture discipline's closest living relatives, on actual content, are Enterprise and Solution Architecture, but only on the x-axis general-planning half of the job. The y-axis half that gives the Business Architect role its own name, capability and value-stream work, remains genuinely distinct.

Where some hirers draw the line themselves

The comparison above measures the gap between Business Architect and Business Analyst postings. A few recent postings state it outright, as a hiring filter. Four of the 161, from three different hiring firms, tell named adjacent-role holders not to apply:

• A UK recruiter, for a growth-strategy role: "Please do not apply if... You are a Business Analyst, or a Project/Programme Manager seeking a step into architecture," or "an advisor who is not hands on in authoring capability maps, TOMs and transformation blueprints."
• A New Zealand architecture consultancy, for a government client: "This is not a technical architecture role and it is not a process-mapping role. If you have not put a future state in front of an executive team and had it land, we are unlikely to be able to engage with you on this one, no matter how strong the rest of your background is."
• A Québec staffing firm, across two postings, excluding a "business analyst profile whose experience covers detailed requirements in the delivery phase, with no demonstrated definition of needs upstream of prioritized initiatives," and any "profile whose analyses are limited to documentation."

None of them draws the line at the job title alone. They draw it at the stage of the work (defining needs and options before an initiative is funded, not detailing requirements once delivery has started), at the outcome (a future state that landed with executives, a recommendation that changed what happened next), and at authorship (building the capability map, not advising on one).

That's the same boundary the content data measures, stated by people screening real candidates. It isn't universal: other employers in the same dataset hire for business-analyst work under the Business Architect title, or accept business-analysis experience as an equivalent background. Four postings out of 161 is a signal, not a prevalence finding, and all four came from recruiters and consultancies rather than employers hiring directly. But it's the plainest statement in the data of where some hirers think the role begins.

Architecture credentials: named often, required rarely

Of the four frameworks compared, the gap between TOGAF and BIZBOK is the one worth pausing on: TOGAF is named roughly 1.8 times more often than BIZBOK, despite BIZBOK being the Business Architecture Guild's own purpose-built framework for this exact discipline. Interpret that as an awareness-and-adoption gap, not a verdict on BIZBOK's content: TOGAF has close to a two-decade head start and a larger vendor and certification ecosystem behind it. It says something about which credential body has won the market's attention. It says nothing about which one produces better architects.

The same pattern holds for every framework tested, not just these two: each one gets named in Business Architect postings at least three times as often as it's actually required.

Soft skills: what actually differentiates

Business Architect postings lead clearly on facilitation and relationship-building (more than double the pooled rate on the last one), and modestly on collaboration, but name influence and persuasion far less often than the two architecture roles they're most often compared with: Enterprise Architect and Solution Architect postings both name it at roughly double the Business Architect rate. The largest gap of all runs the other way, on coaching and mentoring, which adjacent roles name ten points more often.

That's a vocabulary gap around influence and persuasion, not a measured gap in behaviour: this study's method counts what a posting names, not what a practitioner actually does once hired. One plausible interpretation is that the Business Architect role's version of influence runs through building a shared view among people rather than pressing a position against resistance, which would show up as exactly this kind of naming gap even if the underlying skill were equally present. The data can't distinguish that reading from the simpler one, that Business Architect postings just don't use this language as often.

Compensation

Based on 48 disclosed annual-equivalent figures across the main compilation (30% of the 161 postings studied); the rest state "not listed" or equivalent.

• Median: $119,454. Mean $125,553. Range $68,985–$241,900.
• By region: US roles pay meaningfully more than every other well-sampled region, nearly double the Continental European median. Canada's figures cluster consistently under $99K, a real regional floor within this dataset.
• By seniority: a clean gradient in the mean (a different statistic from the medians charted above). Standard-level roles average roughly $107K, senior/lead roles roughly $137K, director-and-above roughly $164K.
• Against the adjacent-role pool: Business Architect's median runs well ahead of the pooled adjacent-role median ($96,606), but that average hides real spread. Solution Architect (n=6) and Process Architect (n=4) appear to out-earn the Business Architect median (n=48), though at these sample sizes a single posting could move either figure. Business Analyst, at $81,287, pays the least of any role sampled in either corpus.

One genuinely interesting counterpoint: Enterprise Architect postings score highest of any adjacent role on architecture-general content overlap, but their disclosed salaries run at or below the Business Architect median. Solution Architect, the role with the least BIZBOK-specific content of any role sampled, pays the most. Content overlap and compensation appear to be tracking two different things entirely.

The archetype, and the gap in it

Pulling every finding above into one composite picture: the typical Business Architect posting, drawn from the 96 "Pure-titled" entries in this study, whose job title is a clean fit for the discipline rather than blended with another role's (60% of the full sample), asks for a practitioner who translates strategy into capability, operating-model, and process work, tracks it across a whole portfolio rather than one initiative, and produces a roadmap.

What it rarely asks for is whether the roadmap actually delivered. Benefits realization, tracking that the promised value showed up, appears in under one in ten Business Architect postings even within this Pure-titled subset. That's not a footnote. It's the discipline's own stated reason for existing (connecting strategy to delivered value), showing up in postings far less often than the upstream design work that precedes it does.

In Design4 terms, this lands specifically on Discover: the phase that asks whether the value promised is actually being produced.

The coding schema itself tracks content areas (strategy, capability modelling, TOM, value-stream design, and so on), not Design4 phases directly: each role's phase presence above is inferred from that coding, not read off a phase label in the data.

Business Architect is the only role in this study's comparison set with any structural claim to Discover at all; every adjacent role sampled sits somewhere in Define, Develop, or Deliver, and none of them close the loop back to Discover, based on this reasoning. What is directly measured is the market's hiring language for that phase: under one in ten Business Architect postings ask for anything resembling benefits realization. Combining the two, the reasoned claim to Discover and the measured near-absence of benefits-realization language, produces one of this study's more actionable findings: the market is largely not hiring for the part of the job that would prove the Business Architect role's own value. Worth a second look by anyone building a business-architecture practice from the ground up: the risk is inheriting this same blind spot rather than designing it out from day one.

Methodology, in brief

Every Business Architect posting in this study was individually sourced (LinkedIn, employer career sites, staffing agencies, job boards) and read in full, not summarised by a scraper. Each was coded against a fixed content, credential, and soft-skills schema using a negation-aware method (a keyword only counts if the surrounding text doesn't explicitly deny it: "no capability map appears in this posting" doesn't count as a capability-modelling hit). The adjacent-role control sample (Business Analyst, Enterprise Architect, Solution Architect, Process Architect, Transformation Lead, Product Manager) was built and coded the same way, so every comparison in this report is like-for-like.

What this method measures is what employers write when hiring for the Business Architect role, not an audit of how the work actually gets done once someone is in it, and not a judgment about the quality or depth of any single posting's requirements. A field mentioned once in a long list scores the same as one the whole posting is built around. Every percentage above should be read as a presence-rate, not a substance ranking.

This is a living dataset. The figures in this report reflect the corpus as of 3 October 2026 (version 2.0; version 1.0, 6 September 2026, covered 108 postings); the full methodology, correction history, and underlying data live in the source research, available on request.

What this means, depending on who's reading it

If you're a practicing Business Architect: what differentiates senior practice, on this evidence, is holding the portfolio-level question (are the things being built actually adding up to the outcomes the organisation exists to produce), reading the political structure before presenting analysis, and forcing a governance decision rather than presenting a finding. None of that shows up on a certificate.

If you're moving toward the role: the credentials are named far more often than they're required, so a missing TOGAF or BIZBOK certification isn't the barrier it can feel like. Business-analysis experience is a real, employer-accepted route in, even though the two roles do different work once you're in the seat. Some hirers now screen explicitly for upstream work, though: if your experience includes defining needs and options before an initiative was funded, or a future state that executives acted on, lead with that rather than with delivery-phase requirements. The soft-skill profile this data actually rewards, collaboration and facilitation ahead of framework fluency, is something to build and point to now, not something a course alone confers.

If you're hiring for the role: naming a framework in the posting signals maturity to candidates more than it screens them, so requiring TOGAF or BIZBOK narrows the pool without clear evidence it improves outcomes. Ask directly for collaboration and facilitation instead of generic "strategic thinker" language, since that's what actually differentiates strong postings in this data. And if you want a hire who can prove the role delivered, ask for benefits-realization experience explicitly, since almost nobody currently screens for it. The clearest postings in this dataset also say which stage of the work they mean (shaping before funding, not detailing during delivery) rather than relying on the title to carry it.

If you're building or maturing a business-architecture practice: the Discover-phase gap above is the one finding in this report worth acting on directly. If nobody in the practice is asking whether the value actually materialised, the practice is structurally missing the one thing that proves its own worth.