DevOps implementation – lessons from the practitioner’s lens
Blog: Capgemini CTO Blog
Successful DevOps transformation almost always requires significant changes in work culture at both macro and micro levels. Client leadership’s ownership of – and close participation in – the entire transformation are essential elements for success.
I’ve had the pleasure of being part of countless dynamic client DevOps transformation journeys and these experiences have provided me a with host of invaluable lessons. In this blog I discuss what I’ve learned and how you can apply this to address common challenges transformation teams face and expectations from leadership.
Typically, clients jump-start their DevOps journeys with a core consulting team that is tasked with conducting an initial DevOps assessment and laying out a DevOps roadmap. This is followed by building out DevOps pipelines and implementing pilots, along with gathering metrics and KPIs, trainings, and enterprise adoption.
To ensure a successful transformation, the core DevOps team requires client participation in obtaining:
- Current-state information and timely access to the client’s ARB (architecture review board) for process approvals
- Client’s infra/cloud teams for setting up environments for installing tools for DevOps pipelines and hardware and software licenses for these tools
- Business (product owners) approval for backlog management and coordination across multiple vendors and CI/CD workflow approvals
- Change control board (CCB) approvals for production environment changes
- Security approvals for tool/process/interface changes and access to environments and the pilot team’s bandwidth
Challenges in gathering current-state information
Assessing your maturity in SDLC functions (version control, build, testing, deployment, environment, and operations) is essential in building a baseline for DevOps transformation. The challenges in gathering this information include procuring adequate time from different teams, along with juggling functions that are being served by different vendors. Additionally, teams could be widely dispersed across geographies and there may be a lack of or insufficient documentation or team buy-in for sharing information due to job security fears.
Delays in process changes and workflow approvals
When it comes to ARB approvals, the DevOps team might recommend new CI/CD processes and/or suggest changes to existing processes. With many clients, the ARB meets once every two weeks or once a month. The DevOps team must wait to get process changes approved before their implementation.
With client security approvals, the DevOps team recommends new CI/CD processes and tools that might require security team approvals. The security clearance process here is generally long, elaborate, not Agile, and can consume lot of effort. CCB approvals entail changes in client production environments that require CCB approval per ITSM/ITIL processes, which could be long and time consuming.
DevOps teams require access to all their environments: DEV, QA, STG, and PRD. To obtain login access to these environments takes a long time and some cases might require background checks and drug tests for core team members. These tests often take longer for offshore core team members. Many clients require changes to production deployments to be approved. The approvals process might be drawn out due to regulated environments, security concerns, unions, maintenance windows, marketing campaigns or sales promotions, etc.
Hardware and licenses for DevOps tools
The DevOps team requires hardware to install DevOps tools in Dev, QA, STG, and PRD environments. They require licenses or support contracts for some of the commercially available tools – and the procurement and installation for this new hardware and tools can be a drawn-out process.
Currently, it’s quite common that clients outsource IT tasks to multiple vendors. These vendors could be geographically dispersed, and the core team may be required to interact with them to attain current state information, collaborate on changes to CI/CD processes, work on pilots or adopt new processes and gather metrics. These vendors vie for the client’s business but have competing interests. Many times, collaborating with them in a timely manner can be daunting.
Release planning and business involvement
DevOps and Agile transformation go hand in hand. Clients must staff new roles, namely, product owners (POs) and Scrum Masters. As DevOps pipelines and processes are set up, product owners should begin to build portfolios, epics, and story backlogs for sprint teams to work on using the new DevOps processes. Leadership might need to be trained on Agile to build enterprise agility throughout all shared services. Delays in backlog management could cause delays in DevOps transformation.
DevOps team pressures
Generally, the DevOps core team does not account for any time for these delays and is under constant pressure to deliver per their promised transformation plan. There is pressure to show early wins to the client, while their employer wants to show a solid ROI to leadership and the business and win the hearts of fence-sitters. The team must work long hours to show progress and meet deadlines when overcoming these challenges.
How can you drive your DevOps transformation towards success?
The shared services team should work in Agile mode, so the required support can be provided in a timely manner. Workflows should be automated where possible to eliminate or minimize human approvals – and traceability for tasks for audit purpose should be built into CI/CD workflows. By taking the above recommended measures, DevOps core teams can work their plan uninterrupted and drive your DevOps transformation to successful fruition.