How do enterprise architects view B2B integration?
We have been talking lately to several enterprise architects in different organizations about how they view B2B integration. We have heard several interesting and completely different approaches to B2B.
Sentence #1: “ B2B Integration ? It’s just another interface.“
In this approach, to solve a B2B integration problem, all we need is to use our existing internal integration platform to implement the interface and add a robust-managed file transfer tool to handle technical connectivity beyond the firewall in protocols such as AS2, SFTP, etc.
This approach regards B2B as a technical problem, and, indeed, the only difference between this and standard A2A integration is the external connectivity.
We believe that this approach makes sense when there are limited B2B requirements or a limited number of trading partners. Investing in a solution that would do it all may be overkill. However, when the B2B space is not limited to a given organization, then this approach might present some challenges:
Usually, in this approach, the managed file transfer tool is not tightly integrated into the standard integration tool (if at all). Thus, both monitoring and management can be a nightmare. The most common, “I didn’t get the file, where is it?” problem would usually require searching through different tools in order to track down the problem.
In addition, internal integration tools are usually monitored in a very technical manner; that is, a technical expert would be required to even understand the problem, not to mention fixing it. This can be a difficulty in B2B, as the person, getting the angry phone call or email from the partner that the file did not arrive, might understand the process and the data, but does not understand the technical implementation.
Sentence #2: “B2B integration? We need a dedicated solution for that?!“
In this approach, we acknowledge that in B2B there are specific requirements that make it not just another interface.
Things like trading partner management, quick onboarding, flexible change management, and business level monitoring must be taken into consideration, and standard integration tools usually do not have built-in support. When looking into different dedicated B2B solutions, they are usually very good at “traditional” B2B standards, such as EDI and SWIFT. These tools were built to support those standards, and, indeed, they do it very well. For example, to create an EDI map from EDI to ERP format is probably very simple and straightforward.
This solution seems to make sense when the specific B2B requirements of an organization are only(or mainly) around these “traditional” standards.
The challenges start to appear when dealing with B2B exchange topologies that do not conform to “traditional” standards.
Sometimes, it is just not possible to exchange information using standards like EDI. In other cases, it is not the best approach to take.
To give a real example of a recent B2B implementation for a large retailer in Europe that needed to communicate with many of its small suppliers and exchange packaging information, as part of the supply chain process. These small suppliers had very small or no IT; thus, we could not use EDI. There was a need to design a user-readable exchange format that these suppliers could consume.
The solution was based on MS Excel. All the orders from the retailer to the suppliers and the packaging information from the suppliers to the retailer were communicated using Excel spreadsheets. From the B2B solution perspective , it required very strong translation capabilities to convert ERP data (where the orders initially came from) to/from Excel.
In addition, in this approach, we can easily develop an enterprise architecture where our B2B dedicated tool will perform numerous, similar integration flows as our internal A2A integration tool, as both tools would eventually need to interface with different back-end systems.
Sentence #3: “We need a holistic approach for B2B.“
The third statement tries to combine the two approaches above.
Here, the preferred solution would be one that would enable leveraging the strong integration capabilities of a pure integration tool, while adding to it the specific capabilities required when it comes to B2B integration. A true holistic solution should take the best from each of the above approaches and package it as one solution.
This approach should make sense for large organizations that are looking to leverage in-house knowledge and resources they have already gained from internal integration projects for B2B integration as well.
To be more specific, the “core” integration capabilities that are mostly needed in B2B are:
- Flexible Data Transformation – To deal with non-standard data exchange and the emerging new standard that is XML based.
- Strong data quality functionality – This is significant in B2B (even more than in internal integration), because we cannot assume anything about the data being sent from the trading partners; thus, there is a need to carefully validate it.
- Reach backend connectivity – Data received from trading partners usually goes to various backend systems. Thus, there is a need to integrate with them in a simple and straight forward manner.
The specific “B2B Only” capabilities that are required:
- Managed file transfer – Ability to connect via different protocols with trading partners.
- Partner management a quick onboarding.
- End-to-end business level monitoring of the B2B exchange – In a simplified explanation, it knowing at every point in time what data had been sent and received from each trading partner is crucial when it comes to B2B exchange. The best solution in this regard is one interface for a real end-to-end monitoring , including managed file transfer issues.
- Industry standards support – We cannot neglect traditional B2B standard support that will simplify B2B exchange in different industry standards.
