‘A supposedly key application turned out to be a hindrance’

• Even the best application becomes a nightmare if it is not regularly maintained - this necessary maintenance effort is usually underestimated.

• A successful modernisation starts with a look at the business requirements the application has to meet and an analysis of the current state of the application.

• Is your key application a USP or rather a brake pad?

Creating new things is often more exciting than improving what you already have. But in this interview, Regina Dietiker explains why companies should invest in the modernisation of their software landscape.

Why do companies need to keep their software applications continuously updated?
In companies, the software structure usually grows over time, with new applications and features being developed and added. However, the best solution is not always chosen for each new project, because this is often associated with additional costs. Often they will opt for a faster solution that may be more cost-effective at that moment. And this means the architecture gets more complex all the time. In this process, companies often neglect to tidy up, and the technical ‘arrears’ mount up.
 

What are the major challenges here?
The task of maintaining and continually modernising software, or ‘housekeeping’, is often underestimated and neglected. But this requires reinvestment of around 20 to 30 percent of the overall budget. Costs are frequently yet incorrectly viewed as overheads that companies will often seek to save on, or fail to include in their calculations from the start. It is up to management to change this. Because when companies neglect maintenance of their existing software, they can incur damage that can prove very expensive later on.
 

How so?
An application is developed at a particular point in time to solve a specific problem. Naturally you use the latest technology and follow best practice in the work. Then years go by, and the software is enhanced based on the existing architecture, technology and familiar methods. Meanwhile the paradigms are shifting; new frameworks and technologies become state-of-the-art, and working methods change. Good IT governance means ensuring that systems remain operable, maintainable and adaptable. For some changes this is relatively simple, in other cases highly complex, and it may not make sense to rebuild; replacement may seem the more lucrative option. But complete replacement involves a very large, expensive project that comes with a lot of risk. And on top of that, the core business does not profit directly in the first instance, and instead has to deal with changeover issues in the early days.
 

Are there differences between sectors here?
There are both sector-specific and task-specific differences. But in the legacy sector, the greatest challenge is always software engineering, meaning the ability to look at things at various levels of abstraction and transfer them to the business logic.
 

What’s the best way to approach this?
It is worth going back to square one and asking yourself: what are the key functions of this software? Which goal am I trying to reach with it? A thorough analysis will ultimately lead to sound diagnosis: what is required in this particular case? Do we even need this application anymore? Do we need to make additional purchases? Do we want to modernise the existing system and get it up to a maintainable standard, or do we need something new? Then comes the planning and the project implementation as well as the follow-up maintenance. If you get this process right, you can really reduce your future costs.

What are the pitfalls?
Discussions within the company will often reveal sensitivities and internal politics associated with application landscapes. There is sometimes a disconnect between the company’s view of itself, and an external view. I remember one case from the services sector where a supposedly key application turned out to be a hindrance to further development. The solution was to purchase additional software. Naturally an external partner like Zühlke is much better positioned to table a recommendation like this.

What are the success factors?
The important thing is that larger-scale modernisation projects are well managed with regular involvement from all essential stakeholders. This requires capable architects and developers who can work at different levels and develop suitable concepts for the controlled execution of the rebuild or new build. A project like this is never just about technology, it essentially has an impact at the organisational level as well, and leads to changes in processes.

What should CEOs and CIOs do?
They should carry out a precise analysis, create a modernisation strategy, and put together an effective team of internal and external specialists. The decisive factor here is that you should never build a solution without first understanding its impact on the three levels mentioned earlier – organisation, processes and technology.