A New Perspective on Architecting DevOps Implementations

DevOps is in focus. As the world moves toward a robust, software-driven future, we are witnessing a rise in the number and scope of DevOps projects. These include a wide range of activities, from large-scale implementations at an organizational level to technologies and solutioning for addressing Continuous Integration and Continuous Delivery (CI/CD) challenges.

Amidst what appears to be a wide range of scenarios, the unifying thread for all DevOps engagements seems to be around the cultural and leadership aspects of the transformation journey.

And DevOps is indeed a journey.

There is an erroneous view that DevOps is just a combination or merger of the development and operations teams to resolve identified challenges. In fact, DevOps is more than a tool for CI/CD. Cultural changes, new ways of working, and revitalized leadership hold the key to the transformation of the team – a journey that is driven and supported by tools and technologies to automate the processes for faster feedback, on-time delivery, and enhanced quality.

Here, I would be narrating the learnings and lessons from our experience of helping a major global customer identify their current state of IT development and operations and redefining their DevOps transformation Journey.

What did it involve?

While speaking with the customer’s leadership, it was evident that the organization was losing its productivity, profitability, and market share due to the inability to deliver IT services to businesses. Their IT was not able to keep its promise of software delivery on time. We identified several concerns across their Software Delivery and Operations (SDO) performance, including:

• Long lead time in delivering the feature to business,
• Lack of business involvement during the development phase,
• Missing deadlines due to quality issues in later stages,
• Lack of automation and too many manual handovers, and a
• Siloed approach across the development and operations teams.

With this challenging scenario in mind, let’s see how we re-architected their DevOps paradigm.

First, Delivering DevOps Leadership – This is the key to the success of the DevOps implementation. We realized that several transformation projects fail due to poor transformation initiatives. This includes:

• Not defining the ‘Why’ part of DevOps implementations,
• Lack of urgency regarding the need for DevOps,
• Poor strategy for DevOps Transformation,
• Not having clear and loud communication with stakeholders,
• Lack of vision and no end goal in the mind, and
• Not thinking through the cultural change.

We worked together to address these issues, ensuring wholehearted leadership support and communicating the transformation plan to the organization through an ‘excess of communication’ (trust me – it’s just what the doctor orders!).

Our teams helped enable people with the right knowledge and right tools to create the right culture.

The revitalized DevOps journey, therefore, begun with an initial evaluation (Due Diligence) of current business and development operations, and delivery practices. We helped draft a good DevOps Transformation roadmap to make the most of the journey along with the customer leadership team.

Secondly, Driving Cultural transformation and Agile – DevOps is really about the people. Organizations often suffer from frozen communication between teams, siloed hierarchical structures, and communication barriers which account for a loss in the end-to-end vision of product development. One of the biggest challenges, therefore, is to measure the cultural need and designing a robust and effective transformation plan.

Agile transformation is the key to changing the habits of the teams to adopt new ways of working and mindsets. Our transformation methodology resulted in around 25 agile teams, called squads, organized into a specific product-based portfolio value stream. Small batches, visualizing the flow of work, frequent delivery, and feedback, brought changes to the mindset of the squads.

Cultural change drives and training camps, and agile conferences were arranged to ensure a complete change in the mindset and delivery processes.

Next in the line, is setting up the adoption of CI/CD practices throughout the organization.

CI/CD Implementation – Our teams helped the customer adopt continuous delivery in an orderly manner across the organization. We undertook a pilot project, measuring its success on each business line and technology by automating and standardizing how the software is deployed.

During this transformation, incremental improvements were undertaken to streamline the release processes. As a result, major deployment risks and pains were identified, and the release process was iterated to ensure extra safety through continuous improvement. Figure 2 9below) shows the typical Continuous delivery pipeline – Source, Build, Test and Production.

                                                                     Figure 2: A typical Continuous Delivery Pipeline – Source, Build, Test, and Production

DevOps, as the collective wisdom goes, is a continuous journey. However, its results are evident from the very start.

While enterprise-level implementation is still on for the instance we spoke about earlier, we have started observing encouraging results through:

• Improved quality in the delivered product with a 50% reduction in defects,
• Increased employee engagement and satisfied developers,
• Improved, strengthened, and extended pipelines,
• Integration of new  to the staging environment for UAT,
• Increase in delivery frequency by 20%, and
• Incremental decrease in lead time (from 90 days to under 60), with growing automation of legacy manual handovers.

Encouraging as the results are, it inspires us to undertake site reliability practices and observation to drive deeper transformation of the DevOps implementation architecting process. By improving pipeline efficiency, application architecture modernization, ways of working, mindsets, and behaviors, the journey will only be strengthened for the benefit of all stakeholders.

A customized Internal DevOps Platform (IDP), capable of extracting a large part of the complexity that burdens DevOps engineers and IT operators can prove to be a game changer here. The idea is that the customer/developer should be able to configure their likable tool with the required license to create a DevOps Toolchain. This would bring developer experiences in continuous learning and experimentation in maximizing the overall DevOps journey outcome, and underscore the joint success of the process.

The change when it happens, would be silent yet powerful one. For after all, the deepest revolutions are often the quietest ones.