Continuous Adoption — keeping current with accelerating software innovations.
This first article on Continuous Adoption intends to set the stage for change in the way enterprises approach software upgrades coming from vendors and open source communities at an accelerated pace.
The cloud has profoundly changed how applications are built, to the point cloud native is now recognized as the preferred way of developing modern, digital capabilities. While led initially by innovations in the public cloud, many components and tools for cloud native applications are becoming available for private cloud deployments. And inspired by these, even more traditional middleware is rapidly modernizing to contribute to increased enterprise developer productivity, not only for building new capability but also modernizing existing applications.
One of the challenges for enterprises operating a private cloud is to deliver a cloud native development and run time platform that keeps-up with the accelerated pace of innovation in components and tools. Public clouds will offer these “as a service” on recent version levels. Private Cloud operators need to do the same. Some differences will always exist and are even desirable, like isolation, governance, and connectivity to traditional IT. However, if private cloud services are lagging too far behind in capability, enterprise developers will either suffer from a lack-of-innovation penalty or simply by-pass their enterprise’s private cloud and expand “shadow IT”.
Building on the insights of giants that ushered Agile, DevOps, Continuous Integration and Continuous Delivery concepts into our industry, vendors and open source communities alike have increased the pace of production of software. At IBM for example, flagship products like Websphere Liberty, API Connect and Information Sever are on a Continuous Delivery lifecycle, providing at least quarterly, or even monthly upgrades. This gives consuming enterprises faster access to technology innovations. At the same time, producers cannot provide support for more and more variations (versions) of an offering and will typically support a limited number of versions behind the most current one. E.g. a minor Kubernetes version is released every three months and only the most recent 3 are supported by the community. While the literature and conferences are plentiful and inspire the producer community to accelerate, what has not received much attention sofar is how consumers, or users, of ‘unfinished goods’ like middleware can deal with this increased pace of their incoming software upgrades.
Moreover, in many IT organizations technology upgrades are considered harmful. They don’t seem to bring business value and change by definition presents risk. In the face of reducing budgets, upgrades are pushed out until the very end of what the provider of the technology will support, and even beyond. However, the technical debt built up because of it, needs to be paid for some time. The scale of the problem leads many enterprises to be burdened with vast obsolescence management programs.
Meanwhile one kind of technology update is often mandated : the security updates. Under the increasing threat of cyber criminality, enterprises will enforce rapid compliance with the latest security patches. This sometimes leads to forced upgrade of the entire software package impacted.
Continuous Adoption is taking a pro-active approach for software consuming enterprises to stay up to date and stay out of support trouble. Like for code changes triggering builds, integration, testing and sometimes even deployment in a Continuous Delivery approach, enterprises should automate similar continuous adoption pipelines, triggered when vendors or communities release new upgrades. Once the capability exists, enterprises can still “throttle” the rate of adoption to match their appetite for risk. Up until recently the risk of change in IT has often led to stringent change control and a cautious attitude towards upgrades. However, as recent studies on DevOps show (Accelerate by N. Forsgren, J Humble and G Kim), lighter weight change control together with more automation drive better software delivery performance, including lower deployment failure rates. And as software is delivered in smaller increments by providers, the risk of ‘bringing the pain of upgrades forward’ reduces significantly. With truly Continuous Adoption, enterprises remove the need for significant migrations programs all together.
In summary, the main reasons for considering Continuous Adoption are :
* Delivering the latest innovations to developers for optimal productivity
* Maintaining security compliance
* Ensuring support availability from providers
* Avoiding shadow IT
* Reducing the risk of upgrades
* Avoiding technical debt
I hope to have sparked some thought with this initial article on the “why” of Continuous Adoption. The “what” will draw on many of the tools and techniques from its twin sister, Continuous Delivery. And there are many reasons why I’m confident that there are very good answers to the ‘how’ question as well: The work IBM’s integration software teams are doing on Agile Integration Architectures is enlightening. The design principles of the new version of Red Hat OpenShift v4 are at the core supportive of Continuous Adoption. IBM’s strategy to deliver middleware through IBM Cloud Paks on OpenShift further strengthen my confidence. And most important of all, I’m inspired by a few leading edge customers who have already experimented with and implemented Continuous Adoption, at scale and in production and are reaping its benefits.
