7 Steps to Successful and Sustainable DevOps Transformation

Source – news.sys-con.com

While the benefits are many, the DevOps journey for an established organization can be a long one filled with surprises and challenges. To avoid as many of both as possible, learning from those who have gone before you can help you apply best practices to ensure a smoother path to success. As a result, in this article, I will outline the seven steps to a DevOps transformation as learned through working hands-on with more than 100 leading enterprise organizations to establish and sustain successful DevOps and IT modernization.

Step One: Exploration
The first step is to have a clear understanding of your starting point before you even begin your journey. At this stage, successful organizations raise their situational awareness through better logging and monitoring of their current processes.

The next step is to define your end business goal, i.e., know what you want to achieve from your DevOps transformation. Many organizations feel pressure to transform without a specific end-goal in mind. If this describes your business, I would encourage you to set aside your fear of missing out and instead inspect the following list of common business drivers to see which might benefit you most:

• Reduce time-to-market
• Reduce maintenance
• Increase Information Security
• Reduce cost of infrastructure
• Eliminate downtime
• Increase scalability
• Increase global reach

With a goal in mind, you will be able to examine the business impact ! both positive and negative – on potential technology decisions, which will act as a guiding principle. With answers to these questions in hand, you should then choose a pilot and build a roadmap.

Step Two: Choose a Pilot
When starting on a journey, the first steps must be impactful but small. Impactful is critical because it creates something that has business value and gets the attention you want this first project to achieve. For example, building a best-practices network architecture may seem to be an obvious starting point but it’s not impactful by itself as it does not add business value. It is analogous to building an airport without having any planes to land. You need the planes to demonstrate the value. Small is important because quick wins lead to the buildup of momentum internally. Large, complex pilots face more resistance and can cause the initiative to lose momentum.

When choosing an impactful pilot, the selection criteria for the pilot should tie into the motivation you have for deploying DevOps. For example, if your motivation is to reduce time-to-market, a project with a tight deadline that can’t be met in a traditional framework will prove to be a good pilot. If your motivation is to improve security, a project that enables a previously unattainable security posture (e.g., PCI compliance) can make for a powerful pilot.

Once you have identified a set of candidate pilot applications that can be impactful in the right direction, the next step is to scope the pilot project such that it is small and attainable in a short period of time. While DevOps has many elements, it’s not necessary to implement all of them in the pilot. In fact, our experience is that it is best not to implement more than three or four concepts in the pilot. Which concepts get priority should stem from the motivation you laid out in step one.

Following the selection of your pilot, you’ll want to blueprint the desired state; out of which should come a detailed sprint plan for execution. With a blueprint and sprint plan in hand, teams can begin building their pilot DevOps architecture.

At Flux7 we have built an Enterprise DevOps Framework, or EDF, (seen here) which calls out the technology that should be included in every DevOps blueprint. Think of it as building an execution engine to operationalize your pilot – and future infrastructure.

This DevOps Framework differs from a traditional development and IT framework, calling on developers to accumulate everything needed for a service to execute, and the IT team responsible for assembling and managing service-agnostic landing zones for these services. Traditional tasks like QA are automated with Inspectors (automated tools to monitor services) and service information that may have been previously manually added is now automatically added via Injectors (e.g., secrets management).

Step Three: Design a Solution
Implementation of this framework and the deployment of your pilot requires people, process, and technology. We will address the people in the next step, but process and technology must be defined up front, but only for the pilot.

A critical next step is tool rationalization. To implement the components from the EDF, we typically refer to the tools we call the 4Cs – Cloud, Containers, Configuration Management, and Continuous Integration/Delivery. Each of these ‘Cs’ helps formulate the components in EDF, e.g., CI/CD of code is a part of pipelines. Cloud provides services that allow for the creation of a landing zone, automated infrastructure provisioning through infrastructure as code, and services to inspect the infrastructure. Containers provide a powerful way to package services in a service-agnostic manner and makes it easy to land them in a Landing Zone. With a strong foundation in these elements, teams will be able to begin extending their infrastructure and DevOps culture.

As an example, in its move to DevOps, Rent-A-Center initiated a pilot based around a partner ecommerce portal. Their motivation was to reduce time-to-market and maintenance costs. For it, they created an infrastructure that used the AWS Cloud to provide infrastructure as code, Docker for containers, Ansible for Config management, and Jenkins for CI/CD. This pilot has served as a template around which they have extended their DevOps technology, processes and team culture.

Step Four: Build COE
DevOps is not only a technology and process transformation, but it’s also a cultural transformation, changing how technology teams in the business operate. As a result, having an internal Center of Excellence (COE) is a key to long-term success. A COE should be a small team hand-picked to build the foundation for the DevOps transition and instill DevOps knowledge into the company.

Moreover, the COE is responsible for teaching others in the organization how the new enterprise DevOps framework works. For example, equipping developers with the new knowledge to assemble everything they need to deliver a service – from code and configuration, to libraries and pipeline definitions.

Organizations that begin their COE with a small team of DevOps engineers are most successful. Take for example the case of Verifone, which needed to ensure development, was able to deliver high quality, secure solutions against tight deadlines. In its transformation, it built a COE from a small team of dedicated DevOps engineers who oversaw the unprecedented launch of a brand new line of business in less than one year due to its success in navigating the DevOps journey.

Step Five: CoE Summit
At this stage, CoE organizations should begin evangelizing their success and should ensure they present the concepts and key skills needed for ongoing success to relevant technology teams. One tactic many successful organizations take at this phase is to hold a CoE Summit where they evangelize the importance of and make sure to pass along the important skills needed to support the new infrastructure, applications and culture. Through a summit, these organizations enable change through collaboration and facilitating discussion across key stakeholder groups including executives, operations, development, lines of businesses and other functional leaders to air concerns, establish options, agree on a strategy and manage culture change.

Step Six: COE Helps Dev and IT
This next phase begins the effective transfer of knowledge from the COE to broader development and IT teams. Learnings from successful organizations tell us that knowledge transfer at the end of each sprint is an effective strategy, instilling necessary skills for these teams to manage and expand on the infrastructure moving forward. For example, it is at this stage that the COE should be training IT to effectively manage landing zones.

A large manufacturing organization created a dedicated team, which it called the Cloud-Crafter Team, responsible for hand-holding development and IT in the initial sprints of its DevOps transformation. The team created a development factory based on self-service elements, such as a service catalog, from where development and IT could begin participating in the DevOps transformation.

Step Seven: Modernization
These six steps culminate here with IT modernization. A virtuous cycle of constant learning should be adopted to ensure ongoing success. Just as technology constantly changes and advances, so too must your COE and broader organization. Effective COEs work on the leading edge, leveling up their best practices and tooling when advantageous to ensure the business maintains its modernized architecture and culture.

Having built a business case for DevOps within the organization, effectively piloting it and building a COE for knowledge transfer and ongoing learning and improvement, the organization has established the fundamental steps for ensuring a successful DevOps transformation. Now, this success can be scaled. Whether to new initiatives or other parts of the company, the organization has created a template for successful and sustainable DevOps transformation.

For established enterprises, DevOps transformation may seem daunting. However, organizations can adopt DevOps rapidly by following these seven steps. Effective assessment, solid pilots built on strong foundational technologies and a core COE that spearheads training and ongoing improvement is a time-tested formula for sustained success.