The Value of Reference Architectures

What are reference architectures?

Reference architectures are standardized architectures that provide a frame of reference for a particular domain, sector or field of interest. Reference models or architectures provide a common vocabulary, reusable designs and industry best practices.

They are not solution architectures, i.e. they are not implemented directly. Rather, they are used as a constraint for more concrete architectures. 

Typically, a reference architecture includes common architectural principles, patterns, building blocks, and standards. Many domains have defined their own reference architectures. Well-known examples include:

• the BIAN service landscape for the banking industry;
• the ACORD Framework for the insurance industry;
• the eTOM business process framework for the telecommunications industry from the TMforum;
• various government reference architectures, for example the Dutch NORA and her ‘daughters’, the US FEAF or the Australian AGA;
• the defense architecture frameworks such as NAF, DODAF and MoDAF;
• reference architectures for manufacturing and supply chains such as ISA-95 and SCOR.

In this blog, we’ve demonstrated best practices to analyze and get new insights on why you (should) invest in certain capabilities. We’ve also looked at how you can provide more context information with Business Model Canvas, resources and value stream views for your strategic and business planning.

In the next installment in this series, we will address how capabilities are realized by the operating model of the enterprise. Stay tuned!

Most of these architectures include a domain's common business functions/capabilities and business processes. Next to that, they may include, for example, common data models, communication standards and exchange formats, and sometimes even common software building blocks and other reusable assets. 

Why use reference architectures?

So, what is the value of using such reference architectures, and why and when should you employ them? Industry frameworks offer significant value by providing a foundational blueprint for understanding a specific domain. 

They give you a clear starting point for developing your enterprise architecture, allowing you to build on pre-existing structures rather than starting from scratch—avoiding inefficiencies that often lead to suboptimal outcomes. 

These frameworks are particularly valuable for areas of your organization that do not differentiate you competitively. 

Take the insurance industry, for instance—business functions and processes are generally similar across companies. The real competitive edge lies in areas such as product offerings, pricing strategies, target customer segments, and relationship management. 

Adopting well-established industry practices for non-competitive functions ensures operational efficiency and aligns with evolving industry norms. For example, many IT vendors, such as SAP, provide pre-defined processes for core functions like accounting, which rarely serve as a source of competitive advantage.

 Another key benefit of leveraging such frameworks is improved interoperability. Businesses must seamlessly connect and collaborate with external partners in today's interconnected world. 

Standards and modular design principles embedded in these frameworks simplify integration, allowing different systems and organizations to work together effortlessly. 

Moreover, adhering to standardized interfaces makes replacing individual components or adapting systems to meet new requirements easier. The concept mirrors the simplicity of LEGO blocks, where standardized connections make building and reconfiguring easy, as my colleague Bas van Gils eloquently explained in his recent blog. 

Industry blueprints also play a critical role in scenarios like mergers, acquisitions, and outsourcing. When two organizations operate under shared standards and frameworks, aligning their functions, processes, or systems becomes significantly easier. 

This shared understanding reduces friction during integration and allows for smoother recombination of resources into new organizational structures. 

Additionally, frameworks are indispensable for benchmarking within your industry. Most organizations do not compete on the design of their business processes but rather on their execution. 

Using standardized models allows for direct performance comparisons, highlighting areas where improvements in execution can drive competitive gains. 

Regulatory compliance is another vital driver for adopting these frameworks. Many industries are increasingly governed by mandated practices and reporting standards, often built on established principles. 

For example, accounting practices and reporting formats, such as XBRL, ensure consistency and compliance across the board, making adherence to these standards a necessity rather than an option. 

How to use Reference Architectures?

Some conditions should be fulfilled before you decide to use a reference architecture. First of all, a reference architecture should be community-based. Users, not vendors, should decide on best practices, and the user community should actively maintain the architecture. 

The world is changing, and so too should your reference architectures. Such an active and open community process is ideally complemented by open standards in describing the architectures. 

Using a reference architecture in an organization also requires governance: the organization should commit to its use and this should be ‘enforced’ in some way. 

Reference architectures are only valuable if people use them as intended and follow their guidance. Otherwise, the whole idea of reusing industry best practices breaks down. 

Your reference architecture of choice should provide true, actionable guidance. General architecture principles are not enough. Actual structure, for example in terms of business functions or processes, building blocks and standards, is needed to provide you with a useful backbone for your own architecture efforts. 

Using reference architectures does not imply that you lose all your design freedom. Rather, you focus that freedom on those aspects of your enterprise where you make a real difference. That is where you, as an architect, can add the most value!