RiskTech Forum

Ideal Banking Data Warehousing Project: 10 Steps For Setting The Right Pace

Posted: 15 January 2013  |  Author: Aarti Nyayadhish  |  Source: iCreate Software


Data Warehousing in a banking context is meant to consolidate disparate data across siloed systems and churn decision enabling information from the consolidated data. Although a Data Warehouse can address data consolidation issues, it cannot be a magic wand for all data related problems. It takes conscious effort from all stakeholders to effectively shape and steer the project. Let’s take a quick look at the steps (which can be taken even before the implementation of the Data Model) for creating an ideal environment for successfully implementing a Data Warehouse in banks.

1. Identifying stakeholders as per the bank’s businesses (retail banking, corporate banking, credit cards, etc.)
Stakeholders should possess relevant business / functional knowledge. For individual business functions, resources from the business side and from the business technology side should be included in the team, for better understanding of the Data Warehouse and its needs. Stakeholders should be committed to the project from the beginning to avoid information leaks in the teams.

2. Training sessions to understand the need for a Data Warehouse in the bank
Stakeholder teams need to understand that Data Warehouse is a data repository for the relevant data elements only and not a replica of the source system. This helps teams decide on the relevant data required to be stored. If the team has members from a non-Data Warehouse background, the training should addresses fundamental questions such as:

- How exactly does a banking Data Warehouse function?
- What are the needs of the bank which the Data Warehouse will address?
- What are the goals and milestones of the Data Warehouse project?

3. Understanding Data Modelling concepts (if not the design details)
Understanding the use of meta-data tables and history tables gives the project team the confidence that their requirements are addressed by/in the Data Model. For example, for a referential Data Model, concepts of facts and dimensions / foreign keys and warehouse keys provides project teams the ability to contribute effectively.

4. Collectively identifying the universe of source systems
Ensure that every system in the organization is given due attention and is considered for inclusion in the Data Warehouse.

5. Starting with a base Data Model and then building on it to understand the overall Data Model approach
The base Data Model should cover the basic dimensions across the business and give an idea about the facts which may need to be stored.

6. Data Mapping
a. Mapping data from the source (source systems in the organization) to the destination (Data Model in the Data Warehouse):

For each dimension in the Data Model, source systems and the relationship between the systems need to be identified. Also, mapping of the data elements can be approached in two stages – functional and technical.

- Functional Mapping: Functional teams are major stakeholders in Data Warehouse projects as they are the consumers of the data. Hence, they may have a better understanding about the source of the data from a system screens’ perspective.
- Technical mapping: Teams involved in sourcing of data from the source systems should handle technical mapping. This involves identifying the source tables from the systems’ back-end from where data is fetched.

Functional mapping can be avoided if the technology team has a clear understanding of the data.

b. Data mapping for each function with the business and technical team members:

The mapping exercise may be required to be done at two levels:

- Direct mapping from the source systems: Most data elements will be mapped directly to the Data Model. Here, source and field names need to be identified.
- Derived mapping from the source systems: Certain data elements in the Data Model might need business rules on the source system data for accurate information. For sourcing to be smooth, business rules need to be clearly documented.

While mapping from two or more systems, the relationship between the two source systems needs to be identified. This completes the mapping exercise.

7. Defining the aggregations
One of the objectives of Data Warehousing is to derive analytical information from historical data. It also involves building predictive trends from the data. The aggregation defines the layers across which data is sliced and diced. It’s best if aggregations are defined based on the information (reports and dashboards) that needs to be derived from the Data Model.

8. Omitting and naming the data elements
Project teams should accept that the source may not be able to provide all data in a standard Data Model. The team should agree to either omit such elements from the model or leave them unused. The preferred way is to omit irrelevant fields. The fields should be left unused only when it is anticipated that they may prove to be useful in the future.

During this exercise, ensure that the names of the elements and dimensions are relevant and easy to understand so that even a novice in the organization is able to relate to the names.

9. Ushering future process improvement
While Data Warehousing per se is not a process improvement project, it may trigger process improvement, but that is outside the context of Data Warehousing). Shortcomings identified in the processes or in the source systems should be noted and can be worked on in parallel. However, changes brought about by the process can be accommodated at a later stage and should not impact the Data Warehousing project.

10. Version base lining
Mappings, and even Data Models, should be accepted as versions which are bound to change as the project progresses. It is important to set up a process around accommodating these changes.

The benefits of a good Data Warehouse are experienced only after data that is relevant and required for building trends, is accumulated. Moreover, generating operational reports from the Data Warehouse defeats its purpose and should be avoided. Simple steps such as the above are stepping stones to setting up a successful Data Warehouse in a banking organization.