APR 1, 2000 1:00am ET

Related Links

10 Sustainability Predictions for 2011
February 23, 2011
A Letter to Future Employees: Embrace Analytics
February 3, 2011
A Hunger for Risk
January 6, 2011

Web Seminars

How Customer Analytics Can Lower Costs and Raise Revenue
July 29, 2014
Improve Omni-channel Shopping Experience with Product Information Management
August 21, 2014

Federated FAQs

Print
Reprints
Email

The two-part series regarding federated data warehouse (DW) architectures that appeared in the December 1999 and January 2000 issues set a record for e- mail responses from readers. (The columns are available in the archives at www.dmreview.com and www.egltd.com.) The feedback was overwhelmingly positive, and there were many requests for further information. In an effort to answer all the questions most efficiently, I've combined and condensed them into this month's column.

What is a federated data warehouse (DW) architecture? A federated DW architecture is an overall system architecture that accommodates multiple DW/data mart (DM) systems, operational data stores (ODSs), amorphous reporting systems, analytical applications (AAs), etc. As the Internet is a network of networks, a federated DW architecture is an architecture of architectures. It provides a framework for the integration, to the greatest extent possible, of disparate DW, DM and analytical application systems.

Isn't a single, central DW system better? Central data warehouses offer several powerful positive attributes; and if your site has the high-level sustainable pain and political will required to be successful, then you should closely examine this option. (To help you decide if this approach is suitable to your site, check out the free build-approach automated assessment in the resource library at www.egltd.com.)

How does a federated DW architecture work? A federated DW architecture shares as much core information among the various systems as possible. This is accomplished by sharing critical master files or dimensions, common metrics and measures, and other high-impact data across all systems that can make use of the information. It is usually accomplished via an enterprise-class ETL tool, which provides a common meta data repository, and the use of common data staging areas.

Isn't this the same as a bottom-up, conformed dimension/bus approach? The sharing of common data points is the same, but in a federated DW architecture you must resign yourself to the fact that individual components of the system will retain unique feeds from various internal and external data sources that are not shared with any other component. This is less than elegant, less than perfect, but a political and practical reality. Also, data sharing in a federated DW architecture is usually not as cleanly implemented as in a straight bottom-up scenario. For instance, in a federated DW architecture, many times shared data is extracted from the mid-level of a component system rather from the source extraction process. As with comparisons with a top-down, centralized system, it is important to remember that a federated DW architecture is not the ideal theoretical vision, but merely the most pragmatic means to reach the goal within some diverse, heterogeneous environments.

How do we go about designing and building a federated DW architecture?

  1. Document your existing DW/DM systems via a high-level enterprise data warehouse architecture (EDWA). The highest level is an entity level diagram showing the various systems and any existing cross data flow and the meta data exchange between them.
  2. Document each of the existing DW/DM systems at the data flow level. This level includes data flow from each data source, any transformation and integration steps, and meta data repositories. Rate each major data element in terms of quality, availability and ease of access.
  3. In conjunction with your users, determine what data offers value add and impact across multiple systems. For instance, adding financial information to marketing information yields profitability by customer and demographic segment.
  4. Collect the various build-phase candidates that derive from step 3 and analyze them to determine impact and viability. (To help with this analysis, there is a free build-phase candidate automated assessment in the resource library at www.egltd.com.) Pick the candidate that provides the best balance between business impact and risk.
  5. Build a small, focused iteration of the federated DW architecture based on the winning candidate from step 4. Document and publicize success to establish and sustain the political will required for future iterations.

From the in- the-trenches perspective, the federated DW architecture is, in my opinion, the best alternative to achieve the maximum level of architecture possible in today's heterogeneous world of custom and packaged DWs, DMs and low cost, turnkey analytical applications.

Get access to this article and thousands more...

All Information Management articles are archived after 7 days. REGISTER NOW for unlimited access to all recently archived articles, as well as thousands of searchable stories. Registered Members also gain access to:

  • Full access to information-management.com including all searchable archived content
  • Exclusive E-Newsletters delivering the latest headlines to your inbox
  • Access to White Papers, Web Seminars, and Blog Discussions
  • Discounts to upcoming conferences & events
  • Uninterrupted access to all sponsored content, and MORE!

Already Registered?

Filed under:

Advertisement

Comments (0)

Be the first to comment on this post using the section below.

Add Your Comments:
You must be registered to post a comment.
Not Registered?
You must be registered to post a comment. Click here to register.
Already registered? Log in here
Please note you must now log in with your email address and password.
Twitter
Facebook
LinkedIn
Login  |  My Account  |  White Papers  |  Web Seminars  |  Events |  Newsletters |  eBooks
FOLLOW US
Please note you must now log in with your email address and password.