The reality of Web services

Andrew McAfee, an associate professor in the technology and operations management unit at Harvard Business School, has been studying who uses Web services and why. More interesting, perhaps, are his insights into why using Web services remains hard. In a recent article in HBS Working Knowledge, Sara Grant interviewed McAfee.

McAfee says "It is in fact getting easier to integrate applications, but it's never going to be easy. There are two reasons for this: one technical; one organizational." The technical reason is semantic mismatch, although McAfee doesn't use that term; he says "dissimilar data and ...dissimilar business processes."

Here's an example of semantic mismatch: two tax services may have identical syntax for their input and output, but one calculates income tax while the other calculates sales tax. Discovery is primarily syntactic, so this, and less difficult problems, makes matching Web services difficult. Before you can integrate systems, you have to discover semantic mismatches and solve the data impedances (dissimilar formats for similar data) that are bound to exist.

There are certainly things that can be done to solve these problems, but before you get too sanguine that all these problems will melt away, bear in mind that we've had programming language syntax down cold for 35 years, but programming language semantics is still very much an open issue.

The political issues are just as problematic. McAfee gives some examples of simple questions that can lead to big disputes:

• Who's got the real customer contact information? Who gets to access it? Who gets to update it?
• What's the last day for bookings in each quarter? Is it the same all around the world?
• Do we have to do a credit check before scheduling every order for production?
• Who gets to certify approved vendors? What's the process for adding a vendor to the list?

I can think of a lot more. When I was CIO for Utah, these kinds of questions were a daily occurrence and one of the primary barriers to greater adoption of eGovernment. I devoted fully one-third of my upcoming book on digital identity to solving these kinds of problems. Almost everything I discuss is equally applicable to Web services.

McAfee suggests that there are some questions a CIO should ask before starting a Web services project. Surprisingly, ROI is not among them. Says McAfee:

Notice that this list of questions does not include anything about cost savings or ROI. I just don't think there are crisp and meaningful ways to do these calculations. This doesn't mean, of course, that a company shouldn't try to minimize costs and identify benefits; it means that it's not smart to focus from the start on cost savings, then get upset when they don't materialize quickly enough.

What should you ask? Here are some of McAfee's suggestions:

• Who are we doing this with and are they in this for the long haul?
• How are we going to reach agreement with them about shared data and business processes?
• What's the first set of interactions that we're going to automate, and what are the next ones?
• What do we eventually hope to achieve by using this technology?

You may think these questions are primarily about linking to external partners, but in all but the smallest companies, these same questions, and others, will have to be asked even about internal projects.

Reading McAfee may leave you thinking that every Web services project is going to be a huge political battle. It needn't be if you put proper governance processes in place from the start. After any pilots to prove the concept, take the time to formalize how disputes and disagreements will be settled and who has authority to make definitive statements. Establish joint rules and agreements about the process. If you ensure the first decisions you make are about how you'll make future decisions, the whole relationship will run much more smoothly.