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:
- What is to be built
- How it will be built
- When it will be ready to meet user requirements.
BI Strategy Document
BI strategy documents at a minimum include four core components:
- Conceptual View
- Data Architecture
- Technical Architecture
- 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
Use-Case View - provides a more business functional
view of the BI strategy and used to formalize the intention of the
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
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
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.
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:
- Establish the guidelines necessary for building and maintaining
the purposed warehouse structures and related technologies.
- Detail the implementation of core processes
- Outline the sequence of establishing data structures.
The implementation view will contain three distinct perspectives:
the overall strategy, architecture and process.
The strategy subsection includes:
- Timelines and Resource availability schedules to help planning
and prioritizing of BI iterations – using process flows.
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].
Outlines high-level process issues such as:
- Refresh rates
NEXT: Longer Term BI
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
NEW! - Get Your Copy of the New
BI Strategy Guide HERE!
Your Choice of Print Or Instant Download Ebook