One of the most frequent questions I get after speeches is, "Please explain what federated means. Isn't it the same as conformed dimensions, etc.?" As long- time readers of this column know, a federated architecture is not a pure, elegant design of any type. Rather, it is a pragmatic manifestation of the political and system realities of day-to-day corporate life. This is a nice way of saying that it is sub-optimal which is a politically correct way of saying that like most real business intelligence (BI)/data warehousing (DW) systems, it can be pretty ugly when you get down to the real nuts and bolts of putting it together and making it work.
If there's one thing the last decade of BI has taught us, it is that there is no panacea. There is no silver bullet and no single answer that will save the day for every team attempting to design and build a productive, politically sustainable, integrated information resource for their business. It is my opinion that neither top-down nor bottom-up approaches will universally save the day and that monolithic hub-and-spoke or architected, conformed data marts will not guarantee success. Many organizations today have multiple data warehouse systems that are a hodge-podge of top-down and bottom-up approaches, monolithic hub-and-spoke, subject area DWs and architected and non-architected data mart systems.
Federated architectures are not elegant. They are not theoretical nirvana, and they are not a magic answer. The greatest challenge facing teams looking for a way to provide the maximum amount of architecture possible for their heterogeneous collection of turnkey analytical applications, data warehouses of various stripes and plethora of data mart systems has been that there have been no products specifically targeted at this issue.
This lack of vendor validation has extended the federated architecture's position as the unwanted stepchild of BI architectural solutions. Without vendor marketing dollars to fund research, fuel publicity, subsidize analyst coverage and all the other buzz required to succeed in our BI world, the federated architecture has been the shareware of the BI market. It has been driven by grassroots support of teams tired of being flogged by their heterogeneous reality. These teams turned to federated architectures to stitch together as much semantic and business rule conformity, sharing of business dimensions and critical metrics and measures as possible.
Fortunately for these teams, and for the market stature of the federated architecture itself, the vendor community has awakened to the heterogeneous nature of reality. Several vendors are stepping up with tools specifically targeted to enabling federated architectures by "gluing" together the disparate elements and components. Some vendors are taking a middleware approach, some are taking an approach driven by meta data, some a data integration approach and some a front-end approach; but all are rushing to fill the gap in the market around the typical reality of being mandated to stitch together an organization's multiple, incompatible BI systems.
In the next few months, you should expect to see a few exciting startups, a few spin-offs, a few big logos and countless examples of re-branded products being touted as the one true silver bullet for enabling nearly instant implementations of a federated architecture in your organization. Don't believe them.
As we learned with re-branded data warehousing tools in the past, simply changing the label on a product to read "new and improved for federation" is not going to take us any closer to our goal of providing as much architecture as we can in the incongruent world of systems. Real federation glue needs to meet the following criteria:
- Heterogeneous data. The tool must support connection, interchange and integration of heterogeneous data, including structured and unstructured content.
- Integrated meta data. The tool must seamlessly integrate meta data from all data sources and all data presentation, analysis and utilization tools.
- Real time. The tool must support real time data, meta data and utilization.
- Integrated semantics. The tool must support and enable the integration of disparate semantics used across the various source and utilization systems.
- Integrated business rules. The tool must support and enable the integration of disparate business rules used across the various source and utilization systems.
The vendors are making good headway on the first three requirements and are still in the deer-in-the-headlights phase on the last two. Of course, as luck would have it, the last two are the most important.
The good news is that there are tools, and more will be coming soon, that will greatly ease the task of federation. The bad news is that there is not now, and never will be, a BI architecture silver bullet. The answer to the question, "What is federation?" remains the same: achieving the maximum amount of architecture possible within your political and implementation realities by the sharing of business dimensions and critical metrics and measures across your heterogeneous systems.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access