DevOps - Pragmatic production, not evangelism
Despite the potential of ‘digital transformation’ and IT in general, many organisations find the reality a little disappointing. Development takes longer than expected, quality is lacking and what is delivered often fails to match the business requirements. Despite the continuous, rapid innovation and evolution of technology, with faster, cheaper and more readily available hardware, the software process seems to still struggle to deliver.
There have been many attempts to improve matters from computer aided software engineering (CASE) tools and methodologies to object orientation, 4th generation languages and tools for ‘citizen development’. So far, no silver bullets in either tools, methods, or superhero developers. One problem is that the software challenge has expanded and become increasingly monolithic. Roles have become specialised and the process structured, typically around a traditional engineering model with well-defined stages. Fine in principle, but inflexible and slow to adapt.
A break with the model was inevitable and shifted (typically) towards fragmentation, blurring of teams and speed with the Agile ‘manifesto’. This favours; individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan.
Agile often leads in turn to more fluid and continuous development and deployment processes, generically termed DevOps. Based on how Agile and DevOps are sometimes presented with almost alternative programming lifestyle enthusiasm, it might seem easy to believe they require some sort of cult following.
Certainly, the word ‘culture’ or phrase ‘cultural shift’ occurs very frequently when talking to enthusiasts. So much so, that many organisations become nervous of the almost revolutionary zeal. They wonder how they will be able to cope with adopting the apparently wholesale change.
While there are significant differences in its approach, DevOps should not be seen as an all-or-nothing dangerously disruptive force. It requires a certain way of thinking and organising teams, but this does not have to change and challenge the entire organisation. It might, over time, have more broad-reaching impacts, but these are based on its results, not its initiation.
Adopting a DevOps strategy
The primary requirement is commitment. Management must be bought into the process, and set out the strategic vision and goals. The starting point is – what are we trying to achieve?
While there are always clear end benefits to aim for – increase revenue, reduce costs, mitigate risk – it is the intermediate drivers that shape and derive value from DevOps. Being more responsive to customers, improving software quality, delivering services that meet business needs. The focus for DevOps adoption has to be decided upfront.
Some tasks are far better suited to the potential benefits of DevOps than others. Well-established software and systems that record and manage well-defined data requirements are unlikely to benefit the most. A better place to start would be aspects of customer or external engagement where changes in market, social, political or personal context open up opportunities for innovation. The questions are, what will be required and does anybody have any clear views yet?
So, next is an acceptance that this will require some experimentation. Some may call this ‘fail fast’, but a much better way to view it is ‘learn fast’. The experimentation is being done for a purpose based on the strategy. Small steps are taken, tested, refined and retried in pursuit of the goal.
Doing this requires a tightly-coupled effort based around different skills; design, programming, quality assurance, build, deployment, customer feedback. Rather than distinct stages or disparate teams, these are provided by close collaborators aiming to simplify and streamline the process.
Pragmatic DevOps
The culture for accomplishing this does not need to pervade the entire organisation, nor does it have to be applied to every challenge. DevOps has to be done with serious intent and commitment – from the top as well as those directly involved – but only for one simple reason. To address a problem hotspot and get the results that the strategy was put in place to achieve.
The reality is that those who put DevOps in place for sound reasons do enjoy the benefits. The frequency of software delivery for assessment by the user is increased and ‘good enough’ initial solutions can be honed to be better. Plus, with direct feedback the whole team feels and takes on responsibility for quality.
DevOps is not a panacea or a cult requiring blind commitment, but nor is it a passing fad. Used pragmatically it moves software development away from either exacting engineering or casual coding to poised production at pace. Getting better business value from software should be what ‘digital transformation’ is all about. Find the right project, set suitable goals and give DevOps a go. Who knows, your business culture might change once it’s benefited from the results?