Overview

“Re-usability increases the pace of innovation and decreases the number of incidents”

Reference architectures are smaller pieces of architecture, often called design  patterns: chunks of lightweight design that match a specific use case and are related to practical items such as configuration blueprints or deployment scripts. These reference architectures are designed to have the organisation’s internal systems of controls already applied. These building blocks allow different teams across different value streams to skip time-consuming compliance audits and changes processes.​

The development of reference architectures must be closely aligned with the wishes or requirements of DevOps teams, creating de facto standards that increase the pace of innovation. Reference architectures are adapted as new techniques and possibilities arise. DevOps teams can create new patterns which can be promoted to new reference architecture building blocks. ​

Because reference architectures match quality and security requirements, working outside of these patterns may require a dispensation process. Dispensation requests are triggers for maintaining and updating a reference architecture or to evaluate its sustained suitability. The aim of this loop-back is to reduce technical and governance debt, using the reference architecture as a technical guide. ​

The importance of communication regarding the why and how-to of using reference architectures and offering up-to-date information is self-explanatory. Consider using tools like Bitbucket or GitHub with an associated wiki to maintain and publish reference architectures and deployment code.  ​

The CCoE is responsible for management of cloud-services based reference architectures and the associated management tooling in close cooperation with development teams. 

Activities checklist

Initial:

• Selecting tools to facilitate a library to store templates and reference architectures​
• Defining the process governing the creation, management and use of the templates/architectures​
• Capturing existing architecture patterns to be used as building blocks​
• Defining a dispensation process​
• Communicating about the benefits and use of reference architectures and how cooperation with DevOps teams will improve the time to market for applications and services​
• Standardising infrastructure building blocks

Recurring:

• Processing architecture requests and updating library accordingly​
• Reviewing impact of services changes on existing reference architectures and templates and updating accordingly​
• Updating documentation

RASCI