Confused about what service-oriented architecture (SOA) really means? You needn’t be, said David Chappell. All you need to do is look at what the major vendors are implementing, because in the services world, the big vendors define the market—they “rule the world.” And whether or not you understand it, SOA is coming.

At his SD West 2005 keynote speech on Wednesday, Chappell, principal of Chappell & Associates of San Francisco, told his audience that SOA is going to radically change the development world—for the better. (“And if you don’t like change,” he advised the audience, “get out of the software business!”) The major vendors have settled, he said, on a set of standards for interoperable Web services—Simple Object Access Protocol (SOAP) for the underlying communications, the so-called “WS-*” standards for the peripheral protocols—and that “the global agreement on SOAP has the potential to affect software development analogous to the adoption of TCP/IP ten years ago. The result then was enormous change, the global Internet.” In the near future, he predicts, “we’ll see that same sort of ubiquitous connectivity at the application level.” It should be no surprise that this kind of move is coming, he insisted. “We know that pretty much all software we build eventually has to talk to other software. Even lonely applications eventually make friends. Doesn’t it make sense that our default architecture should take into account from the get-go this need for connectivity in logic?” Previous attempts (CORBA, Java RMI, COM, DCOM) have failed, said Chappell, since vendors weren’t all on the same page. But Web services is different, simply because agreement exists. “After years of fighting about it, all the major vendors have finally agreed on how to expose those services.” He predicted that within three years, almost everyone in the audience would be building their applications on services.

Of course, even if all the technical issues were settled, “The real impact of this move to a service-oriented world is with people,” Chappell pointed out. How do you motivate people to make the move? For example, if one group in a company builds their applications which can be adopted by other units…what’s in it for the authors? (At a talk in Zurich, Chappell recalled, he was explaining this social process: “A guy jumped up in the front row: This is communism!”) Chappell reported that in his consulting experience, a massive top-down-directed move to a company-wide SOA would be the best choice from a technical standpoint: all the services could be developed together toward a common goal, with less time spent refactoring. “It’s the way any sane architect would approach the problem, yes?” Most information technology departments start out using a return-on-investment argument, Chappell said. “IT goes to the business, with all the credibility IT has (audience laughter), and says, ‘Mr. Business: Give us $5 million dollars—we’ll SOA the world and come back in three years with great ROI!’ Doesn’t work. SOA arguments based on ROI are DOA.” Instead, he said, in all but a tiny handful of cases, SOA adoption occurs incrementally: An application here, a database exposed as a service there. Of course, Chappell explained, such organizations spend considerable time refactoring their services, because getting services right the very first time is quite hard. Despite the resources wasted in rearchitecting downstream, Chappell observed, incremental adoption is the only realistic hope in most companies.

Chappell went on to the trend toward Business Process Management (BPM), and explained how BPM, Business Rules Engines (BREs) and Web services are entwined. “Application servers by themselves aren’t sufficient to support orchestration”, he said, noting that business process logic needs extra services not provided by traditional application servers. Again, the crucial trend is the convergence of vendor support on a common model: Web services to communicate among the business process logic, the legacy applications, and the new Web-service-enabled applications. It may even enable a new class of developer/analyst hybrid, said Chappell. The major vendors all support graphical development of the business logic that runs within their rules engines (“there’s a standard for this called Business Process Modeling Notation that nobody supports yet”, he said wryly). He stepped quickly through a graphical example of creating business logic in the diagramming notation. “But do you see objects anywhere in here?” he challenged. “Do you see classes? Inheritance?” Clearly the engine will compile it to objects under the hood, he said, but it needn’t be visible to the user. Today’s model of embedding business logic in Java or C++ or C# code is flawed, said Chappell, because the logic becomes scattered throughout source files and is hard to find—even for specialist programmers. But the advent of business rules engines, communicating via Web services and driven by graphical editors usable by nonprogrammers, is “about to go mainstream. Last year Microsoft shipped a rules engine”, he pointed out. “They don’t enter small markets.” This means, he said, that the kind of business analyst who used to work in Visual Basic (“by definition, they’re knowledgeable in the business and not afraid of technology”) will now be able to work directly strictly on the business logic that’s their specialty, rather than having to just pass requirements on to developers.

“This is the strongest force in development, the biggest thing we’re going to face, for the next several years,” he wrapped up. “If you’re open to change…welcome to the service-oriented world.”