There's a lot of talk about DevOps, presented as though it's very new and something we've yet to get any experience with, this most definitely is not the case. First of all, let's identify what we're talking about. Strictly limiting our scope to DevOps, Development and Operations, the core principle is bringing together Development and Operations, providing a single team with a mandate to deliver their software. Something we can indeed consider new in the world of enterprise development, a place with great solitary towers on great solitary islands. Development and Operations are often so distant from another in this world, that it requires someone with a tie to intervene when the two try to work together. On the other hand, companies whose purpose in life it is to deliver a product are left gawking in awe at the whole DevOps discussion, wondering what has happened to make their way of working so special.

DevOps then isn't really something we can consider to be very special, it has just had limited applications, something that is in fact rapidly changing. Part of this is the Continuous Delivery and Continuous Deployment movement, again, in themselves not new, but nonetheless something that's moving very rapidly. Because what has really been changing over the past few months (or years), is application development in itself, we've been accelerating  the rate at which we're able to deliver software. This has spurred companies to experiment more (and more safely) and then provide feedback faster. To be able to deliver faster, has driven the need to deploy faster, this is the exact reason why DevOps is taking off now.

Enterprise development in the meantime has grown to a near halt by enforcing processes to become more formal. Going back very far, software development was slow, error prone and as a whole messy, not to mention the often unmitigated disasters of software deployment. Processes were put in place to fix this. In the mean time, tools and best practises developed that allowed faster development and better testing. The first big problems came around 7 years ago when key users started finding out that what they ordered was most certainly not what they wanted, this resulted in the Agile movement which has since grown to stay here, thanks to software testing and accelerated development. In the meantime, build processes improved, automation improved and we found a lot of best practises to get things done. Again, more testing, better tools, more automation. About two years ago, key users started to find out that what they ordered took about 3 times as long to deploy as the delivery itself.

When we fast forward to 2012, everybody started carrying smart-phones, social media was certainly something we started taking seriously and enterprises were old giants trying to survive the economic crisis. All the while, young fast startups were popping up and out of nothing were capable of deploying their magic a dozen times a day, or more, without annoying their users all too much.

So what is making these startups to what old lumbering giants were unable to do? Let's identify their drivers and enablers. Their primary driver is: time to market. The ability to take a new feature and deploy it in 2 days instead of 3 is what sets one startup apart from others. Their enablers are a bit more than a shortlist: Cloud services, Test facilities, Automation utilities. These enablers are really the game-changers, these are what set 2014 apart from 2004, or anything before 2010 effectively, because they enable continuous delivery and continuous deployment. By providing complete automation and improved testing, we can start to guarantee much higher quality, a continuous quality so to speak.