This post is a moderately edited form of an actual interview. Two other posts cover analytic trends to watch (planned) and analytic vendor execution challenges to watch (already up).

Question: What do you think will happen next year with the Tableaus of the world?

Answer:

• I think adoption of flexible-visualization business intelligence tools will continue to be rapid.
• I think enterprise-friendly features will be increasingly important as a basis of competition.

Question: What do you mean by “enterprise-friendly”?

Answer: An example would be QlikTech no longer forcing you to use their native ETL, but rather working with Informatica and soon other third-party products. Also important can be:

• Database size.
• Concurrency.
• A full-featured development cycle for analytic applications.

Question: What does HP have to do to be relevant in analytics/data warehousing?

Answer: Avoid stupidity. HP Vertica is already relevant.

Question: OK. But what can HP do to build on Vertica?

Answer: HP — which botched Exadata 1 hardware — could do a good job with SAP HANA or other kinds of appliance products.

However:

• I don’t think trying to force Vertica beyond its natural growth — the way EMC is with Greenplum — is necessarily a good idea. Natural growth in Vertica’s case is plenty fast anyway.
• Obviously, making good Vertica hardware would be nice. But being hardware-independent is crucial to Vertica, not least because of cloud deployment, an option many buyers want to at least have in their hip pockets.

Question: You expressed some skepticism toward mobile BI/use cases. Why so?

Answer: The form factor hurts functionality a lot, so it’s only worthwhile in cases where timeliness is key.

And without more refined alert-setting functionality, it’s hard to think of that many cases.

Note: My views on mobile BI haven’t changed much since July, 2010.

Question: What about the idea of an enterprise being able to pay-per-drink to run jobs on an analytic cluster. Do you expect that concept to have any legs in 2012?

Answer: While other kinds of SaaS (Software as a Service) BI might make sense, remote computing BI that focuses on hardware cost sharing is problematic. Moving data in and out of the cluster is a big part of the overall cost, at least if you plan to process it only occasionally once it gets there. I haven’t seen a plan yet that gets around that point.

• As one might expect, QlikView 11 contains fairly leading-edge stuff, but also some “better late than never” features.
• The leading-edge stuff is concentrated in the general area of “collaboration”.
• Additionally, QlikTech is always pushing the QlikView user interface ahead in various ways.
• The “Well, it’s about time!” feature list starts with the ability to load QlikView via third-party ETL tools (Informatica now, others coming).
• QlikTech is generally good at putting up pretty pictures of its product. You can find some in the “What’s New in QlikView 11″ document via a general QlikView resource page.*
• Stephen Swoyer wrote a good article summarizing QlikView 11.

*One confusing aspect to that paper:  non-standard uses of the terms “analytic app” and “document”.

As QlikTech tells it, QlikView 11 adds two kinds of collaboration features:

• Integration with social media, which QlikTech calls “asynchronous integration.”
• Direct sharing of the QlikView UI, which QlikTech calls “synchronous integration.”

I’d add a third kind, because QlikView 11 also takes some baby steps toward what I regard as a key aspect of BI collaboration — the ability to define and track your own metrics. It’s way, way short of what I called for in metric flexibility in a post last year, but at least it’s a small start.

That direct sharing of user interfaces is a cool feature, which every business intelligence vendor should offer. In an era of distributed workforces, when people can’t be assumed able to huddle around the same desk, it has value even for use among close coworkers. But it also should prove useful in a variety of more naturally remote use cases, multiple examples of which can be found in each of the areas of:

• Support (internal or external).
• Faceoffs — I mean collaborations — between two or more enterprise departments. Examples might include: manufacturing and purchasing, manufacturing and sales, or accounting and anybody else.

As for social media being used for BI collaboration — that’s generally in the air. For example:

• salesforce.com is pushing enterprise social media use broadly, and will surely increase its emphasis on the social media/BI intersection now that Dave Kellogg is there.
• Spotfire has announced similar features in its latest release.
• The more cumbersome side of the feature set (portal-based collaboration, emailing of individual reports) has been available from multiple vendors for years.
• eBay open-sourced a more dataset-centric version of the idea, just as Oliver Ratzesberger left the firm.*

