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 [1]. A more complete and detailed description for “How to Build a Reference Architecture: User Guide” is also available [2].

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 [3]. 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 [3]. 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:

1. Repeatedly instantiated as standardized, interoperable, and consistent solutions
2. Repeatedly serving as a strategic reference foundation of concepts, capabilities, and their relationships by solutions

Getting Started

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.

Development Guidance

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.

Bibliography

[1] 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

[2] 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.

[3] 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