06-reference/research

multi axis decomposition reference models

2026-08-28·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
reference-modelsetomtaxonomyorganizational-platformschema-design

eTOM carries two named axes at once, states in its own text why the second one cannot be a tree, and then fails to publish it — so the constraint is real, narrow, and not the one we were about to write into the spec

Acronyms expanded once: eTOM = Enhanced Telecom Operations Map, TM Forum's business process framework, republished by ITU-T as the M.3050.x sub-series. FAB = fulfilment, assurance, billing. OSR = operations support and readiness. CRM = customer relationship management. SIP = eTOM's strategy, infrastructure and product process area. PCF = APQC's Process Classification Framework. CIMOSA = Computer Integrated Manufacturing Open System Architecture, the basis for ISO 19439.

The question

Verbatim, from the Notion Research Backlog:

"Does any process/capability reference model carry two decomposition axes simultaneously as separately named dimensions — or is single-axis decomposition a hard constraint of process-framework tooling?"

Context: this is the third follow-up filed by [[2026-08-23-etom-per-function-motion-catalog]], provoked by three mature frameworks cutting Sales three different ways with no overlap. It is load-bearing because spec/00-template-decisions.md D-1 deferred rather than rejected the axis: field, and the 36-motion vocabulary is about to lock.

Answer, up front: yes, and the affirmative case is eTOM itself, which the parent brief read in full without recognizing it. eTOM defines two separately named, simultaneously applied Level-1 dimensions ("functional process groupings", shown horizontally; "end-to-end process groupings", shown vertically), calls their overlay "the inherent matrix structure of the eTOM framework", and specifies a process-ID format that reserves a dedicated slot for the second axis. So single-axis decomposition is not a modelling constraint and should not be written into the spec as one. But eTOM's own text states the exact constraint that does bind, and then demonstrates it: because "in any taxonomy each element must be unique", only ONE axis can be the parent hierarchy and the other has to be an overlay — and across 208 pages of primary text the published IDs use the one-axis numeric form 384 times and the two-axis letter form zero times. The second axis survives only as a parenthetical tag in prose. That is a tooling constraint caught in the act of biting, and it points the D-1 decision somewhere different from where either option was pointing.

Source tiers

