Business Logical Data Model (LDM)

by Sreenivas Methuku

Introduction

Data Model is the backbone of all applications and data repository. It converts the business specific functionalities to a structured form for routine and strategic operations. A good design in data model brings scalability and robustness to a solution. There are two different modeling techniques used in the data warehouse. Based on Kimball’s bottom-up architecture, the dimensional data model used to support analytical reporting requirements and based on Inmon’s top-down architecture, the normalized data model is used for the data warehouse to consolidate enterprise data in a single integrated design. While the normalized design is heavily based on the business process, the dimensional data model design is based on Key Performance Indicators (KPIs).

Industry standard data models such as FSLDM, IFW, OFSA, etc. mainly focus on the enterprise requirements. These are normalized data models suitable for Inmon’s suggested enterprise data warehouse. These are expensive, technology specific, and need customization before implementation.

Coforge has implemented and followed module and sub-module solution in each sprint, using technology agnostic, and modularized industry standard data model which is a right fit for the warehouse implementation.

Apart from the above drivers, At Coforge, we use the following parameters for a quality data model.

  • Data Dictionary: Availability of the definition with the data model gives a good understanding of the actual design coverage. The definition is applicable to the subject area, entity, attribute level while giving full meaning to the data model. The definition masks the business coverage and gives the full clarity on model customization for a specific implementation. For example, the banking specific data model would have the definition covering the calculation of some Basel compliance.
  • Integrated Model: Presence of fully integrated model supports enterprise reporting requirements. Some reports are based across business groups / functional areas, and it is easy to traverse from one subject area to another through common entities.
  • Subject Area to Entity matrix: A data model can support modularized design if it covers different subject areas aligning to process / sub-process of the business functionalities. The business group, by and large, handles a set of process areas. The data model supports the business groups by covering the distinct functionalities, KPIs through respective subject area. The entities for the subject area are defined by analyzing the KPIs in terms of key business measures and related perspectives.
  • Analytics Use Cases: Analytics use cases managing the data model to address the business pain areas either by improving the performance of the business process, or by reducing the cost of the business or by increasing profitability. A hidden business insight can be found from the business data model.

Coforge follows certain best practices while designing these models: Process oriented approach against Data centric or Source centric approach. Below are the salient features of this framework built from vertical specific LDM:

  • Technology agnostic and platform independent
  • Modular in nature
  • Industry best practices in biz KPIs, analytical templates
  • Business process oriented vertical specific data models
  • Highly customizable, flexible, and scalable

Coforge’s Value Proposition

The pre-defined data model brings the quality solution to the data warehouse implementation, saving time and cost during implementation. It is solely dependent on the data model coverage-based business requirements. There is no ideal solution to address all the requirements as most of the business processes are organization specific with the local compliance rules. Based on the previous implementation, Coforge finds there is 30 to 50% of cost reduction in the implementation by following the business data model with associated components.

Approach

LDM is built while analyzing the business / process specific functionalities. At higher level, it is at subject area level connectivity aligning to the process flow or the way different processes are interdependent of each other. By drilling down the higher-level details to granular level, the subject specific data model is the entity relationship, then the entity configuration to highlight how the attributes are configured within the entity. The business definition, data dictionaries, business rules are critical while defining the data model. The functional domain experts provide the details to the data modeler to work on the LDM. Later, the LDM is converted to PDM for a specific database by understanding the availability of datatypes, data lengths, indexing techniques, partitioning techniques. This is how a data modeler plays a vital role in understanding both the business and technical aspects.

Following are key considerations for building the logical data model:

  • The data model is easily adaptable to change and can be configured for any new requirements. It supports different reference data architectures
    • Independent data mart architecture
    • Data mart bus architecture
    • Hub and spoke architecture
    • Centralized DW architecture
  • It has light and highly summarized information for better performance and helps in ensuring consistency among various data sources and applications.
  • Apart from business related columns, following information is also captured in different columns
    • Audit information
    • History information
    • Other technical information.
  • Dimensions are clearly utilized based on their associations with KPIs.
  • Based on different dimensions i.e., Highly Conformed, Medium Conformed, Low Conformed, the analysis is conducted across the analytical subject area.
  • Standard set of rules and guidelines are followed for normalized and dimensional data models.
  • Different data modeling approaches depend upon how the data is being used in query reporting, multi-dimensional analysis, and data mining.
  • Business data model is an important pre-requisite of quality data and is critical to a long lasting, easy to maintain system. Presence of complete data dictionary. More emphasis on detailed data.
  • Reusable, scalable, flexible, and manageable data mode is in place. Data model follows standard nomenclatures.
  • Data model's naming standards, domains, etc. are adaptable to all standard databases.

Conclusion

Organizations for a specific business domain operate in same way and hence, their business functionalities are the same. Even though the requirements at business user’s level could be different, they align to same set of industry standard KPIs. Building the data model for those KPIs is applicable to those organizations and address most of the requirements. A business data model brings following benefits:

  • The data model is adaptable to change easily and can be configured for any new requirements.
  • Help consistency among various data sources and applications
  • It helps in bringing a long lasting, easy to maintain system
  • An integrated model helps in bringing single source of truth in the data warehouse solution
  • Benefits in business to IT affiliation by correlating business requirements in the data structure
  • Pre-build components and processes in overall generic data model driven solution leading to a quick implementation and help in reducing overall BI implementation cost as well as timeline
Download the Whitepaper