How to do software rationalization right

Appendix 2: Typical problems caused by application sprawl

1. Unnecessary software costs for underused applications. This takes the form of annual software maintenance paid to vendors, or fees for cloud applications.
2. Increased administration costs. All applications require some level of system administration, and these costs are often overlooked because they tend to come out of general IT budgets.
3. Increased support costs. Each supported system requires helpdesk staff to support it.
4. Increased training requirements for new users. Also, when there are too many applications, people tend to use each application less frequently and forget how to do things.
5. User confusion caused by a duplication of functionality. Different departments use different applications for the same business processes.
6. De-normalized data. The same information is stored in different systems in different formats. For example, after a merger two different sets of customers exist in two different CRMs. Some customers can be in both systems. Even if each customer is in one or the other system, automated reports covering the whole customer base cannot be obtained.
7. Reduced efficiency. Older applications often don’t have the functionality or ease of use delivered by current applications.
8. Increased interface costs. As the number of applications increases, the costs of those applications exchanging data increases exponentially. Data tends to be siloed in different applications, which prevents users from getting the big picture.
9. Increased development costs. Custom applications developed in-house may have to work with de-normalized data in multiple repositories with different APIs and data schemas. This significantly increases the cost of internal software development.
10. Reduced security caused by an increased attack surface. More applications running mean more potential security holes that hackers can exploit.
11. Unnecessary data center resources consumed. Organizations find the number of VMs explodes, but also find the usage of those VMs (and the applications that run on them) is lower than expected. More applications mean more systems to back up, and more effort to manage those backups.

Appendix 3: Application ownership costs

Ownership costs include all regular, ongoing direct and indirect costs associated with applications. They do not include once off costs like implementation consulting or initial training. Examples are:

Commercial off-the-shelf software ownership costs

1. Annual software maintenance costs
2. Periodic upgrade costs
3. Data center costs, including things like backup, failover, etc. Also indirect costs like power, cooling, floor space, physical security, etc.

Cloud or SaaS software ownership costs

1. User access fees
2. Option fees, e.g. base, standard or premium access.

In-House application ownership costs

1. Bug fixes
2. Enhancements
3. Release testing
4. Change management
5. Analyst & developer salaries & overheads
6. Management of analysts, developers, testers, technical writers, etc.
7. Recruiting costs for developers to maintain obsolete applications, e.g. written in Cobol
8. Application documentation costs
9. Data center costs, including things like backup, failover, etc. Also indirect costs like power, cooling, floor space, physical security, etc.

Ownership costs common to all applications

1. End user training
2. Helpdesk support. Also, as support staff leave, replacements must be trained.
3. Lost user productivity, e.g. when users should be able to do something with the software, but they need support
4. Customer costs, e.g. when slow response from the organization caused by poor software fit results in customers being lost
5. Opportunity costs of downtime
6. Compliance & auditing costs
7. Security testing, auditing
8. Inter-application communication costs, where one application needs data from another, and that must be maintained.
9. Reporting costs, where data from multiple applications must be normalized and merged. Often done manually in spreadsheets.
10. Disaster recovery & business continuity planning and testing
11. IT staff management

Acknowledgment: This article is an updated version of a white paper originally published by Wayferry.

This article is published as part of the IDG Contributor Network. Want to Join?