This write up contains a high level investigation of the Business Intelligence solution offering from Microsoft (SQL Server Reporting Services or SSRS) and the offering from SAP, the Business Objects base reporting package (BOBJ).  While BOBJ does have more options for reporting and presentation, from a basic report feature standpoint both of the tools offer similar functionality and offer the user a great deal of flexibility in the presentation of their data.  The other difference between the two solutions that needs to be considered is the expense associated with the Total Cost of Ownership.  While you will have similar costs in the requirements gathering, design, development, testing, and ongoing administration, there is a significant difference in the licensing cost of these products.  While BOBJ charges by either named user or CPU, SSRS comes with SQL Server so there are no additional costs with adding a BI tool set.

SQL Server and Sharepoint offer a quality BI solution, which meets basic architectural principles and business requirements.  Because of Microsoft’s desire to establish itself in the BI space, it offers the BI components with a license to SQL Server.  The lack of flashy, AJAX style reporting features (which are often shown in demos of BOBJ) may limit the business’s interest in SQL Server.  Additionally, BOBJ’s reporting, ad hoc queries, dashboard, data visualization capabilities are key strengths of the SAP BOBJ product suite and are among top rated BI tools.

When considering the total cost of ownership, a company must consider the individual components that make up this expense.  Total Cost of Ownership (TCO) comes from the High Level Business Requirements, Software Selection Process, Software Installation, Detailed Requirements, Design, Development, System and User Acceptance Testing, Production Software Licenses, the ongoing Maintenance of the solution.   While many of these costs would be similar across the two platforms, a company needs to assess the differences in development time, and ongoing maintenance and understand which tool their personnel and IT infrastructure can support.  Specific costs and return on investments are highly dependent on company’s specific situations and deployment choices.  From our specific client exposure, mid-market companies do not opt for BOBJ, and we find that SQL Server is more prevalent.  An SSRS solution will often be lower cost from a licensing perspective as all components are included with a SQL Server license.  However, SSRS requires a developer to build their reports, where BOBJ supports an end business user self-service model.  So long term technical support and development costs could actually be lower with BOBJ.

Because many companies already own SQL Server licenses within their infrastructure, the ease and low cost benefits of implementation may be too good to pass up.  However, companies either without SQL Server in house or requiring heavily visual reports accessible to business users or self-service access to information with minimal IT support may want to implement BOBJ as their BI stack.

As Business Intelligence consultants we always aim to help clients overcome the operational inefficiencies, find gaps in their current processes, enable cost curtailment and better decision making. My last business intelligence implementation was for a leading pharmaceutical company in the US. The biggest challenge pharmaceutical companies face today is to reduce the cycle time involved to bring a new drug into the market. Before a drug reaches the consumer it must go through the following phases:

Discovery > Clinical Trials > Approval > Manufacturing > Marketing

What is Report Bursting?

Bursting reports is the technique used to run a report once and divide the results for distribution to unique recipients.  

Advantages

There can be significant performance improvements by using report bursting.  For example, if you need to distribute a sales report 50 sales persons with the results separated by the salesman you have two options. You could run the report 50 times filtering the report differently (by salesperson) for each run or you could run the report once and burst the results to each salesperson. By running the report once and bursting the results, the database is only hit once instead of 50 times.

I’m a IBM Certified Cognos developer who is just learning Business Objects.  With many years of Cognos experience and just a few weeks with BO  I must be clearly biased towards Cognos and I probably am.  So with my bias why even write something comparing the two technologies?  Why not?  As a consultant I am always learning new technologies and being asked to compare and contrast them. Given the number of different tools offered by both vendors, I think the comparison is best done at the individual tool level.  It is also important to note that I have not used all the tools Business Objects has to offer.

Web Intelligence vs. Report Studio/Query Studio

Testing in large scale Business Intelligence (BI) projects face challenges in data quality assurance, metrics / aggregation rules verification, source to target mapping accuracy, the test cases to the requirements traceability, and anomalies in the dimensions to facts relationships. 

Oracle Business Intelligence Enterprise Edition (OBIEE) is a BI tool that addresses quite a few of these challenges by the nature of the product's growth strategy.  As Gartner puts it, "70 functional and industry-specific packaged BI applications built on the Oracle BI Enterprise Edition Platform attests to Oracle's understanding of how to leverage the market interest in domain-specific and prepackaged solutions as a growth driver for its platform."  Customers who buy OBIEE typically also buy a relevant packaged solution.

As IBM's Cognos business intelligence tools become more sophisticated and reports, cubes and frameworks more complex, I find it difficult to understand why there is no easy way to version Cognos code.  True, Framework manager does have the ability to connect to Source Safe or CVS, but have you ever tried to roll back to a previous version?   The way the various framework components are versioned and stored within the CM tool does not group all the components together as a single version making it difficult if not impossible to roll back.  I’ve even opened a case with IBM Cognos to make sure this is the case and they confirmed that this feature does not allow the ability back to previous versions.  Knowing that a framework is just XML makes it even harder for me to understand why this is so difficult.  IBM Cognos suggests that instead of rolling back using a source control system, you should roll back using the Synchronize Function.  I’ve found it difficult to get back to where I want using this function 

What about versioning and control of report studio reports?  A Report Studio report is nothing more than an XML file, so it should be simple to maintain a history of changes and allow the ability to roll back to a previous version if needed.  Interestingly enough, unlike framework manager, there is no option to connect to a CM tool from within Report Studio (or any of the other studios for that matter).  My clients are always shocked to find that this feature does not exist.  The best workaround I have found is to copy the report to the clipboard, paste the XML definition into notepad and load into the CM tool of choice from there.   In version 8.3 and later, this is made even easier with the ability to save a report to the local machine, avoiding the step of copying to the clipboard.  It is still far from an ideal solution, but at least reports can be safely versioned and stored in a CM tool. 

According to IBM Cognos, versioning is not available because of security concerns with a source control system connecting to the content store.  If this is such a concern, why not build a versioning capability right into the content store?  Given that everything is already in a relational database, it should be straightforward to add some versioning capabilities.  I’ve also found a product by Motio that claims to allow versioning in the studios, I have not tried it, but if it can be done by a 3^rd party, why not by IBM Cognos?  Perhaps IBM might even think about acquiring Motio?

There just are not many good options for Cognos Configuration Management out of the box.  With such a powerful and sophisticated tool I hope this changes soon.  Until then, we'll have to make do with workaournds and 3rd party solutions.