Might as well go for a SODA

You know the song...  I was singing it today and then somehow linked in to the fact that it is a great acronym, so I am going to use it.

Service Oriented Data Architecture - SODA

I was thinking that as we try to apply the concepts of Service Oriented Architecture in the data world we are looking to create coarse-grained business level data services that can be published and consumed unbinding us or creating an independence from sources of data.

So where can we look internally to start?  Well in some cases we have derived a master view of the following:

• Customer - Customer Master File
• Employees - Human Resources ERP systems
• Inventory in a Store
• Bill
• Account
• Location
• Organization
• and the list goes on...

I understand that this is often termed Master Data Management (MDM) and is a good catch all for saying that this is a unified view across all the business units and should also consolidate our view away from the sub-systems or entities that make up the complete view. But how do we achieve this in organizations with different requirements, priorities and viewpoints.

In a portfolio management way we could think about having teams or people dedicated to each business segment where they are always working to breakdown the silos and build the complete view for all parties.  This is an interesting opportunity for the Data Architecture teams because this creates a new master role that gets them from the plumbing side of life into the customer/consumer of data side.

Comments

[Graham Boundy]

We (the industry) have a long way to go with this. Take customer as an example. In most data models I've seen customer is represented by a number of tables and or associated tables. Any SODA Customer service would have to be aware of the level of customer we're refereing to. Is it the customer table only, or do we include address, or accounts, or household group?

While a Customer Service would provide viewing, Insert, Update, Delete, Drop, Alter, capabilities and it would also have to be Referential Integrity aware.

All this adds complexities to any "full" service we'd like to define.

Can I have some Scotch with that SODA?