Strategic vs Utility Services

I’m often asked what kind of systems continuous delivery is best applied to. While software-as-a-service is the most obvious example of where continuous delivery can be used, keeping systems constantly production-ready from early on in the delivery process – even if you don’t release to users regularly – is beneficial for all kinds of systems. However the benefits of continuous delivery come with a cost – in particular, more intense collaboration, more investment in automation, and more generally the extra effort required to develop software in an incremental fashion and deploy it regularly. In fact, the most important criterion for using continuous delivery isn’t concerned with the technical nature of system you deliver or even the market you work in – it’s whether the system is strategically important to your organization.

In his 2003 article in Harvard Business Reviews, Nicholas Carr argued that IT didn’t matter – that it was simply infrastructure that didn’t offer a competitive advantage. History has proven him to be almost right inasmuch as most IT services, such as email systems and payroll, are like utilities. You need them, but you don’t want to create or manage them in-house. However in many organizations there exist software projects that are considered essential to the organization’s strategy, such as Southwest’s website. Indeed, a service that is considered utility software for one company, such as a bank’s online service, might be considered strategic for another, for example an online-only bank. Martin Fowler goes through the differences between strategic and utility software and provides some good references in his bliki entry Strategic vs Utility Dichotomy.

It’s all too common for organizations to waste a great deal of time and money doing custom development on services that should be utility for them. Usually, they’d be much better off using packaged software. Apart from political considerations, the major reason many organizations don’t do this is because packaged software doesn’t support their business process as-is and thus requires customizing. Often, vendors are all too happy to customize their products, since it means lucrative consulting revenue. But this is almost always the wrong thing to do.

Instead, organizations should change their business process to match what the product supports out of the box. Indeed, this is a good test to discover if a business process is strategic or not: if using commercial, off-the-shelf software to implement the system – and changing the process to match the software’s model – impacts a competitive advantage of their business, then guess what: the system isn’t utility, it’s strategic. There’s a great recent case study from Telstra, Australia’s largest telco, which discusses how they moved from a heavily customised service desk solution to one that ran out of the box.

There are two types of software that are often cited as being unsuitable for continuous deployment: products, and embedded systems. It’s hard to release commercial products to users very frequently because it’s too expensive to support many versions of the system. Embedded systems can’t be released frequently for similar reasons, and also because of course it’s very expensive to rev hardware. These arguments are the reason why I am very careful to distinguish continuous delivery from continuous deployment. Continuous delivery is about keeping your systems production-ready throughout development, so that they can be released to users at any time – in particular, when the business decides it’s the right time to release. It thus follows that you can practice continuous delivery even if you’re not doing continuous deployment.

Indeed there are many benefits to following the principles and practices of continuous delivery, even when working on products or embedded systems. On Go, the CI and release management platform I manage, we only release every 3-4 months, because we can’t support more than a couple of releases. However we use our tool to build itself, and upgrade it every time there is a good build. We deploy once a week to our company’s internal build grid, which is used to build our other products. We do early access builds that are available to users – although unsupported – every two weeks. This ensures our software is always production-ready, that we can get rapid feedback from our users – both internal and external – and that we can release whenever we think the feature set is sufficiently compelling. This kind of practice certainly wasn’t our idea – the Eclipse project has been producing daily and weekly public builds since at least 2002.

Embedded products can also follow continuous delivery by regularly integrating and testing their products throughout their development lifecycle, and by having everybody involved – hardware, firmware, and software – working together from the beginning. Indeed, this is exactly what great product companies already do. One of the biggest advantages Apple has – other than the primacy of design and their focus on perfection – is their vertical integration. When the first Macintosh was created, there weren’t separate, physically separated hardware, software, and OS teams: instead, the entire Macintosh team sat together in one building, and wasn’t allowed to grow past 100 people (see this fascinating interview with John Sculley for more on the early history of Apple). That meant everybody could work together to make sure that every decision – what chips to use, how to implement the operating system, how to build the applications – were made in a way that optimized the product as a whole.

Granted, the Apple team weren’t practicing the level of automation in terms of integration and testing one would expect from a more sophisticated continuous delivery set-up – which perhaps explains why they were still debugging a few hours before the operating system had to ship. But a great deal of the quality of the product was clearly due to the cultural practices of having everyone involved in the system working together from the beginning – something we emphasize in the book, and which finds an echo in the DevOps movement.