BIZBOK, the Operating Model Canvas, and the Galbraith Star vs a function/motion decomposition

The question

Verbatim from the Notion Research Backlog:

"How do BIZBOK business-architecture capability maps + value streams and the operating-model design literature (Operating Model Canvas, Galbraith Star Model) map onto a function/motion decomposition of organizations, and what should the organizational-platform borrow from each?"

Context: the Organizational Platform (phData) decomposes any company into 10 functions running 36 motions, with an 80-role catalog priced against BLS OEWS wage data. Its content sections are deliberately unwritten pending this framework-research round. Sibling briefs tonight cover APQC PCF and the industry reference models (eTOM, BIAN, SCOR); this one covers BIZBOK plus operating-model design canon.

Source-honesty statement, up front. The BIZBOK® Guide itself (v13) is Business Architecture Guild member-gated and I did not read it. What I did read in full is the Guild's own free publication The Business Architecture Metamodel Guide v3.0 (September 2024) — a Guild-copyright document that carries the Guild's canonical definitions of capability, value stream, information, and organization. That is a Guild-primary source but it is not the BIZBOK Guide. Where I use leveling detail that lives only in the BIZBOK Guide's capability chapter (numbered levels, noun/verb naming conventions), I am relying on secondary summaries and I flag each one inline. WebFetch's own PDF extraction of the metamodel guide failed; I recovered the full text locally with pdftotext and read targeted sections, so quotes below are from the actual document.

What we already know (from the vault)

• The vault has essentially nothing on BIZBOK, business architecture as a discipline, the Operating Model Canvas, or Galbraith. Five QMD sub-queries across lexical and semantic modes returned no hit above 0.35 on any of these terms. This is a genuine cold start, not a retrieval failure — which means every claim in this brief is web-sourced and nothing is being cross-checked against prior RDCO thinking.
• The closest adjacent work is [[2026-06-29-ai-capability-org-structures]], which already carries the right epistemic posture for taxonomy work: "the patterns are a design palette, not a clean taxonomy. Real orgs run hybrids and decide centralize-vs-federate per sub-function." That caveat applies directly to motions.
• [[2026-06-14-caf-restructure-organizing-brief]] used a "capability unbundling" framing for internal work division — a third, informal sense of "capability" already floating in RDCO vocabulary. Relevant to the collision analysis below.
• [[2026-08-03-people-and-org-info-guidelines]] sets the handling boundary: concept-level taxonomy stays in the working tree, client stakeholder maps live outside the indexed vault. This brief stays concept-level.
• [[2026-05-13-dorsey-from-hierarchy-to-intelligence-block-mini-agi]] is the vault's existing argument that org charts are the wrong primitive — the same claim Galbraith made in the 1960s (below), which is worth knowing before we pitch it as novel.

What the web says

BIZBOK — capability. The Guild's metamodel guide states flatly: "A capability is what the business does." Three rules ride on it that matter more than the definition:

1. *"Capabilities are identified with a business object in focus. For example, if there is a capability such as 'Customer Management', this capability has the business object 'customer' in focus. Any decomposition of this capability will not change the focus on the customer.… In no case would a child capability of Customer Management veer outside customer scope."*
2. "Each business ecosystem has one, and only one, set of capabilities. In other words, one capability map crosses all business units."
3. "Crucially, capabilities are identified through a business' value streams." — capability maps are derived from value delivery, not brainstormed from departments. (Business Architecture Metamodel Guide v3.0, §5.2)

BIZBOK — value stream. "Value streams provide end-to-end stakeholder value delivery perspectives, with one value proposition per value stream." A triggering stakeholder triggers it; it decomposes into ordered value stream stages (linked by a "precedes" relationship); capabilities enable stages; stage outputs are value items that accrue toward the value proposition. The Guild's worked example is an airline with three value streams — Take a Trip, Send Shipment, Execute Route — and it is explicit that checked luggage gets its own value stream "because the value proposition differs." (ibid., §5.1)

