Accelerate release lifecycle with pathway to deploy: Part 2

As enterprises embrace cloud native and everything as code, the journey from code to production has become a critical aspect of delivering value to customers. This process, often referred to as the “pathway to deploy,” encompasses a series of intricate steps and decisions that can significantly impact an organization’s ability to deliver software efficiently, reliably and at scale.

The first post in this series navigates the complexities and uncovers the strategies and target state mode for achieving a seamless and effective pathway to deploy.

This post expands on the topic and provides a maturity model and building blocks that help enterprises accelerate their software supply chain lifecycle in the ever-evolving landscape of enterprise cloud-native software development.

Pathway to deploy roadmap

To realize an accelerated pathway to deploy, there are several moving parts and stakeholders that must come together. We recommend a 4-stage roadmap for implementation, as shown in the figure below.

Stage 1: Development automation

Infrastructure automation (IaC) and pipeline automation are self-contained within the development team, which makes automation a great place to start. In this stage, the focus is building an enterprise catalog of continuous integration, deployment and testing (CI/CD/CT) and Ops patterns with necessary tooling integrations to automate core development and testing activities. Given enterprise complexity, the most difficult part of this stage is the automation of testing capabilities (wherein test data preparation and execution of test cases across multiple systems is mostly semi-automated). Overall Cloud Capability Centre (CCC), or the equivalent core team, plays a significant role in driving change with application and platform teams.

Stage 2: Institutionalize pattern-driven model

CCC (or its equivalent) works with the architecture board to establish a suite of repeatable patterns (including atomic patterns representing individual cloud services, as well as composite application patterns comprising of multiple cloud services). The architecture review process (along with other related review processes) is modified to institutionalize pattern-centric architecture representations with a backlog established for different groups (such as platform engineering and CCC) to build these patterns as code. This helps adoption and acceleration. Over time, the applications being represented appear as a set of patterns that standardizes development models across the board. In addition, teams such as business continuity, resiliency and security will leverage those patterns (for example, highly available multi-region architectures) to recognize and accelerate approval gates with a standardized approach. They key to this alignment is the co-creation of these patterns between participating organizations.

Stage 3: Self-service and cross-functional integration

Enterprises have many organizations that want to see that cloud applications follow their guidance and best practices. This stage focuses on integrating cross-functional teams (such as security, compliance and FinOps) through automation, tooling, codified patterns or self-service options. This builds on the earlier stages to emphasize meaningful participation between teams. The key aspects of this stage are to:

• Build and align high-availability patterns with resiliency teams where reviews get accelerated, demonstrating adherence to these patterns.
• Codify security and compliance requirements into the patterns and guardrail them on the platform as set of policies.
• Address validation by integrating tooling, such as vulnerability scans, policy check tools (like cloud formation guard for AWS) and container security with the pipelines following shift-left principles.
• Enlist enterprise records teams to study a set of data classification and retention patterns and enlist FinOps teams to assess for appropriate tagging and quota adherence.
• Build AuthN/AuthZ integration patterns that abstract nuances and standardize authentication and authorization of applications, data and services.
• Automate firewall via generation of resource files from IaC execution & importing them to firewall systems as described here.
• Platform Engineering enterprise catalog offering multiple self-serve capabilities.

Stage 4: Automated pathway to deploy

This stage focuses on decentralization and decoupling of various enterprise groups while simultaneously integrating them through automation and DevSecOps. One example is the automation of change management processes, including automated release notes generation, where the system autonomously constructs comprehensive change review checklists by aggregating data from multiple interconnected systems. This results in trust, efficiency and accuracy in reviews. This holistic approach represents a significant leap in operational efficiency and risk mitigation for the enterprise.

Pathway to deploy: Building blocks of the cloud-native model

Let’s explore a few use cases that showcase pathway to deploy acceleration.

Use case 1: Persona-centric IaC codification

Persona- and patterns-based IaC codification can accelerate both development and review phases. The figure below represents multiple stakeholders in an enterprise who have different concerns and requirements for cloud native workloads.

