Developing an EA
How to Build a Reference Architecture
Author: Steven Ring
Editor’s Note: This article is a companion to “Role of Reference Architectures,” also written by Steven Ring. Readers may find it beneficial to read that article first if not familiar with the use of Reference Architectures as part of an enterprise architecture methodology . A more complete and detailed description for “How to Build a Reference Architecture: User Guide” is also available .
The need for Reference Architectures (RA) was recognized by the Department of Defense (DoD) Chief Information Officer (CIO) to provide department-wide guidance for architectures and solutions. The result was the DoD‐wide definition and guidance for the development and used as the DoD Description for Reference Architectures . While initially targeted towards DoD environments, Reference Architectures are equally applicable across a wide spectrum of federal and commercial settings.
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 are general to some abstraction level and are used to solve specific (recurring) issues within a focused subject area environment.
It does this by providing patterns of abstract architectural elements based on a purpose, principles, and technical positions/rules together with a common vocabulary, as shown below.
Discovery of what Reference Architectures are appropriate comes from evaluating an agency’s priorities for existing or planned capabilities. Reference Architectures value is achieved when they are used to guide & constrain solutions in one of two ways:
- Repeatedly instantiated as standardized, interoperable, and consistent solutions
- Repeatedly serving as a strategic reference foundation of concepts, capabilities, and their relationships by solutions
Fundamental to a Reference Architecture is the Domain’s environment, and within that domain-specific focus, the area is called Subject Areas. Once the decision is made to develop a Reference Architecture, the first step is to identify domain boundaries clearly and distinctly and what is in scope and what is out of scope. Next, identify sources of relevant domain architecture data, find, collect, and organize components artifacts. It may be necessary to do “data calls,” interviews with subject matter experts (SMEs) and others, seek organizational documents, use questionnaires, direct or on-site observations, capture the personal experience, etc. Lastly, resolve data quality and taxonomy concerns.
Reference Architectures usually take the form of an MS Word document. A suggested outline is given below where:
- Purpose: Why are you doing the RA identifying goals and objectives and specific purpose and problem(s) to be addressed. Constraints & assumptions of the domain environment plus any timeframe for the execution of the solutions also need to be defined
- 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
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 commitment, development, implementation, and involvement leading to the full embodiment in the organizational culture.
 Ring, Steven (2020). Role of Reference Architectures. The MITRE Corporation, McLean, VA. Approved for public release, distribution unlimited, Case #12-1351, both slides and accompanying paper
 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.
 Office of the Assistant Secretary of Defense (OASD)/Networks and Information Integration (NII) Directorate, DoD Reference Architecture Description, , June 2010, http://www.acqnotes.com/Attachments/Reference%20Architecture%20Description,%20June%202010.pdf
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.