What are the Major Risks of Legacy Applications in the Context of Enterprise Architecture?

Most of information technology (IT) departments split their time between implementing new and maintaining existing technology. On the software side, most of the focus is on applications supporting business processes, and at large legacy enterprises, the significant portion of applications are out of date (legacy), but still running to support business activities. Thus, businesses wonder why the ‘Sun never set’, what are the major risks of legacy applications in the context of enterprise architecture? How does an architect substantiate an updated solution to application modernization?   

1.    The Main Risks of Legacy Applications 

By and large, the risk of any legacy application is that it loses its fit with the evolving business architecture; infrastructure or staff skill set and realigning it becomes overly costly. While no one wants to spend money and time rebuilding something for the moment, as it is still fulfilling requirements, there is a point at which the present value of the cost of continued operation exceeds the present value of the cost of replacement.

1) Supportability: One or multiple components. Hardware, OS, Language, or something else is unsupported or becoming nonviable due to vendor, resource, or financial reasons, also lack of trained people to support them.

2). Flexibility: Due to the architecture (monolithic architecture, hard-coded rules), the application is unable to evolve at the speed of business or restricting other systems from evolving. Inability to continue modification due to lack of build facilities,  inability to integrate with current architectural direction. 

3). Scalability: Application is unable to scale to meet new business needs 

4). Security: The old application isn't secure in new context. Poor security infrastructure around product 

5). Regulation: The legacy application is non compliant to new regulations. 

      6) Cost: Steady-state operations costs increase

     7)  Risk: the existing capability is becoming more and more limited by the day, and that the risk level    
          associated with it is increasing 

2. EA as Tool in Assessing Application Capabilities 

EA is, as much as anything, about understanding ALL of the factors that figure into making the analysis, quantifying them and developing an action plan to retire applications and technologies that are exacting opportunity costs instead of adding value to the organization.

The analysis process/activity to assessment helps within a specific context (company), with identifying risks, determine fault and cause, defining (counter) measures and implementing those solutions. It’s a risk or a set of risks which might lead you to classifying software/ applications as legacy. And it is this set of risks, in most instances (setting political aspects aside), which give you the basis for the business case. Which might lead to buying, reusing of making new software (or parts of it) to replace the legacy. 

Be objective in your assessment and may the best solution win. The questions that Enterprise Architects can framed would include:
1) Capabilities: To what extent can the existing capability support the future demands of our business strategy and business goals
2) Options: To what other options exist to effectively support current and future capability needs which are currently supported by capabilities which have (in all likelihood) high cost, slow response, and low flexibility - but with the prime advantage of being highly customized to current (but not necessarily future) business processes.

3) Risks: How that risk rates against other business risks and what level of risk can they "live with"- the question to the business executives
4) Benefits: What additional business benefits might arise from alternative capability options

5) Gaps: What are the key requirements and how much is the gap between the legacy application capabilities and projected needs. Ensure that the projections are as long term as possible because doing otherwise may cause the legacy to become even more entrenched and harder to replace later.

6) Be Objective: What’s alternative analysis- evaluating each alternative for costs, benefits, impacts (changes to other systems and processes), risks (monetary, operational, reputable, regulatory etc.), and side effects (training of users and support staff). Be careful to be objective.

3. What are Pitfalls 

One must avoid the temptation of "Here is the answer. Now tell me the problems?". To make any of these or multiple of these as a reason to replace the legacy would logically require an assessment of the current and future needs of the organization and the impact/ constraint the legacy system is having on those needs. Therefore, EA could be the right tool to fit in the purpose if avoiding such “EA is big answer to look for the problems” mentality.  

The greatest problem with legacy system replacement is seeing it as legacy system replacement. Often the business processes that have evolved around the legacy applications are fossilized and constrained by the idiosyncrasies of the application. So the approach can be taken is to tackle the business process re-engineering first, then work out what the new system needs to be. In some cases, the replacement is often not what the business wants or needs and significant benefits in terms of simpler and more effective business process are not delivered. Having a business led (not technology led) program is more complex, but much more likely to succeed and deliver genuine business benefit.

Organization and Application Lifecycle Management is part of Architecture activities, EA is rather a process, the process of creating socio-technical systems. EA is a way of achieving effective and sustainable organizations and business ecosystem. From application life cycle management to change (people/culture) management, EA needs to bring value and objectivity.   

Posted in: EA,IT Transformation