BIZBOK — why the two are orthogonal. The load-bearing sentence: "Viewing a business through a capability perspective involves looking at the business at rest, whereas looking at the business from the value stream perspective involves looking at the business in motion, where value is being sought by a triggering stakeholder." They meet only through cross-mapping — and the Guild notes cross-mapping "is always between domains and is not used to associate elements within a domain." (ibid., §5.2, §4)

BIZBOK — the four core domains. "The recommended starting point for a business architecture baseline includes commonly engaged and customer-initiated value streams; a capability map; and an information map", with organization as the fourth core domain. The organization map "describes an ecosystem-wide perspective of business units… paints a picture of how an organization works, rather than how an executive might think it works" and is explicitly positioned as going "beyond the confines of a company's organizational chart." (ibid., §5.4, §4)

BIZBOK — the concepts that sit between capability and reality. This is the least-known part of the metamodel and the most useful to us. A capability is abstract and universal; the Guild then defines three bridging concepts: "Capability Instance: A specific realization of a capability, as it exists or is envisioned to exist, in the context of a given business unit or another situational context"; "Capability Behavior: The way in which a capability acts or conducts itself in certain circumstances or instances"; and Outcome. It adds: "an organization with many business units is likely to have many instances of an implemented capability, requiring independent analysis of the effectiveness and efficiency… of each of those capability instances." (ibid., §5.2)

BIZBOK leveling (secondary, flagged). Numbered-level detail is not in the metamodel guide. Secondary summaries state that capabilities are expressed in noun form ("Product Management") while value stream stages are expressed in verb/noun form ("Process Payment"), and that level-1 capabilities incorporate standard level-2 capabilities "determined on a case-by-case basis" (BPMInstitute, "Capabilities & Value Streams: Business Architecture's Essential Alliance"; Bizzdesign, "Business Architecture Redefined: Mapping BIZBOK to ArchiMate"; BusinessAnalystMentor, "Introduction to Capability Mapping"). I have not verified the noun/verb convention against Guild primary text. What the metamodel does say primarily is the invariance rule: "Capability principles, structure, and performance remain consistent at every level of hierarchical decomposition."

Operating Model Canvas (Campbell / Gutierrez / Lancelott, 2017). Six elements under the mnemonic POLISM: Processes — "the work that needs to be done to deliver a value proposition or service proposition", described as the value delivery chain; Organization — "people who will do the work, the structure, the functions needed to support"; Locations — "where the work is done"; Information — "the software applications needed to support the work"; Suppliers — "those outside the organization whose engagement is also needed"; Management system — "planning, budgeting, performance monitoring and controls needed to run". The canvas is explicitly contrasted with the org chart (which "shows structure only") and complements the Business Model Canvas, covering the operating half — Activities, Resources, Partners. (Van Haren Group, publisher, "Operating Model Canvas in 3 minutes"; corroborated by Umbrex, "Ashridge POLISM & Operating Model Canvas"). I did not read the book; the publisher page is near-primary marketing copy and I found no separate stated definition of "value delivery chain" beyond its identification with Processes.

Galbraith Star Model. From Galbraith's own consultancy site: Strategy "determines direction"; Structure "determines the location of decision-making power"; Processes "have to do with the flow of information"; Rewards "provide motivation and incentives for desired behavior"; People "selection and development of the right people — in alignment with the other policies." The framework's headline claim is that "Organization design is more than just structure", and its constraint is that "for an organization to be effective, all the policies must be aligned with one another." Culture is treated as an output of the five choices, not a sixth lever. (Galbraith Management Consultants, "Star Model"; corroborated on the five points by Strategic Management Insight and Umbrex).

Convergences and contradictions

