A Pragmatic Approach to Simplifying the IT Tools Landscape Abstract

A high level of complexity in the IT landscape and a corresponding increase in the cost of ownership of IT tools presents a significant

challenge to organizations. It is therefore essential to periodically simplify the IT tools environment by implementing a rationalization

exercise. The resultant benefits include a reduction in costs and an alignment with the overall business and IT strategy. While many consider

IT tools rationalization as an integral part of a business application rationalization exercise, there are significant differences which indicate

the need for a completely new approach.

This paper discusses the strategies and objectives of an IT tools rationalization exercise, its execution methodology and framework, key

execution challenges, and the benefits derived. A real life case study at a large bank based in the Asia Pacific (APAC) region is used to describe

a pragmatic and holistic approach to IT tools rationalization that resulted in a substantial return on investment (ROI).

Introduction

The increasing cost of ownership and high level of complexity in the landscape of IT tools has made simplification a priority for many Chief

Information Officers (CIOs). While simplification of business applications has been an area of focus in the past, rationalization of IT tools has

often been overlooked.

An IT tool is a piece of software that supports or delivers specific IT services to the organization. There are similarities between applications

and IT tools and some businesses consider Tools Portfolio Rationalization (TPR) as an integral part of Application Portfolio Rationalization

(APR). However, there are also several differences that require a completely new approach to TPR.

Identification of IT Tools

Many organizations do not have well-established criteria to define or identify IT tools and segregate them from applications. An application

is usually understood to be a large or complex piece of software that is useful in running routine business activities. In comparison, an IT tool

helps support or deliver specific IT services to the organization.

For example, CRM and ERP are classified as applications, whereas IBM IDCAMS is an access method services utility used to store and manage

files on a mainframe and is classified as an IT tool. Similarly, SAP Crystal Reports is an IT tool used for reporting. This classification may differ

from organization to organization, depending on how the software is utilized within the organization. However, it can be difficult to classify

software based on their use: some IT tools are quite versatile and powerful, while some applications are comparatively simple and have

limited versatility. Nevertheless, it is important to begin a rationalization exercise by clearly categorizing IT tools and applications to prevent

any ambiguity in the scope.

The Need for Rationalization of IT Tools

In most enterprises, a combination of organic and inorganic growth has given rise to a heterogeneous IT environment. Weak governance

around IT tools lifecycle management also adds to the challenges of managing IT tools efficiently.

An example is a large APAC bank that had more than 2,000 IT tools catalogued, and more that were not documented but in use across

isolated sections of the bank.

Point of View

2

Such a fragmented IT tools landscape entails various challenges:

n Proliferation of legacy tools

n Significant overlap or duplication in the capability and functionality of tools

n Underutilization of tools

n A lack of tools that meet the functional and technical requirements of the business

n Tools that do not comply with the architecture guidelines and IT strategy

All of this leads to poor governance, along with a high cost of ownership of the tools. In addition, it impedes the achievement of business

objectives, including functional upgrades, modernization, scalability, and reduced turnaround time for project development. These

challenges necessitate the rationalization of IT tools.

Formulation of an IT Tools Rationalization Strategy

Before embarking on a TPR exercise, its objective, scope, and vision should be well defined.

Objectives

Some key objectives of a TPR exercise are:

n Reduce complexity in the IT operating environment in order to attain a state of ‘useful complexity’, which results in substantial benefits

but leaves room for improvement in the future. Reducing complexity beyond this level is costly and may not be advisable.

n Reduce the effort involved in delivering IT projects by standardizing tools

n Improve collaboration and IT capabilities by reducing functional redundancy and overlaps in capability between multiple tools

n Identify the ‘white spaces’, that is, areas where a new IT tool can be brought in to support functions or capabilities that are not currently

supported

Scope

The scope of a TPR exercise should be clearly defined. We believe that the best approach is a phased one and the tools to be covered in each

of the phases should be identified. To continue our example of the bank, the rationalization project was undertaken in phases, with the first

phase covering only software related IT tools.

Vision

