Agility Throughout the LifeCycle: The Rise of DevOps

Until it is released (in the hands of end-users), new developments are “inventory”, to use the lean software term – you have invested time, effort and resources in making changes, but no value is realised for the organisation until any development is actually released and being used by the end-users.

So What is DevOps?
The term DevOps suggests the combining of development and operations together and applying some of the skills of development to the issues of deployment. It is also about looking to break down many of the barriers that have grown up between these two parts of many organisations.

Is it New?
As mentioned at the start, we believe that the principles have been around in various forms for many years.

For those of us who do internal software tool development as part of their job (either from scratch, or to customize and configure), DevOps has always been a part of the reality that we have lived with day-in and day-out for at least a decade or two. Just as Agile Development calls for generalizing specialists across functions, we have had to do the same across the enterprise:

• We’ve had to be experts not merely (nor even primarily) with tool administration/usage but also with the organizations' business-processes and most (if not all) of the enteprise application architecture
• We’ve had to work across not merely the software development lifecycle of these tools, but also the deployment lifecycle for installing, upgrading and supporting the tools
• We’ve had to do far more than mere administrative support too, including new development to any existing internally developed customizations and their configurations.

We've had to be process experts, application development experts, application deployment exports, tool support and administration experts, etc., for most all the business-activities and their processes surrounding those tools.

Is it Elitist?
One of the dangers is that DevOps is perceived as elitist and as relevant to only a few organisations. See Stephen Nelson-Smith’s article which addresses some of these concerns. Does it mean that all sysadmins must be able to program (or at least script actions)? To some people the answer is yes – a new breed of sysadmin-coders will sweep all before them. I believe that is not strictly necessary – although it can be an advantage. The key principle for me is that the operations team needs to consider how to improve the automation of their tasks, and if they can't automate it easily themselves, to seek help in achieving this automation (and the business should allocate necessary resources to doing this).

It is Just a Fad?
Another danger is that of being perceived as a trendy fad – and thus something that can safely be ignored by the vast majority!

The underlying principles being espoused under the term DevOps have been around for a long time and successful organisations have been implementing them well for some time.

The fact that they are wrapped up in a catchy title is good marketing 

Let’s look at some of the issues and principles involved.

Global vs Local Optimizations
Too many companies still have local optimisations rather than optimizations across the complete lifecycle – their development may utilize Agile methods such as TDD, and seem dramatically improved from previous efforts, and yet releases happen infrequently and are not always successful. It doesn’t matter how good your development is if there is a large stumbling block later in the life cycle.

Improving Communication
There is often a lack of communication between development and operations. Each department is often incentivised very differently – development gets rewarded for making changes, operations gets rewarded for