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.