The aim of a TPR exercise should be to retain IT tools with enterprise capability. These tools should have enterprise licenses, enterprise

support, and enterprise monitoring features. A fragmented and departmental implementation of tools should be discouraged, with limited

exceptions to meet governance requirements.

It is therefore essential to map enterprise capabilities with the IT tools to ensure that the right tool supports each capability. The Technology

Reference Architecture and a capability map of the organization plays an important role here. If this is not documented, it is advisable to

create it or map the current and desired structure of tools to industry reference architecture. An example of Technology Reference

Architecture with tools mapped to each capability is illustrated in Figure 1.

3

Recommended TPR Methodology

A high level approach to a TPR exercise is illustrated in Figure 2. The approach can be customized to specific project requirements.

Phase 1: Initiate

In the first phase, the scope of the rationalization exercise is defined by identifying the list and categories of tools. The attributes for which

data needs to be gathered are determined, and the parameters for analysis are identified.

Categorization of IT Tools

Accurate categorization of tools affects subsequent phases and is essential to the success of any TPR exercise. Accurate categorization helps

determine the correct set of attributes for collection of data in the ‘Gather’ phase. In the ‘Analyze’ phase, categorization enables effective

analysis. For example, tools in the security category may need analysis on aspects such as authorization and authentication. The

‘Recommend’ phase should include category-wise as well as individual recommendations for IT tools.

Figure 2: Recommended TPR Methodology

ToolTool

Tool

ToolTool

Old Portfolio Initiate

New Portfolio

Tool

Tool

Tool

Tool

Tool

ToolTool

Tool

Gather

AnalyzeRecommend

• Finalize IT tools list • Manage stakeholder

communication• Define tool attributes for data

collection• Define tool assessment dimensions

Gather information on tool attributes• Basic information• Business value• Technical information• Maintenance and support information• Usage data• Cost aspects• Tool capability

• Tools recommendation:• Modernize• Standardize• Retire

• Business case for implementing recommendation

• Roadmap

Assess tools on these dimensions:• Tool usage• Business value• Technical adequacy• Cost• Technical risks

Figure 1: Sample Technology Reference Architecture

1. SALES

1. 1 SALES MANAGEMENT

1.1.1 SALES PLANNING

1.1.3 SALES PERFORMANCE MANAGEMENT

1.1.4 INCENTIVE MANAGEMENT

1.1.2 SALES EXECUTION

1.1.5 TIMESHARE SALESMANAGEMENT

1.2.2 ACCOUNT MANAGEMENT1.2.1 OPPORTUNITY MANAGEMENT

1. 2 SALES FORCE MANAGEMENT

TOOL A

TOOL C TOOL B

TOOL C TOOL B TOOL A

TOOL C

TOOL A

TOOL B

TOOL B

4

An example of categorization and sub-categorization of IT tools is shown in Figure 3.

Attributes of IT Tools

To continue with our example, the APAC bank identified 40 attributes divided into seven categories for collecting data related to a tool. These

are described in Table 1.

Dimensions for Assessment of Tools

Once data based on attributes of tools has been collected, it is analyzed based on certain factors or dimensions. The dimensions determined

used for the rationalization exercise at the APAC bank are shown in Figure 4.

Figure 3: Sample Categorization and Sub-Categorization of IT Tools

TOOLS

SOFTWARE HARDWARE NETWORK

BI MIDDLEWARE IT MANAGEMENT CRM

ANALYTICS REPORTING WAREHOUSING WEB CONTENT MANAGEMENT

DOCUMENT MANAGEMENT

LEV

EL 2

LEV

EL 1

LEV

EL 0

Attribute Description

Basic information A description of the tool, current version installed, tool category (for example: security, data warehouse, reporting)

Business value Information on the business value of the tool based on its use for critical applications. Any vulnerability to the business due to continued usage of the tool is also identified

Technology Technical information on the IT tool including compliance with architecture guidelines of the organization or length of time for which the tool has been used

Maintenance and support Information on the tool downtime and quality of support; for example, the availability of trained resources to support the tool