*Umm — does anybody have a link to the project, or at least a name for it?

BI has been a communication tool since the first green paper report was dumped on the first desk. And there’s been collaboration in doing analysis at least since it’s been possible to email .XLS file attachments. Still, BI is too often used as bludgeon rather than binocular. Hopefully, the current generation of technology will finally serve to change that.

Let’s try eight categories instead. While no categorization is ever perfect, these each have at least some degree of technical homogeneity. Figuring out which types of analytic database you have or need — and in most cases you’ll need several — is a great early step in your analytic technology planning. 

Enterprise data warehouse (Full or partial)

• Kinds of data likely to be included: All, but especially operational
• Likely use styles: All
• Canonical example: Central EDW for a big enterprise
• Stresses: Concurrency, reliability, workload management

The enterprise data warehouse (EDW) ideal says that you copy all your data into one place, and drive all decision-making from there. Full EDWs are pipedreams. Still, a partial EDW makes sense for most large enterprises, and many indeed already have one. The first product lines to consider for classical EDWs are Teradata, DB2, Exadata, and maybe Microsoft SQL Server, especially if you’re going to stress concurrency and/or operational use cases.

Traditional data mart

• Kinds of data likely to be included: All
• Likely use styles: Business intelligence, budgeting/consolidation, investigative
• Examples: Reporting servers, planning/consolidation servers, anything MOLAP, etc.
• Stresses: Performance, concurrency, TCO

Whether or not you have something like an enterprise data warehouse, it’s common to have lighter-weight data marts as well. A traditional data mart might drive reports and dashboards. Or it might be specialized for budgeting, planning, and/or consolidation.  Some investigative analytics may be in the mix as well.

Any DBMS that can support an EDW can also support a data mart, but it may not be the most cost-effective way to do so. Columnar DBMS might have more attractive performance and TCO (Total Cost of Ownership); the same goes for Netezza. Some of them — e.g. Sybase IQ and Vertica — have excellent track records in concurrent usage as well. Ted Codd pushed what amounts to MOLAP (Multidimensional OnLine Analytic Processing) systems for these use cases. But relational DBMS commonly do a better job, which is one reason most major MOLAP products have wound up at RDBMS companies.

Investigative data mart — agile

• Kinds of data likely to be included: All, especially customer-centric
• Likely use styles: Investigative
• Canonical example: A few analysts getting a few TB to examine
• Stresses: Ease of setup/load, ease of admin, price/performance

Besides the traditional data mart, there are at least two other kinds. Both are focused on investigative analytics, but they’re differentiated by database size.

If you have just a few analysts,* looking at no more than a few terabytes of data (perhaps even just some gigabytes) — and if that data is “single-subject” and fairly homogenous — your watchwords should be “cheap”, “easy”, and “fast”. You don’t need to invest in much hardware, in expensive software, in much administrative effort (the analysts can be their own DBAs),  nor should you endure much set-up time. Just grab a product, grab some data, and start running queries (or extracts into the statistical tool of your choice).

*If you have dozens or even hundreds of analysts hitting the same database, you’re probably back to the more concurrency-oriented scenarios outlined above.

Infobright is often cost-effective among columnar analytic DBMS. Other vendors might cut you a price break as well. If you have multiple terabytes of data, don’t rule out Netezza’s lowest-end products (even if they’d really rather sell you something bigger). Or, if you’re in the sub-terabyte range, maybe you can get by with an in-memory BI tool such as QlikView, and not do anything special on the DBMS side at all.

Investigative data mart — big

• Kinds of data likely to be included: All, especially customer-centric, logs, financial trade, scientific
• Likely use styles: Investigative
• Canonical example: Single-subject 20 TB – 20 PB relational database
• Stresses: Performance, scale-out, analytic functionality

