TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

Data Access Requirements: Be Prepared to Accommodate Overlooked Functionality

Project requirements change and evolve during development. We must be prepared to handle them.

• By Mike Schiff
• October 6, 2015

A colleague of mine, a fellow data warehouse practitioner, recently had an experience with a telecommunications vendor when he needed to contact the vendor about a problem he was having. The call center representative asked for his account number in order to access his data in what was surely a customer master data file. My colleague was traveling and didn't have his account number handy, so he provided his cell phone number instead.

Unfortunately, the number he provided was not the one he needed for account access. He was however, able to access the account when he provided the telephone number of another phone that was also on the account. As he mumbled something about his disbelief at being unable to access the account with what he thought should have been a valid secondary key, the call center representative chuckled and said he was sorry but "that's the way the system works."

As I thought more about this, I realized that as data warehouse professionals, we need to consider how the data we collect will be accessed and used when we design and implement our data warehouses. Although most of us already do so during the analysis and design phases of our projects, how many of us do so post implementation?

As most of us have experienced, when an operational system or data warehouse implementation initially "goes live," one of the first (and frequently the most common) comments from our user community is "this looks great but can it also ..." Despite our best design efforts, and no matter how closely and/or frequently we collaborate with our users, we will likely miss features that only become obvious after implementation. Consequently, we should budget contingency funds for additional post-implementation improvements so that we can accommodate overlooked requirements.

We should not consider our implementations to be finalized until we have surveyed our user base and help desk representatives after they have used the system for a week or two and inquired about additional features they might need. I recommend quickly implementing those that are relatively trivial to incorporate while prioritizing those that require major effort. However, make sure to include any user and helpdesk retraining requirements when evaluating these changes.

If our analysis and design efforts were adequate, many of the desired changes should not be budget-breakers nor would they even require new training. For example, the ability to access a cell phone account through any of the associated phone numbers could be easily accommodated.

Another approach, and one that continues to gain increasing popularity, is to utilize agile development methods. Rather than casting a functional specification in concrete, we quickly deliver a prototype for limited use and then survey users for refinements and/or additional functionality. Most of us would agree that hands-on usage beats reading a functional specification any day. This approach allows for incremental, albeit less-than-complete (as if any development effort is really ever complete!), implementations.

Either way, it is important to remember that requirements change and evolve and that we must be able to accommodate needed changes when this occurs, especially if these requirements change while the system is still in development. Even if they didn't, we should make it a practice to survey our user community shortly after implementation and continue to do so periodically. After all, our responsibility is to meet the needs of our users, not to blindly implement a functional specification that may no longer be valid.