What is a Reference Architecture?
What is a Reference Architecture?
- Expected Parts of a Reference Architecture
- Basics of a Reference Architecture
- Looking at a System's Structure
- Expected Look at a System's Function
Why Use a Reference Architecture
- Testing for completeness of the architecture
- Simplifying cascading directions and constraint for governance
- Consistently answering important questions
- Using a Reference Reference Architecture with standard EA Use Cases
- What Industries use Reference Architectures
What is a Reference Architecture?
A reference architecture is a generic architecture that identifies the normal outlines of a system. It provides the components, relationships, principles, and architectural guidelines.
Technically, reference architecture is considered a part of enterprise architecture. In terms of the TOGAF enterprise continuum, you will find Foundational, Common , or Industry examples.
The best reference architectures provide confidence that the problem, and that every important part is exposed.
When we look at reference architectures, we often see two different types: those that expose the structure of a system and those that show how a system works. Please remember the word system doesn't have any IT connotations. You can describe the Sun's nuclear fusion, a market, and a product release as a system.
Expected Parts of a Reference Architecture
Complete reference architectures will include more than a model. Potential parts include:
- Scope of the system of interest
Boundary of the system and explanation of the problem. May include objectives, particular purposes, and challenges that need to be solved - Model(s) of the system
- Components of a system
- Relationships between components
- Attributes that should be specified
Navigate includes architecture attributes to different components. They can range from a preferred operating model of a business capability to the expected lifespan of an interface - Vocabulary
A specialized glossary with definitions and phrases related to the system of interest
- Architecture Patterns of the system
- Architecture Principles of the system
- Viewpoint Library
- Best practice in the system
The Basics of Reference Architecture
A reference architecture must comprise the components and relationships inside the system. It can include identification of components beyond the scope of the reference architecture to explain how the reference fits into a larger whole.
Reference architectures may be developed at various abstraction levels. One that is quite abstract may display the building blocks of a supply chain (SCOR) or the information required to manage digital products (IT4IT).
A common approach for a reference architecture is to generalize multiple solutions. SCOR's supply chain reference is an example - it shows the common activities for different supply chain approaches. SCOR's reference shows how to put these components together to create a solution.
Looking at a System's Structure
Reference models that support understanding system structure provide the basics of a system. They will exist at different levels of detail and identify the core elements of a system. Structure reference models typically are static models and are normally presented in a simple graphic or a tabular form.
Almost all enterprise architecture uses static models.
Example of structure reference models includes:
- Canada’s GSRM (Government Service Reference Model)
- US Federal Enterprise Architecture’s Technical Reference Model
- Enterprise Architecture Capability Reference Architecture
We use System Structure to test for completeness and to speed the development of unique architecture.
Looking at a System's Function
Reference models that support understanding system function identify how a system works. They will identify the interaction of components in a system. Function reference models are often shown in a diagram. There will usually be a set of supporting documentation and a dynamic model. Strong functional models can be exercised.
We use System Dynamics to explore strong functional models. Understanding how a system works is critical to understanding the effective levers and barriers to change. The example above is new product adoption - think about one that showed the development of enterprise agility or removing technical debt.
Why Use a Reference Model
We simplify the value of using reference architectures to speeding up time-to-deliver and improving quality.
With a reference model you have:
- confidence that all key components, relationship and attributes are considered
- ability to move to identifying the source of deficiencies and their solution
Without a reference architecture you need to figure out the system. Then test your model for completeness and accuracy. All that time is spent getting to the start of analysis.
Reference architectures facilitate collaboration and communication. A reference architecture assist teams avoid mistakes and delays. It provides a basis for governance.
There are other powerful uses that include the following.
- Testing for completeness of the architecture
- Simplifying cascading directions and constraint for governance
- Consistently answering important questions
Testing Completeness of the Architecture
A reference architecture will always provide the components of a system and the relationship between the components. That means we can use a reference architecture to ensure any architecture analysis or design addresses the complete system.
Where you have components in the reference that are missing from the system determine whether there is a gap in the system, or if the component is irrelevant. Missing components are gaps in the system.
Cascading Superior Architecture Decision
The foundation of architecture governance and implementation governance is the ability to cascade an architecture decision from vision and strategy to implementation.
Wherever reasonable, we apply architecture decisions to reference architecture components. Then, when more detailed architecture or design work comes along, we can test for compliance against a reference. There is a balance between applicability and effort. The more applicable the reference architecture to a problem space, the easier it is to cascade applicable decisions. However, the effort to maintain the end-to-end record of decisions increases.
Solution Delivery Implementation Governance
We know the most important outcome of the Solution Delivery use case is enabling implementation governance.
The depth of implementation governance is driven by how detailed the future state and any roadmap. The diagram below provides a visualization of increasing depth and detail of implementation governance using three sources for the solution.
A bottom-up solution is identified by people directly affected. It won’t be filling any identified gap by design. The available guidance will be the overall target architecture.
A gap filling solution will either be identified by people directly affected or as part of an implementation plan. This type of solutions adds guidance from the gap between the current and future state. This guidance comes down to what is expected to change (gap) and what is expected to stay the same (everything else). This provides a boundary for the solution, where it is expected to improve the organization and where it is expected to use what is in place.
Roadmapped solutions are top-down. The workpackage to fill a gap is on a roadmap. The work will have a sponsor. The portfolio will provide specific performance expectations and an implementation strategy. The gap being filled can also be refined by any transition state the roadmap is working towards.
Using a Reference Reference Architecture with Standard EA Use Cases
There are four standard enterprise architecture use cases. Each use case is aimed at assisting a different audience to drive effective change.
Supporting Portfolio Use Case
Architecture work is focused on serving the Portfolio Owner. The portfolio exists. It has clear outcomes and constraints.
Portfolio owners are future action oriented. They intend to drive change and deliver the expected benefits within their constraints.
The future action-orientation of a portfolio owner requires architecture work to focus on enabling change. The portfolio owner needs to be making decisions in advance to drive activity that will result in the outcomes they are accountable for. The practitioner needs:
- An end-to-end architecture to provide context, guidance, and constraints to the portfolio
- One or more focused architecture descriptions that are aligned with the portfolio’s outcome and main components
Portfolio owners aim for the sweet spot between top down and bottom-up planning. Top-down ensures performance expectations, constraints, and dependencies are covered. Bottom-up captures local knowledge and creativity.
The portfolio owners and other stakeholders use the architecture roadmap to direct improvement projects. They understand dependency and synergy. Most importantly, they understand the places they can stop, harvest value, and change direction. Incremental transition points directly support enterprise agility with value delivery.
In portfolio work, architecture specifications are focused on work packages and architecture principles and patterns.
Supporting Solution Delivery Use Case
Solution Delivery Architecture starts with a key assumption—the overall target and changes required to realize it are known. A solution is filling known gaps within known constraints that limit the implementers’ creativity and freedom.
The current action-orientation of an implementer requires architecture to work to focus on transmitting performance expectations and external constraints. The implementer is focused on the performance expectations and constraints of their different projects. Their job is to marshal the resources and execute. The implementer needs to know what they are expected to do and what limits exist to their creativity. The standard use case identifies architecture work should:
- Defines how change will be done, applicable constraints and performance expectations
- Directly support implementation governance
- Effectively guide implementation
It is important to note that architecture for solution delivery is primarily done for implementation governance to support outcome owners.
The most important elements of a solution architecture are:
- The gaps being filled
- The components in the solution and their relationship
- Performance expectations and constraints cascaded from superior architecture
- Performance expectations and constraints that will be applied to the implementation
The critical deliverable is a solution architecture that specifies what gap in the future state the solution will fill, and any applicable constraints and performance expectations. When a roadmap specifies the implementation strategy, the approach to the solution needs to be included in the solution architecture.
A solution architecture is distinguished by its boundary. It addresses a specific problem space. In formal terms, it is a specific system of interest that fits into and interacts with other systems. We do not tie the concept to a specific level of detail. It is sufficient to say that a solution architecture will be more detailed than the surrounding architecture.
What Industries Use Reference Architecture?
Reference architectures are used across all industries.
There are industry specific reference architectures. As well as more narrow focuses like supply chain, AI, IT Infrastructure, public cloud, or container.
The image above provides a set of reference models for humans - respiratory model, skeletal model, circulatory model, digestive model, and nervous system.
How do You Use a Reference Architecture?
There are three ways to use a good reference architecture.
First, it should provide a starting point for the basics. SCOR describes supply chain processes and three manufacturing models. Rather than start with a blank piece of paper. You have the essential core information already available. This way, you don’t spend time re-inventing the wheel when you don’t need to. Instead, one can work on the unique aspects of the wheel in their specific use case. Aircraft wheels need to accelerate from 0 to 140 MPH instantly. The Lunar rover wheels had to be very light, and not throw dust. Both are round, removable, and used to steer. It all comes down to use case.
Second, it should provide an understanding of how a system works. You don’t need to figure out the parts of a system and how they interact. Instead, one should look for how architecture optimizes the parts and interactions for one’s use case. Seven Levers of Digital Transformation is an excellent example.
Third, one should be able to use reference architecture in architecture governance. The reference architecture is used to assess a design to make sure the design considered all the expected needs of a system. For example, in GSRM, all revokable permits need a process for assessing whether the permit holder still gets to keep a permit and an appeals process. It doesn’t matter whether it is a driving license, medical license, or transporting nuclear waste permit all the processes need to be there.
To go further look at Using Reference Architectures for Digital Transformation.
Examples of Reference Architecture
There are many examples of reference architecture:
- Seven Levers of Digital Transformation provides a reference architecture for transforming an enterprise
- IT4IT is an information reference architecture for Information Technology functions.
- BIAN is a reference architecture for the Banking Industry.
- SCOR is a reference architecture for supply chain.
- APQC provides cross-industry, or industry-specific, business process reference architectures. APQC is often used as a foundation for business process models or capability models.
- Eulynx can be used for traffic signaling systems.
- GSRM (Canada's Government Services Reference Model) provides a reference architecture for government services.
- EA Capability Reference Architecture is used to speed up developing an EA team.
- AUTOSAR is a type of component-focused reference architecture for vehicle software.
- AWS has many system structure reference architectures, including a Security Services Architecture.
- The US DoD provides Zero-Trust Reference Architecture.
TOGAF Standard Reference Architectures
The TOGAF Standard includes two reference architectures: the Technical Reference Architecture, and the Integrated Information Infrastructure Reference Model. Common understanding may be achieved with the aid of standardized terminology. In instance, reference architectural standards can provide a shared language.
Reference Architecture vs Reference Model
Most people use Reference Architecture and Reference Model as synonyms. Technically, they are distinct, but the difference is irrelevant for most enterprise architects.
From a purist perspective, a reference model explains part of a system, and a reference architecture explains the entire system. The distinction is tied to the scope of ‘the system.’ However, almost everyone uses the terms interchangeably. One would find it more useful to deliver useful architecture that guides change than spend time on semantic discussions.
A system's architecture is described as being represented by an architectural framework, which is an encapsulation of a minimal set of practices and criteria. The TOGAF Framework offers methods to describe and identify architecture inputs.
Reference architecture goes a step further by expediting the process for a specific architecture type, assisting in the determination of which architectural approaches will satisfy specific requirements, and determining the minimally necessary set of architectural artifacts required to satisfy the "best practices" requirements for a specific architecture. Reference architectures place a strong emphasis on the "template" portion of the concept.
Tests for a Good Reference Architecture
The best reference architectures represent widely acknowledged industry best practices and often recommend the optimum delivery strategy. An easy-to-understand reference architecture improves the quality and speed of architecture development and implementation.
Standard considerations of a good reference model:
- consortia built, with multiple stakeholder engagement
- frames the problem space
- identifies key elements
- identifies key relationships
- tells you how to assess the system.
Enterprise Architecture Capability Reference Architecture
Download the Enterprise Architecture Capability Reference Architecture. It is the foundation of building a solid enterprise architecture team.
Your Enterprise Architecture Capability model is central to an optimized enterprise architecture capability framework.
