BI Strategy Document

The BI vision is documented in a BI Strategy document to ensure that implementation of specific technology or a data structure remains focused on the BI objectives for a particular organisation.

The BI Strategy Plan starts with high-level diagrams, broad policy statements and general definitions. As the BI environment grows, details are added to the strategy document.

The strategy document offers insight into the BI environment, with the focus on communicating:

1. What is to be built
2. How it will be built
3. When it will be ready to meet user requirements.

BI Strategy Document

BI strategy documents at a minimum include four core components:

1. Conceptual View
2. Data Architecture
3. Technical Architecture
4. Implementation View

Each of these components provides readers with a unique perspective of the BI environment being planned. Each section contains alternative approaches and technology solutions.

Some aspects of the overall strategy are provided in detail, whilst other elements are at a very high level or conceptual perspective.

Other sections [views] may be included as required, such as:

• BI Organization Diagram
• Use-case Views
• Section Guidelines

Each Section typically contains subsections:

Architecture Goals and Constraints – guidelines for architects and planners to set overall goals and objectives related to the BI initiative. Any constraints that impact the BI effort must also be defined.

Conceptual View – a BI organization conceptual diagram used as a road map for the enterprise initiative and guide for architects and project planners to define and describe individual components.

Use-Case View - provides a more business functional view of the BI strategy and used to formalize the intention of the BI initiative.

Architectural Design Components – a high level architectural design including only significant components, such as spatial data and analysis or ODS for tactical reporting, a message broker or XML server as a data delivery mechanism for the warehouse. These design components are important in terms of the overall BI objectives.

Standards - any standards that warehouse designers and developers must adhere to, for instance, who gives final approval to any particular iteration.

Conceptual BI Architecture

The Conceptual View provides a broad overview of the entire BI vision.

A conceptual BI Technical diagram is useful for illustrating how all the BI technology fits together, and assists with both the strategy definition and subsequent implementation planning.

Data Architecture View

The data architecture provides understanding as to what data structures are to be implemented, how that data is stored in each and how the data will propagate throughout the warehouse environment.

The following sub-sections may/may not be included:

Data architecture goals and constraints – this may include data integrity items such as “all warehouse-centric data must first be incorporated into the atomic layer, with all subsequent use of that data sourced from this single data structure”. Constraints might also include third-party data or technologies.

Logical data architecture - logical models that support data architecture goals. These will be limited until a specific warehouse iteration has been reached in the BI Roadmap. However, it is possible to provide a subject area model of the enterprise or a series of subject area models that describe core subjects within the enterprise. It may also include rules for mutating raw source data into atomic-level data and even guidelines defining how and when to use star schemas and OLAP cubes.

Architecturally significant design components – this may include items such as: establishment of an atomic layer or an ODS or an enterprise cube farm, or specific data elements such as geospatial data structures or specialized data staging.

Test plans – pre-rollout test plans are a critical part of the BI Roadmap. This section includes a testing and acceptance standard for all warehouse iterations, including: test templates, criteria for enterprise adherence and approval, criteria for test data selection and performance testing (including unit, suite and stress testing).

Data architecture often starts at a high level and evolves details of the architecture with each successive iteration of the warehouse.

Technical Architecture VIew

The technical architecture focuses on tangible components of the BI environment. Components must be described sufficiently, with technical diagrams and related textual detail. At the beginning of the BI program you will only have high level visions of the technical architecture, such as wanting to implement star schemas in a relational database. At this stage you do not know which relational database management system (RMDBS) vendor will be implemented. The technical architecture will evolve as updated versions as necessary.

Including a technical architecture diagram provides a general understanding of the current architecture as well as future architecture as details are confirmed.

The technical architecture section may contain:

• Technical architecture goals and constraints - specific to tangible components.
• Technical architecture - the hardware, software and network/communication components.
• Architecturally significant design components – for instance, you may require a 7x24 implementation with mirroring across two distinct data centers.

Implementation View

The implementation view also typically starts as a high-level perspective, with detail added as it becomes known.

This section is compiled by designers and project planners to:

1. Establish the guidelines necessary for building and maintaining the purposed warehouse structures and related technologies.
2. Detail the implementation of core processes
3. Outline the sequence of establishing data structures.

The implementation view will contain three distinct perspectives: the overall strategy, architecture and process.

Strategy

The strategy subsection includes:

• Timelines and Resource availability schedules to help planning and prioritizing of BI iterations – using process flows.
• Funding

Architecture

Includes details such as:

• Size and performance requirements
• Data quality issues
• Meta data control and retention policies.

The purpose is to indicate potential areas of impact, such as, retention policies will impact both data architecture [partitioning] as well as technical architecture [disk storage].

Process

Outlines high-level process issues such as:

• Refresh rates
• Backup/recovery
• Archive
• Workflow
• Security

Source-"IBM Data Warehousing" by Michael L. Gonzales (published by Wiley).

NEXT: Longer Term BI Strategy

Back To Top

BI Strategy Index | BI Vision | PM Objectives | Drivers Of BI | Barriers To BI | BI Lifecycle | BI Strategy Document | BI Long Term | BI Evolution | BI Best Practices | BI Excellence Survey | BI Scorecard | BI & ERP | BI & SMBs | BI and Cloud Computing