Simplifying Late-binding Data

Late Binding goes way back. The term Late Binding dates back to the 1960s and refers to a computer programming mechanism in which the method of programming does not require the compiler to reference the libraries that contain the object at the time of compilation. Late binding proves to solve the problem of version conflicts and modification accidents. The process of mapping the data in the enterprise data warehouse (EDW).

Mapping a data is just one of the processes required as data must undergo massive transformations. The Late binding technique is used to map the data into the enterprise data warehouse from source systems to standardized and central vocabularies and business rules and systems. Late-Binding is however not an easy process and is often very complicated with layers and layers of data needing to be sorted. There are some rules and principles that can be followed that help in Simplifying Late-binding Data. These principles continue to deliver proven records for military, manufacturing and healthcare organizations that operate under them. These principles summarized are;

  1. Minimize remodeling data in the data warehouse until the analytic use case requires it. Leverage the natural data models of the source systems by reflecting much of the same data modeling in the data warehouse.
  2. Delay binding to rules and vocabulary as long as possible until a clear use case requires it.
  3. Earlier binding is appropriate for business rules or vocabularies that change infrequently or that the organization wants to lock down for consistent analytics.
  4. Late binding in the visualization layer is appropriate for what-if scenario analysis.
  5. Retain a record of the changes to vocabulary and rule bindings in the data models of the data warehouse. This will provide a self-contained configuration control history that can be invaluable for conducting retrospective analysis that feeds forecasting and predictive analytics.

Having a Late Binding Analytics Platform is important and preferred because it avoids the consequences of linking data with volatile business rules or vocabularies too early. This was one of the motivations the architectures had when creating this technique byBy waiting to bind data until it’s time to solve an actual clinical or business problem, analysts don’t have to make lasting decisions about a data model up front when they can’t see what’s coming down the road in two, three, or five years.

It also makes it possible to quickly adapt to new questions and use cases and have the data they need to perform timely, relevant advanced analytics. This is done so the data can be brought together for analysis. A lot of large healthcare organizations have hundreds of analytics vendors supplying data. All that data has to be brought into the enterprise data warehouse (EDW)  in order to ensure the possibility of having a reliable reporting and analysis.

The idea of late binding in data warehousing borrows from the lessons learned in the early years of software engineering. In those early years, very large software programs characterized software development. It was very common and a widespread practice to program hundreds of thousands of lines of code in a single module, supporting numerous and widely different business functions. The code for these varied business functions was tightly bound or coupled together all at once, at compile time. It was a time-consuming process to write and troubleshoot these large programs.

If one piece of the program failed at compile time, the entire program failed. It was all-or-nothing programming. Also, if the program required changes or modifications because of new business rules and requirements after compile time, the entire program had to be modified, recompiled, and placed back in service, often with significant downtime. Hence simplifying Late-Binding data increases agility and efficiency and makes for more efficient use of the data.