At BlueGranite we've been considering the best way to provide better visibility to all the great capabilities BI and Dashboards deliver.

More often than not, when I do an in-person demo of a dashboard solution, it's the first time the audience has seen this kind of solution before--except for maybe a screen print or a sketch.  Personally I don't think an interactive dashboard can be explained or even understood by seeing a screen print! 

 So, today I made a quick (5 minutes) demo and uploaded it to YouTube...kind of a test of whether this is a good format to share quick ideas and demos.  Afterall, there are only so many opportunities to visit in person, and who can be everywhere at once? (hopefully with the Internet, I can?)

The video below demonstrates a BI solution which is a reduced scope demo of a solution our firm implemented in the transportation (trucking) industry.  The technology is primarily SharePoint, PerformancePoint, SQL Server Analysis Services, Silverlight and Bing Maps.

 If you like this way of communicating/blogging for BI demonstration and best practice, let me know.  It takes more time than writing, but if it's useful then in my view it's worth the time.

 --Rob

I've been heavily involved in PerformancePoint implementations since the beginning of that product's lifecycle...our company has done many deployments for clients.  It's a great dashboarding technology, and I'm continually amazed how quickly we can put together compelling solutions with it.  The efficiency and elegance of the underlying design strikes a great balance between power and simplicity of use. 

 Recently Microsoft folded this product into SharePoint as part of the Enterprise CAL.  The net effect for eCal customers is a "free" enterprise-class BI platform; and for customers that would have invested in the BI platform anyway--all the benefits of eCal, including Business Data Catalog, Excel Services and so on.

Here's a Silverlight video going into some additional detail of the benefits of combining PerformancePoint's monitoring & analytics with SharePoint:

Recently I've been working on methods to display time filters in PerformancePoint M&A that are more user-friendly and efficient for users.  The conventional alternatives--Member Selection, Time Intelligence Post-Back and Time Intelligence Filter--have their strengths, and all of them are user friendly!  However I find that often the underlying data structure doesn't fit with the design of these filter tools.

The fundamental problem I seem to encounter most often is that the data in the average cube isn't "as of" the current system date and/or the [Time] dimension extends well beyond the last date/time used in the data set.  For example, a cube may be processed daily, and the [Last Order Date] is yesterday, but the [Time] dimension extends one year in the future (to support forecasting, perhaps).

So, if the last date of the data is Friday, and today is Monday, how can we make our [Time] dimension filter selection default to Friday?  For Time Intelligence, Day-1 in this scenario is Sunday...that's not what our uses expect!  We could just select the last day in the [Time] dimension using an MDX filter...except that often the [Time] dimension extends out in the future, and our users don't want to default to a future date!

What we really need is a way to fill our [Time] filter with valid members, and pre-select the most logical one.  This way our users will always see valid, sensible data upon loading the dashboard.  Unfortunately, as far as I've been able to determine, none of the built-in Filters will support the scenario outlined above without some intermediate/advanced MDX work. 

What we really need is a dynamic date selector that doesn't use the computer system clock, but rather uses knowledge of the data in our data source.  At our firm we've addressed this for clients in some cases by building in calculated members to our Time hierarchies, or with named sets.  This works OK, but it still hasn't completely solved the problem because it's still tough to control what the default selection is going to be.  So, in this article I'll explore another way I went about this using fairly straightforward MDX. 

Some people aren't that comfortable with MDX.  If you're one of them, don't worry too much, because the template outlined below is pretty simple and you can probably use it without fully undertanding what's happening under the hood.

To use this method, the following should be true:

• The solution is based on a single Analysis Services data source (a cube).  If you have multiple data sources, you need to use the Time Intelligence filters.
• The default measure in the cube is NULL for dates after the filter's desired "as of date"

The basic technique here is to use the MDX filter type in PerformancePoint, and tune the MDX to return exactly the members we want in the list.  Unfortunately there's no way to specify to the PerformancePoint MDX Filter which member should be the default (I don't know why, since the Member Selection filter type allows this..feature request anyone?).  So, we just have to make sure the first thing that's returned by the MDX query is what we want as a default. 

Let's implement two scenarios:

1. A list of months, in descending order, with the last month for which there is data available first
2. The current month, current quarter, and current year--again with "current" defined by the last [Time] periods that have data in the cube 

