DevOps has well and truly arrived. Having a team combining development and operations is superseding the traditional model where these functions are separate. If you haven’t already embraced DevOps, you would have heard about it.
The speed of demand for software and system improvement means that more and more IT teams and IT projects will be set up this way. But is the distinction between DevOps and traditional models a useful one? Perhaps, as we spoke about in another blog, the structure is less important than the mentality of the stakeholders. In this article we look at some of the differences between the two models and how you can best take advantage of the DevOps revolution.
Comparing the two environments
Traditional IT setups first send off the Development to an ivory tower somewhere. They could spend months and months developing software, doing their own internal testing before finally deploying it. At this point, the Operations team takes over to support the software day-to-day using process manuals and information provided to them as part of the Development Team’s outputs.
We have found there are two fundamental problems with this approach:
Lengthy handover time: The operations teams don’t want to start their phase of the project if they believe something is half-baked. Ultimately, once the developers’ project is completed, the support teams become responsible for the IT – and the ‘IP’ that built the system has effectively left the building!
Development mindset pitfalls: The development team’s focus is primarily on functionality rather than reliability, so for example, having the tools to analyse problems may not even be built into the software.
Another problem that can arise is where there are multiple supported systems within an enterprise. Very often the IT Team doesn’t just get split by ‘Development’ and ‘Operations’ but also split for each system. For example, an IT Operations Team for the Oracle ERP solution, a website Development Team, website Operations Team, CRM Integration Team, CRM Operations Team. It all starts to get a bit hectic!
The DevOps model can successfully address these issues because it brings the two processes together with a single group of people responsible for developing and running the software day-to-day. The benefit of this approach is not just about overcoming the disadvantages of the old model. Because developers have to look after the software or systems on a day-to-day basis, they get a better appreciation of what it means to run the software and therefore develop a vested interest in making it easier to run. Why would you risk doing anything less than a great job on something when you’re the one who has to clean it up if it goes wrong?!
DevOps is all about speed and agility in implementing the functional parts of a platform or application. It lends itself to Agile project management methodologies and start-up mentality. Short development cycles are encouraged to move working software into production at smaller time intervals – often a few weeks. This contrasts with the previous ‘big bang’ style launch, which sometimes saw years between releases.
Pros and Pitfalls
In our experience of running and setting up DevOps teams in enterprise environments, here’s a summary of the main benefits of the DevOps model:
Defects and teething problems, which always arise, can be fixed on the go, so problems don’t build up and compound each other.
Shorter development cycles mean value is created, and realised, faster.
Developers grow a better understanding of operational needs, e.g. having meaningful logging and monitoring
Higher quality outcomes – as your people are exposed to both the operational and developmental side of the system, they get better and better and solving problems as they arise and building higher quality code first time round.
Lower cost – resources and skills are shared between operations and development teams
Superior customer experience brings business benefits such as elevated internal and reputation for your team and external reputation for the organisation.
A word of caution here. The developers’ side of the equation involves more than skills. For example, if developers just fix things directly without following deployment processes, it can result in undocumented changes and ill-defined environmental variables. In DevOps, the governance element is crucial. The team needs to have the discipline to build in controls and processes to ensure that poor quality code doesn’t make its way into production. Although under a DevOps model, this is in their own interests anyway as developers have to fix it themselves!
There are some scenarios where the DevOps approach may not be relevant or useful. These include:
Certain types of developments, such as pure infrastructure projects, where there is an ‘all or nothing’ delivery
Package installations of off-the-shelf software
Where the cost of errors in software is particularly high, e.g. certain financial systems where there may be almost zero margin for error. This necessitates a style of development and rigorous testing that will likely involve a focused project team who must hand over a perfect product. There will be a much longer lag before the first release of code.
What do you need in place to properly leverage DevOps?
The DevOps way of working has introduced great efficiencies and there are many good reasons why everyone is getting on board. Here are two key considerations:
Firstly, DevOps thrives on metrics and accurate monitoring to measure progress and productivity. Development processes must be clearly defined and broken in to smaller, more manageable chunks. During the testing and phase-based, incremental developments, the deployment must be clearly aligned and automated.
Secondly, there is a danger with DevOps that teams lose sight of the big picture and forget about some of the fundamentals of why they’re doing what they’re doing. What is the actual business purpose of what you’re building? As much as you are responding to user demand for change, you are also of course trying to influence their behaviour.
Without a regular strategic realignment, you could find our DevOps teams taking on lives of their own!
In our experience working with numerous large Australian Blue-Chip Enterprises, there is huge value in the seemingly simple task of de-mystifying the various IT project models and opening people’s hearts and minds to how those new ways of working can make their life better. Isn’t it often the case that it takes an outsider to make something happen that you’ve been trying to do for an age?!
Fusion Professionals prides itself on our business-acumen and nuanced approaches – although DevOps is a great option on paper, seldom is it as simple as transplanting in a totally new modus operandi to a customer’s business. Our unrivalled experience setting up and executing projects under a DevOps structure means that we’re able to tailor our approach to the subtleties of your business.
Comments