Author: Daniel Garcia

“Complexity is one of the great problems in environmental design.” — Christopher Alexander

Introduction

A useful reference architecture (RA) is most valuable when it is developed by the various members of its enterprise, community, or organization. Managing the complexities of an organization requires the skills of its own stakeholders. Their individual skills and expertise are important contributions to the outcomes that will drive what is to be applied in the operational environments. This article will cover what is a reference architecture, what it is used for, and the importance of community involvement towards developing a RA as a useful way to manage the strategic and operational complexities of business, mission, data, and data subject areas.

As an analogy, the notion of Reference Model, Reference Architecture, and subsequent Segment or Solution Architecture constructs are similar to the logical and physical Deoxyribonucleic Acid (DNA),  Ribonucleic Acid (RNA), and succeeding Proteins (amino acids) biology architecture. Where DNA is the master version, and RNA the reference copy directing the amino acids that carry out the physical implementation. The transcription to translation, and ultimately to physical implementation are the conceptual nature of architecture roles as a continuum of activity, and specifically the role of a reference architecture. Since DNA and RNA constructs are an evolution of adaptation over time to persist in a given environment, so too are reference architectures. A given enterprise needs to have a point of reference to plan and persist strategically in its working environment. For the federal government it is about managing its complexity of providing a range of taxpayer necessities; from citizen services to maintaining global security across several global domains. In the commercial enterprises, it is about economic progress and long-term market share in multiple business and industry domains.

Likewise, if there are errors in the DNA master copy (e.g., chromosomes) there will be errors in the implementation –­via RNA, that lead to physical imperfections. A reference architecture must have a level of precision that is a high percentage of accuracy as a version release for organizations to develop practical, effective physical architectures (segment or solutions). It is important that organizations build reference architectures together with their input from their respective expertise. From this approach, organizational enterprise buy-in, mission value outcome, expected strategic performance, and technology guidance are what an effective reference architecture provides as actionable and targeted outcomes in terms of capabilities for organizations.

Through an Enterprise Architecture Program (EAP), a RA also aligns its work in tandem with other enterprise lines of businesses, such Capital Planning and Investment Control (CPIC).  More importantly, it allows an organization, community, or enterprise to build an RA collectively as a way to include key contributions from C-Level people, key functional managers, the various architects, as well as key technologists to achieve buy-in simultaneously.

Purpose of a Reference Architecture

A reference architecture works in tandem with multiple stakeholders and their vested interests. Multiple skill areas come into play within a given organization’s enterprise. Strategic, funding, engineering, and operational areas are but a few that draw from a community-developed RA. Essentially, a RA is to:

• Provide a logical architecture at a level of abstraction that draws from an overarching reference model, and ultimately guides and constrains physical architectures
• Serve as an orientation to manage the complexity of a domain or subject area
• Guide and constrain the design, evolution, and implementation of domain or subject area physical architectures

Before we walk through the creation of a RA and its core components, be aware there are various approaches to what entails a RA. The foundation of a RA here is referenced from the DoD Reference Architecture Description for its five main components of strategy, principles, patterns, technical positions, and vocabulary. However, what is important here is why a RA is created and who are the people that develop an actionable RA.

A reference architecture (RA) is higher level of abstraction used to establish the necessary components to guide and constrain the physical architectures. Reference Architectures will guide and constrain segment or solution architectures. The RA will specify the five logical areas for adoption towards the development and implementation physical solutions. An organization, community, or enterprise will comply with the established RA, using the RA’s strategy, principles, patterns, technical positions, and vocabulary.

Examples of Reference Architecture

A practical reference architecture is one that is focused down on a predetermined line of business, domain area. For example, in an areas such as human capital, financial management, specific RAs can be developed to guide and constrain those specific subject areas. Likewise, a RA can focus on capabilities that are a result of technology services for example, desktop computing and collaboration; identity, credential, and access management; or data management.

Business Value of a Reference Architecture

A reference architecture is tied to an organization’s overall strategic plan for mission, vision, and goals. The RA helps organizations manage the complexities across the enterprise in various ways such as:  

• Creating enterprise level logical model developed by stakeholders
• Guide and constrain physical architectures
• Enable organizational use as mission, business view
• Socialize and serve as community reference to other RAs

Cataloging Reference Architectures

