Want to know what Forrester's lead data analysts are thinking about BI and the data domain?

By Boris Evelson

What is BI? There are two prevailing definitions out there – broad and narrow. The broad definition (using our own) is that BI is a set of methodologies, processes, architectures, and technologies that transform raw data into meaningful and useful information used to enable more effective strategic, tactical, and operational insight and decision-making. But if we stick to this definition then shouldn’t we include data integration, data quality, master data management, data warehousing and portals in BI? I know lots of folks would disagree and fit these into data management or information management segments, but not BI.

Then, the narrow definition is used when referring to just the top layers of the BI architectural stack such as reporting, analytics and dashboards. But even there, as Jim Kobielus and I discovered as we were preparing to launch our BI TechRadar 2010 research, we could count over 20 (!) product categories such as Advanced Analytics, Analytical Performance Management, Scorecards, BI appliances and BI SaaS, BI specific DBMS, BI Workspaces, Dashboards, Geospatial analytics, Low Latency BI, Metadata Generated BI Apps, Non modeled exploration and In-memory analytics, OLAP, Open Source BI and SaaS BI, Packaged BI Apps, Process / Content Analytics, Production reports and ad-hoc query builders, Search UI for BI, Social Network / Media Analytics, Text analytics, Web Analytics.

 

To make matters worse, some folks out there are now trying to clearly separate BI and analytics, by trying to push a “core, traditional BI is commoditized, analytics is where differentiation is today” message. Hmmm, I thought I was building analytical apps using OLAP starting back in the early 80’s.

 

Read more

Not all BI self service capabilities are created equal

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.

  • What do these users need to do?
    • Run and lightly customize canned reports and dashboards
    • Run ad hoc queries
    • Add calculated measures
    • Collaborate
    • Fulfill their BI requirements with little or no training (typically one needs search-like, not point-and-click UI for this)
  • What capabilities do they need for this?
    • Report and dashboard templates
    • Customizable prompts, sorts, filters, and ranks
    • Report, query, dashboard building wizards
    • Portal
    • Semantic layer (not all BI vendor have a rich semantic layer)
    • Prompting for columns (not all BI vendors let you do that)
    • Drill anywhere  (only BI vendors with ROLAP and multisourcing / data federation provide this capability)

#2. Self service for advanced, power users

  • What do these users need to do?
    • Perform what-if scenarios (this often requires write back, which very few BI vendors allow)
    • Add metrics, measures, and hierarchies not supported by the underlying data model (typically one needs some kind of in-memory analytics capability for this)
    • Explore based on new (not previously defined) entity relationships (typically one needs some kind of in-memory analytics capability for this)
    • Not knowing exactly what one is looking for (typically one needs search-like UI for this)
Read more

BI on BI

By Boris Evelson

How do you know if your BI application has high, low or no ROI? How do you know that what the business users requested last month and you spent countless of hours and sleepless nights working on is actually being used? How do you know if your BI applications are efficient and effective? I don't have all the answers, but here's what I recommend.

Start with collecting basic data about your BI environment. The data model (hint, it's a classical multidimensional model exercise) should have the following components:

  •  Requests (these should be available from your help desk and project/portfolio management applications), such as
    • User provisioning
    • New applications
    • New data sources
    • Data model changes
    • New/changed metrics
    • New/changed reports
    • New report delivery options
  • Usage (these should be available from your DBMS and BI apps log files or from www.appfluent.com or www.teleran.com) by
    • Person
    • Time of day
    • Database
    • BI application
    • Report
    • Index
    • Aggregate
    • KMI/KPM
  • Track additional events like
    • Application usage vs. using application/report just to download or export data
    • Incomplete/cancelled queries
Read more