But if you’re looking at tens of terabytes of relational data, or even more, you really do have a “big data” problem. Performance and scalability are major challenges, usually best addressed by MPP (Massively Parallel Processing) systems, such as Netezza, Vertica, Aster Data, ParAccel, Teradata, or Greenplum. Performance POCs (Proofs Of Concept) are a big part of the buying process. Vendor price negotiations are crucial too.

Actually, in the low tens of terabytes you might be able to get away with a shared-disk system that has excellent compression — e.g., columnar products like Sybase IQ, Infobright, or SAND, rather than just Vertica and ParAccel.

Assuming you have affordable, scalable query performance, the competitive differentiator can switch to additional analytic functionality. Aster, Netezza, ParAccel, Vertica, and Greenplum either offer full analytic platforms, or seem to be on the path to doing so. Teradata, which now owns Aster Data, offers substantial built-in analytic capability in its traditional products as well, and the same goes for Sybase IQ.

Continued in Part 2, where we cover some of the more difficult use cases.

• This is a list of Monash Advantage members.
• All our vendor clients are Monash Advantage members, unless …
• … we work with them primarily in their capacity as technology users. (A large fraction of our user clients happen to be SaaS vendors.)
• We do not usually disclose our user clients.
• We do not usually disclose our venture capital clients, nor those who invest in publicly-traded securities.
• Included in the list below are two expired Monash Advantage members who haven’t said they will renew, as mentioned in my recent post on analyst bias. (You can probably imagine a couple of reasons for that obfuscation.)

With that said, our vendor client disclosures at this time are:

• Aster Data
• Cloudera
• CodeFutures/dbShards
• Couchbase
• EMC/Greenplum
• Endeca
• IBM/Netezza
• Infobright
• Intel
• MarkLogic
• ParAccel
• QlikTech
• salesforce.com/database.com
• SAND Technology
• SAP/Sybase
• Schooner Information Technology
• Skytide
• Splunk
• Teradata
• Vertica

That list includes the two I’m obfuscating, plus one more who just emailed to say a signed renewal contract is arriving this week. It does not include others who, less concretely, have said they will sign up soon.

Also, I guess there’s a bit of a gray area for Tableau. As far as I’m concerned, I’m doing an upcoming co-sponsored webinar just for Monash Advantage member Aster Data. Indeed, I declined to contract with or bill Tableau directly for its share,  because I had no good way to do that paperwork. But even so, Tableau is a cosponsor, was involved in the planning discussions and, behind the scenes, is surely footing part of the bill.

*Or, as it now appears to be called, Qlik Technologies.

Let’s start with some quick reminders:

• QlikTech makes QlikView, a widely popular business intelligence (BI) tool suite.
• QlikView is distinguished by the flexibility of navigation through its user interface.
• To support this flexibility, QlikView preloads all data you might want to query into memory.

Let’s also dispose of one confusion right up front, namely QlikTech’s use of the word associative: 

• Notwithstanding QlikTech’s repeated use of phrases like “QlikView’s unique, patented in-memory associative technology,” there is nothing “associative” about QlikView’s data structures.
• Rather, “associative” is a term that can reasonably be used to describe the functionality of QlikView’s user interface. In particular, QlikView can “associate” over fields that have the same name, in that it makes it easy for users to join across them.

With that out of the way, let’s turn to some highlights of QlikView’s underlying technology.

• For the most part, QlikView’s in-memory data structures are quite simple. In particular:
  • QlikView data is stored in a straightforward tabular format.
  • QlikView data is compressed via what QlikTech calls a “symbol table,” but I generally call “dictionary” or “token” compression.
  • QlikView typically gets at its data via scans. There is very little in the way of precomputed aggregates, indexes, and the like. Of course, if the selection happens to be in line with the order in which the records are sorted, you can get great selectivity in a scan.
  • One advantage of doing token compression is that all the fields in a column wind up being the same length. Thus, QlikView holds its data in nice arrays, so the addresses of individual rows can often be easily calculated.