• Convergence, and an uncomfortable one: all three frameworks say the same thing we say, and two of them said it decades earlier. Galbraith (1960s), BIZBOK's organization map ("beyond the confines of a company's organizational chart"), and OMC ("the org chart shows structure only") each open with the argument the Organizational Platform opens with — "an org chart shows who reports to whom; it says almost nothing about how the work actually gets done." This is not a problem; it is validation with a caveat. The claim is not our differentiator and should not be pitched as an insight. What is differentiated is the pricing spine (title→SOC→OEWS loaded rate) — none of these three frameworks price anything.
• Contradiction: BIZBOK would say our derivation runs backwards. The Guild is explicit that "capabilities are identified through a business' value streams." Our 10 functions were derived from an internal structure draft plus a Kwik Trip reality check — a departmental/organizational starting point, not a value-delivery one. BIZBOK would call that an org-chart-shaped map. The defensible answer is that we are not building a capability map (see below) — but that answer only holds if we stop describing functions as "what the business does."
• Contradiction on levels: BIZBOK does not endorse a fixed depth, and neither should we. The metamodel's stance is invariance-under-decomposition, not a level count; the DEFER.L3_EMERGENCE note in function-rules.yaml ("L1 + L2 are universal; L3 emerges per client") is more disciplined than a numbered-level convention, and BIZBOK's capability-instance concept is the theoretical backing for it. Convergence in substance, divergence in vocabulary.

Synthesis for RDCO

The headline: a function is not a BIZBOK capability, and a motion is not a value stream — but the Organizational Platform is a BIZBOK organization map, and that is a better home than either. Test the words against the Guild's own definitions. A capability is object-focused, noun-formed, singular per ecosystem, and derived from value streams. Our functions are Sales, Marketing, Service, Operations, Supply Chain, Finance, HR, IT, Product, Legal & Risk — the standard department set. They are not object-focused (FN.OPERATIONS has no single business object; FN.IT has "technology" only by stretching), and they were derived from organizational structure, not from value delivery. Calling them capabilities would be wrong on BIZBOK's own terms. Meanwhile BIZBOK's organization domain — the fourth core domain, whose artifact is literally called the organization map, whose stated job is to show "how an organization works, rather than how an executive might think it works" — is an almost exact description of what we are building and what we already named the deliverable. Cite that lineage rather than reaching for "capability." The one honest gap: BIZBOK's organization map is populated with a specific client's business units, whereas our platform level holds normalized work-domain types that a client's real units instantiate. We are a typed reference layer above BIZBOK's organization map. That is a legitimate extension, and it is worth saying out loud in the platform's content sections rather than leaving readers to wonder which BIZBOK box we are in.

On motion, the prior in the dispatch survives the test — and the refutation attempt sharpened it. A value stream is end-to-end, has exactly one value proposition, is triggered by a stakeholder, and decomposes into ordered verb-noun stages that cross functions. Field sales, inside sales, retail/store, DTC/ecommerce and partner/channel are none of those things: they are five alternative ways to run the same broad value proposition, they are function-bounded by construction (function: FN.SALES is a required frontmatter field), they decompose downward into seats rather than forward into stages, and they carry no triggering stakeholder. Motion is not a value stream. But it is also not simply "an operating-model variant" with no framework anchor — BIZBOK has a concept for exactly this shape and almost nobody uses it: capability behavior ("the way in which a capability acts or conducts itself in certain circumstances") realized as capability instances. The difference is that BIZBOK's instances are client-specific and untyped — the Guild expects you to discover them per business unit. Our motions are those behaviors, named once, typed, and made reusable across clients. That is the platform's genuine contribution and it should be stated in exactly those terms; it converts "motion" from a coined word into a positioned one. The Operating Model Canvas corroborates from the other side: what actually distinguishes field sales from inside sales from ecommerce is a bundle of Location (customer site / call centre / none), Organization (structure and span), and Information (CRM vs storefront vs partner portal) — three of the six POLISM elements. A motion is, functionally, a POLISM configuration preset scoped to one function. That gives us a concrete build item, not just vocabulary: motion frontmatter today carries only id, name, function, added. The single highest-value addition to the pending hand-section template is a short, structured "how this motion is configured" block — where the work happens, what systems carry it, what the org shape looks like — because that is the content that makes a motion mean something rather than merely name something.