Tool usage Information on the number of users, frequency of use, or capacity of the tool for increased load in the future

Cost Various cost aspects such as license cost, license model, support cost, or operational expenses

Capability Information on tool capability, including capability overlap with similar tools in the enterprise, underutilization, and existing capability gaps

Table 1: Attributes of IT Tools

5

To assess a tool based on each dimension, data related to multiple attributes may be required for analysis. For example, to assess the

technical risk of a tool, data related to several categories of attributes, such as ‘technology’, ‘maintenance and support’, and ‘tool usage’, may

be analyzed.

Phase 2: Gather

Data on tool attributes is collected in this phase. Some additional information that should be collected is:

n Mapping of existing processes to tools to study the impact of changes in tools on business processes

n Application to tool mapping to study the impact of tools rationalization on applications

n A list of all major projects in progress since applications or processes used in these projects will have an impact on the tools landscape

Some key challenges during this phase are listed in Table 2.

Phase 3: Analyze

The data gathered in the previous phase is analyzed to identify any areas that present difficulties or opportunities for improvement. In our

example, the bank used a scoring methodology to grade each tool across the five assessment dimensions. Based on this, the rationalization

strategy for each tool was determined. For example, a tool with a low ‘business value’ and low ‘usage’ score but a high ‘cost’ score may be

replaced with a low cost, low risk product.

Figure 4: Dimensions for Assessment of Tools

USAGE BUSINESS VALUETECHNICAL ADEQUACY

COST TECHNICAL RISK

Challenge Possible Mitigation

Timely collection of attribute data

Data collection can be prioritized based on the complexity and the number of tools in each category. For example, security tools may have priority over data warehousing tools.

Incorrect mapping of IT tools

A list of tools is created and mapped to the Technology Reference Architecture before the gather phase.

Identification of the owner of each tool

The right tool owners should be identified and their commitment obtained at the start of the project. However, the tool owner may not have information on all tool attributes and interaction with multiple stakeholders may be required to collect data.

Poor quality of data collected

All stakeholders should commit to providing and reviewing information. Enterprise architects may be assigned to assess the quality of data collected, and a periodic review of the data collection exercise should be performed.

Availability of data on tool prices

Once all other data has been analyzed, pricing data should be sought for selected tools to refine the analysis.

Table 2: Challenges during the 'Gather' Phase

6

Some points to be considered during data analysis are:

n In situations where attribute data is not available, a qualitative rather than quantitative analysis should be performed.

n Technical dependency on other tools, applications, infrastructure, and processes should be analyzed before making any

recommendation.

n Analyst reports are usually available for the analysis of applications, but such analysis is rarely available for tools. Therefore, additional

information may be obtained by browsing technical blogs or websites to compare the features and capabilities of various tools.

Phase 4: Recommend

In the final phase, a detailed report with recommendations is prepared and shared with relevant

stakeholders. This includes a roadmap for rationalization in order to deliver the desired ROI and

align with the overall business and IT objectives. Opportunities for quick rationalization are also

identified during the assessment.

While most organizations have clear processes defined for implementing and operating new

tools, they rarely have processes or strategies for retirement of tools. CIOs can apply any of

multiple strategies to rationalize tools, including sustaining, extending, remediating, migrating

to new platforms, replacing, consolidating, or retiring. Identifying the correct strategy, aligned

with the standards and guidelines of the organization, for each set of tools is vital to the success

of a TPR exercise.

The other significant outcomes of a TPR exercise are:

n Baseline data on the current state of tools, including financial, commercial, technical, and functional attributes. This information will assist

enterprise architecture teams in managing the tools portfolio in the future.

n A strategy for the creation of a single integrated database or source for information on tools. For example, technical data is generally

available with the engineering team, and pricing data with the finance team. A single and integrated source will enable efficient

management of the tools portfolio.

n A tools portfolio governance model defining the roles and responsibilities of various associates in governing a tool throughout its

lifecycle. This will help contain proliferation and manage the portfolio effectively.

n A list of unused tools and their decommissioning strategy. Retiring such tools, after adequate analysis, can be an easy quick win during

