Most of the major providers of development platforms have already started shipping development tools for Web services. It seems inevitable that everyone will jump on the Web services bandwagon in the not-so-distant future.

However, in the minds of many there are still lingering questions: Why bother? What can I do with Web services that I couldn't do before? And maybe even more relevant: How can I do it better?

This month we'll examine how Web services can help companies cut costs, create new revenue sources, and ultimately improve their bottom lines. As part of this discussion, we'll reintroduce a term that's once again in the hearts and minds of all IT executives: ROI - Return on Investment. We'll look at both sides of the equation, "return" as well as "investment."

Ultimately, companies will measure ROI for Web services by looking at the various kinds of software packages that utilize them, but this article focuses on the more generic characteristics of the technology itself. Also, instead of looking at distant next-generation business models, we'll focus on the pragmatic realities of today.

The Integration Challenge
Cheaper
Admittedly, integration of heterogeneous and previously unrelated systems is a nightmare, and a costly one at that. Besides the political and cultural issues involved (just staying within the corporate walls), there's also a significant technical challenge to cope with. Numerous systems, all utilizing different means to support integration, have to be addressed.

COM/DCOM, CORBA, or a MOM (message-oriented middleware) are just a few of the approaches to choose from. Many existing systems don't work with any of these well-known integration technologies, however, forcing us to resort to methods such as screen scraping as a last hope. This situation leads to a very diverse back-end integration architecture that's inflexible and expensive to maintain.

The situation for integration across multiple enterprises is even more complex. Work across the extended enterprise needs to overcome the diversity of systems that's a magnitude higher than the already complex case of integration of systems inside the firewall. Integration across corporate boundaries is best accomplished using technology that allows us to use the most pervasive piece of infrastructure we've developed over the course of the last few years - HTTP. Yet this technology should not be dependent on particular transport protocols, offering the flexibility to cooperate with existing infrastructures within enterprises.

Another core technology for next-generation integration is WSDL, the Web Services Definition Language, which allows us to provide a standards-based way of defining our interfaces, including parameter names and valid data types. Instead of dealing with very diverse (and often incompatible) ways of describing interfaces, now there can be one, dramatically reducing the complexity of our integration. Services, described in WSDL format and accessible via Internet-based protocols (such as SOAP/http), will allow us to cut costs considerably from an integration perspective.This might not be seen so much on a small scale, but will certainly be apparent if we envision that our services will be consumed by multiple applications and integrated into the system of multiple business partners (customers or suppliers). Just as with traditional integration broker technologies and their associated ROI metrics, the more interfaces need to be integrated, the more such a universal "access bus" will pay off.

While Web services now let you get to the data, you'll still have to deal with data-mapping between the various systems, as we haven't yet standardized on the actual business objects themselves. The mapping problem between business objects is significant, as the layout of records can be quite diverse and complex. There may be differing and sometimes conflicting business rules in the mix as well. Eventually, this problem will have to be addressed by some generic horizontal standards and more specialized vertical ones. Even then, you still have to map inzternally to these objects unless you use them already at the core of your schemas - which is unlikely unless you are building the system from scratch.

Faster
Here's where Web services really shine. Mapping problems aside, it takes just a few quick seconds to pick a WSDL file and integrate the respective service into your environment by using the appropriate software.

Compare this to writing specific integration code for every back-end system and for every application that you need to integrate a particular back-end system into (not to mention the testing effort).

The code used to do this can be quite simple. I've developed similar code as a piece of software from an enterprise portal perspective in a number of days - and I'm not the world's best programmer (that's why I have to write about ROI).

Return - The Upside Challenge
Customer Satisfaction
As illusive and intangible as the notion of improved customer service may seem, happy customers do translate directly into revenue. Web services will enable us to create new and diversified products and deliver them to our customers in a faster and more cost-efficient way. How? Because, as discussed in the previous section, they allow us to rapidly create new applications that consist, to a large extent, of already existing application services (both internal and external).

Business Integration Across the Extended Enterprise
While the dynamic creation of business relationships through Web services is promising and sounds like an opportunity for exciting new business models, there's another, more immediate benefit to be realized. As a result of their "integrative nature," Web services make it easier for companies to link to their business partner's systems, and in doing so they actually become a part of their partner's core business processes. This holds true regardless of whether the link is a machine-to-machine type of integration or a more interactive portal.

For example, a well-developed set of Web services can be integrated into our customers' intranet and thus further help to establish a long-term and beneficial business relationship further increasing the chance of us, as an "integrated supplier," closing business before others can.

Software as a Service
Lastly, offering software as a service (and charging for it) is going to be an exciting model to look at for revenue generation. This kind of revenue generation requires a separate discussion, though.

Beyond ROI
Especially in a belt-tightening economy, investments will be scrutinized for their expected tangible returns. However, as we look at these calculations we must not forget that infrastructure investments such as Web services also have a strong long-term strategic component that must be taken into consideration.

Increased flexibility in our enterprise backbone, including a library of reusable software components as Web services, will often be hard to measure but should nevertheless also be part of a balanced project proposal and part of a company's long-term competitive plan. The same holds true for the ability to extend the reach of services beyond the browser to cell phones as well as PDAs.

Agility
We live in a dynamic world. Change and new customer requirements are the norm, not the exception. Competitive pressures force us to change our system's designs on a regular basis.

Web services - if done correctly - will provide us with a toolbox of services (internal ones as well as external ones) from which we'll be able to pick and choose the components needed to satisfy new requirements.

Thinking about intranet or extranet portals (just to emphasize again that Web services are not just machine-to-machine technology), the flexibility provided by this new technology will allow us to react to changing requirements and build new or modified portal workspaces in a much more dynamic fashion.

One note of caution, though: this assumes all the services you need are available and are sufficiently parameterized to be used in multiple contexts as well.

Investment
There is no return without investment. The investment required for Web services is potentially considerable. What are some of the factors (besides the associated costs for the software you use)?

Paradigm Shift In the past we have architected and developed systems in a fairly controlled way. We analyzed a business problem, wrote the specification, and developed to that specification (and hopefully tested along the way). While many of the core objects of the system were often developed with reusability in mind, the degrees of adaptability were limited to the minimal level demanded by the targeted solution.

For Web services to truly work we must develop business objects that are highly parameterized and configurable to support the reuse envisioned by the brave Web services pioneers. Furthermore, we need to keep these services at the level of business objects and services rather than lower-level system services.

In general, Web services may also bring with them a stronger focus on modeling than before. This will result in a need to utilize a new skill set that may be brought into your organization through training or new personnel. So, what's the net? Architects and developers will have to learn new tools and think about new development patterns. This in itself can require major training efforts that are often costly (the training itself plus lost productivity during the time of the training).

Convert Applications to Services
This is where the rubber meets the road. Certainly, the new tools in the marketplace will make it easier to convert existing business objects and functions to Web services. That said, there'll be a few important factors to consider.

Internally, you may have developed some applications you want to convert to the new paradigm. As we've learned through the Y2K experience, reengineering is not as simple as it sounds. At the very least, it's time- and cost- intensive.

Externally, many packaged application vendors will take some time to convert their interfaces to Web services. That also will require upgrading to a new release, which in itself is a costly and time-intensive undertaking (just think about how long it took for many vendors to adopt normal Web-based interfaces).

Conclusion
As with many of the other major paradigm shifts, there will be costs and risks involved to be able to harvest all the returns. The benefits, however, of Web services, tangible or more strategic in nature, warrant an investment in this new technology.

What approach did you use to sell the idea of Web services inside your company? Please e-mail me to let me know.