When EDI first came into use, supply chains were simpler, with a limited number of suppliers. Now, thanks to globalization and specialized manufacturing, there might be hundreds of suppliers in a supply chain. And, as prices change, businesses move overseas, and market conditions evolve, these suppliers change as well.
Businesses want control and visibility over their processes – even as they grow more complex – because they are so integral to business strategy and success. Yet, while EDI messaging approaches may not be fully fit for today’s competitive landscape, given its adoption and organizations’ investment in it, EDI isn’t going away anytime soon. To succeed, companies must find a way to marry new architectural approaches to B2B/EDI challenges that insulate the legacy technologies from the new and abstract its limitations.
Applying agile approaches to EDI
MuleSoft’s work with leaders in retail, manufacturing, and transportation and logistics suggests that it is possible to innovate and differentiate, despite the constraints that B2B/EDI can impose. These organizations are applying API and microservices approaches to drive a “two-speed” innovation approach that supports innovation, even in the face of legacy B2B/EDI technologies. We see two distinct patterns:
RESTful API “experience layer”: For many organizations, B2B/EDI does not need to be the primary means of interacting with external trading partners. New and emerging distributors, such as resellers and suppliers, may not have the strict requirement to interact via B2B/ EDI interfaces. In fact, they may prefer to engage through more modern techniques, such as providing purchase order instructions through a RESTful API, rather than an X12 850 purchase order message. In these cases, organizations can drive significant increases agility by wrapping existing B2B/EDI gateways with RESTful APIs and insulating trading partners from the pain of collaborating through B2B/EDI.
Reusable APIs “process layer”: Where organizations must continue to leverage B2B/EDI messages, innovation is still possible. For existing B2B/EDI interfaces, organizations can use a microservices-based approach to reuse processing logic between trading partners (e.g. common message validation or message enrichment processing logic to avoid duplication of effort and decrease the time it takes to onboard new partners).
Both of these approaches reflect a broader API-led connectivity approach.
The API-led architecture
API-led connectivity is a multi-layered approach that scales IT capacity through its emphasis on modular components, decentralized authority over application development, and reusable assets. It is a fundamental shift in the IT operating model and promotes decentralized access to data and capabilities while retaining security.
API-led connectivity calls for a distinct “connectivity building block” with three components:
- Interface: Presentation of data in a governed and secured form via an API.
- Orchestration: Application of logic to that data, such as transformation and enrichment.
- Connectivity: Access to source data, whether from physical systems or from external services.
System Layer: System APIs provide a means of accessing underlying systems of record (e.g. ERP, billing systems, etc.) and exposing that data while providing downstream insulation from any interface changes or rationalization of those systems. These APIs are changed more infrequently and are governed by central IT, given the importance of the underlying systems.
Process Layer: The business processes that interact with and shape this data should be encapsulated independently of the source systems from which data originates, as well as from the channels through which that data is delivered. These process APIs perform specific functions, provide access to non-central data, and may be built by either central IT or line of business IT.
Experience Layer: Data is now consumed across a broad set of channels, each of which want access to the same data, but in a variety of different formats. Experience APIs reconfigure data so that it is most easily consumed by its intended audience — all from a common data source, as opposed to setting up separate point-to-point integrations for each channel.
API-led connectivity in the EDI context
The API-led approach provides flexibility to serve different partners as well as control over core systems. Using the retail industry as an example, below is a diagram of how API-led connectivity can co-exist with EDI. In this example, we show the following APIs:
- System API layer: This layer provides consistent, managed, and secure access to backend systems by abstracting and unlocking data from core systems such as a legacy backend database, SAP, and Salesforce to create product APIs, order APIs, and partner APIs.
- Process API layer: This layer takes the core assets and combines them with business logic to create more value. By aggregating data extracted from the Product, Orders, and Partner APIs, the Sales Order, Invoice, and Shipping Notice APIs are created. These APIs process the purchase order, check inventory levels, and create the appropriate acknowledgment notices necessary for partners.
- Experience API layer: This layer is designed for consumption by a specific end-user app or device that will be exposed to the partners. Anypoint Partner Manager creates a partner profile that can be templatized and reused from Partner 1 to Partner 2 if the new partner requires similar B2B/EDI formats, e.g. EDI 850 via AS2. This will ultimately be exposed to partners via a web channel or portal to allow for B2B transaction statuses to be viewed and the associated payloads to be viewed or downloaded.
The architectural benefits of this approach include creating a decoupled architecture that abstracts away complexity and having a more agile response to change. All channels are able to reuse the same process logic, so as new partners are onboarded, all that’s left to manage is the logic of receiving messages. The purchase order processing logic is already baked in, thus allowing the retailer to move quicker.
This approach can be taken one step further — the retailer could apply the API-led connectivity approach at the experience API layer too. In this scenario, trading partners can submit purchase orders via a partner API and create the required EDI 850 message to process the purchase order document. In this way, it could onboard partners more quickly by eliminating the intricacies of EDI for franchises that may not have an EDI gateway or for new retail channels like kiosks that do not “speak” EDI.
To access a case study of a North American retailer that is engaging customers in new ways with B2B/EDI, download our whitepaper, Modern supply chain management and EDI systems.
