MicroStrategy Reviews

I would agree with the fact that MicroStrategy brings along with it increased costs but would clearly like to quote that it brings along it with it huge benefits that probably other reporting tools dont offer. The tools architecture has been framed in such a way that the design and development are easy thus reducing the maintenance efforts.

Companies do think twice before implementing MicroStrategy because of the costs involved. Not only its about the implementation but also technical support which is around $10,000 per year. Also when there is a project coming in any company analyses if its possible to achieve it with other reporting tools with lesser implementation, administration, support and maintenance costs but they do not analyse if in the long run any other additional features would be required which would be beneficial for the users. After a year of implementation when the users come in with new requests then they start to understand that their current tool does not offer the required and start to evaluate other tools and plan to migrate it. I think this might not be the case if their COE team had done an extensive analysis initially on the capabilities of the tool. This tool bring along with it some special capabilities like mobile, social and cloud.

MicroStrategy has established itself in all industries like communication and media, education, energy and utilities, financial services, food and beverage, health care and life sciences, manufacturing, retail and travel. Today, 14 of the top 20 global financial institutions rely on solutions powered by MicroStrategy. It has also showcased a number of successful Mobile BI Implementations. One is Whole Foods Market. This purveyor of natural and organic foods has over 300 stores and annual revenues of over $10 billion. The grocer is part way through a project to put mobile analytics into the hands of every store team leader using smartphones. Store team leaders have access to dozens of key performance indicators about their store. Given the limited screen size of a phone, whole foods decided not to implement charts. Instead, tabular data is shown, with a simple traffic light system used to highlight good, mediocre, and poor performance. Each store team leader can configure their own version of the app to show the performance of a few other stores alongside their own. So store managers often pick the closest store to them geographically, or a store of similar size, or leading stores in other regions.

With Cloud Personal, any analytics can be shared with other people through mail. MicroStrategy has recently unveiled an interesting demonstrator of the power that can be gained from harvesting social data.With Wisdom, users can understand the demographic profile of people who like specific entities – be they people, places or products. For example, it’s easy to discern the demographic profile of people who like a certain politician, a particular brand of beer, or a TV show.

Users can experience and enjoy MicroStrategy products – primarily Visual Insight – in minutes with no risk or investment. The visualizations and dashboards created can also be viewed using MicroStrategy’s native mobile BI applications for iOS devices.

Thus even if the costs are high the benefits are huge.

A common problem in MicroStrategy that users face is the performance of reports. But with simple tuning techniques that the product provides this can be fixed in no time.
I would like to share with you the techniques that I have played around with.

First I would like to talk about the caching.

Caching allows for improved performance in response to report queries. As the cache gets stored in the memory, when repeated queries are made against the same reports the data is fetched faster.

Caching comes in different forms - Project/Report Level Caching and Template Caching

1. Caching can be enabled/disabled at project or report level. However the report level setting will override the project level setting. Using Project Configuration we can enable the caching else in report – using caching options we can enable or disable the caching. This type of caching is very useful only in cases where the data is preloaded in the database and there is no incremental refreshing of the database at any time of the user report run. For a data warehouse caching would help as against a OLTP ( Online Transaction Processing) system where data is frequently refreshed.

2. Templates can also be used for caching. Using a common template for developing common reports will help to fetch report data faster.

In projects I have worked on, we have implemented template level caching where in one template is built with common set of attributes and metrics and the reports are built by using the templates as shortcuts and in turn we cache the templates. Hence when one of the reports built from the template is run the entire data of template is run and gets cached in the memory and when other subsequent reports are run the report hits the cache and does not hit the database thus increasing the performance.

Next I would like to talk about intelligent cubes. This is a form of In-Memory cache.

Rather than returning data from the data warehouse for a single report, you can return sets of data from your data warehouse and save them directly to Intelligence Server memory. These sets of data can be shared as a single in-memory copy, to be used by many different reports created by multiple users.

These are gaining huge importance as they have several advantage over report cache as report caches expire or become invalid in certain circumstances.
A few instances are:

1. When there are changes made to the objects in the data warehouse, the existing caches may be configured so that they are no longer valid when hitting certain warehouse tables. Any further report execution will not hit the cache.

2. When the definition of an application object changes (such as report definition, report, report template, metric definition) the related report cache is marked invalid.

3. When there is need to control the growth of caches in the intelligence server memory, old caches need to be expired automatically.

Intelligent cubes can be refreshed on daily, weekly, quarterly monthly or yearly. In my past experience where I was working with a financial firm, we maintained cubes for different regions - Asia, EMEA and Tokyo. Also we developed cubes for daily and monthly data. Hitting against the database caused performance issues and having a single cube to store all data had its problems.
Also with recent versions of the tool, a new concept called incremental refreshing was introduced where in a cube loaded with 1 lakh records need not be refreshed just to insert or update a few row of records. With this new concept it was just sufficient to build a incremental refresh report with the required criteria to refresh the cube. For eg: If data was loaded for Region A at 9:00 AM from the database into the cube and data for Region B was available only at 12:00 PM then a incremental refresh report can be created on top of the cube with only one filter condition like Region = B and with the insert records option so that it does not override the existing data.