The ERP Promise vs. the ERP Reality
The pitch for enterprise ERP has always been integration: one system that manages finance, procurement, inventory, manufacturing, HR, and customer management, with data flowing seamlessly between them. In 1995, this was a genuine competitive advantage. Organizations that could unify their operational data in a single system made faster decisions and ran leaner operations than competitors still coordinating through spreadsheets and phone calls.
Thirty years later, the same pitch is used for systems that have grown into something quite different. SAP ECC, Oracle E-Business Suite, and their contemporaries now represent multi-decade accumulations of business logic, customization, and organizational memory. A large manufacturer might have an SAP implementation that has been customized by dozens of consultants over 20 years, contains millions of lines of custom ABAP code, and has organizational processes so deeply coupled to specific ERP behaviors that nobody is quite sure what would happen if those behaviors changed.
This is not a software problem - it is an organizational archaeology problem. The ERP has become the de facto documentation of how the business actually operates. Migrating away from it is not a technical migration; it is a business process re-examination that most organizations do not have the stomach for. So they stay. And they pay the maintenance costs, the upgrade costs, and the opportunity costs of building every new capability inside a system designed before cloud computing, mobile, and API-first integration existed.
What Composable Architecture Actually Means
Composable ERP draws from the MACH architecture principles - Microservices-based, API-first, Cloud-native, and Headless - applied to enterprise resource planning specifically. The core idea is disaggregating the monolithic ERP suite into discrete, best-of-breed modules that communicate through well-defined APIs rather than shared databases and proprietary integration layers.
In practice, this looks like replacing the monolith gradually rather than all at once. The composable ERP of 2025 is not typically a fully greenfield replacement - it is a hybrid architecture where the core financial ledger (the part of SAP that nobody wants to touch) remains in place, while high-velocity domains like e-commerce order management, logistics orchestration, and customer-facing inventory visibility are extracted into modern, API-first systems that integrate back to the financial core through event-driven connectors.
The key principles that make this work:
- API-first integration contracts. Every module exposes and consumes data through documented REST or GraphQL APIs. No direct database connections between modules. No proprietary integration buses. If a module needs to be replaced, the API contract defines the interface the replacement must honor.
- Event-driven coupling. Business events (order placed, inventory updated, invoice approved) are published to an event stream. Downstream modules subscribe to relevant events rather than polling or waiting for synchronous calls. This enables loose coupling that allows modules to evolve independently.
- Domain ownership. Each module is owned by a product team responsible for its reliability, performance, and evolution. The cross-functional ownership model that made microservices work in software companies is applied to ERP domains: the team that owns the procurement module is responsible for its integration contracts, not a central IT team responsible for everything.
Which Modules to Decompose First
Not all ERP domains are equal candidates for extraction. The framework for prioritizing decomposition targets considers two dimensions: business value from modernization and technical feasibility of extraction.
Domains with high business value from modernization are typically those where the monolithic ERP creates the most friction - where the rigidity of the old system is visibly costing money or competitive position. Common examples:
- Order Management. In omnichannel retail and distribution, order management systems (OMS) need to handle complex routing logic across channels, real-time inventory availability, and dynamic fulfillment rules that monolithic ERP systems cannot update quickly enough to match market expectations. Replacing the OMS layer with a modern, API-first system (Fluent Commerce, Manhattan Active OMS, or custom-built) while keeping SAP as the financial system of record is a mature pattern with well-understood integration approaches.
- Warehouse Management. Modern WMS capabilities (robot integration, dynamic slotting, real-time labor management) require API response times and update frequencies that traditional ERP warehouse modules cannot match. Purpose-built WMS platforms with ERP integration are now standard in sophisticated logistics operations.
- Product Information Management. The ERP's product data model was designed for financial and procurement purposes. Managing rich product content, digital assets, market-specific attributes, and channel-specific presentations requires dedicated PIM systems that the ERP cannot accommodate without extensive customization.
Domains with lower feasibility for early extraction are those where the monolith's complexity is most deeply embedded: financial consolidation, tax management, and statutory reporting. These are the last to be touched, not the first.
Integration Patterns for the Transition Period
The transition from monolith to composable is a multi-year journey, not a cutover event. During that transition, you are running a hybrid architecture: some domains still in the monolith, some extracted into modern systems, and integration between them. Getting the integration patterns right during this period determines whether the migration is manageable or chaotic.
The strangler fig pattern is the standard approach: new capabilities are built in the modern system, which gradually absorbs functionality from the monolith until the old system can be retired domain by domain. The critical discipline is maintaining a single source of truth for each data entity throughout the transition - knowing definitively whether customer master data lives in SAP or in the new CRM, and ensuring every system that needs customer data reads from that source through the API layer rather than maintaining its own copy.
Event-driven integration using an enterprise event bus (Apache Kafka, AWS EventBridge, or equivalent) provides the loose coupling that makes this manageable. SAP has mature Kafka integration through the SAP Integration Suite and third-party connectors. When the inventory module publishes a stock update event, the OMS, the e-commerce platform, and the customer portal all receive it through subscription - without the publishing system knowing or caring which consumers exist.
Data migration during decomposition is the hardest operational problem. Historical transaction data must remain accessible (for auditing, reporting, and operational continuity) while new transactions flow through the new system. Dual-write periods - where both systems record transactions simultaneously while the new system builds confidence - add operational complexity but reduce the risk of the data gap that makes cutover migrations so nerve-wracking.
The Cost Honest Analysis
Composable ERP is not cheaper than monolithic ERP in the short term. The transition costs are real: integration development, data migration, organizational change management, and the period of operating a hybrid architecture before the legacy system can be decommissioned. Organizations that budget for the technology without budgeting for the change management consistently underestimate total program cost by 30-50%.
The case for composable ERP is not cost reduction in year one - it is total cost of ownership over 5-10 years, combined with the strategic value of agility. Organizations on monolithic ERP typically spend 15-20% of their IT budget on maintaining and upgrading the ERP itself, with major upgrades consuming significantly more. The ongoing licensing costs of cloud ERP modules are often lower on a per-function basis, and the elimination of custom ABAP maintenance costs (which compound as the codebase ages) can be substantial.
The agility benefit is harder to quantify but often more strategically significant: a composable architecture allows individual modules to be upgraded, replaced, or extended independently. When a better order management platform becomes available in three years, you can evaluate and migrate to it without touching the financial core. In a monolithic environment, the equivalent change would require an upgrade of the entire ERP suite.
GTEMAS Approach to ERP Modernization
GTEMAS's ERP modernization engagements start with an architecture assessment that maps the current ERP landscape - what lives in the monolith, what integrations exist, which business processes are most tightly coupled to specific ERP behaviors, and where the highest-value decomposition targets are. This assessment typically surfaces both quick wins (domains that are nearly self-contained and could be extracted within 6 months) and longer-term program candidates (domains with high value but significant coupling that requires careful untangling).
We design integration architectures that allow decomposition to proceed incrementally without creating integration debt - event-driven patterns that will scale as more modules are extracted, rather than point-to-point integrations that need to be rearchitected when the next module is addressed. And we build migration playbooks that account for data, process, and organizational change - not just the technology transition.
The organizations that successfully modernize their ERP infrastructure treat it as a strategic program, not a technology project. If your organization is navigating the gap between the ERP you have and the agile architecture you need, we would welcome a conversation about where to start and how to sequence the journey.