Author: Steven Ring

Reference Architectures in Practice

The need for Reference Architectures (RA) was recognized by the Department of Defense (DoD) Chief Information Office (CIO) to provide department-wide guidance for architectures and solutions. However, there was little agreement, much confusion, and multiple meanings within the commercial, federal, and DoD Information Technology (IT) communities on what constitutes a Reference Architecture.

A common understanding was needed combined with a generic definition that could provide policy and direction to DoD Enterprise components for guiding and constraining Warfighting, Business, Intelligence, and Infrastructure environments. MITRE (this author) was tasked by DoD/CIO to develop a reference architecture definition and the result was the published DoD‐wide definition and guidance for the development and use as the DoD Description for Reference Architectures [1]. A companion DoD memo published by the DoD Architecture Standards Review Group(ASRG) encouraged DoD components to adopt and incorporate RAs into their architecture programs.

Reference Architectures are general in nature to some level of abstraction and are used to solve specific (recurring) issues within a focused subject area environment. The benefits of developing and using RAs are numerous and include [2].

	Enables Agencies, Organizations, and Enterprises to ·       Align their needs, goals, objectives, and requirements in fulfilling their responsibilities ·       Assist in overseeing and integrating policies, acquisitions, and integrations across programs ·       Influence and be a basis for investment planning decisions ·       Apply to Modernization, Innovation, and Transformation initiatives
	Promotes and encourages adherence to common approaches and reuse: ·       Collaborate across and within organizations to identify key areas of concern and build consensus on appropriate courses of action ·       Concentrate on capability concepts unconstrained by implementation details in delivery of systems, services, and solutions ·       Serve as a tool for providing common information, lexicon, guidance, approaches, and direction to guide and constrain architectures and solutions
	Value achieved when Reference Architectures used to guide and constrain solutions: ·       Repeatedly instantiated as standardized, interoperable, and consistent solutions ·       Serves as a strategic reference foundation of concepts, capabilities, and their relationships repeatedly by solutions ·       Supports validation of solutions against technical positions

Stakeholders consist of both 1) those who own or produce Reference Architectures and their instantiated solutions and 2) those who consume or use the solutions. Stakeholder roles include executive and senior leadership, domain subject matter experts (SME), Architects (Chief, Enterprise, Segment, Solution), and Functional/ Program Office management. Within a specific domain, some producing/consuming roles may have more responsibility than others.

Reference Architectures are not solutions nor solution architectures. Reference Architectures define what is needed to achieve enterprise goals and objectives. Solutions describe how to achieve those enterprise goals and objectives as real-world implementations and their concrete and specific details of processes and resources (human and system) necessary to deliver missions, capabilities, systems, and services. The DoD IEA defines solution architectures as the fundamental organization of a system, embodied in its components; their relationships with each other and the environment; and the principles governing its design and evolution [3].

Reference Architectures should not be confused with Architecture Frameworks such as The Zachman Framework [3], DoD Architecture Framework [DoDAF] [4], Unified Architecture Framework [UAF] [5], or The Open Group Architecture Framework [TOGAF] [6]. Architecture Frameworks provide guidance and rules for structuring, classifying, and organizing information. They consist of an organized set of (layered and hierarchal) structured artifacts that include descriptions, perspectives, visualizations, products, building blocks, and architecture data elements together with how they fit and relate together.

Nor should Reference Architectures be confused with Reference Models such as Federal Enterprise Architect [FEA] Business Reference Model [BRM] [7], etc. These are taxonomies that provide standardized categorization of entities. In fact, Reference Architecture are independent of frameworks (DoDAF, UAF, TOGAF, ..), methodologies (Structured, BPMN, UML, UPDM, SysML, …) and Enterprise Architecture tools (No Magic’s- MagicDraw [8], UNICOM’s System Architect [9], SparX System Enterprise Architect [10]).

What is a Reference Architecture?

The purpose of a Reference Architecture is to be an authoritative source of information about a specific subject area that guides and constrains the instantiations of multiple architectures and solutions [1]. Reference Architectures provide the necessary level of technical standards/ rules to direct the development of repeatable standardized, interoperable, and consistent solutions/ implementations across an Agency [11]. Gartner defines Solution Architectures as an architectural description of a specific solution [12].

