Composable ERP strategy: Key benefits and steps for success

Coined in the early 2020s by Gartner, the term composable ERP has become trendy. It denotes a type of ERP architecture that involves piecing together business applications rather than packaging them into a single "monolithic" system, which has been the traditional architecture -- and main selling point -- of ERP in its half-century-plus of existence. Proponents say composable ERP allows a mix-and-match approach to key ERP functions like accounting, HR, inventory management, order management and CRM, giving organizations more flexibility, scalability and freedom to adopt emerging technologies.

But what does composable ERP really mean, and why would you want to assemble what you can still buy all in one piece? Following a composable ERP strategy introduces technical and organizational challenges that call for having a clear view of the benefits and risks.

Sanjay Mhaskey is lead principal consultant at EOne Infotech, an IT consultancy and Oracle ERP partner based in Edison, N.J. He has extensive experience in Oracle ERP implementations and is a certified blockchain expert. Last September, he published a journal article on composable ERP architecture.

Mhaskey explained the essentials of composable ERP, including its main benefits and challenges, and offered advice on deciding if it's right for the organization. This interview was edited for length and clarity.

Sanjay Mhaskey

How do you define composable ERP?

Sanjay Mhaskey: Composable ERP is an architectural philosophy wherein different ERP capabilities are built using separate modules, compared with monolithic ERP, which is one application with different capabilities or functions -- for example, inventory management, financial management and transportation -- all built into a single application and tightly integrated.

What makes it truly composable as opposed to simply pairing an ERP system with another vendor's HCM or CRM software, which is very different from the decentralized, made-from-scratch ERP that seemed to be the original vision?

Mhaskey: When we think about composable ERP, obviously, modularity is one characteristic. The second is that the whole architecture is based on microservices -- small building blocks, each with its own capabilities, self-contained and not tightly integrated.

For example, we can have inventory management as a microservice. Inventory management caters to multiple business functions, such as sales order management and manufacturing. It is self-contained in the sense that, to customize an inventory management module, we don't have to customize sales order management or manufacturing management, even if they're linked. They're self-contained in that they do not have to depend on the libraries of different business functions and self-contained even in the data. We can customize a module or microservice without impacting the whole application.

We can also look at composable ERP as a composition of different microservices talking to each other that are event-driven and not tightly integrated. Unlike a monolithic ERP where, for example, a sales order management application would call a business function or refer to a database that belongs to an inventory management table, a composable ERP system would be based on events. One microservice or module would send an event, and another microservice would consume that event.

Are there other architectural elements and technologies?

Mhaskey: The most important thing is to have an API mindset. When we think of composable ERP, we always think of the application programming interface, the backbone, the standard way of communicating between different modules or applications. Second are the various technologies that support development of microservices. We also need something like orchestration: different "workers" in the form of microservices and a "manager" that decides what work to give to which microservices.

One of the technologies that is commonly used is Kubernetes. It's a kind of container management that supports developing composable ERP architecture by deploying and scaling containers comprised of microservices.

What are the benefits of composable ERP?

Mhaskey: One is being able to face the challenges of market disruption. Second is innovating continuously to stay competitive with peers.

Third is scalability. Depending on what part of your business is consuming the most resources, you can pick a particular module and develop or deploy it so it is scalable. For example, if a retailer wants to use e-commerce to market their brands more rapidly, they would develop an e-commerce module so they can just scale up that piece. With monolithic ERP, if they want to scale up, they incur a lot of infrastructure cost, and then there's hardly any ability to scale down. Companies using composable ERP can scale up or down at will, depending on their market needs.

Another benefit is avoiding vendor lock-in and not having to depend on the vendor for upgrades or customizations. Suppose somebody wants to customize a business process. They're dependent on the vendor because most of the source code is proprietary. It becomes very difficult for them to switch to a better choice. They also have to depend on the ERP vendor for upgrades, which again incurs costs.

Digital transformation is the need of the hour. Monolithic ERPs barely support digital transformation. They do support it, but not in the way it can be achieved through composable ERP.

What are the important considerations before deciding whether to adopt composable ERP?

Mhaskey: ERP caters to all the business functions of a company. It's a major, major application that is critical to the organization. Any change from a monolithic ERP to a composable ERP would be a total transformation.

Companies must first think about whether they really want to go for it. If their processes are not that complex and their ERP is simple, they'd better stick to monolithic ERP.

Any change from a monolithic ERP to a composable ERP would be a total transformation.

They also have to think about the challenges they face from using monolithic ERP, whether it's scalability, the ability to innovate or time to market. Once the business challenges are identified, they can consider how the capabilities of a composable ERP will address those challenges.

Obviously, it's going to hit the culture and the way they develop and customize the applications. It's not just a transformation to the business. It's also transformation in the IT group -- the developers, consultants and technical people involved. It's a total cultural change.

