Well, this was supposed to only be a 2-part blog (Part 1 and Part 2 ) but there has been such an overwhelming interest and fantastic feedback on the first two parts, that I feel compelled to keep going since the topic is obviously of great interest to many.
One of the best responses to the blog I received was from a customer working at a large organization who is currently using both solutions who responded by email and then was kind enough to spend some time on a Teams call with me to expand further on his experience and assessment.
So, for this blog, I would like to share with you all, this truly customer-centric viewpoint.
The first point they made addressed the issue of replacing a BusinessObjects Universe with a PowerBI (PBI) model and here is the response unedited :
“It isn’t possible, no matter the amount of time, to replace a BusinessObjects universe with a PBI model because:
- BusinessObjects universes can have unlimited numbers of objects and tables. PowerBI doesn’t have the equivalent of a business layer that can organize objects in folders. Every table has its own folder in PowerBI, and they are just organized in alphabetical order making it impossible to build understandable models to report writers as the number of tables and objects increases.
- All tables in PBI have at least some data whether they are imported or direct query. In a BusinessObjects universe there is just metadata. For this reason, and others, a PBI model can get too large to work effectively on the desktop where all models are built.
- Every table in PowerBI has to be written in freehand SQL because there are no aggregate functions and because there is no way to limit which columns to use from the table in the model. This is extremely time consuming to build large models. In a BusinessObjects universe you can use a table browser to select tables and choose specific columns within that table to have objects created from.”
In the subsequent web meeting, I had with the customer, they listed out the following additional characteristics of the BusinessObjects architecture that clearly differentiates it from PowerBI. This list may not include everything but it is an excellent check list to use if you should ever consider replacing BusinessObjects with PowerBI :
- SQL queries are dynamically created within a Web Intelligence report
- Objects can be organized in a way that makes sense to business users by nesting folders
- Tables can be built quickly in the universe foundation layer using a table browser
- Complex joins can be easily created and edited in the universe
- Ad-hoc reporting requires the possibility of sometimes hundreds of tables and thousands of objects being at the disposal of the report writer. The BusinessObjects universe contains only metadata so no matter how many tables and columns, it will not grow more than a few hundred megabytes in size.
- BusinessObjects is designed to work at the database level using native SQL. This is possible because native SQL is used to define objects in the Universe Business Layer.
- Using the Query Builder editor, a user can easily build reports that contain very complex SQL such as sub-queries, set analysis, AND/OR conditions and user-entered prompts.
- Objects can be renamed or organized and that will cascade to reports using these objects.
- Synchronizing and Merging of Queries
I would like to express my gratitude to this customer who asked to remain anonymous for this excellent insight that adds further valuable information to the BusinessObjects Web Intelligence vs. PowerBI solution comparison.
I am looking at writing a Part 4 to this blog, at the suggestion of another customer, about how you can leverage BusinessObjects to enable and accelerate tools like PowerBI, so please standby.