Reference Model

Definition

A reference model is an abstract, generic representation of a domain — most commonly a set of business capabilities, processes, or data concepts — developed independent of any single organization's structure, technology, or terminology. In business architecture, the most widely used reference models are industry capability maps: pre-defined groupings of what a bank, insurer, telecom, or hospital system does, organized in a hierarchy that reflects common industry patterns rather than any one company's org chart. A reference model is deliberately generic. It is not the finished deliverable; it is scaffolding. Architects take the reference model and cross-map it against the organization's actual operations, rename elements to match internal language, prune capabilities that don't apply, and add ones unique to the business. The output — a tailored, organization-specific capability map or operating model — is distinct from the reference model itself, though the two are often confused. It's also important to distinguish a reference model from a standard or a mandate. TOGAF's Technical Reference Model, APQC's Process Classification Framework, BIAN's banking model, and TM Forum's Business Process Framework are all reference models — voluntary, adaptable starting points. None of them prescribe how a specific enterprise must operate. Treating a reference model as compliance obligation rather than a customizable accelerator is a common and costly misstep.

Origin & Context

The concept originates in enterprise architecture practice, most formally in TOGAF's Technical Reference Model, which gave architects a generic taxonomy of infrastructure services to adapt rather than invent from scratch. Industry consortia later extended the idea to the business domain — APQC's Process Classification Framework, TM Forum's Business Process Framework (eTOM), and BIAN's banking industry architecture network all published sector-specific reference models so member organizations wouldn't each independently reinvent a capability or process taxonomy. The Business Architecture Guild's BIZBOK also codifies reference models as a recognized accelerator for capability mapping work.

Why It Matters

Business architects and CIOs care about reference models because they compress the time to a credible first-draft capability map or operating model from months of workshops to a matter of weeks. For CIOs managing M&A integration, a shared reference model gives two merging organizations a common vocabulary to compare operations before a single system gets touched. For regulated industries, sector reference models (like BIAN for banking) also make it easier to benchmark maturity against peers and demonstrate structured thinking to auditors and regulators. Skipping this accelerator and building a bespoke taxonomy from a blank page is one of the most common reasons early-stage BA programs stall.

Common Misconceptions

Myth: A reference model can be adopted as-is and used directly as your organization's capability map or operating model.

Reality: Reference models are intentionally generic. They must be cross-mapped against your actual business, renamed to match internal terminology, pruned of capabilities that don't apply, and extended with anything unique to your competitive position. Skipping this tailoring step produces a map nobody in the business recognizes as their own.

Myth: A reference model is essentially an org chart or a process flow diagram.

Reality: Reference models are typically structured around business capabilities or high-level process groupings — stable, organization-agnostic descriptions of what a business does — not around reporting lines or execution sequences, which change far more frequently than capabilities do.

Myth: Adopting a well-known industry reference model automatically signals architecture maturity.

Reality: The reference model is only the starting point. Value comes from how rigorously it's tailored, cross-mapped to systems and value streams, kept current, and actually used in governance and investment decisions — not from the mere fact that it was adopted.

Practical Example

A mid-sized insurer beginning its first formal business architecture initiative faced a familiar problem: no existing capability map, and a business architecture team of two with a tight window to show value before the next planning cycle. Rather than facilitate months of workshops from a blank page, the lead business architect started from an industry-standard insurance capability reference model, mapping its generic capabilities like Underwriting, Claims Management, and Policy Servicing against the insurer's actual operations. Business stakeholders reviewed the draft, renamed several capabilities to match internal language, removed ones that didn't apply to the company's commercial-lines-only focus, and added a capability unique to their specialty market. The tailored map was then cross-mapped to applications, surfacing redundant claims systems the CIO hadn't previously connected across business units. What could have taken a prolonged discovery effort instead produced a credible, business-validated capability map the team could defend to the executive committee within the current planning cycle.

Industry Applications

Banking & Financial Services

Architects use the BIAN reference model as a starting taxonomy for capabilities like Party Management, Payment Order, and Credit Risk Assessment, then tailor it to the institution's specific product lines and regulatory footprint.

Telecommunications

TM Forum's Business Process Framework (eTOM) provides a standard reference for process areas like Service Fulfillment and Assurance, giving carriers a common language for outsourcing, systems integration, and vendor management.

Manufacturing & Supply Chain

The SCOR (Supply Chain Operations Reference) model gives operations and BA teams a shared structure for Plan, Source, Make, Deliver, and Return capabilities, supporting supply chain benchmarking and network redesign.