Every good data project specifically ones that involve some degree of enterprise reporting
or business intelligence propose a unique set of challenges. Most of those challenges relate
directly to the integrity of the current data architecture. Although it is next to impossible (or
very risky at a minimum) to modify a company’s existing underlining data architecture, there
are other solutions that will allow you to “start from scratch” for lack of a better phrase.
One way to breath new life into an old and outdated architecture, is to create an alternative
data schema that new applications or reporting clients can consume. Most of the time this
solution is best suited for enterprise reporting as the data will most likely not be updated in
a manner in which critical business application can rely on. That’s quite alright though, as
this technique is best utilized in a business intelligence project where the source data will
be read-only from a client perspective anyway.
So how would you facilitate a data-centric project in an environment that contains many
different data sources and subject areas that require a common data architecture? Enter
MDM: Master Data Management. MDM can be defined as a set of guidelines, procedures,
and toolsets to collect, store, clean, and maintain enterprise-wide data for the purposes
of a consistent “one version of the truth” data store that end-user will consume in some
manner.
Below are the tenants of MDM with a brief description of each. Some of these items
seem like plain common sense, but it also serves as a strict guideline to keep your
data-centric projects on track.
1. Identify sources of master data – Collect and documents all sources of data that
the organization consumes. These can be databases, excel files, flat files, etc..
2. Identify the producers and consumers of the master data – Indentify and document
the applications, vendors, and end-users involved in the production and consumption
of data within the organization.
3. Collect and analyze metadata about for your master data – Document the databases,
tables, columns, stored procedures, data types, and any other descriptive information
that is contained within your data sources.
4. Appoint data stewards – Appoint a group of individuals who know the source data at
a detailed level to help facilitate the movement of that data to the Master Data Model
while adhering to the defined business rules of the organization.
5. Implement a data-governance program and data-governance council – This group will
have the knowledge and authority to make the important decisions regarding the Master
Data including maintenance, content, and storage.
6. Develop the master-data model – This is the phase in which the actual data model will
be defined and developed. A well-seasoned data architect with a commanding knowledge
of the source data and business rules is required.
7. Choose a toolset – This should be the easy part. In my case, Microsoft SQL Server
is the natural choice. Analyze your company’s current toolset, as they may have already
spent good money on a current set of tools.
8. Design the infrastructure – Decide how this master-data model will be consumed in your
environment and design an appropriate system for the consumption of that data. This may
include Reporting Services, Sharepoint, etc..
9. Generate and test the master data – Take the time to generate real-world-ish data to test
your processes and schema. During this phase, you will ferret out any errors or inconsistencies.
10. Modify the producing and consuming systems – If you are unlucky enough to have to re-tool
an existing application to utilize this new data source, this will be a huge undertaking. You
will basically have to re-write your application in most scenarios. If you are using this master
data as a reporting source, then you can start building new reports (which is why you went
through this exercise in the first place!).
11. Implement the maintenance processes – Maintenance is never easy or fun, but if you used
robust tools (like SQL Server Integration Services) to move the data, you are already ahead of
the game. Just make sure the rules for updating your schema are robust and will withstand the
test of time. A frequent audit of your processes will usually catch any anomalies.
Need BI consulting, training, or innovative BI tools?
Come see our offering:
http://www.PragmaticWorks.com
How Big Is Your Package?