Home > Articles > Data > SQL Server

SQL Server Reference Guide

Hosted by

Business Intelligence Layouts and the Build or Buy Decision

Last updated Mar 28, 2003.

With a firm understanding of the uses for a business intelligence system from the first set of articles in this series, in the last article I explained the various parts of the landscape that you can build a system with. In this tutorial I'll explain the ways you can put those parts together to create the landscape you need.

Before I do that, we need to discuss the various options you have for putting your system together. At a basic level, you can either build the landscape yourself, or rely on buying a complete package from a vendor for the solution.

To be sure, in every build solution there's something to buy, and in every guy solution there's something to build. Let me explain that a little further.

If you decide that it would be preferable to build all the components I mentioned in the last article, you still have to license certain pieces, such as the operating systems, databases, and reporting systems. On the other hand, if you buy an entire solution, you still have to wire up the various components. Most vendors have either a graphical or programming language extension to accomplish this, but you still have to do quite a bit of work on your own to put everything together, despite what the nice vendor tells you. And don't always believe that an expensive complete package will save you time.

In fact, on some of the larger BI systems I've worked with such as SAP's BW, the time spent making the system function far exceeded what it would have taken me to implement a custom solution. So what factors would cause you to buy versus build, or vice-versa?

Once again, it's best to build a matrix to make your decision. As you may have guessed by now, I'm a big fan of making decisions this way, and for good reason - it just works. To make a decision matrix, place the various options such as the vendor's solutions and the build-it-yourself routes in a column on the left side of a spreadsheet. Across the top row, list out the factors that are important for your organization, such as total time to implement, supportability, total costs and the like. In the columns next to each decision, rank the decision objectively, with the higher numbers meaning that this particular decision doesn't meet the requirements as well and the lower numbers meaning that it does. In any case, make sure the factors work to the positive, meaning that if you get all one's in a row, it would mean you'll use that decision. Sort the results, and you'll have your answer. I do this so much I even buy a car this way!

In simple decisions such as buying that car, I can do all the research myself, and mostly just with a Car and Driver magazine and the Internet close at hand. In a decision as large as your entire enterprise, however, this needs to be a group effort. In fact, it's not a bad idea to pay for a little outside help, as long as it's from an objective source. Whatever you do, consider the source systems as a heavy factor. One of the reasons we chose the SAP solution in the case that I mentioned was that the primary sources for the data were all SAP R/3 installations.

These days it's becoming a bit more difficult to find a pure build or buy. Oracle has a very mature Data Warehouse function built right into their database, and you can use SQL Server 2000 with DTS to do everything except reporting. In SQL Server 2005, Microsoft includes a complete end-to-end solution for Business Intelligence. In addition, many vendors BI solutions leave something out here or there, such as a Meta Data Repository or a robust ETL tool, so you end up having to build on top of your buy.

To help you with this process, it's best to know what you need. In the last article I mentioned several components, and you can mix and match them in various ways to suite your needs. While the exact configuration can take hundreds of shapes, there are three basic categories that I group layouts into from a broad perspective.

NOTE: Let me reiterate that if you don't have a coherent data strategy and a rock-solid reporting infrastructure, you don't need BI yet. Get those things straightened out first, or you'll have serious problems when you integrate that data into a BI landscape.

The first layout type is fairly simple. It involves your source systems, an extract tool, the Operational Data Store, and the front-end tools such as a BI explorer and a reporting system. If you're unfamiliar with any of these terms, see the last article.

With this simple solution, you're usually implementing in a department or a small company environment, something with only one or two similar source systems. The primary concern here is getting data out of the source systems into an analysis system. With the (free) optional Reporting Services software from Microsoft, you can implement this entire scenario fairly quickly using SQL Server with DTS packages and Analysis Services, which I'll cover in a future tutorial. In some cases all you're looking for is analytical reporting, which can be accomplished with something like Crystal Enterprise or Hyperion.

The next step up is to aggregate data from one or more departments, companies or regions. To create and analyze this kind of information, you'll transfer the data from the ODS layer to a Data Mart.

In this layout, you've got a management-level audience, so the ease of use becomes far more important. Managers don't have time to learn lots of complex software tools, so you'll need to have their requirements built in to the presentation.

Other considerations on the build or buy for this layout are the network loads that it creates for transferring the data. Do you "trickle" the data across or do you "bulk load" it during non-peak hours?

The last layout type is the most complex. In this system you're bringing the data all the way from the source systems through an ODS Layer and several Data Marts.

You won't be able to bulk-load this level of data unless your users will tolerate the lag it takes to move it through the system. Whether you decide to bring the data over in small chunks or large loads, make sure you create a plan for the inevitable failures that will occur in transfer. Your plan should allow for the data to be late, but not inconsistent.

In this layout you'll have tools at each level pecking at the data. As you turn the data to information, the vital need is Meta Data. At every level, the user needs to be able to click on a data field and find out what it means. Remember, you don't decide meaning (the business does) but you do implement it.

In the next tutorial, I'll dive deeper on these components, starting with the Operational Data Store. I'll begin to create a Business Intelligence system using SQL Server.

Books and e-Books

If you're getting serious about a Business Intelligence system, check out some real-world experiences in Impossible Data Warehouse Situations: Solutions from the Experts by Sid Adelman, et. al.

Online Resources

For a lot of information on the various "buy" solutions, check out DMReview.