• Customer Needs Analysis
• Market Entry and Competitive Strategy
• Partnership Strategy and Channel Development Programs
• Product Roadmap and Positioning Evaluation

Why UDDI Will Succeed, Quietly: Two Factors Push Web Services Forward

(April 2001) On UDDI's six-month birthday, we suggest that two aspects of the growing momentum for web services—one economic, one technical—will help make a success of the standard for registering and discovering web-based services. Bottom line, UDDI will succeed because its technical underpinnings work for the geeks. By Brent Sleeper.

There has not been a lot of vocal celebration, but the Universal Discovery, Description, and Integration (UDDI) standard recently turned six months old. Perhaps the Nasdaq's seeming freefall is causing commentators to finally turn a more skeptical eye towards the acronym-heavy technologies of the sector, but we argue that a softening economy, combined with growing support for one of UDDI's key technological foundations, actually bodes well for the initiative's success.

The standard's big-name backers (chief among them, IBM, Microsoft, and Ariba) ensure that UDDI will receive a large share of attention, and we doubt any of our readers are completely unfamiliar with it. Still, web services, and UDDI in particular, are only recently generating substantive discussion among leaders in the e-business community. Whether this lack of vocal attention is owed to its seemingly simple objective or to a healthy dose of skepticism for vendor-sponsored standards, we are not sure, but significant momentum is growing, tortoise-like, behind the scenes.

From an initial group of 36, more than 175 companies have now endorsed the initiative by contractually agreeing to "support the future development of UDDI." The group ranges from drivers of major industries like Boeing and Ford to a prominent cast of technology vendors. Notably, membership in the consortium is crossing political boundaries as competitors like Ariba and Commerce One, and Microsoft and Sun Microsystems all become involved with the UDDI project.

None of UDDI's fundamental benefits has changed radically in the past six months, yet solutions for developing and supporting web services are being announced with increasing frequency. Cynics among us might wonder what—beyond the incessant PR machines in Redmond and Silicon Valley—is driving the recent flurry of activity.

So, why are so many companies warming to such a seemingly ordinary protocol? We suggest that two major factors will drive UDDI's success:

• Business and economic conditions are right for tackling the problems that UDDI solves
• Very smart decisions drove the standard's technology underpinnings

UDDI: A Brief Refresher

The less-than-felicitous ring of the UDDI acronym belies the standard's simplicity. UDDI essentially provides for three links that have been missing in existing approaches to developing componentized, web-based services:

• A standardized, transparent mechanism for describing the service
• A simple mechanism for invoking the service
• An accessible central registry of services

Conceptually, the information provided in a UDDI business registration consists of three components: "white pages" of company contact information; "yellow pages" that categorize businesses by standard taxonomies; and "green pages" that document the technical information about services that are exposed (see Figure 1, below).

Figure 1: The UDDI Business Registry

Because UDDI's value is usually couched in this mundane language of a phone directory, it is easy to overlook how important a central registry is for a wildly distributed medium like the Internet.

As a point of illustration, consider the World Wide Web before 1994. Try to remember, if even possible, what using the web was like before a couple students at Stanford University decided to publish and continually update a directory of all the web sites they found. Yahoo! had a radical impact on how Internet users looked for information on the web and was second only to NCSA Mosaic in shaping how we all use the medium today.