• To get its UI flexibility, QlikView implicitly assumes a star/snowflake schema. That is, there should be no more and no less than one possible join path between any pair of tables. In some cases, this means one will want to rename fields as part of QlikView load scripts. For example,
  • If two keys are meant to be joined on, you might want to give them the same name.
  • If two columns have the same name and mean different things (e.g., different kinds of dates), you can give them different names.
  • You can mark which columns you do or don’t want to have “qualified” names – i.e., table-specific modifications that force the names to be unique.
• QlikView is designed for gigabytes-scale databases. (More precisely, it’s constrained by how much RAM you can address in a single box, and that’s how the numbers currently work out.) In particular:
  • QlikTech recommends 2-4 gigabytes of compressed data per core. QlikTech says 10X is a good rule of thumb for compression, although it sounded like that’s a little (not a lot) on the high side when compared simply to raw data.
  • QlikTech further recommends RAM amounting to another 10% of data size be set aside for each concurrent user (e.g., for cache). However, Hakan said that’s really too pessimistic, and in most cases 5% would suffice.
  • Bottom line: QlikView “comfortably” handles databases with 10-20 gigabytes of compressed data, at whatever product of record count and record length you like. (E.g., 1 billion relatively narrow records.) That’s on the order of 100 gigabytes of raw data.
  • Indeed, several QlikView customers manage several billion records each.
• The main ingredient of the performance secret sauce in QlikView is that selections are compiled straight into machine code. (QlikTech gave me the impression that this post is the first time that will be publicly revealed.) Notes on that include:
  • In the old days, QlikTech thought compilation gave a 10X performance benefit vs. interpreted code. However, 5X might be a more up-to-date figure.
  • It’s not just code; part of the compilation is to create temporary lookup tables.
  • A single calculation can use multiple cores. QlikTech thinks it’s done a very solid job of engineering efficient multicore parallelism. (Note: So far as I could tell, Hakan was using “calculation” to refer both to queries and, well, calculations.)
  • There’s a good reason QlikView runs only on Intel-compatible processors. A port would be painful.
• In QlikView’s world, one set of users accesses one set of applications against one database on one machine. However, different subsets (or copies of the same subset) of the same underlying database(s) can of course be run on different machines.
• Naturally, QlikView caches results and tries to re-use them. One smart thing about QlikView’s caching algorithm is that it takes into account the cost of generating the calculated results. This has the happy effect that large result sets, which are often the ones most likely to be useful in a subsequent calculation, are the ones most likely to be retained.
• One thing I unfortunately forgot to ask about is loading QlikView data into memory, something that has at times been problematic.

One last thing: QlikTech is going public. That means there is a QlikTech S-1, from which I learned, among other things, that QlikTech now seems to be called Qlik Technologies. Dave Kellogg offers an outstanding overview of the information in QlikTech’s filing(s). The points I’d add to Dave’s are primarily from the QlikTech balance sheet:

• Deferred revenue, which Dave calls out as high in absolute terms, is also growing faster than revenue (or any major component of revenue).
• Accounts receivable are also growing faster than revenue or any major component thereof.
• One possible explanation is weirdness with international distributors, which is at least potentially consistent with what QlikTech says is a shift in geographical mix.
• Another explanation is increasing deal size/complexity, something that is anyway common among enterprise software companies gaining market share, and that is also consistent with what QlikTech says is a growing fraction of revenue coming from existing customers.

]]> http://www.dbms2.com/2010/06/12/the-underlying-technology-of-qlikview/feed/ 25 http://www.dbms2.com/2010/02/11/intelligent-enterprise-editors-choice-201/ http://www.dbms2.com/2010/02/11/intelligent-enterprise-editors-choice-201/#comments Thu, 11 Feb 2010 23:13:42 +0000 Curt Monash http://www.dbms2.com/?p=1578 As he has before, Intelligent Enterprise Editor Doug Henschen

• Personally selected annual lists of 12 “Most influential” companies and 36 “Companies to watch” in analytics- and database-related sectors.
• Made it clear that these are his personal selections.
• Nonetheless has called it an Editors’ Choice list, rather than Editor’s Choice.

