This article originally appeared on the BeyeNETWORK.
So you have built your system. You have done a data model, some mapping and transformation, and you have loaded some data. Now, the end user comes in and says that
Only after you build a perfectly functioning system do the real requirements start to emerge. How typical is this scenario? As typical pollen on a warm spring day. So how do you handle these requirements-after-the-fact?
One way to handle them is to create a “bolt-on.” A bolt-on is an addition to the system that is not really integrated into the system. It is an addition to the system in the least offensive place.
So what’s the big deal with bolt-ons? As long as there are only one or two bolt-ons, there may not be any problem. Almost every system has a few. They are like the mole on Cindy Crawford’s face – they give the system a distinctive and recognizable flair. But when there are a lot of bolt-ons, the system does not have flair and resembles Frankenstein more than Cindy Crawford. The problem with bolt-ons is in their number. A few are probably inevitable. A lot are unacceptable.
So why are bolt-ons even around? Bolt-ons are popular where there are many changes or additions to requirements. Whenever a change to a requirement occurs, if the change is to be taken into account properly, the data model is affected. Then mapping is affected. Then extract, transform and load (ETL) processing and the physical design of the database are affected. There is a ripple effect throughout the design and physical infrastructure of the data warehouse environment. It is just easier to add a bolt-on and not have to worry about really integrating the data.
The cumulative effect of creating a lot of bolt-ons is that data is not really integrated. And data integration is one of the foundations of data warehousing.
When a review is made of a data warehouse environment, one of the features that the reviewer looks for is the existence of bolt-ons. And how can a reviewer find bolt-ons? There are some characteristics that are as distinctive as DNA in a drop of blood. Some of these characteristics are:
- Numerous tables
- Numerous tables that contain a key and one or two attributes of data
- Tables that have very similar data (logically speaking)
- Tables that contain abstractions of the same data
Bolt-ons represent a short-term solution. Proper integration of data takes more time and effort,
but the end result is a much stronger, much more viable data warehouse.