My purpose in this column is to present a tiny subset of the infinite variations of a business intelligence (BI) federated architecture. As many of you know, the federated architecture has evolved as a response to the reality that many organizations have multiple data warehouse and data mart systems; packaged and turnkey data warehouses, data marts and analytical applications; non-architected data marts; and data islands.

The goal of the federated architecture is to provide the maximum amount of architecture available in the political and implementation reality of your unique site. It does so by providing the means to share and distribute core business dimensions (such as product, customer, etc.) and key metrics and measures (such as unit sales, net revenue, etc.) across the heterogeneous BI infrastructure elements of the organization.

In the classic, centralized upstream federated architecture (which has been illustrated in past DM Review columns available at and, a common federation point is created upstream of the BI system components. This architecture is viable only in small- to mid-sized organizations.

In implementing a federated architecture, as well as data warehousing in general, your chances of sustainable success are inversely proportional to the scale you are trying to achieve with any single entity in your system (i.e., the enterprise data warehouse or centralized federation integration area). This is not due to technical reasons, but due to ownership, political, fiefdom and other "soft" issues. Due to this im-mutable law of political sustainability, the second major form of federated architecture ­ distributed upstream federation ­ evolved as illustrated in Figure 1.

Figure 1: Distributed Upstream Federation

In this scenario, your chances of sustainable success are inversely proportional to the number of design changes you are imposing on existing systems, teams, business functions, fiefdoms, etc. Your goal is to build an integration point for the disparate systems and to accommodate their diversity and heterogeneity. If you make your goal the native homogenization of the disparate systems at their source, you will not succeed, as architecture ranks just about last in the political pecking order. In this scenario, semantic and business rules consensus is your greatest challenge.

You will need to provide a wide variety of cross-reference tables, lookup tables, etc., to interface various disparate business rules, semantics, keys, etc., as well as a meta data architecture that can coordinate the multiple federation integration areas. This set of challenges often leads to the downstream-federated architecture represented in Figure 2.

Figure 2: Downstream Federation

Downstream federated architectures are not limited to a centralized federation area and often have a distributed architecture, similar to their distributed upstream cousins. Again, integrated meta data, and cross-culture semantic and business rule consensus are your top challenges.

In the end, we are faced with the fact that nothing is ever as simple in real life as it is presented in keynotes, slides, articles or books. Consider this a spotter's guide to the basic types of federated architectures. The ultimate diversity of implementation will reveal combinations of all these basic types, as well as hybrids, derivatives and variations. I recommend that you not get locked into debates about rigid definitions, classes, structures and stereotypes; instead, celebrate diversity.

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

Don't have an account? Register for Free Unlimited Access