Why decommissioning IS legacy platforms in Corporate environments is generally slow and hard

Change is not easy, even for prospect of improvements, because majority of people - and organizations are made of people – are not inclined to risk.

When it comes to IS platforms, it is possible to prepare long list of reasons for not undertaking any evolution.

However - paraphrasing Jack Welch - it is always better to change before being forced to do it, for adjustments happen anyway and it is more convenient to drive them instead of withstanding their consequences.

One core reason, in our view, for thinking twice about changing IS platforms is related to consequences of poor retirement of legacy applications and upgrade of IS environment in the change-over phase.

New platforms, new processes

Indeed, new platforms imply new processes, and implementation of these initiatives on corporate scale assumes, first and foremost, that those current processes to be replaced - or enhanced - are well, or at least sufficiently, known.

This is always a challenging condition and what make the difference is not the existence of a reality gaps, but size, diffusion and position of these white spots all across the global organization.

The dark side of the moon

In fact, large organizations have always dark sides.

In our context, this means that next to, or behind, those activities carried out in plain sight (in accordance to official guidelines and platforms), there are additional processes, not in corporate “radar”, which are crucial to such official operations, while specific and necessary to ad-hoc local requirements.

These unknown processes are generally executed by means of a number of non-official solutions, and these local applications – unknown to corporate directories - are often deeply integrated with those official legacy applications to be replaced.

To be clear, these stray processes – and supporting applications - are local yet legal, and they are too many and too fragmented to be taken all into account.

Paradoxically, this creates a perfect “lose-lose” situation, because it gives sometimes corporate program managers a good excuse to overlook them, and justify as well local managers too for not undertaking clarifications with global platform owners, because of a badly applied “don’t ask, don’t tell” concept.

Range of such peculiarities and specialties covers in principle any domain of activity. Often relevant unforeseen applications answer to needs, which may arise from local legislation, legacy of practices (for instance in case of M&A), and from any typically local process domain (for instance fiscal laws, or commercial practice), which makes globalization not fully global yet.

In certain further cases, while not accounted for, such off-radar activities are crucial for effective operations of those official guidelines which targeted legacy applications, going to be retired, support.

In fact, as often it happens, global IS platforms do not cover fully the details of daily fragmented activities. This obliges local IS teams to use their ingenuity to fill functional gaps with add-ons and plug-ins applications, which make the global process enabled, while now integrated on local basis.

In other circumstances, while not strictly needed, these non-official activities are however functional to keep going smoothly the organization, by granting and maintaining local uses – whatever - up to a level of granularity which is not known at corporate level, and disregarded – deliberately or not - in the global scope of replacement.

Unfortunately once this local complementation starts, by means of local IS teams, then troubles start accumulating too with time and use.

The original local good intention to lubricate declination of global processes, while running also in accordance to local tastes, leads soon to growing ramifications of more granular and very specific practices, which may lead to build of whole parallel IS environments, whose legacy platform, addressed for retirement, will be just the tip of an iceberg.

It is easy to understand that a corporate program meant to decommission a legacy platform, without knowing enough about its ramifications and roots, it is very similar to going through a mine field without knowing where mines are buried.

Shaking the tree

In order to explore existence and extent of hidden gaps and white spots, a reasonable and prudent way is to probe targeted organization by launching scalable approach instead of full scale programs.

By assessing resistance and operational impacts, program managers may try to understand what is behind these reactions and adjust both deployment plans and characteristics of deliverables.

In order to avoid potentially catastrophic roll-backs, when late discovery of hidden processes may force to develop alternative plans, it is advisable to start with ancillary processes, instead of addressing - first thing - core show-stopper activities.

Resolution and vision

Even after that we know what is necessary to be known, this does not grant by itself that it is possible to go beyond road blocks, unless proper leadership is displayed and vision is offered and shared with local organizations impacted by the change.

In fact, knowledge of the actual picture – always partial by its own nature – does not imply too that scalability can be properly set up since inception of any corporate program.

It takes a clear vision to know what to implement, how to develop and adjust the plans and how to engage and communicate in credible way advantages, objectives, pitfalls and failures (as failures always happen).

Moving too hard and with too much momentum may result on a one-way walk over quicksand for those resources careless engaged in development and deployment.

Buy consensus

Permanent gathering of intelligence - before, during and after the official program lifetime - helps also for crucial activity of identifying and engaging - in the proper fashion - those people and functions, which may help in definition, development, deployment and maintenance of corporate IS platforms.

As an example, for legacy platforms, it may help to invite their owners to co-own and run activities of phasing-out, by offering credit for new adjusted deployed solutions, in return of full and active support in neutralization and retirement phase of their former creature.

Motivating the right people - by use of any appropriate means – makes always the difference.

Migration goes with mitigation

The capacity of conceiving alternative scenarios, as consequence of developing knowledge about actual boundary conditions for the program, may help in reducing impact of unplanned situations.

However, plan B must always exist.

Increasing knowledge of full extent of targeted legacy applications, which does include all connected unknown ancillary applications, advises often to have contingency migration plans in addition to scalable solutions.

It is about “clustering” and removing, instead of eliminating them one, by one.

This implies changing plans and it may oblige to stretch timelines, in order to allow for consolidation of scattered applications before replacement in single instance solutions.

Of course, without credibility and leadership, no plan B works well. In fact, this would only result in delayed plans, without adding certainty to deliverables.

Conclusions

Programs have to be planned - carefully and enough - before being executed with resolution and as quickly as possible.

If time variable starts running out of control (outside tolerance of anticipated allowances), and costs follow, this means that planning has to be revised with redefinition of basic assumptions and re-focus on priorities.

Legacy platforms may be a major cause for unwanted program evolution, and this is why their addressment is a priority for validation and ultimate success of any corporate IS initiative.

Sun Tzu would have probably said to program managers that they have not to worry any program if they know their resources and objectives and their opponents as well.

 #transformation #digitalization #change #strategy #IT