(Actually, he’s really called it an “award.”)

People advising Doug — who come to think of it actually are Contributing Editors to Intelligent Enterprise or something like that — included Cindi Howson, Seth Grimes, three others, and me.

And if past is prologue, I will now get a flood of PR emails calling my attention to this award that I already have both participated in and blogged about.

As usual, the sense:nonsense ratio on these lists was pleasingly high. Analytic DBMS vendors cited included IBM, Microsoft, Netezza, Oracle, Sybase, and Teradata in the “Most influential” group, with Aster, Greenplum, HP, Infobright, and Vertica among the “To watch” crowd. It’s tough to argue with those selections, whose most questionable element is probably the not-ridiculous supposition that HP could do something interesting over the coming year. Cloudera and Intersystems also made the list, deservedly.

All three of QlikTech, Tableau, and TIBCO made the list, which is appropriate given the potential for and interest in interactive data exploration technology.  The BI majors, independent or otherwise, were all on as well. In text mining, Doug included Attensity and Clarabridge, which I think is exactly right. (Plus OpenCalais.)  Upon reflection, I probably should have nominated Mark Logic, even though most of its business is non-enterprise; but hey, nobody’s perfect, and the same goes for lists. Open source was well represented, with Apache, Actuate, Jaspersoft, Eclipse, Infobright, Nuxeo and R all being cited (but not Ingres or Pentaho). Kalido made the list, with my endorsement, their silly I-CASE like marketing messaging notwithstanding.

Speaking of imperfections — there only are a few category names, and so category assignments can be pretty bizarre. (In an ideal world, middleware wouldn’t be included under “enterprise applications”.) Greenplum hasn’t really “extended” its DBMS with a “cloud” option. As much as I’d like Netezza to be more influential than SAP, that’s probably not the best way to rank them. And there are a number of “This company is on a roll!” kinds of comments that I wouldn’t necessarily endorse.

But those are all nitpicks. On the whole, it’s another nice job.

• Over a 20 week period, I had travel in 13 of them.
• 3 of those were vacation in November.
• As travel finally wound down:
  • It was time to focus a bit on my own business
  • Elder care got serious; e.g., my parents went to the hospital on consecutive days, Christmas week, the first one on their 52nd wedding anniversary
  • Linda and I both got really nasty colds
  • The holidays were happening
  • I started helping out a really cool startup company (first time I’ve taken stock in a private company in years; more on that soon)
  • There was less industry news going on anyway than in some other recent months

But of course I plan to speed up the research/analysis/writing soon. Here, FYI, are a few things I have on my plate.

For a couple of years now, the center of what I’ve written about has been high-performance analytic data processing. You can expect me to keep pursuing that in all its aspects. But there are two specific areas I’ve identified in which I want to redouble my efforts.

First, almost every BI vendor has an effort in “in-memory analytics” and/or “interactive data exploration.” I suspect there’s a lot of difference in underlying technologies, but I’m having trouble getting details. QlikTech (the worst foot-dragger of the three), Microstrategy, and Jaspersoft all owe me follow-up conversations with the people who know what’s going on well enough to explain it. Tableau keeps promising me a briefing and then not delivering. And I’m even further behind with the behemoth companies — Oracle, Microsoft, IBM/Cognos (arguably) et al.

Second, solid-state memory is coming to data warehousing. The obvious reasons are that it’s obviously close, and Moore’s Law still applies to bring it closer. More specific reasons for believing in solid-state include:

• Teradata has made large strides in making solid-state memory useful.
• The stealth start-up I mentioned above is poised to make further strides.
• (I’m not totally sure yet about this part) The in-memory analytics mentioned above might wind up working better in solid-state memory than in DRAM.

I’m spending quite a few cycles thinking about this area.

I’d also like to look further at analytic applications and advanced analytic functionality. I foreshadowed some of that in my Aster webinars. There’s some good stuff to talk about at Teradata I should try to write up soon. I need to have a follow-up conversation with fascinating anti-fraud guy I met at Netezza’s London event. But that’s all just scratching the surface.

