/ TECHNICAL DEBT, RISK MANAGEMENT, MATURITY LEVEL

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):

Table 1. Oracle Java SE Support Roadmap
 Release LTS GA Date Premier Support Until Extended Support Until Sustaining Support

6

N/A

December 2006

December 2015

December 2018

Indefinite

7

N/A

July 2011

July 2019

July 2022

Indefinite

8

N/A

March 2014

March 2022

March 2025

Indefinite

9

September 2017

March 2018

Indefinite

10

March 2018

September 2018

Indefinite

11

September 2018

September 2023

September 2026

Indefinite

12

March 2019

September 2019

Indefinite

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?

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.

Nicolas Fränkel

Nicolas Fränkel

Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps. Currently working for Hazelcast. Also double as a teacher in universities and higher education schools, a trainer and triples as a book author.

Read More
Managing the risk of not upgrading
Share this