Architecture
=========
In a nutshell, Microstrategy (or MSTR for short) architecture is composed of three layers
1 - Web/Mobile interface that connects to any given Intelligent Server (middleware)
2- Middleware (Intelligent Server) that
a. connects to data layer (many connectors included in the default license)
b. executes created SQL/MDX queries, OLAP functions
c. Generates pre-loaded MOLAP cubes (aka Intelligent Cubes) to speed up results (if defined)
3 - Data Access: Access to your DataWarehouse (no need to be dimensional model, but recommended) using any of the several included connectors
Attributes and Facts definition
======================
Using Microstrategy Architect you basically define:
a. Attributes and attribute forms (which corresponds to the Dimensions in the Dimensional Model)
b. Facts (which corresponds to Facts)
c. System Hierarchy or relationship of Attributes to Facts. Here it is where you also define your Star or Snowflake model for your attributes. Also (and this is a really cool feature) same Fact can be located at different aggregation levels either because you have it in the datasource (e.g an agg view) or because you ask a given FACT in MSTR to extend the value to another level. This is interesting to enhance performance using tables with pre-processed aggregated data, instead of letting MSTR calculate aggregations "on the fly"
d. User Hierarchy: or drill-in paths to see the information in your reports / Documents
Report and Dashboard Generation
=========================
Then you can start creating :
- Measures: Formulas (e.g KPIs) that uses Facts or other measures
- Reports which are data sets of attributes and Measures (here you can also use other type of objects like filters, consolidations, custom groups,etc...). You can see and export these datasets in a variety of formats (Excel, PDF, etc...) However the top use case for this report is as datasource for Documents/Dashboards
- Dynamic Documents and documents: You include "n" number of reports as your datasource and then represent using the widgets (Tabs, Tables, Heat Maps, ESRI Maps, ...) These are ultimately the Dashboards or final reports that end user will see and - here it comes the most valuable feature of MSTR from my point of view- either from Web or from mobile device - So you can quickly compose a mobile dashboard in few clicks if (and only if) you have created the right data model (e.g a solid DWH schema). At this point it is worth to mention that MSTR allows you to iteratively enhance the model and reports/dashboards (so no big-bang deployment needed)
- You can also create predictive analysis (datamining) using some of the techniques and gadgets provided as well as interactively play with data and come to conclusions using MSTR Visual Insight (kind of an 'slice and dice data' tool). Outputs from those analysis may be dashboards/documents.
Scheduler
========
Reports and Documents can be run on demand or can be scheduled to be generated and sent to target audience. Scheduler is also responsible of the Intelligent cubes refreshing (MOLAP recreation at a regular basis)
Microstrategy licensing model allows:
===========================
a. Access to all tools available (recent change, one year ago more or less) - before you had to license certain tools, now you have access to all tools in either on-premise installation or Cloud. Interesting Tools
b. In the on-premise installation model, licenses per user and therefore have high scalable BI solutions: In this licensing model you can deploy your architecture (Web Front-end and Middleware or Intelligent Sever) in as many servers you want.
Before we used Microstrategy at Xerox Services (HR services) we used to analyze data using Spreadsheets, to calculate and report on service SLAs and KPIs.
No need to mention how using MSTR has enhanced the process since then but a couple of the key benefits are:
- Data access not affecting transactional systems (data sources)
- Complex calculations (SLAs, KPI rules) right there on time when needed and always right or always wrong but centralized in a single place where formulas can be corrected if needed
Probably this is not MSTR's fault but BI tool in general: sometimes trying to follow MSTR rules to get some formulas and data using MSTR techniques is harder (and less performant) than just prepare yet another DWH view collecting needed data (with needed inner or left outer joins and aggregations) and just model that new view in MSTR.
Also MSTR, as all these BI tools, generate automatic SQL code from the model defined in the architecture tool so sometimes you are getting weird results but are easily trackable (MSTR reports in all SQL generated code) to be fixed.
No ETL comes with the tool, either you have your own solution (MSTR SSIS, Informatica) to model your DWH or you connect MSTR to the datasource / transactional (which is not good)
You can use MSTR as an ETL tool though - when you import data you have data wrangling option where you can apply many functions as well as creation of new columns. Also MSTR enables you to connect to the files and with datamart functionality or transaction functionality and ffsql you can write it back to DB. Its far from being Informatica yet there are some options how to handle this...