« Winer Nails It | Main | Salt Lake Tribune News Quiz »
The Tolerance Continuum
Dion Hitchcliffe has a nice graphic on his blog showing a tolerance continuum. Notice at the top are things like HTML, RSS and folkonomies. At the bottom are ontologies, RDF, and enterprise applications like CRM and ERP.
I spoke with Dion yesterday and he talked to me about governance mistakes he sees clients making. The number one problem is something he called the “tyranny of the ‘MUST understand’ flag.” You get a SOAP-based Web service loaded up with WS-* header elements all tagged ‘MUST understand’ and you end up with something every-bit as much a central command and control structure as if you’d just reintroduced the mainframe. No one can do anything unless they’re using the same toolset.
This isn’t exactly what we’re hoping for with SOA. We’re hoping for flexibility and agility. The answer is for the SOA architecture group—the people who are creating the design rules necessary to ensure interoperability—to be tolerant of diversity wherever they can. Here’s a set of questions I came up with to help determine whether introducing options and choice is worthwhile:
- Is there a way to support additional options or to increase choice?
- Will these options increase service independence?
- Is allowing choice likely to increase unintended and serendipitous service re-use?
- Can additional options be introduced without increasing interdependencies between services?
- Will the cost of additional choice simply be more infrastructure rather than reliability or interoperability? Another way to ask this is, will the costs be one-time or ongoing?
- Are there acceptable ways to mitigate the negative side effects of the additional options?
If the answer to these questions is “yes” then the more tolerant approach will probably serve the enterprise well.
Posted by windley on December 29, 2005 5:17 PM
Comment from Michael Neale at December 30, 2005 3:34 AM
Good points. People come up with interesting and simple concepts that just work, but then there seems to be a tendency to stratify them into impenetrable standards, which totally defeat the reason these ideas worked in the first place.
I am increasingly impressed with what you can to with simple user friendly tagging, rather then forcing precribed meta data formats on users. Let them form their own classification systems.
Comment from Dion Hinchcliffe at January 2, 2006 6:05 PM
Yes, complexity is the enemy of interoperability. And the more complex a standard or technology is, the less reliable it is, and the less likely it will be used.
Like George Morimisato, co-author of Microsoft' new SSE standard says, "the chance of a standard being adopted is inversely proportional to its complexity."
More details complexity and SOA here:
http://web2.wsj2.com/web_20_and_soa_power_panel_on_syscon_tv.htm
Comment from Robin Mulkers at January 4, 2006 7:51 AM
Hi Phil,
If tolerance is about supporting several formats for the same piece of data, it might not decrease but increase the service complexity or you will end up with string only generic attributes in service definitions that are less meaningful unless you read the attached “how-to-use” or “readme-first” documentation file.
Service reuse and flexibility should not be enabled at the cost of a less strongly typed nature of the interface the service offers (ex: a service returning an array of key/value pairs à la SDO instead of a real element with attributes defined in the XML schema). The service interface should reflect the complete functional nature of the message flowing in/out of the service.
But between the lines of your post, I can read also that tolerance is about backward compatibility. On that point, I fully agree, services in SOA will evolve over time, reflecting the new consumer needs. This evolution must be as smooth as possible and must prevent a situation where one code base of each reused service is maintained for each client. Because it is against the original goal of service reuse in a SOA.
This is all about change management in SOA http://blogs.ittoolbox.com/eai/applications/archives/006451.asp