Entry Point: Change is a Constant

How many times have you received bad data from an upstream ‘stable’ database environment for no reason what so ever?

1…
2…
10…
13…
76…

Never…?

How’s this for a reply… no environment is stable! PERIOD.

Each and every data warehouse environment is subject to change, subject to growth, subject to budget constraints, and other external conditions (i.e., political changes). Their will always be change, THAT you cannot control.

Remember SOx. One recent example in Ontario is the Harmonized Sales Tax move. This means for those organizations tracking tax in their internal systems, they must make changes to their databases and systems to incorporate the HST and alter their PST and GST taxation collection and tracking in Ontario. This is a nice example of an externally forced-upon change. This particular impact will impact both Operational and Decision support systems.

Personal Experience:

The data files were coming in just fine from a source system that was considered stable (i.e., no data issues from them since project delivery).

Then one day, the volume dropped by more then 70% on file feeds received daily...

How many times have you received bad data from an upstream ‘stable’ database environment for no reason what so ever?

1…
2…
10…
13…
76…

Never…?

How’s this for a reply… no environment is stable! PERIOD.

Each and every data warehouse environment is subject to change, subject to growth, subject to budget constraints, and other external conditions (i.e., political changes). Their will always be change, THAT you cannot control.

Remember SOx. One recent example in Ontario is the Harmonized Sales Tax move. This means for those organizations tracking tax in their internal systems, they must make changes to their databases and systems to incorporate the HST and alter their PST and GST taxation collection and tracking in Ontario. This is a nice example of an externally forced-upon change. This particular impact will impact both Operational and Decision support systems.

Personal Experience:

The data files were coming in just fine from a source system that was considered stable (i.e., no data issues from them since project delivery).

Then one day, the volume dropped by more then 70% on file feeds received daily.

After some investigation the source system (System B) identified that their volumes had changed as well. They did not even know their data volume had decreased. The investigation was escalated to their source (system A), who identified that all the records where being sent to system B. There were no changes to System A, “more on that shortly.” Back to System B; they do not have the data. Open the source files and there the data was, the records that were missing were in the source files with blanks in the identifying fields.

A scheduled software (note scheduled) upgrade on System A, could not process French characters and inserted blanks in the initial fields and subsequent ID fields. So when System B arrived to pick up the record IDs it found nothing to insert.

A simple software upgrade that resulted in wasted time, money and missing data.

 

Ignore the potential for change and you will be left holding an empty bag. Never get comfortable.

Remember to inform all your upstreamers of how their changes may potentially become a critical impact to your environment.

Some of the most common forms of changes in systems are the result of the following items:

• Data integration
• Mergers and acquisitions
• Politics, laws and regulations,
• Software changes
• Web interfaces (change of portals)
• Hardware changes

I’m certain you may be able to add to this short list, and I welcome you to.

If you are someone making change, remember to practice proper Change Management techniques, a topic for future discussions.