One commonly overlooked challenge to developing any data warehouse is actually getting access to the source systems and data that you plan on integrating into a data warehouse environment. Whether it is just getting permission to get the data, or working with source system resources to actually acquire the data, this can be a significant challenge. Over many years of working in a variety of industries, I have not seen an industry where this is more complex than it is in healthcare.

In the 1964 movie Doctor Strangelove or How I Learned to Stop Worrying and Love the Bomb, the Doomsday Machine was maligned as being ineffective if your opponent was unaware of its existence – the result being the destruction of the world. So it is with intellectual capital and organizational knowledge. If this capital and knowledge is not made available to the rest of the organization, it’s worthless.

The Merriam-Webster dictionary defines scope as “extent of treatment, range of activity or influence, range of operation.” Once an organization has determined it needs a data governance program and the program’s existence has been established by the charter, it is important that the program’s scope be defined. To what extent will data governance influence the organization’s activitites, and how far will the operation extend into the business processes of the enterprise? These questions will determine the scope of the data governance program.

In my last column I discussed the issue of disparate meta data repositories and the four most common problems created by this phenomenon. – Missing Meta Data Relationships – Typically Built By Non-Meta Data Professionals – Costly Implementation and Maintenance – Poor Technology Selections Last month I discussed Missing Meta Data Relationships and Typically Built By The Non-Meta Data Professional. In this month’s column I will address the final two problems and discuss why they exist.