A Series of Unfortunate (Delivery) Events
79% of new products miss their launch date.
That was the conclusion of a CGT/Sopheon Survey in which the impact of such market misses were also explored. What it didn't dig into was the reason why so many products and projects miss their launch date.
When we start digging into the details with respect to applications, we can find at least one causal factor in the delivery process, specifically that portion which focuses on the actual move into production, from which consumers (internal and external) are ultimately able to get their hands on the product they desire: your app.
This is tied to a lexical misinterpretation (or perhaps misapplication) of the word "delivery" in "continuous delivery". Continuous delivery as used by developers and DevOps alike really means delivery to an application's penultimate destination. Not the ultimate destination, but its penultimate destination. That is, within most enterprises, production. Which means into the hands of the multiple operations' teams who are responsible for provisioning the resources necessary to move that app to its ultimate destination, which is of course the consumer.
While continuous delivery efforts in development, closely tied to continuous integration, testing and build process automation, has stepped up in terms of being ready to go to production, there remain multiple obstacles in the production delivery process which have not stepped up. Here we find the bottlenecks inherent into the overarching "delivery" process, where slow manual processes and complexity continue to wreak havoc on delivery timelines and impede the timely delivery of applications into the hands of consumers.
The problems in the production delivery process are similar to those that impede progress in development: handoffs between teams responsible for different tasks within the timeline, manual processes that introduce inconsistent and errors that must be found and fixed and even a failure to clearly define dependencies in a way that makes it possible to checklist the process and keep it moving forward. Continuous delivery addresses these issues within the development delivery process, but has not yet extended far beyond development and into the production delivery process. A recent DZone survey on Continuous Delivery indicates 22% of respondents had moved continuous delivery into production,focusing on infrastructure and another 57% want to do so. This desire and practice is further validated by the 28% of respondents in a Rackspace DevOps adoption report who have implemented infrastructure automation.
But infrastructure is only one part of the production delivery process that must be considered, especially for new applications, as there are a multitude of other services in production that must be provisioned, configured and integrated in order to delivery an app to its ultimate destination. These services, traditionally delivered by network-hosted infrastructure, must also be included by continuous delivery practices if we are to achieve the faster time to market that 9 of 10 executives today feel pressured to realize (CA, Greasing the Gears of Innovation in the Application Economy).
I/O (that's Infrastructure / Operations for the uninitiated) and network pros alike are well aware of the need for more agility (and the speed and consistency it brings) in the network. Their awareness of enablers like API-enabled infrastructure, app templates and programmability of the network in general is high and in our research, they place a great deal of importance on it whether they're a believer in DevOps or SDN or both. The stage is set (sorry, pun not intended) to move continuous delivery further down the delivery chain, from development into production, where it can continue to make a significant impact on organizational success in an application world.
Continuous delivery shouldn't stop half-way to the goal of delivering apps to the consumers they're intended for.