Competitive SOA

Service reuse is at once one of the least understood and most challenging benefits of Service-Oriented Architecture (SOA). There are many roadblocks to achieving measurable return on investment (ROI) from reusing Services, both technical and organizational, but perhaps the greatest of these is the human tendency to want to have something of our own as opposed to sharing someone else’s. After all, we all learned to share in kindergarten, but we didn’t like it then, and we don’t like it now! If your own team builds a Service, it’s bound to do just what you want, while if you share one from elsewhere in the enterprise, then all bets are off.

The most familiar approach to addressing this issue and ensuring proper Service reuse is to establish effective governance — the creation, communication, and enforcement of policies, primarily for Service creation and consumption. Establish enterprise reuse policies and govern these policies as part of a comprehensive governance framework, and people will reuse Services — or else. ZapThink has spoken many times about the importance of governance, to be sure, but the fact remains that the more governance you have, the more rigid your organization becomes. And after all, no one actually likes to be governed. This innate distaste for governance is actually interfering with some organizations’ SOA efforts. Fortunately, ZapThink has an admittedly unconventional approach to resolving this anti-governance climate. What the enterprise just might need to add the requisite spoonful of sugar to the SOA governance medicine is a competitive environment for Services, especially since competition among Service implementations in the enterprise can also improve their quality as well.

Bringing Competition to Service Creation

Now, we’re not cooling on the need for governance. What we’re proposing is governance tempered by a healthy dose of competition — or even capitalism. Encourage different provider teams within the enterprise to create competitive Service implementations, and then allow the users who wish to consume those Services to shop for and choose the implementations that best meet their needs. Furthermore, provide for a bona fide payment for the provider teams’ troubles, either in the form of chargebacks to the teams’ departments, or even better, bonuses to the team members themselves.

Here’s an example of how competitive Services can address issues of governance. Let’s say you have a policy that all Service implementations must have management interfaces. This policy is familiar to anyone with a telco background, as management interfaces are de rigueur in that world — but in enterprise SOA circles, many people consider such a policy as invasive. After all, if a SOA management vendor deigned to claim that they required Service developers to change their Service interfaces for their tool to work, they’d be laughed out of the IT shop. In spite of that limitation, however, management interfaces for Service implementations are a great idea, and in any case, telco-based Software-as-a-Service (SaaS) Providers are implementing such interfaces already.

In the competitive environment, then, there’s no policy requiring management interfaces for Service implementations, but rather the policy is that Service consumers get to choose among Services, whenever there are two or more functionally identical Services to choose from. Some might have management interfaces and others won’t. The implementations without management interfaces are likely to be less expensive, but those with the interfaces will likely offer better Quality of Service (QoS) as well as other non-functional benefits. At that point, market forces will drive the relative popularity (and pricing) of the various competitive Services.

Challenges with Competitive Services

Perhaps the most obvious concern managers are likely to have about this competitive Service notion is whether creating extra, potentially superfluous Service implementations is cost effective. After all, one of the primary reasons to implement reuse as part of a SOA initiative is to reduce redundancy, and isn’t this whole competitive Service idea a plan for increasing it instead?

First, it’s important to point out that we’re not suggesting anyone fund duplicate Service creation efforts simply to create a competitive environment. Rather, we’re saying that in an environment where potentially overlapping efforts are already the norm, policies that promote competition may be more cost effective than policies that dictate reuse directly.

Secondly, it’s important to look for the optimal number of competing teams, factoring in the quality benefit of competition. Too many would clearly not be cost effective, but only one or even two such teams will be more likely to produce Services that are lower in quality overall than if there are at least three competing efforts. The ROI question then becomes how to measure the value of the better quality Services, not just taken individually, but also in terms of the impact competition will have on Service quality over time. Keep in mind that the relentless pressure to compete yields its most important benefits over time, just as in any competitive marketplace.

Another challenge organizations will face when considering a competitive approach to Service creation is how to handle the logistics of such competition. There must be a straightforward way to discover competing Services, and to make the appropriate judgment call as to which one is most appropriate for the task at hand. This evaluation may start out as a manual, design time exercise, but clearly the big win comes when automating the Service selection.

Today’s registry/repository solutions will need to rise to this challenge for competitive Services to become broadly accepted. After all, Service discovery is right up their alley already. Add the ability to compare Services and then to handle the commerce aspects of the chargebacks or payments, and these products will be good to go. The next challenge will then be establishing an approach for rating available Services based upon various criteria, but that capability may still be a ways out for the enterprise environment.

Enterprise Services and the Free Market

Once enterprises begin to look at their internally created Services competitively, it’s hardly a leap to consider business-to-business (B2B) Services the same way. And with today’s ongoing convergence of SOA and SaaS Services, there is already a nascent, yet growing B2B Service marketplace. What such Service marketplaces as yet don’t offer are sets of sufficiently similar Services to promote true competition — but this state of affairs is already changing, as the number of available B2B Services is exploding.

The rising competition among B2B Services, however, will not simply center on price. Varying functionality as well as QoS, security, and other non-functional requirements will also impact the market demand for such Services. The lesson here for Service Providers is clear: prepare to compete on all these levels, or risk losing in the open marketplace. Furthermore, the starting point for any SaaS Provider looking to compete in such an environment is SOA, since supporting the Service abstraction with the appropriate loose coupling, management, security, and reliability that SOA affords will be the critical enabler of competitive SaaS.

The ZapThink Take

The Darwinian survival-of-the-fittest language of competition might suggest that we’re promoting a laissez faire approach to Services, but nothing could be further from the truth. Just as capital markets require regulation to function properly, enterprise Services require governance as well. But while lack of governance leads to problems, so too can excessive, onerous governance. People need to have sufficient leeway of personal decision making, not just to get their jobs done, but also to maintain morale overall. Building competition into the policies that determine SOA governance can promote the proper level of flexibility into the enterprise’s governance framework. This benefit is perhaps the most subtle of the competitive SOA approach — balancing governance with user empowerment in a way that leads to steadily increasing quality over time.

A separate angle to this story is the expanding opportunity for Service Providers who wish to offer SaaS-based capabilities to the marketplace. Those Providers who currently aren’t thinking in terms of SOA are delivering tightly coupled, essentially proprietary Services — and such an approach will clearly give way to Service Providers who do go the extra mile and architect their offerings to provide standards-based, loosely coupled, governed Services based on SOA. But once they truly achieve this level of loose coupling, they have also enabled true competition, because customers will now not only be able to switch from one SaaS provider to another, they will be able to switch from one Service to another whenever they like. Is supporting this level of customer flexibility an enormous challenge for the Service Providers? Absolutely. Will they rise to the challenge? Only the ones who survive!