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.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

9 thoughts on “SOA drives an odd data model”
  1. I agree. In short (generalized): data should be modeled within the boundaries of a service. This principle helps in determining the right level of granularity of the services. Also data persistency should be organized within the boundaries of a service. This may lead to redundant data as an architectural principle, which is right to maintain independency. Event driven architecture priciples are at the basis of keeping the redundant data in sync.  

  2. Nick

    I have been wondering for while whether SOA should come up with different data models than traditional applications.  My thought was that the data structures may be driven by the message formats but that you might get to the same data model in the end.  Your example points out a problem with this theory.  Well done.

  3. Nick,

    Thanks for this posting. This is a topic I feel has seen too few blog posts. Beeing one of the ordinary breathers this is a question that confuses a lot of us. I really would like to see concrete examples of a couple of service’s data models along with the services operations and if data redundancy exist within these models how data is kept synchronized?

    I think this would be very useful for “the masses” to get a concrete view of what a service model could look like.

  4. Hi Robin,

    You know… you are right.  When my current crush is over, I’ll pull out some items and make them available as examples.  

    I’ll see if I can describe the principles that I work with to allow those examples to be reusable.

    — Nick

Leave a Reply

Your email address will not be published. Required fields are marked *

five + sixteen =

This site uses Akismet to reduce spam. Learn how your comment data is processed.