As an organization establishes a specific RA, other RAs will normally be developed to guide and constrain other segment or solution architectures to manage the complexities of their organizational portfolio of business, capability, and technology domains. Eventually, an organization will have a catalog of key RAs that are in the process of developing, using, updating, or creating to manage the segment or solution architectures. The catalog of RAs are not standalone areas of guidance, but rather each have relationships to each other, and will demonstrate a greater picture of an organization’s enterprise portfolio.

Who Creates a Reference Architecture?

 A combination of mission, business, and technical stakeholders bring expertise to the development of a RA with their individual areas of expertise, concerns, and shared enterprise experience. It is their contribution as a sharing of intersecting goals, business or technical concerns, and ultimately a finished reference architecture that is a result of community involvement as opposed to one group developing the RA and then delivering as a product developed in isolation. Less success of the RA will be realized, more of a shelf-ware document will be realized. It is much more effective, and efficient long-term to build consensus through the development of a reference architecture. Here is an example of who should be included (other stakeholders as necessary should be added as necessary):

• Senior leaders
• Line of business subject matter experts (SMEs)
• Architects ­– Chief, Enterprise, Segment, Solution
• Functional Managers – Domain-specific
• Program Managers – Domain-specific

Motivation & Contribution Through Stakeholders

For organizations to develop a RA collectively, it helps to pre-arrange the foundational activities among the desired stakeholders. Surveys, questionnaires, community visits and other forms of communication to assess, and shape the activities necessary for developing a reference architecture. Some of the reasons for engaging stakeholders early and often is to:

• Enable multiple types of expertise to establish the five major components
• Minimize stovepipe development of RA with community involvement
• Allow their contributions to enable enterprise buy-in from the beginning to operational
• Establish focal point for physical architecture insertion and governance

Setting the Scope & Focus of a Reference Architecture

Contributors and stakeholders must consider what is sensibly manageable when the group develops a RA. It also practical to set versioning along with focus areas of the RA in a way that defines what can be accomplished to become operational for physical architectures to align and comply with. Focus areas are higher priorities within the RA scope to manage expectations through the development of the RA. As an example, in the case of a desktop RA would be to manage the complexity in a first version to agree on what is easily achievable, or critically important for the physical architectures to implement. A desktop RA in a community or enterprise level, might need to have user mobility, unified collaboration, or a common email platform as an initial version.

Achieving RA’s Five Essential Components Through Community Development

A reference architecture targeted to a segment (e.g., human resources line of business), or a solution architecture (e.g., desktop computing) should be developed with strategy, principles, patterns, technical positions, and vocabulary to set the stage as a foundational structure and method for all RAs. While there are various methods, and components that can be used to develop RAs, the following five components are referenced here from the DoD Reference Architecture Description, June 2010.

Strategic Purpose

This component clarifies the scope, focus areas, objectives, and purpose of the reference architecture. It identifies the key stakeholders, and subject matter experts, and other major contributors. It also lists the issues to overcome, capabilities to achieve, and strategic alignment to the high-level strategy. What is key for this component is to establish the domain or subject area the RA will cover that is tied to organizational strategy, and also used for traceability plus validation over time.

Community RA Contribution to Strategic Purpose: Draw-in key strategic objectives collectively, categorize as key RA intentions, arranged as enterprise, mission, business, security, and technology types.

Principles

Principles are high-level guidance strategic ideals that provide a basis for decision-making throughout an enterprise and inform how the organization sets about fulfilling its mission and vision. Such enterprise-level principles are a means of harmonizing decision-making across an organization. Principles are a key element in a successful architecture governance strategy. A reference architecture sets the principles at a high level for domain area rules, values, and other.  The principles are also tied back to domain or subject area requirements. 

Community RA contribution will form Principles that are:

• Tied to organizational, business, mission, and technology strategy
• Expression of desired outcomes of physical architectures
• Expected value to stakeholders

Patterns

An architectural pattern serves as a reusable solution to a common recurring problem. A problem is expressed in terms of what is to be solved in a predictable, repeatable manner. In the case of a the RA, it might be an area in the human resources lifecycle such as payroll; or it could be a common, enterprise desktop scenario where the strategy is to unify desktop computing across the enterprise. Architecture patterns that are specific to a domain or subject area RA should include high-level aspects of the enterprise’s business and technology relationships to serve both the strategic and physical intentions. Architectural patterns can be expressed in variety of appropriate models or text-based descriptions.