It takes a lot of development time for product teams to manually code for each of these concerns, not to mention the time it takes for stakeholders to manually review each area. Codifying these in hardened discrete or composite patterns provides product teams the right Bootstrap code and acceleration, creating stakeholder trust and review efficiency.

Use case 2: Shift-left security and policies validation

Automate security, compliance and other policies for infrastructure as part of CI/CD pipeline. This ensures that deployed infrastructure will be aligned to enterprise policies even before it is deployed. There are multiple approaches provided by cloud providers and open-source tooling that can accomplish this (including Checkov, Cloud formation guard and cfn-nag). Typically, security teams codify policy validation rules, and product teams integrate policy validation within CI/CD/CT pipelines before the infrastructure is provisioned to cloud environment.

Use case 3: Automated compliance evidence collection for reviews

Cross-functional cloud platform, security and compliance teams build automation that enables evidence collection, accelerating security and compliance reviews. This would typically require leveraging Cloud APIs to query information from deployed cloud resources, as well as building compliance evidence and posture. Such capabilities could allow product teams to execute such automation in a self-service model or via DevOps pipelines and identify compliance posture, along with capturing review evidence automatically. The maturity level increases when evidence capture is executed automatically and the review is in a completely hands-free mode.

Use case 4: Integrated patterns and pipeline toolkit

Composite cloud-native patterns like AWS Active-Active Serverless APIs require several discrete patterns to come together. These patterns include:

1. Cloud services, such as Route53, API Gateway, Lambda, Dynamo DB, IAM, CodeDeploy, CodeBuild, CodePipeline and CodeCommit.
2. Nonfunctional Requirements, such as AuthN/AuthZ, multi-region active-active deployment, security at rest and in transit, tracing, logging, monitoring, dashboards, alerting, failover automation and health checks.
3. Integrated enterprise tooling, including Code Quality, SAST, DAST, Alerting, Test Management, tracking and planning.

A one-click solution would allow product teams to select the right pattern, which will create the necessary Bootstrap code that integrates several codified patterns as described in prior use cases.

Pathways to deploy: Delivery approach

For a delivery model to realize pathway to deploy, the CCC (or equivalent) must work with multiple organization groups as shown in the figure below.

Pathway to deploy delivery model would comprise of the following steps:

1. Define the entire path to deploy process through a set of application lifecycle phases, activities, deliverables and dependent groups involved.
2. Define and standup multiple squads focusing on different aspects on the pathway to deploy.
3. Plan fora flex model within the squads to bring in supporting groups as required.
4. Build a backlog for each of the Cloud Capability Center squads and initiate capability development.
5. Align to the 4-stage maturity model so enterprises can track maturity.
6. Establish product teams and relevant stakeholders as part of the backlog refinement and prioritization.
7. Ensure that automation adoption is continuously focused. The success of pathway to deploy depends on building the automation and getting it adopted.
8. Build central knowledge management and planning management around pathway to deploy.
9. Make it easier for product teams to incorporate these activities into their delivery plans (with for project tracking and agile collaboration tools such as Jira).
10. Build a measurement system for pathway to deploy phase gate SLAs and continuously track SLA improvement (as pathway to deploy capabilities mature over a period).

By considering why cloud transformation may not yield full value, and identifying release lifecycle acceleration as a key challenge, this narrows down the focus to pathway to deploy. Pathway to deploy can be a common vehicle that facilitates multiple groups to accelerate the entire software supply chain lifecycle beyond the development and testing lifecycle acceleration that exists today. A 4-stage roadmap has been defined where initial stages focus on DevSecOps and patterns adoption, and advanced stages mature towards product engineering culture. It is recommend that product teams collaborate with participating enterprise groups in a decentralized manner to leverage automation and self-service. The maturity model encourages organizations to incrementally scale by starting small, and our delivery approach brings predictable outcomes to this complex journey.

Source: ibm.com