First, take a look at MDX statements that will return these member sets.  This is just plain MDX you can experiment with in any MDX front-end application, such as SQL Management Studio.

This first query returns a list of all Months in the [Time] hierarchy, and reverses the order so the last month is first. For example: {Dec-08, Nov-08, ..., Jan-08}

SELECT
NONEMPTY (Order([Time].[Time Hierarchy].[Month].AllMembers,
 RANK([Time].[Time Hierarchy].CurrentMember,
   [Time].[Time Hierarchy].[Month].AllMembers),
   BDESC)) ON COLUMNS
FROM [Sales Cube]

Using this query, we'll generate a filter that looks something like this:

This second query returns members from different levels--the last Month, Quarter and Year for which we have data.  For example: {May 08, Q2-08, 2008}

SELECT
{
 TAIL(NONEMPTY ([Time].[Time Hierarchy].[Month].AllMembers)).Item(0),
 TAIL(NONEMPTY ([Time].[Time Hierarchy].[Quarter].AllMembers)).Item(0),
 TAIL(NONEMPTY ([Time].[Time Hierarchy].[Year].AllMembers)).Item(0),
} ON COLUMNS
FROM [Sales Cube]

We'll use this query to generate a filter that looks something like this:

So how do these queries know where the fact data ends? Well, I've cheated actually. These queries work as presented because they will automatically intersect with whatever the default measure is within the cube, and any NULL tuples will be filtered out by the NONEMPTY keyword.  If your default measure doesn't align with what you consider the "data as of" date, you'll have a bit more MDX work to do...you need to add a specific measure to the MDX in that case (see the MDX documentation for a syntax diagram).

You'll need to tweak these queries to work with your own data, but your MDX should be pretty close to these examples.

With the queries tested, simply paste them into a standard PerformancePoint M&A MDX filter definition.  To do so, follow these steps:

1. Create a new query, selecting the MDX Query filter template 
   
   
2. In the Enter MDX Formula edit box, paste the contents of one of the above queries, leaving out the SELECT, ON COLUMNS and FROM clauses.
   
   
3. Save the filter
4. Add the filter to a dashboard, and use it as any other filter

Well, that's it!  The second example is especially flexible, as you can use just about any MDX you want to use to add new items to the list.  Just be certain that any member returned in the query is from the [Time].[Time Hierarchy]...if it's not, your filter targets probably won't know what to do with them and the solution won't work!

While this tutorial deals with a [Time] hierarchy, you can probably see that the same idea can be applied in other ways.  MDX has many powerful functions and methods you can leverage to make filter sets more intelligent--which is a great way to make our users' experience with BI solutions simpler and more intuitive. 

When planning a deployment of PerformancePoint Monitoring & Analytics (PPS M&A), an often overlooked component in the business solution is the ProClarity Analytics Server (PAS) application layer.  

PAS is sometimes not deployed by customers, and their analysts aren't trained in the effective use of these analytical tools. In my view, this is often a mistake.  Analytics has at least two constituencies--and all need to be considered when planning a successful BI deployment.

A sales specialist I have a great deal of respect for, Mac Hussey, once explained it this way...this isn't a direct quote but my interpretation of his ideas: PerformancePoint server M&A's native scorecards, analytic grids & views cover "Little a" (lightweight analytics), while PAS covers "Big A" (heavy analytics). 

Two A's...so what's the difference? "Little a" is flashy, cool and as easy to use as a web page--often requiring no training beyond a quick overview.  In most industrial and service industries, perhaps 85% of BI dashboard users are executives, managers and line of business users.  These users don't use analytics in their primary job function, but use analytics to support their "real" jobs. 

Even in the long-run, they may only want/need "Little a". If your organization fits this mold, it may seem that reaping the low-hanging fruit using "Little a" is really where all the value lies--and that's certainly true at first. Eventually, though, the "Little a" users want to know root causes, and analysts really need to dig and develop further insights.  That's when "Big A" is needed (ProClarity Analytics). 

"Little a" is certainly a "low hanging fruit picker" and brings in quick ROI in for any BI dashboard deployment.  Yet time spent deploying and training on "Big A" is where the game-changing ROI comes from over the mid/long-term. Currently this means deploying an additional application (PAS) and training end-users.  

