The other week I wrote a post discussing how PowerView was the future of SQL Server Reporting Services, and the killer features that made it a compelling choice. Despite the numerous positive advances that PowerView brings to Microsoft/SQL-based reporting, there are of course a number of counter arguments. I deliberately left these out in order to look at some of these reasons in a later post.
As such, here are five reasons why PowerView, despite all its pizzazz, is simply not capable (in its current form) of replacing the venerable SSRS.
One of the major shortcomings of PowerView’s current implementation is its lack of customisation options. Compared with vanilla SSRS, where you can tweak just about every single property of a control, the options in PowerView are extremely limited.
Take the charting component, for example. In PowerView, you have a choice between 4 types of chart: Pie, Line, Scatter or Bar/Column (I’m not going to even entertain these as different types). You can assign your axes and values, and choose a colour scheme for your view…and that’s it. No secondary axes, scale breaks, major/minor tick marks, and so on.
SSRS is extremely powerful, and all the properties in standard SSRS objects are still there in the underlying RDL file (check out Dan English’s blog for a rundown of what makes a PowerView RDLX file), they’ve just been disabled. It’s possible there might be more control in a future version of PowerView if Microsoft choose to expose more options, but for the time being, if you want customisation, you’re better off sticking with vanilla SSRS.
But it’s much easier when you don’t have to install anything extra to view your reports.
Ahhh, SharePoint. And not just SharePoint, but SharePoint Enterprise. It’s like Microsoft’s own, personal licence to print money. Yes, with Excel 2013 you can share Excel workbooks, but it’s a long way from being a portable, easily accessible solution.
Vanilla SSRS supports either SharePoint integration or a native mode Reporting Services server, which includes all the necessary components for deploying, managing, scheduling (more on that in a minute) and running reports. It’s also much cheaper than forking out for a SharePoint Enterprise licence, requiring only the free SQL Server Express Edition to run an SSRS native mode server (at least in its most basic form).
Unfortunately, it’s currently SharePoint Enterprise only for PowerView, something that is sure to be a blocker to many SME’s in adopting PowerView in any serious manner. Microsoft seem set on pushing SharePoint as an important part of their BI platform, but they really need to consider how to help people share the great things they create with the tools on offer.
As I mentioned above, one of the great things about SSRS is its support for automation of report execution and delivery. A lot of businesses rely heavily on the ability to create dynamic data-driven subscriptions and deliver reports directly to client and executive inboxes at critical times.
With PowerView not currently having any means of scheduling or automatic report delivery, there’s a large gap here that quite simply requires SSRS. Even if Microsoft were looking to replace vanilla SSRS with PowerView, there’s a huge infrastructure shortfall that needs addressed. Report automation and delivery is an absolutely critical business requirement, and one that PowerView and its supporting cast is simply not equipped to handle. It’s great for the power users and self-service BI platform, but there’s still a massive need for the business support that SSRS can provide.
Finally, one of the greatest, and most overlooked capabilities of vanilla SSRS is its sheer flexibility. Even if you’re totally stuck on a report and can’t figure out a way to achieve your goal, you can always extend it by using some custom code. Simple functions can be embedded within the report itself, while entire client libraries can be deployed directly to the report server, offering a huge array of features to even the simplest report. I’ve used custom libraries to support complex string formatting and currency conversion, customisable column naming, and many other features.
But of course, if you can add JS or .NET code to SSRS, then really the only limit is your imagination. There are so many possibilities. PowerView doesn’t support any custom code in its current state, and it’s a huge limitation of the current component.
PowerView’s first iteration and a half (It’s a stretch to call the version in Excel 2013 2.0) have delivered a solid foundation and a great tool for power users, executives and prototyping. As a self-service component, it’s simple, quick, and graphically very impressive.
But beneath all the fanfare, there’s a worrying lack of depth. SSRS is a complex, flexible and scalable platform that offers something for every business, from the home-run self-employed effort, to multi-national, blue-chip corporations. Its innate flexibility allows heavy customisation straight out the box, and the infrastructure behind it supports business processes and software.
A lot of people are worried about Microsoft’s future plans for corporate-level BI, and a lot of their focus over the past year or so has been placed in the self-service side of things. As such, there’s not been much movement on new features for the corporate crowd. While it’s great to bring BI tools to the masses, it’s important that the business users aren’t forgotten in the long run, as there’s definitely a need for multi-tiered BI in any organisation. Here’s hoping that SQL Server 2014 and beyond bring some new developments to keep both sides, and those of us who see the value in both approaches, happy.