Tag Archives: Interoperability
Calling My ERP Friends: Seamless Network Interoperability As The Next Evolution Of B2B Networks
Imagine you meet a new friend who you want to communicate with regularly. That sounds easy, right? But, instead of just selecting her name on your phone and contacting her, your telco provider says you first have to create a “flight plan” – a list of all your new friends sorted by 1) their value (meaning what’s in for you and your friend), and 2) the technical effort it takes to connect. Unfortunately, your new friend is No. 21 on the list. That makes her part of the third wave to be “onboarded.” But, even before the first wave, there has to be a pilot to test the best way(s) to get in touch with your friends. And, once wave three starts, a communication consultant will get in touch with her on your behalf to tell her she will have to contract with your telco provider before the two of you can communicate.
In private life, this scenario sounds crazy. In the world of B2B communication, this is how it often works.
In a B2B scenario, regular communication between trading partners is a key success factor. Sharing forecasts, commitments, production plans, stock-on-hand details, and end-to-end procure-to-pay communication avoids surprises and disruptions and ensures a high level of transparency, agility, and process efficiency.
For many years, one-to-one Electronic Data Exchange (EDI) for integrated electronic B2B communication as well as on-premises supplier portals was the state-of-the-art technology. However, technical setup, maintenance, and support costs were fairly high and, depending on the industry, prevented the technology from adding significant value for users.

