A Blog Series on Application Modernization

Welcome to this new series on Application Modernization. The posts in this series try to capture my thoughts around the topic and eventually will end up in a more curated publication. First and foremost my aim is, to give an overview of the state of research in this area, an overview about good practices and proven approaches but also anti patterns I saw in 15 years of projects with more or less success. I am struggling to start this writing for years and it makes me happy finally have the confidence and willingness to start.

Figure 1: The DP Dollar

I start this writing in interesting times. Even though the need for application maintainance and also modernization was well accepted for decades already, like in the NCC 82 Paper “Application generators at IBM”[1], see Figure 1: The DP Dollar. Even back then the notion of missing skills in the workforce was mentioned and used to explain the need for 4th generation application generators. As we know from historical developments this has been an ongoing challenge for the past decades already. Even this fact has been elaborated and discussed in academia and the business world, there always has been too much hope for technical solutions or some magical disappearance of the problem. Today the awaited remedy is based on generative AI.

The desperation for a solution is massive and therefore the expectations in a AI based solution is immense. A closer look at the problem will reveal, that today’s technology can only be an assistant and not a solution itself. The technical debt that the IT infrastructures have build is only to small parts a pure technological one, but also in many parts a intellectual one. The first chapter of this series will introduce the reader to some history and some of the reasons that led us into today’s situation and why simple solutions always fall short, especially in the area of AI in most recent discussions.

Before diving into solutions and technology the next section will elaborate the problem dimensions and also the reasons why to act. This is especially important as we often dive into a solution before, we really understand the issue that shall be cured with it. These drivers for modernization will also come with side effects that need to be well understood to prevent the same problems in future again.

To asses the size of the problem and work out a step by step modernization approach it is important to understand the dimension of the landscape, assess the issues and gaps as well as the technology itself. This will lead to a clear understanding and allows to build a plan, when and how what artifact needs to be analyzed and changed.

The next step is then an in depth analysis of each application in focus to understand its state. Very often the documentation is lacking not only on a technical, but also a business process level. The rediscovery of the actual business to support is very crucial to the modernization itself, as the target will not be just a technological refresh but also an alignment with the changed business needs.

Another requirement for the execution of a modernization is a clear definition of the future target architecture. This will not be a detailed technical stack as such and by no means a collection of tools and frameworks, but a clear view on the chosen design patterns, used architectures and a rough estimated technology variety. Each project later needs a certain freedom to work out details that then will easy match with each other’s though.

In the section of How to modernize, the different approaches to modernization will be introduced and explained how to apply those with the given problem state. Every chapter will give some examples on successful implementations of the approach, but also a set of antipatterns that should be avoided.

The final thoughts in this series will be on how to avoid the scale of the problem in general. While we are working in a rapidly changing industry, there are practices that at least prevent us to end with


[1] National Computer Conference, 1982 – “Application generators at IBM” by AARON M. GOODMAN: https://dl.acm.org/doi/pdf/10.1145/1500774.1500818

This Post Has One Comment

  1. Christoph

    Dear Tobi,
    “there always has been too much hope for technical solutions or some magical disappearance of the problem.”
    I find this to be painfully true, but it also never fails to make me chuckle.
    I think the problem with this sort of hope or expectation is that you cannot prove to its believers that it isn’t going to happen. It is like a carrot on a stick: The reward is right there, just one more step and we should reach it. All the while new problems and new debt keeps amassing.

    Looking forward the next part!

    Kind regards
    Christoph

Leave a Reply