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:
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:
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.
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!
