We recently covered The Goal of SOA is managing complexity, wherein we covered the perspective of Mike "Wolf" Gilbert.
(Via Nicholas Carr)Web services,in simple terms, comprise a set of software tools and standards that allow diverse applications to talk to each other over the Internet. At a technical level, they’re an exciting and important development. As with middleware and read-anywhere programming languages like Java, web services help managers escape the maddening incompatibilities of legacy systems.
At the business level,software is used to automatically and seamlessly connect the processes of different companies, allowing the quick assembly and disassembly of entire value chains reaching from the supply of components to the delivery of finished goods. In turn, businesses evolve into increasingly specialized modules that can be easily plugged into these flexible new enterprise networks. Joined in a "service-oriented architecture," companies themselves begin to look and act like loosely coupled software applications. In an article by Andrew McAfee, a Harvard Business School professor, in the new issue of the MIT Sloan Management Review. In Will Web Services Really Transform Collaboration?, McAfee takes a scalpel to the common wisdom about web services. "If information systems could look for and find each other, share data and execute business processes, all with no (or very little) human involvement, we would probably find ourselves in a very different business world," he writes. "Web services, however, will not create this world, nor will any technology on the horizon." McAfee explains that computer-mediated collaboration between companies requires three very different kinds of agreements.
-The first and simplest are agreements on "transport"—the networking protocols that allow applications to connect.
-The second are agreements on "payload"—the data standards that allow applications to share information.
-The third and most complicated are agreements on "process"—the sequence of activities in a work flow and the allocation of responsibility for them. The problem, McAfee points out, is that web services only really automate transport agreements: "They make it possible for two applications to talk to each other[i.e., transport], but they don’t specify what conversations they should have [process] or what words they should use [payload]."
It’s possible for two or more companies to negotiate agreements about payload and process but, as always, that takes a lot of human interaction and a lot of time. McAfee describes how it took more than a year for IBM and one of its distributors to hash out the shared protocols necessary to create an automatic, computer-to-computer ordering system. Such efforts will be worthwhile for automating stable, high-value connections between the processes of large companies—the kinds of processes that used to be linked through electronic data interchange, for instance—but otherwise they’ll rarely be worth the hassle. Nicholas Carr adds, this is evidence of technologist’s fallacy. Computing professionals and pundits sometimes exhibit a tendency "to confuse business with information processing, to want to see companies as, in essence, computers. They overlook, or give short shrift to, the physical and human characteristics of commercial organizations—to all the things that can’t be reduced to digital code, that can’t be ‘exposed’ or ‘made transparent’ through networks. This skewed perception leads them to conclude that companies, like computers, can and should become components, or modules, in broad and flexible networks." Web services will play a key role in overcoming incompatibilities between information systems, helping create a more standardized and productive IT infrastructure for business. But they’re not going to usher in an age of protean value chains. And they're not going to usurp the place of managers in negotiating, overseeing and modifying complex partnerships. Machines matter, but people matter more.