Managing the risk of not upgrading

Recently, I talked with a friend working for a public administration. He was very happy because they finally would be migrating to Java 8. Yes, you read that right.

Telling it just like it is

Just to get a common understanding, this table shows the support roadmap for Java versions (from Oracle Java SE Support Roadmap):

Prices for the different support levels are not publicly available, as it depends on a lot of customer-specific factors. Suffice to say, the price is growing with every support level: e.g. "extended support" is more expensive than "premier support".

I told my friend he should probably migrate to Java 11, to jump on an LTS version. His answer was that they couldn't move all their applications (> 500) every 6 months. While this is a fact, it also qualifies as unmanaged risk. What will happen if a bug in the JDK is discovered? What if it's a blocker impacting, let's say, half of the applications?

Note that the end of Public Updates for Java 8 is September 2017, already three year ago!

Implicit vs. explicit decision

At that point, the decision has already been made implicitly, without any data supporting it. And I believe this is a serious issue.

As a manager in a technology department, it's one's duty to make decision while being as informed as possible - or to provide the decision makers with the necessary data to make such decisions. For example, in the current situation, that means that at least the following themes should be put on the table:

• The straightforward path: ** How much does the support cost? i.e. request a quote from Oracle sales ** How will the cost evolve over time?
• Delaying the migration: How much would it cost to migrate applications to Java 11 instead of Java 8?
• Alternatives: ** What are possible alternatives? ** Are there alternate JVM providers e.g. Azul, AdoptOpenJDK, etc.? ** What are their respective support policies? ** What is the associated cost? ** What is the cost of testing a sample of the application portfolio in order to check for compatibility?
• Preparing for the worse: ** How many of the applications do have a business continuity procedure? ** How much does running those procedures cost?

Of course, this is only a sample of the possible questions - and answers, that could help come to a decision.

In essence, it all boils down to the risk management triangle:

1. Severity of the risk: What's the impact of the risk?
2. Chances of the risk occurring
3. Mitigation cost: Is there one or multiple way to mitigate the risk? What are their associated costs?

Conclusion

Usually, technical debt is only approached through the lenses of code. Sometimes, it goes as far as to include libraries, or even application architecture. However, everything that is required by the application needs to be taken into account: platforms, operation systems, etc., in one word infrastructure components.

In the end, it's easy to ignore the problem: just push it under the rug, and it's done. But when the fecal matter hits the rotary impeller - and it will - the blame game will start. At this point, the organization will be bogged down into finding the "root cause": it will be a complete waste of time, with no documented decisions available. And it will happen again and again.

Some organizations already document their decisions regarding architecture. Infrastructure components should be subject to the same process. This is the next step on the maturity scale in the management of technical debt.

To go further:

• Business continuity
• Risk management
• Eliminating Java Update Confusion
• Java version history
• Architecture decision record (ADR) examples for software planning, IT leadership, and template documenation

Originally published at A Java Geek on June 14th, 2020.