My book “The Data-Centric Revolution” will be out this summer. I will also be presenting at Dataversity’s Data Architecture Summit coming up in a few months. Both exercises reminded me that Data-Centric is not a simple technology upgrade. It’s going to take a great deal more to shift the status quo.
Let’s start with Lawyers, Guns and Money, and then see what else we need.
A quick recap for those who just dropped in: The Data-Centric Revolution is the recognition that maintaining the status quo on enterprise information system implementation is a tragic downward spiral. Almost every ERP, Legacy Modernization, MDM, or you name it project is coming in at ever higher costs and making the overall situation worse.
We call the status quo the “application-centric quagmire.” The application-centric aspect stems from the observation that many business problems turn into IT projects, most of which end up with building, buying, or renting (Software as a Service) a new application system. Each new application system comes with its own, arbitrarily different data model, which adds to the pile of existing application data models, further compounding the complexity, upping the integration tax, and inadvertently entrenching the legacy systems.
The alternative we call “data-centric.” It is not a technology fix. It is not something you can buy. We hope for this reason that it will avoid the fate of the Gartner hype cycle. It is a discipline and culture issue. We call it a revolution because it is not something you add to your existing environment; it is something you do with the intention of gradually replacing your existing environment (recognizing that this will take time.)
Seems like most good revolutions would benefit from the Warren Zevon refrain: “Send lawyers, guns, and money.” Let’s look at how this will play out in the data-centric revolution.
Lawyers
While there are plenty of lawyers in most established enterprises, most are concerned with preserving the status quo. That’s mostly what lawyers do. What we need from the equivalent of lawyers in the data-centric revolution are people who can construct the new normal.
The new normal includes data governance. Again, typical data governance is about keeping things more or less the same. Data governance for the data-centric world, is about creating a new order. In place of thousands of complex data models, the data-centric approach rests on a single, simple, federate-able model for the enterprise. The data governance trick is firstly to establish this shared model.
Once the initial model is instantiated the governance policy is even more challenging than in a traditional environment. In a traditional application-centric world, while governance is typically a corporate function, almost all the data models are local to their applications. As a result, in a traditional environment governance is more about understanding how things map than it is about shared meaning, policy, or new ways of doing things. In data-centric, once we have the first version of the shared model, all subsequent users need to agree, share, and co-evolve the model. The good news is semantic technology and graph databases make this much simpler, but the problem doesn’t solve itself. It requires governance, cooperation, policies, and procedures to keep everybody rowing the same direction. Things that lawyers are typically good at.
Guns
The equivalent to guns in this environment is executive level support. Power. Every successful transition we’ve seen has been accompanied by senior level attention and direction. And unfortunately, “successful” projects get torpedoed in senior management cross fires.
We built a data-centric product catalog and compatibility workbench for a company that made over 1 million complex electric devices. The system was far more powerful and flexible than the existing system, at 1% of the complexity. When we say 1% of the complexity, in this case the existing system consisted of 700 tables and 7000 attributes, for a total schema size of 7700 concepts. The replacement system (which contained all the business information from the existing system), was implemented in 46 semantic classes and 36 properties for a total of 82 concepts. The system was built and converted and ready for production for a little over $ 1 million. Unfortunately, senior executives not in the chain of command for the sponsors of this project, had committed to a multi-year, multi-tens of millions of dollars replacement system (based on a package) that was obviously going to be far more complex and less flexible than the system just built. After investing several years in getting this project approved, most executives don’t want to find out after the fact that there is an easier way and managed to sideline the elegant project.
On the other side, a company we came across built a very early version of a data-centric architecture. One of the interesting features of their environment was the role of meta-data. In most systems, metadata, and a meta-data repository, are after the fact documentation systems. They are descriptive. In this case, the data architects had built a metadata system that could generate physical databases in conformance with the metadata. This approach is prescriptive. The interesting wrinkle was that once senior management caught wind of what was going on, they mandated that going forward there would be no physical databases that were not generated by the metadata system. As an interesting side effect, this mandate essentially ended the use of packaged application software. They have held the line for over a decade. The physical databases are 100% in synch with the corporate metadata model. The equivalent of guns in this environment is corporate political power.
Money
It takes money to run the transition to a data-centric architecture, but surprisingly not all that much. It is a fraction of the cost of a single major application implementation project. It is not so much the amount of money, but the ability to fund the initiative without interruptions.
The transition to data-centric goes much better with a small focused team, who are not victim to quarterly or annual start/ stop pressures. Application projects can start and stop (and most do), but to make the incremental continuous change requires a consistency that is hard to get otherwise.
Our observation is that a team of 4-10 over many years will eventually pick up all the functionality needed to gradually convert most of the backlog of existing and planned application systems. As I mention in Data-Centric Revolution, the Montefiori Healthcare System was able to build in 5-6 years with a small team, what is likely the most sophisticated medical analytics system in existence. The net costs of their efforts are even less than the resources would suggest, as they have be funding their efforts with grants that would not have been possible without the architecture.
In this world the equivalent of money, is not money per se, but the ability to fund a small but continual effort.
Summary
We think this is going to be one of the quietest and lesser hyped revolutions of the history of IT trends. However, that doesn’t suggest it will happen of its own accord. There are some new technology in the revolution (but most of it is proven out, and we’ve discussed in other articles in this series). The main issues will be political and issues of discipline and will.
As such we think the slogan “send lawyers, guns and money” is not too far off the mark. We’ll have to pay a lot of attention to the governance, process, policy, executive support and long-term funding in order to succeed.