It does this by providing patterns of abstract architectural elements, based on a purpose, principles, and technicalpositions/rules together with a common vocabulary (Figure 1).

Figure 1. Reference Architecture Components

Purpose: Why are you doing the RA identifying goals and objectives and specific purpose and problem(s) to be addressed Principles: What you must do in the form of enduring and seldom amended high-level foundational statements of organizational tenets, culture, and values. They drive technical positions and patterns in defining how an organization fulfills its mission Technical Positions/Rules: What you will do in the form of technical guidance, rules, policies, agreements, protocols, and standards based on principles. Technical positions are applied to solutions and help constrain and drive their compliance. Patterns: General architectural representations (tabular, structural, textual, behavioral, or graphical models) at a level of generality unconstrained by implementations details Vocabulary: Glossary of terms and definitions relevant to solutions

See the companion article How to Build a Reference Architecture for detailed information and guidelines [13]

When Are RAs Appropriate?

Discovery of what Reference Architectures are appropriate comes from an evaluation of an agency’s priorities for existing capabilities or capabilities planned to be developed. Capabilities are what is needed to achieve an organization’s goals and objectives.

Fundamental to a Reference Architecture is the environment called the Domain and within that domain specific focus areas called Subject Areas. Once the decision to develop a Reference Architecture is made, key phases in development include 1) clearly and distinctly identifying domain boundaries and scope of the capability area and identifying what is in scope and what is out of scope, 2) component data collection, and 3) and then resolving data quality and taxonomy concerns. It is in the context of the domain environment that the five components are defined and described. Depending on the nature of the domain subject areas, some components may be more heavily addressed than others.

 

 

 

Classifications of Reference Architectures

There is no “one-size-fits-all” Reference Architecture. Differing purposes, scope and unique characteristics across domains lead to Reference Architectures defined at many levels of abstraction and breadth of coverage along two dimensions (Figure 2). However, each individual Reference Architecture within a domain is “fit-for-purpose”. This means specific scope, characteristics, and purpose are identified within that domain. Note that while there is singularity of purpose, there will differentiations of solutions within a domain and that is by purpose and design.

• Levels of abstraction: ranging from highly concrete and specific where more guidance and decisions are necessary in the development of solutions up through to highly abstract, generic, and conceptual where less solution guidance and decisions are necessary
• Breadth of Coverage: ranging from narrow or minimal aspects of a solution up to full, end-to-end comprehensive coverage of operational, business and IT solution aspects

Figure 2. Levels of Abstraction and Breadth of Coverage

There may be multiple Reference Architectures within a single subject area. Figure 3 shows Reference Architectures #1 and #2, representing different emphasis or viewpoints, contributing to multiple solutions (A,B,C). One (#1) may be singular (A) but also contribute with #2 to other solutions (B,C). Figure 4 shows a parent/child hierarchy within a single subject area.

Figure 3. Multiple Reference Architectures	Figure 4. Hierarchy of Reference Architectures

How Do You Use a Reference Architecture?

As stated earlier, Reference Architectures are abstract and normalize the institutional understanding of capabilities at the enterprise level. They provide a common set of principles/rules, process patterns, and technical positions for use to guide and constrain development and implementation of Enterprise, Segment, or Solution architectures.

But how do you do this in practice? Well, there are two approaches.

1. Reference Architectures repeatedly instantiated as standardized, interoperable, and consistent solutions
2. Reference Architectures serve as a strategic reference foundation of concepts, capabilities, and their relationships repeatedly by domain solutions

For the first approach, let’s assume we have a holistic and generalized Reference Architecture model, say, Conduct Joint Protection for how to protect a military base. This would include generalized operations, systems, and sensors. One instantiated solution might be applied to Ft Hood, TX. Here the physical layout of the base and other unique base considerations would dictate specific systems and specific sensors according to the RA purpose, principles, and technical positions.

