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

E: hga.bi.ww@logica.com

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 hga.bi.ww@logica.com