ebook part 3_ the bi framework_ how to turn information into a competitive asset
TRANSCRIPT
Published by Logica
Copyright © 2009 by Logica
All rights reserved. This document is protected by international copyright law and may not be reprinted, reproduced, copied or utilised in
whole or in part by any means including electronic, mechanical, or other means without the prior written consent of Logica. Whilst reasonable
care has been taken by Logica to ensure the information contained herein is reasonably accurate, Logica shall not, under any circumstances
be liable for any loss or damage (direct or consequential) suffered by any party as a result of the contents of this publication or the reliance
of any party thereon or any inaccuracy or omission therein. The information in this document is therefore provided on an ‘as is’ basis without
warranty and is subject to change without further notice and cannot be construed as a commitment by Logica.
The products mentioned in this document are identified by the names, trademarks, service marks and logos of their respective companies or
organisations and may not be used in any advertising or publicity or in any other way whatsoever without the prior written consent of those
companies or organisations and Logica.
ISBN/EAN: 978-90-814105-1-9
1 Introduction
2 Business value of BI
2.1 Enterprise Value Management2.2 BI Market pull2.3 Track risk and compliance2.4 Ectract more value from customer interactions2.2.5 Track performance and align metrics across the organisation
3 Business Intelligence definition
3.1 BI Foundation3.2 Related Disciplines3.3 Creating value with BI3.4 Maturity models
4 Managing BI
4.4.1 Cost Effective Management of BI4.2 BI Competence Center (BI CC)4.3 BI Delivery models4.4 Estimating investments in BI
eBook #1
5 BI Lifecycle
5.1 BI Strategy5.2 BI Definition5.3 BI Development5.4 BI Exploitation
eBook #2
6 BI Solution Engineering 98
6.1 Benefits of the BI Engineering Framework ............................................................................................ 996.2 Connection to the BI lifecycle .............................................................................................................. 1006.3 Stakeholder perspectives .................................................................................................................... 1026.4 Engineering disciplines ........................................................................................................................ 1046.6.5 The BI Engineering Framework Model ................................................................................................ 1066.5.1 Business Context (scoping) ................................................................................................................. 1076.5.2 Business Context (analytical) .............................................................................................................. 1086.5.3 System Context ................................................................................................................................... 1096.6.5.4 BI Architecture ..................................................................................................................................... 1106.5.5 System Concept .................................................................................................................................. 1116.5.6 System Specification ........................................................................................................................... 112
7 Best Practices
7.1 DWH Architecture evaluation7.2 ETL Framework7.3 Data Quality7.4 Data Vault7.5 Dimensional modelling7.7.6 Data and Text Mining
Available in May 2010
8 Ferrari Case 160
8.1 Introduction ......................................................................................................................................... 1708.2 Strategy study ..................................................................................................................................... 1708.3 Feasibility Study .................................................................................................................................. 1718.4 Requirements Analysis ....................................................................................................................... 1738.8.5 Demonstration .................................................................................................................................... 1748.6 BI Architecture .................................................................................................................................... 1758.7 Data warehouse Realisation ............................................................................................................... 1768.8 Reporting and analytics Realisation ................................................................................................... 1778.8.9 Data Quality ........................................................................................................................................ 1788.10 Data Vault Modelling ........................................................................................................................... 1798.11 Dimensional Modelling ........................................................................................................................ 1828.12 Exploitation .......................................................................................................................................... 183
10
Dear reader,
Welcome to our newest version of the Logica Business
Intelligence Framework. It has come about thanks to
the global collaboration between multicultural, multi
specialist and very experienced people dedicated to
improving organisational performance enabled by CPM
and BI. When we listen to our customers, or look at our
own company’s organisation, we still face some of the
traditional challenges:
We have many ways of producing metrics.•
We do not have a common language within each •
part of our organisation.
We provide alignment in mergers but we have •
experienced challenges in supporting them.
We have a wealth of data but have yet to determine •
what value it adds and how to deal with the quality
control.
I could keep going, and it is an easy job to list all of the
challenges, but that does not help create value. We
consider every project that involves Business Intelligence
to be an opportunity for transforming and improving
the organisation. It is part and parcel of the change
management process. Since the 90’s we have been
delivering process-oriented projects using pre-built
applications, such as ERP-related solutions. This greatly
helped to rationalise behaviour involved in such a process,
gave us a sense for how IT departments and new maturity
levels operate with an industrialised approach, but in
many cases lacked the impact it had on the associated
decision-making process. If we need proof of this, we just
need to ask ourselves a few questions.
Do I have the same common language and •
definition of indicators throughout my company?
How do I explain the need for so many reports, •
dashboards, etc.?
Is my Business Intelligence as mature as my ERP? •
If I was to make a call to the helpdesk for every •
data quality issue, would I need to double the size
of the helpdesk?
Today, our goal is to give you our latest vision of the Logica
Business Intelligence Framework, and so help you to take
full responsibility for some of the challenges listed above,
and some of the other challenges that have to be faced.
We face them knowing that it will not be easy. We have
shaped visions, crafted strategies, scoped and delivered
projects, and then we completely outsourced them; this
work represents millions of man hours. Our challenge
is to leverage our former common language that we
used for Business Intelligence and to make it a source of
additional value for our customers and our people. The
main difference is that it is not a book written by a few of
our experts but a collaborative effort. It is also the result
of different practices that have been merged together and
the blended experience from a variety of our constituent
countries. They have been challenged by our best people
and customers; the practices that are used are present
because we are confident that they deliver results in
today’s global environment.
So what can I expect from the Logica Business
Intelligence Framework? A quick win could be to
benchmark an approach, a vision, the performance of a
Preface
11
Business Intelligence Competence Center, or simply your
operational costs. Another possibility could be to use the
framework in your own effort of aligning your organisation,
thus avoiding the need of making the investment yourself.
We strongly believe that the Total Cost of Ownership
of BI can be lowered significantly by implementing
a standardised BI development and management
methodology in your organisation. Sharing the same
standards, procedures and guidelines within your
organisation and with your BI suppliers enables effective
communication between the parties involved and makes
BI development a repeatable and predictable process. We
use the BI Framework to align and optimise the blended
delivery of BI, combining local expertise with near- and
offshore delivery centres.
We like to consider this BI framework to be an open
source project. We will maintain it, provide new releases
and commit to improving it with our community and in
doing so unify our customers, partners and people in
doing so. We always talk of Web 2.0 and we would like
to think of our Framework as BI 2.0. Therefore, we invite
you to be part of our innovation process. We prefer talking
about collaboration and development rather than research
and development. We encourage you to read this book
and to become acquainted with BI and our vision of it.
We look forward to you comments.
Stéphane Jaubert,
Managing Director
Business Intelligence
Global Practice Leader
6
Engineering framew
ork R
epeatable p
rocess E
nterprise architecture framework Taxonomy Proven practice P
redi
ctab
le q
ualit
y, t
ime
to m
arke
t, co
st to
deli
ver Stru
ctured knowledge management Technology
independent Agile BI Construction Audit services
Stakeholder perspective Engineering disciplines Busin
ess
mot
ivatio
n Bus
ines
s co
ntex
t B
usin
ess
activ
ity m
onito
ring
Engineering framework
Repeatable process Enterprise architecture framework Taxonomy Proven practice P
redi
ctab
le q
ualit
y, t
ime
to m
arke
t, co
st to deliver Structured knowledge
98
6 BI Solution Engineering
Designing and developing a BI Solution requires not only
a good understanding of the BI lifecycle as defined in
chapter five. It also requires strong skills and capabilities in
software engineering. In this chapter we will introduce our
BI engineering framework, supporting BI practitioners in
their daily operating environment.
The BI engineering framework is the working environment
for the BI practitioner. It offers a structured set of
activities and deliverable templates to enable efficient,
manageable and repeatable BI development. BI framework
describes the main processes to be understood by
all involved parties in a BI initiative. The BI engineering
framework defines in detail the activities, deliverables,
interdependencies and resources to support the BI
practitioner. The stages of the BI Framework map onto the
phases in the engineering framework. The BI engineering
framework is not only used by the BI consultants of Logica,
but has also been adopted as the formalised development
methodology for BI by many of our customers.
The Engineering Framework developed from the need to
structurally collect, manage and reuse the best practices
of the BI community. For effective adoption of the
Engineering Framework, Logica based its best practices
on existing methodologies and industry standards
wherever possible and on specific Business Intelligence
ones where appropriate.
The framework consists of several phases bringing
you from high level definition of the BI strategy to the
maintenance and support of existing BI solutions. In
every phase the same set of engineering disciplines need
attention, which are based on the Enterprise Architecture
Framework of Zachman. Also, each phase has different
types of activities associated to it. Construction activities
to develop a BI solution. Research activities to provide
advice, plan ahead or envision future solutions. Service
activities for repeatable activities that do not require full
time involvement. Verification activities to verify if the results
of the actual stage comply with earlier set expectations.
To prevent companies from disintegrating, the concept of a comprehensive information architecture becomes more and more vital. The Zachman Enterprise Architecture Framework model provides an integrated model to structure and manage the information architecture of an organisation. (Source: John Zachman, 1987, www.zifa.com)
It is not the intention to develop an entire methodology.
In fact, there is more a need for a taxonomy which
offers insight into relationship with an existing system
development or project management methodology.
After all, we want to deliver services to a wide variety of
customers and independent of trends.
Before going in more detail on the Engineer Framework
itself we will start with the benefits of using this framework
in the design and development of a BI solution. After
that we will go in more detail on how the engineering
framework is connected to the earlier defined BI lifecycle
and how the engineering framework is structured by
engineering disciplines and stakeholder perspectives.
We will conclude this section by bringing together the
different components of the engineering framework into a
comprehensive BI engineering framework model.
99
BI Solution Engineering
6.1 Benefits of the BI Engineering Framework
The design and development of business intelligence is an
engineering process, and therefore requires a structured
approach of executing activities and delivering results.
Without that kind of structure, designing and developing
a BI solution would be like an new invention every time
again. Imagine Toyota building cars without properly
documented production processes in place.
The tangible benefits of using a consistent and proven BI
engineering framework are:
It offers a good proven practice in conducting a BI z
initiative. By using it, you prevent making the same
mistakes over and over again. It improves the quality
of BI development and lowers the cost of design and
development by re-using best practices. On top of the
available best practices the engineering framework
offers a structured knowledge management system
to collect and evaluate organisation specific best
practices as well.
It offers a repeatable process for designing and z
developing a BI solution. By using it, the organisation
achieves BI solutions with predictable quality, time to
deliver and cost to deliver. The engineering framework
already includes industry metrics on a lot of the
activities and products to be used for benchmarking or
estimation. Consistent usage enables an organisation
to collect organisation specific metrics. This allows to
better predict future BI initiatives.
It offers a standardized traceable and audit able z
documentation system through all perspectives
and disciplines of BI design and development. This
dramatically improves knowledge transfer and hand-
over to BI practitioners in- and outside an organisation.
Smooth knowledge transfer and hand-over are key
enablers to improve resource management of BI
projects, change management and maintenance
efforts.
Sharing the same engineering methodology between z
parties is a huge advantage in achieving effective
communication. Effective communication is a key
enabler in aligning the demand and supply chain on
BI. Using the same reference framework is a proven
success factor in outsourcing and off-shoring BI
development and maintenance. Out-sourcing and off-
shoring of BI in a effective manner can significant lower
the Total Cost of Ownership (TCO).
It offers BI specific engineering content and does z
not replace existing project management or system
development methodologies. The structured definition
of all deliverables, activities and required resources
enables easy integration into any standard project
management methodology. Also the models used, are
commonly known in the marketplace. This makes the
BI engineering framework easy accessible for any BI
practitioner.
It offers technology independent design of BI z
solutions. Considering the rather dynamic BI
marketplace preventing vendor lock-in becomes
important. The preferred tool vendor of today may well
be replaced by some other vendor tomorrow, based
on market dynamics or shifting requirements in the
organisation. The engineering framework keeps BI
development agile by enabling low cost and low risk
migration to new BI technology.
100
6.2 Connection to the BI lifecycle
The four main stages in a BI lifecycle are BI Strategy, BI
Definition, BI Development and BI Exploitation. The BI
engineering framework provides the detailed collection of
activities, deliverables and services needed to execute the
four stages in the BI lifecycle.
Table 6.1 BI Engineering Framework activities
Lifecycle Stage
BI Strategy
BI Definition
BI Development
BI Exploitation
Deliverable
Business Context
System Context
BI Architecture
System Concept
System Specification
Repository data & code
BI Solution Configuration
Audit Services
Information Management
Assessment
Readiness Assessment
Compliance Audit
Service Audit
Construction Activity
Business Analysis
Requirements Analysis
BI Architecture Design
Logical Design
Physical Design
Realisation
Research or Service Activity
Strategy Study
Demonstration
Feasibility Study
Prototype
Proof of Concept
Transition
Maintenance and Support
Data Resource Management
Information Delivery
Management
BI Engineering Framework activities & deliverables
As shown in the table four different types of activities exist
in the engineering framework:
Construction activity; z
A construction activity is part of the development
cycle and as such contributes directly to the design
of a solution. The result of a construction activity has
the form of a model. By using models to document
the design, those involved can evaluate the proposed
functionality of the system from their perspective. In
addition, using standard design primitives imposes
uniformity. The entire set of models constitutes the
system documentation.
Research or Service activity; z
A research activity is also part of the development
cycle. However, this time it is a specific question
that needs answering. Certain questions arise
during every design and realisation process to some
101
extent. Answering them is more efficient and safer
(due to uncertainty) when done separately from the
construction activities. A research activity originates
from the models delivered by a construction activity.
The result of a research activity is an advisory text.
The result of a service activity is the operability of the
system, manifested by a status report.
Audit Services; z
A audit activity is an activity that is taken from the
primary development cycle to offer an objective insight
into the results of prior construction activities. Thus,
the audit activity makes a statement about an existing
situation; for stages 1 and 4 this would be the existing
business, for stages 2 and 3 this would be the work in
progress (a project), i.e. the intended situation.
The result of an audit activity comes in the form of a list
of findings.
When reading the Engineering Framework from left to right
it is becomes apparent that deliverables of a construction
activity serve as input for the research, review and service
activities. Potentially an activity can be performed twice
over the course of a project because, as we derived
earlier, we have to deal with development of the back end
and with the development of the front end.
The BI engineering framework is organised as a matrix
of related deliverables, as shown in figure 6.1. On the
horizontal axis we find the various subject areas to be
specified, based on engineering discipline perspectives.
On the vertical axis the level of detailing the specification
based on stakeholders perspective are given. Before
going into detail on the various deliverables in the cells of
the matrix we will introduce the meaning of the horizontal
and vertical axis in the engineering framework.
In a typical BI engineering process the deliverables in the
engineering framework will be delivered in order from left
to right, from top to bottom. All deliverables need attention
to ensure a complete and comprehensive definition and
specification of the BI solution. Depending of the situation
some deliverables will contain more and some deliverable
will contain less information. However, determining that
a certain model is not relevant for a particular BI solution
is also valuable information. Therefore, there is no reason
to skip a subject. IT specialists have a tendency to add
increasing detail when using a top-down approach.
However, from the perspective of a stakeholder a high
level of details always matters. In doing so the framework
follows the best practice as prescribed by Zachman.
BI Solution Engineering
BI Solution Engineering
Deliverable
Deliverable
Deliverable
Deliverable
Engineering Disciplines
Sta
keho
lder
Per
spec
tives Deliverable
Figure 6.1 BI Engineering Framework
102
6.3 Stakeholder perspectives
On the vertical axis the framework is ordered in such a
way that the models depict the view on the business from
a specific stakeholder’s perspective. The deliverables and
activities are linked to these perspectives, as shown in the
table below.
Table 6.2 BI Engineering framework stakeholder perspectives
Deliverable
Business Context
System Context
BI Architecture
System Concept
System Specification
Repository data & code
BI Solution Configuration
Stakeholder
Business Owner
Business Analist
BI Architect
BI Designer
BI Developer
BI Administrator
Perspective
Business scope
Business model
Added value for the business
Capabilities provided to the business
Key design decisions based on BI strategy,
system context and roadmap
System behaviour (internal)
System construction aligned with
technical constraints
Inventory of system components and
procedures to run the BI solution
Below the definition of the deliverables aligned with the
stakeholder perspectives:
Business Context; z
The business context provides the BI initiative with a
consistent frame of reference for all those involved in
the initiative. Also, it serves as input for the BI strategy
because it contains the objectives of the business
and the business drivers. The business context is
made up of the business scope and the business
model. The business scope defines the activities that
the organisation focuses on because the mission
and vision of the organisation deem them important.
The business scope is the first row in the Engineering
Framework. The business model describes how the
organisation is structured in order to achieve objectives
within the business scope. The business model is
the second row in the Engineering Framework. The
requirements of the information system are derived
from the lowest level of detail of the business model.
System Context; z
The system context describes the capabilities of the
system within the scope and the criteria of the BI
strategy. Synonymous terms would be: Definition,
System Requirements. The documentation consists
of models that contain natural language which
103
BI Solution Engineering
makes it legible for the ‘user organisation’. These
models describe the external behaviour and not the
internal behaviour of the information system. The
required capabilities are already present implicitly, in
the earlier mentioned business model. The system
context however, explicitly states the items in the
business model that are relevant for a specific IT
solution. It offers the user organisation and the project
management a specific definition of the scope of the
required IT solution.
BI Architecture z
Key concerns follow from the scope and criteria in the
BI strategy and the requirements. The BI architecture
describes the key design decisions that address
those key concerns. The architecture also provides
so-called key concepts to enforce a standard way
of implementation of certain subjects. Late arriving
dimensions for example can be dealt with once as a
key concept and within the system concept referring to
the key concept is sufficient then.
System Concept z
The system concept describes the internal behaviour
of the system. It is the representation of the business
according to the system designer. Using the system
concept the solution can be verified against the
system context and the architecture. Documentation
consists of formal models – at the attribute level – that
are legible to experienced IT generalists. At this point
the documentation is still independent of technology.
As such, the documentation should not be cryptic or
specific to a certain software product.
System Specification z
The system specification describes the physical details
of the system in order to embed the desired behaviour
and to enforce a particular construction method. It is
the representation of the business according to the
system developer. Documentation consists of models
and specifications that are legible to IT (product)
specialists. At this level the documentation does
depend on the technology. The system specification
is an augmentation of the system concept, containing
technical instructions. A system specification is
especially applicable in situations where complex
and risky components have to be built or when less
experienced developers must to perform a task and
need support in doing so. In both situations it allows
for the technical solution to be evaluated within the
team before commencing the realisation. For trivial
processes (e.g. the simple 1-to-1 loading of reference
data) a good practical approach is to define a standard
and to identify all processes that adhere to the
standard.
z Repository data and Code
The code and the repository data are in fact the detailed
representation of the system in formal language. It is the
representation of the business according to the system
developer. The documentation consists of comments
in the code and release notes.
z BI Solution Configuration
The configuration is the entire collection of objects
and documentation that will be handed over for
maintenance. The documentation consists of a list of
physical objects that are legible to IT specialists.
104
As described, on the horizontal axis the framework
is ordered by engineering discipline perspectives.
Deliverables follow the same design primitives within a
column, but each row assigns the meaning relevant to the
stakeholder. The table below shows the characteristics of
the engineering disciplines.
The motivation aspect forms an essential cohesive
element when combined with the Data, Function and
Timing aspects. This stems from the fact that business
rules evaluate data and then either trigger a response
or enforce a constraint. Business rules guide processes
into specific scenarios. The People and Network
perspectives bring to life what is described and form
the implementation. Models in the Data, Network and
Motivation aspects consist of components that cannot be
considered independently. These models form a network;
changes in a component cause changes in the entire
model. Therefore, these models are defined at enterprise
level, independent of a particular system’s implementation.
Components of hierarchical models, like process,
control and organisational models, can be considered
independently. The components of those models can
interfere through interfaces which allow detachment at
certain points. This allows those sections to be isolated
and therefore to be part of a particular system’s
implementation.
Below the definition of the deliverables aligned with the
engineering disciplines:
Data; z
Defines the data structures from the perspectives
of various stakeholders in terms of entities and
relationships. At the business level these are semantic
6.4 Engineering disciplines
Table 6.3 BI Engineering Framework disciplines
Aspect
Meaning
Design primitive
Business discipline
IT Discipline
Model type
Model dependency
Network
Where
Node Connection
Logistics
Infrastructure
Engineering
Implementation
Network
Motivation
Why
Goals / Means
Performance
Management
Business Rule
Engineering
Essential
Network
Data
What
Entity / Relationship
Data Management
Software or
Information
Engineering
Essential
Network
People
Who
People Labour
Organisational
Design
Interaction
Engineering
Implementation
Hierarchical
Function
How
Input Output
Business Process
Engineering
Software
Engineering
Essential
Hierarchical
Timing
When
Event Response
Planning
Software
Engineering
Essential
Hierarchical
105
BI Solution Engineering
descriptions of data and the data structures. At the IT
level these are logical and physical data models which
demand specific modelling techniques, like Data Vault
or dimensional modelling.
Function; z
Defines the processes from the perspectives of various
stakeholders in terms of input and output of data and
the necessary transformations. At the business level
these are the descriptions of business processes.
At the IT level these are logical and physical process
models.
Network; z
Defines network components from the perspectives
of various stakeholders in terms of nodes and
connections and the relevant properties such as
location, availability, volume and access security. At
the business level these are semantic descriptions of
the logistic system. At the IT level these are the logical
and physical infrastructure models.
Timing; z
Defines the temporal dependencies from the
perspectives of various stakeholders in terms of events
and responses and the relevant properties such as
timing, lead time and frequency. At the business
level these are semantic descriptions of the business
master plan. At the IT level these are logical and
physical process flow models (for batch processing) or
state transition models (for transactional processing).
People; z
Defines the human facets from the perspectives
of various stakeholders in terms of labour and the
relevant properties such as autorisation, norms and
bandwidths. At the business level these are semantic
descriptions of the organisational structure and
the associated Critical Success Factors and Key
Performance Indicators. At the IT level these are logical
and physical user interface models.
Motivation; z
Defines the decision-making rules from the
perspectives of various stakeholders in terms of
objectives and resources and the relevant properties
such as priority, value and uncertainty. At the business
level these are semantic descriptions of business
rules that converge to targets. At the IT level these are
logical and physical business rule models.
106
6.5 The BI Engineering Framework Model
The combination of the engineering disciplines and
stakeholder perspectives is a matrix of deliverables to
be managed in a BI initiative. The table below presents
the various subject models used in the engineering
framework.
The last two rows in the engineering framework are in fact
not models to deliver. The ‘Repository data & Code’ and
‘BI Solution Configuration’ do represent the results of the
engineering efforts in the previous rows, an implemented
and running BI solution. In the next sections the models
used in the BI engineering framework are defined in more
detail, grouped by the stakeholder perspective.
Table 6.4 BI Engineering Framework overview
Deliverable
Business Context
System Context
BI Architecture
System Concept
System Specification
Repository
data & Code
BI Solution
Configuration
Network
Business Locations
Logistic System
BI infra context
Logical Infra. Model
Physical Infra. Model
Infrastructure
Environments
Infrastructure
Environments
Motivation
Goals & Strategy
Objectives & Policies
BI semantic
rule model
Logical rule model
Physical rule model
Busines rule code
Business rule objects
Data
Business Terms
Semantic
data model
BI semantic
data model
Logical data model
Physical data model
Database code
Database objects
People
Organisational
Entities
Organisational
Structure
BI user task model
Logical user
interface model
Physical user
interface model
User interface code
User interface
objects
Function
Services & Products
Business
process model
BI essential context
Logical
process model
Physical
process model
Process code
Process objects
Timing
Business Events
Master Plan
BI event model
Logical control model
Physical
control model
Procesflow code
Procesflow objects
BI Engineering Framework subject models
Mission & Vision statement
Enterprise Architecture criteria, topologies and standards
Enterprise Architecture criteria, topologies and standards
107
BI Solution Engineering
6.5.1 Business Context (scoping)
The business scope defines the activities that the
organisation focuses on because the mission and vision
of the organisation deem them important. The business
scope is the first row in the Engineering Framework.
Table 6.5 BI Engineering Framework business context
Model
Business terms
Services and products
Business locations
Business events
Organisational entities
Business goals and strategy
Method
A list
A list
A list or geographical map
A list
A list
A statement
Description
The things (entities) that are important to the organisation, including a semantic definition
That which the organisation wants to deliver to its customers, summarised in the way of
business processes performed by the organisation.
Locations of active involvement by the organisation
The events that are important to the organisation
The organisational entities that are important to the organisation and the assignment of
critical success factors.
The qualitative description of objectives that the organisation strives to achieve and the strategy
chosen to achieve them. The critical success factors follow from the objectives.
The strategy may (partially) follow from a SWOT analysis.
108
6.5.2 Business context (analytical)
The business model describes how the organisation
is structured in order to achieve what is defined in the
business scope. The business model is the second row in
the Engineering Framework.
Table 6.6 BI Engineering Framework Business Context
Model
Semantic data model
Business Process model
Logistic network
Master plan
Organisational structure
Objectives & Policy or
Business plan
Method
Fact-Dimension diagram;
dimensional model
Flowchart of swimming lane
Geography
Dependency diagram
Organisational chart
Business rules dictionary
Description
The data model that describes the data structure from an analytical perspective.
This model is the main depiction of the information needed by management and staff.
The management model, for example according to INK or CPM.
The locations where management and staff functions reside. The head offices and local branches.
This model illustrates the locations where the information will be required and applied.
This may be of particular interest to businesses that operate across various time zones.
The internal alignment of activities (the response) as a result of report events.
This model will illustrate the dependencies and lead times of the reporting processes.
The organisational hierarchy. This model will illustrate the boundaries of management and staff.
The model shows the assignment of the key performance indicators (KPI’s).
The semantic business rule model consists of a hierarchical depiction of objectives and means
(business rules). At the analytical level, however, it is important to classify objectives as operational,
tactical or strategic ones and to define the relevant means to achieve them. A BI solution can monitor
and enforce business rules at the operational level and assist management in achieving their
assigned objectives.
109
BI Solution Engineering
6.5.3 System Context
The system context describes the capabilities of the
system within the scope and the criteria of the BI
strategy. Synonymous terms would be: Definition, System
Requirements. The documentation consists of models
that contain natural language which makes it legible
for the ‘user organisation’. These models describe the
external behaviour and not the internal behaviour of the
information system. The required capabilities are already
present implicitly in the aforementioned business model.
The system context, however, explicitly states the items
in the business model, that are relevant for a specific IT
solution. It offers the user organisation and the project
management a specific definition of the scope of the
required IT solution.
Table 6.7 BI Engineering Framework System Context
Method
A cross-section of the
FDD or dimensional model
as documented in the
business model
Context diagram of
level-0 DFD
Context diagram
displaying the devices.
Note: combined with
business locations as
documented in the
business model
Event list
Formalised table or
UML activity diagrams
See the business model
Description
The definition of the system in terms of data and information.
The explicit listing of facts and dimensions as supported by the data from external sources
The definition of the system in terms of terminators (users and systems) and
corresponding data flows.
The definition of the system in terms of attached devices and the types of connections,
taking into account the various locations and the logistic system.
The definition of the system in terms of business events and the expected input and
output responses.
The definition of the system in terms of tasks and labour with corresponding KPI’s.
The nature of the labour offers insight into the most effective method of presenting information
to a particular type of user.
The definition of the system in terms of objectives and business rules.
The explicit listing of the supported objectives and business rules.
Model
BI Semantic data model
Reference to / or subset of
the semantic data model
BI Essential context
Top-level design
consolidating business
requirements
BI Infrastructure context
Reference to / or subset of
the logistic system
BI Event list
Top level design
consolidating business
requirements
BI User task model
Top level design
consolidating business
requirements
BI Semantic business
rule model
Reference to / or subset
of the business plan
110
6.5.4 BI Architecture
Key concerns follow from the scope and criteria in the
BI strategy and the requirements. The BI architecture
describes the key design decisions that address those key
concerns. The architecture also provides so-called key
concepts to enforce a standard way of implementation of
certain subjects. Late arriving dimensions for example can
be dealt with once as a key concept and within the system
concept referring to the key concept is sufficient then.
Table 6.8 BI Engineering Framework Architecture
Model
Topology for data
processing
Product topology
Method
Template
Template
Description
The data logistics from source to report. Possible topologies are Hub-Spoke,
bus structure or separate data marts.
The software stack for ETL, Reporting & Analysis, data storage and the OS.
111
BI Solution Engineering
6.5.5 System Concept
The system concept describes the internal behaviour
of the system. It is the representation of the business
according to the system designer. Using the system
concept the solution can be verified against the system
context and the architecture. Documentation consists
of formal models – at the attribute level – that are
legible to experienced IT generalists. At this point the
documentation is still independent of technology. As such,
the documentation should not be cryptic or specific to a
certain product.
Table 6.9 BI Engineering Framework System Concept
Model
Logical data model
Logical process model
Logical infrastructure model
Logical control model
Logical user
interface model
Logical business rule model
Method
Entity relationship
diagram (ERD)
Data flow diagram (DFD)
for ordering and overview.
Mapping matrix for the
specification of the
transformations.
3 tiered model
Workflow / dependency
diagram
State transition
diagram (STD )
Fact dimension diagram
Hierarchy of rules with
the following syntax:
IF condition THEN action
taking into account priority
and importance.
Description
This model describes the entities and relationships. Depending on the architecture, the most
appropriate modelling methodology can be chosen, such as normalised (3NF), Data Vault or
dimensional modelling.
This model describes the transformation processes; broken down to a level that shows how the
output is generated. The level of detail is sufficient when an accurate estimate can be given and test
cases can be designed.
This model describes the setup of the application, middleware and data layers.
When designing the model topics of importance are the OS, the file system, the connections (lines),
the storage architectures, the firewalls and the routers.
This model describes the various states in which a system can reside. The model should also
enforces that the system can only reside in a particular predefined state and that changing states
can only takes place in a controlled manner.
For regular data warehouses this is usually a simple model; a workflow diagram or dependency
diagram will often suffice.
For large data warehouses or in the case of real-time BI with transactional or time-dependent input
this is a very important model.
This model describes the user interfaces that the users need within their assigned tasks.
The description covers the information that the user interface portrays in the form of a cross-section
of the semantic data model. The design is conform the assigned KPI’s.
This model is a hierarchical depiction of the business rules in terms of entities and attributes
according to the logical data model. The condition of a business rule evaluates a historical dataset.
When the condition results in TRUE a certain action follows. Examples of such an action can be the
firing of another business rule, returning a value, manipulating a data element or sending a message.
Within the BI discipline the following uses of business rules apply:
– Evaluating data quality (plausibility of the data)
– Revealing the degree to which the operational business follows the business rules.
– A special variation of (2) is Business Activity Monitoring (BAM)
112
6.5.6 System Specification
The system specification describes the physical details
of the system in order to embed the desired behaviour
and to enforce a particular construction method. It is the
representation of the business according to the system
developer. Documentation consists of models and
specifications that are legible to IT (product) specialists.
At this level the documentation does depend on the
technology. Specifications are allowed to be encoded
and specific to a certain product and, thereby, fitting
well into the ‘culture’ of a technical competence. The
system specification is an augmentation of the system
concept, containing technical instructions. A system
specification is especially applicable in situations where
complex and risky components have to be built or when
less experienced developers need to perform a task and
need support in doing so. In both situations it allows for
the technical solution to be evaluated within the team
before commencing the realisation. For trivial processes
(e.g. the simple 1-to-1 loading of reference data) a good
practical approach is to define a standard and to identify
all processes that adhere to the standard.
Table 6.10 BI Engineering Framework System Specification
Model
Physical data model
Physical process model
Physical
infrastructure model
Physical control model
Physical user
interface model
Physical business
rule model
Method
Template
Template
Template
Template
Template
Template
Description
This model offers database specific instructions for what techniques to use (or to avoid).
Other specifications are schema’s, data files and parameters like block size etc.
This model offers ETL tool specific instructions for what techniques to use (or to avoid).
Furthermore there is a breakdown into tool specific process steps.
This model offers hardware specific instructions for what techniques to use (or to avoid).
Other specifications are of hardware and network components, software versions of the OS,
the network and the middleware.
Basically, this information should be sufficient to request an infrastructure administrator or
supplier for an offer.
This model offers workflow tool specific instructions for what techniques to use (or to avoid).
Furthermore there is a breakdown into tool specific states
This model offers reporting tool specific instructions for what techniques to use (or to avoid).
Furthermore there is a breakdown into tool specific reporting structures
(menu- and authorisation matrices)
This model offers business rule engine specific instructions for what techniques to use (or to avoid).
Other specifications are of search algorithms, sourcing technologies etc.
8
Winning the grand prix R
acing intelligence FIA compliance Predictive analytics Authenticati
on O
pera
tiona
l BI A
utho
risat
ion S
ingl
e
source of fa
cts Car simulation toolkit
Business case Acquiring circuit data Com
petitive intelligence Operational excellence Operational BI W
inni
ng t
he g
rand
prix
Rac
ing intelligence FIA compliance
P
redictive a nalytics A
uthentication Operational BI Authorisati
on S
ingl
e so
urce
of
fact
s Car
sim
ulat
ion
toolk
it Business case Acquiring circuit
170
Within this book we use a case to illustrate the vision
and approach we take in achieving Business Intelligence
solutions. The information used in this case is based on
public available sources. The case does however not
necessarily reflect the actual situation at Ferrari. The
case is used to demonstrate the activities to perform and
the products to deliver in the defined stages of the BI
Framework. The table below present the case against the
BI Framework stages.
8.1 Introduction
Table 8.1 Ferrari case - BI Framework stages
BI Framework stage
BI strategy
BI definition
BI development
BI exploitation
Ferrari case
Strategy study
Feasibility study
Requirements analysis
Demonstration
BI architecture
Data warehouse realisation
Reporting and analytics realisation
Data quality
Data vault modelling
Dimensional modelling
Exploitation
Since 1950 Ferrari has been at the peak of F1. When the
titles come along, and there have been many, the season
has been viewed positively. But even when championships
were not won, Ferrari was at the centre of things. Success
hasn’t always come along and there have always been
times of hardship. Racing will always be fundamental to
Ferrari. The history of Formula 1 is tied to that of Ferrari.
The Ferrari F1 team is the only team to have taken part
in all world champion races in the maximum formula that
have taken place until know. In describing each Ferrari
model, inevitably, you will find some information on the
drivers that won on circuits around the world as they
8.2 Strategy Study
171
too are part of our history. Of course, our fans are also
fundamental and their joy adds a shine to all our victories.
2005/2006 Evaluation
After a six year winning streak, the Ferrari run comes to
an end. Nine wins, seven pole positions and 201 points
on the board: that is a resume of Ferrari’s 2006 World
Championship. The figures are impressive but they were
not enough to take either of the two titles. 2005 has been a
very difficult year and on the eve of the Bahrein Grand Prix,
the first round of the new season, there was tension in the
air. A less than perfect reliability record and a few too many
mistakes proved very costly. (Source: www.ferrariworld.
com)
Business strategy Ferrari F1 team
After two years without success Ferrari really needs a
successful season to live up to its reputation. Success in
F1 obviously has a positive effect on the image and sales of
Ferrari Company as a whole. To gain success next season
the Ferrari F1 team, next to excellent drivers and cars, will
focus on:
Investing in Racing intelligence, leverage past race 1.
experience, combined with long-term weather
forecasting, to gain insight in specific conditions and
requirements for each race in the new season and to
predict racing conditions for upcoming races.
Reliable pits-driver communication, preventing last 2.
season mishaps.
Optimise information delivery to the FIA (Fédération 3.
Internationale, de l’Automobile), to stay compliant with
regulations and prevent fines or worse penalties.
BI Strategy Ferrari F1 team
The Ferrari F1 team needs a Business Intelligence solution
to support reporting and analysis on racing statistics
and long-term weather forecasting. The same BI solution
will also deliver the necessary information delivery to the
FIA. Reliable pits-driver communication is of course very
important but will not be supported by the BI solution due
to the pure operational nature of this process.
Current BI situation
Currently Ferrari does use the circuit information
systems to acquire race statistics during a race. The
race statistics are used to evaluate the race but are not
stored historically. Information about the performance
of the cars in the race is fed real-time from the cars into
the pit system to determine necessary pit stops and/or
adjustments to the cars’ configurations. After the race this
data is sent to the Ferrari Factory for further analysis and
historical perspectives. Race analysts and constructors
in the Ferrari team are used to working based on their
experience and available real-time data and do not use
8.3 Feasibility Study
Ferrari Case
172
any historical data. Reporting to the FIA is performed by
manually typing up a report based on data available from
the pit systems, where traceability and audit ability of this
information is not guaranteed.
Gap Analysis
The Ferrari F1 team does not have any serious BI
capabilities available yet to support the business strategy
of the team. Neither a BI system nor experience with trend
analysis and predictive analysis is available within the
team. Also historical data is not available, except perhaps
for car statistics within the Ferrari Factory. Reporting to
the FIA is not compliant with traceability and audit-ability
requirements of the FIA. The Ferrari F1 team has to
invest in acquiring the right data, BI technology, skills and
capabilities to fulfil the requirements as stated in the BI
strategy.
173
Based on interviews and workshops with the
constructors and race analysts of the F1 team an
information requirements matrix is defined, indicating
the measurements and the dimensional view on the
measurements for both the constructors and the race
analysts.
Also, in this early stage a data source analysis is performed
to ensure the availability of data or to identify any data
sourcing issues upfront. The analysis shows that the F1
team relies on a lot of external data. Efforts can now be
started to acquire this external data to support the future
BI solution.
8.4 Requirements Analysis
Race Results
Position Time
Race Analysts
Race Analysts &Constructors
Race Analysts &Constructors
Race Analysts &Constructors
N/A
FIA Database forhistory, Pit system
for actuals
Constructors
Constructors
Constructors
Race Analysts & Constructors
Constructors
Ferrari Factory Reseach labfor history, car telemetrics
system for actuals
Race Analysts &Constructors
Race Analysts
Race Analysts
Race Analysts
N/A
FIA Database forhistory, Weather
forecast agency forpredictions
Dimensions
Location Continent Country CircuitCalendar Year Quarter Month Day Week DayTime Hour Min Sec MsecRace Type Lap Sector Corner
Data SourceMeasures
MeasuresCar Statistics
Oil Temp Tire Pres Susp.
Weather
Temp Humidity
Data SourceDimensions
FIA Database
Generate in BISolution
Generate in BISolution
CircuitDatabase
Ferrari Case
174
Demonstration8.5
To give the constructors and race analysts some idea
of the advantages of a BI solution, a demonstration
environment is created with some relevant sample data
and some reporting and analysis capabilities, using
standard functions of Excel.
For the constructors a simple model is configured to
predict the average and maximum lateral G-force of
the car on a specific circuit based on races on that
circuit in the past. G-force prediction is very important
for the constructors to optimise the configuration of the
suspension of the car.
For the race analysts a simple model is configured to
predict the required minimum lap time and average lap
time on a specific circuit based on races on that circuit in
the past. Lap time prediction is very important for the race
analysts to plan the right racing strategy with the drivers.
Both demonstrations are realised using sample data and
very basic analytical functionality. By selecting the most
relevant analysis subjects the future end-users, are now
convinced of the benefits of a BI solution.
4,0
3,5
3,0
2,5
2,0
1,5 2002 2003 2004 2005 2006 2007
1,9 2,1 2,0 2,4 2,5 2,6 3,0 3,2 3,4 3,2 Season
3,4Prediction
2,7Prediction
G-Force Statistics
Lat
eral
G-F
orc
e
Agv Lateral G-Force
Max Lateral G-Force
1:37:55
1:35:02
1:32:10
1:29:17
1:26:24
1:23:31
1:20:38
1:17:46
1:14:53 2002 2003 2004 2005 2006
1:32:03 1:30:21 1:35:06 1:28:12 1:27:05 1:28:02 1:26:01 1:25:34 1:24:01 1:24:04 Season
1:27:00Prediction
Laptime Statistics
Lap
tim
e
Agv Lap-Time
Max Lap-Time
1:22:00Prediction
4,0
3,5
3,0
2,5
2,0
1,5 2002 2003 2004 2005 2006 2007
1,9 2,1 2,0 2,4 2,5 2,6 3,0 3,2 3,4 3,2 Season
3,4Prediction
2,7Prediction
G-Force Statistics
Lat
eral
G-F
orc
e
Agv Lateral G-Force
Max Lateral G-Force
1:37:55
1:35:02
1:32:10
1:29:17
1:26:24
1:23:31
1:20:38
1:17:46
1:14:53 2002 2003 2004 2005 2006
1:32:03 1:30:21 1:35:06 1:28:12 1:27:05 1:28:02 1:26:01 1:25:34 1:24:01 1:24:04 Season
1:27:00Prediction
Laptime Statistics
Lap
tim
e
Agv Lap-Time
Max Lap-Time
1:22:00Prediction
175
Based on the strategy study and a very successful
demonstration of how a Business Intelligence solution
could support the F1 team a decision is made to
implement a brand new Business Intelligence solution for
the Ferrari F1 team. The solution must provide all required
information by the FIA and support the race analysts and
the constructors with predictive analytics. Data will be
extracted from multiple sources and historical data must
be stored to provide trend analysis capabilities. Information
to the FIA will be provided with a secure publication
mechanism, audit-able and traceable. Information for the
constructors and race analysts will be provided in multiple
formats to maximise flexibility, however authentication and
authorisation are very important.
In the table below the requirements of the new BI
solution are mapped onto a standardised BI Architecture
framework.
Ferrari needs the most comprehensive architecture
scenario, based on the mapping of the requirements onto
the BI architecture functions. Now we know what type of
functions and supporting software we have to consider
when starting development.
8.6 BI Architecture
Function in Architecture
Extract
Integration
Storage
Subject Area
Function
Utility
Publish
Personalize
Present
Ferrari F1 BI Solution
Data from the circuit databases and the FIA database will be purchased and delivered. Historical data from
the Ferrari factory research lab will be acquired. All data from the pits and car systems will be collected.
All acquired data will be integrated to provide maximum support to the race analysts and constructors.
A single source of facts, keeping track of all historical data, is very important for Ferrari.
Subsets of data will be created to support the different information needs of the FIA, the race analysts
and the constructors.
To map our data to the information requirements of the FIA, specific calculations and aggregations
will be performed.
Analytical tools will be provided to the race analysts to perform simulations.
Authentication and authorisation are very important due to the value of the available information to
our competitors. A secure publication mechanism has to be provided.
The information to the FIA will be delivered compliant with the specific interface requirements of
the FIA officials.
All BI products will be presented trough the standardised portal of the Ferrari F1 team.
Ferrari Case
176
Data warehouse Realisation8.7
As defined in the BI architecture a data warehouse with
multiple data marts has to be developed to support the
information requirements of the FIA, the race analysts
and the constructors. Multiple data sources will be
extracted and integrated into a ‘singe source of facts’. The
development will be performed in three releases, based
on the priorities set by the Ferrari F1 team. The figure
below presents an overview of the components that will be
developed in each of the three increments.
Based on the priorities set by the F1 team and the
required source data for each data mart the releases are
defined and developed accordingly. The data warehouse
will be modelled using Data Vault, the data marts using
dimensional modelling.
Release 1
Release 1
Release 1
Release 2Release 2
Release 3Release 3
Release 3
FIA ComplianceData Mart
Car AnalyticsData Mart
Race AnalyticsData MartWeather
Forecasts
CircuitData
CarTelemetrics
Pitsdata
FIAData
Extract, Integration, Storage, Access
Ferrari F1Data Warehouse
177
Reporting and analytics Realisation8.8
In the first increment the standard reports to comply
with FIA regulations will be developed based on the
FIA compliance data mart. In the second increment the
information needs of the constructors will be met by
implementing a car simulation modelling toolkit and by
implementing OLAP functionality. These functions enable
the constructors to perform simulations, ad-hoc detailed
analyses and development of standardised reports. In the
third increment the race analysts will be provided with ad
hoc analysis and reporting capabilities. The authentication,
authorisation, publication and distribution of all information
products will be managed trough the existing portal of the
Ferrari F1 team.
FIA ComplianceData Mart
Car AnalyticsData Mart
Race AnalyticsData Mart
Function, Utility, Publish, Personalize, Present
FerrariF1
Portal
FIAReports
Car SimulationModels
Authentication,Authorisation,Publication,Distribution
CarCubes
RaceCubes
CarReports
Race Analysts
Constructors
FIA
CarReports
Ferrari Case
178
Data Quality8.9
In the business strategy of the Ferrari F1 team one focus
area was mentioned, which we could not cover with a
Business Intelligence initiative:
Reliable pits-driver communication, preventing z
mishaps of last season to happen again.
Let us to take a closer look at the reasons why this issue
has gained this level of interest of the F1 management
team of Ferrari. Last season the following peace of pits-
car communication between a German driver and an
Australian constructor became critical. The driver was on
pole position and racing for the champions title. The oil
temperature in his car is rising and he needs to now his
position.
The driver did not finish this race and ends up third in the
overall championship. Analyzing this of communication
reveals some serious quality issues:
Oil temperature was within margins, but the car caught z
fire? Was temperature given in degrees Celsius or
Fahrenheit? Considering the international set up of the
F1 team some agreements on this would have been
helpful.
Why did the driver lose his position to the second z
driver of the race, without knowing? His position in
the race was not noticed by the pits, causing serious
problems on the track.
Lap
34
35
36
37
38
39
Pits
Within margins, keep pushing.
Pole position, your are half a lap before.
You lapped him already I guess.
Within margins, keep pushing.
…
…
Driver
Oil temperature rising to 200, should I make a pitstop?
Current position?
Who is driving close behind me?
Oil temperature is now rising to 250!
I am losing my position!
Engine on fire!
179
Data Vault Modelling8.10
Based on the information requirements matrix and
mapping to the available sources the following business
keys are defined for the F1 datawarehouse data model:
Hubs
Car Hub
Driver Hub
Circuit Hub
Race Hub
Definition
The unique identification of a car in the Ferrari F1 team.
The unique identification of a driver in the Ferrari F1team
The unique identification of a circuit in the F1 Grandprix organization
The unique identification of a race in the F1 Grandprix organization
Based on the information requirements matrix and
the performed mapping to the available sources the
following relevant relationships are defined for the F1
datawarehouse data model:
Links
Race Event Link
Car Performance Link
Driver Performance Link
Linked hubs
Race, Circuit
Car, Race
Driver, Race
Definition
Identifies the occurence of a race on a circuit
Identifies the telemetrics of a car in a specific race
Identifies the performance of a driver in a specific race
Ferrari Case
180
We can now start drawing the data vault data model,
associating the hubs with the links.
Satellites
Circuit Satellite
Driver Satellite
Car Satellite
Race Satellite
Car Performance Satellite
Driver Performance Satellite
Linked to
Circuit Hub
Driver Hub
Car Hub
Race Hub
Car Performance Link
Driver Performance Link
Definition
Containts descriptive attributes of a circuit
Contains descriptive attributes of a driver
Contains descriptive attributes of a car
Contains descriptive attributes of a race
Contains the performance attributes of a car in a particular race with a particular driver.
Contains the performance attributes of a driver in a particular race.
Race Event Link Circuit Hub
Race Hub Car Performance Link
Driver Performance Link
Car Hub
Driver Hub
Based on the information requirements matrix and
the performed mapping to the available sources the
following descriptive attribute sets are defined for the F1
datawarehouse data model:
181
When we add the defined satellites to the data vault
model we end up with the following model for the F1 data
warehouse.
Race Event Link
Race Satellite Race Hub
Driver Performance Satellite
Driver Performance Link
Driver HubDriver Satellite
Circuit Hub Circuit Satellite
Car Performance Link
Car Performance Satellite
Car Hub
Car Satellite
Ferrari Case
182
CalendarDimension
DriverDimension
RaceDimension
CircuitDimension
DriverPerformance
Fact
CarDimension
RaceDimension
CalendarDimension
CircuitDimension
CarPerformance
Fact
Dimensional Modelling
8.11 Based on the information requirements matrix and the
mapping to the available sources; two subject areas are
defined. The first one measures the performance of the
driver, the second one is measuring the performance
of the car. Both subject areas are modelled in a ’star
scheme’ below.
Based on the future use and granularity of the facts we
would share the calendar, circuit and race dimension
between the two ’star schemes’ making them ’conform
dimensions’.
183
Exploitation8.12
Ferrari managed to implement the first two increments
of their BI solution, including a strong maintenance and
support organisation. In their opinion the BI solutions
contributed to the success of the 2007 season.
The season 2007 will be remembered in the history of F1 as fiercely contested and one of the most spectacular ones of the entire history of F1. Three drivers were only one point apart at the end of the last race, while the Finn from Ferrari, Kimi Raikonen, gained the laurels and became World Champion. With nine victories Ferrari gained the Constructors Title, after three years without. (Source: www.ferrariworld.com)
Ferrari Case
184
ReferencesAbonyi, J., Feil, B., and Abraham, A.
Cios, K. J., Pedrycz, W., Swiniarski,
R. W., and Kurgan, L. A.
CRISP-DM
Dan Linstedt
Dy, J. G., and Brodley, C. E.
Fayyad, U., Piatetsky-Shapiro, G.,
and Smyth, P.
Gartner
Inmon
Imhoff
Kaplan and Norton
Kimball
Mimno
Miradi, M.
Moss
NESMA
OVUM
TDWI
‘Computational Intelligence in Data Mining’, Informatica, 29, 3-12.
‘Data Mining, A Knowledge Discovery Approach’, Springer, New York.
Cross Industry Standard Process for Data Mining. (www.crisp-dm.org)
‘The Business of Data Vault Modelling’, This book presents the business of next generation data warehousing,
including the Data Vault model and approach or methodology. (www.danlinstedt.com)
‘Feature Selection for Unsupervised Learning.’, Journal of Machine Learning Research, 5, 845-889
‘From Data Mining to Knowledge Discovery in Databases.’, American Association for Artificial Intelligence.
Gartner, Inc. (NYSE: IT) is the world’s leading information technology research and advisory company. (www.gartner.com)
Bill Inmon, world-renowned expert, speaker and author on data warehousing, is widely recognized as the ‘father of data
warehousing.’ He is creator of the Corporate Information Factory and more recently, creator of the Government Information
Factory. (www.cif.com)
Claudia Imhoff, Ph.D., is the President and Founder of Intelligent Solutions, a leading consultancy on data warehousing
and business intelligence technologies and strategies. (www.intelsols.com)
Founders of the balanced score card approach (www.valuebasedmanagement.net)
Worldwide known innovator, writer, educator, speaker and consultant in the field of data warehousing. He has remained
steadfast in his long-term conviction that data warehouses must be designed to be understandable and fast. His books
on dimensional design techniques have become the all time best sellers in data warehousing. (www.kimballgroup.com)
Mr. Mimno has accumulated extensive practical experience in identifying mistakes that are commonly made in the
development of data warehousing applications, and assists MMH clients in building successful data warehouses
incrementally.(www.mimno.com)
‘Knowledge discovery and pavement performance, data mining’, Wohrmann Print Service, The Netherlands.
Ms. Moss has written a number of books, white papers, and articles on business intelligence, project management,
information asset management, development methodologies, data quality, and organizational realignments. In 1991 she
self-published her first methodology RSDM 2000, Relational System Development Methodology, Volumes I & II. Since
then, she has co-authored the books Data Warehouse Project Management, Impossible Data Warehouse Situations, and
Business Intelligence Roadmap, and Data Strategy
NESMA (Netherlands Software Metrics Association), the second largest Functional Sizing Measurement Organisation in
the world.(www.nesma.nl)
At Ovum we fully understand convergence across telecoms, IT services and software. We invest heavily in researching
what is happening in a market that is dynamic and full of risk and reward. We analyse the changes and identify the threats
and opportunities ahead for our clients. (www.ovum.com)
TDWI (The Data Warehousing Institute™) provides education, training, certification, news, and research for executives
and information technology (IT) professionals worldwide. Founded in 1995, TDWI is the premier educational institute for
business intelligence and data warehousing. (www.tdwi.org)
185
Treacy and Wiersema
Zachman
Founders of the value discipline model (www.valuebasedmanagement.net)
John A. Zachman is the originator of the ‘Framework for Enterprise Architecture’ which has received broad acceptance
around the world as an integrative framework, or ‘periodic table’ of descriptive representations for Enterprises.
(www.zachmaninternational.com)
186
accountable ....................................................................................................................................................................................................... 22, 36, 72
Analytics Culture ................................................................................................................................................................................................................... 43
appliances .................................................................................................................................................................................................................... 83
architecture design ....................................................................................................................................................................................................... 73, 79, 83
Audit Services ........................................................................................................................................................................................................... 68, 101
balanced scorecard ................................................................................................................................................................................................. 28, 29, 38, 44
Basel II ............................................................................................................................................................................................................. 23, 25
benchmark .................................................................................................................................................................................................. 10, 49, 59, 61
BI CC .................................................................................................................................................................................................. 10, 52, 53, 54
BI Development .........................................................................................................................................................................11, 53, 59, 67, 85, 98, 99, 100
BI Exploitation .......................................................................................................................................................................................................67, 94, 100
BI foundation .................................................................................................................................................................................................. 36, 37, 38, 72
BI lifecycle .......................................................................................................................................................................................... 14, 66, 68, 98, 100
BI projects .................................................................................................................................................................................... 51, 52, 53, 54, 99, 127
BI strategy ....................................................................... 52, 53, 66, 67, 68, 69, 70, 71, 72, 73, 85, 86, 94, 98, 100, 102, 103, 109, 110, 122, 171, 172
BI value creation ................................................................................................................................................................................................................... 40
Blended delivery .................................................................................................................................................................................................. 11, 55, 56, 58
Business Analysis ....................................................................................................................................................................................................... 52, 66, 69
Business Analytics .............................................................................................................................................................................................................. 38, 40
Business Context ................................................................................................................................................................................... 100, 102, 106, 107, 108
Business modelling ................................................................................................................................................................................................................... 90
Business Modelling .................................................................................................................................................................................................................... 38
business performance ............................................................................................................................................................................................................. 25, 38
Business reporting .............................................................................................................................................................................................................. 37, 90
business value discipline .................................................................................................................................................................................................................... 18
Cause Effect ................................................................................................................................................................................................................... 44
change cost ................................................................................................................................................................................................................... 60
Client Relationship Management ................................................................................................................................................................................................................... 82
CMMI .............................................................................................................................................................................................................. 55, 56
Configuration .....................................................................................................................................................................................................79, 103, 174
construction cycle .............................................................................................................................................................................................................. 40, 41
consumption cycle ................................................................................................................................................................................................................... 41
content rationalisation ................................................................................................................................................................................................................... 50
Index of Terms
187
Corporate Performance Management ......................................................................................................................................................................................... 28, 29, 34, 38, 186
cost effective BI ............................................................................................................................................................................................................. 48, 56
cost reduction ........................................................................................................................................................................................................... 49, 127
Critical Success Factors .......................................................................................................................................................................................... 28, 30, 36, 40, 105
Customer Intimacy .................................................................................................................................................................................................................... 19
customer profitability ........................................................................................................................................................................................................ 26, 27, 59
Customer Relationship Management ......................................................................................................................................................................................... 25, 34, 38, 70, 154
data governance ................................................................................................................................................................................................ 36, 37, 72, 133
Data Integration .................................................................................................................................................... 37, 39, 85, 87, 118, 121, 130, 131, 159, 186
data management .................................................................................................................................................................................... 36, 37, 38, 72, 87, 131
Data Migration ...................................................................................................................................................................................................... 37, 39, 127
Data mining ................................................................................................................ 26, 44, 90, 153, 154, 155, 156, 158, 159, 160, 161, 163, 164, 165
data modelling ........................................................................................................................................................... 37, 55, 58, 88, 116, 134, 135, 137, 146
data models .................................................................................................................................................................. 74, 83, 88, 90, 105, 129, 134, 147
data ownership ............................................................................................................................................................................................................. 36, 72
Data Quality ............................................................................................................................................................................. 39, 116, 126, 127, 170, 178
Data Resource Management ...................................................................................................................................................................................................... 67, 95, 100
Data Vault ............................................................................................................... 88, 105, 111, 116, 124, 134, 135, 136, 138, 140, 141, 142, 146, 176
DBMS ................................................................................................................................................................................................................... 88
definition of BI ................................................................................................................................................................................................................... 34
dimension .................................................................................................................................... 60, 74, 76, 77, 124, 147, 149, 150, 151, 152, 153, 182
Dimensional modelling ............................................................................................................................................................. 88, 105, 116, 146, 147, 153, 176, 182
document warehouse .......................................................................................................................................................................................................... 161, 162
DW2.0 .................................................................................................................................................................................................................. 162
engineering framework .............................................................................................................................................................................. 98, 99, 100, 101, 104, 106
Enterprise Application Integration ............................................................................................................................................................................................................. 39, 80
Enterprise Content Management ......................................................................................................................................................................................... 34, 35, 39, 91, 160
Enterprise Resource Management ............................................................................................................................................................................................................. 70, 82
Enterprise Value Management .................................................................................................................................................................................................. 18, 19, 20, 38
estimating ...................................................................................................................................................................................................... 59, 61, 124
ETL ........................................................................................................................................................... 56, 58, 83, 87, 116, 123, 124, 125, 126
expert estimation ............................................................................................................................................................................................................. 59, 61
188
Extract more value from customer
interactions ............................................................................................................................................................................................................. 22, 25
facts ..................................................................................................................................................... 44, 60, 74, 76, 81, 146, 147, 149, 150, 182
Feasibility study .......................................................................................................................................................................................... 52, 66, 69, 71, 171
FPA ................................................................................................................................................................................................................... 61
funding ................................................................................................................................................................................................................... 53
granularity ........................................................................................................................................................... 76, 77, 88, 90, 140, 147, 148, 159, 182
increments .................................................................................................................................................... 38, 56, 67, 73, 76, 79, 83, 85, 86, 176, 183
Information Culture ................................................................................................................................................................................................................... 43
Information Delivery Management .............................................................................................................................................................................................................. 67, 94
Information Lifecycle Management ................................................................................................................................................................................................................... 38
Information Management Culture ................................................................................................................................................................................................................... 70
Information Security .............................................................................................................................................................................................................. 57, 77
Infrastructure rationalisation ............................................................................................................................................................................................................. 50, 51
investment ............................................................................................................................................................... 11, 20, 21 42, 43, 57, 59, 60, 61, 85
Key Performance Indicators ................................................................................................................................................................................................ 27, 28, 30, 105
lifecycle management ............................................................................................................................................................................................................. 38, 41
Maintenance and Support ..................................................................................................................................................................................................... 95, 98, 183
Master Data Management ............................................................................................................................................................................................................. 39, 50
maturity ............................................................................................................................................................. 10, 41, 42, 43, 44, 45, 56, 66, 68, 85
measures ............................................................................................................................................... 28, 30, 36, 38, 57, 77, 146, 147, 148, 149, 182
Meta data ................................................................................................................................................................................................................... 83
MIFID ................................................................................................................................................................................................................... 23
offshore .................................................................................................................................................................................................. 11, 51, 55, 58
OLAP ................................................................................................................................................ 44, 88, 90, 153, 154, 158, 159, 160, 163, 177
Operational Excellence .............................................................................................................................................................................................................. 19, 20
opportunity matrix ................................................................................................................................................................................................................... 49
predictive model ............................................................................................................................................................................................................. 26, 27
Processes and organisation
optimisation ............................................................................................................................................................................................................. 50, 51
Product Leadership .................................................................................................................................................................................................................... 19
project cost ............................................................................................................................................................................................................. 60, 61
Query & Reporting Services ................................................................................................................................................................................................................... 90
189
reduce churn ............................................................................................................................................................................................................. 25, 26
Repository .......................................................................................................................................................................... 100, 102, 103, 106, 160, 164
risk & compliance framework ................................................................................................................................................................................................................... 25
ROI ...................................................................................................................................................................................................... 21, 61, 134
SAS-70 ................................................................................................................................................................................................................... 57
service cost ............................................................................................................................................................................................................. 60, 61
snowflake .......................................................................................................................................................................................................... 149, 153
Solvency II ................................................................................................................................................................................................................... 23
SOX ................................................................................................................................................................................................................... 23
stakeholders .............................................................................................................................................................. 18, 22, 23, 69, 78, 85, 101, 104, 105
star ..................................................................................................................................................................... 88, 117, 134, 149, 152, 153, 182
strategy cycle ................................................................................................................................................................................................................... 40
Strategy study .................................................................................................................................................................................. 66, 68, 69, 70, 170, 175
System Concept ........................................................................................................................................................................................... 103, 110, 111, 112
System Context ................................................................................................................................................................................... 100, 102, 103, 107, 111
System Specification .................................................................................................................................................................................. 100, 102, 103, 106, 112
TCO ........................................................................................................................................................................................... 41, 43, 49, 55, 99
Testframe ................................................................................................................................................................................................................... 93
text mining ................................................................................................................................ 26, 38, 90, 116, 153, 154, 160, 161, 162, 163, 164, 165
traceable .................................................................................................................................................................................... 22, 24, 36, 72, 99, 175
Track performance and align metrics
across the organisation ............................................................................................................................................................................................................. 22, 28
Track risk and compliance ............................................................................................................................................................................................................. 22, 23
V-model ................................................................................................................................................................................................................... 93
190
Figure 2.1 Value disciplines .................................................................................................................................................................................................................... 19
Figure 2.2 Enterprise Value Management ................................................................................................................................................................................................................. 20
Figure 2.3 BI Spend Prediction (Source Gartner, Feb 2008) .................................................................................................................................................................................... 21
Figure 2.4 Regulations introduced (Source: Gartner) ............................................................................................................................................................................................... 23
Figure 2.5 Logica GRC Framework .................................................................................................................................................................................................................... 24
Figure 2.6 Predictive model generation (The CRISP DM Model) .............................................................................................................................................................................. 26
Figure 2.7 Predicting bad debt customers ............................................................................................................................................................................................................... 27
Figure 2.8 Lack of alignment on vision, mission and strategy .................................................................................................................................................................................. 29
Figure 2.9 BI and CPM alignment .................................................................................................................................................................................................................... 30
Figure 3.1 Challenges for BI .................................................................................................................................................................................................................... 36
Figure 3.2 Business Intelligence foundation ............................................................................................................................................................................................................. 37
Figure 3.3 Value creation with BI .................................................................................................................................................................................................................... 40
Figure 3.4 Maturity model (source: TDWI) ................................................................................................................................................................................................................ 42
Figure 3.5 BI Maturity by Logica .................................................................................................................................................................................................................... 44
Figure 4.1 Cost reduction roadmap (illustration) ....................................................................................................................................................................................................... 50
Figure 4.2 BI Competence Center .................................................................................................................................................................................................................... 52
Figure 4.3 Blended delivery model .................................................................................................................................................................................................................... 58
Figure 5.1 BI Framework .................................................................................................................................................................................................................... 66
Figure 5.2 Granularity diagram .................................................................................................................................................................................................................... 76
Figure 5.3 Architecture components .................................................................................................................................................................................................................... 81
Figure 5.4 Sequential and Iterative Development ..................................................................................................................................................................................................... 86
Figure 5.5 Star scheme .................................................................................................................................................................................................................... 88
Figure 5.6 Universal testing model .................................................................................................................................................................................................................... 93
Figure 6.1 BI Engineering Framework .................................................................................................................................................................................................................. 101
Figure 7.1 Dimensional Data Warehouse ETL Framework ...................................................................................................................................................................................... 123
Figure 7.2 Data Quality skills ...................................................................................................................................................................................................................131
Figure 7.3 Data Quality Score card .................................................................................................................................................................................................................. 132
Figure 7.4 Continuous data quality improvement ................................................................................................................................................................................................... 133
Figure 7.5 Loading hubs .................................................................................................................................................................................................................. 143
Figure 7.6 Loading links .................................................................................................................................................................................................................. 144
Figure 7.7 Loading Satellites .................................................................................................................................................................................................................. 145
Figure 7.8 End dating Satellites .................................................................................................................................................................................................................. 146
Figure 7.9 Granularity Diagram .................................................................................................................................................................................................................. 148
Index of Figures
191
Figure 7.10 The Crisp-DM Model .................................................................................................................................................................................................................. 156
Figure 7.11 Data Mining Techniques .................................................................................................................................................................................................................. 157
192
Table 1.1 Target audience .................................................................................................................................................................................................................... 14
Table 2.1 Decision making levels .................................................................................................................................................................................................................... 28
Table 3.1 Levels of BI usage .................................................................................................................................................................................................................... 35
Table 4.1 Content rationalisation oppertunities ........................................................................................................................................................................................................ 50
Table 4.2 Infrastructure rationalisation oppertunities ............................................................................................................................................................................................... 51
Table 4.3 Process and organisation rationalisation oppertunities ............................................................................................................................................................................ 51
Table 4.4 Organisational structure of a BI CC .......................................................................................................................................................................................................... 54
Table 4.5 Management of a BI CC .................................................................................................................................................................................................................... 54
Table 4.6 Predictive value of benchmark parameters ............................................................................................................................................................................................... 60
Table 5.1 BI Architecture components .................................................................................................................................................................................................................... 82
Table 6.1 BI Engineering Framework activities ....................................................................................................................................................................................................... 100
Table 6.2 BI Engineering framework stakeholder perspectives .............................................................................................................................................................................. 102
Table 6.3 BI Engineering Framework disciplines .................................................................................................................................................................................................... 104
Table 6.4 BI Engineering Framework overview ....................................................................................................................................................................................................... 106
Table 6.5 BI Engineering Framework business context ...........................................................................................................................................................................................107
Table 6.6 BI Engineering Framework Business Context ......................................................................................................................................................................................... 108
Table 6.7 BI Engineering Framework System Context ............................................................................................................................................................................................ 109
Table 6.8 BI Engineering Framework Architecture ..................................................................................................................................................................................................110
Table 6.9 BI Engineering Framework System Concept ...........................................................................................................................................................................................111
Table 6.10 BI Engineering Framework System Specification ...................................................................................................................................................................................112
Table 7.1 Architecture evaluation criteria .................................................................................................................................................................................................................119
Table 7.2 Evaluating architecture topologies .......................................................................................................................................................................................................... 122
Table 7.3 ETL Framework Stages .................................................................................................................................................................................................................. 125
Table 7.4 ETL Framework Management Processes ............................................................................................................................................................................................... 126
Table 7.5 History strategies ...................................................................................................................................................................................................................151
Table 7.6 Dimension types .................................................................................................................................................................................................................. 152
Table 7.7 Data versus text mining .................................................................................................................................................................................................................. 164
Table 8.1 Ferrari case - BI Framework stages .........................................................................................................................................................................................................170
Index of Tables
193
Abonyi, J., Feil, B., and Abraham, A. .......................................................................................................................................................................................................... 166, 184
Cios, K. J., Pedrycz, W., Swiniarski,
R. W., and Kurgan, L. A. .................................................................................................................................................................................................................. 166
CRISP-DM ............................................................................................................................................................................................ 26, 155, 156, 157
Dan Linstedt ............................................................................................................................................................................................................ 88, 134
Dy, J. G., and Brodley, C. E. .................................................................................................................................................................................................................. 166
Fayyad, U., Piatetsky-Shapiro, G.,
and Smyth, P. .................................................................................................................................................................................................................. 166
Gartner .............................................................................................................................................................................................................. 21, 83
Inmon and Imhoff .................................................................................................................................................................................................................. 120
Kaplan and Norton ................................................................................................................................................................................................................... 28
Kimball .......................................................................................................................................................................................................... 120, 146
Mimno .................................................................................................................................................................................................................. 120
Miradi, M. .................................................................................................................................................................................................................. 166
Moss .................................................................................................................................................................................................................. 120
NESMA .............................................................................................................................................................................................................. 61, 62
OVUM ................................................................................................................................................................................................................... 83
TDWI .............................................................................................................................................................................................. 42, 83, 120, 122
Treacy and Wiersema .................................................................................................................................................................................................................... 19
Zachman ............................................................................................................................................................................................................ 98, 101
Index of References
Logica
250 Brook Drive
Green Park
Reading, RG2 6UA
United Kingdom
T: +44 20 7637 9111
F: +44 20 7468 7006
I: www.logica.com/BI
About Logica
Logica is a leading IT and business services company, employing 40,000 people. It provides business consulting, systems
integration, and IT and business process outsourcing services. Logica works closely with its customers to release their
potential - enabling change that increases their efficiency, accelerates growth and manages risk. It applies its deep
industry knowledge, technical excellence and global delivery expertise to help its customers build leadership positions in
their markets. Logica is listed on both the London Stock Exchange and Euronext (Amsterdam) (LSE: LOG; Euronext: LOG).
More information is available at www.logica.com.
Have you missed one of our eBooks?
Feel free to contact us at [email protected]