In my last post, I commented on the continued use of legacy communications protocols such as async, bisync and X.25 for B2B e-commerce. I have never seen an official report on the use of legacy communications in B2B integration. However, I am confident there are over 10,000 companies are still using legacy dial-up connections. In this post, I want to continue the discussion exploring the implications of the business community’s continued use of these ancient technologies. I also want to explore the roles of commercial entities and government regulators in phasing out these legacy communications protocols.
Who and Why?
The primary users of async, bisync and X.25 are small businesses that established EDI programs over a decade ago and see no benefit in upgrading to newer technology. These companies are still running EDI software on a Windows 95-based PC and a dial-up connection to their VAN provider. Many of these companies running the older technology do not even know what async or bisync is. They just know that the PC sitting in the corner automatically phones home every night and magically retrieve all of their purchase orders.
Why don’t these customers upgrade to newer technology? Most small businesses lack the resources, budget and technology expertise to upgrade to a newer B2B communications protocol such as AS2 or FTP. Furthermore, most are reluctant to make changes to their EDI configuration for fear of disrupting electronic commerce with customers. Would you want to be the EDI manager who was responsible for losing a $2M order from Wal-Mart during a cutover from bisync to AS2?
Challenges of Legacy Communications in B2B
Does it matter that so many businesses are still using legacy communications technology for B2B? That is a subject of significant debate. But I have listed below a few disadvantages of such pervasive use of the older technologies:
- Business Disruption – In the early days of EDI, communications functionality was bundled into desktop software packages. Many of the developers of these early EDI translator packages no longer offer support for the older software. Consequently, if the older software breaks then there is a significant risk that users will not be able to quickly remedy the problem. The result could be a disruption to order flow with trading partners, which could have a ripple effect across the value chain.
- Limited Functionality – Users of legacy communications technology are only able to conduct the types of B2B transactions supported by the original EDI software package. In most cases, the older software does not support the newer XML schemas introduced in recent years to support automating a wider range of business processes. Consequently, the ability to develop more collaborative business processes between buyers and suppliers is constrained by legacy technology.
- Outdated Information – Users of legacy communications tend to operate in an off-line batch mode. EDI documents are exchanged with the VAN once a day or sometimes once a week. Consequently, these companies receive updates to orders, forecasts, shipments and bank balances only once a day or once a week. The overall supply chain becomes less agile when companies cannot exchange order, logistics, inventory and payment data in near-real time to respond to changing market conditions.
Why consider a Regulatory Approach?
There have been several attempts by industry to force technology upgrades each of which have failed:
- Lower Cost Substitutes – The advent of the Internet in the late 1990s introduced a number of substitute technologies that small businesses could use for EDI such as AS2, FTP and Web Forms. Despite aggressive sales efforts by vendors, there remains a significant population of small businesses unwilling to upgrade their B2B technology.
- Product End of Life – Commercial service providers such as the major telecommunications carriers have discontinued support for legacy protocols such as X.25, async and bisync. However, carrier efforts have been handicapped by their large customers, which have trading partners still using the legacy protocols. These corporations are major buyers of telecom services that use their purchasing power to negotiate extensions to the end-of-life to the legacy B2B protocols.
- Pricing Deterrents – A number of VAN providers have attempted to raise the prices of async and bisync dial-up services in an attempt to encourage customers to transition to more modern communications protocols. The new pricing models of VAN providers met with considerable outrage from the end-user community. Ultimately, the service providers were forced to abandon the pricing policies and extend indefinite support periods for the older communications.
With vendor-led efforts to drive technology upgrades failing, it seems that the only remaining alternative might be public policy. Or we could accept the fact that bisync will be alive and well in 2015, 2020 or maybe even 2050. Should the FCC impose an end-of-life date for legacy B2B communications protocols? Should there be government subsidies to enable upgrades to AS2 and FTP? Post your thoughts and let me know what you think.
2 Responses to “Bisync 2020 – The Case for FCC Regulation of B2B Communications”
[...] Perhaps, most interesting to me is the ability of the French and German banking sectors to decommission the legacy protocols. BCS is scheduled for phase-out by the end of 2010 and ETEBAC will be discontinued in 2011. I find it interesting to contrast the rapid migration to EBICS in Europe to the seemingly never-ending extension of dial-up protocols in the US. There are still tens of thousands of companies in the US retail and manufacturing sectors relying upon communications protocols such as LU 6.2, SNA, asynchronous and bisynchronous dial-up for the exchange of mission-critical commercial documents. The French and German governments, no doubt, accelerated the migration, which makes we wonder why a similar approach by the US FCC to eliminate bisync would not be appropriate. [...]
Hi Steve
I saw this – and it is very interesting – but the one thing that you are overlooking is very simple. No customer left behind.
The 10,000 or so customers who aren’t changing from legacy communications (some of which are very important applications – like core systems for major companies) bisync or async or SNA or x.25 – is not because they don’t want too – but that it doensn’t make business sense to trade in a link that works 100% of the time with technology that only works 80-90% of the time and some times not at all.
When the macro policy was developed that 90% of the work is in the last 10% of the project – and we just will rush our product to market – forget about the 10% that gets lost in the shuffle – works great for 90% of the transactions – but what about the 10% that falls thru the cracks – we don’t care about that?
It is like saying that there is an acceptable statistical rate of casualties in war – great – if it is not your credit card transaction that gets lost – or airplane reservation – or wire transfer – or purchase order from Walmart
There is a reason GXS leaves no customer behind. It makes good business sense.