You have dozens, maybe hundreds, of operational data sources spread among multiple business groups and locations. If only you could get a clear, consolidated view across all this information at once, you would gain a better understanding of what’s working and what’s not -- in sales, customer service, manufacturing, you name it. The cure to this common problem involves a fundamental decision: Should you consolidate all your data onto a single database platform, or implement a federation solution that allows you to query all your data right where it is now?
In the old days, the deck was heavily stacked in favor of consolidation. Federation has come a long way in recent years, though, thanks to improvements in data profiling and metadata management, new levels of abstraction for accessing different systems, and new methods of getting at deeper pools of data. Today a federation solution might allow users to correlate historical data in a warehouse with real-time data from transactional systems and even pull in supporting documentation from content management systems and file servers -- without migration migraines.
In practice, the solution may well involve a mixture of the two approaches. Even the most ardent proponent of data centralization, namely Oracle, acknowledges that federation must be part of every business strategy. Nor is the biggest advocate of federation, IBM, blind to the benefits of data consolidation. The difference between Big Red and Big Blue is one of emphasis: Oracle would have you shoot for 80 percent consolidation and 20 percent federation, whereas IBM would push that ratio just as far the other way.
For Oracle, the decision to consolidate is plain common sense. Fewer copies in fewer places results in cleaner data and better information. If you consolidate, you change business processes continually without touching the information in your databases. If you standardize on a single platform, you can leverage a common infrastructure and set of tools for real-time process monitoring, historical analysis, and forecasting.
Federation, on the other hand, will mean continually chasing your tail. Because business changes so rapidly, Oracle believes that any requirements you build into a federated system will be out of date by the time you deploy them and that any meaningfully complex federated system will be impossible to maintain.
IBM will tell you that centralized data is nice when you can achieve it but that the world is moving in the opposite direction. Just look around you. The biggest information technology initiatives today -- RFID, for example -- involve generating massive amounts of data at distributed locations. Enterprises don’t have a choice: They have to solve the problem of heterogeneity.
In IBM’s view, Oracle is resisting the natural order of things and glossing over the difficulty and expense associated with waging a constant battle against data entropy. Migrating data and applications to a single platform is not only painful and costly but a logistical nightmare. You grapple with layers of system dependencies -- analytical apps linked to the data stores, for example -- and wrestle with end-users about when to make the move. For the people using the data to do their jobs, “now” is never a good time to consolidate.
These arguments may be sweeping generalizations, yet two paths to more meaningful views of enterprise information and richer, real-time business intelligence have clearly emerged. The federation camp, represented by IBM, focuses on middleware for integrating heterogeneous data sources and optimizing queries that span many systems. The Oracle consolidation camp zeroes in on a standard database platform -- and on providing methods for moving data from one database to another.
Of course, unlike IBM and Oracle, enterprise IT organizations can’t afford to be exclusively focused on either consolidation or federation. They must choose the right tools -- or combination of tools -- for the job at hand. In practice, those choices will depend more on compatibility with existing architectures and skill sets than on commitment to one ideology over another.
Read more about data management in InfoWorld's Data Management Channel.