Community RA Contribution to Patterns: Required, or easily achievable enterprise, mission, technology scenarios that depict desired outcomes, and target physical implementations.

Technical Positions

Technical positions make up the doctrinal, operational, business, technical, or industry implementation guidelines, which engineering specifications are based, common building blocks are established, and solutions are developed.

Technical positions are derived from a collection of the doctrinal, operational, business, technical, or industry standards, implementation conventions, standards options, rules, and criteria that can be organized into profiles that govern solution elements for a given architecture.

Community RA Contribution to Technical Positions: Identifying and gathering mission, business, and technology constraints as in the form of a list, category, taxonomy, or ontology construct.

Vocabulary

A domain-specific, or a subject area that makes up a reference architecture will have relevant vocabulary, which provides the acronyms, terms, and definitions.  It enables a common understanding of terms and consistency for stakeholders, and provides guidance for segment and solution architectures. The RA’s vocabulary highlights the importance of a common lexicon as key content of a reference architecture.

Community RA Contribution to Vocabulary: Identifying and gathering mission, business, and technology terms, language, definitions in the form of a list, category, or taxonomy construct.

Using Modernized Methods to Streamline the Work of Reference Architectures

The discussion in this article is mainly focused on the DoD’s prescription for creating reference architectures, and the five logical components needed to establish for the physical segment and solution architectures. This approach is intended is to provide guidance for the various DoD-type of RAs to manage the complexities of the overall portfolio of domains and capabilities in the Department.

To extend the DoD RA Description, it is worth considering newer methods such as Agile for technology considerations, Scaled Agile Framework (SAFe) for enterprise scaling with multiple teams, and Digital Engineering for model-based systems engineering (MBSE). These methodologies baked into a RA in key areas such as principles, design patterns, or technical positions can add significant enablement of delivery to an operational state described in a segment or solutions roadmap.

Follow on Recommendations & Activities

Now that a reference architecture has been developed for a specific subject area (e.g., desktop computing, HR payroll), much of the challenging work at this stage is documented but is not fully completed just yet. The work of enterprise architecture continuum is not over. The next areas of involvement will be to promote the reference architecture to the greater organization by the RA development team. At least two key areas are necessary to ensure a successful version RA release. First, begin by informing the senior leadership that sponsored the effort on what the RA is, the vital components that were developed, and its ultimate value of managing the complexity of the targeted operational architectures. Recommend to this senior group of their valuable communication efforts are regularly needed to promote the RA enterprise wide in appropriate forums.

Second key area is the intended integrators of the reference architecture. It is this group who will implement what the RA is guiding and constraining in their subject area for segment or solution architectures. This key group is typically made of integrators, technical managers, project managers, and others. Inform and advise this key group that through appropriate forums such as architecture, engineering review boards, and other key governance venues that alignment and compliance to the reference architecture will be part of the review and approval process.

Summary

 An organization’s catalog of reference architectures are key enterprise instruments that provide ties to strategic performance, mission deliverables, and effective technology agility. Much like an organism’s amino acids, the active physical components in an organization need guidance and constraint from reference architectures. RAs are an implementation reference similar to RNA, which organizations need to work with other business, mission, technology lines of business in an organization. Much more important are the valued contributions by stakeholders who, each add their strands of connective expertise.  

 

Bibliography

Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I., & Shlomo, A. (1977). A Pattern Language: Towns, Buildings, Construction.

Burns, Ken (2020). The Gene: An Intimate History. https://www.pbs.org/kenburns/the-gene/

Department of Defense. Reference Architecture Description. (2010). https://dodcio.defense.gov/Portals/0/Documents/DIEA/Ref_Archi_Description_Final_v1_18Jun10.pdf

Griffiths AJF, Gelbart WM, Miller JH, et al. (1999). Modern Genetic Analysis. New York: W. H. Freeman. The Nature of DNA. https://www.ncbi.nlm.nih.gov/books/NBK21261/

Muller, G. (2008). A Reference Architecture Primer.

https://pdfs.semanticscholar.org/f5ba/ac466fd37e8b530d40cfedb7bf31c4320680.pdf?_ga=2.130566927.1249441080.1586100417-1814754208.1583241142

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

Stevenson, Richmond. EA and Agile Teams. https://eabok.org/perspectives-on-ea/ea-agile/.

The Open Group Architecture Framework. Architecture Principles. https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html