Application Rationalization & Modernization: Why is Sun Never Set?

At a time when successful organizations are characterized by how “dynamic” and “agile” they are, applications have become the integral component of an enterprise’s flexibility.

Most information technology (IT) departments split their time between implementing new and maintaining existing technology. On the software side, most of the focus are on applications supporting business processes. A new application is usually intended to replace an outdated (legacy) application. However, both will typically run in production until the new application is proven, after which the legacy application is obsolesced (no longer used) and sunset (no longer maintained, usually removed). At least, in theory, that is how it is all supposed to work.  However, in practice, legacy applications are rarely sunset. Why?

1. Why Legacy Applications never Retire?

There're quite many reasons for applications to become legacy, but never retire, such as:

1) It's not so fitting in the purpose of the organization now, or not so prioritized in current market condition

2) Technology out of date, but some users continue using some of the functionality provided by the legacy application to support daily business activities.

3) Organizations have a "set it and forget it" mentality. One of the challenges of application modernization is the (perceived) embarrassment factor;

4) For some legacy (applications reach their life cycle), it could be too costly to modernize, especially for some struggling organizations and industries.

5) Some of these older applications often require other legacy applications that are used for management and maintenance purposes.

6) Any application that includes information that the business needs and uses is legacy and necessary to be continued and/or transformed, which requires another IT project to make that happen. More restrict, any application that goes into production...is now legacy

7) Organizations continue to add new applications, and application vendors continue to upgrade to keep in step with the newest operating systems, IT departments faced with serious application sprawl and a growing backlog of out-of-date and often unsupported applications. Too many applications overlap functionality, too old applications;

 8) A lot of new systems are being built on top of legacy systems. This dependency makes it almost impossible to retire old systems. And there are a lot of business processes and services that would have been designed around the legacy systems over the years...trying to change those would have some impact on the operations.

Therefore, although legacy applications are used less and less since they continue to support some business needs, they are never sunset.  This is a huge headache for support teams trying to reduce the amount of tools and the number of skills needed to maintain their portfolios. The Systems Development Life Cycle (SDLC) shows how IT should be caring for and nurturing applications from cradle to grave. Unfortunately, people tend to keep systems on life support longer than necessary to squeeze the last little bit of productivity out of it...while wasting boatloads of cash in the process

In large corporations, business executives fail to see technology costs clearly by each of the business functions. One of the problems that some CIOs will face in convincing business application owners to move to a newer application is cost. Faced with restrictive budgets and perceived risks of unplanned downtime, the application owners can be reluctant to commit to modernizing or consolidating their applications. Unfortunately, the longer people wait to maintain or modernize their apps, the larger the problems and costs faced when they are actually forced to make these moves.

2. IT Application Rationalization Driven by Business Initiatives

Application rationalization effort is a consequence of a more fundamental issue - Business is not understanding IT and irrational proliferation of technology, Business is not making decisions based on the cost of doing business. What to do about a legacy beast, that continues consume some resources while still satisfying needs, is not a simple evaluation/decision; Even "application modernization" seems to remain an elusive, fuzzy concept which can mean a host of things. Therefore, the way to do it is through some careful, painstaking business analysis (involving the business processes, costs, system lifecycles, benchmarking, impact assessments etc), the end to end enterprise architecture that will look at the business, application, technology, data and information architectures. Not easy and it comes at a price.

In many cases application rationalization doesn't work, although many organizations run rationalization projects and many suppliers promote their track record,  many don't actually rationalize their applications. Instead, they consolidate contracts, licenses, and infrastructure or re-organize resources. In one extreme case,  an organization claimed great success for their rationalization program but actually they had simply changed how they counted their apps!

This is a painstaking process that requires detailed Business Analysis to find out the ground truth. You then have to model the same processes with the existing technology and applications to identify the functions that each application performs. From there you have a fighting chance to rationalize but there are many pitfalls and Bear Traps ahead so don't think it can be done in a short period. 

Should we all give up? No. Application architecture rationalization makes good sense and is informed by understanding the current portfolio. Also, remember that your current management and governance practices generated your irrational applications and may need to be changed to avoid creating more of them.

But how to manage Application Rationalization (AR) more effectively?

• To address a business pain point. Rationalization efforts must be incorporated in a business-led effort to address a business pain point. The result of this was convoluted business processes to mapping to this myriad of systems. The business wanted/needed a change and drove a project to develop more coherent business processes. These processes were deployed over a layer that abstracts the systems. In this process, components were pulled from various applications to provide needed functionality for business process activities. As a byproduct, a few (only a few) applications were retired. The bottom line, application rationalization projects rarely if ever stand on their own. They don't get out of the gate.

• Successful application rationalization, like most things in IT, must be a business led initiative. If done to improve operational effectiveness, reduce costs or avoid business risk,  the buy-in exists throughout the organization shall perform the required work. Otherwise, you have IT trying to push a rope uphill.

