A degree of tolerance for SOA

A degree of tolerance for SOA Service Oriented Architecture - When the application is low-risk, developers need less rather than more rules to enable innovation - By Phillip J. Windley

Governance, like service oriented architecture SOA itself, comes with its own catch-22: You want to create a broad-based, modularized IT environment that supports unprecedented agility, but you can't possibly anticipate every variation -- nor can you create policies that take into account every feasible future scenario.

That's where the idea of "tolerance" comes in. For service oriented architecture SOA applications that involve actual business transactions, you need careful, detailed rules and formal change management. But in other instances, exemplified by a number of Web 2.0-style apps, developers should be able to get creative without being smacked down by some architectural committee.

Take CheapGas, a great site for finding the gas stations in your neighborhood with the cheapest gas. CheapGas is a "mash-up" of Google Maps and data from another site, GasBuddy.com. Unlike most enterprise-level Web services, CheapGas exists without much governance at all. There are some necessary standards, such as HTTP and Google Maps API, but nothing resembling the stack of WS-* protocols that could accompany some mission-critical enterprise apps.

Dion Hitchcliffe, CTO of Sphere of Influence, remarks that "90 percent of the time if you're presented with a service with data in it, it's going to be RSS, not SOAP." That's no accident: RSS delivered over HTTP is a remarkably tolerant format. SOAP has its place, but often a simpler, more tolerant approach will deliver results sooner and with more opportunities for reuse. Where you use one or the other depends on the application and the level of risk you can tolerate.

In Design Rules, their groundbreaking book on modularity, Carliss Baldwin and Kim Clark describe how architecture "free[s] designers to experiment with different approaches" within the design rules of the architecture. They argue that this experimentation yields tremendous value. Conversely, governance that is overly strict can tie the hands of developers and drive value out of your service oriented architecture SOA effort.

One issue requiring governance might involve choosing a standard for security tokens. Should you support SAML, Kerberos, or something else? An alternate approach could be tolerance of different security token formats, which would require installing or licensing a token exchange service.

Tolerant protocols and processes aren't at odds with governance; they're complementary, but the more tolerant your service, the less governance you'll need to create robust systems. The ultimate reward of well-designed services is that they get used in unintended and serendipitous ways, making them more useful than their designers could have imagined. This kind of reuse is the real promise of service oriented architecture SOA.