You've just gone to your CIO with a plan to implement your IT organization's high-profile B2B "Project X" using Web services. Your CIO patiently listens while you explain the benefits of using third-party Web services as part of your mission-critical infrastructure, how contracts will be negotiated electronically without the need for pesky legal departments, how everyone will outsource all their security and management to providers they never need to meet in person, and how applications will dynamically assemble and modify themselves as your needs change.

You confidently sit back, smile, and wait for your CIO to give his inevitable nod of approval. It's only natural - after all, this model works just like the electric grid but with software services. After a few moments of thought, your CIO's head begins to nod. But wait, his head is nodding side to side, not up and down! The CIO is rejecting your proposal. How could this happen?

The reality is that adopting an emerging technology like Web services is risky business in the eyes of a CIO. To convince your CIO to adopt Web services, the short-term and long-term rewards have to be clear and the risks have to be manageable. You know it's in the best interest of your organization to move to Web services, but others don't share your foresight. In this article, we'll give you the tools you need to sell your organization on adopting Web services. Just remember though - you need to prove you can walk before you're allowed to run.

The first place to deploy Web services is within the enterprise, not across enterprises. This allows you to have total control over every aspect of the project, to manage the risk and ensure its success. What kinds of inside-the-enterprise projects are best suited to showcasing the benefits of Web services? Web services are all about connecting systems together, so integration projects are the right place to focus. Typically, a great starting point is a project with a Web front end that needs to access one or more other IT systems - portal projects, intranet Web sites, call center applications, etc. These projects are a great fit for Web services since they leverage its tight fit with existing Web technologies such as HTTP, XSL-T, and HTML.

The Evolution of Integration
You find an integration project well-suited to the use of Web services. You propose using Web services on this project and are told, "We've been doing integration for years without Web services, why do we need them now?" Best practices in integration have changed rapidly in recent years, and different models for integration have different trade-offs. It's easy for someone to be confused - so let's walk through the different models for integration: point-to-point, centralized, and backbone.

Point-to-point: The "Classic Coke" of Integration.
Point-to-point integrations have been going on since IT began. You know the type: "For my project, I need to connect system A's purchasing with system B's inventory management, so we'll just hand-code what we need right now to make this work." Even though point-to-point is the oldest way of integrating, it's still the most common for a few simple reasons: when projects are treated independently of each other, point-to-point is the cheapest solution for any given project and often the fastest way to get that individual project done. In addition, it puts total control in the project owner's hands with in-house resources and tools.

The downside of point-to-point integration is apparent when you look at the "big picture." If all projects are treated independently of one another, how can you possibly optimize your costs and productivity globally, across your projects? The answer is that you can't. Over time, a series of independent point-to-point integration projects breed a fragile spaghetti of application interconnections with no reuse among projects. Over the long run, you end up spending more and taking longer to get the job done while ending up with a brittle enterprise infrastructure (see Figure 1).

Centralized Integration: The "New Coke" of Integration
More recently, a few enterprising vendors realized the limitations of point-to-point and proposed a new twist on integration: instead of connecting applications directly together, put in a middleman "integration solution" (see Figure 2). The applications connect in a point-to-point fashion with the integration solution, but never directly to each other. This isolates the applications from changes in one another and provides a single point of control and reuse over all integrations - resulting in lower long-term overall costs.

Unfortunately, the strength of a centralized model is also its crucial weakness. Integration solutions suffer from the "first car builds the road" syndrome: the first integration project to attempt to use the integration solution is saddled with the bulk of the cost in both software and services. And, since you are "buying for the enterprise" rather than "buying for the project," the initial costs are very high. In addition, since the solutions are vendor-specific, the skills needed to build integrations are scarce, and the cost and delivery time of any individual project ends up being significantly more than with a point-to-point solution. And the projects themselves typically are done with outside resources or resources under the control of a central authority (because of the necessary skill sets), significantly reducing your control and increasing your risk.

To compound the problem, to get the long-term benefit from an integration solution you must standardize on one vendor's proprietary solution - a significant point of long-term risk and cost. Imagine the vendor is bought or goes out of business; your infrastructure might need to be totally replaced. Or, imagine you merge with another company; this means converting their infrastructure to your integration solution to gain back the benefits. Implementation of integration solutions often becomes the project that never ends.

For many of these reasons, single-vendor proprietary integration solutions are struggling now that the Internet bubble days of "infrastructure at any cost" are over.

Backbone Integration: The Choice of a New Generation?
Not exactly the new kid on the block, backbone integration has taken place for many years and is the benchmark integration model for large organizations. Most large financial service firms, for example, have application communication backbones. Instead of specifying a single platform or solution through which applications communicate (creating a centralization burden and risk), a backbone is formed by defining a set of standards through which applications communicate - distributing the responsibility for following the standards to each application group, division, or project (see Figure 3).

Typical backbones include standards for transport, protocol, encoding, description, location, and sometimes even data semantics. Any application that obeys these common standards is, by definition, "on the backbone." By having multiple applications obey these common standards, any application on the backbone can now communicate directly with any other application on the backbone.

A backbone model has a number of significant advantages. It allows for a clear division of responsibility. It requires no single vendor or point of failure/risk. Backbones provide reuse of integration points across projects. Backbones scale effectively to the largest, most complex IT environments on the planet.

With all of these enterprise advantages, though, how do backbones work at the project level? With the right tools in place, backbone-based integrations are as fast and cost-effective to implement on a project-by-project basis as point-to-point integrations - precisely because backbones are built incrementally on a project-by-project basis.

All the advantages and none of the problems - why doesn't everyone do integration using an integration backbone? The answer is hidden in the last paragraph: "with the right tools in place...." Large IT organizations have the resources to custom-build the tools, frameworks, and infrastructure needed for the organization's custom backbone standards. Once these tools are built they can be effectively leveraged across the entire organization to dramatically reduce integration cost and time - but the cost of building a good custom toolset is typically prohibitive for all but the largest organizations.

What About Web Services?
Web services are a collection of related Web standards for transport (HTTP, SMTP), protocol (SOAP), encoding (XML), description (XSD, WSDL), and location (UDDI). Essentially, Web services form a core set of backbone standards - an "out-of-the-box" backbone.

Web services give you the standards, but the magic equation for forming a backbone is backbone = standards + tools; what about the tools? Because of its broad industry adoption, this is where Web services shine. By the end of this year most, if not all, tools and platforms will support Web services. Today, you can choose Web services-enabled tools such as Visual Studio .NET or Borland JBuilder. You can choose Web services-enabled platforms such as .NET Server, BEA WebLogic, or IBM WebSphere. If you want to leverage your existing tools, you can use free or open-source technologies such as the Microsoft SOAP toolkit or Apache SOAP. The choices are limitless.

But, beyond tools and platforms, most packaged application vendors have announced support for Web services. This means that, once available, these applications will plug almost directly into a Web services backbone with no custom coding - something not possible with custom backbones.

Web services are a set of standards and tools that make backbone integration available to every organization, large and small. With the tools readily available, a Web services backbone can be built up incrementally, on a project-by-project basis, without the need for a "big bang" implementation. This essentially lets you begin deploying Web services as part of point-to-point integration projects, and then seamlessly scale these up to a complete Web-services backbone.

Of course, you have the option to define a custom set of standards for building a backbone, so let's recap why Web services form the most effective choice for a backbone: