Composable ERP: Modular, API First Systems for Mid Sized Businesses

For years, buying an ERP meant choosing one large package that covered almost everything: finance, purchasing, inventory, sales, production, and HR. That approach gives you one source of data and one vendor to call. But many mid sized companies have also felt the other side: modules that do not fit still have to be used, small adjustments cost a lot, and replacing one part means replacing everything.

The term composable ERP has emerged as an alternative. The idea is that business systems are assembled from components that can be chosen, replaced, and connected through APIs, like building blocks. This article explains what composable ERP means in practice, when it pays off, the risks that are often underestimated, and how to adopt it step by step without creating a new integration mess.

Summary

• Composable ERP means a lean ERP core combined with specialised applications connected through APIs, rather than one large package that does everything
• The main benefit is freedom to choose the best tool for each function and to replace one part without dismantling the whole system
• The risks are integration complexity, inconsistent data, and responsibility spread across many vendors
• The approach demands discipline in master data, API contracts, and integration monitoring
• For most mid sized companies, the best path is a stable core for finance and inventory, with specialised components in the areas that truly differentiate the business

From monolithic ERP to assembled ERP

Traditional ERP is designed as a single integrated system. All modules share the same database, so a sales transaction immediately affects stock and the accounting journal without any extra integration. That is its main strength, and the reason ERP became the answer to the hidden cost of data silos.

Problems arise when business needs evolve faster than the package can. A distribution company may need a field sales app far better than the ERP's built in module. An online store needs an order management system connected to many marketplaces. A factory needs more detailed production scheduling. In a monolithic ERP, the options are to force the built in module, pay for expensive customisation, or build a separate system that is not connected.

Composable ERP flips the thinking. Instead of asking which modules the ERP vendor provides, the company asks which business capabilities it needs, then chooses the best fitting component for each capability, with the ERP core as the centre for recording official transactions.

Components of a composable architecture

In practice, a composable architecture usually has several layers. The split does not have to be rigid, but the pattern helps clarify each part's role.

• ERP core: general ledger, payables and receivables, inventory, and purchasing. This is the source of truth for financial and stock figures
• Specialised applications: CRM, point of sale, warehouse management, field sales, HRIS, or applications built specifically for the company's unique processes
• Integration layer: APIs, webhooks, and message queues that move data reliably between the core and specialised applications
• Data and reporting layer: a data warehouse or dashboards that combine data from every component for analysis
• Identity layer: single sign on and consistent access control across all applications

The role of APIs in this approach

Composable ERP is only possible if every component provides a complete, documented, and stable API. API first means the system is designed so that all its functions are reachable through the API, not just through application screens. When assessing vendors, check whether the API covers the operations you need, how request limits work, whether webhooks are available to notify other systems of changes, and how the vendor handles API version changes.

When composable ERP pays off

This approach is not right for every company. It delivers the most value when several of these conditions hold.

• There are processes that truly differentiate your business and are poorly served by standard ERP modules
• The company operates across many channels, such as physical stores, an online store, marketplaces, and B2B sales, each needing specialised tools
• The business grows through acquisition or expansion and needs to combine different systems
• The company wants to replace legacy systems gradually rather than all at once
• There is an internal IT team or technology partner able to maintain integrations over the long term

Conversely, for businesses with fairly standard processes, one integrated ERP with light adjustments is often cheaper and easier to manage. Splitting systems without a clear business reason only adds points of failure.

Risks that are often underestimated

Integration becomes a product in its own right

Every connection between systems is software that must be designed, tested, monitored, and maintained. More components mean more connections. When one vendor changes its API, an integration can break without warning. Companies often budget for each application's licence but forget to budget for building and maintaining the bridges between them.

Inconsistent data

If item codes in the warehouse system differ from those in the ERP, or customer data in the CRM is out of sync with the receivables module, reports will contradict each other. Composable ERP requires clear rules on which system is the source of truth for each type of data. This foundation is covered in more detail in our article on ERP master data.

