Ten years ago, in the early days of data warehousing, there was only one approach and one architecture. The business-driven demands of the market led to the evolution of multiple approaches and architectures for data warehouse systems. As the market grew into business intelligence (BI) and data warehouses became one of many components of complex, heterogeneous BI systems, multiple layers of architectures developed. As BI has matured, three tiers of architecture have evolved: global, fiefdom and project (see Figure 1).
Global architectures function at a meta or enterprise level and serve to integrate lower-level architectures. Fiefdom architectures function at a corporate or functional level and serve targeted needs of organizations or functional groups. The project level is fundamentally nonarchitected and commonly serves the needs of departments or initiatives.
The critical challenge is that project-level systems cannot integrate horizontally across projects nor vertically into fiefdoms. Fiefdoms cannot integrate horizontally across disparate/foreign fiefdoms nor vertically into non-fiefdom-compliant projects. Only global architectures can integrate heterogeneous environments.
Figure 1: Three Tiers of Architecture
Global architectures are scalable across very large organizations. They are also uniquely scalable across complex, heterogeneous organizations. They are both adaptable and flexible, thereby enabling integration of disparate elements. Lastly, they are culturally scalable, which allows their implementations across an entire global enterprise. To be successful, global architectures need to be focused on pragmatic success within the political, cultural and implementation realities of the organization.
Fiefdom architectures require strict compliance from all cultural, political and functional groups that wish to store and retrieve data from the system. In order to overcome these compliance hurdles, they require unswerving, long-term endorsement from the very top political layers of the organization. Fiefdom architectures are vendor-sized (i.e., they are very popular among vendor partnerships) and are a vehicle used to own and control the account. They are also IT-culture friendly in that they avoid uncomfortable business-driver, business-value, communication, expectation management, cultural and political issues. They are almost exclusively focused on selecting and implementing technology, which are the strengths of technologist-dominated teams.
Project-level systems are quick-hit, speed-to-market oriented. They are generally grass roots in nature and are usually viewed and positioned as heresy versus fiefdom approaches. Project-level systems are buy/packaged-solution friendly in that a packaged, turnkey system can have a quick impact on the business. Consequently, they are department friendly. In this context, the focus is on speedy business impact rather than worrying about or waiting for architecture or integration with other BI systems.
Current common manifestations of the three BI architecture tiers can be seen in Figure 2.
Figure 2: Common Manifestations of the Three BI Architectures
Most organizations find themselves in a heterogeneous state with a wide variety of nonintegrated custom, turnkey and hybrid data warehouse, data mart, data mining, analytic application and general- purpose BI systems (see Figure 3).
Figure 3: Example Heterogeneous BI-Architecture
In order to integrate their foreign fiefdom and noncompliant project systems, some organizations are adopting global architectures (see Figure 4).
Figure 4: Example Global Architecture
The components of a global architecture are:
Communication Forum. This is the most important element. It is used as the vehicle of exchange between the stakeholders of all involved BI systems.
Change Management. This may be an interface to the organization's existing change management (CM) resources or a set of CM resources and capabilities within the BI organization.
Best Practices. Best practices include not only techniques, methodologies and standards, but also a reference as to which tools, vendors, consultants, internal resources, etc. performed well (or not).
Marketing, Evangelizing and Expectation Management. At the project-lead and manager level, marketing consumes a large segment of time and bandwidth. It is essential to have consistent branding, messaging and communications in order to initiate and sustain political will for the BI system.
Meta Data and Documentation. One of the primary deliverables of the global system is a reference as to who has what data using which semantics derived by what business rules, etc.
Data: Key Metrics, Measures and Dimensions. Last, but not least, comes the shared data itself, comprised of uniquely integrated, politically meaningful metrics, measures and dimensions/masters.
Sweet spots for global architectures include large, complex, heterogeneous organizations. This is especially true in large enterprises where there are several data warehouse systems and the prospect of ongoing implementation of additional custom, packaged or turnkey data warehouse or data mart systems. Another common driver is decentralized or powerful functional groups. These groups usually have built or are building their own BI systems and are unlikely to readily comply culturally or politically with a fiefdom architecture. Culturally, global sites are ones where business politics and speed to market hold sway over IT and architecture compliance proponents.
Fiefdom sweet spots are midsize organizations or functional groups within larger complex organizations. These sites are comfortable with centralized planning and its requirements for centralized command and control. Consequently, organizations where there are strong personality cult groups have more success with the compliance required in this approach. IT-driven projects are more likely to be a fiefdom approach, as they are a good fit for IT culture. They usually require a long-term political mandate and commitment of resources by the board and CEO level of the organization. Culturally, these sites are more likely to be ones where IT and architecture compliance proponents hold sway over business issues (i.e., speed to market).
Sweet spots for nonarchitected project-level systems include departments; rogue IT groups; remote, unsupported organizations; vendor-controlled sites; and groups with little to no resources.
All three architecture tiers have inherent risks.
Global risks include:
- Too many gaps. Not enough data is integrated for the business to perceive long-term value in the system.
- Lack of elegance/purity. This can lead to passive-aggressive fiefdom zealot pushback or political or functional sabotage of the system. Don't underestimate the level of passion in the fiefdom-level camps.
- "What do we believe in?" Global teams need to clearly define the goals and guidelines of the system, lest lack of clear direction dismay and disrupt the participating teams.
- Lack of business focus yields low to no business impact. It is critical to stay focused on measurable, unique business value, especially in the first few iterations.
Fiefdom risks include:
- Tail wags the dog. When compliance to the dogma becomes more important than delivering value, the project is at risk.
- Who's driving the bus? Teams that over-focus on fiefdom-approach compliance can abdicate control to powerful vendors and their agenda(s).
- Department of delay. A fatal mistake is to have mandatory conformance to architecture slow the delivery of business value to a trickle.
- Multimillion-dollar island. When the expensive fiefdom system can't integrate with the foreign fiefdom of an acquisition or of a powerful functional group, unpleasant political consequences follow.
- Hill to die on. Teams can expend all their political capital driving compliance, and then become a casualty on nondelivery hill.
- Hit the wall. Teams can find that their fiefdom architecture can't scale technically, culturally or politically.
Project-level risks include:
- Data islands. Once created, the system can't integrate or share data with any other BI systems.
- Resource turnover. The people who bought or built the system move on, and there is no one to provide ongoing support. These systems are usually abandoned on the IT department's doorstep.
- Vendor/product obsolescence. The vendor or the technology used to build the system is no longer in existence.
- Can't scale to meet demand. The system is great, and provides notable business value, but can't scale past a small data set or small number of users.
In order to succeed with the implementation of a global architecture, it is important to keep the following keys to success in mind:
- Focus on political and cultural reality.
- Adopt as much consistent architecture as possible (i.e., avoid nonarchitected systems at every turn) and gain as much fiefdom compliance as you can support politically.
- Reject theory and vendor-driven agendas vendors' jobs are not on the line; yours is.
- Stay flexible, don't get boxed into a corner by orthodoxy.
- Stay focused on speed; be a facilitator of speed not a merchant of delay.
- Stay focused on business value; don't value architecture over meeting business needs.
In today's BI world, organizations that value the integration of disparate, heterogeneous BI systems and are focused on facilitating speedy delivery of politically meaningful value to the business should consider implementing global architectures.
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