Figure 1: Traditional, one-to-one connections between companies have reached a level of complexity that is difficult and expensive to handle. As a result, suppliers hesitate to introduce new connections.
In the past 10 years, multiple B2B collaboration networks have evolved. B2B collaboration networks are cloud platforms that offer multiple ways to connect and also support manual or electronic communication with the cloud platform. The key advantage of those networks is the ability to connect just once to communicate with multiple trading partners. Most of those networks have a focus area (either a specific business area, such as procurement or logistics, or a specific industry), and trading partners are fairly distributed across those networks.
Figure 2: Cloud collaboration platforms allow a company to connect once and communicate with all trading partners on the network.
In order to drive value for the companies collaborating via such a network, the number of connected trading partners is the key success criteria. Unfortunately, convincing trading partners to join a new network takes months, if not years, because they have to connect to multiple communication channels, which drives process complexity and costs.
Figure 3: Suppliers still must connect to multiple collaboration platforms (e.g., in case supplier C and D would like to collaborate with company A and B).
Consequently, suppliers and customers are heavily pushing network operators to connect their networks, enabling interoperability between the networks so the trading partners can stay on the network of their choice and still transact with all their customers. As a result, network providers can establish things like value-added network (VAN) tunnels and field maps between the networks so every message can be transmitted and translated easily from one network to another.
This approach shows incredible results in terms of supplier adoption and onboarding time. Furthermore, the rate of electronically integrated processes (driving process efficiency and compliance) is much higher compared to net new onboardings, which often start with web graphical user interface-driven, manual processes.
There are several reasons for success:
- The network of networks (NEON) approach truly fulfills the connect-once promise. Besides some additional potential legal and commercial agreements, the supplier can continue to use its network of choice.
- Companies have almost immediate access to all trading partners connected on the networks and can run robust B2B collaboration processes within a matter of days.
- There’s no need to convince and educate suppliers in regards to how to connect to and maintain a new network.
- Issues can be resolved quickly, as the network providers speak to each other directly.
- There’s no need to build up additional backend integration for orders, forecasts, track and trace, etc., as a supplier’s backend systems (ERP, planning, engineering, etc.) typically would already be well integrated into its network of choice.
The flipside is related to the fact that there’s no standard method of interoperability. These network-to-network connections will always look different in terms of:
- Technical connectivity protocols and formats
- Business rules: Many networks will send out a reminder in case of an overdue order response or an alert in case a goods receipt does not match the original order. Those rules need to be aligned between the networks, so it’s clear who informs who in case of a disruption.
- Electronic invoice compliance: In the event that both networks can create legal electronic invoices, one network would have to step back.
- Support models: Support workflows could be different for a network A and B combination compared to a network C and B combination.
- SLAs (e.g., response times, uptimes, etc.) and security aspects (e.g., support of International Traffic in Arms Regulations, or ITAR, compliance)
- Commercial and legal aspects: For example, some networks charge suppliers, some charge customers, some are transaction-based, some are spend-based.
Last, but not least, while the technical aspects of the NEON approach can be solved quite easily, misalignments in terms of processes are harder to solve. Think about a supplier-managed inventory (SMI) process: It is fairly easy to technically share forecasts and stock levels, but it is more difficult to come to an agreement about process workflows, responsibilities, and liabilities.
Still, what we see in the market is that the benefits of connecting once overlay the potential negative aspects. There are more and more success stories of where a procurement and supply chain collaboration network interoperates with industry networks.
Making it as easy as possible for trading partners to communicate with their customers is the key success criteria to drive value in terms of process efficiency and working capital at minimal IT costs. Interoperability between networks is the next evolutionary step to enable companies to interoperate seamlessly, in just the way you would get in touch with a friend.
The Ariba Network is supporting the approach of network interoperability and established network connections to multiple industry and solution-specific networks so that customers not only have access to more than 4 million suppliers directly connected to the Ariba Network, but also to suppliers connected to other networks.
OpenStack’s next challenge: interoperability
Since its inception, OpenStack – the open source platform for cloud computing – has been out to prove that it is capable of hosting mission-critical enterprise workloads.
Earlier this year at the OpenStack Summit in Austin, it received just such validation, with analysts and customers agreeing that the platform is ready for prime time, as more than half of the OpenStack projects moved from proof of concept to production.
So what’s the next major goal for OpenStack?
The answer came at the OpenStack Summit in Barcelona, during the Wednesday keynote by Jonathan Bryce, executive director of the OpenStack Foundation.
According to Bryce, the next hurdle is application portability, not just between various distributions of OpenStack – there are easily three dozen of those already – but also, somewhat surprisingly, between OpenStack and third-party services like AWS, Azure, SoftLayer and Google Cloud.
“To me, it’s very clear that the future is multi-cloud,” Bryce said.
Source: Max Smolaks, DCD
Interop Challenge at OpenStack Summit 2016, Barcelona
A rising tide
Six months ago in Austin, Don Rippert, IBM’s general manager for Cloud Strategy, Business Development and Technology, issued an interesting challenge – he asked community members to try and run the same applications and automation tools across as many different OpenStack distributions as possible.
The challenge involved deploying the LAMP stack – traditional foundation of countless online services – using Ansible and Shade, as well as running a Docker Swarm cluster.
In Barcelona, the challenge culminated in a live demo in front of 5,000 attendees of the summit. It featured representatives of 16 organizations, each running their own flavor of OpenStack or their own type of cloud service, and yet achieving the same result. This marked the first time someone has demonstrated the proof of interoperablebility among various OpenStack environments at such a grand scale.
Participants included AT&T, Canonical, Cisco, DreamHost, Deutsche Telekom, Fujitsu, HPE, Huawei, IBM, Intel, Linaro, Mirantis, OSIC, OVH, Rackspace, Red Hat, SUSE and VMware. And the instance deployed by Linaro was based on a 64-bit ARM server.
“When I talk to customers that are looking at OpenStack, or using OpenStack, or are really using any major open source project, they want three things that they think distinguish the open source approach from proprietary approach,” Rippert said.
“They seek additional innovation based on the community, and looking at the problem from a different direction. They expect better integration, since we each know what the code does and we can handle the code itself. And they expect interoperability – they expect that three vendors, five vendors, 16 vendors are all offering an OpenStack platform, and their workloads will run across all of those platforms.
“The one area of doubt, for our customers and some industry analysts, is interoperability. Will the vendors allow interoperability? Or is it in their best interests to make anyone on their distribution stay on that distribution?
“It is really not in our best interest. Because the way we gather momentum around cloud in general and OpenStack in particular, is by being interoperable. Yes, we compete with each other, all 16 of those companies up there, and we will continue to compete with each other. But you know, a rising tide gives us more surface area to compete in. We have all the reasons at IBM to think we can win more than we are going to lose, and I’m sure everyone on that stage thought the same way.”
In Barcelona, the OpenStack Foundation also announced continued progress of the ‘OpenStack Powered’ program, which requires relevant products and services to run interoperability tests in order to carry the OpenStack brand. There are now 46 products and services meeting such standards.
But the real interoperability work is yet to begin– the long-term objective for the community is to achieve a situation where customers can easily move their OpenStack workloads into proprietary clouds and back again. The key here is standard APIs. Of course, the OpenStack Foundation can’t force a company like Amazon to adopt its APIs, but if there’s a will, there’s a way – like the exotic solution recently developed by Platform 9 and described as “stretching imagination” by Bryce.
“Multi-cloud is not just about OpenStack clouds – it’s really about all of these cloud technologies providing the resources and capacity that users need to get what they want done,” he said.
“So I want you to think about APIs, think about multi-cloud, think about AWS and the different ways to tie those together. That could be a very interesting thought exercise, right?”