Blending DevOps culture with Cloud Native Technology and Platform Engineering is a great way to boost your DevOps initiative to new heights! In this post, the nvisia DevOps team, in partnership with enterprises large and small, has had a front row seat on many DevOps adoption journeys. Today, we share some tips, tricks and hacks to help those who are striving to become elite performers.
In the previous blog post we talked about the business value and struggles associated with DevOps adoption. In this post we turn our attention to the nvisia Cloud/DevOps team's secret sauce.
#1 Adopting the 3+1 View of Cloud Native DevOps
Many organizations make the mistake of thinking DevOps is done after they establish a few CI/CD pipelines. Stopping there leaves a lot on the table. In fact, we dare to say those organizations missed the point of DevOps.
While DevOps culture and practices are a critical component of succeeding in a cloud native DevOps world, they are not the only thing. To get "elite performer" results, DevOps needs to be blended with other enabling aspects into a broader initiative that, like any great enterprise evolution, can be presented in terms of people, process and technology.
So for our first tip, the nvisia DevOps Team presents the 3+1 View of Cloud Native DevOps as shown below. We use this approach to re-frame our client conversations regarding DevOps adoption, assessments and roadmaps. Here we blend aspects of Cloud Native (Technology) with DevOps culture (Process) and Platform Engineering capabilities (People) into an Agile implementation to quickly establish flow to deliver value in each sprint.
Each of the pillars need to be raised together to achieve meaningful capability improvement within an enterprise and move the needle on specific business goals. Please note the +1 Agile Implementation at the base of the diagram. Agile adoption is the lynchpin for an organization moving from knowing to fully understanding Cloud Native DevOps. You can't fake it forever - every sprint you dig deeper and understand more.
#2 Agile Adoption of Cloud Native DevOps
This means organizing work across enterprise departments as epics and features, then grooming a backlog of prioritized stories/tasks for each sprint. This can be really hard. Keep in mind that each sprint needs to measurably move you toward achieving a new or improved capability that brings business value. For example, a business goal may dictate that experiments need to be run every week to support product management. That means that you need to be able to release at least once per week without impacting the end user's experience. So, what are you going to do in each sprint to get the organization closer that goal?
Depending on your Agile process skills and maturity, making this work can be more or less challenging. As a bit of inspiration, we provided a partial sample of a Capability/Goal matrix below. For each of the Capabilities shown, we list some key business goals and a definition of done. Another really important consideration is the cross functional participation required to be successful. For more on that, please see the next tip.
#3 Make sure all the seats are set at Cloud Native DevOps Table
From the beginning, identify all of the seats at the table (RACI style) + Tools adoption and training related to each area. Make sure these areas are represented during each sprint so the organization can share the journey with a common purpose. Otherwise, most folks will try to do too much at once and step on each others toes. The main purpose is to create a cross functional team that will start to punch holes in the silos and eventually knock them down. Below is a partial view of a capability planning tool we use at nvisia to align goals and roles across the enterprise. It can be helpful to identify epics and plan a series of sprints.
Please note that Operations, Risk/Compliance, Enterprise (cloud) Architecture, IAM and Data Management functions are omitted for brevity.
#4 Establish (cloud) platform engineering capabilities
Establish platform engineering capabilities as the hub between all enterprise functions. Generally, the platform engineering capability exists to implement reusable tools and self-service capabilities with automated infrastructure operations (IaC and Pipelines) to improve the developer experience and productivity. The enterprise benefit is fast deployment of reference architectures using standardized tools, components and automated processes.
In this model, specifications are realized as code and consistently applied to all application team landing zones. Hence, this group is responsible for collaborating with Security, Networking, Operations, Compliance/Risk, and Enterprise (cloud) architecture to evolve the enterprise posture of applications and also to make compliance/performance of such specifications observable to the same constituents. Application teams can shift left by using the approved resources from the platform engineering team.
#5 Look for accelerators
Tap into experienced resources who have been involved in a journey to cloud native DevOps. These could be pockets of resources within your existing organization (maybe from acquisitions) or external experts like nvisia 😎. Additionally, look for accelerators (detailed working samples that often include IaC) to lift cloud architecture and cloud native technology. While accelerators should be sought to inform your perspective and educate your teams, be very careful about going all in on any particular one. Many are academic or may lock you into a vendor solution.
At nvisia, we have developed a practical proven variation of the Cloud Adoption Framework (CAF) accelerators for both Azure and AWS. We call it Digital Foundations and use it to get our clients up and running faster with less rework. Bringing a prebuilt library of proven components (IaC code and pipelines) to realize architectural best practices can reduce timelines from years to months!
Click here to learn more about Digital Foundations.
Conclusion
Cloud adoption journeys are filled with promise and challenge. Look to build a strong Platform Engineering team to own the effort, rely on infrastructure as code, and move to a hub-and-spoke model to enable teams, without constraining them.