Blog post

2013 Data Resolution: Avoid Architectural Cul-de-Sacs

By Merv Adrian | December 27, 2012 | 4 Comments

DBMSdata warehouseData Integration
I had an inquiry today from a client using packaged software for a business system that is built on a proprietary, non-relational datastore (in this case an object-oriented DBMS.) They have an older version of the product – having “failed” with a recent upgrade attempt.
The client contacted me to ask about ways to integrate this OODBMS-based system with others in their environment. They said the vendor-provided utilities were not very good and hard to use, and the vendor has not given them any confidence it will improve. The few staff programmers who have learned enough internals have already built a number of one-off connections using multiple methods, and were looking for a more generalizable way to create a layer for other systems to use when they need data from the underlying database. They expect more such requests, and foresee chaos, challenges hiring and retaining people with the right skills, and cycles of increasing cost and operational complexity.
My reply: “you’re absolutely right.”
Their only recourse, absent utilities that can extract data when needed (via federation, virtualization or distributed processing models as identified in Gartner’s Information Capabilities Framework), is to build and materialize an intermediate datastore – ODS- or DW-style. That means an exhaustive effort to anticipate all likely future requests for data. It’s unlikely they will be able to do so, and any change to that system will be as difficult as the one-offs they build now. They could literally recreate the entire database in an alternative architecture that their other systems can access via conventional methods, but the cost of building and maintaining such a redundant “layer” might rival replacement cost.
Thus, my conclusion: their vendor has demonstrated itself to be an architectural cul-de-sac they might want to consider exiting. If you have any similar systems in your portfolio, here’s a New Years’ resolution for you: back out of that dead end. As soon as you can.

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • Bruno Aziza says:

    Merv – great post and I’m happy to read about a “data liberation resolution” for your clients.

    The situation you are describing is so common, it’s not even funny. We see it everyday – I could almost guess the vendor you are referring to…it’s got to be one of the ‘3-letter-word’ ones…

    Anyways…why did the client want to extract the data? Analytics?

    Analytically Yours,
    Bruno Aziza
    VP Marketing,

  • Merv,

    Great topic and it’s something we see all the time. These older, operational systems truly represent the VARIETY challenges of Big Data. It’s a common theme…the source data is diverse, and doesn’t fall into neat relational structures for analytics.

    Today, our customers routinely access this data (and data from outside the walls of the company) by transforming the operational reports that come out of these applications. These reports are a business critical information asset that have been tested and audited for accuracy, especially in public companies.

    By transforming the report data (from file) and using it as a data source, our users usurp the complexities described in your post, and get immediate gratification from the report and the “point in time” calculations that only exist in the report itself.


    Jon Pilkington
    VP of Products – Datawatch

  • @Merv, if there was a set of open (or at least, published) APIs, of any kind, to access either the app’s objects, or the underlying database, a custom connector could be built for a data integration tool that would then provide an easier way to connect to any other system. Since they won’t be upgrading, maintenance is probably not an issue there. But if the system is entirely closed and locked, exiting that dead-end seems to be the only alternative.

  • Svetlana Sicular says:


    I have been watching these cases on various occasions. I call them “Data revolution for data proletarians.” Many of the proletarians are not Gartner clients so we cannot help them, moreover, they disseminate worst practices. It is about time to step back and look at good old principles not as legacy but as heritage. And, BTW, they are not so old.

    Happy New Year!