BizTalk 2004 and Analysis Services: bad cubes?

In these last busy two months I’ve seen many things that deserves to blog, but until now I hadn’t time to do it. But today I have 5 minutes to talk about the current BizTalk 2004 integration with Analysis Services 2000: this time I have some critics to do.

There is a database with two cubes (MessageMetrics and ServiceMetrics) and I don’t know if it really give to a user what he really needs, but for sure this cube doesn’t follow the actual best practices, but instead it follows what I would call “worst practices”. Let’s see:

  • All dimension are private
  • Possible “shared” dimension are private, so there is no easy way to have a virtual cube to relate measures from different cubes
  • It seems there are no designed aggregations
  • The missing of shared dimensions causes the inability to optimize the cube process

I don’t know if this should be considered only as a “demo of possible integration” or if it is sold as an example of products integration. In both cases it fails the target, because I sincerely can’t see the added value of a such poor designed olap cube. It doesn’t scale. It requires “another service” (Analysis Services) only to give you what is available with SQL aggregation (if you have a lot of data, cube design is really bad) but with an added latency (the cube needs to be processed).

 I just checked here: it has to be considered as a BizTalk feature. I’m curious to see BizTalk 2006 advances here.

Uhm… someone has some fact to convince me that I’m wrong?