B2B Web Services Set for 2005 Blast Off

J Scott Bushey, a principal solutions developer with Avanade, shares why his firm see strong demand for B2B-based web services solutions, designed to better integrate partner networks. See why tapping into his 3 key trends in EDI/VAN modernization will create huge opportunities for architects and developers.

Tags: Web Services, Supply Chain, Trading Partner, Community, Standards, EDI, Global Supply Chain,

Principal solutions developer, Avanade

For all the talk in 2004 of sending IT jobs outside the U.S., there are signs that in 2005 the outsourcing of manufacturing to low-cost producers may in fact create opportunities for IT architects and developers skilled in the art of Web Services-based integration.

Despite sending aspects of manufacturing offshore for the past decade, the well-oiled "global supply chain" remains elusive. And that's where the 2005 opportunities for industrial-strength Web Services lie.

Let's take a look at today's realities.

Today's "Global" Supply Chain Myth
Just how global is today's supply chain?

According to a Deloitte Touche Tohmatsu study, more than half of North American and European companies surveyed had moved production to lower-cost countries. Yet the survey showed most of these manufacturers were still organizing supply chains by the decades-old approach -- product, function, facility, country or region.*

Add to that phenomenon the prevalence of EDI (Electronic Data Interchange) and VANs (Value Added Networks) for global supply chain communications, and it's not so surprising that so many firms' global supply chains are fragmented. Take a closer look at today's e-commerce supply chain infrastructure, and you'll get a better idea of the problems -- and the opportunities.

For decades, EDI has dictated the industry-specific software formats (and company-specific handshakes) for electronic communication among trading partners. VANs provided the secure communication infrastructure - literally, phone lines enhanced with security and other services.

Over the years, all this customization made EDI a "standard" in principle only, as each link in the global supply chain had to cope with its own special set of technical, software and security issues.

This meant the "global supply chain" was not one seamless end-to-end corridor for secure e-commerce, but instead was comprised of long, interconnected supply chains, that discreet manufacturers managed as clusters of links. Any cost and labor efficiencies - much less automation - were sacrificed to dedicated, costly relationship and "standards" management.

Building Next Generation Supply Chains
For 2005, watch for Web services to bring more pieces into place to enable more seamless integration of global supply chains. VANs are rapidly evolving from their origins in network technology, to more cost-effective forms using Web services.

These next-generation VAN-driven networks also promise to smooth today's EDI software disparities resulting from trading partners' EDI formats. The vision is that supply chain participants could continue to use the enterprise applications they prefer, and expose them to their partners' systems, as needed.

Since few companies have experience with integration across organizations, there's a risk that IT teams will simply perpetuate the evidence of disconnection found by Deloitte. But with some strategic planning - and observance of useful lessons from EDI, companies can establish a functional trading partner community using Web services now, and enhance it later.

Web Services Integration -- Taking a Page from EDI
Relationship management is crucial at the outset of any effort to use Web services to connect the supply chain. It doesn't have to take up staff time - but trading partners will need to agree on some rules of engagement. They'll help ensure some degree of standardization - important for interoperability. On the non-technical side, successful relationship management also depends on making sure they have a mechanism for reaching a final decision.

EDI has traditionally tapped the largest participant to serve as the final decision-maker. That's because it's most often the customer that most needs its vendors to be connected. So, at the outset, today's most successful EDI architectures have the decision-maker as the "hub" of interaction, while other participants become "spokes."

Setting and agreeing to these rules are important because once in place, Web services can use them to keep partners "on the same page" by smoothing over differences in technology, platform, and experience. Setting up the rules in advance makes it easier for other companies to join in the future, too.

Here are three Guiding Principals (or Best Practices) from EDI that could benefit architects and developers looking to design and deploy a Web services trading partner network.

3 Keys To Web Services Trading Partner Success
Through trial and error, EDI has shown successful supply chain interaction rests on three points: a standards base, interoperability, and low barriers to entry for new participants. When one of these three elements is missing, IT staff often must intervene to salvage an exchange between customer and supplier systems. With all three points built in from the start, next-generation trading partner communities are more likely to flourish.

