Skip to content

Chapter 3

Consideration 2: No prescription without a diagnosis

An answer to the question of why to start a software modernization journey, can be seen as an indication of the symptoms of outdated IT. The next step is to find out what the underlying causes are; to diagnose the problem.

FOR THIS DIAGNOSIS, TWO QUESTIONS NEED TO BE ANSWERED.

What requirement gaps can we identify?

Some IT landscapes are not unlike a medieval cathedral. It took vast amounts of effort, material and money to complete these often complex structures. Over great amounts of time, additions might have been built, and subtle changes introduced. The church however, has been able to fulfill its intended purpose for centuries, and, as long as this raison d’etre still holds, will continue to do so. It makes no sense to tear down the church in order to modernize it. However, by modern standards, the church might be cold and dark. So in order to meet new requirements, a central heating system is added, electric lights are installed, and a WiFinetwork is set-up.

Other IT landscapes are more like houses. Most houses do not last as long as the cathedral might, and the owner’s requirements for the house will change at a faster pace. A new kitchen or bathroom, solar panels on the roof, an extension or a new conservatory, all changes that might profoundly affect the house. However, the foundations and load-bearing walls will probably remain the same. If the owners do not have requirements that are too different from the starting requirements, it does not make sense to tear down the house.

As with the cathedral and the house, in order to determine whether to replace or upgrade an IT landscape, and how to upgrade, depends on the gaps between current (and future) requirements, and those the system is able to fulfill. In our diagnosis, the first important step is finding out where those gaps are, and how big they are. In terms of our example, the church might be too cold. In terms of an application landscape, developing certain new products might be hindered. Where does the existing landscape not meet current or future business requirements?

What IT problems cause these gaps?

Once we have a clear view of what the gaps between the capabilities of our current IT landscape and the desired capabilities are, the second stage of our diagnosis is finding out what underlying technical issues are to blame. In this stage of the process, we look at the technical side of things. What applications are in the landscape, how are they connected, how have business processes been implemented in IT systems.

For each problem identified in the first stage of the diagnosis, a root cause analysis will be performed on the IT landscape, with the goal of finding out exactly what technical issues underpin the problems felt by business. Is a certain application notperforming? Are there no(t enough) people to maintain and expand a system? Is automation of certain tasks insufficient? Do people need to work around inflexible systems?