Core Software Revival: Practical insights from and for business & IT
To this end, we will answer questions customers from various industries regularly ask us in relation with Core Software Revivals and shed light on aspects of business and IT modernisation.
What are typical modernisation requirements concerning core applications in companies?
Roland: Companies are constantly evolving. Needs for modernisation arise either through increased customer expectations towards services offered and user experience or through the advancing digital transformation. If a company aims to offer its customers digital product add-on services or entirely new digital services, for instance, this usually necessitates the mapping of seamless end-to-end processes for these services and often pushes existing core systems to their limits. This requires modernisation in parts or general. In return, companies receive insights into the use of services or products by their customers. Through the data created, they can then better understand the latter, obtain valuable insights and derive measures.
Additionally, product development and provision processes are increasingly digitalised. Required adaptation of these processes often result in core system modernisation requirements. This digitalisation and the associated creation of data allow for the creation of digital twins. This way, processes, products or entire systems can be mapped and visualised in the digital world.
Another large topic is the increased automation of process steps in technical departments to relieve staff on the one hand and on the other increase efficiency. Once again, outdated core systems present obstacles that result in a need to modernise. Another point is the speed of such changes. If one wishes to implement business requirements and process adaptation as quickly as possible, modern systems naturally offer better possibilities to do so.
Another point that isn't usually a core initiator of modernisation efforts, but that we are often asked about, is the acceptance of core systems by employees. If systems and user interfaces are outdated they are often rejected, especially by young employees, and are not perceived as valuable tools but rather as a burden. As a company, one wants to offer one’s employees a modern system that allows for efficient work.
Is the need for modernisation in companies always obvious and how does one deal with IT and business having different requirements or expectations?
Roland: No, the need for modernisation is not always obvious. Also, it's not always clear at first glance, where the need for modernisation originates. Often times, issues arise at a certain point, but a detailed analysis reveals that the actual reason for modernisation to be required lies elsewhere. When we implement projects with our customers, we always try to localise and understand the actual issue. In this context, it's about finding out what the most important factor is for the individual areas. For this, we proceed step by step using analytical and creative methods based on our modernisation model to identify the actual issues and objectives to be reached. Building on that, we define the steps required.
Let's use a concrete example to make this clearer: Recently, we were working on an IT-driven modernisation project, in whose context the IT department aimed to implement a purely technical modernisation as a 'big bang’ on a modern platform. When the business side of the company and the respective technical department learned of the project, however, it had lots of ideas and improvements to contribute and wanted those implemented as well. To cater to all these needs of the technical department and those of IT, we created an alternative modernisation approach and implemented it. The technical department received modernised front-ends with the desired improvements. At first, the back-end processes still run on the main frame and modernised step by step. This way, the technical department received a new system meeting its requirements in a (from its perspective) short time, while IT was able to iteratively replace its main frame in the background, without the business side noticing anything or being hindered.
How do you arrive at a technical IT assessment of a core system?
Michael: Time and time again, we are asked how we arrive at a reliable IT assessment of a legacy system. We take a two-stage approach to such an assessment, firstly by asking specific questions and secondly by analysing the existing system. We usually start by asking questions about the current status of the system and whether there are any known problems. Often, we encounter surprising statements. We also ask what other systems are still in use. Most often, software doesn't consist of a single system, but several interconnected ones. This results in follow-up questions, especially on interfaces and data flow. What systems are supplied by the existing system and where does it get its data from? Another important question deals with modernisation itself. Do you wish to modernise everything or just parts? If possible we also speak with the former system provider / their developers (if they still exist) to get their take on the need for modernisation.
In addition to their answers, we go into a deeper technical analysis in which we examine the source code with tools and thus evaluate its condition with regard to complexities, dependencies of programme parts or modules and thus also the architecture, as well as the general code quality. This analysis provides a complementary, neutral picture of the IT-technical status of the existing software.
What modernisation models are there and which one is the right one?
Michael: There are several replacement and change models depending on whether the main driver for modernisation is of process or technical nature. The latter is usually used in the context of modernisation that is required from a technical standpoint. Then, we speak of models such as ‘Lift & Shift’, meaning a technical platform swap, which today also means going into the cloud. Another approach is called ‘Transpiling’, a tool-supported transformation of a system from one programming language to another one; for instance from Cobol to a more modern language such as Java. Both approaches are based on the idea of a 1:1 migration. If one only wishes to change a part of a system, the ‘Refactoring’ approach comes into play in which we only modernise or encapsule those parts or make them easier to maintain.
Apart form that there are replacement models that are used when larger process changes are on the agenda. This includes the partial or complete replacement of legacy core systems with standard software; especially when the process analysis reveals that many process steps can now be covered by standard software. Alternatively, or often in addition, the use of a low-code platform for individual processes or process steps can also be useful. These platforms usually have their strengths in workflow-like processes or are also suitable for automation between core systems. If neither of the two replacement strategies mentioned is suitable, the only remaining option is to rewrite the legacy system in a modern programming language, taking into account suitable modern enterprise and software architecture principles.
In practice, almost all projects show that there is no such thing as "one strategy fits all", but that well-chosen mixed forms usually make sense, depending on how the overall system can best be replaced.
This means, for example, that some parts can be covered by standard software, others can be implemented with low-code platforms, while still others can be completely redeveloped because, for example, processes need to be implemented from scratch. If one part of the software runs very well and meets all requirements, one can use Transpile or Lift & Shift to lift it to a new technology.
Another practical example, another main frame replacement: Specifically, we are talking about a very large system that ran on a main frame and was supposed to be moved into the cloud. We instantly realised that we would need all our replacement scenarios in one form or another. During analysis, we found that the main frame had a specific authorisation system that could not be moved into the modern world. This was a case for Refactoring on the basis of the Strangler pattern. To save the customer lots of time and money, we didn't want to rewrite the whole system, but our customer still aimed to move the system into the cloud. The original plan saw us use Lift & Shift to do this. This plan had to be abandoned, however, as some parts such as their complex job control system would no longer work as intended. Moreover, it turned out that the younger developers were not exactly familiar with Cobol which meant that a large part of the business logics had to be moved from Cobol to Java using Transpiling. At the same time, our business consulting colleagues worked with the technical department and found out that it needed new, work-flow style features. As our customer was already using a standard software in another area its use in this environment with adequate integration seemed reasonable in order to not confront users with a system change. Other legacy system features were no longer suitable and needed to be rewritten. In the end, we used almost all modernisation concepts on this project to provide the customer and system users with the best value.
Last question: When is the right time to modernise?
Roland: To cut a long story short, there is really no right time to start modernisation. As you, dear readers, already know, modernisation projects include many challenges in practise. That's why many are reluctant to start but as in real life, the longer you wait the more difficult it becomes to improve a situation. That’s why our motto is to start modernisation efforts early. This buys you time to analyse and allows you to plan everything in more detail. Usually, you will also need some lead time to obtain the budget needed. And that’s what the actual answer to the question is that the right time was yesterday. 😉
If you still have unanswered questions, don't hesitate to use the form at the bottom to send them to us. We are looking forward to answering them!
Get in touch!
We are looking forward to your message
* Please fill out all fields