Both the MySQL and PostgreSQL communities are in some disarray. Other non-behemoth OLTP/general-purpose DBMS seem to be, at best, thriving niche products. (I see little in the way of innovative new use for, say, Progress, Cache’, Ingres, or anything multivalue.) But it feels as if there’s more opportunity out there than is being met. And at a minimum, I’d like to learn more than the almost nothing I know about OLTP NoSQL alternatives.

I’ve already said that I expect to give an industry-overview talk at MIT on January 28. I also have an overviewy press article and overviewy white paper under discussion. If those come to fruition, I’ll of course let you know.

Besides the above, I of course have a number of specific posts that I need to get around to researching and writing at some point, often on topics I’ve already written about before.  Three subjects fairly high on the priority list are scientific data management, machine-generated data, and Oracle Exadata.

And finally, I have some subjects queued up for a couple of my other blogs as well. If you don’t already take our multi-blog integrated feed, this might be a good time to switch over.

• Jaspersoft has a new v3.5 product release. Highlights include multi-tenancy-for-SaaS and another in-memory OLAP option. Otherwise, things sound qualitatively much as I wrote last September.
• Inforsense has a cool composite-analytical-applications story. More precisely, they said my phrase “analytics-oriented EAI” was an “exceptionally good” way to describe their focus. Inforsense’s biggest target market seems to be health care, research and clinical alike. Financial services is next in line.
• Tableau Software “gets it” a little bit more than other BI vendors about the need to decide for yourself how to define metrics. (Of course, it’s possible that other “exploration”-oriented new-style vendors are just as clued-in, but I haven’t asked in the right way.)
• Jerome Pineau’s favorable view of Gooddata and unfavorable view of Birst are in line with other input I trust. I’ve never actually spoken with the Gooddata folks, however.
• Seth Grimes suggests the qualitative differences between open-source and closed-source BI are no longer significant. He has a point, although I’d frame it more as being about the difference between the largest (but acquisition-built) BI product portfolios and the smaller (but more home-grown) ones, counting open source in the latter group.
• I’ve discovered about five different in-memory OLAP efforts recently, and no doubt that’s just the tip of the iceberg.
• I’m hearing ever more about public-facing/extranet BI. Information Builders is a leader here, but other vendors are talking about it too.

A little more detail, especially on Jaspersoft:

• Jaspersoft is not using multi-tenancy is to offer BI SaaS itself. But SaaS vendors were demanding the feature. What’s more, a couple of household-name corporations are using Jaspersoft’s multi-tenancy to give extranet BI access to their various customers or suppliers. Lawrence Livermore Labs seems to be a Jaspersoft extranet user too.
• The way Jaspersoft’s multi-tenancy works is that the concept of “organization” is added to the privileges hierarchy. Each organization sees its own virtual server. Only administrative superusers can span organizations.
• Jaspersoft also has a new memory-centric OLAP capability — with disk-based ROLAP for overflow – unrelated to the Mondrian MDX server. That’s a pretty common story in BI these days, I think, but I’ll confess to being unclear about exactly who is offering what when in that regard.
• Jaspersoft’s memory-centric OLAP is just a query accelerator, not a near-real-time data ingester like Aleri Live Update. Jaspersoft does handle real-time telemetry from at least one space mission (to Mars) — but how great can the bandwidth on that be?
• There’s also some kind of AJAX/Web 2.0/mash-up/whatever going on in Jaspersoft v3.5.

Some more detail yet, especially on Inforsense:

