Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
- Microsoft SQL Server Programming
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- BI Explained
- Developing a Data Dictionary
- BI Security
- Gathering BI Requirements
- Source System Extracts and Transforms
- ETL Mechanisms
- Business Intelligence Landscapes
- Business Intelligence Layouts and the Build or Buy Decision
- A Single Version of the Truth
- The Operational Data Store (ODS)
- Data Marts – Combining and Transforming Data
- Designing Data Elements
- The Enterprise Data Warehouse — Aggregations and the Star Schema
- On-Line Analytical Processing (OLAP)
- Data Mining
- Key Performance Indicators
- BI Presentation - Client Tools
- BI Presentation - Portals
- Implementing ETL - Introduction to SQL Server 2005 Integration Services
- Building a Business Intelligence Solution, Part 1
- Building a Business Intelligence Solution, Part 2
- Building a Business Intelligence Solution, Part 3
- Tips and Troubleshooting
- Additional Resources
BI Presentation - Portals
Last updated Mar 28, 2003.
As I explained in my previous tutorial in the Business Intelligence series, IT workers often focus a great deal of their energy in building a BI landscape on the back-end tools and processes. This is a good approach, since presenting data before the infrastructure can handle the load or interpretation would only lead to audience frustration, and would slow or kill the adoption of the final product. In that tutorial I explained how to segment the presentation of the analytical results using the "clicks" paradigm. The clicks paradigm breaks apart the user communities based on the number of independent movements they perform to get at the data.
At the "0-click" level, the user doesn't do anything to get to the data; it "finds" them through a common interface such as e-mail. At the opposite end of the spectrum is the "3-click" user, which presents the user with a blank (or nearly blank) electronic canvas that they use to assemble the parts of the data they wish to see. The lower levels require no training or effort, but provide a limited and fixed amount of Business Intelligence. The higher levels provide more flexibility and power but require more effort and knowledge to use.
In previous tutorials in this series I mentioned e-mail as an example of a simple delivery method, and a report or BI tool as a more complex environment. But by far one of the most flexible presentation tools is the Portal. Portals can serve the needs of each of the audience levels, from 0 to 3 click environments.
Several years ago Portal technology was touted as the answer to every enterprise IT challenge. But as time went on, the fervor died down. With so much rich web programming now available, many IT professionals don't see the difference between a Portal page and a complex web page. And in terms of technology, the differences on the web page aren't really all that important. The primary usefulness of a Portal comes in two areas, which have important impacts for the Database Architect: the way the web pages are used, and the back end technology that supports the Portal environment.
Let's start with a simple definition of a Portal, and then I'll apply that to the Business Intelligence landscape. A Portal is a web-based interface that displays a set of personalized or customized data in a consistent fashion. Microsoft Live is an example of a personal portal, where users can select from various topics that interest them and then customize that data based on location, gender and so forth. The choices they make are saved, normally in a client-side file or by using a login, and the user is presented with the same information and environment regardless of where they log on from.
Microsoft also includes a free Portal environment in Windows 2003, called SharePoint Services. Selecting this component installation gives you a full environment that you can use to create content quickly and easily. Adding the Windows SharePoint Portal to Windows 2003 gives you the ability to link all of the SharePoint Services sites and gives enterprise search capabilities, individual site creation and more to the landscape. Microsoft's Analysis Services in SQL Server 2005 can use these tools to present data with very little effort on the developer's part.
There are other Portal software offerings in addition to the Microsoft software. Almost every Business Intelligence vendor offers some sort of Portal technology, or links in to one or more of the top players in this area. Regardless of which you choose, many of these products back-end into a database server. As a DBA, you'll be impacted by a Portal implementation just as you would with any other application. As the Database Architect, the decision you make for a product solution is vital to the success of your landscape.
The primary decision points around which portal to implement involve the usual suspects of cost, ease of use and implementation and technology impacts. But there are other factors that you need to consider based on the solution you chose for your BI landscape. Throughout this series I've emphasized the need to make each layer of the BI landscape a component, so that you can decide whether it makes sense to build a particular layer or buy it. Of course, in every "build" decision there are things you will have to buy, and in every "buy" decision you will have to build or at least customize something. The decision comes in how much your team plans to take on as a development effort and how much you are willing to pay to circumvent much of that work. The same holds true for the Portal decision.
In my experience, most BI systems have not been used to their full potential. Only a select few in the organization are taught how to use the tools and still fewer understand the power the data holds. When a complex BI environment is set up by the IT staff, they often feel that the general audience within the company should be limited to executives. I have stated in these tutorials that the data contained in a BI system is strategic in nature. Should all strategic data be shown to each employee? Certainly not.
But within the sphere of responsibility of each employee, there are tactical decisions that have strategic ramifications. Giving each employee the level of information they need to make correct decisions is one of the best ways to move the company or organization forward. The onus is on the technology implementation team to tailor the information to the audience — hence the applicability of the Portal. Portals are perfect vehicles for presenting BI data to each and every member of the organization. Combined with a proper security design, the same data can be presented to various members of the organization in the most effective way using the same Portal design.
Which brings us to the previous point. You need to ensure that the Portal technology and design decisions are made based on the needs of each employee. If a vendor's solution is only to present higher-level executives with the data, you are better off with a build decision. Although this causes you more work, it provides a superior product in the end, and benefits the entire enterprise. Not only that, but your solution will be adopted more readily by a larger audience, which gives it the focus it deserves and helps ensure success.
When you design your Portal component within the BI landscape, ensure that you consider the following elements:
- The availability of "parts." Each vendor will have a name for this feature, but in essence it is an area on the web page that presents a different section of data. A great feature is the ability to size, move or arrange the parts by the user, and an override of certain areas that are retained by the designer. This gives the Portal a consistent look and feel, but allows users to tailor the environment to what best suits them.
- The level of integration with your other components. I mentioned the Microsoft Portal solutions earlier because they have complete integration not only with Analysis Services, but also with Reporting Services, SQL Server, and even Microsoft Office components such as Outlook and Excel. Other vendors provide integrations to varying levels with these components as well. In any case, if you have bought a solution for a particular layer of your BI landscape, make sure the Portal technology is compatible with it.
- The need broad browser support. Although there are many web browsers available, your organization will no doubt have settled on just a few or even one for the "official" workstation build. If your organization is limited to a single browser, you have far more flexibility in the Portal technology source. If you have a multi-browser environment, ask hard questions about whether the Portal technology adequately supports them.
- Ensure that the Portal technology has a back-end solution compatible with the rest of your infrastructure. One sure way to scuttle all of your hard work is to implement a Portal solution, encounter a problem, and then discover that the only guy that knows Linux just left the company last week for a competitor.
In the integration sections that follow, I'll show you how to display the analytical data in your organization using Portal technology.
Informit Articles and Sample Chapters
An interesting synergy exists between technologies, and this article will show you how to use XML in your Portal choices. As I've detailed before, SQL Server (especially 2005) has the ability to work quite well with XML documents.
I've explained that Reporting Services is often used as both a rich client tool and a simple presentation method. In this article you can learn how to combine both using Analysis Services.