Published on Global Data Consulting (http://www.globaldataconsulting.

net)

Home > Articles > Best Practice > IBM IFW Banking Data Warehouse (BDW) ? One model for many solutions

IBM IFW Banking Data Warehouse (BDW) ? One

model for many solutions
By bojan
Created 06/08/2010 - 15:03

Prolog

There is no doubt that IBM Information Framework (IFW) Banking Data Warehouse model (BDW) is
practically industry standard for banking data warehouses. However, the model principles (abstraction
layers, platform independent) and structure (banking data warehouse (BDW), business solution templates
(BSTs), application solution templates (ASTs)) give us various aspects of the model usage. In this article I
will tray to catch them all (for those who are beginners in the models, before they continue reading this
article, I recommend to read the previous articles regarding the same subject matter, published on this site).

General Architecture approach

Data warehouse architecture - Inmon versus Kimball approach? In fact, you can use both. This decision
depends of what you want to achieve and in which timeframe.

The strategically (Inmon) approach considers unique data/information repository that is capable to
integrate the whole information potential of the organization ? enterprise data warehouse (EDW). EDW
then ?feeds? departmental databases (data marts). This approach has following characteristics: the longer
start-up time, higher (but with lower subsequent project development costs), requires larger team of
specialists, methodology of implementation is quite complex. Considering the IFW BDW model, this
approach using a full potential of the model including system of records and summary area (based on
BDW) as well as data marts (Business Solution templates, BDW) and interfaces (Application Solution
Templates, AST). Unique data/information repository requires carefully designed System of records area of
EDW ? to be comprehensive enough to get all information potential upcoming from operational source
systems on one hand, and to preserve well-structured scalable model with relatively small number of
entities easy for maintenance, on other hand. System of records (and Summary area) deigned on that way,
will become great foundation and unique repository for ?feeding? data marts (which is business
information repository accessed by business users).

On the other hand, the tactically (Kimball) approach considers data marts as a single business process.
EDW in this approach represent set of all data marts in the organization. Enterprise consistency achieved
through data bus and conformed dimensions. This approach has following characteristics: quick start-up
time, lower start-up costs, requires small team of generalists, methodology of implementation is fairly
simple. Considering the IFW BDW model, major role in this approach plays Business Solution templates
(BSTs). BSTs are designed as logical cubes covering specific business domains (Asset Liability,
Profitability, Relationship Marketing, Risk, and Compliance). Final solution that has to be aligned with
business requirements, should be derived from BSTs (as part or whole BST, several BSTs, mixture of
measures and dimensions from BSTs, slight customization by adding some measures or dimensions)

Data architecture

Depending of which general approach you are using (Inmon/strategically or Kimball/tactically) various data
architecture components will be used.

Strategic approach considers following data architecture components:

Operational sources ? various data sources across the organization

Staging Area ? temporarily data storage using in ETL process (using for CDC-Change Data
Capture, slight transformations, and so on)
EDW (System of Records, Summary Area, Feedback Area) ? major part of architecture, planned
to store reference and transaction data
Data Marts ? derived from BST, star schemas or snowflake schemas, relational model
Cubes (OLAP) - OLAP representation of relational data marts
Metadata (business and technical) ? solution configuration and parameterization data, business
rules for various purposes (e.g. mapping operational data sources to destination model)

Tactical approach considers the same components as strategically approach except EDW component.

Note: during our implementations of BDW we are developed our own approach for Staging area design
that improves significantly ETL performance. More about that you can read at:

http://www.globaldataconsulting.net/articles/technology-platform/ibm-bdw-model-hands-%E2%80%93-
volume-1 [1]

The process: Start up project

Note: implementation process described in this part, is derived from IBM Global Services
Methodology with some modifications (with intention to make implementations efficient and
effective), which are derived from our experience in implementations working on in a last five years.

The implementation process has four global phases:

Solution Outline
Design
Build
Deployment

Solution outline is initial implementation phase containing activities for outlining the project. This phase
has following sub phases:

Business Discovery contains preliminary business and technical environment analysis. Input
documents are Business Analysis Questionnaire and Technical environment questionnaire. Output
document is Business Case.
Project Outline contains activities related to the technical and organizational aspects of the
project management (project organization, business scope definition, technical architecture
 specification and project plan definition). Project organization includes establishing of BI
competence center, defining roles and responsibilities as well as selection of project management
and implementation methodology. This sub phase results with formal document named Project
organization. Business scope definition gives a picture about what would be a solution output
(specification and features of reports, analytical tools, dashboards and other applications).
Technical architecture specification describes the technical architecture of the solution
(hardware and software infrastructure).Technical questionnaire from business discovery phase has
used as input for this activity. The result is formal specification of the technical environment
required for the solution. Project plan is a formal document that has to provide solution
implementation in defined scope, budged and timeframe.
Technical Environment Deployment contains activities of technical environment setup (setup of
development and production environment, installation, parameterization and configuration of
system and platform software)