• Inforsense is focused on applications that answer a few questions rather than doing high-volume analytics, and are “designed to change.” This may be needed when there’s enough of an analytic business process that conventional BI tools aren’t a good fit (perhaps unless combined with some kind of composite application development tool or methodology).
• Inforsense’s application sweet spot to date is combining and moving around various kinds of health care data. (Especially laboratory data, both research and clinical.)
• Inforsense is a bit confusing because it was founded out of an academic research effort (Imperial College, London) to do data mining parallelized onto grids. That is no longer the company’s main focus, but the confusion continues with an occasional low-revenue, supposedly-high-prestige research award.
• Inforsense is further a bit confusing because, irrespective of focus, its analytic technology can supposedly be almost all things to almost all people. (Exactly the same thing complaint could be made about almost any other BI company.)
• What remains of the academic focus is what Inforsense characterizes as a “very flexible dataflow environment.”
• Inforsense can talk to lots of data sources and so on, including web services. It can also do updating, albeit not in demanding OLTP environments.

A few more notes, especially on Tableau Software:

• Tableau is built around a proprietary language VizQL. VizQL seems to be similar to SQL in that it focuses on filtering data. I haven’t yet read a paper Tableau sent, which should make it clearer what VizQL does that SQL doesn’t.
• Tableau is one of the new breed of “exploration” oriented BI vendors, encouraging users to just dive into data.
• I don’t know whether this is more a matter of technology or just astute marketing, but Tableau seems to be somewhat more focused than other vendors on the idea that you filter data, keep refining that filter as makes sense to you, share that filter with other people, and so on. It is hard to overstate how blind I think the BI industry is being in not aggressively developing and enhancing this kind of technology.
• That said, Tableau’s capabilities in this area still seem pretty primitive too.
• Like most software vendors, Tableau says its biggest competitor is incumbent/no decision. In Tableau’s case, the incumbent can be either BI tools or Microsoft Excel.
• Tableau says its second biggest group of competitors is other new/easy BI vendors such as QlikTech and LogiXML. Interestingly, both got mentioned with about equal emphasis.

February, 2011 edit: Here’s a partial link that works right now.

Of course, some parts do make sense.  E.g.:

• Business Objects’ completeness of vision seems to have been downgraded because of its new affiliation with SAP’s ever-confused Netweaver strategy.
• Microsoft’s completeness of vision is dinged for — well, for not being very complete.
• SAS, which unlike other vendors actually gets customers to integrate BI and predictive analytics, gets top marks in “completeness of vision”.
• IBM/Cognos leads the way overall.

Parts I find more dubious include:

• Whether or not vendors have strong international sales presences affects their “completeness of vision” scores. Huh?
• In-memory analytics are hugely emphasized, to the point that TIBCO Spotfire gets very high “completeness of vision” scores despite being just a portion of an overall BI product line. Yet vendors who get similar performance from allowing drilldown within reports don’t seem to get the same credit.
• Endeca isn’t included, while Spotfire is.
• Despite criticizing Microsoft for not delivering on promised products and Oracle for not doing much at all, Gartner gives both better “ability to execute” marks than are given to Information Builders and Microstrategy.
• While Gartner correctly points out in the commentary that company size is not a strong indicator of ability to execute, this awareness doesn’t seem to have been reflected in the actual chart.
• Gartner’s supposedly rigorous numbers seem sloppy. LogiXML is seemingly cited as almost making the $20 million product revenue cutoff, despite being a company with $7.3 million in overall revenue.

I don’t doubt that Gartner has done good research in support of this article. Indeed, I learned things from reading the supporting commentary. But the actual Magic Quadrant presentation methodology is, as always, fatally flawed.

But of course, no technology is perfect, not even one as great as David thinks QlikView is. In particular, the idea that QlikView automagically gives you access to all your information, without any prior work, is refuted by David’s comment from the link above:

Thanks Juan. We’ve taken a similar approach. Moving the data from its original source to the QVD format can be quite time-consuming for large volumes, so it is best to do it just once. Similarly, doing calculations and other data preparation in scripts and saving the results is often critical to producing quick response for end-users, since it minimizes the amount of time spent waiting for on-the-fly calculations. I haven’t personally needed to build applications that reload from QVDs on-demand, but can easily envision situations where this would also be an important strategy to ensure adequate performance.

In fairness, QlikTech and its fans never claimed that deployment was instantaneous; rather, it takes a few weeks or months. Surely much of that time goes to exactly the kind of pre-massaging David describes.