Newton’s First Law of Motion states that a body at rest will remain at rest unless an outside force acts on it, and a body in motion at a constant velocity will remain in motion in a straight line unless acted upon by an outside force. … Outside forces are sometimes called net forces or unbalanced forces.
In my last blog post I did a lengthy analysis of “The Cloud Capex Conundrum” — the seeming paradox that on-prem capital investment is holding steady while public cloud revenues continue to skyrocket. My conclusion was a huge cohort of cloud-native applications is being deployed into public environments, while existing portfolios of on-prem applications continue to operate in their traditional environments.
In a way, this is counter-intuitive. Traditionally, most observers treated the aggregate of all application portfolios as a pretty fixed total, with the on-prem/cloud deployment a question of what proportion of applications would be moved and what proportion would remain where they were initially deployed.
The evidence from the IDC chart is that traditional analysis is mostly wrong-headed. In fact, the total aggregate of applications is growing sharply, with the net increase going to cloud and the legacy pool of applications staying right where they are. In other words, there is no significant migration of existing applications from on-prem environments to public cloud infrastructure.
The interesting question is why the migration portion of cloud deployment has been so small. After all, cloud infrastructure offers all those benefits outlined in the NIST cloud computing definition. Which are so necessary to achieve the goodness outlined in the DORA report, which I discussed in a previous blog post.
The answer lies in what I refer to as application inertia — those forces that restrain application migration. Application inertia is key to understanding what dictates how IT shops treat their existing application portfolios; more importantly, application inertia will dictate what options those shops have in the future as their companies pursue digital transformation initiatives.
What is application inertia? It represents all the forces that affect application deployment. The figure below illustrates those forces and where they operate in the application lifecycle.
Early in the lifecycle, there’s lots of investment. Development of code, obviously. But there are lots of other labor-intensive activities: infrastructure preparation; security audit and recommendations implementation; operations practices and support readiness; monitoring and logging support. Put another way, writing the code for an application is only a portion of the technical work needed to create and deploy an application.
There is also a significant organization overhead in deploying an application. Many groups need to be involved in obtaining final commitment to the effort of bringing an application into production. These groups often go by the name of stakeholders, and they all need to be involved in the application lifecycle process. Stakeholders include operations, computing infrastructure, storage, network, identity management, DNS, cybersecurity, procurement, and legal. You may be able to think of other groups at your company that are commonly involved in initial application lifecycle efforts.
The purpose of stakeholder groups is to ensure that the areas they are responsible for are addressed and policies they develop are followed. So early in the application lifecycle there’s lots of effort making sure ultimate deployment of the application is compliant with all requirements.
For the development group, each group and each policy represents an activity that is necessary for final deployment — lots of work to ensure everyone’s needs are met. Notwithstanding the undoubted importance of all this activity, it represents inertia — absent investment of organization energy, the application will sit listless, unable to move forward.
Once an application is actually created and deployed, the level of involvement of these activities and groups drops significantly. After initial deployment, most application investment involves development and operations groups. Investment directed toward stakeholder activities is much lower because the other groups accept that their initial policies and work carry over to ongoing application changes.
In sum, then, application investment is heavy early on because there’s so much non-functionality work, which drops away as the application lifecycle goes beyond initial deployment. In Newton’s terminology, once an application has been released into production, it has momentum and will carry on in a straight line. Much less energy is required to continue work on the application because it has momentum — it’s in production, so everything must be ok, policy-wise. Therefore, most of the investment can be directed toward functionality improvements carried out by development and operations.
In fact, in most IT organizations, once an application is deployed, there’s little money available for investment for anything other than functionality improvements. That’s why one hears so much wailing about technical debt buildup; the organization directs the reduced investment budget available toward new functionality, deliberately avoiding internal application investment that does not improve what it delivers to external parties.
Here’s the thing, though. If someone decides to explore migrating an existing application to the cloud, guess what? All those stakeholder engagement activities and policy implementation processes start over again. Newton’s phrase for this is that outside forces are necessary to redirect the momentum of the application. In an enterprise IT context, trying to redirect the ongoing inertia of the application toward another infrastructure environment requires a significant round of funding, not to mention getting the attention of all those stakeholder groups for what may be seen as a plumbing effort — swapping one infrastructure for another — and not a functionality improvement.
This explains why so little of the industry’s existing application portfolios have been migrated to the cloud — migration requires a ton of work with no visible improvement in what the application delivers. I’m of a mind that, due to application inertia, most existing applications will remain just where they reside today, with little organizational appetite to confront the inertia associated with the status quo.
The issue of application inertia applies in the other direction as well. There is supposedly a move toward “cloud repatriation,” whereby IT organizations suffer buyer’s remorse at their decision to deploy applications into public cloud environments and, once they come to their senses, move them back on-prem where they can operate more securely and less expensively. The only problem is a move back toward on-prem requires all the same stakeholder engagement and process work, just in reverse.
Consequently, the much-ballyhooed cloud repatriation movement will remain, like the Loch Ness Monster, much more discussed than witnessed in real life.
To paraphrase Newton, once an application is in place, it tends to remain in place — no matter where it resides.
Incidentally, if you’ve remarked to yourself that application inertia is reminiscent of data gravity, you’re absolutely correct. Both represent forces retarding a change in the existing state of affairs, and a reluctance to invest in moving something that exists, operates in a fashion, and requires confronting organizational sloth in the service of minimal incremental improvement.
Given the reality of application inertia, what are the paths forward for enterprise IT organizations? There are four approaches to addressing the reality of today’s on-prem applications that are in-place and humming along.
Merriam-Webster defines sleeping dogs lie as “to ignore a problem because trying to deal with it could cause an even more difficult situation,” which is just about a perfect summation of application inertia. After all, the applications are in and running, require relatively little new investment, and (presumably) deliver the benefits originally envisioned for them.
This approach also carries the benefit of reducing organizational tumult. The main challenge with this approach is that yesterday’s benefits may not be sufficient for tomorrow’s digital transformation needs. Sleeping dogs lie is the default position for the vast majority of applications within enterprise portfolios, as evinced by the well-known Gartner stat that IT organizations spend 80% of their budgets “keeping the lights on.”
Many IT organizations are pursuing a lift and shift strategy in which existing applications are transferred unchanged into public cloud environments. The benefit of this approach is primarily that it allows exit of obsolete data centers and can be seen as a stepping stone to greater cloud adoption. It may reduce infrastructure costs as well.
The downside of this approach is that it requires significant investment of “outside forces” — remember, rehosting takes you back to the heavy investment portion of the application lifecycle) without delivering any functional improvements.
Lift and shift also doesn’t bring cloud-native capabilities (e.g., rapid elasticity) to an application; in fact, many companies pursue this approach and then are surprised that applications aren’t magically transformed by relocation. Life and shift is a way for IT organizations to achieve incremental infrastructure benefits, but the business side of the house often feels like it is IT activity for the sake of activity.
One interesting caveat to this discussion is the path VMware has pursued over the past couple of years. It has formed partnerships with AMG in which the cloud providers host VMware environments inside their cloud offerings.
These partnerships make it possible to migrate VMware-based applications unchanged into AMG infrastructure, thereby gaining the benefits of reduced costs and on-prem infrastructure decommissioning without changing the deployment environment. Newton would refer to this as reducing the amount of outside force needed to change direction. For enterprise IT organizations, the availability of an unchanged deployment environment may reduce application inertia sufficiently to support greater numbers of lift and shift migrations.
So, with the exception of the VMware environment mirroring via AMG partnerships, lift and shift is a net positive approach, but it’s important not to oversell what it brings to the table.
As just noted, both sleeping dogs lie and lift and shift leave functionality unchanged, which is a drawback when digital transformation demands new capabilities from existing applications. This hasn’t been an issue for the initial tranche of applications deployed into public clouds, as they commonly operated as islands of functionality (e.g., a standalone marketing website tied to a one-off promotion).
This approach has the benefit of leaving core business systems undisturbed. However, it is inevitable as digital transformation descends deeper into a company’s products or services that these cloud-native applications will need to reach back into core business applications to drive transactions or offer real-time data status.
Short of confronting application inertia for those applications, what can be done? Many IT organizations will insert a layer between the calling cloud-native applications and the core business systems; this layer will serve as an integration mechanism to connect the two dissimilar types of systems.
A common reachback approach will be an API layer that translates calls from the cloud-based systems into interaction mechanisms the legacy system can accept (can you say screen scraping or its modern hipper version, RPA?).
Wrap and extend layers are commonly written with cloud-native characteristics and are often deployed in the cloud themselves. This is a good approach as it reduces the amount of application inertia that must be confronted for core systems. A drawback to wrap and extend is that it may exacerbate the shortcomings of these systems, as they were never designed for elasticity and scale, and making it easy to access their functionality via APIs may increase load to the point these shortcomings are exposed.
It’s a cliche to say software is eating the world, that every company is now a software company, and that digital transformation is affecting the entire economy. Here’s the thing, though: cliches contain more than a kernel of truth. That’s how they become cliches.
Once one accepts the meaning of those cliches, it’s clear that for some portion of an existing application portfolio, none of the previous approaches may be sufficient.
As the digital transformation revolution continues, IT organizations will need to transform some applications from caterpillars to butterflies, which is a major (and messy) process that results in a thing of beauty.
The key question confronting IT organizations is how large a portion of their portfolio needs to change into butterflies, and how quickly must that portion grow? Application inertia is very real, but the cost and mishegas it entails must be confronted for some irreducible part of the existing portfolio, lest the deadweight of outmoded applications irreparably harm the overall company’s prospects.
Over time it’s likely that the vast majority of every IT organization’s application portfolio will need to undergo a caterpillar to butterfly transition; the critical question is how quickly the kaleidoscope of butterflies is required.
Application inertia confronts IT organizations daily. Changing the direction and speed of legacy applications is hard — really hard. But, as the cliches just cited illustrate, the business environment in which legacy applications operate is changing fast. There are many who assert that the change is accelerating; in other words, if you think things are unsettling now, you ain’t seen nothing yet.
Actually, deciding how quickly to convert the portfolio of existing applications from caterpillars to butterflies isn’t even (or at least, solely) an IT decision; application inertia is now a business survival issue. This means CEOs will need to recognize that digital transformation isn’t merely a question of how to allocate a fixed IT budget — it’s a question of how much capital investment to direct toward IT to accelerate digital transformation. Failing to get this right puts their company’s future in peril.