Skip to Content

I posted a tweet this morning about a decision I had to make this week that was not easy for me, and several requested some additional information to clarify.   Let it be known, that I, Greg Myers, SAP Mentor, ASUG Volunteer, and BusinessObjects Certified Professional, recommended we use the Microsoft Reporting and Analysis Services for an upcoming project. (insert collective gasp here).

Quick background on the project. I’m working on building an internal data repository for all of our server and application performance metrics. It’s going to be huge in a few months. Our goal is to use this data to be able to forecast capacity of our massive “platform”,  to model what types of business activities have what effects on our infrastructure, and to forecast what adding new clients (and what types of clients) will do to performance and capacity. It’s a tall order.

   We have performance monitoring tools that gather many of the statistics for us, but they are light on the reporting side, so we’ve been looking at other ways to get to where we need to go. My first idea was to use an Oracle database for our back end, and use BusinessObjects on the front side for reporting. When we began doing our breakdowns of what that would actually entail, it quickly became a sub prime option (I will do some comparisons in a moment). The next option we considered was a Microsoft SQL Server back end, with BOBJ on the front side for reporting. And the third option (probably final) was to use Microsoft thru and thru (SQL Server, Analysis and Reporting Services). And yes, I chose the final option.   Here’s why:

       1. An Oracle back-end requires lots of technical know-how to build, manage, tune, and maintain. We have several Oracle DBA’s, but none have the bandwidth to take on an extra project like this. I cannot support Oracle by myself.

     2. We need OLAP cubes to do some of the correlation and modeling we are proposing. Oracle can do them, but again require lots of brain power (that I don’t have).

     3. Since we need OLAP cubes, WebIntelligence isn’t really the proper tool to go browsing through those. SAP has the tools, but we aren’t currently licensed for them.

     4. Much of the metrics will be going into executive dashboards. We want to be able to integrate with our corporate SharePoint site since that is where our managers are used to going for information. We can’t currently integrate BOBJ with SharePoint because 64-bit SharePoint isn’t supported with the Integration Kits.

     5. None of the solutions I’ve discussed so far have any type of ETL tool that we are licensed for or have at hand to use. We have to move the data somehow.

     6. We have a large SQL Server farm which is licensed for Analysis and Reporting Services, and staff that has the ability to support a new warehouse of this size.

       7. The Microsoft BI stack integrates very cleanly with our current version of SharePoint.

     8. The Microsoft BI stack (and SQL Server) includes an ETL Tool (SSIS)

     9. The Microsoft solution will cost us roughly one fourth of what the Oracle/BOBJ solution would have cost.

         In the end, it was purely a business decision.  We needed something that fit into our current landscape that would be easy to support and maintain, and not break the bank to implement. I certainly have my personal preferences, and I know that the Oracle/BOBJ solution would have been way more sophisticated, but I’m not sure sophistication is needed in this case.  In the end, I am happy with my decision and recommendation, because I truly feel it’s the best solution for this problem.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Gregory Misiorek
    nothing wrong with extending the existing infrastructure, incremental ROI is infinite. Microsoft is still a dominant force in corporate IT even though Apple has a hold on consumer. sometimes, making work what you have is a better way to succeed than going for the best of breed which often carries a cost premium. Microsoft also seems a natural choice for the installed BO instances. Oracle can be daunting, too.
  2. Former Member
    Was this ETL tool considered at all? Gives uncomparable advantages with auto-documentation and other maintenance related benefits compared with SSIS.

    I’ve done couple of DW implementation with both.



    1. Former Member
      Teemu – even though SAPBO DS/DI would be a great tool, there is no comparison with MS-SSIS when it comes to cost and maintainability! Especially for “projects” like the one Greg wrote about, it is impossible to justify the heavy cost of buying a full DS product suite unless you already own licenses to it at an enterprise BI level.
  3. Former Member

    I read your blog with great joy.
    You gave the word that the current BOBJ releases don’t fit in a 64-bit Microsoft environment. I encountered the same problems with BEx and Excel 2010. In my special case I will also use Microsft SQL Services. In a 64-bit environment Microsoft gives the pace and hopefully SAP will close the gap very soon.    
    The sad thing is, your story tells that you will choose SAP tools in a enviromnent embossed by SAP, but in a “non-SAP” environment you still have to choose e.g. Microsoft tools for better compatibility, integration, lower costs and TCO or skill reasons.
    Maybe SAP rethinks its license model to make BW and BO data servcies more attractive for merely Microsoft environments?   

    1. Greg Myers Post author

      I was actually thinking that same thing while driving to work this morning. I think it would be a smart move if SAP were to put together an “All-in-one” solution like Microsoft that is reasonably priced for small to mid-sized businesses. They could easily have a package of BO/Data Services/Sybase that was a soup-to-nuts BI solution. Pre-packaged Analytics products are already available in several flavors, why not a plain vanilla one, too?

  4. Former Member
    Want to go fishing on a secluded mountain lake?

    Seriously though, nothing wrong with making the right choice for your business, or with enumerating why here. I personally love SQL Server when compared with Oracle, but in my personal opinion the reporting services interfaces are significantly more challenging to work with than any BOBJ tool (although its been a while since I looked).

    It’s also interesting that you aren’t the first person I’ve heard make the same decision with very similar reasons lately. Perhaps SAP should take a look at this.

    One thing, isn’t the Edge platform supposed to be the one stop shop for SME BI customers? What are they missing?

  5. Derek Loranca
    While I am a ‘BOBJ nerd’ too, I agree with you 100%.  Pick the right tool for the right job!  This applies to picking the right BOBJ tool for the task at hand, as well as the completely right tool set to complete your task- BOBJ or not. 

    I think that selections like these are better than trying to force a square peg in a round hole…

  6. Former Member
    Hi Greg,

    It seems to be that the major reason you choose SQL Server Analysis is that it’s easy to build the OLAP cubes, while it costs much effort for Oracle.

    But I think when building the presentation layer you might keep thinking of the benefits of BOBJ.

    If it was I I would hire another Oracle consultant to build the OLAP or EDW layer.


  7. Ty Miller
    Greg, thank you for your blog.  Your arguments are sound and the points well articulated.

    Along with the subsequent posts, I would like to provide my perspective on each of the points and share some information about what we at SAP BusinessObjects are doing to improve our BI and IM solutions for all technology landscapes from relational to multi-dimensional data sources, from Windows to Linux and UNIX operating systems, from .NET to Java, Active Directory to LDAP, SharePoint to Java Portal Servers and for SME to large enterprise customers.

    Indeed, as I think you would agree, one of the strengths of SAP BusinessObjects is that it supports a plethora of technology platforms, many of them often deployed within a single customer’s environment.

    As a preface to my replies, it’s important to note that the majority of your issues are valid in the current 3.x environment.  However, we have heard our customers’ collective feedback while working on our 4.0 business intelligence suite which is currently available in restricted shipment and that we expect to become Generally Available in the next few months.  To be specific, with this release we will be addressing both the 64-bit SharePoint issue as well as the native OLAP client requirement.

    1.     There are so many criteria that go into choosing a database that I’m not going to try to expound upon them here.  Each database, Oracle, SQL Server, DB2, Sybase, etc. has its pros and cons which are different from customer to customer and project to project as noted above.  What we do strive to do, however, is be an equal opportunity database consumer.
    2.     Fully agree that some OLAP structures allow you to perform multi-dimensional analysis that is simply not possible with many relational data structures.
    3.     Understood.  You want a pure OLAP BI client.  The new SAP BusinessObjects Analysis, edition for OLAP tool is our web based native OLAP client on the new SAP BusinessObjects BI 4.0 platform.  It connects directly to MSAS.  As you note, however, it sounds like you may not be licensed for that.  If in the future you find that the stakeholders within your company want to connect to both MSAS and Essbase OLAP cubes, know that our new dimensional semantic layer provides multi-dimensional access for Web Intelligence, Crystal Reports for Enterprise and Dashboards with no data flattening.  Even though you’ve decided to move forward with MSFT’s Analysis and Reporting Services, since you already have Web Intelligence I would encourage you to give it a spin once you get your hands on the updated BI 4.0 suite just to see what it’s like.
    4.     Hear you loud and clear.  This has been a well known gap in our MSFT integration story and we are working feverishly on our new IOMS (Integration Option for MSFT SharePoint) package for our BI 4.0 suite to address this.  I hope, and think, that our MSFT centric customers will be pleased with what our engineers have done.  Our plan is to release this Spring with native support of both 2007 and 2010 64-bit SharePoint to go along with our new 64-bit BI platform.  Expect to find new features like significant improvements to search and management capabilities by leveraging the new BI platform’s search engine, auditing, a tight, native integration into the SharePoint user experience.  We have done so much work integrating with SharePoint, in fact, that we intend to completely replace our own .NET portal which in 3.x was called InfoView with this IOMS integration.
    5.     Depending on the size of your project, or for future projects, I would encourage you to consider our mid-size BI/ETL solution called Edge.  SAP BusinessObjects Edge is our BI and ETL solutions combined into one package.  Licensing limits usage to a certain number of users and I believe number of CPUs that can power it, which is appropriate for projects similar in size to your own.  It is essentially the exact same BI and ETL platforms leveraged for the more data and user intense large enterprise projects.
    6.     This is a reasonable choice if you know that this project will be for SQL Server only.  I won’t go into all the details of why I think SAP BusinessObjects is still better here as your familiarity with SAP BusinessObjects tools is evident in your opening statements.
    7.     Agreed.  I think that our IOMS integration will as well.  I hope that you give it a test run!
    8.     As noted above, the SAP BusinessObjects Edge stack provides a full fledged copy of SAP BusinessObjects Data Services which is second to none, including Informatica and Ascential, in its ETL capabilities.
    9.     I agree that the Oracle/BOBJ solution could be expensive, but on a per user basis, given the right requirements in terms of number of users, amount of data, failover, etc. the value could very much be superior.  I’m not suggesting that your project meets those criteria, and you may not have had the option to take advantage of our new BI 4.0 suite as a ramp up customer, but I do hope that you are able to test all the new capabilities neatly provided in what we consider our largest, most important, and most strategic BI and IM release ever:  SAP BusinessObjects Business Intelligence 4.0 and SAP BusinessObjects Data Services 4.0.  And later this Spring, for smaller project based deployments, SAP BusinessObjects Edge 4.0.

    Really appreciate the candid feedback on this forum guys.  Keep it coming.  It pushes us to make our solutions better.

  8. Former Member
    I just wanted to add that SQL Server is fairly quick and robust and until in memory computing becomes more common, will outweigh the advantages of HANA, the new poor performance killer!
    1. Greg Myers Post author
      I agree with you on the performance front, Augusto. But if you did a price comparison between HANA and SQL Server, the difference is staggering. I’m sure the price of HANA will come down in time, but for now, there really isn’t a solution comparable with the MS BI stack for the price.

Leave a Reply