the exercise. It yields cost savings and aids rationalization of the portfolio.

Conclusion

The IT tools environment needs to be simplified on a periodic basis by implementing rationalization projects. This is expected to yield several

benefits including a leaner and standardized tools portfolio, alignment with the business and IT strategy, and a reduced cost of ownership.

The cost of retiring tools, lack of immediate financial benefits, organizational resistance, and a lack of qualified developers for migration to

new tools are some key barriers to simplification. The pragmatic approach recommended in this paper will mitigate these barriers and

thereby assist CIOs in their simplification efforts.

To continue with our example, the APAC bank identified over 50 initial rationalization opportunities involving over 200 IT tools. The top five rationalization opportunities provided an opportunity of about $8.5 million in potential savings to the bank over five years, on an initial investment of $1.9million.

7

About the Authors

Sujatha Gopal

Sujatha is global head of Innovation and Service Offerings Management in the Business and IT Architecture practice at Tata Consultancy

Services (TCS). She has over 16 years of IT experience in multiple roles including those of an IT strategy consultant, enterprise architect,

project manager, and technical lead. She has a wide range of experience in enterprise architecture, service oriented architecture, application

portfolio rationalization, solution architecture, and IT strategy. She has published several articles on these topics. She is also a member of

various enterprise architecture forums.

Debabrata Pruseth

Debabrata is an enterprise architect consultant in the Business and IT Architecture practice at TCS. He has eight years of experience in

enterprise architecture, IT strategy, and application portfolio rationalization. An avid writer, he has published papers in numerous journals

and conferences such as the Cutter IT Journal and Project Management Institute (PMI) National Conference. He has an MBA in Finance and

Systems from Xavier Institute of Management, Bhubaneswar (XIMB) and a Bachelor’s in Technology from the National Institute of Technology

(NIT) Rourkela. Debabrata is a Six Sigma Black Belt and is TOGAF 9 certified.

Pooja Subramanian

Pooja is a business analyst in the Banking and Financial Services (BFS) domain within the Global Consulting Practice (GCP) at TCS. She has

seven years of experience in roles such as delivery lead, functional consultant, and business analyst. She has also worked extensively in

presales and business development roles. She has an MBA in Finance and Operations from IIM Lucknow, India.

TCS

Des

ign

Serv

ices

M

03

15

II

I

About Tata Consultancy Services Ltd (TCS)Tata Consultancy Services is an IT services, consulting and business solutions organization that delivers real results to global business, ensuring a level of certainty no other firm can match.TCS offers a consulting-led, integrated portfolio of IT and IT-enabled infrastructure, engineering

TMand assurance services. This is delivered through its unique Global Network Delivery Model , recognized as the benchmark of excellence in software development. A part of the Tata Group, India’s largest industrial conglomerate, TCS has a global footprint and is listed on the National Stock Exchange and Bombay Stock Exchange in India.

For more information, visit us at www.tcs.com

IT ServicesBusiness SolutionsConsulting

All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is correct at the time of publishing. No material from here may be copied, modified, reproduced, republished, uploaded, transmitted, posted or distributed in any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and

other applicable laws, and could result in criminal or civil penalties. Copyright © 2015 Tata Consultancy Services Limited

ContactFor more information about TCS’ Global Consulting Practice visit: http://www.tcs.com/offerings/consulting/Pages/default.aspx

Email: global.consulting@tcs.com

About TCS' Global Consulting Practice

TCS’ Global Consulting Practice (GCP) is a key component in how TCS delivers additional value to clients. Using our collective industry insight, technology expertise, and consulting know-how, we partner with enterprises worldwide to deliver integrated end-to-end IT enabled business transformation services.

By tapping our worldwide pool of resources – onsite, offshore, and near-shore – our high caliber consultants leverage solution accelerators and practice capabilities, balanced with our knowledge of local market demands, to enable enterprises to effectively meet their business goals.

GCP spearheads TCS' consulting capacity with consultants located in North America, UK, Europe, Asia Pacific, India, Ibero-America, and Australia.