The business aspects of software modernization

Never touch a running system.

This is an age-old premise in the IT world, which is often still practiced to this day out of fear of change and error, and this will probably be difficult to change in the future.

However, this approach is often not effective because, although it can be applied to the micro-segment, it does not appear to be suitable for everyday use in the overarching, big picture. This is especially the case when certain economic components are added and there is a compulsion to react to external changes.

Therefore, there is one key question to ask in software modernization: "Why modernize?"

Of course, there are also extreme constellations in which modernization makes no sense from a technical or economic point of view. This must be recognized and only those who are experts in this field can reliably judge when the risks are too high for the possible benefits. In this case, it is the duty of every responsible service provider to point this out.

In our white paper, we already describe in detail why and when you should modernize. However, we mainly focus on the technical aspects and neglect the economic and organizational components.
When it comes to modernization, we also like to use the comparison to the Nash equilibrium - if all factors of a game remain permanently the same, so does the result. But the moment a player changes a factor, the other players must also react to the change. - And it is exactly the same with the modernization of systems in a competitive context.

A good example is the appearance of the first innovative smartphones. Until then, a few companies such as Nokia, Sony and Siemens were market leaders in that field. But then the first iPhone appeared, promising consumers a completely new experience. Nokia and Co. did not adapt their technology or their production and thus lost their pioneering position very quickly. Even if this example leaves out many details, it shows in a radical way what effects such a -non-reaction- can have.

And just as Nokia and other manufacturers couldn't know what the new trend of smartphones would mean, those in charge can't always foresee the impact of relying on legacy languages or legacy systems for too long.

In industry, these effects are not always immediately foreseeable, which is why legacy systems are used for far too long.

The reasons for modernization are almost always economic, because no one modernizes just for prestige or ego. These economic reasons are often indirect and are often not reflected in sales, but even the lack of labor in certain technology areas has a direct impact on the sales a company can achieve.

But first back to the original question - But why modernize now?

Modernization can be useful or even necessary for many reasons:

One reason for modernization is the lack of qualified workers in certain technologies. It has become incredibly difficult to find and hire COBOL, PL/I, mainframe, AS400 programmers/experts. If, on the other hand, you rely on industry standards such as Java, C# or Python, for example, it is much easier to fill positions.
Adaptations to a system become cumbersome, too time-consuming or even completely impossible. This is always critical when an application or infrastructure needs to be adapted quickly and easily for legal reasons. This includes legal requirements, such as adjustments to tax rates or adjustments to accounting obligations, or saving data according to appropriate standards, or the like.
Architectural components, such as databases or application servers, are outdated and need to be replaced. In such cases, the application is often the bottleneck. Costs for mainframe and co. with a non-optimized code base cost more than programs and applications running in a modern cloud environment and architecture. The same is true for database migration. Many of our projects have the simple background of migrating databases from Informix or DB2 to Oracle. In these cases, an outdated legacy application would again be an extreme bottleneck, making migration completely impossible.
Not only do outdated application architectures cause younger candidates to refuse to work on a system, but it also causes performance to suffer. SOA or microservice architectures often cannot be implemented with old, monolithic architectures of legacy languages. This factor should not be underestimated, especially if there is a customer user base that also uses the application (e.g., online insurance calculators for consumers or rate calculators for banks).
Legacy languages and legacy applications are often a reason why moving to the cloud becomes impossible. However, this move is usually a useful and cost-effective process. Many large enterprises are trying to move away from mainframe and co. and the high MIPS costs associated with them. But an old legacy application makes exactly this goal unattainable.

But why do CIOs, CTOs and C-level managers not dare to tackle these systems and architectures?

To do this, you need to understand what agenda a C-level executive has. At this level, managers have a fixed-term contract of between 2-5 years and they often have overall responsibility for IT and its smooth operation. Now, if one goes for modernization, existing systems change and a risk arises.
Often, new systems and the associated new GUIs are not welcomed by the user base. Many managers are not willing to take these risks.

But now for the interesting part of the whole thing...

Legacy and software modernizations can be carried out with virtually no risk and
without downtimes of operational systems. In addition, modernization always involves a proof of concept including a pilot phase, which is basically nothing more than a reflection of the overall project.

Many companies do not consider the monetary damage they can cause by not modernizing old systems.

Our following basic approaches have already proven themselves in many situations:

You can't force modernization on anyone!
It's not just management that needs to get on board. The user base and stakeholders must also be involved. If you don't want to take into account the relevant factors, there's no point in embarking on a transformation. After all, modernization is impossible without cooperation with the customer.
Fears and concerns must be taken seriously.
No questions must be left unanswered. The concept and approaches must be complete and understandable. The customer must understand how and with what means the analysis and later the transformation of his systems will be carried out.

A central element of our modernization and transformation approach is that the business logic of the systems does not change. All of the company's existing processes need not and should not be adapted.

No means are used that influence the complexity. Likewise, no runtime environments may be created. The output must be genuine, because only in such a way arises after successful transformation into a new system -> for example "Real Java".

There are many differences between Cobol and Java. Both languages use data and resources differently and communication also differs greatly. Conversely, this means that Cobol methods cannot be transformed directly to Java, which immediately precludes migration of the source code.

And here we already have the problem that occurs when using many converters, because they take the complete source code and transform everything into a new code.

But why do I take parts of a code that are not needed in the new environment with me to a new environment?

If one understands and internalizes these realities, a transformation can be approached with a very high degree of self-confidence.
The decisive factors here are know-how and experience with modernizations.

With this well-founded approach, which has already proven itself many times over, we hope to be able to take away this fear from our customers. Because if a service provider lacks this expertise, we too would be afraid of a transformation.

With our knowledge and practical experience, modernization modernization projects, however, are no cause for concern!

You have questions?

Our experts support you and are here to help you with any questions you may have.

Or take a look at our references.