Boris Evelson serves Application Development & Delivery Professionals. See the full Analyst bio.
Visit Forrester.com to learn how we make Application Development & Delivery Professionals successful every day.
Follow Boris on Twitter.
Boris Evelson serves Application Development & Delivery Professionals. See the full Analyst bio.
Visit Forrester.com to learn how we make Application Development & Delivery Professionals successful every day.
Follow Boris on Twitter.
Posted by Boris Evelson on April 26, 2010
By Boris Evelson
There’s a lot of hype out there by many vendors who claim that they have tools and technologies to enable BI end user self service. Do they? When you analyze whether your BI vendor can support end user self service, consider the following types of “self service” and related BI tool requirements:
#1. Self service for average, casual users.
#2. Self service for advanced, power users
#3. Ability to instantly add a new data source (unmodeled). This typically requires some kind of integrated data federation capability
#4. Ability to instantly provision new BI app (via BI SaaS or a mashup) or add storage capacity (usually this requires some kind of data virtualization, private cloud or BI SaaS)
So here’s the list categorized by whether it’s a commodity feature that most BI vendors provide vs. unique and differentiated features that only certain BI vendors offer:
Commodity
Unique and differentiated
If your BI vendor offers most of these, then indeed, yes, they can claim to enable end user BI self service. See the full research doc here
Download the first report from the Mobile App Development Playbook
Comments
clarification on in-memory and ROLAP
There was a great question from one of the readers asking why I included in-memory OLAP and ROLAP as part of the self service BI capabilities. Aren't these just implementation choices, was the question. No, in-memory and ROLAP are indeed much more than just implementation choices. Here’s why
#1. In-memory gives you a ability to explore and analyze WITHOUT a data model, since
- Every entity/attribute is already cross referenced in memory with all other entities and attributes
- Aggregates can be built on the fly
- Every attribute can be instantaneously reused as a fact or as a dimension
So, this means that in a traditional BI environment, when I need to report/analyze something that is not pre-built, pre-modeled in my data model, I have to request a data model change form a DBA. With in-memory model, I can just run the new query and the model is constructed on the fly. I can’t do that with disk based OLAP tools.
#2. ROLAP and “prompt for columns” give me (at least theoretically) a capability to create a single report template, and from that single template I can prompt myself for any columns and drill anywhere in my underlying DWs and DMs. With MOLAP and DOLAP I can only drill anywhere within that cube, but not drill anywhere in the entire DW (or anywhere in multiple DWs and data marts. While I’ve never seen this done to that theoretical extent, I do indeed see that the users of ROLAP (MicroStrategy and Oracle BI Server) typically require fewer canned reports.