Application rationalization is the process of cataloging and eliminating duplicate software applications used across an organization. This allows IT departments to improve efficency, simplify portfolio complexity, and lower the total cost of ownership (TCO) for their application portfolio.
Application rationalization (app rat) initiatives are most successful when the application portfolio is clearly aligned to business outcomes. In order to get the most benefit from your app rat initiative, you need to identify a framework for ensuring business alignment and a process that is defensible and repeatable.
With the right framework in place, organizations can run application rationalization initiatives without interference from organizational politics and unnecessary turf wars. Fact-based conversations will replace subjective arguments, and your app rat initiatives will return better results—enabling more control over app sprawl and freeing up funds for innovation.
In this article, we will look at how to build a robust framework for a successful IT app rat initiative.
Despite company’s best efforts to control spending and secure the network, IT organizations are fighting an uphill battle.
Disengaged business partners can torpedo application rationalization initiatives. The key to engagement is a fact-based dialogue about the total cost of ownership (TCO) of your applications. However, this is a difficult number to build consensus around. If your assumptions are too simplistic, the business will dismiss them. If too complicated, the accuracy of the numbers is hindered by the effort of pulling them together. Striking the right balance between the two drives engagement.
Business stakeholders and Infrastructure and Operations (I&O) managers likely already know there are issues in key areas of their portfolio because older applications running on legacy systems are taxing innovation by hoarding dev resources. Start there. An app TCO initiative does not need to be exhaustive to drive engagement, but it must address areas that are already flagged as an issue.
Bloated application portfolios hide redundancy and lock innovation spend to legacy apps. Simply reducing the number of apps is a win—usage and investment outliers are easier to spot in a reduced pool of apps. With a smaller portfolio, there is also more scrutiny on assessing the business value of new applications. The existence of an application rationalization process drives better new app evaluations.
Increasing a SaaS (Software as a Service) footprint at the expense of on-premises perpetual licenses is a sound IT strategy. But moving all apps from one platform to another, without evaluating business value, is a wasted opportunity. With fewer applications to move, you’ll cut the technical workload and deliver a business-value-focused SaaS portfolio.
Buying something new is often the easiest path—but that goes against the spirit of application rationalization initiatives. Organizations with successful app rat initiatives maximize existing apps for business value before adding something new to their portfolio.
Application names and owners are the baselines for the portfolio assessment. An application rationalization initiative is often driven by a specific goal (like removing ‘retired’ apps from the portfolio within two quarters) that focuses on a small part of the total portfolio. However, a baseline assessment of the entire portfolio may find mis-identified apps (wrong owner, incorrect labeling of retired vs active, etc.) important to the current initiative. This also establishes necessary groundwork for follow-on broader app rat initiatives.
Business stakeholders engage early in app rat initiatives by assisting in the portfolio analysis. An application list and an app-to-server mapping file are sometimes the only two pieces of data given to IT Finance. This data needs context and validation. If the source data is wrong, the recommendations coming out of an application rationalization initiative are useless. A successful application rationalization initiative is driven by accurate validated data. Finance doesn’t own the data—I&O does and must validate application list data with operational data.
A portfolio assessment identifies applications running on older legacy systems that require specialized infrastructure. This ongoing maintenance ties up development spend that could drive innovation.
An application portfolio assessment is complete when:
Successful app rat analysis distinguishes between an application’s name and its business value. For example, Trello is a SaaS-based project management software. An app rat initiative must define its business value (“With Trello, we project manage contractors that deliver 30% savings on labor vs a full-time employee.”). This value assessment makes it easier to evaluate redundant capabilities in similar applications (“We have Trello, but we also have surpluses licenses for Wrike and Nutcache. Let’s agree on one standard and retire the others.”).
Redundant capabilities with a sound business case are not candidates for rationalization. For example, uptime availability affects organizations with a workforce spanning multiple time zones. Evening hours in North America are early morning hours in Australia; late afternoon in Japan is night time in France. If all app servers for an organization are rationalized to one location, I&O has a maintenance window falling into at least one region’s core business hours. In this case, there may be a business need for redundant capabilities.
Business value is defined when applications are:
Application TCO must determine the fully-loaded cost of supporting and delivering apps. This includes general ledger (GL) entries for both license costs and indirect costs for infrastructure and operations. There are always defensibility questions with app TCO analysis: how accurate are these numbers? A successful app rat initiative will have app TCO analysis as an ongoing activity. With Apptio Cost Transparency, our clients bring in monthly operational and financial data that IT finance can unpack and analyze with self-serve analytics.
Application TCO needs to review costs, identify the drivers of those costs, and analyze project spend associated to each application.
Application TCO is defensible when:
Aligning business value to applications creates organizational resistance. Breaking down application costs by business function identifies investments in run-the-business (RTB) versus grow-the-business (GTB) spend. But this can set up an ‘us versus them’ scenario where GTB is seen as the only spend that matters. Delivering keep-the-lights-on (KTLO) capabilities is a key part of IT’s remit and there is resistance to change if KTLO is dismissed as merely a throttle on innovation. Organizations should prepare for this by aligning IT spend to corporate goals and consulting for buy-in with a broad group of stakeholders during the app rat process.
A call to action from an application rationalization initiative often drives additional expenditure. Retraining staff on a rationalized application impacts adoption and the cost of implementation. The resources to retrain need to be identified, scheduled, and added to the consideration of business value (ex. is retraining a justifiable use of our training resources?).
Business value is aligned to business function when:
A slice of the application portfolio is identified as adding quantifiable business value. The follow-up question: how well is it delivering this business value? Successful app rat initiatives address this question.
The effectiveness of application business value is determined by how it supports existing processes and functionality. An organization selects an application that supports an existing process or leverages an application to redefine the process (ex. sales stages with Salesforce SalesCloud), but the key question is how well an application automates a business process. Automation is the key functional quality for assessing an application.
An application rationalization initiative allows employees to weigh in on their own experience with an application. If an application is unwieldy and provides poor user experience, it impacts the attitude and engagement with the business.
Technical limitations need to be assessed against IT’s goals. Stakeholders may wish to expand the cloud footprint for IaaS (Infrastructure as a Service) and SaaS, but existing solutions may only be available on-prem with legacy infrastructure support. If a SaaS offering is not available, the choice is stark—you are left where you were. The more difficult choice is when there are options in the cloud that need further analysis. Can you make an assumption that the app will be secure in the cloud? Maybe. Are you so tightly wed to the IT strategy on cloud that you will heavily invest in modernization in order to adhere to it? Possibly.
Altering application portfolios drives changes in hardware. A push to cloud offerings allows on-premises servers and storage to be repurposed. However, pushing infrastructure to the cloud without repurposing the resulting excess on-premises capacity is a waste of effort and expense.
Technical and functional quality of applications is defined when:
An application rationalization initiative needs metrics to communicate success. Over time, applications with low business-value will be purged from the portfolio—and new applications with low business value will not get through the procurement process.
IT communicates the success of app rat initiatives with:
Application rationalization initiatives identify existing application spend and provide analysis on how to use that spend more effectively. IT exists to serve the business and an application portfolio needs to be reviewed with that perspective. Value, functional and technical quality, redundancy in capabilities: these are assessments rooted in business, not technology. Successful app rat initiatives ingest monthly financial and operational data, provide self-serve analytics on app TCO, and drive more effective business value orientated application spend.
The Definitive Framework for Application Rationalization provides prescriptive guidance on identifying and removing duplicate applications. Use a 6-phase approach to cut apps and deploy savings in more rewarding areas. Learn how to execute each of the following phases: