Wayne Eckerson, of The Data Warehousing Institute, recently contacted me about a project he is working on to fully classify, describe and compare the available architectures for data warehouse systems. He had formed four categories: top-down, bottom-up, hybrid and federated. He was interested in having me review his take on federated business intelligence (BI) architectures and comment on the characterizations of the other three.
Wayne's goal is to create an education track on the various architectures so teams can make informed and educated decisions on the appropriate approach given the inherent strengths and weaknesses of each. This is an outstanding goal. As longtime readers know, I have complained for some time about the lack of unbiased education available to teams when it comes to picking the approach that matches the unique characteristics of a site. I have dedicated quite a few column inches of editorial space to educate people on how to make the right choice. So, bottom line: Bravo, Wayne, for driving this initiative.
During our exchange, the characteristic of a federated approach being an "architecture of architectures" versus an architecture per se came up. This is, perhaps, the single most important distinguishing characteristic of a federated BI architecture. In my opinion, a federated approach is the only thing capable of being applied across a large organization as anything even resembling a standard.
As the Internet is a network of networks joined by common protocols and standards, a federated BI architecture is an architecture of architectures joined by common protocols (business rules) and standards (semantics).
The first steps in creating a federated environment are to document/audit the existing systems and create/facilitate a communications forum for the various BI system teams across the enterprise. You must create a directory of the variety of architectures/systems and open the paths of communication. This will enable the BI teams to agree on the protocols and standards that enable data integration in order to achieve a semblance of integrated BI architectures in a typical large organization. The documentation and the agreed-upon protocols and standards that comprise the federated architecture become the architecture of the architectures.
When it comes time to assess the BI inventory of the enterprise, you will undoubtedly be facing a hodgepodge of approaches, systems, architectures, turnkey systems, etc. I believe the only politically and culturally viable way to tie them together is with a federated approach.
There is no shortage of project teams that are zealously following one approach or another. There are also many global architecture teams that are working hard to codify one approach or another as the corporate data warehousing architecture standard. There are some organizations that have been working diligently to implement one approach or another for years, with varying degrees of conformity and success. The realities of corporate politics, implementation resource reality and the vendor-driven nature of the BI space will always yield architectural diversity.
The net of this is that you should get yourself and your team educated so that you can make a valid choice between top-down, bottom-up or hybrid architectures for your team, project, group, company or global enterprise.
In the end, you'll be faced with the same heterogeneous mix of BI systems, architectures and approaches as everyone else. A federated BI architecture is usually the only way to leverage some organization-wide value and capability out of these varied BI systems that dominate large organizations.
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