Prior to the advent of Yahoo! (whose directory model was then followed by Lycos' search engine), finding information was time-consuming and depended upon the user simply knowing where to look in the first place (combined with not a small amount of serendipity). Today's haphazard approach to finding web-based services is quite similar; people implementing and connecting to remote systems must agree to protocols offline and depend upon manual documentation to make their computers and software talk to one another

UDDI promises to remove this bottleneck and significantly improve the ability of web-based software to connect to other software. Just as Yahoo! dramatically increased the efficiency of web users' ability to find information, so will UDDI's registry and nomenclature profoundly increase the efficiency of integrating web-based applications and business processes—and thus, free up valuable technical and business staff to focus on more strategic questions. As e-business increasingly moves toward an environment of machine-to-machine communication, efficient discovery of automated business processes is essential.

Astute readers will note that Yahoo! leveraged its groundbreaking directory into a multi-billion dollar market capitalization. Who, if anyone, will exercise ultimate control of the UDDI registry remains an open question. The directory of web services is itself designed to operate as a distributed web service, and the consortium's "first among equals"—Ariba, IBM and Microsoft—each operate an instance of the service. Much like the domain name system (DNS), additional operators and registrars may emerge. Much like the current debates about top-level domains and control of registry assets in the DNS infrastructure, we expect some political wrangling while UDDI's founders wrestle with the conflicting demands of retaining their leadership positions and the system's distributed architecture.

An Economic Silver Lining

What is on the mind of today's CIOs? To put it simply in James Carville's famously colorful colloquial, "it's the economy, stupid." We will not dwell on the latest earnings disappointments and layoffs in the technology sector. Instead, let it simply suffice to say that the sudden vacuum in the capital markets and the increasingly unsteady forecasts of economic seers will prompt corporate decision-makers to take increasingly defensive postures for at least the next six months.

The conventional wisdom holds that, with the Internet-fueled boom of the 1990s in the increasingly distant past, technology spending will dry up. The CIO of a major financial services company to whom we talked recently warned that his firm, normally a technology leader, will not invest in any major IT projects for the rest of the year. He argued that firms like his overbuilt in e-commerce and other technologies in anticipation of continuing explosive growth and now are watching their fixed costs very closely. This state of affairs indeed may bode poorly for infrastructure investments designed to facilitate top-line expansion.

However, this does not imply that all technology spending will vanish. Driven by an imperative to preserve the bottom line, corporate managers will continue to look for unexploited ways to increase efficiency. The very visible tech sector problems notwithstanding, we suggest that technologies that make companies trade more efficiently—enterprise application integration, supply chain management, and collaborative planning and forecasting—will receive a good deal of welcome attention over the next nine months.

Even the surprising earnings troubles at Ariba and Commerce One, whose MRO and indirect materials procurement automation technologies enable the simplest forms of automated business trade, may very well hold a silver lining for companies developing the next generation of business web services. Many of their potential customers have already plucked the lowest-hanging fruit and are now seeking efficiencies in the more complex processes that web services will enable.

Historically, technology solutions to these complex processes have been equated with wrenching, multi-year installations of monolithic enterprise resource planning (ERP) systems. Internet-based technologies are only now making inroads into a segment traditionally dominated by proprietary technologies.

It is worth taking a step back and examining why projects of this sort—be they supply chain automation, ERP, or any number of enterprise application integration (EAI) efforts—are so difficult from a technology perspective.

Simply, it is because every business process that is modeled, mapped, and automated is unique to that implementation. Sure, the code at more progressive installations may be modern, object-oriented, and reusable, but negotiating connections between systems—in programmers' parlance, specifying and documenting remote procedure calls (RPCs)—remains a one-off affair. Each time a new partner or customer enters the mix, the implementers must again manually navigate a connection.

The underlying reason is that remote procedure interfaces are not discoverable. In other words, there have not been ways to automatically query these interfaces for their capabilities, nor could systems "self-heal" and reestablish links among one another once established. Remote procedure calls are notoriously fragile and always the weakest link in any EAI initiative.

Until such business process negotiations are improved, we will continue to read about initiatives such as Nike's ill-fated supply chain automation effort. We do not necessarily blame the technology involved in this case (for the record, it was i2's), but the underlying technology paradigm must change in order to prevent future disasters like this one. Referring to the Nike situation, a GartnerGroup analyst recently projected that five percent of major companies implementing new enterprise software will experience some sort of failure in the coming year.

SOAP Lays the Foundation for Change

The status quo has served to support the position of technology platform providers looking to own the entire gamut of their customers' technology installations. Out of necessity, however, this "dictatorship of the platform" is changing very quickly in an environment of cross-organization automation. Indeed, web services promise the same vendor independence and interoperability that has made the web itself so successful.

