Burton Group: Why Bust Data Silos When You Can Bridge Them?

Loraine Lawson

Data silos are inevitable, according to Lyn Robison of the Burton Group. Silos are a natural part of decentralized IT systems, he argues, existing not just because of decentralized information systems, but because of the departments, groups and teams that are part of everyday, enterprise life.


He makes a good point:


"It's important to realize that traditional approaches to this problem have not fixed the data silo problem. Service-oriented architecture or enterprise-wide software applications won't eradicate silos. Really, Silo busting is a fool's errand."


Therefore, instead of fighting a losing battle by trying to eliminate silos, IT divisions should instead focus silo-bridging, argues Robison.


In two recent blog posts, Robison outlines his case for bridging, rather than eliminating, silos. It's called MODS-Methodology for Overcoming Data Silos-and he says it's a ground-breaking approach for bridging silos and delivering integration information from decentralized systems, without the usual integration rigamarole.


Robison compares MODS to a library's card catalog system. In case you've forgotten, a card catalog was a series of cards about a book. The card catalog was arranged alphabetically, and included a subject, title and author card on each book. Each of these cards would give you the book's reference number so you could find it in the library stacks.


The key thing to remember here, as Robison points out, is that the library did not move all the books into the card catalog-which is basically how integration typically works-it just told you where to find the books.


Likewise, MODS requires a registry of all key enterprise data, but the registry simply tells you where you can find instances of that data. Meanwhile, the data stays decentralized, in its silo.


You can also think about MODS as a "project-based approach to MDM and data integration," with each MODS project consisting of scoping a topic and five steps:


  1. Model to understand the type, which includes understanding the data you have and the data you need on a particular topic.
  2. Identify to track individual instances, which involves creating a registry that contains a master list of of instances on the topic.
  3. Classify the data, which defines who can see what.
  4. Convey, or automate the delivery of information on the topic based on services. He specifically mentions that this will probably entail using REST, instead of SOAP, so users can access it via a browser.
  5. Control, which means applying the appropriate security to your automatic delivery systems.


How would this theory play out in practice? In "Data Integration that can actually Work," Robison points out that UPS basically uses this approach to manage information about shipping. Rather than trying to create one huge system to house all information about a parcel, UPS identifies each parcel and then uses that identifier to track the parcel across all its system silos.


To learn more about MODS, you can check out "A Data Management Freebie," in which Robison introduces MODS. It includes several key background links, but the bulk of the information is in an embedded webinar explaining MODS and how to get started with this approach.


The Burton Group is also giving away-for now-"Delivering Integrated Information from Data Silos Using MODS." This white paper, written by Robison, was published June 25 of this year, so it's up-to-date information about the Burton Group's MODS approach for managing data.


You'll need to register to download it, but that's a simple process.


MODS isn't meant to be a magic solution, Robison writes. But, he explains in the webinar, they "are ideal for today's it environment in that they are inexpensive, they are low-risk and they deliver compelling results for the business."


And at the compelling price of free, it's an approach worth checking out for your business.

Add Comment      Leave a comment on this blog post
Jul 1, 2009 1:09 AM Loraine Lawson Loraine Lawson  says: in response to MEllard

Good questions. I'll scan through the free report. You might want to as well.

Jul 1, 2009 12:46 PM MEllard MEllard  says:

Can you elaborate a bit on what this approach means for data quality, governance etc. costs over time? While you avoid the expense of centralizing everything at the get go - doesn't it also end up costly to get all these disparate systems on the same page - and keep them there? More silos seem like more opportunity for errors, redundancy, outdated info, etc. - not to mention that system upgrades/changes will thus continue to keep happening across the organization rather than centrally?  Curious to understand this better. Thanks.

Jul 6, 2009 8:41 AM Lyn Robison Lyn Robison  says: in response to Loraine Lawson

I hope you don't mind me jumping in here. You have to combine this concept of silo bridging with stringent application portfolio management. IOW, you need to keep (or reduce) the number of silos to the bare minimum. Minimizing the number of silos and then bridging the ones you can't get rid of is really your best and only option. Feel free to contact me via my blog at http://dmsblog.burtongroup.com/data_management_strategie/mods/


--Lyn Robison

Jul 10, 2009 10:11 AM John O'Gorman John O'Gorman  says: in response to Lyn Robison

I'll add a quarter's worth if I may...

The establishment of a central registry - especially if it is organized as a semantically oriented reference hub (think along the lines of a Rosetta Stone) begins to negate the need for so many silos. When, as Lyn suggests in his paper on MODS, you begin to assign 'Application of Record' status, the silos that were built to circumvent these should either begin to disappear on their own or be mandated out of existence.

The approach leads to, believe it or not, a relatively small controlled vocabulary with a still small but substantially larger number of managed associations. You'll be amazed how stable these are.

The other thing you start to see is a new balance between operational applications and the common information that connects and integrates them.

John O'Gorman

Jul 13, 2009 1:55 AM John O'Gorman John O'Gorman  says: in response to Jan Herd

Re: MODS (2)

Interesting illustration of the problem Lyn is trying to solve...

MODS in Lyn's case is an acronym for "Methodology for Overcoming Data Silos"

MODS in Jan's case is an acronym for "Metadata Object Description Schema"

This is one use case in my framework - where two identical strings have completely different interpretations. Another use case is for the opposite situation: where two different strings reference the exact same object. Lyn's article has a couple of examples of this, but these happen all the time in localization or cross-discipline vocabularies.

John O'

Jul 13, 2009 12:35 PM Jan Herd Jan Herd  says:

Are you aware of the MODS standard which was devised by The Library of Congress Standards Office?

see http://www.loc.gov/standards/mods/mods-schemas.html


Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.