As the DevOps movement gains traction in the enterprise space, there are five pitfalls that CIOs need to avoid to make a DevOps strategy work for their business.
DevOps is an IT practice of merging the tasks performed by a company's application development team and those performed by its systems operations team. It brings the development and operations teams closer together through automation, enabling the business to react to change quickly.
In a traditional IT set-up, the application development team gets a business brief and writes codes and the software program. It then hands over the program to the testing and development team, which tests the apps in isolation. If the testing is successful, the development team sends the program or software back to the operations team to be rolled out to users.
But working in isolation leads to frustration and inefficiencies, with each team not understanding the limitations or challenges of the other. More crucially, IT and the business are both badly affected.
Under the DevOps approach, the teams work together and release smaller, more frequent updates, which helps to increase efficiency, reduce errors and improve IT quality. DevOps practices also tear down the silos and communication gaps that usually exist between software engineers, IT and other parts of the business.
Seeing DevOps purely as an automation activity
The key to DevOps is in automating as much as possible, both in the process of moving a development project through testing into run time, and in how any operational problems are dealt with.
But DevOps goes far beyond that, said Matthew Skelton, co-founder and principal consultant at Skelton Thatcher, which helps enterprises to build and operate software systems. “If you develop a DevOps strategy which involves a special team that is in charge of automation, then you are missing the point,” Skelton told Computer Weekly at a DevOps panel debate organised by managed cloud provider Rackspace.
DevOps involves automating the journey of the code elements from the development team through to the production team and back. It also involves automating the roll back and feedback process for efficiency. “Focusing only on automation will give you just a tiny bit of added IT efficiency,” said Skelton.
Stephen Thair, co-founder of DevOps Guys, which provides operations as a service, added: “DevOps is not just an IT thing. Focusing on automation alone will only give you faster software – it won't solve your bottleneck issues. Bottleneck issues will just be transferred elsewhere.”
Thair, also speaking at the panel debate, advised CIOs to consider the Calms (culture, automation, lean, measurement, sharing) model when planning a DevOps strategy.
Hiring another team just to focus on the IT side of DevOps will create another silo within the enterprise, Thair warned.
Having a weak case for doing DevOps
“It is important to have a good grip on why you want to do DevOps,” said Chris Jackson, DevOps CTO at Rackspace. “It is easy to get stuck in the mindset that everyone is doing it, so I will too.”
DevOps is an excellent way of speeding up how an IT department can ensure it is meeting the needs of the business, but a DevOps project must identify and align with business needs.
Experts on the panel advised IT to always ask why a DevOps approach is being taken up. For example, if the business is losing customers who are fed up with bugs in the software, a specific DevOps goal will be to solve that in the next releases of the software, improving customer retention.
Having an articulate strategy will help the DevOps team to convince the stakeholders and win the budget and IT resources they need.
“CIOs must also avoid turning into ‘DevOps evangelists’ who do not actually do it,” said Steve Acreman, CTO of Dataloop.
Not involving compliance and audit teams
DevOps does not just involve putting the development and operations teams together in one room. It is an amalgamation of many stakeholders, including the auditors. It is a continuous process of software development and automation that can result in a lot of grey areas in audit and compliance, panel experts warned. Auditors need to understand the processes, evaluate the controls and identify the risks, they said.
“It is key to involve everyone and develop an inclusive level of thinking,” said Jackson. “What’s the use of having a wonderful, efficient automated system in place if your documents are not going to reflect that change?”
Taking compliance officers and auditors on board will help businesses mitigate risks, the experts said.
According to Thair, DevOps is not just a cool, secret Skunkworks project, but a business-wide, enterprise-class project that needs the confidence of financial stakeholders, IT and the operations and testing and development teams.
Taking a prescriptive blueprint and being rigid
It is important to find the right leadership within the enterprise that will enable and facilitate the DevOps strategy rather than directing or mandating the tools, said Jackson. “That is a classic mistake.”
Organisations must also change their views on how to deal with failures, said Skelton. “If the business is going to punish the teams if the DevOps project is not progressing according to plan, then the teams will hesitate and back off from the deployment.”
According to experts, while it is important to keep the eye on the final objective and to ensure the project is not too much over budget, it is important to see failures as opportunities. DevOps is not a one-size-fits-all approach and CIOs must encourage experimentation, said Thair.
Overselling the concept
DevOps is not a silver bullet that can solve all the enterprise's bottleneck issues and IT inefficiencies. “If you say everything is going to be fantastic ahead of the full deployment, then you are raising expectations and this may lead to disappointment,” said Thair.
DevOps also does not mean the end of operations as a team. It is important for CIOs to win the confidence of the operations teams and tell them they are still important, or they will resist the change, he warned.
CIOs must take a project-by-project approach to DevOps, rather than a sudden and complete shift. Skelton suggested starting with valuable but not mission-critical projects.
“That way, enterprises can see the clear benefits of DevOps practices, but if it doesn't work, their mission-critical workloads will not be affected,” he said.
If DevOps succeeds in smaller projects, it can then be rolled out to high-profile schemes, he added.