As DevOps moves from early adopter territory into the mainstream, there is the inevitable evolution in how it is described. As with Agile before it, ask twenty people to define DevOps and you’ll get twenty slightly different answers. But it’s important that nuance doesn’t get in the way of understanding it at a fundamental level. Amazon Web Services’s has a clear and succinct take on the what and the why:
DevOps is the combination of cultural philosophies, practices, and tools that increases an organisation’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organisations using traditional software development and infrastructure management processes. This speed enables organisations to better serve their customers and compete more effectively in the market.
At its core is the move away from the ‘siloing’ of development and operations teams to cross-departmental integration; the onus is on close collaboration and communication between the teams which, when coupled with the appropriate technology and tooling, can create the conditions for optimising software delivery. The outcome? Continuous improvement through development and deployment that is fast, iterative, reliable, secure, compliant, and derisked.
Many of the articles on DevOps stress that it is a mindset, not a toolset, and go onto explore the cultural challenge inherent in any shift of traditional thinking and process. Nothing wrong in that but there are dangers in relegating the technical piece to an afterthought, or worse, making the assumption that the technology isn’t part of the overall challenge. Because a DevOps philosophy can only take root and thrive in a DevOps-tuned environment, where underpinning systems and resources have been designed carefully to align with the needs of a DevOps-focused organisation. When DevOps is instead shoehorned into an existing infrastructure, problems can arise.
Take the example of one government agency that in recent years has committed to a very aggressive digital transformation agenda. Operating entirely online, they have plenty of ambition but has plenty of ambition for the future with IT enablement front and centre of its strategy. One of its first moves a few years ago was to move from the traditional ‘waterfall’ development approach to embrace a DevOps culture. There was positive adoption from its large technical team but their will and efforts were soon being thwarted by their legacy development environment. So where they wanted to spin up environments in minutes they instead found themselves having to wait weeks for the support provider to provide a single instance. And those critical success factors for DevOps – the ability to be agile, to work cooperatively, to build a momentum, to follow a smooth, standardized, proven process – these were compromised every day by a platform whose availability, speed and usability fell well short of what was required.
Without a ‘DevOps by design’ approach to the underlying environment, adopters are likely to find themselves in the same boat as this agency: jeopardising not only the success of the DevOps program itself but, and far more importantly, an organisation’s ability to respond, capitalise and compete in a fast-changing world. In the government agency’s case, they responded to the danger with a complete rework of its development environment; it is now fully aligned with the requirements of the team and set up to allow DevOps to flourish and deliver to its maximum potential. It opted for an Oracle Engineered Systems SuperCluster-based Platform-as-a-Service solution together with Oracle Agile implementation services and advanced customer support; going the managed service route unlocked further gains in that focus on development can be total, IT resources are freed up for more innovative work.
Putting in place an environment tuned up for DevOps has transformed performance at the agency: the team’s output level has doubled in less than a year; new functionality is being designed and delivered in a single day when previously it may have taken up to 8 months to get it live; fresh ideas are flourishing because for the first time the agency knows that it can ‘afford to fail’; and the cumulative confidence of the team in a DevOps approach that is now no longer stifled by technology but catalysed by it is seeing renewed commitment to and enthusiasm for the agency’s transformational agenda.
There’s no argument that the cultural challenges around DevOps are significant and worth examination. Prepare to see the phrase ‘it’s more a change of culture than a change of technology’ a lot this year. But it would be dangerous to assume that technology doesn’t have a role to play. It won’t be the lead, but the supporter. But remember, it’s the supporter that keeps everything else propped up.
