Reference Architectures

Reference Architectures (RAs) are documents that guide decision-making to maximize architectural value within a defined scope.

Reference Architectures, Architectural Methods, and Solutions

Reference architectures help implementers maximize the architectural value of the solutions they design, based on the long-term goals and needs of the UW. They help designers and implementers leverage the lessons-learned and knowledge of experts by sharing the vision and designs of the experts through common language.

Reference architectures will be defined at various levels of detail, from high level principles to detailed implementation guides. “Guardrail” documents can be developed to address multiple levels of reference architecture related to a topic such as integrations, reporting, or security.

Teams employ architectural methods to develop reference architectures that serve to provide useful guidance for a given scope with a given lifetime.

The Reference Architecture Process

The Reference Architecture Process enables the University of Washington to establish reference architectures. The process determines the scope, authority, and applicability of each reference architecture, guides its drafting and approval, and ensures its publication, use, and eventual retirement.

The Reference Architecture Process is intended to:

• Enable the UW to establish reference architectures that are sponsored by key decision-makers and supported and understood by people in the areas where each reference architecture will provide the most value to the UW
• Make clear the official current version, status, scope, authority, and applicability of each reference architecture
• Enable reference architectures to be established quickly and revised as needed
• Make it easy for people applying a reference architecture to obtain further guidance (or review if needed) and propose improvements to the reference architecture

Reference Architecture documents themselves are not so important as the process of UW stakeholders coming together to construct those documents and, in so doing, converge on common solutions. The documents represent the product of building a common approach across stakeholders as much as they serve as a guide for implementations.

For that reason, appropriate and sufficiently broad representation in RA teams is critical to the success of getting to common and shared solutions. It is the responsibility of the EA program to encourage processes and provide tools and frameworks for that collaboration to take place.

Reference Architectures and Projects

The Reference Architecture Process can be triggered in multiple ways.

The Reference Architecture is a deliverable of a project

In order to maximize the ongoing value of a project, architects may include an RA as a deliverable to communicate a new architecture to multiple stakeholders in a simple and repeatable manner. This is the more common case.

Example: a deliverable of the API Access Management Modernization effort is to provide clear guidance and even example source code to teams to understand how to implement OAuth2 for system-to-system access in the UW environment in place of the prior mutual TLS approach.

The Reference Architecture is the project

In other cases, architects and other stakeholders execute a project to research, design, prototype, and even implement a new architecture.

Example: multiple application and infrastructure teams identify a need for a more flexible compute platform than standalone VMs and propose a container-based application architecture project.

Roles in the Reference Architecture Process

Multiple roles are involved in establishing and updating reference architectures (RAs). Briefly, their accountabilities are:

Activity	Accountable Role
Identify the need for a new RA	Enterprise Architecture Domain Council
Prioritize potential RAs and decide which ones to develop next	Enterprise Architecture Board
Ensure that the architectural decisions in each RA are consistent with enterprise strategy	Architecture Management Practice Owner
For an area of the UW: Provide or delegate input on the content of an RA Commit resources to participate in the RA drafting process Lend authority to the decisions the RA contains Champion the RA to ensure implementation decisions are consistent with it	Reference Architecture Sponsor*
Arbitrate implementation questions or new issues as they arise	Architecture Review Board identified for each RA
Oversee implementation decisions consistent with the RAs	Architects, designers, and other implementation decision-makers

*The name of this role may vary by type of reference architecture — for example, Guardrail Sponsor for a guardrail.

At each stage, input should be considered from multiple sources; the above are just the roles with a key responsibility at each stage.