Oddly enough, this blog post is to remind me of a discussion I had with a friend tonight about SOA;

Here's one to not tackle after pork, sausage, squash and cabbage (no, really! *burp*): Does it count if it is not over SOAP Web Services?  What if your services are in the same app domain as in a plugin architecture?

The benchmark I lean on here is:  If our systems agree on schema & contract over classes & data then we are on the path to SOA.

Which brings us back to Jean Paul de Sousa.  The story of the small ISV in the corporate space can be -to lean on a canonical example- recieving a requiment like: Here's our definition of "The Customer" <insert schema here>. 

The good news is for the ISV maybe I don't care how you store your customer, so long as the system boundaries talk with respect to the agreed on schema for a customer.  The bad news is for, again to pick on a common example, what if wearing the ISV hat I store the customer_name as one field, however "The Customer" definition has it as first_name & last_name.

As the ISV, the temptation is to split our customer_name field at the service boundary translation code on the first occurance of space, so that "John Smith" becomes "John" "Smith".  "Jean Paul de Sousa" however should be split on the second space! 

My ETL experience and ponderings, coupled with the non-trivial digestion task I am faced with, bring me to the conclusion that this isn't a new problem at all!  Just a new place for an old problem to live.  Awesome.  Schema and contract it is ;-D

Listening To: Almost Crimes by Broken Social Scene from You Forgot it in People