Application Portfolio Rationalization – Data Analysis Phase

We explored business drivers and high-level approaches for Application Portfolio Rationalization (APR) initiatives in my last blog. While there are many frameworks available for APR analysis, the project’s success depends in equal measure on the completeness, quality and accuracy of the underlying data used.

Most enterprises typically have a large set of products, applications and services managed by their IT division. APR exercises start with a discovery phase to scope and define the enterprise IT landscape, with emphasis on collecting data about the mix of products, applications and services. In mature organizations, this IT assets data could be available in a ITIL standard CMDB (Configuration Management Database) or a tool such as LeanIX. In less mature organizations it may simply be maintained in Excel sheets or documents. In the worst-case scenario the APR team may have to start from scratch, gathering this data from various application owners and business functions via interviews, documentation review, demos and walk-through sessions.  

Let’s explore in more detail the type of data that is usually gathered in such discovery workshops, before the APR analysis begins.

In God we trust; all others must bring data!

The IT assets data for APR exercises can be broadly classified along 4 dimensions:

• Business information
• Technical information
• Financial information
• Domain and Regulatory information

The emphasis is usually on numeric data gathering wherever possible, in order to ensure that the APR analysis is very objective and can provide a mathematical model for the portfolio management, vis-à-vis just a subjective set of inferences and recommendations.

Now, let’s look at each of these 4 dimensions in some detail.

1.     Business Information

This includes basic business information about the application or IT asset – primary business function, business unit within the organization, business owners, business process and sub-processes served by this application, application criticality and business impact. It also includes data such as application type (packaged, COTS, custom-built, SaaS), application vendor, application maturity, implementation date, last upgrade and application stage (evolving, stable, sunset).

2.     Technical Information

Technical information captures data regarding the application technology stack – development languages, databases, middleware, third-party components & libraries, underlying OS and deployment hardware or cloud details. It also includes data about the external integrations, APIs supported, number of interfaces, number of active users and total number of total users. Additionally, it may capture nuances of the application such as functional complexity, code complexity, documentation levels and code coverage. All these details help construct a model for the technical fitment of the application.

3.     Financial Information

The emphasis is on collecting all relevant cost heads – number of FTE resources allocated and their cost, number of contract resources allocated and their cost. It also includes resource spread across various functions such as architecture, design, development, maintenance and support. Additionally, the application may use third-party components and libraries, so their cost needs to be factored in as well. Similarly, the deployment footprint and ongoing usage cost of underlying infrastructure has to be apportioned. Anything that adds up to the TCO (Total Cost of Ownership) of the application needs to be captured for accurate financial modelling and analysis.

4.     Domain and Regulatory Information

Depending on the industry and the business processes being served by the application, there may be a number of domain-specific data elements that need to be captured for analysis. For example, the application’s handling of sensitive data, adherence to industry compliance standards such as PII, HIPAA, SOX, PHI, etc. It also includes any information about any regulatory requirements and associated reporting that the application serves in the organization’s business.

In summary – data completeness and accuracy are an important aspect of the initial discovery phase for any APR exercise. In large enterprises the IT asset portfolio may run into thousands of products, applications and services. An incremental, sprint-based approach to gathering and analyzing this data can be adopted to deal with the complexity of such an APR exercise - while continuously delivering results to the APR initiative sponsors and executive leadership. Most APR frameworks support such an iterative approach to delivering the complete analysis. We will explore some such frameworks in an upcoming blog.