The world of IT has been, over the years, swept by many innovations. 3rd generation languages, 4th generation languages, object oriented programming, waterfall model. prototyping model, Agile and so on and so on. Each of these innovations were improving on top of previous approaches and promising better returns to the organisation in term of speed of delivery, quality of delivery and cost of delivery. Many of these set the industry ablaze and people internalised them with full hearts. In fact, the greatest incentive to adopt any new approach was “ readiness to market” – will I be there before the competition or at least with the competition?
Now we have DevOps. DevOps is the approach of IT delivery where there is close cooperation between developers and operations people and systems are delivered in incrementally useful chunks. It is about bringing in the operations people right from the requirements and design stage.
DevOps is being embraced by a lot of organisations to better their quality, speed and cost parameters. Can I miss out on this wave? Do I DevOps or don’t I?
If I look at InformationWeek’s Research : 2014 DevOps Survey, I find that DevOps is certainly gaining momentum. So should I jump on this bandwagon? That depends…….
First of all, do I have a problem now? Am I able to meet all my targets and meet our competitors at full blast? Or, looking at it from an organisational level, is my IT delivering what is being demanded from it? If everything is going well, then maybe I can wait till your next review before making any changes.
Secondly, am I already using Agile methodologies and /or ITIL approaches? This means that I am already on the way to performance and results improvements and so moving to a DevOps approach will be much easier and logical.
Thirdly, am I in a high-pressure business with customer facing apps (like retail) that need constant updates? In this situation I have a strong case to move to DevOps immediately. The old concept of large releases every three months or every year, is slowly giving way to more frequent updates addressing new features and bug fixes. Look at some of the retail providers.
Fourthly, am I technologically advanced in my organisation to absorb the DevOps approach? DevOps requires a high level of automation of your processes. (For example, am I on the cloud?) If not it is better to wait for you to get to the minimum basic need for implementing DevOps. Also am I too technologically diverse within the organisation? This will present a problem in DevOps implementation.
Fifthly, do I have the organisational discipline to do this? If not, I first need to bring in the required discipline. Am I willing to change my culture to embrace DevOps. I may need to change my hiring practices and change user interaction approaches – accept small changes. I will need to understand the tensions between Dev and Ops and integrate them gracefully.
Sixthly, am I a start-up? Or a new organisation? If so, I shouldn’t think twice. DevOps is the way forward for me. I don’t have old baggage. I can implement DevOps.
Summarising the above, I feel that if I have lots of problems now and is in need of some improvement, or if I am in a high-pressure business like retail or if I am a start-up I need to implement the DevOps methodologies for system development immediately. If I am in none of these situations I can wait. If I am in one of these situations, if I am already using Agile and/or ITIL approaches, it makes things easy. And if I decide to move towards a DevOps approach I need to ensure that I bring in the right organisational discipline and the right technologies before I start on the DevOps path.
So while many a time it may be better to take arms against a sea of troubles, and by opposing, end them, sometimes it is nobler in the mind to suffer the slings and arrows of outrageous fortune.
