289

5
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,

Upload: lkaraga

Post on 26-Mar-2015

54 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 289

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 solutionsBy bojanCreated 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,

Page 2: 289

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 organizationStaging 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 dataData Marts ? derived from BST, star schemas or snowflake schemas, relational modelCubes (OLAP) -  OLAP representation of relational data martsMetadata (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 OutlineDesignBuild 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

Page 3: 289

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 -

Page 4: 289

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 abstractionWell-structuredWide business domain coverage Comprehensive classification model

Page 5: 289

Flexibility and scalability in terms of change and growingPlatform independentProvided data modeling tools and implementation methodologies

3 votesBest 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