• An AR project generally goes through 3 phases.
  1) Phase 1/”Woo,  a lot of applications there”: In this phase,  IT and or Business are confronted with the limits of the complexity of their application portfolio: there are a lot of applications, applications provide overlapping functionalities, there is no 'official' list of the corporate applications, no clear ownership of the applications

2)Phase 2/ "You see we have reduced our portfolio by 20%". After making a list of all application, a number of applications are shut down. However, if you look at the wood, you will find that these initial successes are applications that people forgot to shut down in previous years, or never got done to convince the last 'stubborn' user, or an application was renamed to become a module of a larger application. Although the application list got shorter, the actual business benefits or cost reduction generated by this phase is close to zero. 

   3) Phase 3: in this phase, IT and Business start to realize that some of the functional overlaps of application are not exactly overlapping and that is never possible to simply shut down an app and migrate users to the other application. In reality, the application portfolio can only be simplified with significant upfront investment. And worst of all, there is rarely a business case to do so. On top of that, the organization now realizes that you cannot just rationalize the application portfolio without also looking at your technology, skills, and sourcing portfolio. 

• The reduction of the complexity of the application portfolio. Complexity is #of apps, #of vendors, supporting cost, development platforms.  A better approach to tackling the application portfolio complexity (or business IT alignment in general) is a combination IT organizational and IT management process changes. Including implementation of concepts like Business Architecture, the creation of an EA function, EA board, Program/Project portfolio management, IT service portfolio management. 

Application Rationalization can’t be successful unless when the short-term objectives and quick win nature of AR were transformed into the long-term strategic decision for the IT organization, supported with activities to increase the maturity of the IT governance process and skills of the organization as a whole.

3. Application Portfolio/Life Cycle Management

From Application consolidation, rationalization/ modernization, integration, optimization to now, cloudification, application lifecycle management is the critical part of IT strategy, which is an integral part of business strategy, and linked directly to business goals. The strategic corporate benefits of application modernization & overall ALCM are effectiveness, efficiency, differentiation, and agility.

Take more of an application portfolio & lifecycle management approach and trying to weave a few different practices from different areas together, including application rationalization. It will take more in-depth interviews and modeling to screen out false positives After recognizing and prioritizing the projects need be modernized, with the long-term perspective from the executive sponsorship, how to transform it successfully via the strategic/technologic partners, change management, culture, etc.

1) Application rationalization has been a holy grail in enterprise architecture. Big EA model and inventory effort are important for application portfolio management. Rationalization of that portfolio becomes possible only as/after there is a well-described inventory. It's tough and expensive to build that inventory from scratch,  so begin with a strong, forward-looking process for capturing change in applications throughout the business; capture a bunch of facts and metrics for each application (business, tech, risk factors), but by far the most important, and the hardest to get, is the financials.. If you've gathered some convincing financial data and can demonstrate cost savings or increased efficiency or decreased complexity or whatever, EA will be well received. 

2) Collect more Data and establish an IT baseline: don't even start on a rationalization project until you've got the right processes in place for allocating costs to applications, and some historical data that people actually believe.  Input comes from systems management software, financial reporting, and instrumentation of apps, platforms, and servers. Reporting/analytics about what do you have, who uses it and how much, who pays for it, how much does it cost, etc.  Two other parts are a decision-making framework (hopefully will prevent new redundancies or budget sinkholes) and a reporting/analysis suite (using existing tools we have in-house!). 

3) Make a lean and mean approach where you assess all applications on maximum 10 criteria: business value, training cost, support cost (business & IT), technological alignment, availability of skills, vendor viability, ... Based on this first analysis, make some quick wins and use this to support other initiatives focusing more on governance and long-term benefits. For the actual process of rationalization, share some best practices about how to rate/rank/optimize.

4) IT orchestrates the transformation: the two most important components are an agreed upon cross mapping of data, processes, rules & operational procedures between all current applications (this is a type of virtual multi-dimensional Cartesian product), and a means of automation. It takes a lot of patience, sense of humor and deep pockets. To move forward with portfolio rationalization and modernization, some CIOs are actually funding a portion of these projects in order to provide the incentive to app owners to make this commitment. It's kind of a win-win, as the app owner has less of a cost burden than if they did it on their own, and the CIO has a newer, more agile application portfolio that is most likely going to be easier to manage, reducing their costs in the long run

In summary:  At a time when successful organizations are characterized by how “dynamic” and “agile” they are, applications have become the integral component of an enterprise’s flexibility. Also, IT is no longer for build-to-last, but for build-to-change, focus on the value chain of your business and only deal with the key functions that your business has effective distinctive competitiveness to overcome the competition.

Posted in: CIO Debate,IT Performance Management