Sun Microsystems' recent announcement of its Sun ONE web services initiative was one more indication that the companies that control today's enterprise computing—Microsoft, IBM, Sun, and Oracle—know the future of their businesses isn't in self-contained boxes, but rather in the gray space between trading partners' systems. While these platform vendors are loath to give up their oligopoly, they cannot afford to miss the web services train, and each has verbally committed to supporting some version of Simple Object Access Protocol (SOAP) interoperability in their e-business software products. Add in a wide array of interesting developments coming out of independent software vendors, and there is suddenly a critical mass of technologies built on top of SOAP, a simple, XML-based approach to linking applications over the Internet.

By nature of its simple design and forgiving syntax, SOAP helps solve the fragility of traditional RPC implementations. Not coincidentally, SOAP forms the core of the UDDI technology stack (see Figure 2, below). Rather than inventing another self-contained, monolithic solution, UDDI's backers chose instead to apply existing, accepted mechanisms to solve a specific problem. By combining the SOAP messaging layer with its own directory, the UDDI coalition made some very smart decisions about technology and synthesized a solution that is technically sound and seductively easy to implement.

Figure 2: The UDDI Technology Stack (UDDI.org, 10/2000)

Though the fear, uncertainty, and doubt sowed by Microsoft's recent announcement of its "Hailstorm" peer-to-peer web services project and other political tempests have blown through the community of independent SOAP developers, some version of the standard will survive because it is so eminently practical. Now committed, the platform vendors will not be able to unilaterally derail this momentum. SOAP's quiet march forward bodes well for the UDDI consortium's standard for establishing directories of B2B web services. In turn, adoption of UDDI will reinforce the need for ensuring the interoperability of vendor-independent protocols like SOAP.

Looking Ahead to the Advent of Web Services

Granted, UDDI by itself will not usher in a miraculous new paradigm. Even with proposed enhancements like the Web Services Description Language (WSDL; see Figure 3, below), businesses will require several additional layers of functionality and logic before web services truly will transform their trading relationships. While WSDL abstracts a particular service's various connection and messaging protocols into a high-level bundle, additional elements that support complex business rules must still be implemented to provide for automated business interactions. Indeed, we expect that mechanisms for security and authentication, contract management, quality control, and more will soon follow; we hope that these layers will reflect decisions as smart as the UDDI group's choice of SOAP.

Figure 3: Proposed Web Services Standards (InformationWeek, 4/2001)

STANDARD	ORIGIN	PURPOSE	RECENT STATUS	EXPECTED FUTURE
UDDI (Universal Description, Discovery, and Integration)	Created by Ariba, IBM, and Microsoft; Version 1.0 draft specification released in September 2000	A set of XML protocols and an infrastructure for the description and discovery of business processes	The UDDI specification hasn't yet been submitted to any standards organizations; Draft version 1.0 in use by developers	Two more draft specifications are planned before UDDI is turned over to a standards organization some time during the next 12 months.
SOAP (Simple Object Access Protocol)	Created by DevelopMentor, Microsoft, and Userland Software; Microsoft solicited industry feedback on the SOAP 0.9 specification in September 1999	An XML-based protocol for messaging and RPC-style communication between two processes	SOAP 1.1 specification simultaneously released and submitted to the World Wide Web Consortium in May 2000; SOAP 1.1 specification in use by developers	The World Wide Web Consortium's XML Protocol (XP) Working Group is working on a SOAP standard, which will be called XP
WSDL (Web Services Description language)	Created by IBM and Microsoft by merging previous proposals: SCL, SDL, and NASSL; Version 1.0 specification released in September 2000	An XML language used to describe how to connect to a Web Service.	WSDL 1.0 specification submitted to the World Wide Web Consortium in March, 2001; WSDL 1.0 specification in use by developers	The World Wide Web Consortium has not yet announced what action they will take on the WSDL submission