The very same Conduct Joint Protection could, then, be instantiated again but now to, say, Hanscom Air Force Base in Massachusetts. Here a completely different physical layout and other specific base considerations would dictate other specific systems and specific sensors. A third instantiation could be applied to, say, the Norfolk Navy Base in VA. In each case, it is the substitution of general and somewhat abstract elements with specific real-world elements in multiple instantiated solutions according to the RA purpose, principles, and technical positions that enables the Reference Architecture to achieve value.

For the second approach, let’s assume we have multiple domain solution models of (warfighting, intelligence, etc.) operational capabilities (sourced from CONOPS, mission operations/areas, system operations, etc.) depicted here as simplified Activity decomposition models #1,#2 in Figure 5). Each has its own considerable cyber vulnerabilities but lacks strategic Defensive Cyber Operations (DCO) capability guidance. Let’s further assume we have developed a generic pattern model of, say, Conduct Defensive Cyber Operations (DCO) capability (also depicted here as a simplified Activity decomposition model DCO RA in Figure 6) repeatedly used by domain models as a strategic Reference Foundation for alignment, fusion, and harmonization purposes.

Figure 5. Domain Models #1,#2	Figure 6. Conduct DCO Reference Architecture

One of the ways the RA model can be used as a reference would be where it was determined there is missing functionally in the domain models #1 & #2. A portion of the DCO RA can provide that functionality. Here, the relevant DCO RA activity tree (or single activity) is directly inserted into the domain model to account for this missing functionality.

Another way would be where the domain models already account for either all or partial functionally. Here, the DCO RA is used as “touch points” to align its functionally per domain model.

A third way would be where the DCO RA is used as a strategic reference in providing functionality that is not addressed nor accounted for in the domain model #1. Here, an analysis is needed to determine where best to insert the DCO RA functionality into the domain model.

Development Guidelines

Figure 7 below shows development guidelines. First, the domain/subject area must be defined with boundaries and scope established. Goals are the most abstract elements that leads to purpose, stakeholders, assumptions, etc. Principles (what you must do) derive from goals, culture, and values. They are seldom changed.

Each Rule should derive from one Principle. While some Rules may be applicable to multiple Principles, the most relevant Principle should be associated with a single Rule. Patterns (models) derive from an operational understanding of capabilities needing to be delivered and are central to a Reference Architecture. Technical Positions/Standards (what you will do) derive from Rules and apply only to the solutions. It is important to emphasize this point – it is the instantiated/ referenced  Solutions (from Patterns) that adhere to the Technical Positions/Standards and not the Reference Architecture itself.

Figure 7. Reference Architecture Development Guidelines

RAs may have temporal aspects (Figure 8) based on the domain environment having a time frame or based on individual solutions having their own time frames.

Figure 8. Temporal Aspects of Reference Architectures

Reference Architectures usually take the form of an MS Word document. Figure 9 shows a suggested outline. This should be used as a starting point and adapted, as necessary.

Figure 9. RA Word Template

A Reference Architecture can be, by itself, an Architecture. Figure 10 below provides a list of suggested mappings to DoDAF v2.

Figure 10. Suggested Mappings to DoDAF v2

 

Reference Architecture Maturity Model

A Reference Architecture Maturity Model (MM) has been defined to be used for evaluating and measuring organizational progress and success in adoption and implementation. It measures the current state of maturity and success in increasing stages of commitment, development, implementation, and involvement leading to full embodiment in the organizational culture. This MM, like the Reference Architecture outline, should be used as a starting point and adapted, as necessary.

 

	Create Awareness: Enterprise recognizes need for RA ·       Capability gaps or planned capability needs recognized ·       Domain issue(s) and stakeholder concern(s) to be addressed by one or more of the solutions are identified ·       Goals, objectives, constraints & assumptions of the environment plus any timeframe for the execution of the solutions are defined
	Prepare: RA published and adopted ·       Domain/subject area boundaries and scope defined ·       Sources and ownership of component data identified and collected with data quality and taxonomy concerns resolved ·       Maturity model measurable outcomes established ·       RA training and education provided
	Implement: RA applied to guide and constrain solutions ·       Solutions prioritized for development ·       RA guides and constrains prioritized solutions as instantiations or as a strategic reference foundation ·       Measurable outcomes provided and reported
	Manage: RA efficiently and effectively applied and managed across the enterprise ·       Capability gaps closed or planned capability realized ·       Further solutions developed & implemented ·       Solutions validated to be in conformance/ compliance/ alignment with Technical Positions
	Embed in Culture: RA evolves and matures as enterprise requirements change with time ·       RA fully embedded in organizational culture and environment ·       If necessary, RA revised, and the maturity reverts to the Prepare stage

