sapienti sat: Making SOA Ready for the Enterprise

Asking the eternal rhetorical questions

I recently came across a really interesting post JaBoWS is the Enemy of Enterprise SOA by Nick Malik from Microsoft. And I could not resist to comment on it. Nick was kind enough to reply with the most detailed and relevant comment I ever got, and as I started my counter-reply I realized that is deserves its own entry, so I will be posting trackbacks to both comment streams.

It seems that the gist of Nick's response was to build a case for a common (presumably across the entire enterprise) information model. Such a model would be a Really Good Thing. So good in fact, that only a mean argumentative person like myself, would ever even try to argue against it. But like other similarly Good Things (e.g. the Word Peace or the Enterprise Data Model from the 90s) it would be very hard (read - impossible) to achieve in practice for any non-trivial set of circumstances. So what shall one do - give up? No, I do not think so. A solution that I have built and would recommend to the rest of the world is Refinement - if you look at that post, I actually provided some use cases that fairly similar to the one which Nick have proposed.

So if one has the luxury of time and resources to stop the onslaught SOA in their organization while the experts analyze all the requirements and define a common information model to end all ambiguities - congratulations, you found a perfect solution to this really difficult problem. If, however, you live in the world with the rest of us and this is not an option, then perhaps the imperfect solution of Alpha building the original set of services based on their understanding of the world and just a dash of common sense and Bravo evaluating each service for a "fit" and taking the appropriate action might work just as well. Once the degree of fit and the impedance mismatch are clear, they will have a number of options:

1. to reuse the service as-is /* which I believe would be very rare */,
2. to reuse the functionality and define their own non-functional characteristics /* also too good to be common in non-trivial cases */,
3. reuse most of the functionality by refining the existing service with their own Refining Method(s) /* this is where I see the bulk of cases */,
4. evolve the service though versioning to serve the now expanded set of requirements /* this would be fairly common as well but require a higher degree of coordination between Alpha and Bravo and thus greater level of SOA Maturity across the organization */,
5.  or make an informed and responsible decision not to reuse, which, if you look at it from this prospective, is not a bad choice at all.

And a viable SOA Governance platform would allow them to make any of those choices (and to change their mind later) through its Service Virtualization, Versioning and Refinement capabilities. So going back to my argument that SOA Governance is what separates Enterprise SOA from JaBoWS and other cheap imitations, since I take the broadest possible view of the governance that includes all those things, I believe it still stands. For more on where in my view SOA Governance ends (or does not) have a look at this post.

And finally, in response to the second comment – no, I do not believe that a successful implementation of SOA governance (by the way, I was referring not just to design-time governance, but to the entire thing including analysis- and run-time as well) requires adherence to an enterprise wide information model or any other hard-to-achieve practices. And with regards to the non-functional characteristics I was referring to versus the System Quality Attributes as described here - I believe they are quite different. The latter represent the -ilities that are primarily of interest to the technical side of the house (architects, developers, operations and the rest of IT), while the former represent the things that are of interest to business today. And while there might be some overlap: e.g. security and availability are likely to end up in both sets, I doubt that SOX compliance (or, say, Patriotism or Political Correctness if our legislators ever get their way and codify them as regulatory requirements for businesses to adhere) will ever make it to the first list, and Maintainability or Portability into the second. Furthermore, I emphasized the word today to highlight the fact that governable non-functional characteristics are very fluid and are likely to change with time, geography or vertical, the set of -ilities is quite stable and I have not noticed significant changes since I started thinking about those things in early 90s.

Now that we have established what Enterprise SOA is, shall we just go and build it?