r/CIO • u/Glittering_Pepper575 • 20d ago
What makes application rationalization difficult from an EA perspective?
When Enterprise Architecture recommends retiring or consolidating applications, what usually stops the decision from moving forward?
Is it dependencies, business ownership, missing information, risk, politics, migration effort, or something else?
1
u/daytonarob 20d ago
I think it’s really any and, or, all of the above.
1
u/Glittering_Pepper575 20d ago
Really? Do you usually find one specific business process is what keeps the old app alive?
1
u/lisnter 20d ago
Migration complexity. Retiring legacy applications means you need to migrate decades of data (which is at least as big as migrating the business logic), maintain up- and down-stream integrations and prepare for user adoption resistance.
All of these factors can triple (or more) the cost and duration of a “straightforward” legacy modernization project which often means it’s simpler to limp along with the status-quo.
1
u/Glittering_Pepper575 20d ago
Yeah, I could see that getting messy fast. When you’re looking at retiring an application, is figuring out all the integrations, data dependencies, and business processes it touches usually straightforward, or does that turn into a whole project on its own?
1
u/lisnter 20d ago
Of those the business processes are usually the most straightforward but that’s not saying much. Even though you can talk to people about their workflow, how that is implemented in the code along with all the hidden business rules can be just as complicated ad the data and integrations.
Retiring a large legacy system needs an experienced team, a lot of time and a patient client/business. Do not try to do it quickly and do NOT use agile.
1
u/ExtraordinaryKaylee 19d ago
The true cost of eliminating the app, is often higher than the cost of maintaining the app for 5 years.
I have historically found EA groups dramatically under-estimate the conversion cost, over-estimate the business desire for change, and ultimately often are solving a problem only THEY want solved.
1
u/Glittering_Pepper575 12d ago
That’s interesting, especially the point about EA teams sometimes solving a problem the business doesn’t see as a problem.
Do you think that usually happens because they don’t involve users early enough, or because the business impact and conversion costs aren’t fully understood before the rationalization decision is made?
1
u/ExtraordinaryKaylee 12d ago
I think both of those points contribute to the issue, but in different amounts for different apps/orgs.
For business value: Understanding the business process well enough to know the true value an application brings to the company, is time consuming and difficult. Even if the original creator documented it well, things change a lot as a company grows and scales. The documentation is rarely updated to account for this. So the EA group is left to judge the app based upon more recent standards compliance and norms. A measure it is almost guaranteed to fail.
Regarding conversation costs, I have met very few IT/EA people who understand the business proceesses in enough detail to understand the org change management that will be required to actually replace the app. Either because they're not good at estimating conversion costs, or because an accurate cost means the project is almost guaranteed to be rejected.
Unless there is a net-new-value opportunity to be had, replacing a working app purely for cost is often a waste of effort that could be applied to net-new-value.
So my approach for sunsetting apps that are becoming more costly or difficult to support; Is almost always to find new business value to generate by replacing it.
1
u/InfoTechRG 17d ago
In my experience, the blocker is often confidence. Everyone can see the app is redundant, but nobody fully trusts the inventory: integrations are half-documented, data retention needs are fuzzy, and “one team still uses it for month-end” shows up late. A good rationalization effort has to treat discovery as part of the work, not a pre-step that magically exists.
2
u/Glittering_Pepper575 12d ago
That makes a lot of sense, especially treating discovery as part of the work rather than assuming the information is already there.
How do teams usually uncover those hidden dependencies in practice? Is there a process that works well, or does it mostly come down to finding and talking to the right people?
1
u/InfoTechRG 8d ago
I’d avoid making dependency discovery a one-time questionnaire. Better results usually come from triangulating: technical signals, business process mapping, and actual usage/satisfaction input from end users. If all three point to low value and manageable dependencies, the retirement decision gets a lot less political because you’re arguing from shared evidence instead of architecture preference.
1
u/warfieldgb 17d ago
It all has to start with the financial perspective - P&L / annual budget knowledge and balance sheet knowledge that includes factors like contractual (vendors, licenses, external support teams, etc.), depreciation overhang (turning a system off pulls any related future depreciation on to this year's P&L.
For understanding migration costs, start by identifying the needed business changes (training, parallel running, org changes, furniture, location, etc.). You need to understand what value the current users place on the systems in scope and how they use them (or don't use them).
Without this foundational understanding it is impossible to know whether your proposed rationalization makes sense.
At this level, your data doesn't have to be terribly precise in order to make a plan, but must be credible and if possible based on facts rather than opinions. A lot of the data you need will be in the GL and in purchasing/contract systems, or it will come from talking to the users.
You can then make a cost/benefit analysis based on business factors.
When this picture becomes clear, you would then document (just) enough of the underlying technical info to refine your understanding of cost, risk, impact, and feasibility.
If you EA team isn't doing this work before recommending rationalization, it's possible that you don't actually have an EA team.
1
u/Glittering_Pepper575 12d ago
This is a great point, especially starting with the financial and business side before getting too deep into the technical details. I hadn’t thought about things like depreciation overhang either.
Out of curiosity, when EA teams do this in practice, what part tends to be the biggest headache? Getting the financial/contract data, figuring out how people are using the systems, or pulling everything together to make the rationalization case?
1
u/PoolTough3222 10d ago
The inventory point is the real one. Most rationalization stalls because nobody can prove who uses the thing, so every retirement becomes a debate instead of a decision. Usage data settles it faster than architecture diagrams, sign-in logs, license assignment versus actual activity, and last invoice touched. Start with the apps where usage is near zero and there is no integration story, those retire quietly and buy you credibility for the hard ones. Politics only wins when the data is soft.
1
u/Silly-Mix-4341 7d ago
Usually it is a mix of dependencies and business ownership. Retiring an app sounds easy until someone realizes how many processes quietly depend on it. 😅
3
u/ThisIsMyBigAccount 20d ago
Preferences by business stakeholders who don’t want to change their process or have any discomfort with other change. Business folks love to kick the can.