Since this is a new concept, they also have to think about their capabilities, such as using APIs and microservice technologies. Are they ready to take on the extra load of governing the architecture compared to a monolithic architecture? They also have to think about the domain of their business, whether it is within geographical boundaries or outside, and whether it would make sense for them to deploy these modules or microservices at different geographical locations to improve latency.

What challenges do organizations face when implementing composable ERP?

Mhaskey: Typical challenges would be identifying the modules to consider for microservice development and thinking about the data model.

In monolithic ERP, you have a unified data model, but in composable ERP each microservice has its own data. There's a chance that master data will get duplicated, so the challenge is to unify data and avoid duplication across modules.

Security is also a challenge. You have to come up with a unified security layer because each module or microservice will have its own security for accessing data.

You have to make sure the microservices are coordinated well. For example, if you change or customize a microservice that another microservice was referring to, once you change it -- even when you just change the IP address -- it still should work. A service registry is one solution.

Teams might be spread across different geographies, with one module or microservice deployed in Europe and another in the U.S. A different team could be the owner or manage the module deployed in Europe.

Do composable ERP costs differ from those of monolithic ERP?

Mhaskey: One of the objectives of composable ERP is, of course, the cost advantages, such as avoiding vendor lock-in and scalability costs. This architecture is going to reduce the cost. That is definite. But whether it's going to increase the initial cost compared to monolithic ERP can only be determined by the level of composable ERP the company is going for. It all depends on the complexity.

Is this the kind of project where the organization must develop the ERP from the ground up, maybe with outside help?

Mhaskey: You can have a multi-vendor setup. A crude example: You can have the inventory management module from SAP, the transportation module from Oracle and maybe an e-commerce module from Oracle NetSuite. Because composable ERP supports interoperability, SAP inventory management would be talking seamlessly to Oracle transportation management. You have the flexibility of choosing from the best software in the industry.

Composable ERP, especially microservices, also supports a developer community that works with standard APIs. That helps with developing things in-house. You don't always have to depend on the big vendors and can develop something that serves a niche in your business and easily talks to the other applications.

Can you give examples of companies that have implemented composable ERP?

Mhaskey: Among the big players is Coca-Cola European Partners, which bottles beverages. They transformed from their monolithic SAP ERP to an architecture that is totally based on microservices. It has helped them scale their operations and reduce costs. They were able to avail themselves of all the benefits of composable ERP.

TechStyle Fashion wanted to go for e-commerce and was looking for a solution to help it better market its brands. They didn't completely transform their ERP landscape, but the e-commerce part and other elements of composable ERP have helped them market their products. They also have better visibility into their supply chain.

Other companies do not market themselves as having a composable ERP architecture but do have it in some sense. They integrate maybe a CRM system with, say, Oracle ERP, or they use Salesforce that seamlessly integrates with SAP ERP. They're using a modular architecture but not in a true sense of composable ERP. It has to have microservices to be truly considered composable ERP architecture.

What are some of the keys to success with composable ERP?

Mhaskey: [First], it's having a vision for composable ERP and very clear reasons for wanting to transform from monolithic ERP. Second is governance. For this architecture to succeed, you must have solid architectural governance in place, a security model, role-based access and clarity about the kind of security you're going to implement. You also need to choose a data model because different modules will have their own siloed data.

Composable ERP goes back several years to when Gartner first used the term. How popular has true composable ERP become, or has it maybe not lived up to its promise?

Mhaskey: This is a comparatively new architectural concept, that's for sure. But the need for modularity dates back 20 years or more. Most big companies are using multiple ERPs. They might have SAP at the core and NetSuite that integrates with it for e-commerce functions. Or maybe it's Oracle JD Edwards for retail and SAP for core ERP functions.

And why is that? They could very well use one ERP for their business functions, but companies find reasons to use multiple applications or modules to meet their business requirements. The need is already there.

Things are still evolving. The architectural concept is in place, but companies are still not very confident because it's a high-stakes transformation that will cost money and drastically change the culture. Companies are also a little dicey about composable ERP because there aren't many use cases.

Many ERP vendors have introduced the concept of low-code/no-code, which is similar to composable ERP. But you don't have to code it from scratch. You just plug in different components and build whatever you want.

Companies have realized the need, but it has not gone to that level of modularity, even with low-code/no-code ERP architecture. Things are moving in that direction but not 100%.

Where do you think composable ERP will be in the next three to five years?

Mhaskey: Think of an AI machine learning application as a microservice that is helping a business make a decision. You can develop a machine learning solution as a microservice that can be seamlessly integrated with an existing application -- for example, a financial or inventory management application -- with all the capabilities that this modular architecture has. I've published a paper on this topic.

Composable ERP will definitely promote development of applications that use AI technologies and help integrate them with existing ERP systems. In two to three years, things are going to move fast.

David Essex is an industry editor who creates in-depth content on enterprise applications, emerging technology and market trends for several Informa TechTarget websites.