Continuous Delivery is Eating DevOps as Software is Eating the Business

For years, IT has been automating business processes. Now IT is automating its own processes to keep up with the rapid pace of change and to meet the business demand for new software features and capabilities. 

What if the business could release dozens of tested software improvements to production daily? Could the business respond to market and customer demands more quickly? The answer is yes – and continuous delivery makes this possible. 

Continuous delivery involves the automation of the application development and delivery lifecycle, thus taking software from code to production in an automated process – and doing so more quickly than traditional processes. It is also the foundation for enabling the DevOps implementations that are occurring in many organizations today. 

Continuous delivery is an opportunity to bring the development and operations teams closer together. The industry calls this new culture DevOps. Companies that are successful with continuous delivery have embraced it. DevOps is all about a no-blame culture - getting everyone focused on the release and how they can successfully deliver it to the business in short order.

By adopting a DevOps mindset, developers and IT operations have to execute the cultural changes necessary to bind them together into a single team that can successfully leverage continuous integration and continuous delivery to its utmost.

DevOps teams use continuous delivery techniques such as applying automation and version control to the configurations of the supporting application infrastructure. By being able to duplicate (and replicate) these environments exactly, development, testing and production environments are in sync. Release to production becomes smooth - a non-event, and any errors that occur throughout the delivery process can be quickly identified and resolved. 

With automation, you eliminate manual processes that slow down delivery and are also prone to human error. Once a developer changes an application, the change automatically propagates through the build, test and deployment processes in quick succession. This enables frequent, incremental and higher quality software releases deployed to production – hence at lower risk and cost than traditional software development practices. 

While this automation can be intimidating to some organizations at first, the value in more rapidly delivering what the business wants outweighs the effort that the transformation requires.

One key aspect of continuous delivery, is that it makes it possible to channel critical business, IT and market feedback into the development cycle to quickly enable incremental feature improvements and enhancements. With continuous delivery, an organization can innovate, test and deploy revenue-generating software many times each hour, day or week—as often and as quickly as the business requires. 

However, the iteration doesn’t end once new code gets deployed to production. Business metrics are continuously collected in production and the business will be able to compare metrics against pre-defined goals (shorter sales, increased sales, etc.) This feedback loop to the business is a key aspect of continuous delivery. 

Software is at the heart of many products. As software eats the world, the business must deliver new software capabilities more quickly and efficiently. Business units are trying to sell more in their markets and respond more quickly to market demands. They are trying to interact in new ways and more intimately with customers in order to gain a competitive edge. The business is increasingly looking to IT for software processes that enable fast cycles.

Continuous delivery is at the forefront of the software-led business. Continuous delivery enables the line of business to meet market requirements in order to drive the business forward. Continuous delivery empowers the business to respond to competitive threats by testing new capabilities or even new markets – and doing so quickly. This enables the business to learn what works - and more importantly, what doesn’t work - using an approach that is faster, low risk and low cost. 

Continuous delivery practices fold IT into the business strategically. Continuous delivery affects business-driven software change and error resolutions in close proximity to testing for quick course corrections to keep the business on track. IT can respond in a very timely fashion to the needs of the business and the business can embrace IT as a partner.

A common misconception associated to highly iterative and automated IT processes could increase risk and quality. On the contrary, reality shows that accelerated delivery of capabilities does not translate to sacrifices in quality. 

Continuous testing is inherent in continuous delivery practices, so automated testing is central to this software delivery methodology. Automated testing ensures that every time you release a new update or feature, you put it through a rigorous and repeatable automated testing process. Furthermore, since very little changes between two iterations, it gets very easy to spot where the issue comes from, how to solve it and, in the meantime, revert back to the previous version, which was known to work.

The result is a software release candidate that instills confidence. The candidate meets your quality standards because it passes long-established testing criteria. We’re actually talking about building quality into the process through automated testing: Organizations utilizing effective continuous delivery practices are able to produce higher quality software.

Similarly for business changes, since continuous delivery makes businesses release relatively small incremental features, frequently, if any given functionality doesn’t yield the expected output/metrics, the business hasn’t invested as much time and resources as they previously would have for the same outcome. The business can gather immediate feedback and make a decision as to whether they're going to continue to invest in the incremental functionality or revert back to the previous business situation, without having too much invested.

Businesses are increasingly relying on software. The automobile industry is a good example, but by no means the only one. Automotive manufacturers today utilize embedded software in the form of ECUs (electronic control units) to control systems throughout the car. Cars can have up to 10 million lines of code and 125 ECUs or more in them. 

When automotive manufacturer Tesla discovers an issue with its cars, it delivers the software directly to the owner in the form of a download the owner initiates from within the car. This process saves Tesla millions of dollars – unlike the process that traditional automotive manufacturers use, which requires expensive physical recalls when an engineering or manufacturing issue is discovered. That’s the kind of leap modern software delivery practices – such as continuous delivery - can provide to the business.

As software eats the business, so continuous delivery eats software development and deployment. If you don’t care about continuous delivery, your competition will. You will find yourself facing either a smaller, more nimble company or a larger, more nimble company – both of whom have adopted continuous delivery. They will outpace you very quickly in their ability to deliver new capabilities to market. Can you wait months to deploy a solution that your competitors already used to steal your customers and eat your lunch yesterday? 

Yet, moving from a traditional development processes - such as waterfall - to a continuous delivery practice is not an easy transformation for large organizations. In order to make the move to continuous delivery, they have to take a holistic approach to their processes to enable transformation.

A lot of firms dip their toe in the water first, trying continuous delivery on a single and simple project led by a team motivated to perform that transition. That gives them experience with a project that is low risk. Then they can take what they learned from that small project and apply it to broader initiatives. In any case, forcing a big bang approach is very likely to fail. 

When the first project is successful, other project teams will want to adopt continuous delivery practices. When a small team completes a project successfully using continuous delivery, people share that success and promote it throughout the organization. Suddenly, everyone wants to adopt continuous delivery.

Continuous delivery produces a satisfying counter-intuitive result: any apprehensions about potential risks associated with the shift to continuous delivery are relieved as speed, transparency, automation and cross-team collaboration and ownership of software actually get rid of old risks, spare the enterprise new risks and catapult application delivery. In the process, applications are optimized – and so is the business.