The most borrowable thing in the whole brief is BIZBOK's object-focus invariance rule, and applying it immediately finds defects in the live tree. The rule: any decomposition of a parent must not change the parent's object in focus. Run it against our 36 motions and three flags surface. (1) FN.OPERATIONS.REAL_ESTATE (real estate & facilities development) introduces a new object — property — that Operations does not otherwise hold; it was added by ruling to close a Kwik Trip coverage gap, and it is the tree's weakest node by BIZBOK's test. (2) FN.OPERATIONS.MAINTENANCE (maintenance & facilities) and FN.OPERATIONS.REAL_ESTATE both claim "facilities" in their names — overlapping object scope between siblings, which BIZBOK's one-and-only-one-set discipline treats as a defect to resolve, not a naming quirk. (3) FN.IT.SECURITY's object is arguably risk, which is FN.LEGAL_RISK's object; the platform already hedges this by titling the function "IT (incl. Security)". None of these are fatal, and at least one may be the right pragmatic call — but each should be recorded as a knowing exception rather than discovered later by a client. The second borrowable rule is sibling homogeneity ("capability principles, structure, and performance remain consistent at every level of hierarchical decomposition"): under Operations, "Core production" is a deliberately abstract slot per PRINCIPLE.CORE_PRODUCTION_ABSTRACT while its three siblings are concrete named motions. That is level mixing on BIZBOK's terms. It is probably the correct design — the abstract slot is what makes the taxonomy industry-portable — but it means the abstract-slot pattern is a declared architectural exception, and the content template should say so, because a business architect reading the tree will spot it in ten seconds.

On Galbraith: the answer to "is the map missing design dimensions" is no for the map and yes for the assessment, and the house rule already draws the line correctly. The Star's five points are Strategy, Structure, Processes, Rewards, People, and its whole purpose is to judge fit among them — it is a diagnostic and design instrument, not a description. "Maps describe, Assessments judge" is precisely the boundary that keeps rewards and people-practices out of the Organizational Map: comp plans and promotion practices are not observable at map-building time, and pulling them in would turn a describable artifact into a consulting judgment nobody asked for. But the Star does expose one gap that is describable and is missing: decision rights. Galbraith's structure point is not headcount, it is "the location of decision-making power." The Map records who sits in which seat under which motion at what loaded rate — it does not record who can approve a change. For a platform whose downstream deliverable is workflow Upgrades, that omission bites: the Upgrade recommendation needs to name the person who can authorize it, and today the Map cannot answer that. Decision rights are observable in discovery, they describe rather than judge, and they belong on the seat. Rewards and people-practices should stay out of the Map and instead become a risk checklist item in the OIP Upgrade path — "this Upgrade changes what a seat does; whose incentive system does it touch?" — which is where Galbraith's alignment claim actually earns its keep.

Per-framework borrow-vs-build verdict

Consolidated vocabulary table

Why this is in the vault

This brief is the input to a specific, imminent decision: the Organizational Platform's README.md states that "the hand-section template locks at exemplar time, after the framework-research round," and the content sections for 10 function pages and 36 motion pages are held unwritten pending it. Three of the findings change what that template should contain — a configuration block on motion pages (from OMC), an object-focus admission test and a declared-exception note for the abstract-slot pattern (from BIZBOK), and a decision-rights attribute on seats (from Galbraith). It also settles the naming question that would otherwise surface mid-engagement at Kwik Trip, where the Organizational Platform and the Intelligence Platform are presented to the same stakeholders and "capability" can only mean one thing.

Open follow-ups

• Does the BIZBOK Guide's capability chapter name explicit failure modes for leveling — and specifically does it warn against process verbs leaking into capability names? The metamodel guide gives the invariance rule but no failure-mode catalogue; the noun/verb convention I found is secondary only. The chapter is member-gated. Worth resolving whether Guild membership is worth buying for one chapter, or whether a public Guild conference deck covers the same ground.
• Is there any published framework that types delivery-pattern variants the way "motion" does — a named, reusable, cross-company catalogue of how a function is run? BIZBOK's capability instance is untyped, OMC's configurations are per-organization. If the answer is genuinely no across BIZBOK, OMC, Galbraith, and the industry reference models the sibling briefs cover, that is a defensible originality claim; if a niche literature exists (operations strategy, service design, channel strategy), we should know its vocabulary before coining ours.
• What does BIZBOK's own retail / convenience-industry reference model contain, and does its capability set collide with or corroborate our 10 functions? The metamodel guide states the Guild publishes industry reference models including manufacturing, telecom, transportation, and "a common" model. If a retail-adjacent one exists and is obtainable, it is the closest thing to an external validation set for the Kwik Trip instantiation.
• How do practitioners actually resolve the case where a decomposition legitimately needs to change object focus — is there a sanctioned pattern (shared capability, cross-mapped capability, a second parent), or does BIZBOK simply forbid it? This decides whether FN.OPERATIONS.REAL_ESTATE is a recorded exception or a modelling error we should fix.

