Powering Omnichannel Commerce with MuleSoft’s API Led Connectivity

You need connected systems for true Omnichannel

Omnichannel has been indiscriminately used as a buzzword by a large number of marketing organizations for quite some time now. But what does it really mean? Real Omnichannel involves providing your customers with a uniform seamless experience across any channel they come through, every time they do it, for any type of interaction. Given the number of channels, systems, and complexities of e-commerce, a true Omnichannel experience cannot be accomplished using one system. It is more of an orchestration of systems working together. A conductor of that orchestration is needed. That conductor is typically the OMS (Order Management System) that sits at the center and ties all systems together.

Now the challenge is to get all the systems to speak the same language, so they can communicate timely and efficiently. It can be acceptable for some of the interactions to be on a batch basis, happening nightly for example. But for the most part, especially in this day and age, a large part of this communication needs to happen in real-time. Imagine if you receive an order in the mail for an item you ordered online, and you want to return it because there is a problem. You know the company you bought it from has a store 5 minutes away, so you drive there. Your expectation is for the associate to be able to locate your order instantly, start a return, and process a refund to your credit card. In order for this to happen, their backend systems need to be real-time connected.

What language does each system talk?

Each system has its own language if you will (their API specifications). The conventional (old) way of integrating systems together is to build each integration between 2 systems independently (point to point). This is not a big problem if you have a total of 2-3 systems. It starts becoming a major problem when you have a large number of systems that need to be connected.

Looking at the diagram above, to get all these systems integrated you will have to build 57 point-to-point integrations. Some systems need more integration points than others. What happens when these systems are retired in the future and need to be replaced with newer applications? All these integrations will need to be rewritten, making the task of replacing the systems daunting and sometimes causing upgrades to be continually postponed.

What if all systems spoke the same language?

MuleSoft’s API Led Connectivity helps you do just that. Think about it as a quick translator you bolt onto your systems, so they can all speak the same language. Although not mandatory, it helps to define a standard language to be used (your own abstract data model). Your API network will use that abstract data model to exchange messages between systems.

MuleSoft’s API Led Connectivity breaks down the APIs into three reusable layers:

1. System APIs: Each one of the backend systems will have its own System API that exposes its functionality in a standard way. This allows other applications – and teams working on them – to build their integrations without the need to learn the inner workings of that system.

2. Process APIs: This layer will contain APIs that encapsulate processes that need to interact with multiple systems to complete. The example in the diagram above is for an Order Process API. When an order is placed, it needs to be created in the OMS, details of the order need to go to the ERP, and the customer record needs to be created or updated in the CRM. This is all done by the Order Process API which leverages the involved backends’ System API layer.

3. Experience APIs: The third layer is responsible for accessing data and presenting it in the format each 3<sup>rd</sup> party or external system needs, with user experience in mind, along with specific formats and connectivity requirements of that system. In our example, we have multiple external systems that will be creating orders: a mobile app, several e-commerce websites, retailers, and stores. Each one of these systems will have its own experience API to handle its specific requirements, but all of these experience APIs will be calling the same Order Process API to create an order.

Moreover, MuleSoft provides a self-service portal – Anypoint Exchange – for organizations to publish their APIs and make them discoverable. APIs can be viewed only internally if private or can be made publicly available. Documentation as well as a mocking service to try out the API is included.

What if one of the systems needs to be replaced?

Let’s assume the company decides to replace their ERP system and move from SAP to NetSuite. If point-to-point integrations were used, at least 9 integrations would need to be redone in our example. But if API Led Connectivity was implemented, only the System API would need to be rewritten to point to NetSuite instead of SAP. All other APIs and integrations would remain intact.

Conclusion

MuleSoft’s API Led Connectivity approach can dramatically boost an organization’s efforts in implementing a true Omnichannel commerce platform. The ability to quickly implement real-time, scalable, and reliable integrations enables the business to deliver the uniform, quick customer experience expected nowadays. This is achieved thanks to the increase in the speed of implementing integrations by providing reusable components and enabling ease of use and self-service of APIs. The approach also increases productivity as a result of freeing up time otherwise taken by maintenance activities.

References:

1. What is API-led Connectivity? https://blogs.mulesoft.com/learn-apis/api-led-connectivity/what-is-api-led-connectivity/

2. The value of connectivity. https://www.mulesoft.com/ty/wp/application-network-benefits