Design phase is crucial for project success. This phase consists of four sub phases:

Business requirement analysis includes detail business analysis plased on top of Business
Scope definition document (generated in Solution outline phase). Detail business analysis should
result with definition of every cell of information/report or peace of software functionality (formal
document is Detail specification of Business requirements).
Data source analysis includes activities of gathering information about all operational data
sources that could be a source of usefully information prerequisite, to match business requirements
(and that includes analysis of platform, purpose, physical organization, entities, periodicity and
growth and so on). This sub phase result with a formal document named Data Source Specification
(or Analysis). The document, named Technical environment questionnaire (generated in Solution
outline phase should be used as input for this phase.
Data Warehouse model design includes: scoping of BDW model according to business
requirements, as well as design of following entities (logical and physical level): reference data,
profile data, transactional data, classifications, associations, summary, data marts, metadata, and
feedback. This phase results with formal definition of logical and physical data model. As input, the
document named Detail Specification of Business requirements is used.
Mapping Operational data sources to Destination data model describes business rules
source data transformation in order to feed destination model. This sub phase results with formal
document Data model definition and mapping operational sources to the destination model

Build phase includes development of applications on top of the model in order to provide required
functionalities to the business users. That includes: ETL applications, OLAP applications, Front end
applications (reports, dashboards, analytical tools) and so on. As input, should be used Functional
software specification document, derived from following documents: Detail Specification of Business
requirements, Data model definition and mapping operational sources to the destination model. Quality
assurance (QA) activity is integral part of this phase. At the end, this phase results with formal document
named QA certification.

Deployment phase is final phase and includes four sub phases: technical deployment, training,
stabilization and final acceptance. Technical deployment includes application deployment from
development to production environment and initial load of data warehouse (with data history). Major
activities in stabilization phase are related to data cleansing and bug fixing. End user training is
important for user acceptance ? business users must be familiar with solution in order to start using it
(regarding the user adoption, end user participation during implementation is also highly recommendable -
mandatory).Final user acceptance is a stage when solution is ready for usage ? this is momentum for
official production roll up.

Considering the general architecture approach (Inmon/Strategically, Kimball/Tactically), strategically driven

start-up project requires more effort and time then tactically, but they have a much greater leveraging
opportunities for subsequent projects. Furthermore Kimball?s approach brings relatively simple solution in
comparison with Inmon?s approach (there is no EDW component and accordingly ETL complexity is lower)

More about the BDW implementation process you can find at:

http://www.globaldataconsulting.net/open-lab-topics/model-data-warehouse-implementation-process [2]

The process: Subsequent projects

Most common subsequent project scenario is when you getting a new set of requirements after the first
phase (start-up phase) or any other phase are already completed. Considering the process, more and less,
you should go through the most of the phases as you do with the startup project, relaying on existing
architecture established in previous phases (for Inmon/Strategically generally architecture approach
foundation architecture has much more leveraging opportunities then if you are using Kimball?s/tactically
approach).

Other uses: Corporate data dictionary

Financial Services Data Model (FSDM), as comprehensive and well-structured classification model is a
great foundation for corporate data dictionary standardization. There is no uncommon situation where an
organization purchasing BDW model with primary purpose of standardization and integration (to respond to
the problems in heterogeneous environment). Adoption of FSDM as standard corporate dictionary will
improve communication between various participants in business processes inside (Business and IT
users) and outside (customers, regulatory institutions, auditors etc.) of the organization.

Other Uses: Customer Data Integration, Master Data Management

Comprehensive and well-structured logical model of entities data warehouse can be used as data
foundation model for customer data integration (e.g. involved party data concept entities) or master data
management. This could be a part of data warehouse implementation or separate projects.

Epilog

IBM IFW Banking Data Warehouse model (BDW) can be used for various purposes and for solving various
kinds of problems within an organization. All of these usages are derived from model?s primary goal: to be
corporate data model foundation. Wide usage of the model is possible, with the help to the following
characteristics of the model:

Layered, with different levels of abstraction

Well-structured
Wide business domain coverage
Comprehensive classification model
 Flexibility and scalability in terms of change and growing
Platform independent
Provided data modeling tools and implementation methodologies

3 votes
Best Practice

Source URL: http://www.globaldataconsulting.net/articles/best-practice/ibm-ifw-banking-data-warehouse-bdw-

%E2%80%93-one-model-many-solutions

Links:
[1] http://www.globaldataconsulting.net/../../../../../../../../articles/technology-platform/ibm-bdw-model-hands-%E2%80%93-
volume-1
[2] http://www.globaldataconsulting.net/../../../../../../../../open-lab-topics/model-data-warehouse-implementation-process