Information Architects are an interesting crew.  Take everything you know and love about a person who “thinks” in data, add layers of set theory that you haven’t looked at since college, throw in a pinch of realism, a flair for idealism, and an ability to generalize things that you didn’t think could be generalized, and you get an Information Architect. 

But sometimes, that way of thinking can lead you astray. 

If we are to create an Enterprise SOA, with services that are both independent and composable, we will not succeed unless those services surround objects that make sense to the business.  Sometimes, when you generalize too freely, you create an object that cannot be understood by the business.  And while you can store the information, efficiently, you cannot manipulate it independently.

Take the concept of an invoice.  It has a header and lines and information about products.  Looks a lot like a purchase order. 

An average database engineer may tell you that you can create a table for the invoice header and put in a status flag or two.  Then you can store both invoices and purchase orders in the same structure.  Some information architects would agree.

SOA thinking says “no.”  If you are going to build an independent service, then you have to seperate the logic between services, so that there are no side effects between them.  It is nearly impossible to insure that there are no side effects between services when they store their core data in the same data structures.  Especially when you consider the temptation to place logic into stored procedures.  While you don’t have to create one set of stored procedures for one table, there is nothing in a normal database system to prevent it.  Complexity creeps in.

To seperate the logic, you have to have a good partition to seperate it on.  As any information architect can tell you, the number of different ways to represent something is close to infinite.  So you have to decide what things need to be stored, and represented, in seperate ways.

So when you are busy creating your data models, remember not to generalize too much.  If you are tempted to combine two entities, consider this: if different people create or manipulate those objects, or they have different lifecycles, resist the temptation.  Keeping things seperate on the basis of roles and processes is a good thing. 

It’s a good way to keep your independent services… independent.