I've been working with a new User Interface Platform group in Microsoft Services IT for the last three months.  This group is using Panorama as their BI interface within their platform. 

Although I have a bias toward building custom web based applications for BI UI's, I must say that I'm impressed with Panorama.  The charting is great and the security models are flexible.  I would say the biggest drawback I've seen at this point is that Panorama does not handle dynamic security models in Analysis Services very well.

One thing I really like about Panorama is that you can customize slicer security by altering their base asp files which gives you maximum flexibility when dealing with data level security.

I'll try to post more information about Panorama in the future.

I have a bias towards developing custom web-based front-ends for reporting applications.  This bias has come from working with clients who have purchased commercial front-ends only to get caught in a dependency trap.  This dependency trap has three components which are on-going software maintenance fees, large consultant fees, and application customization fees. 

Here is a prime example of the dependency trap.  I had a client who purchased an off-the-shelf application that provided about 85% of the functionality they needed.  A good question to ask would be why somebody would purchase an application that only delivers 85% of what you need?  The answer has three parts.  First, it was the best application available at the time.  Second, the VP in charge of the department did not want to build an in-house application.  And third, the salesman for the company told the VP that the application could be easily customized.

Anyway, this off-the-shelf application included 320 hours of consultant time (2 consultants @ 40 hours per week for 4 weeks) for application configuration and training.  After one month, the consultants had burned up the 320 hours on the installation of the application and on training.  However, the performance of the application was pitiful and not operating as promised.  So the consultants stayed for another four months (additional cost to my client) to do their original work correctly.

To make a lengthy story short, every time a change was requested (to customize the application) the minimal waiting period was two months the minimal cost was $8,000 per incident.  Granted, if the changes were significant, I could understand the cost and time….but one request was to have an existing column added to a report.  Since the column already existed, all the company that sold the application had to do was change the query the report was using…something that would require at most, one hour of work.  Instead, they told my client they would need to wait at least two months and pay the $8,000 to have the column added to the report.  How ridiculous.

When my clients ask me what I would use for a front-end, I always recommend developing an in-house web-based front-end because the costs are less and the in-house application will be more flexible and customizable in the future compared to the off-the-shelf products. 

A big concern for senior management is that in-house applications are dependent on the developers who build them.  I totally disagree.  If the in-house application is properly documented then it will not be dependent on individual developers.  So if attrition is a concern, you have documentation for your new developers to follow.