<img height="1" width="1" src="https://www.facebook.com/tr?id=292546644544618&amp;ev=PageView&amp;noscript=1">

Decommissioning - it is time for spring cleaning in your organization

Sooner or later, every organization is faced with the problem of decommissioning an application being used. This happens for many different reasons.  

We’re decommissioning!

So, why would you want do decommission in the first place? For starters, an application may no longer be suitable for business requirements having changed over time. This can, for example, be related to the functionality of the application or the ergonomics of its use or the user interface. The modification of the application is expensive enough and does not have sufficiently good effects for the changes to be feasible. Therefore, a new application should be implemented, and the old one should be decommissioned.

Secondly, an application can be simply no longer necessary. Perhaps it was used for a product that we no longer sell and we want to completely cease its support. Perhaps it handled processes that turned out to be unnecessary. Perhaps in the last 6 months, no one logged in to the application.

We may also be dealing with the duplication of functions. We have another (newer, better) system that does the exact same things. This situation can occur in many ways. One of them is the merger of two (or more) organizations that operate in the same sector.

Maintaining an application can be too expensive. The costs related to maintaining the application exceed the benefits arising out of its use. The reasons for this can be the same as described above. There can also be the issue of technological debt – applications that have not been updated for many years become difficult for IT to maintain. This particular application can require specific technological skills. The organization needs to maintain these skills just for this application alone. Software and hardware vendors have policies that force clients to upgrade – cost of supporting old versions exceeds cost of supporting new versions by order of magnitude.

Several things can be done with a decommissioned system. We can simply shut it down and forget about it. This is a rare case. Most often, such systems are integrated with other systems. Therefore something needs to be done in order for existing processes to continue to operate. Another reason is when we need to keep the data, e.g. due to compliance or regulations.

The most common situation is that we will want to retain certain (perhaps all) of the system functions and its data. Functions can be reimplemented in new or existing systems. Case by case, it would be done in a different way. In the case of data, we can follow the path of the transferred functions. However, often we would not want to transfer the full changes history to the target system. Historical data will be sent to a dedicated archive or to a data warehouse.

But it is difficult…

When an organization makes a decision regarding the implementation of such a project, it turns out that it is not as easy as it may have seemed. Most often these are old legacy systems which are decommissioned. The company no longer has any people that have a system related knowledge – about related processes, integration, and use cases. This causes discomfort to the decision makers – what could stop working once we shut down the system? How critical is it to the organization? Will we be able to quickly repair this problem?

In turn, it means that each system decommissioning project is preceded by a long and detailed analysis. During such analysis, it generally turns out that the system was incrementally developed and modified by different teams and by different vendors. The consequence of this is a lack of consistent documentation regarding the system, which fails to comply with what is actually operating in the production environment. In addition, the system architecture and data models were also incrementally developed and modified, with a wide range of anti-patterns.

The data model is “secured” for the case of further development with a set of attributes such as param1, param2, param3,...; in various places. This design pattern is often implemented in the application logic or even in the application interface. This chain of relations means that we have a structure that everyone is afraid to touch for fear of it “blowing up”. This means also that some of the dependencies between data that could be clearly described in the database structure are programmed in the application logic, which makes them more difficult to read and harder to find!

The attributes of data objects are used in the source code in different ways. The business logic of applications provides data with different meanings depending on the call context. For example, if we are dealing with product A, then the ‘date’ field means the date on which an agreement is signed, if it is product B – the date on which an agreement becomes active, and if the ‘status’ is ‘inactive’ – the agreement termination date. A “bunch of if’s” that is copied into different parts of the code, and then modified in just a few of these places, is one of the biggest nightmares of programmers or systems analysts.

This phase of analysis is to some extent a process of reverse engineering the application. System decommissioning projects mainly fail because during this phase of analysis, it is not possible to restore the full logic of the system’s operations. Because of that we can encounter decisions regarding “printing” the system – due to the risk of overlooking a certain business logic, a complete set of source data, the source code, and interpreted data (like reports) should be archived.

Dear Editor, what needs to be done then?

How should the problem of difficulties in system decommissioning be solved? It seems to me that the method is simple, though it may seem to be a bit iconoclastic. Each system has its own life cycle. Its decommissioning should take place within a few, at most a dozen years from the implementation. Fast forward yourself to the moment you decommission the system. Now think what do you need to do it efficiently. Convert it to requirements. And repeat this process every time you design and implement any changes to the system.

Difficult? I think not. It just requires a somewhat different way of thinking. It requires a somewhat less emotional bond with “one’s own” application – it will not last forever. Will this be more expensive? Perhaps – if we will prepare well-designed solutions instead of quickly made and improvised ones. However, the difference in cost should not be significant. However there will be a big difference in costs of the decommissioning project.

In such architecture, IT projects, even the less sexy ones such as migration and system decommissioning can be more pleasant and much less stressful.


software development, application development, decommissioning, application lifecycle
Paweł Kot

Paweł joined ITMAGINATION in November 2016 after leaving PZU Group where he held the role of IT Architecture Director. In ITMAGINATION he focuses not only on insurance but on the whole financial industry acting as Enterprise Architect and Product Manager responsible for the product portfolio for FSI clients.

Would you like to learn more? Contact us.