Never touch a running system.
This is an age-old premise in the IT world, which is often still practised today for fear of changes and errors, and this is unlikely to change in the future.
However, this approach is often not effective, as it can be applied to the micro segment, but does not seem suitable for everyday use in the overarching, big picture. This is particularly the case when certain economic components are added and there is a compulsion to react to external changes.
There is therefore a central question that must be asked in the context of software modernisation: ‘Why should we modernise?’
Of course, there are also extreme constellations in which modernisation makes no sense from a technical or economic point of view. This must be recognised and only those who are experts in this field can reliably assess when the risks are too high for the potential benefits. In this case, it is the duty of every responsible service provider to point this out.
In our white paper, we describe in detail why and when you should modernise. There, however, we mainly focus on the technical aspects and somewhat neglect the economic and organisational components.
When it comes to modernisation, we also like to use the comparison to Nash equilibrium – if all factors of a game remain the same at all times, the result will also remain the same. However, the moment a player changes a factor, the other players must also react to the change. – And it is exactly the same with the modernisation of systems in a competitive context.
A good example is the appearance of the first innovative smartphones. Up until this point, a few companies such as Nokia, Sony and Siemens were the market leaders in this field. But then the first iPhone appeared, promising consumers a completely new experience. Nokia and co. did not adapt their technology or production and very quickly lost their pioneering position. Even if this example omits many details, it shows in a radical way what effects such a -non-reaction- can have.
And just as Nokia and other manufacturers could not have known what the new trend of smartphones would mean, those responsible cannot always foresee the consequences 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 modernisation are almost always economic, because nobody modernises just for reasons of prestige or ego. These economic reasons are often indirect and are often not reflected in turnover, but even labour shortages in certain technology areas have a direct impact on the turnover a company can achieve.
But now back to the original question – why modernise now?
Modernisation can be useful or even necessary for a variety of reasons:
But why do CIOs, CTOs and C-level managers not dare to tackle these systems and architectures?
You need to understand what the agenda of a C-level executive is. At this level, managers have a fixed-term contract of between 2-5 years and often have overall responsibility for IT and its smooth operation. If modernisation is undertaken, existing systems change and a risk arises.
New systems and the associated new GUIs are often not welcomed by the user base. Many managers are not prepared to take these risks.
But now to the interesting part of the whole thing…
Legacy and software modernisations can be carried out practically risk-free and
without any downtime for operational systems. In addition, modernisation 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 modernising old systems.
Our following basic approaches have already proven themselves in many situations:
It's not just management that has to get involved. The user base and stakeholders must also be involved. If the relevant factors are not taken into account, there is no point in embarking on a transformation. Because modernisation is impossible without cooperation with the customer.
No questions must remain unanswered. The concept and the approaches must be complete and comprehensible. The customer must understand how and by what means the analysis and subsequent transformation of their systems will be carried out.
A central element of our modernisation and transformation approach is that the business logic of the systems does not change. All of the company’s existing processes do not have to and should not be adapted.
No means are used that influence complexity. Similarly, no runtime environments may be created. The output must be genuine, as this is the only way to create ‘Real Java’, for example, after successful transformation into a new system.
There are many differences between Cobol and Java. Both languages utilise data and resources differently and communication also differs greatly. Conversely, this means that Cobol methods cannot be transformed directly to Java, which immediately rules out the 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 new code.
But why do I take parts of a code that are not needed in the new environment with me into a new environment?
If you understand and internalise these facts, you can approach a transformation with a high degree of confidence.
Know-how and experience with modernisation are crucial here.
With this well-founded and proven approach, we hope to allay our customers’ fears. Because if a service provider lacked this expertise, we would also be afraid of a transformation.
However, with our knowledge and practical experience, modernisation projects are no cause for concern!
