Knowledge Graphs and GraphRAG: When Structure Beats Search (Copy)
Every time a large bank or telecommunications company starts a business architecture program, the same question surfaces early: should we build our capability map and process model from scratch, or should we start from the industry reference model that already exists for our sector?
The question sounds like it should have an obvious answer. An industry reference model represents decades of accumulated knowledge from dozens of organizations that have already solved the mapping problem. Starting from it should be faster, cheaper, and more likely to produce a model that is recognizable to vendors, regulators, and partners who use the same vocabulary. Why would anyone build from scratch?
The honest answer is that industry reference models are genuinely valuable in specific conditions and genuinely counterproductive in others, and the organizations that get the most from them are the ones that understand the difference rather than adopting wholesale or rejecting wholesale. Understanding what BIAN and eTOM actually are, what they do well, where they fall short, and how to make the adoption decision intelligently is what this post is about.
What Industry Reference Models Are and Are Not
An industry reference model is a pre-built architecture artifact, a capability map, a process framework, a data model, or a combination, developed collaboratively by an industry body whose members include organizations with domain expertise in the relevant sector. The artifact represents a consensus view of what organizations in that industry need to be able to do, how their processes are structured, and how their information is organized.
The key word is reference. A reference model is a starting point, not a prescription. It describes what is common across organizations in the sector, not what is optimal or differentiated for any specific organization. A bank that implements BIAN exactly as published will have an architecture that describes what all banks do in common. It will not have an architecture that describes what makes that bank different from its competitors, what its specific operating model choices are, or how its particular history of acquisitions and technology decisions has shaped its current capability landscape. The reference model is the floor. The organization's specific architecture is what gets built on top of it.
This distinction matters because organizations frequently misuse reference models in one of two ways: treating them as prescriptive designs that must be implemented in full, which produces compliance overhead without proportional value, or treating them as external artifacts that do not apply to the specific circumstances of their organization, which forgoes the genuine acceleration they provide. The right relationship is deliberate selection of the reference model elements that are genuinely applicable and meaningful adaptation of those that are not.
BIAN: The Banking Industry Architecture Network
BIAN is a global consortium of banks, technology providers, and service firms that develops and maintains a standardized reference architecture for banking. Now at version 13, with formal expression in the ArchiMate modeling language, BIAN has evolved from a conceptual framework into a production-ready architecture reference that integrates with major enterprise architecture tooling platforms.
The core of BIAN is its Service Landscape: a structured map of banking capabilities organized as service domains, the discrete, non-overlapping business capacity units that make up a complete banking operation. The service domains cover the full scope of banking activity from retail and corporate banking through risk and compliance, operations and execution, and management and support functions. Each service domain is defined with a consistent semantic structure: a control record that describes the domain's primary data object, a set of behaviors the domain supports, and the service operations through which the domain interacts with other domains.
The value proposition of BIAN for banks undertaking architecture work or modernization programs is specific and well-documented. Tech Mahindra's 2026 analysis of BIAN adoption describes its primary benefit precisely: it provides a common language that reduces fragmentation, enables interoperable API-first integration, and provides governance guardrails for incremental modernization. That common language is valuable in two directions. Internally, it allows business and technology teams to discuss capability requirements without the translation friction that arises when different functions use different vocabulary for the same banking activities. Externally, it aligns the organization's architecture vocabulary with that of its vendors and technology partners, most of whom map their products and services to BIAN service domains in their product documentation and sales processes.
The limitation of BIAN that organizations consistently discover in practice is that it is a semantic framework rather than an operational one. BIAN defines what banking service domains are and how they relate to each other. It does not specify how a specific bank should organize its operating model, allocate accountability, prioritize investment, or sequence its transformation program. An organization that expects BIAN to answer those questions will be disappointed. An organization that uses BIAN as the vocabulary for its capability map while making its own operating model and investment decisions will find it genuinely useful.
BIAN is also comprehensive to the point of being overwhelming as a starting point. The full Service Landscape covers several hundred service domains across six capability areas. An organization attempting to map its architecture to all of BIAN simultaneously will spend more time on mapping than on the transformation work the mapping was supposed to enable. The practical approach is to identify the three to five capability areas most relevant to the current transformation program and engage with BIAN at that scope, expanding the coverage incrementally as the program advances.
eTOM: The Enhanced Telecom Operations Map
eTOM is the business process framework maintained by the TM Forum for telecommunications service providers. Now at version 25.0, released in November 2025, it is the de facto standard for telecom process architecture globally and one of the most mature industry reference models in existence.
Where BIAN is organized around service domains and capability concepts, eTOM is organized around business processes, described at multiple levels of abstraction from the strategic to the operational. The framework's three primary areas, Strategy, Infrastructure and Product; Operations; and Enterprise Management, cover the full scope of telecom operations from customer-facing service delivery through network management, partner and supply chain management, and corporate functions. Each area is decomposed hierarchically through process groups, processes, and sub-processes, with the level of detail selectable based on the architectural purpose.
eTOM's primary value for telecom organizations is in process standardization and interoperability. A telecom operator that uses eTOM process terminology in its vendor contracts, system integrations, and operational documentation can communicate unambiguously with its technology suppliers, managed service partners, and industry peers who use the same vocabulary. The reduction in translation overhead across these interfaces is the concrete, measurable benefit that makes eTOM adoption worthwhile in the sectors where it is genuinely applicable.
eTOM is part of the TM Forum's broader Frameworx suite, which also includes the Shared Information Data model for data architecture and the Application Framework for application portfolio mapping. Organizations that use eTOM alongside these companion frameworks gain a more complete architectural reference. Organizations that use eTOM in isolation for process documentation without connecting it to data and application architecture will get less value from the investment in learning the framework.
The limitation that academic research on eTOM consistently identifies is that the framework provides a hierarchical taxonomy of processes rather than end-to-end process flows. It describes what processes exist and how they relate structurally, but it does not specify the sequential logic that connects them into value-delivering workflows. Organizations that need both the structural taxonomy and the end-to-end flow design need to extend eTOM with their own process flow documentation, which requires additional effort that is not always anticipated at the outset of an eTOM adoption program.
Other Industry Reference Models Worth Knowing
BIAN and eTOM are the most mature and widely adopted industry reference models, but they are not the only ones. Several other sectors have developed reference models that are worth knowing for organizations operating in those domains.
| Model | Sector | Primary Focus | Maintained By |
|---|---|---|---|
| BIAN | Banking and financial services | Capability and service domain reference architecture | Banking Industry Architecture Network |
| eTOM / Frameworx | Telecommunications | Business process framework for service providers | TM Forum |
| ACORD | Insurance | Data standards and process reference for insurance transactions | ACORD (Association for Cooperative Operations Research and Development) |
| ARTS | Retail | Data model and process reference for retail operations | National Retail Federation |
| HL7 / FHIR | Healthcare | Data interoperability standards for health information exchange | Health Level Seven International |
| APQC PCF | Cross-industry | Process classification framework applicable across sectors | American Productivity and Quality Center |
| SCOR | Supply chain | Process reference model for supply chain operations | Association for Supply Chain Management |
When to Use an Industry Reference Model
The decision to adopt an industry reference model should be driven by the specific work being done rather than by a general preference for standards or for organizational uniqueness. The conditions where reference model adoption consistently produces more value than custom development are specific and worth naming precisely.
When the primary deliverable is a common vocabulary rather than an analytical model. The most consistently valuable use of industry reference models is as a shared language for conversations between teams, functions, vendors, and partners who would otherwise use different terminology for the same concepts. A bank that can tell its core banking vendor that it needs the Loan Processing service domain to support specific behaviors described in BIAN vocabulary will have a more productive vendor conversation than one that uses internally invented terminology that the vendor needs to translate. The vocabulary benefit does not require implementing the full reference model. It requires adopting its naming conventions consistently in the specific areas where cross-organizational communication is happening.
When the work is in a domain where most capabilities are commodity rather than differentiating. Industry reference models describe what organizations in a sector have in common. For capability areas that are genuinely commodity, where the organization's competitive differentiation does not depend on doing them differently from the industry standard, the reference model's definition is likely to be accurate and sufficient. Using the reference model in these areas avoids custom design work that adds cost without adding strategic value. The question to ask for each capability area is: does our competitive position depend on doing this differently from the reference model's description? If the answer is no, the reference model definition is probably good enough.
When system integration with vendors and partners requires a shared architecture language. Many banking technology vendors map their products to BIAN service domains. Many telecom technology vendors map their products to eTOM process areas. When an organization's architecture uses the same reference model vocabulary as its vendor ecosystem, the mapping work required to connect architecture decisions to vendor capabilities is significantly reduced. This is a practical integration efficiency that is easy to underestimate at the point of the adoption decision and very visible in the day-to-day work of architecture and procurement teams.
When the organization is starting its architecture practice and needs a validated starting point. Building a capability map or process model from scratch requires the team to make hundreds of naming and scoping decisions that an industry reference model has already resolved. For an organization starting its architecture practice, using a reference model as the starting point accelerates the initial mapping work significantly and produces an artifact that is more likely to be recognizable to external practitioners. The custom tailoring that the organization's specific circumstances require can be applied incrementally on top of the reference model foundation rather than being invented from scratch.
When Not to Use an Industry Reference Model
The conditions where reference model adoption creates more friction than value are equally specific.
When the organization's business model differs significantly from the sector norm. Reference models describe the consensus view of what organizations in a sector do. Organizations with genuinely differentiated business models will find that significant portions of their capability landscape are not well-described by the reference model, and that forcing their architecture into the reference model's structure requires either misrepresenting their actual operations or maintaining a complex mapping between the reference vocabulary and their actual business vocabulary. A bank with a highly distinctive distribution model or a telecom operator with a diversified portfolio that extends well beyond traditional connectivity services may find that the reference model covers only a portion of what they need to map.
When the immediate architectural purpose is strategic differentiation rather than standardization. Reference models describe industry common ground. Strategic architecture work is often about defining how an organization will be different from the industry norm, which capabilities it will develop beyond the standard, and how it will organize them to create advantages that competitors using the same reference model cannot easily replicate. A capability map used for strategic investment prioritization needs to reflect the organization's specific strategic choices, not the industry average. The reference model can provide the baseline layer of commodity capabilities; the strategic layer needs to be built from the organization's own strategic intent.
When adopting the reference model requires organizational energy that exceeds the value it provides. Industry reference models are large, detailed, and require significant investment to learn and apply consistently. For organizations undertaking focused, time-pressured architecture work on a specific problem, the overhead of learning a comprehensive reference model may exceed the value of the common vocabulary it provides in that specific context. A targeted custom capability map built for a specific decision in eight weeks may be more valuable than a BIAN-aligned capability map that takes six months to build correctly.
The Adoption Pattern That Works
The organizations that extract consistent value from industry reference models share a specific adoption pattern that avoids both the failure mode of wholesale adoption and the failure mode of wholesale rejection.
They begin with the reference model as a checklist rather than a template. The reference model's scope is used to verify that the custom architecture work has not missed significant capability areas or process domains. The reference model's vocabulary is used wherever it is accurate and accessible. Where the reference model's definitions do not match the organization's actual operations or vocabulary, the organization's own definitions take precedence and the mapping to the reference model is documented for integration purposes rather than imposed as a naming requirement.
They apply the reference model selectively to the domains where its benefits are highest, typically the commodity capability areas and the vendor and partner integration interfaces, and build custom architecture in the areas where the reference model's common-ground perspective does not serve the organization's specific strategic and operational context.
And they treat reference model alignment as a means to specific ends rather than as an end in itself. The purpose of using BIAN is to accelerate capability mapping, simplify vendor conversations, and provide a governance foundation for modernization. The purpose of using eTOM is to standardize process vocabulary across a complex integration landscape and align with partner and supplier communication. When the reference model is serving those purposes, it is earning its adoption cost. When it is generating compliance overhead without producing those specific benefits, it is not.
Talk to Us
ClarityArc's business architecture practice works with industry reference models including BIAN and eTOM as tools rather than constraints, applying them where they add genuine value and building custom architecture where they do not. If you are deciding whether to adopt an industry reference model or trying to make better use of one you have already adopted, we are ready to help.
Get in Touch