Developing an EA
Role of Reference Architectures
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 . 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 .
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 .
Reference Architectures should not be confused with Architecture Frameworks such as The Zachman Framework , DoD Architecture Framework [DoDAF] , Unified Architecture Framework [UAF] , or The Open Group Architecture Framework [TOGAF] . 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] , 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 , UNICOM’s System Architect , SparX System Enterprise Architect ).
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 . 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 . Gartner defines Solution Architectures as an architectural description of a specific solution .
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
See the companion article How to Build a Reference Architecture for detailed information and guidelines 
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.
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
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|
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.
- Reference Architectures repeatedly instantiated as standardized, interoperable, and consistent solutions
- 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.
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.
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.
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.
A Reference Architecture can be, by itself, an Architecture. Figure 10 below provides a list of suggested mappings to DoDAF v2.
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
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)
 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
 Ring, Steven (2020). Role of Reference Architectures, The MITRE Corporation, McLean, VA. Approved for public release, distribution unlimited, Case #12-1351, companion slides
 Zachman International Enterprise Architecture, https://www.zachman.com
 US Department of Defense Architecture Framework (DoDAF), https://dodcio.defense.gov/Library/DoD-Architecture-Framework
 Object Management Group, Unified Architecture Framework® (UAF®), https://www.omg.org/uaf/index.htm
 The Open Group Architecture Framework (TOGAF) https://www.opengroup.org/togaf
 Federal Enterprise Architecture Reference Models, https://eapad.dk/gov/us/common-approach/reference-models/
 Dassault Systemes CATiA No Magic, https://www.nomagic.com
 UNICOM System Architect, https://www.teamblue.unicomsi.com/products/system-architect/
 SPARX Systems Enterprise Architect, https://sparxsystems.com/
 Adapted from DoD Information Environment (DoD IEA),DoD CIO, v2.0, volume I, 2012
 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
EABOK® Knowledge Areas
Organizational Scope and Structure of EA
Developing an EA
- Business Requirements and Value Proposition
- Methodologies and Processes
- Architecture Frameworks
- Data and Information Management
- Project Management
- Change Management
- Testing and Evaluation
- Modeling and Simulation
- Role of Reference Architectures
- How to Build a Reference Architecture
- Coordinating the Creation of a Reference Architecture
Management of EA
EA in Practice
Perspectives on EA
EABOK is an evolving knowledge base and more information will be released as available.
In addition to the EABOK Board members, the content is also contributed by the following MITRE employees:
- Carla Kendrick
- Brenda Yu
- Eddie Wang
- Rose Tykinski
- Wakar Khan
- Mike Russell
This website is managed by the EABOK Consortium and hosted by MITRE to enable stakeholder collaboration within the EA community.
EABOK and the EABOK logo are trademarks of MITRE and are used by The EABOK Consortium with permission.
All other trademarks are the property of their respective owners. All rights reserved.