Related

Filed the same night, same research round — and they do not fully agree. [[2026-08-17-apqc-pcf-function-motion-mapping]] · [[2026-08-17-gtm-motion-origins-industry-reference-models]]. The disagreement that matters: this brief concludes the founder's prior survives the test and proposes a configured-as frontmatter block (location / systems / org shape); the GTM sibling concludes only 2 of 10 functions carry true motions and proposes a different amendment, axis: substitutable | sub_function plus a variants: list. Two competing schema proposals, neither written with knowledge of the other, both landing before the content template locks. The GTM sibling also carries a VERIFICATION STATUS: ITERATE (hard) banner — its 2-of-10 verdict is explicitly not yet safe to act on, which is relevant to how much weight it should take against this one.

• [[2026-06-29-ai-capability-org-structures]]
• [[2026-06-14-caf-restructure-organizing-brief]]
• [[2026-08-03-people-and-org-info-guidelines]]
• [[2026-05-13-dorsey-from-hierarchy-to-intelligence-block-mini-agi]]
• [[2026-06-15-caf-architecture-decisions-and-meta-council]]

Sources

Primary (fetched and read in full):

• Business Architecture Guild, The Business Architecture Metamodel Guide v3.0, September 2024 — https://cdn.ymaws.com/www.businessarchitectureguild.org/resource/resmgr/whitepapers/business_architecture_metamo.pdf (WebFetch extraction failed; full text recovered locally via pdftotext -layout and read at §4, §5.1, §5.2, §5.3, §5.4, and the business-process association section)

Primary-adjacent (fetched):

• Galbraith Management Consultants, "Star Model" — https://jaygalbraith.com/services/star-model/
• Van Haren Group (publisher of the OMC book), "Operating Model Canvas in 3 minutes" — https://www.vanharen.net/standards/operating-model-canvas/operating-model-canvas-in-3-minutes/

Secondary (search-result summaries only — not individually fetched; used for the noun/verb naming convention and level-1/level-2 practice, both flagged inline as unverified against Guild primary text):

• BPMInstitute, "Capabilities & Value Streams: Business Architecture's Essential Alliance" — https://www.bpminstitute.org/resources/articles/capabilities-value-streams-business-architectures-essential-alliance/
• Bizzdesign, "Business Architecture Redefined: Mapping BIZBOK® to ArchiMate®" — https://bizzdesign.com/blog/business-architecture-redefined-mapping-bizbokr-archimater
• BusinessAnalystMentor, "Introduction to Capability Mapping" — https://businessanalystmentor.com/capability-map/
• Umbrex, "Ashridge POLISM & Operating Model Canvas" — https://umbrex.com/resources/frameworks/organization-frameworks/ashridge-polism-operating-model-canvas/
• Umbrex, "Galbraith Star Model | Org Design & Operating Model" — https://umbrex.com/resources/frameworks/organization-frameworks/galbraith-star-model/
• Strategic Management Insight, "Galbraith's Star Model Explained in Depth" — https://strategicmanagementinsight.com/tools/galbraiths-star-model-explained/

Not read (flagged, not fabricated):

• A Guide to the Business Architecture Body of Knowledge® (BIZBOK® Guide) — Business Architecture Guild member-gated
• Campbell, Gutierrez & Lancelott, Operating Model Canvas (Van Haren, 2017) — book not read
• Galbraith, Designing Organizations — book not read

Working-tree files consulted (phData-internal, not vault paths):

• organizational-platform/README.md, spec/02-organizational-platform.md, spec/schemas/function-rules.yaml, intelligence-platform/README.md