Starting with the release of Strategy ONE (March 2024), dossiers are also known as dashboards.
Strategy is one of the veterans in the BI industry, and whether it is a good match for big data projects or not is a question I’ve been asked far too many times in recent years (basically almost before every launch of a new project, give or take).
To me, the question seems to be a very valid one. And I think Strategy has asked the question internally so many times and thus enhanced the product in that direction. This is not a shortcut or a twist in the product, but more of issues carved deep in the product DNA. We tend to think that 'big data' is a new term and that it was there was no such thing before it was named, but in fact Strategy has been handling very large amounts of data for a long time before the term was invented.
It’s not like “we got here first” or anything (and who is “we” exactly anyways), but once you get to the top, and stay there for a very long time (and number of product versions) you do have an advantage. You see that with a lot of BI tools; Qlik was very proud of their memory management since the product was initially developed with strong limitations of very small memory sizes at the time, thus they have very efficient memory handling, and an in-memory data model to match. The same goes for Strategy, but for one key functionality that becomes a game changer with big data – relational online analytical processing, known as ROLAP (I’ll elaborate soon for those not familiar with the term).
Strategy has several key advantages:
1. A best-of-breed ROLAP engine that enables optimal utilization of the big data platform
2. An Enterprise grade architecture - multi tier clusters & load balancing
3. The ability to develop any flavor of BI reporting and dashboards from multiple sources and blend it together at multiple platform tiers
4. Changes in the big data Platform Ecosystem
I’ll try my best to explain:
1. Best of breed ROLAP engine that enables optimal utilization of the big data platform
ROLAP is a term long used in the BI field and stands for “Relational Online Analytical Processing”. To keep things short – it does the analytical analysis directly in the underlying data platform, instead of on a dedicated server on the side.
This used to be a slightly limiting factor in the old days, but with today’s progress in big data platforms, the response times over huge amounts of data can retrieve results surprisingly quick, while in the process – using the platform you already paid for, for exactly what you paid for it to do – perfect match.
Does it make sense to invest money in a big data project and then retrieve data to a different multi-dimensional engine that has far less resources for analysis? The answer is rather clear.
(You can read more about ROLAP here, here, and here.)
And to top all that, Strategy can work directly on top of existing table structures. Usually there is no need for pre-created view layers, so any kind of calculation can be created from the base table or an aggregation table.
2. Enterprise grade architecture - multi-tier clusters & load balancing
Strategy is built for performance and workload. Each and every tier in the architecture can scale to a cluster of multiple nodes. It is still not yet unlimited like Hadoop style server farms, but clusters of up to 8 nodes are usually enough computing power to support all your users, even for an OEM customer base. Columnal storage cubes with internal “map reduce” style queries supply great performance and help boost throughput for complex tasks when needed.
Strategy clusters help control and distribute the workload across multiple servers, and since a lot of data entails potentially bigger data-sets, this control is important. You can control at multiple levels of the product, again, depending on the bottlenecks.
3. Develop any flavor of BI reporting and dashboards from multiple sources and blend it together
In traditional BI, almost all the reports/dashboards came from a single data-source (the Data Warehouse (DW) obviously). Today, many times the old DW is still working, and there is an additional big data project in the organization (either as a temporary phase, or as new technology assistance such as columnar tables to help relational database performance).
So, there is a need to blend (\mesh) data from several different source systems. I have seen a few production environments where a single report displayed data from several SQL Server databases, Vertica and MySQL. Strategy does that well for several such scenarios on multiple levels, just pick the most suitable one for your needs.
It is common to think that all the BI is done by dashboards, but in fact the plain old “reporting” is still alive. Not all data requirements are dashboards and data discovery or in-depth analysis, and for that Strategy is a winning horse with a lot of capabilities.
No matter what kind of report, Strategy can do it all. It does dashboards (dossiers), it makes pixel perfect documents for complex logics in the front end, and it creates basic flat reports for Excel and csv integrations.
MSTR acts as a one-stop shop, no need for multiple tools to accomplish the different tasks. One platform can support them all. With the same objects comes a unified logic, unified security, etc. If you have several different tools in the organization, you know how much time may be invested in changes between reports created by different tools.
4. Changes in big data Platform ecosystem
We tend to think that the platform is more or less permanent. This used to be true with old DW vendors (and not to mention OLTP databases, where it’s usually even more complicated). But it seems that in most big data projects, even though it is never easy, a change of data platform is considered more often than in the past, and eventually occurs more than in the past. Maybe the reason is the rate of change in the big data ecosystem, and the number of new unicorns that seem to be popping up like mushrooms after the rain.
“How is that related to Strategy?” you ask? The big advantage of Strategy is that the queries are not hard-coded in the product. So once Strategy supports the original database (DB) platform and the destination DB, the reports could change platforms a lot easier than performing the changes manually. Just recently, I’ve changed a project from Redshift (with a nice set of query optimizations for redshift) into Snowflake. The move from one vendor to the other took a few hours, but even though the queries look very different, since Strategy creates them, it was really straight forward. It was not a big project yet, but the bigger the project becomes, Strategy’s advantage in this area becomes clearer.
This article is focused mainly regarding Strategy and Big Data. As a platform, Strategy includes various additional features that help to complete the vision of the data platform and the day-to-day data life: automation, administration, versioning and merging tools, etc., and obviously, the famous metadata of Strategy. But these are not specifically related to big data projects, thus not in the scope of this article.
In short, in my opinion...
If you have a big data project/platform and you consider any reporting or BI on top of it, I would strongly recommend Strategy as one of your options. It will probably check more “V”s for capabilities in your checklist than others, and with a long and successful track record you can be sure that your data platform is in the right hands.
No matter which BI platform you eventually choose for your data platform– best of luck to you all!!!!
A note from the Community team
Learn more about big data and Strategy: Analyzing Big Data in MicroStrategy product documentation.
Also, check out Nadav's Hebrew translation of this article.