Scattered responsibility

When an order from the online store does not reach the ERP, who is responsible? The online store vendor, the ERP vendor, or whoever built the integration? Without clear roles, problems can bounce around unresolved. Assign an owner to every integration and agree service levels in writing.

Security and access control

Every component brings its own user accounts, API keys, and potential security gaps. Manage identity centrally with SSO, store API keys securely, and limit each integration to only the data it truly needs.

Design principles that make composable work

1. 01Define one source of truth for every data entity: items, customers, suppliers, prices, and financial accounts
2. 02Design event based integrations, such as order created or goods received, so other systems react without constant polling
3. 03Use queues and retry mechanisms so data is not lost when one system is temporarily unavailable
4. 04Log every integration message so failures can be traced and reprocessed
5. 05Document data contracts between systems and treat changes to them like software changes
6. 06Monitor integration health with dashboards and alerts rather than waiting for user complaints

These principles echo the broader architecture discussion in our article on monoliths versus microservices. Composable ERP essentially applies similar logic at the level of business systems: modularity brings flexibility but demands operational maturity.

Adopting it step by step

1. Map business capabilities

List the business capabilities you need, such as taking orders, managing stock, invoicing customers, paying employees, and analysing sales. For each capability, note the system used today, how well it works, and how important the capability is as a business differentiator.

2. Define a stable core

Functions such as accounting, tax, and inventory rarely differentiate a business, but they must be highly reliable. They are best handled by a mature, stable ERP core. Our guide to which ERP modules to implement first can help decide the order.

3. Choose differentiating areas for specialised components

In areas where your business excels, such as customer experience, field sales, or a special production process, consider best in class applications or custom software. This is where composable flexibility truly adds value.

4. Take the integration layer seriously

Do not connect systems directly one by one without a plan. Design a central integration layer, complete with logging, automatic retries, and monitoring. The investment pays back every time you add or replace a component.

5. Replace legacy systems little by little

Composable ERP fits a gradual modernisation pattern: one function moves to a new component while the old system keeps handling the rest, until the old system can finally be switched off. This approach is covered in our articles on modernising legacy systems without stopping operations and ERP go live strategies.

Example scenario: a distributor with many channels

Imagine a consumer goods distributor that sells to wholesale shops through a field sales team, to consumers through its own online store, and to other buyers through several marketplaces. Every transaction is recorded in a legacy ERP whose sales module was designed for office orders. The field team writes orders in a notebook, the online store has its own system, and marketplace stock is updated by hand every morning.

With a composable approach, this distributor does not have to replace the ERP all at once. The ERP core keeps handling inventory, receivables, and accounting. A field sales app that works offline is added and sends orders to the ERP through the API. An order management system brings together orders from the online store and marketplaces and passes them to the ERP, while stock changes from the ERP are pushed back to every channel through webhooks. A separate dashboard combines sales data from all channels for management.

Success in this scenario is not decided by the applications chosen but by things that are invisible: the same item codes in every system, clear rules on which system determines available stock, a queue that holds orders while the ERP is under maintenance, and one person responsible for monitoring the integrations every day.

Questions when assessing vendors

• Are all key functions available through the API, including creating, changing, and cancelling transactions?
• Are webhooks or event notifications available for important data changes?
• What is the API versioning policy, and how long are old versions supported?
• Can data be exported in full if the company switches one day?
• How is access control applied to API access?
• Is there a test environment for developing and testing integrations?

The answers matter as much as the feature list. Consider the pricing model too, whether SaaS or a one time licence, because subscription costs across many components can add up faster than expected.

Conclusion

Composable ERP is not a trend every company must follow, but an architectural choice with real benefits and costs. For mid sized companies with distinctive processes, many sales channels, or aggressive growth plans, it offers flexibility that is hard to get from one big package. The keys are a stable core, disciplined master data, and an integration layer that is designed and maintained seriously. Without them, a modular system simply becomes a new collection of data silos with a more modern name.