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. 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.
- Architecture Value Scorecard v2
- Container-Based Applications Reference Architecture
- Delete Means Delete
- EA Guiding Principles
- Minimize site-to-site VPNs
- Private IP Addresses for Office Systems
- Security and Privacy Policies
- UX Design Guides
- Workday Guardrails
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:
|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:
|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.