Hands-down: Object-oriented metadata architecture.
Why? Allows the re-use of objects throughout the platform, resulting in fast development, need for smaller staff, and faster ROI.
Example: Create a filter for Latest Month.
You can add that filter to any metric, use that filter in any report, add that metric into any other metric (such as Latest Month Highest Performers). Any metric can be added to any report. Reports can even be used as filters within other reports.
It can be used in any platform MicroStrategy offers: Developer, Web, Office, Mobile, Dashboards, Data Discovery… This is the same for metrics, reports, dashboards, etc. Build it once, use it anywhere (no need to create duplicate objects for Web and for Mobile, for instance).
If a change is needed in an object, the change is permutated throughout the system. For instance, if the definition of the Sales metric changes, you change the Sales metric and wherever the metric is used, the change is expressed.
This feature saves a lot of time in development and support because you don’t need to keep re-creating objects (and in re-creating them, introduce possible errors). A very small team can support many more users than any other platform, saving the organization money in the long run. In my opinion and experience, this gives MicroStrategy the edge over any other BI system.
Improvements to My Organization
Truly provides a single version of the truth. Once you create a metric or report that is correct, it is always correct, no matter where it is deployed. When a company I used to work for first rolled out MicroStrategy, there was a lot of suspicion by the existing DBAs and the traditional SQL report developers about the system’s results. If a report would show incorrect results one month, there was a lot of finger-pointing at MicroStrategy and ‘AHA!’s. In every case, the MicroStrategy team was able to prove that the error was due to incorrect data in the database.
Over time, the MicroStrategy system grew to be the ‘system of record’ and used to validate data loads for other systems.
Room for Improvement
Documentation and training: Though the basics of the platform are well documented and the in-house training offerings are the best software training classes I have ever attended, MicroStrategy falls a little short when it comes to some of the lesser-known/used features. For most, this will not cause a problem. But if your situation calls for the need to work with System Manager (a workflow application), for example, you'll be stuck searching thru Google and YouTube looking for information.
Use of Solution
I have used it since version 5 (1998); 18 years off and on.
I occasionally encountered stability issues. If the metadata becomes extremely large, I have seen instances in which there are internal inconsistency errors. By this, I mean that it’s not that the system suddenly returns incorrect data but rather the internal definition of an object (could be any object: metric, filter, fact, report, hierarchy, etc.) becomes ‘corrupt’. MicroStrategy provides an easy-to-use tool, ScanMD, that finds and fixes these issues should they occur.
The inconsistency is due to the way the MicroStrategy metadata is structured. It is a relational database with many tables. These tables have foreign keys to the other metadata tables. For example, an Object table and a Where Used table. Sometimes the deletion of an object or an update in an object might not be cleanly expressed throughout the metadata database and the relational integrity is broken for that object, throwing an error message when the object is used.
I have not encountered any scalability issues.
Customer Service and Technical Support
Like any technical support group, it depends on which individual you are working with. Some have been stellar. Others make you wonder if they’ve ever really worked with the software beyond basic training. Overall, they are better than most I’ve dealt with.
I did not previously use a different solution.
Set up can be complex, though not as complex as SAP, for example. The most important thing, the very most critical thing, is that the data model is correct. Attributes need to be clearly understood and their relationships to each other and the various facts needs to be carefully defined BEFORE you begin. An ER diagram, be it in Visio or a tool like ERwin, is invaluable and in my personal opinion a must have. Going back to redefine attribute relationships and table structures can be very difficult. Do not think you can ‘figure it out as we build’. You’ll need a person who is an experienced data modeler on the team.
Software installation and hardware configuration is fairly straight forward.
Pricing, Setup Cost and Licensing
MicroStrategy can be very expensive compared to other platforms – at first blush. The cost of purchasing the software and licenses has frequently been identified in numerous surveys as the factor most often cited for not going the MicroStrategy. The initial buy-in can be expensive; however, the platform is so much cheaper to run over the long haul than most other enterprise systems. A very small dedicated team of developers and quick development times (after initial setup) result in a much-lower yearly platform cost than other systems.
From a licensing viewpoint, there are basically two ways to go: per CPU or per user.
Per CPU: If you will have more than a few hundred users on your system or foresee a very dynamic user base where the number of system users can grow rapidly then shrink then grow again – use per CPU. You can have virtually unlimited users.
Per user: If you have a well-defined user base that you anticipate to stay roughly the same or grow slowly over time this may be your best option. Also, if you anticipate a very high workload (many thousands of reports run per day), this option allows you to add hardware without incurring licensing costs.
FYI It is easier to renegotiate your licensing with MicroStrategy if you go from per user to per CPU than to go the other way around.
Other Solutions Considered
I do not know if/what other products were evaluated prior to MicroStrategy.
- Do not attempt to ‘learn as you go’. It is a powerful platform and thus complex to understand. Attend MicroStrategy training classes. MicroStrategy offers on-line and in-house options, but take the classes at a MicroStrategy-sponsored training center; you need to be fully immersed. Those who’ve attempted ‘learn as we build’ are never satisfied.
- Your team needs to have at least one person who is an experienced data modeler and that person needs to take MicroStrategy Architect training and should become MicroStrategy certified in that.
- Your team should have a medium proficiency in SQL. They don’t need to be SQL wizards but they should have a solid base.
- Your initial developers will need to be dedicated MicroStrategy resources. Do not expect them to be supporting and developing a variety of other software/platform initiatives.
- Have a very good working relationship with your DBA staff. Communication is key.
- Document, document, document. Documentation is not for you and your staff – it’s for the poor developers that come in afterwards. Have an ER diagram available for all your source databases. Have flow diagrams showing data loads, schedules, events, outputs. Maintain your system server diagrams (including ODBC connections, etc.). Besides helping new staff with on-boarding, it will help analyze impacts of system changes and is a virtual requirement when doing upgrades.
- In your project plan, expect to utilize at least 25% of the timeline in building the data model (if one does not already exist).
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Sep 19 2016