Do applications have the right to retire?

Today’s enterprise application landscapes are voluminous, complex and scattered. Over the past decades, new applications have been added to the landscape using the popular technology of that decade. Therefore, it can be that one organization has several applications built in Cobol, PL/1, Oracle Forms, PowerBuilder, Adabas/Natural, C, C++, Microsoft VB, Java or C#, and standard packages, like MFGPro, Baan, PowerSoft, SAP, Oracle, Hyperion, among others.

In addition, mergers and acquisitions have complicated the application landscape. After a successful merger,  one organization has or will acquire two or three ZX systems instead of one ZX system. Moreover, all three will probably be based on different technologies. The past decades, more applications were added to the application landscape, but none of them were faded out.
It is evident that the costs of maintaining such a scattered enterprise application landscape are oversized. Costs are outrageous as a result of maintaining several systems with more or less the same functionality, and due to maintaining scarce resources and skills of different technologies. Therefore efficient application management of the legacy-environment is now high on the CIO / IT Management agenda.

Apart from the maintenance costs, there are also hidden costs: the costs of legacy applications that hinder innovation. There is something paradoxical with legacy applications: they support the most essential business processes and they also form an obstacle for today’s business needs like agility, flexibility and time-to-market. The legacy applications may impede new business opportunities and business growth.

There are many (technical) strategies to deal with legacy applications: encapsulation, wrapping, re-hosting, re-plat forming, replacing, re-engineering or re-building it. Alternatively, one can also choose the strategy of just doing nothing.

It is a strategy a few organizations are following today. They set up a completely new environment apart from the current one, mostly based upon standard package functionality. The legacy applications are “frozen” and its application management is out-tasked or outsourced.

Yes, indeed, applications do have a right to retire. End-of-Life Application Management is a serious scenario to be considered for legacy applications. By placing them in an end-of-life scenario, a minimum level of service is keeping the applications alive at low cost including only “must have” changes. Don’t kill your legacy; retire them.

Kees Kranenburg

Kees Kranenburg is CTO Systems Integration BeNeLux. His field of play is software development and application management and the organization, processes, methods and tools necessary to professionalize and industrialize them. He is responsible for the standardization and industrialization of service delivery and manages the core SI competences. Kees is member of Atos Global SI Software Engineering Process Group and chairman of Atos Global SI Software Engineering Technology Group. He is author of some books, “Model-based Application Development” (1995) and “Managing a Software Factory” (2008), among others, and several articles in public.

1 comments

  1. Ryan Bryers says:

    Hi Kees, a very good article. I’m an Enterprise Architect in UK SI Architects Practice and the scenario is one we face all too often in large opportunities where the client is essentially recognising the problem you outline and uses an outsourcer like Atos to accept the risk on their behalf as innovation is always required.

    The problem I’ve often faced is the diverse expectations of the client and the client workforce. The client wants rid of the legacy estate and will recognise a series of applications and packages that are out of support but are central to business operations. The client workforce, especially in government and health, are so tied to the existing solution and system (despite its age and strategic capability) that change is blocked in a hostile manner. In the end the workforce can be the blocker to successful migration. Interesting then that in TOGAF the ability to be a blocker is only assessed at the Senior Stakeholder level.

    Ah well, it keeps us Enterprise Architects busy :)

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>