Reference architecture & patterns for cloud transformation — Accelerating target operating model change

As one looks at transformation of applications to cloud (mostly from on-premise / traditional systems), many people talk about reference architectures as well as patterns. For most complex enterprises, its a journey from a traditional operating model to a newer cloud operating model. Successful cloud transformation initiatives always drive continuous re-alignment of the target operating model along the application transformation initiatives. Reference architectures and patterns play a pivotal role in transforming to a new cloud operating model. Lets examine how:

Reference architecture (RA) and patterns provides recommended designs, structures, integrations and related artifacts that align to enterprise standards and best practices. RA and patterns helps abstract a problem and describe the solution in the form of a solution architecture, assisted by codebase that developers can leverage while implementing the pattern. Patterns could be of multiple types — atomic or composite patterns. While atomic patterns describe the application component technology considerations (based on enterprise standards and guidance), composite pattern describe a repeatable solution aspect. Patterns are accompanied by key considerations, usage guidance, applicable cloud transformation dispositions etc. Each of these patterns map to one or more sun-risen service in the cloud platform along with automation code snippets for leverage by application teams. Generally, these code snippets will contain security / operational / monitoring configurations as appropriate. There could be multiple aspects of guard-rails ranging from security & policy configurations, monitoring & alerts on inappropriate usage of the services etc. Following diagram depicts various dimensions & consumers of RA & patterns.

Reference Architecture & Patterns: multiple dimensions and concerns

Reference architectures and patterns are central to how teams across the enterprise operate and communicate designs, implementation specifics, plans & timelines between each other. This also means that the reference architectures and patterns need to accommodate multiple perspectives that address needs of various enterprise teams. In doing so, it address the following concerns:

• Code for devops integration and infrastructure as code for automated provisioning & configuration of cloud services that the pattern leverages
• Monitoring policies & configurations integrated into infrastructure as code including integration to monitoring dashboards
• Implements security concerns such as authentication / authorization integration points, encryption (at-rest & in-motion), network / security group configurations, ingress-egress configurations, free-of-vulnerabilities (vulnerabilities scanned & approved) etc.
• Any impact to the business / feature-function offered while using the pattern (external facing front ends etc.)?
• Implements variety of enterprise policies and standards w.r.to GRC (Governance, risk and compliance) — leverages latest set of cloud services, technology options, session time-outs, data classification tags, data restriction design considerations and so on
• Last but not the least — It helps program managers communicate synchronization of backlogs across work streams to ensure timelines of various consumers and creators are met. For e.g. Platform teams sun-rises set of services (per needs of pattern) versus app teams using the patterns and associated platform capabilities

Reference Architectures & Patterns leverage in application transformation to cloud

Typical application transformation engagements have two broad categories of disposition types — Migration or containerization (usually there is a source and then there is a target pattern), and Modernization (RA and patterns apply to target solution components & piece-parts).

For Migration & Containerization, source patterns are typically a description of current state platform, technology or solution abstraction. Target patterns are typically a set of allowed target cloud service / middleware technology option (or variant) or a solution pattern. Target patterns are accompanied by key considerations, usage guidance, applicable dispositions etc. Deployment pattern provides guidance to teams based on application availability and resiliency tiers. One of the key aspect of accelerating cloud transformation engagements is to ensure there are definitive sets of source to target patterns mapping that addresses several aspects highlighted in the diagram below.

Migration & Containerization teams will have to describe their designs through a set of source to target mapping with key transformation considerations. This approach helps synchronize migration & containerization teams with various other work-streams (such as platform teams w.r.to platform and target cloud services availability, ensure tooling availability, data migration approach & needs, developer skill needs for execution team as well as post transformation support etc.). This also ensures better planning & creation of pool of transformation candidate applications given the availability of certain set of target patterns

Source to target patterns and transformation considerations

For Modernization work-streams, what is more relevant is the Reference architecture and patterns themselves — which represents piece-parts of an application or a component. Solution architects describe their target solution in terms of RA and patterns while providing specific customization aspects to address the target functional and non-functional needs. Following diagram depicts a set of exemplar target patterns for a target cloud native solution:

Exemplar modernization patterns

Reference Architectures & Patterns driving agility and speed in cloud transformation initiatives?

Previous sections articulate what patterns mean, ingredients of RA and patterns, how migration, containerization or modernization initiatives use patterns etc. From an enterprise perspective, patterns help automate and streamline various program work-streams and activities from design to build per the diagram below.

Enterprise development lifecycle & acceleration via patterns

Does this resonate with Enterprise DevOps? Yes its an operating model change that RA and patterns bring:

As we examined above, RA and patterns address the concerns of various stakeholders of the enterprise work-streams through codifying and automating their needs. A few examples of how this drives target operating model change:

Reference Architecture & Patterns driving target operating model change

Key highlights how how RA & Patterns influence (or should influence) target operating model change are:

• Synchronizes various work-streams of the organization through the concept of RA and patterns while addressing individual work-stream’s concerns
• Patterns implement various enterprise concerns as-code (Security, data classification, compliance, SRE based operations / monitoring / runbooks etc.)
• Drives ability to infuse significant level of proactive checks-and-balances in the DevOps pipelines (e.g. Cloud formation guard rules based service integrated with pipeline to ensure proactive security checks prior to deployment) which enables various participating work-streams to rely on “data” and move away from “document review culture”
• Helps derive a common architecture and design language that drives common understanding of solutions across various organizations within the enterprise
• Helps drive significant change to end to end development to deploy timelines while moving this to near-cloud-native models in complex enterprises

Conclusion — This article examines the aspect of Reference architecture and patterns from the perspective of driving target operating model change. There are several other levers to drive target operating model change and RA & patterns are just one of them. In subsequent articles we will look at other levers and possibly some code examples too.

Feedback & Comments welcome…. Thanks.