Many enterprises want to start an application consolidation project to cut costs or improve business agility, but...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
they often find that a project stalls when it comes time to decide which applications should stay and which should go.
To help you push through that inertia (and the tough decisions that will follow), we talked to a range of experts and practitioners about how to kick start the application consolidation process. CIOs can use the following questions to devise a consolidation strategy and establish the criteria by which application decisions will be made.
Some decisions still won't be easy, but having a methodology is the first step to application consolidation success.
What is the function of the application? Is it customer facing? Revenue producing? Core to what the business does, or is it a commodity? Core might not necessarily mean the application itself, but the intellectual property (IP) locked in that application. A policy and claims insurance application may be deemed core, but what information in that application is actually core, and can the overarching application be retired with the IP transferred to another system?
Be ready for political battles when deciding what is core vs. commodity, but no application should be deemed off limits when taking stock of the application portfolio.
"CIOs need to look at their ERP systems, financial software like general ledger, accounts payable … all of their applications and ask, 'Why are we doing all this?'" said Phil Murphy, an analyst at Forrester Research Inc. in Cambridge, Mass. "Application portfolios are being overloaded with 40 years of adding applications and not taking anything out, and [CIOs] can't tell you what's in the bucket exactly, only that it costs more than they want it to."
How well can we support this application long term? Do you often have to bring in outside help, or keep a consultant on staff full time to support an application? Does the underlying programming language and technology of the application jibe with the company's overall and evolving enterprise architecture strategy?
"You need to be asking the enterprise architects what the future technologies are for the company and which technologies they want the company to start to move away from," Murphy said.
Application standardization vs. migration
When should CIOs consider standardizing on particular applications vs. migrating to a new application during application consolidation efforts? Research firm Gartner Inc. offers these guidelines for standardizing vs. moving to something new:
- The application technology is current and will be well supported for at least seven years.
- Business teams are happy with the performance of the application as it is.
- The application can support the needs of other business units being transferred over to it. -- C.T.
However, getting rid of an application because of its age is a common mistake. A 25-year-old COBOL program can be less problematic than a newer client/server Visual Basic application, Murphy said.
The underpinning technology's staying power should also be a factor. Was the application acquired by another vendor? If so, is the vendor promising long-term support and backing this up with regular updates and a support program? Has the vendor introduced a new application that overlaps what you're currently using? Or perhaps it's bundling it with a new suite of applications. Find out the vendor's long-term strategy for supporting the application as the product strategy changes.
And crunch the support numbers. Start taking stock of how buggy an application is and how much it costs every time the IT team has to fix that application. Or perhaps the company is outgrowing an application, causing IT to work full time on enhancements. Maybe it's time for a new application suite that covers more requirements and requires less customization.
Even if the application proves to be a cost center from an IT perspective, it may be a revenue-producing application. "If the business department is making $10 million using this application, even though it costs more than other applications to support, is it a smart move to replace it or disrupt a money-making business process?" Murphy said.
Look for areas where you can eliminate data replication.
At Ridley Inc., multiple AS/400 applications all have different user interfaces and are integrated with several other systems, such as Cognos. "It became very obvious that we had redundancies when the CEO asked for reports," said Jeff Kadlec, IT Director at Ridley, a maker of animal feed and nutrition products based in Manakato , Minn., in the U.S. and Winipeg, Manitoba, in Canada.
"We couldn't handle different points-in-time requests for BI, and we had to figure out a way to display information as a single source of the truth to our executives," he said. The company rolled up all AS/400 applications and Cognos, among other applications, to Microsoft Dynamics AX, a project that continues.
Do not throw out duplicate applications for the sake of consolidation, however, warns Gartner Inc. in a study on the principles of application consolidation. A manufacturing facility in one country may use a different production management system than a facility in another country because production models are very different. Forcing one facility to use another production system could destroy valuable information. So remember to ask the right questions. In this case, it's a question of production engineering and not application consolidation, according to Gartner.
Choose a standard for data definitions, technology and application sets. Standards then become one set of criteria in deciding which applications and technology stay or go.
That's not to say that establishing standards is easy. At Ridley, a project team of business and IT leaders took six days to decide what it would take to gather information into a single source. "That does not include executing on anything, just deciding on the definitions, business requirements and getting approvals for just those decisions. That still doesn't include financial approval for the project," Kadlec said.
Once established, those definitions and standards drove decision making.
"For the development team, for example, we now have an approved set of tools and databases they can use, and even if it might be simpler in the short term to use a different tool set to get a job done, we would rather put more work into it so that we stick with our corporate objectives and standards," he said.
Decide which data is worth keeping as part of the application consolidation project.
Remember that a goal of application consolidation is the ability to offer more consistent data views and dimensions from fewer sources to simplify data presentation and business analytics. So picking what data is important -- which is challenging in itself, given data holds different value to just about everyone at a company -- is as key as choosing which applications can be retired.
"What impact will bringing old [data] into that system have, and what effort will it take to massage that information in the new repository to get it to meet what you want it to do?" Kadlec said. "Sometimes it's better to simply do some re-entry of data; in other cases you will have to massage it and clean it."
Let us know what you think about the story; email: Christina Torode, Senior News Writer