Summary

The purpose of this paper is to educate and provide guidance and direction on the development and use of Reference Architectures for current and future capabilities. Reference Architectures address different levels of abstraction (from the specific to the generalized) and different levels of coverage (from narrow to full end‐to‐end) depending on the “fit-for-purpose” needs.

Two conditions are required for a Reference Architecture: (1) the five components – purpose, principles, technical positions/ rules, patterns, and vocabulary – must be provided in some form or another and (2) be general in nature and used to solve specific issues within a single focused environment as a reference basis, foundation, or to guide and constrain solutions.

While initially targeted to DoD environments, Reference Architectures are equally applicable across wide spectrum of federal and commercial environments. The key point is that Reference Architectures are defined to be an authoritative source of information about a specific subject area that guides and constrains the instantiations of multiple architectures and solutions. They should be updated periodically to account for emerging technology, new standards, and changing requirements and business needs. The Maturity Model should be adapted and refined to fit the organization’s capability needs and then be used to track progress and maturity. The Reference Architecture document template, likewise, should be adapted and refined.

Today, Reference Architectures are widely used throughout the DoD and Federal Agencies to provide information, guidance, and direction for focused subject areas. These Reference Architectures have wide‐ranging purposes, uses, levels of detail, and levels of abstraction. Many examples include:

• S Space Force Space Cyber Defense Reference Architecture (SCDRA)
• Enterprise-wide Access to Network and Collaboration Services (EANCS) Reference Architecture
• IC/DoD Content Discovery and Retrieval Reference Architecture
• Data Center Reference Architecture (DC RA)
• Army Positioning, Navigating and Timing (PNT) Systems Reference Architectures
• DoD Cybersecurity Reference Architecture (CS RA)
• Unified Capabilities Reference Architecture (UCRA)
• Network Optimization Reference Architecture (NORA)
• Active Directory Optimization Reference Architecture (ADORA)
• Defense Intelligence Information Enterprise (DI2E) Reference Architecture
• Joint All Domain Command and Control Reference Architecture (JADC2 RA)

Bibliography

[1] US Department of Defense, Office of the Chief Information Officer (DoD/CIO), Reference Architecture Description, Jun 2010, http://www.acqnotes.com/Attachments/Reference%20Architecture%20Description,%20June%202010.pdf

[2] Ring, Steven (2020). Role of Reference Architectures, The MITRE Corporation, McLean, VA. Approved for public release, distribution unlimited, Case #12-1351, companion slides

[3] Zachman International Enterprise Architecture,  https://www.zachman.com

[4] US Department of Defense Architecture Framework (DoDAF), https://dodcio.defense.gov/Library/DoD-Architecture-Framework

[5] Object Management Group, Unified Architecture Framework® (UAF®), https://www.omg.org/uaf/index.htm

[6] The Open Group Architecture Framework (TOGAF) https://www.opengroup.org/togaf

[7] Federal Enterprise Architecture Reference Models,  https://eapad.dk/gov/us/common-approach/reference-models/

[8] Dassault Systemes CATiA No Magic, https://www.nomagic.com

[9] UNICOM System Architect, https://www.teamblue.unicomsi.com/products/system-architect/

[10] SPARX Systems Enterprise Architect, https://sparxsystems.com/

[11] Adapted from DoD Information Environment (DoD IEA),DoD CIO, v2.0, volume I, 2012

[12] https://www.gartner.com/en/information-technology/glossary/solution-architecture

[13] Ring, Steven (2020). How to Build a Reference Architecture: User Guide. The MITRE Corporation, McLean, VA. Approved for public release, distribution unlimited, Case #12-1351