Eventually I'm sure we'll see ProClarity Analytics fully integrated into PerformancePoint, and the "ProClarity" product brand will be just a fond memory. When that happens, every user will have access to both the "Big a" and "Little a", even if--as with Excel's features--they only know how to use the most common analytical capabilities offered by the product.  Until then, Microsoft BI practitioners who address the needs of users in the "here and now" will need to continue to pay close attention to the spectrum of user needs when planning BI deployments.

In a Microsoft BI environment, we very often want to grant data visibility permissions at the datebase level.  The most common way to accomplish this is to use Kerberos delegation. 

In Active Directory, delegation comes in two flavors: Constrained and Unconstrained. Constrained delegation provides an enhanced level of security for deployments where Kerberos delegation is used to pass end-user credentials to back-end services.

In an unconstrained delegation configuration, servers and service accounts are trusted to send Kerberos tickets to any service on any destination computer. This typically isn’t a problem, since administrators know what their service accounts are used for, and what software is installed on their servers.

However, using constrained delegation provides an additional level of security by restricting which back-end services on which destination server a computer account or service account may pass Kerberos tickets to. Constrained delegation satisfies the “principle of least privilege”, where even trusted principals are granted only the minimum permissions needed to get their job done.

Promoting delegation from unconstrained to constrained delegation is relatively simple. This additional level of security isn't without cost, however.  Following a constrained model will result in additional long-term administration (the addition of a new back-end web server or database will require additional Active Directory configuration). However, if the least privilege principle is the best practice in your company, constrained delegation is for you.

The following process goes through constrained configuration of a typical distributed Microsoft BI environment. This process assumes you’ve already configured an unconstrained Kerberos delegation environment. The following only covers the upgrade to constrained delegation.

In the following scenario, there are:

1. A single database server running SQL Server and Analysis Services (BI-DB).
2. An application server hosting PPS Monitoring Server, ProClarity Analytics Server and Reporting Services (BI-APP)
3. Finally there is a SharePoint server (BI-WEB).

Services on each server are run using the service accounts svc_bi_db, svc_bi_app, and svc_bi_web, respectively.

First the documentation. Don’t skip this step! The key to completing this process successfully is organization, because any mistake may cause integrated authentication to fail and the troubleshooting will be difficult and even more time consuming! You need to know what service accounts are running each service on every server, and use this information to make Active Directory configuration changes.

Documentation is a two-step process: document delegation trusts needed for each server, then the trusts needed for each service account. If you’ve already setup your basic Kerberos delegation using SetSPN or ADSIEdit, you should have this information handy.

The following are the trust requirements for our scenario:

