The hard truth about lifecycle management

IT gets lifecycle management wrong a lot.

Search for a definition of lifecycle management and you’ll find something along the lines of: A strategic approach to managing the life cycle of an application or platform from conception to end of life — from provisioning, through operations, to retirement.

Under this definition lifecycle management doesn’t seem to do anything.

It doesn’t help get a new platform or application implemented — that’s what your app dev and change management methodologies are for. It doesn’t help with day-to-day operations — that’s what ITSM is for. It doesn’t help retire an application or platform, other than spotting an event or condition that makes retirement necessary. The event might be external, like a vendor bankruptcy or product phase-out, or internal, like nobody uses the application anymore. But retiring the application or platform? That’s what archiving, decommissioning, and once again change management are for.

The view from here? Managing the lifecycle of an application or platform from conception through end of life just isn’t something IT needs to invest time and energy on.

Version currency management: The lifecycle management IT needs

There is, however, a lifecycle management practice that’s essential — frequently ignored, but essential. The lifecycle management IT needs is a set of reliable, tactical methods for keeping platforms and commercial applications current, which is to say no more than one or two versions behind what the vendor is currently selling.

Call it “version currency management.”

To contrast it with the usual lifecycle management, imagine for the sake of argument that some of your applications run on top of EnGarde Secure Linux.

EnGarde is way beyond end of life. To borrow from the Munchkins, it isn’t merely dead; it’s really most sincerely dead. Your servers might not have heard the news, but just because they continue to run doesn’t mean you’re in a satisfactory situation.

That EnGarde runs on an end-of-life server doesn’t mean it will install on the new hardware you have no choice about buying when your end-of-life server becomes an expired server. It doesn’t mean it will work with an update to one of the platforms that run on it, or with an update to an application that relies on it, either.

EnGarde, just like any other obsolete and unsupported technology, will only continue to work until it doesn’t. And when it doesn’t, IT has a crisis on its hands.

Eliminating EnGarde from your platform portfolio isn’t lifecycle management, because at no time in the proceedings was there a lifecycle to manage. When EnGarde introduced its Linux distro it hadn’t set a retirement date in its business and product plans after all. Neither did IT when it selected it. When IT incorporated EnGarde into its platform portfolio its disposition would have been Retain or Extend.

No, from the perspective of IT’s architects, EnGarde’s discontinuation was an event — an unfortunate event that changed EnGarde’s Vendor and product viability score from whatever it had been the last time IT’s architects had visited it to -2 (the worst possible score), and its disposition to either Replace, if its functionality was still needed, or Retire if no applications or platforms ran on it anymore.

Compare that to a company that relied on BizTalk 2016 as its application integration platform. Well before BizTalk 2016’s retirement, Microsoft announced that its successor, BizTalk 2020, would be released mid-2019, and BizTalk 2016’s end-of-life date (well, month) would be November 2022.

Following these announcements, with a proper version currency management practice in place IT’s architects would have flipped BizTalk 2016’s disposition to Update, and, with that, added a BizTalk Update project to the company’s project master schedule and budget, timed to avoid the expense and risk of continuing to use out-of-support technology in the platform portfolio.

Version currency management is the lifecycle management IT needs. It includes:

• Application and Technology portfolios that track the version in use for their components, although without effective version currency management, “version in use” would be “versions in use.”
• For each component, the vendor’s announced version update and out-of-support schedules.
• Algorithmically derived project schedules and budgets for updating components to current versions.
• Alternatives review, to make sure Update is the optimal disposition, rather than replacing the component with a functionally equivalent but overall superior alternative.
• Technical architecture principles and policies for keeping components current, reviewed, and approved at the executive leadership team or board level, so IT has to fight this budget battle just once.

Gotchas

Version currency management isn’t particularly complicated in concept. But there are a few roadblocks to prepare for.

First and foremost, when you update a platform you need to know where the ripple effects will hit. It’s rare than an update is perfectly downward compatible with the previous version.

Which also means making sure your software quality assurance team is keeping its automated regression testing up to date.

Second, updating an application to its current version can sometimes require updating some of the platforms it relies on. Which means looping back to the platform update gotchas.

And third, especially for application-layer version currency management, scaling raises its ugly head.

Having hundreds — and, in some portfolios, thousands — of applications in production, keeping the database of vendor version update schedules current in the technical architecture management system is challenging. Faced with the magnitude of this challenge, many IT shops give up and kick the can down the road until a component’s version obsolescence results in a crisis. This is a dreadful decision, because when you kick the can down the road enough times you eventually run out of road.

No, application-layer version currency management is as essential as it is laborious. What works best — maybe “least worst” is more accurate — is dividing and conquering, making sure every application in the portfolio has an assigned IT product steward who is responsible for the health, care, and feeding of the applications assigned to them. That includes keeping a database of vendor version plans current.

Understand, version currency management isn’t going to cover its practitioners in glory. Mostly, they’ll be treated the way all bearers of bad news are treated.

The good news about the bad news is that bearing this bad news is better than the bad news you’d bear if you don’t do it.