Microsoft Drives Mass Adoption of BI by Hiding It

By Lisa Vaas  |  Posted 2004-09-29

Microsoft Drives Mass Adoption of BI by Hiding It

Bill Baker, Microsoft Corp.s general manager of SQL Server Business Intelligence, thinks few people wake up and say, "Im going to do BI today."

Instead, they say, "Im doing my job today." Thats the mass audience Microsoft is targeting with its latest business intelligence offerings, which include new SQL Server Report Packs for Exchange and Business Solutions CRM; Report Builder, a tool that enables simple report creation via a drag-and-drop environment; and Integration Services, which is a rechristened version of DTS (Data Transformation Services) that will reach into nonpersistent data stores such as those found in RSS (Really Simple Syndication) feeds or Web services.

Baker sat down with Associate Editor Lisa Vaas at the PASS (Professional Association for SQL Server) user conference in Orlando, Fla., to refute the common user misconception that enabling end users with report building will crush the infrastructure under a data deluge, and to talk about Microsofts latest BI advances.

Is it a legitimate concern to worry about end users flooding the system with reports after they get their hands on Report Builder?

[It] is a legitimate concern for DBAs [database administrators] to have. If 10,000 people randomly started writing reports, life could get interesting. But the first thing to understand is DBAs have to give users permission before they write reports. Thats part of role-based permission. You can shut that off for a lot of reasons, and there are a lot of reasons to do that: compliance, for example, or whatever a given corporate policy is.

Do you really want users to start cranking out reports en masse? Some IT managers say no. Read more here.

The second thing is, we cache very cleverly. If you and I pull the same report, we only keep one copy if its cached. We cache the smallest number of reports possible.

Is it true, though, that youll wind up with three report versions, as users tell me? As in, the original report in the OLTP [online transactional processing] system, the flattened Reporting Services version and the rendered report in database cache?

You definitely will have [the data stored in] operational sources—whether thats in order systems, inventory systems or whatever. Its very common to have a data warehouse, [for example,] for a lot of good reasons. And that data warehouse often represents more data than [the original operational sources].

Next Page: You dont have to duplicate data to do a report.


After that, though, OLAP is just an optimization for [end users]. End users always ask for report versions: What region? What city? … It doesnt mean you have to copy the data.

The important thing were trying to do with OLAP is to present a business view of the data. Thats how business users think: "Show me the most profitable city for each product." Thats a really cool thing to be able to find out about a product line.

Thats a conceptual view of the data. But we dont have to make a copy of the data warehouse and turn it into a cube view and stick it on the disk. We can look at it with a relational OLAP lens. Were not unique in that. But it does not require any duplication of the data. If you want, for performance reasons, we and other vendors can materialize a multidimensional view on disk. You get speed, you get faster queries. But we do not have to duplicate any data to do a report.

Does Reporting Services require users to cache data?

No, Reporting Services does not require end users to cache any data. Im not sure where that perception came from. Optionally, we do caching, but we do it on the server.

Whats the trade-off?

Taking up space on the Reporting Services server. But youre saving the time and CPUs on the database server. Youre offloading the database server.

You dont have to cache. You can cache when the first user comes in, keep the cache, expire the cache, keep it around three days or whatever. You have a lot of choices. Theres a lot of control and flexibility there.

Whats the coolest feature of Report Builder?

Templates. One principle is that its easier to edit than to create. If I give you a blank template, 99 percent of people just stare at it. If I give you common shapes and you can start from there, then youre off. Take it and modify it for your own needs.

Next Page: The infinite coolness of infinite drilldown.


[Another cool thing] is infinite drilldown. Thats a cool feature [of Report Builder]. Static reports are somewhat interesting. There are people who wake up, say "Im going to do BI today," they get [reports] in the morning, make a decision and go off and do something [based on the reports findings].

But we want to achieve more interactivity with data. If a number looks interesting, you can hover over it and click it [in Report Builder]. We generate the reports. We make the reports, we use them, then we get rid of them.

You can dance around from report to report to report. You dont have to think it out in advance. Nobody says, "Heres where people may go." You just draw the report, publish it, and end users start navigating it. Theyre creating reports every time they click [on a given piece of data within a report], and they dont even know it.

Thats how you drive mass adoption of BI, is to hide it.

You featured Barnes & Noble Inc. in your keynote. Are they a good example of hiding BI?

Barnes & Noble, now theres a company devoted to its geographies. They say, "The person who runs the store can make a better decision about what books to put in front, what books to put in back, etc., better than any corporate executive or IT staff can do." But theyre not a BI person. We cant tell them to take a training class and go write a report. We say, "Look at the information weve got. If you want to think of it more, start clicking."

Check out eWEEK.coms Database Center at for the latest database news, reviews and analysis.

Be sure to add our database news feed to your RSS newsreader or My Yahoo page

Rocket Fuel