Business Intelligence and Master Data

Last month we had in inspiring Business Intelligence Unit meeting. One of the key items of this meeting was a Microsoft Master Data Services (MDS) presentation. During the presentation a firm discussion developed. Main topic of this discussion was, belongs Master Data Management to the Business Intelligence domain?

Microsoft positioned MDS as part of their BI Suite, I think MDM does not belong to the Business Intelligence domain. BI uses MDM as a validated source for its core dimensions.  The main goal of Business Intelligence is to create actionable information. The main goal of MDM is to have a one clear (unified) view of the ‘key’ business Entities, and the organization uses that view everywhere.

MDM and BI overlap, have mutual interests and structures however are different by nature.

I think many organizations lack a common definition and source of their ‘Key business Entities, often leading to confusion of tongues.

Regards Kees

Count

English: Albert Einstein Français : portrait d’Albert Einstein (Photo credit: Wikipedia)

Not everything that can be counted counts, and not everything that counts can be counted

Albert Einstein (1879 – 1955)

The necessity of a Data Warehouse

Today my two penny thoughts about Data Warehousing. It’s my profession however sometimes I feel that I am the jerk that copies data from one source to another. Mostly to obtain a so called ‘a single version of the truth’. What truth, every manager presents his own Excel sheet and argues that his figures are better, more accurate than the other ones including my version of the truth.

Sometimes I feel I have to build a DWH just because that is what everybody else does. Its common practice. We need a DWH, to do what???. If you don’t have one what do you miss? My colleagues and I often argue, you need a DWH to structure your organization data into a form it is easy to access, report, and analyze, and in the end make decisions. This sounds to me as a concept, or objective.

To achieve this objective, the question arises should one use the ‘generic’ Way Of Working? Use the paradigms as postulated by ‘Kimball’, ‘Inmonn’, and ‘Linstedt’? What if, if your Enterpise data is already consistent in the ‘various’ source systems.? What if, you are able to obtain your required enterprise data directly from the source system easily with minimal performance impact? What If you are able to combine/relate that data with data from other systems, just by using views, or other means? Modern in memory software like QlikView,Tableau, Microsoft’s PowerPivot are able to do so. What remains is the set up of one or more data models.  A data model defines the relationships between the various data for a given Enterprise Information need. It also translates database names into meaningful business names. For various needs one is free to create different ‘relationships’ (consolidate). 

In modern times Information needs vary more rapidly than a traditional DWH implementation is able to keep up with. To me a Data Warehouse is a mean, no more no less. And if there are other means that do the job cheaper, more effective, with less effort why not choose them.

The need for a ‘traditional’ DWH is there when (non exhaustive):

• Data of the various source systems is not aligned to each other or are difficult to align
• History is not well kept in the source systems
• Its difficult to extract data from the source systems
• When Querying the source system directly you go up for a cup of coffee or have a chat with on of your colleagues.
• The data from the sources is highly distorted, you hire a third party and let them cleanse and clean it. Making some sense out of it.
• You think you have to apply a bunch of business rules on the source data. You where not able to do so when the data was entered in the first place.

 

 

 

Accuracy

Last week,  during the system test, the tester rejected newly added SSAS cube functionality. The reason was that the 7th decimal differed from his test script result. After studying his SQL script I noted he used wrong numeric conversions. I pointed him on this and to the fact that business expects an accuracy of six decimals. Furthermore I told him that numeric math with SQL server has some odd behaviour by design, and due to this behaviour he would have some challenges to equal the results. He was not pleased he wanted the full 12 decimals behind the decimal point be equal so he raised an issue.

This week 1 designer and 2 testers did a full investigation on this matter. It costed them half a day to fully understand the mechanics of numeric math in Microsoft SQL Server, and to correct the test scripts accordingly. There was a full match between the expected results and the new SSAS functionality.

I could prevent all of this by just adding a generic round function around the ‘issue’ causing formula in SSAS. The ‘stored’ figures then match the required accuracy. I guess when I implemented this functionality, it did not pass my mind  that someone else could have a completely different perception on these figures.

How accurate do you want to be?

You find more about SQL server precision, scale and length at: http://msdn.microsoft.com/en-us/library/ms190476.aspx

SSAS: Microsoft SQL Server Analysis Services.

Hello

My first blog ever. Forgive my errors I guess I have to learn a lot. This blog site will discuss my first two penny thoughts how BI could lead to Organizational Knowledge, Experience and Wisdom.  It’s about organization maturity.

“Possession of Facts is Knowledge and the Use of Knowledge is Wisdom”

Thomas Jefferson (1743-1826).

And a quote a former collegue of mine used often from Wittgenstein.

“The world is the totality of facts, not of things”.

Wittgenstein (1889 – 1951)

Let’s start

Kees