• Main Site
• About Us
• Contact Us

SOA adoption about what we expect: In its infancy and more services supply chain than product

Posted on May 18, 2007

I don’t think it was any coincidence that five out of six of the case studies presented at this week’s InfoWorld Service Oriented Architecture (SOA) Executive Forum in New York City (next scheduled for November 2007) represented activity in the services supply chain. Unlike manufacturers and distributors, banks, service bureaus, the transportation industry, and so forth not only automate the key processes in their flagship services delivery flow but also support their back offices and supplier/client-contactfor year points. Historically, service providers look first to IT for a leg up on competition.

For that reason, I look to the services industries to gauge the uptake of SOA. Enterprises that provide service for a living seem to “get it” when it comes to something called “service oriented.”

• They understand the importance of service level agreements in real life so they understand it in terms of its IT meaning.

• They build their businesses on applying the same technique to multiple different situations, using the same subset of techniques in multiple points of a client engagement, and reusing techniques in multiple engagements for the same client as well as in work for multiple clients. That’s polymorphism, encapsulation and inheritance in an SOA discussion.

• They understand the need to respond when you get a call. IT folks call that client/server (C/S).

In addition, for those investors who feel an asynchronous bus mechanism is a mandatory element in SOA, the service industry understands that concept as well. That’s what the dispatcher or senior partner does.

What I heard at the InfoWorld conference was that SOA is coming along at about the pace I would expect: about five years behind the PR hype (to which I admit contributing when I was an IDC analyst).

Not to worry; C/S grew at a similar pace. For example:

• The buzz around C/S started in the late 1980s but it was 2000 before C/S-based packaged apps’ revenue exceeded that of monolithic packaged apps (including annual maintenance fees).

• In-house-developed C/S apps, based on tools such as Powersoft, permeated business more quickly.

There is no reason to assume a faster uptake of SOA in making investment decisions, or to be disappointed by its adoption rate. Although we have been talking about SOA for years, the first SOA-based packaged applications are just now beginning to ship. It will be a decade before they dominate application market revenue flows. In addition to the technology challenges inherent in SOA (granularity of decomposition, scale, security, and so forth), enterprises have to deal with their own application ROI/retirement cycles and business issues—such as the timing of new services and products—that have nothing directly to do with IT.

Of the three companies I heard present at the Forum, there were some interesting points that might spell investment success or failure for SOA early movers.

Two of the three users were approaching SOA from the portal perspective rather than a Big Bang approach.

To the extent SOA is being adopted today, prior to SOA-based packaged applications being available in quantity, it involves the use of SOA tools and infrastructure. That means it involves decomposing in-house-developed C/S applications that are now as much as 10 years old at the user interface (UI) level. Based on this very small sample (and discussions with other users), concentrating on the UI seems to be a preferred method. One of these users went with the Big Bang approach of laying in a bus first, but as with many users I speak with, the bus is only initially supporting a discrete need as opposed to the whole company.

In terms of decomposition accomplishments, none of the users are really into anything too granular yet.

(That is true of the packaged application suppliers as well.) In SOA theory, there will one day be—for example—a single universal “city” service that handles address format in different countries (discriminating among state or province, zip or other postal code, and so forth and ‘displaying’ the result correctly for that country), ties the related address to GPS coordinates to clarify which exact city is being referenced (correctly choosing between San Jose, CA and San Jose, Costa Rica, for example), and even ties the city to various tax-calculation or other geopolitical-related “services.” In theory, every application will use this “City” service (why reinvent the wheel) as appropriate. When the service gets updated because a tax changed or a postal code moved, since all applications “call” that one service, what you change once, “runs” everywhere.

But the change will also cascade out to any other service that inherited any of its characteristics, an “Address Line” service for example, that inherited the zip code algorithms. In reality however, most enterprises are still trying to figure out who their customers are and to find some way to be sure they are storing each customers’ name/address/phone record in one place. Very granular services such as for each line in a user record are a ways off.

There is a historically consistent role for consultants.

The three companies were using consultants as well as their own staffs to implement SOA so there is some hope yet for a BPR reprise among the Accenture’s and E&Y’s of the world

If you combine the not unexpected pace of SOA adoption with what the users said, you need to be looking at infrastructure (i.e., middleware, BI) players first. Who is the Powersoft of the SOA era? If you think the portal perspective will prevail, then this game is over. When acquired by BEA (BEAS) two years ago, Plumtree was the last man standing. But success for the portal perspective approach might help drive BEA to the next level. If like many you believe that an enterprise service bus (ESB) is a prerequisite of SOA success, might the SOA infrastructure winner perhaps hail from the same Massachusetts county in which Powersoft grew (before being acquired by Sybase)? Progress (PRGS) and Iona (IONA)—nominally—are based there; Iona got into the ESB market recently by acquiring LogicBlaze. But I do not want to write off those other Irish guys nor discount the possibility that Software AG (TecDAX, ISIN DE 0003304002 / SOW), or Sun (SUNW) could use their ESB efforts to engineer another growth spurt.

Next year, just as C/S-based packaged apps lagged C/S-based in-house development, it will be time to invest in SOA on the applications side. SOA-based packaged apps are not an incremental opportunity with all of the implications in that statement that I described here. So it is very likely that only one real new screamer will break into the existing (highly compacted) pack of application players.

Looking at examples from each of the last three decades, who is the SAP (SAP), PeopleSoft or Siebel of the SOA era?

Some would say it’s Salesforce.com (CRM), but I think it is much too early to make that call. Each functional area (customer automation in this case) tends to produce only one screamer and Siebel already “screamed” in this category. Salesforce.com could just as easily turn out to be Baan. I am betting on the guy who figures out how to market hundreds or even thousands of universal services such as the two I described above. I haven’t yet seen that company, which will be more publisher than developer. I could be convinced that it’s Salesforce.com, because of its AppExchange and related platform rather than its functionality. Such an event could move the company back to triple-digit growth. –Dennis Byron

Tags: enterprise service bus, SOA, service oriented architecture, portal

Comments