1. Standards
Setting standards for several aspects of interaction can make a huge difference in the launch and success of a trading partner community. These elements include what data will be exchanged, its format, transport mechanism(s) used to communicate it, relevant interfaces to other participants' systems, and overall approach to implementation.

Fortunately, web services standards can help eliminate some of the haggling over definitions. The fundamentals of a basic web service have already been defined by the major players in the technology industry who comprise the Web Services Interoperability Organization (WS-I): WS-I Basic Profile 1.0 addresses web service elements including messaging, service description and service publication and discovery.

There may be vertical industry standards that can streamline negotiation of some aspects of trading partner interaction, as well. These may include business process standards and even specific message schema. By incorporating pre-tested industry specifications, trading partners can focus on choosing tools and defining conditions for minimum conformance.

However, it's advisable to steer clear of "horizontal" business process specifications in the early stages of community formation; standards for services like advanced security measures can be added once the community is up and running. Most important, participants should take a hard line against exceptions. Non-conformance simply risks the complexity that characterizes EDI and VANs.

2. Interoperability
Choosing standards does not necessarily guarantee that once work begins, code will function and systems will successfully exchange data. In fact, it's possible for participants to use extensive scripting to generate code that doesn't actually implement Web services.

So in the beginning, frequent communication is a must. It will help with a handful of obstacles likely to pop up because IT environments have never been built with external interaction as a primary function. For example, without access to trading partners' infrastructure, work may be stopped by firewall settings, server permissions, and network and machine administration.

Just as important to communication is some way to track errors. Participants will need something more than the time of the problem, since some errors will prevent an action from taking place.

3. Low Barriers to Entry
It's tempting to try to build the ideal trading community with Web services - but its success is probably better served by a quick launch of basic functions than the perfect implementation. Since standards and interoperability require the skills to implement them, it's extremely important to design the project to accommodate trading partners' capabilities and even certain aspects of their infrastructure.

Lessons learned from EDI suggest the community "hub" should lead the way in gauging participants' skills. The group's choice of standards and technology - as well as the project timetable - should reflect the reality of participants' capabilities.

That could mean companies with greater Web services savvy provide some form of support to those with less experience. It may also determine the format of Web services to be deployed: Document-literal exchanges just specify content and format, and their smaller payload makes them easier to implement than remote procedure call (RPC) Web services that invoke action on data.

The group also should note individual participants' IT platforms and infrastructure capabilities. An inventory of participants' operating systems can help anticipate whether the community will need to integrate multiple platforms and define aspects of Web services collaboration so that they can be supported easily by all partners - instead of delaying community launch. Then a timetable can be set to encourage the "lowest common denominator" to upgrade infrastructure support for more advanced operations.

Beyond 2005 -- Web Services' Impact on EDI/VANs?
Long-term, Web services may have some interesting and compelling ramifications for IT staff that support the supply chain. Analyst firm ZapThink posits the rebirth of VANs in the form of Web services-enabled networks, or WSVANs, that could handle some aspects of service oriented architecture - security, reliability, policy, and even some data integration. The firm envisions that companies would connect to the WSVAN, provide a service request along with reliability and security requirements, and then the network would do the rest.**

Whether or not this vision becomes reality, Web services can help reduce the complexity of trading partner interactions over the long term - and it's a smart time to start building what EDI had promised.

J. Scott Bushey is a principal solutions developer at Avanade Inc., a technology integrator for Microsoft solutions in the enterprise. He is responsible for architecting and developing .NET solutions, focusing on Web services. Founded in April 2000 as a joint venture between Accenture and Microsoft, Avanade has helped more than 1,000 companies unlock the value of the Microsoft enterprise product suite. Today, Avanade has 2,000 employees around the world, serving customers from 30 locations.

*Deloitte Touche Tohmatsu, "The Challenge of Complexity in Global Manufacturing: Critical Trends in Supply Chain Management," (June 2003).
** Ronald Schmelzer, "Resurrecting the VAN: The Web services network," ZapThink LLC (Feb. 9, 2004).