With this information, we’re ready to make the Active Directory changes. These changes are mostly made in the Active Directory Users and Computers snap-in, however we’ll see that the named instance used for the OLAP server isn’t supported by this snap-in (I don't know whether this is a bug or the intended behavior, but you can read about it in Microsoft knowledge base article 936628). We'll work around this limitation by making the final configurations in the ADSIEdit snap-in.

First let’s take care of the machine account configurations:

1. Launch Active Directory Users and Computers.  Find the PPS server (BI-APP for us) in the list, double-click it.
2. Click on the delegation tab. 
3. Select the third option, Trust this computer for delegation to specified services only
4. Click the Use Kerberos Only radio button
   
5. Click the Add button
6. In the Add Services dialog, click the Users or Computers… button, then enter the service account used to run the database services on the database server (the second column in table #1). 
   
7. In the Add Services dialog, we need to select all the services in the third column of table #1 (MSSQLSvc/BI-DB:1433 and MSOLAPSvc.3/BI-DB:PROD in this example), then click OK.  Note that if your OLAP database is a named instance (as ours is), then only MSSQLSvc is available…this is because this snap-in doesn’t work for named OLAP instances.  We’ll get around this problem later using the ADSIEdit snap-in.
8. With MSSQLSvc added to the Delegation tab of the BI-APP machine account, press OK on this dialog to save the delegation settings.
   
9. Repeat the same sequence for the BI-WEB server, but this time in addition to adding services for the account svc_bi_db, also add services for the svc_bi_app account to allow delegation of security for HTTP services to that machine.  When you’re done, the computer account delegation tab for BI-WEB should look like this:
   
10. Repeat the same sequence for BI-APP’s service account (svc_bi_app) using the values in columns 2 & 3 of table #2, yielding the following configuration when complete:
    
11. Again, the same sequence for BI-WEB’s service account (svc_bi_web), yielding the following configuration:
    
12. If your OLAP database has no instance name (you're using the "default instance"), you’re done!  If not, you’re almost finished, except that the Active Directory Computers and Users snap-in doesn’t support the named instance of the OLAP database.  So, open the ADSIEdit snap-in (adsiedit.msc) instead.
13. Navigate within ADSIEdit to find the computer account for the APP server (BI-APP for us). 
14. Right-click on the computer, choose Properties.
15. In the Attribute Editor, locate the string msDS-AllowedToDelegateTo, and click the Edit button.
16. Add two values for the OLAP database used in your environment (MSOLAPSvc.3/BI-DB.terrafirma.kerr.cc:PROD and MSOLAPSvc.3/BI-DB:PROD for our example).  Note that the two are the same except one has the FQDN and the other has only the NetBIOS name of the server.  Both are required.  When finished, the string editor should look like this:
    
17. Click OK, on the string editor, then OK on the machine properties to save changes.  If you return to this editor in ADSIEdit, you can review and update these chnages.  However, beware that if you review changes in the Active Directory Users and Computers snap-in, you won't see these named instance entries.
18. Repeat this change for the web server as well (BI-WEB in this example)
19. Repeat this change for the user accounts used on the BI-WEB and BI-APP servers (svc_bi_web and svc_bi_app in this example).

OK, that’s all.  Now the environment is configured for constrained delegation.  From this point on, AD will still allow Kerberos delegation as before, except now it will carefully check not only that service accounts are running on the machine they should, but also that each service account is only passing tickets to servers/services that are pre-authorized.

Business Intelligence is a broad topic, spanning a set of technologies and business improvements spanning from enterprise reporting to analytics to performance management.  One of the more interesting areas is in data exploration and visualization.

State-of-the art BI tools enable a level of exploration and data visualization beyond our wildest imagination when I started in BI 15 years ago.  At that time, to achieve acceptable performance virtually everything deployed to a broad audience had to be pre-designed, and with only a limited amount of “ad-hoc” direction by the end-user. The value was still huge—pulling together multiple data sources into a cohesive reporting environment was a jump to light-speed (many companies are still trying to make that jump today).

One of my favorite data visualization tools is the Decomposition Tree.  I love the Decomp Tree because it’s super-intuitive…everyone “gets it” right away. 

The Decomp tree is powerful not just because it can “break down numbers”—we’ve been doing that with hyperlinks on reports for years.  The real power is that it allows users to select his/her own breakdown path, then easily explore that new path, tweak it, and cross-drill across dimension members.

In the screen print above, we started with Geography and switched to fiscal year, then switched to product.  The Decomp tree makes it easy to let the user go in any direction in any order—all very easily. No need for the report designer to anticipate every permutation the user might need!

By delivering this type of visualization to users, everyone wins.  The users win—they get the information they need quickly. Information at your fingertips – delivered! For IT, tools like the Decomp Tree let users access information in the format they need it, rather than prompting yet another custom reporting request.

Francois Ajenstat wrote in a recent blog posting that Microsoft will release a SP3 for SQL Server 2005.  There has been a groundswell of support in the user community for this, and it's a relief to know it's on the way.

This is especially great news for those of us deploying and supporting PerformancePoint on the SQL 2005 platform.  Currently, the system requirements for PerformancePoint planning server require build 3186 of SQL Server 2005, which is a "hot-fixed" version of SQL Server 2005.  It has seemed a bit strange that the production version of PerformancePoint Planning server requires a hot-fix version that's only available through special request to Product Support Services.  It's nice to see that will change soon.

While on the subject of build version numbers, keeping all the build numbers straight can be a real challenge sometimes.  One handy SQL statement to pickup the service pack level if you don't recall version numbers well:

SELECT 'SQL Server ' 
+ CAST(SERVERPROPERTY('productversion') AS VARCHAR) + ' - ' 
+ CAST(SERVERPROPERTY('productlevel') AS VARCHAR) + ' (' 
+ CAST(SERVERPROPERTY('edition') AS VARCHAR) + ')'

Also, aspfaq.com hosts the following pages that have complete references on build numbers:

SQL Server 2005 build number matrix

SQL Server 2000 build number matrix