Reference Architectures

Last updated: August 16, 2022

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 architecture process

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. For instance, the IAM team may leverage the Brick lifecycle method to develop an IAM Web Authentication Brick reference architecture. That reference architecture may be developed in consultation with customers and serve to guide users that are planning solutions that rely on IAM services.

Below are the current reference architectures.

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.

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 team
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 Director of Enterprise Architecture and Strategy
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.