Legacy System – Business Logic Buried in the Source Code

Whether in the financial sector, the insurance industry, or telecommunications — you find software with a long lifespan and a high proportion of business logic everywhere. This combination in a legacy system can lead to problems that you are best off thinking about right when the software is being created. At the latest, however, after a few years these problems will be screaming for attention. But what exactly are they? And what can you do about them?

First, two definitions:

1. Business logic code implements the knowledge that is important to the company. In the financial sector, for example, the rules for assessing the risk of loans are business logic code.
2. Technical code implements the business logic code on the given platform. Persisting risk assessments of certain customers in a database is an example of technical code.

The lifespan of these two different types of code is very different.

Technical Conditions Change Quickly

From mainframe to client, on to the company’s own server farm and into the cloud. From Smalltalk through Java to Kotlin. From SQL through Hibernate to Mongo. Technologies are constantly changing, and you cannot resist every technological shift.

Business Logic Code, on the Other Hand, Is Relatively Stable

The knowledge of the company may expand and change bit by bit. But you will hardly ever start completely from scratch. Here a new legal requirement, there an extension of existing rules — but you will not throw everything overboard. Especially when it comes to knowledge that was coded 15 years ago by employees who may no longer even be with the company, the work of recovering that knowledge from the code is difficult at best.

A Common Problem — Mixing Business Logic and Technical Code

A problem obviously arises when these two types of code are mixed together. If a clean separation of business logic and technology does not take place, the different requirements for the lifespan of business logic code and technical code lead to serious consequences.

Once the software has grown in this way for a few years, you can only deal with technical changes in one of two ways:

1. Not implementing technical changes, or only very slowly

   The first path is initially the easier one, as it leads to low costs in the here and now. However, you do not solve the problem this way — you merely push it ahead of you. Furthermore, you not only fail to implement the current technical adaptations, but you also fail to keep up with future technical steps. Ultimately, you risk being overtaken by younger, technically better-positioned competitors.

2. Modernizing all technical and business logic code

   The second path is usually associated with extremely high costs. A complete migration of a large software system can drag on for years — years during which both the technology and the market requirements continue to change, delaying the migration even further. A business nightmare!

How Can You Address This Problem?

If you are developing a new system, the answer is simple: separate business logic code and technical code. Under no circumstances allow a mixing of technology and business logic! A model-based approach is very well suited for this, in which you model the business logic and the tool generates the technical code from the model. In this way, it becomes easier later to respond to technical changes by modifying the generator.

Whether you predominantly use textual DSLs (Xtext) or graphical DSLs (MPS) depends on many factors. Whether, for example, domain experts should write code is just as relevant as the experience of the available developers or licensing considerations.

For a large, grown system, the answer is considerably more difficult. Whatever you do, high costs will arise. The most important imperative here must be not to let those costs arise twice.

If you are migrating code on a large scale or even rewriting it incrementally, one of the core goals must be to prevent these high costs from arising again in the future. Here too, you should work toward freeing the business logic from the technical code and ideally mapping it in a model. From this model you can then in turn generate technical code for the new target platform. How you obtain this model from the existing source code — manually, partially or fully automated — depends very much on the existing code base, i.e., on the individual case.

Whether partially automated migration of your legacy system makes sense is explained in our blog post „Can the Modernization of Your Legacy System Be Automated?".

Legacy Modernization at itemis — We analyze the potential of your legacy system together with you and support you on the path to a modern architecture: Legacy Modernization →