Time To Invest In Service Oriented Architecture

I don’t think it was any coincidence that five out of six of the case studies presented at the May 15-16 InfoWorld Service Oriented Architecture [SOA] Executive Forum in New York City represented activity in the services supply chain (by the way, the next SOA forum is scheduled for November 2007).

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 they also support their back offices and supplier/client-contact 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.

In making investment decisions, there is no reason to assume a faster uptake of SOA 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 (see the Research 2.0 June monthly for more detail), 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, which 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 is very granular.

1) In SOA theory, there will one day be—for example—a single universal “city” service that (1.) 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), (2.) 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 (3.) 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. And the change will also cascade out to any other service that inherited any of the first service’s characteristics, an “Address Line” service for example, that inherited the zip code algorithms.

2) In reality, granular services such as for each line in a user record are a ways off. 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’ correct name/address/phone record in one place.

• There is an 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 (ACN) and E&Y’s of the world.

If you combine the not unexpected, historically consistent 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, Progress (PRGS) and Iona (IONA) look interesting; 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 high flyer will break into the existing (highly compacted) pack of application players.
So 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 new important player and Siebel already claimed that role in the CRM category. Salesforce.com could just as easily turn out to be Baan.

Instead, 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 (the city and address line services). I haven’t yet seen that company, which will be more a software publisher than a software developer. I could be convinced that it’s Salesforce.com. But that’s because of its AppExchange and related platform rather than its CRM functionality. Such a revised business plan could move salesforce.com back to triple-digit growth.

Comments

[Sr. Pessimist:]

I agree with the article. Software services, like web services, make software service delivery easier. Plus, I'm against calling software a "good." It's intangible, in its operative form. So it doesn't align correctly to distribute it as if it were a "good" when it's more of a design of service. It ultimately becomes uncompetitive (or anticompetitive just to survive a little longer, like Microsoft).

2007 May 30 03:26 PM