Ramkumar Kothandaraman writes about some of the business-level complexities I mentioned a few weeks ago. I wrote...

Although the infrastructure is still immature, the real problems for the enterprise are at the boundary where the services architecture meets the business architecture. The real problems of heading toward a world of rich services is how to get them to play at the business level. How do you keep them agreeing on a correct chart of values, a correctpart and product hierarchy, roles and responsibilities, up-to-date with engineering change notices, etc.

As Rumkumar points out from his experience...

[It] is very easy draw service boundaries that may create data related problems later on...

things started falling apart the moment we started integrating different services. The main problem we faced was that the 'Customer' entity is required by all the systems...

So, we went down the path of building a common module (system of record) for common entities. Things worked for a while, before we got into implementing a scenario that actually required a cross-join between product entity and a related entity owned by order management service...

So, what is the solution? Here is a practical one. "Try to share the database between related services.“...

For example, think of your favorite ERP system (SAP, Peoplesoft etc) as a business service that exposes one more services - one for HR management, one for Inventory, one for Order management, one for Accounting etc. But, they all share single logical data model. Ever wondered, why big ERP systems such as SAP have a single database that contains the tables required by all the modules? I tend to think this is the reason why they did it.

This problem is not insurmountable, but neither is it easily solved. Note this problem has nothing to do with your business and my business agreeing on a common Internet data model. This problem exists solely within the intranet of your business. This is just the tip of the iceberg toward a complete "service oriented architecture".

Note also I suspect vendor consolidation will accompany the move to SOA...

These are not insurmountable. To reiterate I believe the movement toward an SOA will be preceeded by a movement to realign IT for the enterprise architecture and go hand in hand with vendor and product consolidation, and less custom development.

In part this could support "service" vendors to actually gravitate around *databases* as a coordination mechanism rather than pure services, with some services privileged to create and update certain domains of data. Realizing this from experience through vendor agreement and implementation may take some time however.