Tier What Status
A — primary, fetched and read this session ITU-T Rec. M.3050.1 (03/2007) eTOM – The business process framework (= TMF GB921 R7.0); ITU-T Rec. M.3050.2 (03/2007) eTOM – Process decompositions and descriptions, 208 pp Downloaded as PDF from itu.int over plain curl, text-extracted with pdftotext -layout. Every eTOM quote and every count below is verbatim from that extraction
A — primary, local artifact organizational-platform/02-functions/*.md and 03-motions/*.md in the phData OI repo Read directly. The axis-heterogeneity observation is my inference from node names and page prose, not a claim the repo makes about itself
B — secondary description of a paywalled standard ISO 19439:2006 Enterprise integration – Framework for enterprise modelling (three named dimensions) Encyclopaedic and vendor summaries via WebSearch. The standard itself is paywalled and was not read. Treat the three dimension names as reliable and any detail below that as not verified
B — secondary, primary gated ArchiMate core framework (layers × aspects) pubs.opengroup.org now sits behind an Open Group SSO redirect; both 3.0 and 3.1 chapter 3 URLs bounce to identity.opengroup.org. Structure taken from secondary tutorials. Flagged, not retried
B — established theory, secondary Ranganathan's faceted classification / colon classification; enumerative vs faceted Secondary summaries. The claim used here is uncontroversial and does not need primary text
Via vault SCOR DS practice-overlay mechanism; APQC Retail PCF store subtree Not re-fetched. Cited from [[2026-08-27-scor-ds-make-to-order-variants]] and [[2026-08-26-apqc-retail-pcf-store-channel-decomposition]], both of which read their own primaries

What we already know (from the vault)

What the web says

1. eTOM defines two dimensions by name, in its terminology section, and crosses them (Tier A)

M.3050.1 §3.13, the definitional entry for the first axis:

"functional process groupings: The functional process groupings (e.g., customer relationship management, service management and operations, etc.) aggregate processes involving similar knowledge. The eTOM functional process groupings are the highest level decomposition of the enterprise. Functional process groupings are shown horizontally in eTOM… Also termed as horizontal process grouping(s)."

M.3050.1 §3.7, the second axis, given its own definitional entry:

"end-to-end process grouping: The top-level view of the eTOM framework shows end-to-end process groupings… these groupings represent processes that have end-to-end results that are key measures for the enterprise. Also termed as vertical process grouping(s)."

Both are Level 1, explicitly and simultaneously. M.3050.1 §3.17:

"• Each vertical (end-to-end) process grouping is level 1. • Each horizontal (functional) process grouping is also level 1. • All the process elements, e.g., order handling (which appear in the end-to-end process and the functional process groupings) are level 2."

And the crossing is named as the framework's central innovation (M.3050.1 §6.1.2):

"The overlay of the horizontal functional process groupings and the vertical end-to-end process groupings forms the inherent matrix structure of the eTOM framework. This matrix structure is the core of one of the innovations and fundamental benefits of the eTOM framework."

Counts, from the same clause: seven Level-1 vertical end-to-end groupings (strategy and commit, infrastructure lifecycle management, product lifecycle management, OSR, fulfilment, assurance, billing) crossed with eight Level-1 horizontal functional groupings in four layers. This is a true cross-classification, not two separate models: both dimensions partition the same scope at the same level, and the Level-2 elements are the cells.

This is a decisive negative on the "hard constraint" hypothesis. One counterexample is enough, and it comes from a framework already in the quartet.

2. eTOM also states the constraint that IS real, and names its cause (Tier A)

M.3050.1 §6.1.2, immediately before the matrix passage:

"It has been developed as a structured catalogue or hierarchical taxonomy of process elements which can be viewed in more and more detail. Since in any taxonomy each element must be unique, it was decided from the start that the primary top-level hierarchy of process elements would be the functional (horizontal) groupings. The end-to-end process (vertical) groupings are arranged as an overlay on the horizontal groupings."

"When viewed in terms of the horizontal functional process groupings, the eTOM business process framework follows a strict hierarchy where every element is only associated with or parented to a single element at the next higher hierarchical level… These vertical end-to-end process groupings are essentially overlays onto the hierarchical top-level horizontal groupings because, in a hierarchical taxonomy, an element cannot be associated with or parented to more than one element at the next higher level."

So the constraint is not "one axis". It is "one parent axis". Everything else has to be expressed as an overlay. That is precisely the unique-parent rule of a tree, and it is a property of the representation, not of the domain.

There is a second, less obvious cost stated in the same clause:

"These vertical and horizontal process groupings represent alternative views relevant to different concerns about the way that processes should be associated. Note that we will see that these alternatives have been selected to yield a single common view of the level 2 processes defined at the next level of decomposition, and hence do not represent a divergence in the modelling."

Read that carefully. The two axes only work because they were co-designed to bottom out in one shared set of Level-2 elements. eTOM did not build a tree and then bolt a second axis onto it. The cell set was derived from both axes at once. That is the difference between a matrix framework and a tree with tags, and it is the reason a second full partition cannot be retrofitted cheaply.

3. eTOM specifies a two-axis identifier and then never publishes one (Tier A)

M.3050.2 §5 defines the process ID format as aaaaaa.b.XXXX.c.d.e, where:

"XXXX: These letters (up to 4 letters) are used to identify level 1 vertical end-to-end processes… S for strategy and commit; I for infrastructure lifecycle management; P for product lifecycle management; O for operations support and readiness; F for fulfilment; A for assurance; B for billing; E for enterprise management. Note that for processes spanning more than one vertical process, the combination of letters representing those vertical processes is used (for example, 'customer interface management' uses FAB)."

"c: Digit representing level 1 process. d: Digit representing level 2 process. e: Digit representing level 3 process."

That is a coordinate identifier: c.d.e is the path down the primary tree, XXXX is the position on the second axis, and the second axis is explicitly many-valued per element (FAB = a member of all three verticals at once). It is faceted classification with a compound notation, in a telecom standard, in 2007.

Then the publication drops it. Across the 208 pages of M.3050.2 I counted 384 occurrences of the one-axis numeric ID form (1.1.1.4, 1.2.1.6.2, and so on) and zero occurrences of the two-axis letter form. The vertical dimension survives in exactly two degraded ways: a parenthetical note explained once in §5 —

"each level 2 and level 3 process described here has an associated indication of its positioning within the particular vertical and horizontal level 1 process… For example, CRM operations support and process management… has the indication (CRM-OSR)"

— and as loose prose ("the individual SM&O FAB processes", "CRM FAB processes", eight such mentions). And §6 concedes the organizing choice outright: "This Recommendation is organized using the horizontal functional process groupings as the prime categorization for the SIP and OPS process areas."

The reason given for the collapse is graphical and editorial, not conceptual (M.3050.2 §5): the full matrix "is too graphically complex a picture to be used directly. Once level 3 processes are included, a single figure becomes quite impractical."

That is the tooling constraint, isolated. The model is two-dimensional. The document, the numbered outline, and the diagram are one-dimensional, and the document format wins.

4. Multi-dimensional decomposition is standardized elsewhere, at three dimensions (Tier B)

5. What nobody does (Tier A/B mixed, stated as a limit)

I found no reference model that publishes two co-equal parent hierarchies over the same elements. Every affirmative case is one primary tree plus one or more overlays, or a pre-derived cell grid. That distinction is the whole finding: "carries two axes" is true of several frameworks; "carries two axes as two trees" is true of none of them, and eTOM says why in one sentence.

Convergences and contradictions

Synthesis for RDCO

Separate the two claims, because the spec is about to record one of them and only one is true.

The modelling claim — that a process or capability model cannot express two decomposition axes simultaneously — is false, and it is false against a source already in our quartet. eTOM names both dimensions in its terminology section, applies both at Level 1, calls the crossing its core innovation, and specifies an identifier with a slot for each. ISO 19439 goes to three dimensions. Faceted classification has answered this since the 1930s. If the spec is going to justify staying single-axis, it must not use "reference models can't do this" as the reason, because a client with an architecture background can open a free ITU-T PDF and find the opposite sentence in twenty minutes.

The tooling claim is true, narrower, and much more useful. The binding constraint is the unique-parent rule of a hierarchical taxonomy plus the one-dimensionality of the artifacts a taxonomy ships in: a numbered outline, a spreadsheet, a folder of markdown files. eTOM demonstrates the whole failure mode inside one document set. It defines a two-axis ID, declares the matrix its central benefit, then publishes 384 one-axis IDs and zero two-axis ones because the full grid "is too graphically complex a picture to be used directly." The second dimension degrades into a parenthetical. Our repo is 36 markdown files in one directory with FN.FUNCTION.MOTION in the filename. It is a strictly weaker container than eTOM's, and it will lose the second axis faster and more quietly.

So the D-1 call: revisit before the lock, but not to add axis: to motion frontmatter. Three moves, in order of how cheap they are.

First, and this is the one I would do regardless of everything else: declare the cut. eTOM names its axes in its definitions clause. The Organizational Platform names none, and by inspection the 36 motions are already cut on at least five different axes. Sales splits by channel (DTC / field / inside / partner / retail). Finance splits by work type (AP-AR / FP&A / tax-treasury). IT splits by managed asset (applications / data-analytics / infrastructure / security). Operations splits by object (core production / maintenance / quality control / real estate). Supply Chain splits by supply-chain stage (procurement / inventory / distribution). That heterogeneity is probably fine and may even be correct, since different functions genuinely have different natural cuts. What is not fine is that it is undeclared, because it means "motion" does not mean the same thing on two adjacent pages of the same artifact. FN.SERVICE is the sharp case: contact-center and field-service are channels, success is a relationship stage, and the function page itself hedges them as "complementary lanes more than alternatives" in body prose rather than in a field. One cut_by: line per function page, ten edits, no id changes, fully reversible. It is the same fix fn-it-security.md is already hand-rolling in a sentence. (The five-axis reading is my inference from node names and page text, not a claim the repo makes. It is the first thing to check before acting.)

Second, close the axis: deferral rather than extending it, by folding it into the overlay artifact. [[2026-08-27-scor-ds-make-to-order-variants]] already recommended a variant page with id, definition, source, confidence and applies_to:. eTOM's XXXX letter code is the same construct with a shorter name, including the many-valued case (FAB), and eTOM reached it for the same stated reason. Generalize that page one notch: give it a dimension: field naming which axis it belongs to (pipeline-stage, customer-type, fulfilment-strategy, circularity), so the artifact can carry several second axes rather than one anonymous variant list. Then axis: substitutable | sub_function is not deferred, it is answered: substitutability is a property expressed by an overlay's applies_to: breadth, not a boolean on a tree node. That converges the two open schema threads into one decision instead of leaving both dangling past the lock.

Third, be explicit about what we are giving up, because it is not nothing. eTOM's matrix works because both axes were selected "to yield a single common view of the level 2 processes" — the cells were derived from both dimensions at once, so the two views do not diverge. Our 36 motions were not derived that way; they were assembled function by function from practitioner vocabulary. That means a true second partition is not a schema addition, it is a re-derivation of the motion layer, and an overlay is genuinely cheaper rather than merely more convenient. Say that in the spec. "We run one primary axis because a taxonomy element can have only one parent, and a second full partition would require re-deriving the motion set as cells of both" is a defensible sentence with a citation behind it. "Nobody does two axes" is not.

Confidence. High on the literature question, and I would defend it in front of a client: primary text, unambiguous wording, both dimensions defined by name in the same clause, verified counts. Medium-high on the schema recommendation, because the second and third moves depend on the 8/27 variant-page proposal being adopted and that decision is itself unmade. Medium on the five-axis heterogeneity read, which is my inference from 36 filenames and ten function pages and which the founder can overturn by inspection in five minutes.

What would change it. If the 36 motions turn out to be one consistent axis under a definition I have not seen, move one collapses and moves two and three stand unchanged. If a live engagement needs two axes queryable together rather than one primary plus a filter, the overlay is insufficient and the matrix cost re-enters, at which point the honest move is to re-derive the motion layer rather than nest. And if TM Forum's current GB921 has abandoned the matrix in the Domain restructure, the 2007 evidence weakens as a live precedent while remaining a valid existence proof — the parent brief's first open follow-up already covers that fetch.

Why this is in the vault

It answers the third open follow-up of [[2026-08-23-etom-per-function-motion-catalog]] with a primary-text counterexample, and it does so before the 36-motion vocabulary locks in organizational-platform/03-motions/. Concretely, it converts spec/00-template-decisions.md D-1 from a deferral into a closable decision by supplying the mechanism (overlay, not parent axis), the citation that makes staying single-axis defensible in a client room, and a ten-edit cut_by: change that should land before the lock rather than after.

Open follow-ups

Related

Sources

Tier A — primary documents, fetched and read this session

Tier B — secondary descriptions; primary gated or paywalled

Via vault, not re-fetched