The discussion with QlikView fanatics (look at my previous post) eventually did cost me a lot of time. But I felt it necessary.
------------------------------------------
The discussion on LinkedIn eventually resulted in my simple question:
.....But your remark about DWH and next generation BI tools is
interesting. Are you saying that Qlikview replaces all DWH and ETL
functionality? ....
------------------------------------------
His answer:
Dear Ronald,
I love to discuss at my blog only as it is readable by everyone who visit my page.
If you look at QlikView architecture its not required to create a data
warehouse as any how it is pulling data and storing it in QVW files
which have GUI also and it is single layer architecture. So if we pull
data either from raw table (Transaction System/Data base) or from Data
warehouse it makes no difference as you are pulling required
field/dimension and it is being stored in QVW file as its native way. I
saw different software companies who propose QlikView as a front end
tool that will be pulling data from Data warehouse. It is just to
stretch the project so they can make more money on services as QlikView
take very less time to implement hence it is not giving much profits to
vendors as compared to traditional BI Software to earn from QlikView is
only way do rapid sales. Show ROI to customer in short time, Get repeat
order implement fast and make it customers success and set example for
next prospect.
If you look at ETL functionality QlikView’s edit script is sufficient enough in my view.
Sorry to say but it is not an advertisement I am not employee of
QlikTech. I am a sales guy who sales QlikView also apart from Navision
and Actionbase kind of tool.
Regards
Sudhir Kumar Singh
------------------------------------------
My answer:
I like qlikview a lot. As I said, it's extemely powerfull in
several areas of Business Intelligence. I also acknowledge the fact
that it's deployment time is fast and customer statisfaction is high.
But claiming that you don't need any form of propagation of data when
you have QV is a bit short-sighted.
Somehow you have come to believe that data warehousing is there to
serve soly business Intelligence as defined by Qlikview. That's scary.
Wake up and smell the roses and welcome to the 21st century- a single
system of fact can/should and will offer so much more for any company.
In my opinion data should be stored as (vendor) neutral and open as
possible in order to serve as many functionalities as possible. It's
called - begin agile for requirements you may not know in advance and
creating a sustainable architecture for your data. If might even be a
possiblity that an organisation does not want to lock her data into one
single tool........aint that realistic?
Has is ever occured to you that there might be several
uses/functionalities for the same data? Use/functionality that is not
offered by QV (you will probably respond now that QV can do it
all.....). Storing the data in a proprietary format aint gonna help
this a lot....Or is the storage solution offered by QV open for other
vendor's?
Something I also worry about is the effect Excel had on data proliferation. QV could lead to same issues as Excel. Data lying around everywhere...
And I am not talking about my doubts concerning the storage of (semantic) compliant data across all possible outputs......
And I am not talking about the extreme privacy regulations in
government that screams for datamanagement and sophisticated security
architecture accompanying your data as well as your BI.
And I am not talking about metadata management control. A pillar
where any sound data management architecture must be build upon.
And I am not talking about large enterprise deployment of data and
business Intelligence. The word 'scale' jumps to mind; extreme amounts
of data, users, usage and business process complexity. You do not 'buy'
a tool to accomodate this....you architect an environment.
I am also not talking about the fact that many (especially) large size companies NEVER allow direct access to transational systems. And right they are! So you gotta build some kind of datastore and refresh it periodically. With increasing amounts of data this is by sure an architectural challenge.
Another thingie that keeps bothering me; especially in large firms standaardisation is a goal in itself, this is mainly because of maintainability reasons. Tools need to have a level of integration with existing hardware, existing scheduling software, existing version control software, existing configuration management software, existing identity management sofware and so on.....How does QV compare to others on these integrational aspects? Somehow I got some doubts....
And one thing that I just need to say; claiming that you can
compare yourself with SAS concerning statistical analysis and data
mining. Well, that only shows your level of 'thorough' investigation
into non-QV tooling....
And I am not talking about maintainability and governance in these large organisations.
Again,QV has earned it's rightfull place in the BI front-end
tooling arena. But to claim that DWH and ETL is just a 'trick' of
vendors to make money,that's not very nice.
In the end,QV is just another tool..
Couldn't agree more with Ronald. QV is a decent tool for what it does however, is way way off before it can be considered to replace the need for a EDW.
Posted by: Aditya Sikaria | Wednesday, October 21, 2009 at 12:46 PM
Ronald,
I completely agree with your thoughts on QlikView. The "No Data Warehouse" rhetoric is an annoying marketing gimmick, though one that admittedly resonates very well with the business and SMB companies. On the enterprise side though, I believe that exactly this message might seriously hinder broad adoption of QlikView. It's rubbing many enterprise architects the wrong way, and some may no longer wish to review QlikView objectively.
In my opinion, the correct place for QlikView is in the presentation layer. The only exceptions to this being, as Gilles also points out, the use of QlikView as a prototyping tool or as a tool for companies that are very low on the BI maturity ladder.
One point I disagree about is the issue of data proliferation. Just like other solutions, QlikView Server offers a central repository for documents and it's perfectly possible to only allow access to the documents through a central portal. Besides that, IMHO the issue of data proliferation is not about the tool, but about governance.
Kind regards,
Barry
http://www.qlikfix.com
Posted by: Barry | Wednesday, November 24, 2010 at 05:39 AM