This content has been marked as final. Show 9 replies
The short answer is that OBIEE has much more funcitonality then Discoverer and is more of a reporting system then just a reporting tool. Therefore, OBIEE requires more infrastructure, more complexity, more configuration and comes with a much greater licencing cost. Whether it is worth spending the extra time, money and resources to use OBIEE depends on your budget and how much you need the extra features.
First of all, you are absolutely correct in that Discoverer is not going away. 11g is due out this year and I know there is a 12g planned because I have seen references to it. In my opinion, and I know both tools, they are both excellent reporting tools. Should you decide to start out with Discoverer, which is a much cheaper option than OBI EE, any investment you make will not be lost because should you decide you want to go to OBI EE later you can convert your Discoverer metadata into OBI EE metadata. This utility is out and available now.
What is currently missing is the ability to convert Discoverer workbooks into BI Answers requests. I know that Oracle is working on this but we are not there yet and I suspect it will take some time to get this conversion assistant to fully work.
While you can interface Discoverer 10g with OBI EE 10.1.3.4 the mechanism today is not as straight forward as you might think. In fact the best you can do today is to interface Discoverer with BI Publisher or convert your Discoverer EUL into OBI EE metadata. You cannot interface Discoverer with BI Answers or Interactive Dashboards and you cannot migrate Discoverer workbooks.
Coming later this year are brand new versions of both Discoverer and OBI EE, both 11g. Because the OC4J components will still not be the same you will still need an OBI EE server and a Discoverer server. However, there will be smart interfaces between Discoverer and BI Publisher and Interactive Dashboards meaning you can retain your investment in Discoverer for your standard users but publish data using BI Publisher and create executive dashboards using Interactive Dashboards. This is because from 11g Discoverer will no longer be tied to Oracle Portal technology and its portlets will be a lot more open source allowing Discoverer content to be published to a far greater audience. It is still not clear when the worksheet migration utility will be released so you, like me, will have to keep an eye out.
Thus, I think using Discoverer as your launch point into BI makes very good sense, particularly if you a) already have some invsetment in Discoverer, or b) you don't have a lot of budget at this time. Discoverer is a very popular tool and it does provide a less complicated product for end user reporting when compared to OBI EE. In the future,especially following 11g, I see customers being likely to utilise both at the same time.
Right now you need to maximize your investment in Discoverer by harnessing its power to the full. Too many companies only scratch the surface of Discoverer and don't invest time or money into training or making a good EUL. Many also fail to install it correctly or stay up with current patches.
As an FYI, I am presenting a paper at ODTUG in June and at the Baton Rouge User Group in July called Maximize your investment in Discoverer. Following the June presentation I will make my paper available as a download on my website (http://ascbi.com)
Does this help
I suppose morning for you,Good Morning!!
You gave a good explanation comparing Discoverer and OBIEE,it was simple at the same time informative.
I got to know the importance of discoverer and overview of OBIEE.
As michael said above,many companies dont invest time or money training people or making good EUL user nor many
companies realise the importnace od discoverer or they are not aware of.
Well, you can get plenty of opinions on this. Discoverer is an easier imiplementation than OBIEE, and less expensive. Might be a good entry point. The problem that I see with Discoverer, and why Oracle is making the move to data warehouses, is that Discoverer is less than friendly for non-IT people. Discoverer is basically a front end tool to generate an SQL statement. So you are going to be limited by what you can do in SQL. And often to accomplish what you need to do in a Discoverer workbook/report, you need to do some complex SQL. For an IT person, not such a big deal. For a non-IT person, a big deal. The Discoverer user also has to have a good understanding of the Oracle data base structure, which again most non-IT people won't have. Now the supposed answer to that is to create custom folders in Discoverer that help hide this complexity from the users. But what that means is that if someone wants to develop a new Discoverer workbook/report, they have to work with IT to get the custom folder designed, developed, tested, and moved into production. Not a quick process usually. If you want to give your users the ability to generate reports/inquiries/analysis on the fly, by themselves, often as one time requests, then you are going to want to look at true data warehousing solutions, such as an OBIEE. You have to be careful with OBIEE. Yes, you can migrate Discoverer reports to OBIEE, but they basically still work the same way they do in Discoverer. OBIEE has many components to it, one of which is a true data warehouse. The downside to OBIEE is the time and cost to develop the data warehousing part of it. Discoverer might be a way to get users to start thinking about the things they want to be able to do, so that they can be more helpful/useful in the data warehouse design/development. A big challenge to data warehousing is being able to figure out the user requirements early on, even anticipating what the users don't yet know they will need. So you really have to look at what you want to accomplish, and any budget and time constraints that you have. Keep in mind there are vendors out there that offer data warehousing solutions. So if you think the data warehouse solution is the way that you want to go, you may want to evaluate other solutions besides just OBIEE. Food for thought.
Hi Rod, Michael, John and Kranthi,
Thanks very much for replying to my post and to Michael and John for all the detail and thoughts.
I should have put in my original post that I have used Disco a bit over the years and been involved with install/ config and design of EUL's etc. Apologies for not saying that however it is always great to hear others experiences with products like Disco. I really agree on the design of EUL's, well any sort of metadata layer really. It is not a 1 day task is it, although some EUL's you see may look like only 1 day was taken. I always think it needs to to be owned by a few key business users especially in terms of nailing requirements and having a strong technical/ functional person to assist both the technical and functional sides to ensure what results does do the job. It is quite a difficult thing to get right.
I attended an OBIEE 2 day Oracle course by Mark Rittman in 2007 to get an overview of the product as it was then, and since that time had not really looked at it a great deal, but have been more recently and had a few queries on it via email from others. However after going over the documents on the Oracle site was left a bit 'puzzled' over which (if it was a choice rather than using both OBIEE and Disco for example), was the one to focus on.
So your replies have been really helpful. John on the Data Warehouse side of OBIEE, I have not really touched on this bit in any detail, does this mean Oracle are promoting use of the Oracle Warehouse Builder tool? This has been around for a very long time so I wonder if it is being used at all?
Thanks again Cel
(One final thing, I hope Oracle will start to use the plain non-coloured documentation standard for OBIEE as the OBIEE doc is not as clear to read or to print off which I generally do when I install and configure s/w, at least parts of the documents.)