How Application Rationalization Without Process Clarity Leaves Enterprises Unprepared for AI

Cost is almost always the trigger. A board directive arrives to cut 20% from IT spend. The response is predictable: count licenses, consolidate vendors, renegotiate contracts. Savings are declared. Then, six months later, the initiative stalls because nobody can explain why three systems are writing to the same data field differently or why migrating the ERP took down invoicing for a week. The problem was not the savings exercise. The problem was calling it rationalization when it was actually standardization, and not knowing the difference.

José Freitas is Lead Enterprise Architect at IATA, the International Air Transport Association, where he leads enterprise architecture frameworks that support digital transformation across the global aviation ecosystem. He previously spent years at IBM and Deloitte as a chief architect and enterprise architecture consultant across banking, manufacturing, and telecommunications in regulated European markets. His earlier AI Data Press piece explored how rushing the discovery phase creates long-term complexity. This conversation extends that argument into why rationalization without process discipline leaves organizations structurally unprepared for AI.

"When organizations focus only on applications and infrastructure, they miss the two things that matter most: data and process," Freitas says. "You run an application, but in reality, the fuel of everything is data."

Two disciplines, two questions

Application rationalization and application standardization are frequently treated as the same exercise. They're not.

Rationalization is a business-driven, top-down exercise. It asks: Do we have overlapping business capabilities? Are two or more applications delivering the same business function, creating duplicate processes and fragmented data? Its output is the consolidation of redundant business functions, cleaner processes, and a more coherent data estate. This discipline is owned by business leadership and enterprise architects working from a capability perspective.

Standardization is an architecture and IT-driven, bottom-up exercise. It asks: Does our landscape comply with our technical standards? Are there out-of-support components, duplicated infrastructure, or non-compliant platforms that need to be retired? Its output is a more maintainable, secure, and cost-efficient technical environment.

Both deliver value. But they answer fundamentally different questions, involve different stakeholders, and require different governance. "When organizations focus only on applications and infrastructure, they miss the two things that matter most: data and process," Freitas says. "You run an application, but in reality, the fuel of everything is data."

TOGAF's four layers make the stakes clear: rationalization and standardization work on the bottom two, application and technical, and produce measurable cost savings. The top two, business processes and data, determine whether those savings translate into anything. Without clean processes and a coherent data estate, AI initiatives have no reliable foundation. Cost efficiency is a starting point, not a destination. EA does not carry this work alone. Product management, data engineering, and operations must also align incentives and budgets to sustain what rationalization produces.

The hidden costs nobody counts

Both disciplines are typically justified on license cost alone. But that's the wrong unit of measure. Every duplicated business function carries at least three costs beyond the license: training people to use parallel tools, maintaining parallel support contracts, and running inconsistent processes that fragment the data estate. "You count your money, you count your tools, you look at the interfaces," Freitas says. "But sometimes you do not even think about why you have this interface, why this data is going there."

The last cost is the most expensive and the least visible. When the same business process executes differently across systems—even slightly—the data it produces is inconsistent. That inconsistency does not show up on a license invoice. It shows up when you try to build a reliable reporting layer, or when an AI model trained on that data produces unreliable outputs. It also reflects in people. Someone, somewhere, is correcting that data manually every week, a chronic cost that never appears on an invoice and is never attributed to its architectural root cause.

Rationalization's true benefit is therefore not cost reduction. It is process consolidation and data clarity; cost savings follow as a consequence. A tool is just a vehicle. The destination is a clean, understandable, well-governed process.

Standard over custom

The instinct to customize deserves a direct challenge. Major platforms carry embedded best practices developed across thousands of customer implementations. Organizations that customize heavily pay for that differentiation in complexity, upgrade friction, and future integration costs. "Instead of trying to adapt a tool that already has best practices built in, companies decide to be different. Being different in this case is not a good thing. It will cost you money and speed," Freitas says.

The exception is differentiation. Where a process is a genuine source of competitive advantage, custom extensions may be justified. Standardize what keeps the lights on; protect what sets you apart.

The same logic applies to oversizing. Leaders bring tool preferences from previous roles at larger organizations and deploy platforms scaled for a company five or ten times their current size. "You have a cannon, but you just want to shoot a fly. If you own it, you own all the cost that goes with it."

Fix the patient without killing it

Where rationalization becomes genuinely dangerous is in systems deeply embedded in operations. An ERP platform underpins invoicing, payments, procurement, supply chain, and payroll functions that an organization cannot miss for a single day. Beneath all of them sit master data records: the customer, vendor, material, and account definitions that every transaction references. A migration executed without a full understanding of both the processes and the master data that feeds them can break everything simultaneously. "If you try to do that cold-hearted, you kill the patient," Freitas says.

You can plan. What you cannot do is expect the plan to hold in legacy environments. The goal is to manage the uncertainty deliberately—incremental slices, parallel runs, regression tests, rollback checkpoints. Some ERP modernization risk is unavoidable. The question is how to contain it, not whether to proceed.

This is why process mapping and master data assessment are prerequisites, not deliverables. Before any consolidation decision, organizations need a shared vocabulary of what the business actually does and a clear picture of which master data records support it, independent of which systems currently hold them. Migrating a platform without auditing the quality and completeness of its master data is one of the most reliable ways to carry yesterday's fragmentation into tomorrow's architecture. A customer record that was inconsistent across three systems before consolidation does not become clean simply because there is now one system to be inconsistent in.

A capability map grounds consolidation decisions in business logic rather than IT preference. BPMN notation makes process variants across business units comparable and defensible. EAM platforms maintain a living model of the architecture, capability relationships, integration topology, lifecycle risk, that a static spreadsheet cannot sustain. Together, these disciplines give the migration a foundation that survives contact with reality.

AI readiness starts here

Rationalization and standardization are prerequisites for AI initiatives, not alternatives to them. Organizations that plan to layer AI on top of their existing environment need to first map application families, data flows, support risks, out-of-date systems, and critical business processes. Without that mapping, AI initiatives inherit every unresolved dependency in the stack.

Process mining platforms can compress the discovery timeline significantly by surfacing how processes actually execute, not how people believe they execute, from event logs. AI-assisted EAM tooling can model the downstream consequences of a rationalization decision before it is executed: which integration points break, which data flows are disrupted. These tools are genuine accelerators. But the judgment about what to do with what they reveal remains a human responsibility. "The less regulation, the more afraid you should be," Freitas says. "If regulated industries still have spaghetti, the rest of the world doesn't even have a bowl."

The organizations that successfully bridge rationalization and AI readiness are the ones that got serious about the business and data layers first. Treat process and data clarity as the primary deliverables. Cost savings follow standardization. Transformation follows process clarity.