Bolt-ons

If you are thinking that bolt-ons may be the solution for after-the-fact requirements or requirements changes, reading this article may change your mind.

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 they have some additional requirements that they forgot to mention, or that they just discovered new requirements, or they have requirements that just now have become politically acceptable to discuss.

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.

 Bill InmonBill Inmon

Bill is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations. Bill can be reached at 303-681-6772.

Dig deeper on Data modeling tools and techniques

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchBusinessAnalytics

SearchAWS

SearchContentManagement

SearchOracle

SearchSAP

SearchSOA

SearchSQLServer

Close