This paper talks about moving toward a realistic and functional DevOps culture from current dev and ops model without creating a huge disruption in ongoing business.

What does DevOps mean?

We have come full circle! With the advent of IT in the ‘90s, when software development and delivery was evolving, we had a “DevOps” model running very well within the organization. The ownership of development, quality testing, deployment, and fixing production incidents lay with the developer and developers were not far away from operational nuances of the applications they developed. With IT maturing in two decades, and huge development requirements pouring in, and also to some extent, realization of difference in skillsets required for all the activities of the PLM cycle, the need for different roles for every step in the software lifecycle management was felt. This led to the bifurcation of roles and tasks done; we now have IT Development doing software development and Operations taking responsibility of the run part. This resulted in more hand-offs and hence is more time consuming. The outcome is conflict between the continuous changes IT development is bringing and operations’ need for stability making them resistant to change. The net outcome is that, the sponsors (business) are looking at two teams having regular conflicts, hence neither realizing the business needs on time nor ensuring the right stability.

DevOps as a Solution

And now, again, we are looking for a solution to provide business with change and stability in parallel. Everyone wants to move toward a setup of dev and ops together, aka DevOps. Why? Well, there are four prime reasons for it-

1. Faster Roll-out of products: With customer needs changing every other day, there is pressure on the IT side to roll out changes and new features faster with maximum intersection between development and run teams
2. Ownership of product: With change in operating and delivery models, the ownership from development of a product to deploying it to providing operational support (monitoring alerts & proactive issues fixes), everything will be owned and contained within one single team i.e., DevOps team.
3. Infra into cloud: with Infra sourcing model changing to Cloud and most of the operations tasks being automated, the need for having a huge operation team is getting lost
4. Cost pressure: Telcos have huge pressure to contain their Opex cost, optimize team size

Misconception: And while we are at the DevOps concept, it becomes important to establish a clear difference between DevOps and CICD. There is a misconception around DevOps as implementing CICD pipeline

• DevOps is a change in Ways of working, a setup where development and Operations come with one single ownership and are done together with smooth collaboration in tasks from the development side to operations and vice-versa.
• CICD is one of the automation tools that helps in achieving the DevOps ways of working.

Approach

The approach to achieve a functional DevOps culture can be done in three stages-

1. Assessing As-is Ways of working of an organization

• Understanding current Operating model- How the organization is structured, what is the current delivery method- Agile/waterfall, understanding the current team structure, skillsets present within the team- accessing how many are open and willing to cross-skill and upskill themselves
  
• Identifying patterns and logical groups based on skillsets
• Doing an evaluation on potential next stages and plan

3. Create building blocks to move toward To-be model

• DevOps – deciding on new activities and responsibilities With few guiding principles applied, such as below, we need to come up with a new set of responsi bilities and ownership of processes moving toward erstwhile development teams or to-be DevOps
  • Activities which are closely related to current development/scrum teams are taken as first list for DevOps
  • Activities needing 24*7 support should stay with Operations Team
  • Core infra related activities to stay with operations
  • Security related activities could stay with security operations
  • SoP based problem solving to be executed by Operations while others are investigated by DevOps
• Bring in more ownership & Agility to the Development teams. This could be done by creating ownership of few E2E processes entirely by one team, such as- Release & Deployment process

Implementation steps

Following steps are enablers to implementing effective DevOps –

Creating a Feedback Loop

DevOps in itself is a continuous improvement in ways of working. It is of utmost importance to enable feedback mechanism

• From a Business point of view, constant feed back on Right first time and on improvement of product launches.
• From the DevOps teams side, efficiency brought in by tools and also further streamlining of processes
• From the operations side, continuous automation of anything that is repeatable and more movement efforts spent on DevOps activities
• From teams for changes, toolsets and processes being introduced to them
• From stakeholders, sponsors on the effect on Opex reduction, plus experience with the end customer is post inducing entire ownership to a single team.
• From IT all together, in terms of how automations and optimization is helping them

With this, we can develop a good feedback and communication mechanism to work on and improve on those to cultivate a stable IT setup.

Gradually, we will see a decline in manual efforts being spent on most operations tasks and almost everything being automated. This would eventually lead us to our nirvana stage of “No-Ops” support at all; thus marking the successful completion of realistic functional DevOps and moving toward End State.

An initial step toward realistic DevOps culture can be stated as success, once the below parameters are showing improvements:

• Faster release and deployment
• Right first time and speed in incidentresolutions
• Improvement in automation levels
• Maturity in Knowledge Management
• Processes getting leaner and executed withminimal exceptions

Once this reaches acceptable KPI levels, the organization can move forward to full-fledged DevOps with the entire automation suite in place and then toward the final journey of No-Ops.

Ajai Ramachandran

Partner, Communication BU, Wipro Limited.

Ajai Ramachandran is a Solutions Lead heading the Transformation program, T-Mobile Netherlands as part of the Communications BU. He has 19+ years of experience working with various service providers across world.

Mansi Dubey

Consultant, Communication BU, Wipro Limited.

Mansi Dubey is DevOps consultant working for T-Mobile Netherlands, Transformation program as part of the Communications BU. She has 6+ years of experience working with various service providers across Europe.