Readings on Enterprise Architecture Vol. 4 (Reference Architectures): Food for thought and a starting point for your designs

Following up with a new take on background information in the context of enterprise architecture. Feel free to check prior ones here: Vol. 1 (books), Vol. 2 (articles/videos), and Vol. 3 (research articles).

This time we take a look at reference architectures. Why is it so tough to explain what they are? What are their benefits? Why should you consider using them? What are common examples?

The article shares a summary of the term, selected benefits and challenges of using reference architectures and a list of examples to check for your industry, function or technology focus and adapt to support solving your individual challenges.

Definition

When attacking a new challenge most of us ideate using e.g. a whiteboard and looking around for sources of trusted information and knowledge to refer to. Where could we start and maybe benefit from experiences of others?

A reference model is an abstract frame for understanding key parts (entities) and significant relationships among them in a defined context addressing concerns of the respective stakeholders and their challenges.

Extending this, reference architectures provide a more complete set of preferred vocabulary, principles, building blocks, design, practices and relations among these for a particular industry, domain, or field of interest (problem area). Often, they are referred to as a blueprint derived based on industry or technology best practices.

In most cases it includes a fair-to-understand overview (usually on one page) of the domain of interest like e.g. a process overview or an example application landscape. Reference architectures could be defined at various levels of detail, from high-level approaches to specific implementations like e.g. a industry value chain overview vs. a domain and vendor specific reference architecture to design a data platform.

In case of reference model vs. reference architecture - keeping it short here we could go with one area model vs. more complex relationships outlined not only on one level (see Define and Evolve Services part in my take on Enterprise Architecture ) and a tendency to link functional / business topics with (IT / SW) implementation/operations.

Benefits and Challenges

Why should you care about them? They should help you with analyzing and adapting a feasible design in your context. They support to speed up the phases of design and planning – especially so you can focus on the situation specific challenges, no need to build basic structures fresh up from zero.

Basic types and Variety of References

Why is it tough to describe the one thing a reference architecture is? Because it’s about the possible variety in a couple of dimensions like e.g. purpose of use (strategy & planning vs. solution design & implementation), focus area (business vs. technology), level of abstraction (low vs. high detail), breadths of coverage (one aspect vs. end-to-end), specification of delivery (vendor/product-neutral vs. specific) and the link to the individual situation and indicated need / objective.

These aspects tailor the result and lead to a great diversity of reference architectures, even within the same field. e.g. BIAN outlining a capability model for the banking industry vs. AWS summarizing a reference for using their services for high frequency video streaming.

Reference architectures appear basically along all areas of enterprise architecture, as discussed in a variety of ways. Basic types are mentioned in the following:

Business Reference Models (BRM) support designing, planning and executing what a business does to deliver products and value to customers including e.g. business motivation models, business capability models, business process models.

Technology Reference Models (TRM) provide overviews on e.g. IT services, technology stacks and infrastructure setups. These technologies support to deliver the indicated capabilities and business processes.

Information Reference Model (IRM) structure pieces of information, their relationships and how they need to flow to process the work indicated.

Considerations and reference architectures

Sometimes the term reference architecture comes across quite geeky and seems to be an IT people thing. If you pick the appropriate ones, they definitely support to understand your industry, key structures and then dive into specific business or IT cases. They help business and IT architects and analysts with the daily work in their domain, as they won’t be able timewise to design everything from scratch.

Of course, one shouldn’t forget not to take everything referenced for granted. Sometimes the proposed structure worked out in another practical, or even a theoretical context. It does not need to work for your current context.

You need to rework / restructure the reference to fit your context. You need to verify, blend, and extend the source with others and your individual content. The reference does not provide the single truth but an "example" how one could process it. In most cases they are not near a ready-to-implement solution blueprint.

They support as one, definitely important resource to understand context, and nail down from general to specific along business capabilities, org structures, processes, applications, etc.

Please find below reference architectures listed along a basic structure, majority directly accessable. It’s definitely not exhaustive and might evolve over time. Feel free to comment on more relevant ones from your side that helped you out.

Industry Focus

Banking: Banking Industry Architecture Network (BIAN) Service Landscape

Banking: IBM Banking Industry Architecture

Insurance: Association for Cooperative Operations R&D (ACORD) framework

Healthcare: The Open Group Healthcare Enterprise Reference Architecture (O-HERA)

Retail: Association for Retail Technology Standards (ARTS) framework

Telecommunication: eTOM business process framework (TMForum)

NGO: Non-Governmental Organization (NGO) Reference Model

Government: US Federal Enterprise Architecture (FEA) Framework

Government: Dutch Governmental Reference Architecture (NORA)

Government: Australian Government Architecture (AGA)

Defense: Department of Defense Architecture Framework (DoDAF)

Defense: NATO architecture Framework

Various: APQC’s Process Classification Framework (PCF)

Various: Industry Capability Models

Various: Business Architecture Guild Reference Models (access required)

Domain / Function Focus

Finance, Sales and SCM: OpenReference frameworks

SCM: Supply-Chain-Operations-Reference (SCOR) Model

Manufacturing: Reference Architecture Model Industry 4.0 (RAMI4.0)

Manufacturing: Cisco Validated Designs for Digital Manufacturing

Legal: Deloitte legal operating model

Technology Focus

IoT: IIC Industrial Internet Reference Architecture (IIRA)

IoT: IBM IoT Reference Architecture

Cloud: NIST Cloud Computing Reference Architecture

Cloud: The Open Group Cloud Ecosystem Reference Model

Security: NIST Cyber Security Framework

Security: Microsoft Cyber Security Architecture Reference Model

Security: Cisco Security Reference Architecture

Data Center: Data Centre Services Reference Architecture Document (RAD)

Various: AWS Solution Architecture Center

Various: OASIS open standards for e.g. cybersecurity, blockchain, IoT, cloud computing, legal data exchange, content technologies

General Sources

EABOK 2022 Reference Architectures in Practice

Open Group 2021 Reference Architectures and Open Group Standards for IoT

LeanIX 2022 The Definitive Guide to Reference Architecture

BizzDesign 2014 The Value of Reference Architectures

ARC 2022 What Is the Value of Reference Models in a Technology Strategy

Note: This article reflects the private opinion of the author. Unpaid advertisement.