Resurrecting the VAN: The Web services network
by Ronald Schmelzer, Senior Analyst, ZapThink, LLC
Both software vendors and enterprise end-users have always
looked to make business-to-business interactions automated, reliable, and secure. While many companies currently seek a set of products and specifications that improve B2B interactions, many large firms will tell you that they've been accomplishing the goals of reliable, secure, guaranteed interaction between companies for decades, in the form of Electronic Data Interchange (EDI). However, it's not EDI's technology (which today is both arcane and obsolete), but rather its infrastructure that's given it such longevity. We're talking about the Value-Added Network (VAN) here – a set of capabilities offered by third-party network providers to guarantee the required level of interaction between any two participants on the network.
This was first published in February 2004
A third-party "network" for Web services
In the 1980s, companies found that their primary challenge in trying to automate their business connections was managing point-to-point electronic relationships with dozens or even hundreds of suppliers. The VANs emerged as a means to provide basic connectivity between supply chain participants in the form of store-and-forward mailboxes that provided protocol conversion, security, and guaranteed delivery. However, the EDI VANs left a sour taste in the mouths of many companies due to their steep implementation costs, monthly line charges, and per-transaction fees that racked up as the number of interactions increased. Then the Internet and the Web came along and specifications like ebXML emerged, with the hopes of speedily bringing the demise of EDI and the VAN.
But now that Web services have emerged, many companies realize that the while the VANs are technologically and economically inferior to standards-based, service-oriented approaches, they offer a compelling business model for providing guaranteed and secure interactions between businesses. As a result, we're seeing a resurgence in the popularity of the business model that was the Value-Added Network. The EDI VAN business model has evolved to become the Web services Value-Added Network (WSVAN).
In many ways, the WSVAN is similar to the EDI VAN and has to meet many of the requirements and features that the system offered to EDI users. What makes a WSVAN compelling in a Web services scenario is that by utilizing a trusted intermediary network, individual endpoint participants can delegate the security, reliability, and robustness aspects of delivery to the WSVAN, thus keeping their Web services lightweight and simple in design. What makes a WSVAN superior to the EDI VAN, however, is that the technology used is based on standards-based, loosely coupled, coarse grained, asynchronous service-oriented architectures that ZapThink talks about so frequently in its research.
VANs for the masses?
Another key problem of traditional EDI VANs is that their cost structure made them prohibitively expensive to implement for the majority of businesses. Only the largest of supply chain firms could afford the costly set up fees associated with complex EDI software tools, and the exorbitant per-transaction fees that quickly racked up. As a result of these high costs, many small and medium-sized firms simply could not afford to participate in the electronic, automated supply chains of their larger trading partners. Without their participation, the value of these electronic trading networks were dubious indeed – companies simply could not replace their paper-based processes with electronic ones because they still had to support the small firms who could not afford to connect electronically.
WSVANs hope to change this fundamental flaw of the EDI VAN by significantly reducing the cost of connecting to and participating in a third-party service network. WSVANs promise significant economies of scale and skill by offering to shift the complexity of managing critical aspects of an SOA (security, reliability, policy, and aspects of information integration) to the network. Companies simply connect to the WSVAN, provide the network with information about the services it requests and its required level of reliability and security, and the network does its best to meet these requirements. In addition, WSVANs allow users to roll out new services incrementally, without requiring that an organization adopt SOAs or even Web services in any part of its IT infrastructure.
Most importantly, WSVANs fill a critical role in the SOA picture: simplifying loose coupling. Since the WSVAN is physically hosted outside the walls of the enterprise, any company looking to expose or consume services from the WSVAN will necessarily have to abstract the services in a way that's loosely coupled from the underlying transport, implementation, and even location. And so, WSVANs are most compelling to those companies that want to realize the value of SOAs but can't make the move for budgetary or philosophical reasons. In essence, the WSVAN becomes a hosted SOA.
No more software?
If taken to an extreme, companies might come to the conclusion that with a WSVAN that fills the role of a hosted SOA they have no need at all for any software that aims to solve integration challenges. If that company's integration challenges were all externally-facing, then sure, perhaps a WSVAN would solve all their integration problems. However, as ZapThink discusses frequently in its research on service-oriented integration, integration challenges abound in many different forms behind a company's firewall. Integration in fact is not a single problem, but a spectrum of different concerns: application integration, information integration, semantic integration, and more. WSVANs aim to solve specific aspects of integration: application and information integration between companies. The remainder of the integration issues still need to be dealt with using the SOA approaches that ZapThink covers in its ongoing research.
More importantly, using a WSVAN to simplify B2B integration does not obviate the need to build SOAs. Companies that desire the business benefits of increased business agility, process-driven services, and standards-based communication still need to move their internal systems to Web services-based SOAs. Utilizing WSVANs will certainly simplify some aspects of building cross-organizational SOAs, but they will not remove their need entirely. As such, companies considering WSVANs should explore their own plans to move to an SOA and understand the timing of when to adopt such network approaches.
Where goes the WSVAN Market?
A number of companies are innovating different parts of the Web services VAN picture. And while many of them would argue (quite vigorously) that they are in fact not a VAN from a strict technology and economic stance, they in fact do mirror many of the business value propositions that VANs offer companies. In fact, there are three kinds of companies that are all seeking to build the value proposition of the WSVAN:
ZapThink sees that WSVANs are in fact evidence of the continued evolution of SOAs. They represent an approach to implementing many of the hard aspects of getting SOAs to work in cross-organizational scenarios without requiring significant investment in their implementation. However, WSVANs, like all integration products and services, are limited to specific integration scenarios. For companies looking to realize the value that the EDI VANs once promised without the technological, economical, and business problems that they posed would find the emerging class of WSVAN offerings compelling and nothing like their older counterparts.
Copyright 2004. Originally published by ZapThink LLC, reprinted with permission. ZapThink LLC provides quality, high-value, focused research, analysis, and insight on emerging technologies that will have a high impact on the way business will be run in the future. To register for a free e-mail subscription to ZapFlash, click here.
For more information:
This was first published in February 2004