QlikView versus BI Applications and OBIEE
Having worked with Oracle Business Intelligence (BI) products for several years, some colleagues and I recently spent some time evaluating a third party offering called “QlikView”. Whilst our main interest at Prōject has always been Oracle’s BI Applications for E-Business Suite, the buzz being generated around QlikView intrigued us. The Oracle BI Applications provide pre-packaged analytics reporting built on OBIEE, so we were keen to see if QlikView was a suitable competitor to BI Applications for our E-Business Suite customers.
QlikTech’s website certainly makes QlikView look compelling; they even offer a free download of the “personal” edition, which I recommend taking them up on. However, some of the videos on their website omit details of the technical expertise required to administer the product on a corporate scale. We also had reservations about the scalability of the product with large data sets (which are not unusual, even for mid-size E-Business Suite customers).
For any organisations considering a BI solution for the E-Business Suite, here is some food for thought if considering QlikView over the Oracle BI Applications. This is not a detailed technical comparison of the products; our expertise lies with OBIEE. The below simply gives a summary of areas in which we believe OBIEE (and the BI Applications) offer a significant advantage over QlikView.
- Integration with the E-Business Suite and Security
The BI Applications offer seamless integration out-of-the-box with the E-Business Suite. The 11g release of OBIEE contains an “Action Framework”, which enables users to drill down in dashboards and navigate back to transactions within the E-Business Suite. In addition, the Action Framework can now also be used to conditionally trigger actions within the E-Business Suite (e.g. kick off Workflows); true insight to action.
The BI Applications can also provide object and data level security based on E-Business Suite credentials; user name, employee, Operating Unit, responsibility, application.
- Features
One of QlikView’s strengths is its visually rich appearance. However, the release of OBIEE 11g greatly improved Oracle’s offering. Among other features, the 11g release includes full integration with BI Publisher (for pixel perfect reports), KPIs, scorecards, iOS applications (for iPad/iPhone), geospatial mapping as well as new chart types and rich animations.
Oracle’s recent Endeca purchase will presumably also add unstructured data searches into the fold in future releases.
We definitely recommend that a complete evaluation of features is performed, and a decision is made based on requirements.
- Fusion Applications Roadmap
Elements of OBIEE technology are embedded in Oracle’s next generation Fusion Applications. At a recent partner event in London, Oracle quoted that the following non-exhaustive list of skills are required for Fusion Applications:-
- Webcentre Suite, ADF, JDeveloper
- SOA, BPM Suite
- OBIEE, OBIA, OTBI, BIP
- Identity Management
- ODI
Oracle made the message clear; organisations should be looking to build up OBIEE skills in readiness for Fusion Applications.
- Hardware / Architecture / Scalability
As stated above, QlikView personal edition is free and I recommend that you try it. The personal edition is great as a “desktop BI tool”, but on its own does not extol the virtues of a “single version of the truth”. With employees across an organisation creating and sharing their own BI content from various data sources, widespread usage of the personal edition could very quickly replicate Excel-style reporting silos.
The server edition of QlikView is intended for the enterprise customer. However, the architecture is significantly different to OBIEE and the BI Applications. The main difference is that there is no requirement for a data warehouse; reports are written against source databases and the results are compressed into the server’s file system and loaded into memory. Without a data warehouse, we struggle to believe that QlikView will be able to compete with OBIEE in terms of performance on medium to large data volumes; certainly not without a very large investment in hardware. With the release of Oracle’s engineered BI machine, Exalytics, it would be interesting to see if the same performance can be achieved by QlikView for the same price.
After doing some research on the QlikView website†, I found a PDF document covering scalability of their enterprise product. The main takeaways were:-
- 200 concurrent users
- 70GB of data
- Hardware for the QlikView servers:-
- 4 clustered machines
- 3 of the machines had 64 CPU cores and 256GB RAM each (totalling a staggering 192 CPU cores and 768GB RAM!)
- 1 of the machines had 32 CPU cores and 128GB RAM
† http://www.qlikview.com/us/explore/resources/whitepapers/qlikview-scalability-overview
70 GB is really not a huge amount of data, certainly within the context of the E-Business Suite. Compare the above specs with Oracle’s high-end engineered BI machine Exalytics, which only contains 1TB RAM and a modest 40 CPU cores; this supports many thousands of concurrent users. Granted, you would need a machine for the datawarehouse too, but I doubt that you would need the difference in processing for this (184 cores). Again putting this into context, Oracle’s high-end Exadata X2-2 database machine has a maximum of 264 CPU cores, which would be reserved for only the largest of organisations. The key point really is to do your homework on the projected hardware costs as the number of users increases.
If an organisation did decide to deploy QlikView on top of a data warehouse, then they must also factor in the cost of licensing an ETL* tool (such as Informatica or ODI), as well as designing and building the warehouse and ETL from scratch. With OBIEE and the BI Applications, the ETL and warehouse come pre-packaged, as do the Informatica licenses.
Another key difference is the lack of a metadata layer in QlikView’s architecture. The OBIEE repository (or RPD) maps the physical data sources (data warehouse, source OLTP databases etc) through a conformed business model (logical model) to a presentation layer seen by the end user. The benefit of this structure is that the metadata can be amended without the need to reload data or change reports and dashboards.
* Extract, Transform, Load; the processes by which data is loaded into a data warehouse
- Pre-packaged BI Applications
The age old question of “build versus buy”! The Oracle BI Applications are built based on best practices and cover all of the core E-Business Suite modules (GL, AP, AR, PO, PA, INV). Whilst a host of dashboards also come bundled with the BI Applications, the real value lies in the pre-built ETL, data warehouse and RPD. In effect, the BI Applications can be installed, the ETL run and the business can be up and running with BI dashboards in a matter of weeks.
From our experience, the BI Applications are a great starting point for most E-Business Suite customers wishing to begin a BI journey. The BI Applications greatly reduce deployment timescales; and even if they have to be extended to meet customers’ needs, this is always quicker and cheaper than starting from scratch.
In contrast, QlikView has no pre-packaged content for the E-Business Suite, so one must be careful to factor this in to any budget or comparison. Starting with blank piece of paper can be deceptive, and costs can quickly escalate. We must remember that years of effort have gone into the BI Applications; this is not something that can be replicated in a short timeframe for minimal budget.
- Price
It is a common misconception that OBIEE and BI Applications are prohibitively expensive (even for mid-size organisations). Oracle’s recommendation is that any organisation running E-Business Suite should have OBIEE and BI Applications. Oracle BI Applications license costs have come down greatly in the last year, and coupled with fixed price implementations, are now extremely competitive. With potentially high hardware costs for QlikView at the enterprise level, combined with hidden costs of building content, it is certainly best to weigh everything up before making a decision.
Summary
From what we have seen, it is very much “horses for courses”. QlikView is a neat product, certainly at the desktop level, but we see limitations for medium to large scale roll-outs. Beware of slick marketing and do your homework; we certainly have doubts about scalability of QlikView and integration with the E-Business Suite. Oracle’s roadmap is clear; any customer with E-Business Suite should seriously consider OBIEE and BI Applications.
We would certainly like to hear about people’s experiences of medium to large scale implementations of QlikView against the E-Business Suite.
Coming from such deep experience in OBIEE, I can certainly understand your inclination towards pre-packaged applications.
From a pure end-user perspective, OBI is still tightly coupled with IT. Qlikview or Tableau, on the other hand, have a very loose coupling with IT in creation of their meta-data and creation and maintenance of reports.
Both Qlikview and Tableau talk about meta-data development but from rather report standpoint without taking into consideration maintaining one standard and consistent definition across the enterprise.
Our experience has been centered around creating standard metadata dictionary in OBI and generate dashboards and reports that are completely standardized across the whole exterprise. For data analysts and data diggers perspective, we have exposed/recreated the same metadata in Qlikview/Tableau and allows them to build one-off reports and dashboards. The additional flexibility you get from Qlikview and Tableau can never be accomplished so easily in OBI without IT involvement.
Hope this adds a perspective to the other face of the same coin
Hi Kris, thanks for your great response.
I completely agree with your comments; the guts of any BI tool should lie with a datawarehouse and single, entity-driven enterprise model. Whilst Tableau and QlikView may offer desktop benefits (as you say, users “digging” away on an ad-hoc basis), the source of the data should still be the single enterprise model. I have previously come across customers using different presentation tools, based on an OBIEE platform (that was before OBIEE 11g though).
When you mention that OBIEE is tighly coupled with IT, I presume that you are referring to the maintenence of the meta-data layer (the RPD)? I happen to agree with this approach, as any changes to the RPD may impact the whole organisation and should not be taken lightly. I guess the logic behind it is that if the enterprise model is correct, and controlled, then users will have all of the building blocks that they need in the presentation layer to build dashboards.
I guess my main point with the article is that on it’s own QlikView may not meet the BI requirements of an organisation, but like yourself, I do see potential benefits of having it included in the solution. I guess it also depends on the customer’s requirements, and whether they can support two BI platforms. As you confirm, the other key benefit of OBIEE is the BI Applications which greatly reduce deployment time.
Kind regards,
Andy.
Good observation on tools like Qlikview and Tableau being a complementary rather than replacement tool for packages like OBIEE. Big stack BI programs definitely have their place with the nicely designed data warehouse, but there is definitely a need for analysis of data sources that are outside IT control. Best practices or not, the need is there.
We are a holding company which has 3 subsidiaries using EBS R12. 2 manufacturing companies, 1 distribution company. We are end-users, not affiliated with Qlikview in any ways.
We choose Qlikview to be our enterprise BI for these reasons:
1. It scaled out really well in our distribution company. Around 350 million invoices have been pumped into Qlikview servers with 100 users digging the Qlikview data on their own. We are now planning to cluster our Qlikview data hence we have a Qlikview farms to handle the load. This is still in-progress.
2. We forced Qlikview to be our datawarehouse. All ETL manipulation is done in the background by Qlikview. And we have another Qlikview to read the “cleaned” data to be presented to users to dig-through. Nobody believes that this technique can be done, but we proved that it can be done nicely and worked great.
3. We don’t like Oracle solutions because:
- IT involvement is high
- Hardware requirement is extremely high
- CAPEX is high
4. The so-called “Pre-Built ETL” for Oracle EBS is really not a great product on its own. It is expensive (yes.. it has its own SKU!
yet we can’t use it immediately. Still need some more work to be done, adding DFF, etc. If any Oracle Sales Rep comes to you and brag about Pre-Built ETL, that’s really a marketing gimmick. Go on and ask them to do a Proof-Of-Concept to prove that their Pre-Built ETL can easily be installed and you will be surprised when you hear the answer 
5. Deployment time = 2 months. Nothing more to say.
OBIEE came and told us that 4-months is very optimistic. Yeah right!
6. $$$ is low. For those of us who don’t use USD to buy our lunches and dinners, this is extremely important. Every single penny counts.
regards,
Horasi
Hi Horasi,
Thanks for your comments, it is great to hear about real customer experiences.
I would be especially interested to hear what the combined hardware specs are of your current QlikView infrasturcture, and also your planned clustering. Are you saying that you have circa 350 million records in the ap_invoices_all table in EBS? I would certainly expect OBIEE to be able to deal with these volumnes, but it all comes down to suitably sized hardware.
As I mentioned in my blog, there is no right or wrong way to do things, I really want to promote discusson such as this one so that others can make informed decisions. Our background is Oracle, so we really appreciate further insight into QlikView in the real world (for example, the above hardware stats are from the QlikView website; it would be interesting to see if your setup differs wildly). Obviously it would be great to benchmark the two systems side by side with the same data!
You are quite right in your summation that DFFs have to be modelled into the BI Applications. However, this is a simple task which should be carried out during implementation. All required DFF segments can be modelled during implementation, and no further effort is then required. I guess the main point is that starting with the BI Applications (even without DFFs) is far better than starting from scratch, as the alternative is that someone will have to put the effort in to design the DWH and build the ETL (whether you are using QlikView or OBIEE). I would like to add that I think that refering to the prebuilt ETL of BI Applications as a “marketing gimmick” is unfair. To replicate the pre-built ETL would take months and months of effort, and for most EBS customers it is an ideal starting point and saves a lot of time and effort. That’s not to say that it will work for everyone, which again emphaisises the importance of a proof of concept.
In terms of proof of concepts (PoC), we work with Oracle and turn around PoC’s for BI Applications in a matter of days. The important thing to understand is the value of a PoC and what to expect from it. If a customer is expecting all of their DFFs, a fully modelled DWH completely tailored to their unique EBS configuration along with all of the out of the box dashboards being useful and meaningful, then in my opinion that is unrealistic. One could argue that this expectation exceeds the typical scope of a PoC, which are usually free (you would effectively be performing an advanced CRP). This highlights the fact that it is important that the customer fully understands what they are getting at every stage of the sales cycle, including the PoC.
Like any off the shelf product, the timescale for a PoC can vary depending on the complexity of EBS configuration (e.g. if a customer has 20 segments in the CoA, multiple hierarchies per segment etc then it might take longer). It is also important to consider whether there are BI Applications to cover the whole EBS footprint, not to mention the degree of customisation in EBS.
Your reasons for not liking Oracle solutions are interesting, and again will vary from customer to customer. Has this experience been brought about by Oracle EBS, or are you satisifed with this product? I would say that once OBIEE/BI Applications have been bedded down, that IT involvement is typically pretty low. I would expect the same to be true for QlikView i.e. once it has been implemented that IT’s involvement will diminish and it is over to super users to create content based on the available Warehouse data. If there is a constant drain on IT for QlikView or OBIEE (and the configuration of source systems is pretty static) then I would question why. With regards to hardware requirements being high, I would again like to know what your hardware stack is for QlikView. As above, QlikTech’s own documentation appears to quote higher requirements than OBIEE.
Finally, I would really appreciate some insight as to how QlikView integrates with EBS, both in terms of logging in (SSO), securing data (e.g. using EBS responsibilities) and being able to drill down from dashboards back into EBS forms and/or instigate EBS actions (such as putting a credit hold in place or starting a Workflow) from within the dashboard. These are big selling point for OBIEE and I would like to know what QlikView has to offer.
Kind regards,
Andy.
Hello Andy
we are starting a new obiee implementation and dff is one challange we r facing, d u have some developer guide on how to embed them in the obia layers all the way till its available in subject areas?
regards
hager
I have been dabbling in the BI space for a while now and have had the lucky privilege of working across many organization and looked at many different BI tools from a variety of different vendors.
What always amazes me, it that decisions are made, preferences are built, pre-conceived notions are always in place. Experiences (good and bad), cost, time, ROI and over effectiveness is usually not down to the tool you choose, but more usually down to skills and experience of the people doing the implementation.
From a “lets cut corners to get it in cheap and fast” to “let’s take our time and really do a good job on this to make sure its future proof” and everything in between…
There are very good boutique SI’s that specialize in OBI as there are in Qlik. They all know best practice on how to make the most of these tools.
When looking at feature function, scalability etc comparison between the tools, how many people do the same for the SI’s and people implementing? This is where the real clever decisions are made.
Based on my own personal experience, An oracle Ebiz organization will always be best using OBI with the prebuilt apps (if you want an oracle comparison to Qlik, look at Endecca) , The point here is that you will only every get a full realization if its implemented by someone who knows what they are doing.
If you are in a position where you “think or are told” you can build all of the connectivity and ETL for a another third party BI tool, and build all of the security etc that comes out of the box with oracle, faster, quicker and cheaper than using the prebuilt oracle content, – walk away and speak someone who knows what they are talking about!
Hi Ian, many thanks for the comments. I agree with your sentiments wholeheartedly. A system is only as good as those who implement it. At Project we pride ourselves on making sure that all of our BI consultants are accredited by Oracle.
Kind regards,
Andy.
Hi all. I stumbled over this interesting blog. Comments made are very useful to me in positioning QlikView in the Enterprise environment. So first of all I want to thank you for that and Andy for setting up this blog. And like Andy correctly said; ‘there is no right or wrong answer’. But a few things are a fact. Supply chains are getting shorter and shorter, product life cycles are getting much shorter too. This calls for an agile and flexible BI solution where the business is in charge of ‘the next question’. Not IT.
That doesn’t mean we don’t need a scalable, secure and integer environment. Yes we do! And that’s exactly where IT comes in and where we have heavily invested in in the last couple of years.
I’m however convinced there’s room for a BI portfolio in almost every enterprise. I haven’t seen many enterprises that manage one or even just two BI solutions. OBIEE and BI Apps serve a purpose and so does QlikView on the broad spectrum of BI needs. But don’t make the mistake of following a ‘one shoe fits all’ strategy.
Referring to Andy’s questions around what QlikView has to offer in integrating with EBS I can set up a call anytime to discuss. Let me know what you prefer.
Kind regards,
Hans
We recently completed a BI search for a customer. The search was totally above board, even though we are an oracle partner. We initially included Qlikview in the comparison and had to drop it because it simply was deficient in to many areas. That doesn’t mean that it will be deficient forever. By the by the customer did not go with OBIEE and we still got the consulting contract due to our objectivity