Three things that absolutely should NOT be obstacles to these ends are:

• Corporate DBMS standards.
• Corporate data governance processes.
• The difficulties of ETL.

Reasons they shouldn’t or don’t need to be obstacles include:

• Analytic DBMS are often vastly more cost-effective than general-purpose ones.
• In particular, analytic DBMS are often much easier to install and manage than general-purpose ones.
• Heavy data governance bureaucracy is often unnecessary because:
  • The department should know what the limitations on the data’s accuracy are.
  • The department should know how much data accuracy is required.
  • The side-effects on other departments of any data inaccuracy would be minimal.
• There are multiple good schemes for populating data marts, managed by cost-effective analytic DBMS, with data from integrated data warehouses.
  • ELT (Extract/Load/Transform) almost always works, because data cleaning/data quality was handled at or before the IDW level, and because the analytic DBMS has the processing power to pull it off.
  • ETL (Extract/Transform/Load) should be easy as well. (If isn’t, something may be lacking in your ETL set-up.)
  • Analytic DBMS are increasingly adding capabilities for easy spin-out of real or virtual data marts. Other kinds of technology (e.g. virtualization) are having their database spin-out capabilities upgraded as well.

One point to remember in support of departmental autonomy is that departments’ views of what data to use may be more expansive than central IT’s. One reason is that important data may be external to the company, outside IT’s natural realm  of concern. Examples of this include but are hardly limited to:

• Anything like “market data”.
• Anything like “sentiment analysis”.
• Data owned by supply chain partners.

Further, even the more innovative internal data sources are commonly departmental, for example various kinds of multi-structured data (text verbatims from customers, log file data, and so on).

Whatever is true of data management (and ETL) is true for metadata management, even if it’s done by some kind of business intelligence tool. What I mean by that is:

• Whoever manages data is also responsible for ingesting and emitting it …
• … and specifically for emitting it in understandable, well-organized, well-named formats, …
• … so that departments can take responsibility for what amounts to lightweight analytic application development.

As for the “application development” itself, I’m envisioning at least three things:

• Math.
• Sophisticated relational query.
• Data visualization.

I.e., I’m talking about what “analysts” and “quants” do. So to put the point even more simply:

• Analysts and quants should be able to consume data that’s organized in a friendly manner.
• Central IT should be friendly in how it serves data.

One corollary of this approach is that departments should try to adhere to corporate BI standards, at least for routine dashboard and reporting. Indeed, if a department brings in a business intelligence tool different from the corporate standard, there are three main possibilities:

• The tool is integrated with something else it makes sense to bring in, such as a third-party data supply or application.
• The tool has an important capability the corporate standard doesn’t have, such as more flexible visualization and drilldown.
• Central IT screwed up, making things much more difficult than they needed to be.

• Splunk is first and foremost an analytic DBMS …
• … used to manage logs and similar multistructured data.
• Splunk’s DML (Data Manipulation Language) is based on text search, not on SQL.
• Splunk has extended its DML in natural ways (e.g., you can use it to do calculations and even some statistics).
• Splunk bundles some (very) basic, Splunk-specific business intelligence capabilities.
• The paradigmatic use of Splunk is to monitor IT operations in real time. However:
  • There also are plenty of non-real-time uses for Splunk.
  • Splunk is proudest of its growth in non-IT quasi-real-time uses, such as the marketing side of web operations.

As in any release, a lot of Splunk 4.3 is about “Oh, you didn’t have that before?” features and Bottleneck Whack-A-Mole performance speed-up. One performance enhancement is Bloom filters, which are a very hot topic these days. More important is a switch from Flash to HTML5, so as to accommodate mobile devices with less server-side rendering. Splunk reports that its users — especially the non-IT ones — really want to get Splunk information on the tablet devices. While this somewhat contradicts what I wrote a few days ago pooh-poohing mobile BI, let me hasten to point out:

• Splunk is used for a lot of (quasi) real-time monitoring.
• Splunk’s desktop user interfaces are, by BI standards, quite primitive.

That’s pretty much the ideal scenario for mobile BI: Timeliness matters and prettiness doesn’t.

Hmm. Maybe StreamBase LiveView needs a mobile option as well …

Splunk’s basic use is to take the text string that is a log and make sense of it. But Splunk now also supports JSON structures. It does this via something called spath, which as you might guess from the name has XPath similarities. That probably bore more discussion than we found the time to have.

By the way: If you’re interested in BI over XML, that’s what my former clients at Skytide were founded to do, before they pivoted a bit. I don’t think those capabilities have disappeared from the product.

Splunk has graciously allowed me to post a slide deck. More stuff in there, including quotes from a customer — Expedia — that has 2700 Splunk users.

Mobile business intelligence — real business value or just a snazzy demo?

I discussed some mobile BI use cases in July 2010, but I’m still not convinced the whole area is a legitimate big deal. BI has a long history of snazzy, senior-exec-pleasing demos that have little to do with substantive business value. For now, I think mobile BI is another of those; few people will gain deep analytic insights staring into their iPhones. I don’t see anything coming that’s going to change the situation soon.

BI-centric collaboration — real business value or just a snazzy demo?

I’m more optimistic about collaborative business intelligence. QlikView’s direct sharing of dashboards will, I think, be a feature competitors must and will imitate. Social media BI collaboration is still in the “mainly a demo” phase, but I think it meets a broader and deeper need than does mobile BI. Over the next few years, I expect numerous enterprises to establish strong cultures of analytic chatter (and then give frequent talks about same at industry conferences).  

Business intelligence for mid-market enterprises is problematic

Given the saturation of the large-enterprise BI market with supposed enterprise-standard BI systems, it would seem that smaller enterprises comprise a large part of the BI growth opportunity. However, the large-enterprise and mid-range BI markets are very different. For example:

• Large enterprises typically have tough challenges in data integration; smaller enterprises may truly start out with their data in only a few systems.
• There are many reasons for large enterprises not to do their BI in the cloud, such as bandwidth, internal politics, or the unsuitability of most cloud infrastructure for analytic DBMS scale-out. Smaller enterprises, however, may prefer SaaS (Software as a Service) BI.
• The BI market for smaller enterprises is heavily OEM. But unless you’re buying some kind of data/analytics bundle, the large enterprise BI market still seems overwhelmingly standalone.
• Large-enterprise BI tools incorporate much of a DBMS-like technology stack; at smaller enterprises, BI can often stick to its specialized-application-development-tool knitting. But on the other hand …
• … large enterprises almost always already have a data warehousing infrastructure. Mid-range BI buyers may not have a separate analytic DBMS. Therefore …
• … BI/DBMS bundles make more sense in the mid-market than they do at large enterprises.
• Each large enterprise has a unique infrastructure, and  commonly a unique competitive situation as well. Thus, the idea that you’ll pre-build most of an analytic application for a large enterprises — because you know what data model they need to do their BI — usually turns out to be silly. But smaller enterprises can be more homogeneous, and so for them pre-built analytic applications can actually work.

I don’t know of anybody who’s really cracked the code on mid-market BI. Crystal Reports (long owned by SAP Business Objects) has huge OEM share, but somehow hasn’t parlayed that into a comprehensive mid-market BI presence. Various SaaS or on-premise vendors have cool product ideas — e.g. Gooddata, Endeca, or my clients at PivotLink — but none seems to have set the world on fire to this point.

Departmental BI is doing better

The news is happier in a related market — business intelligence for departments of larger enterprises. However, this is a hard market to analyze, for at least two reasons. First — as is often the case — the distinction among large-enterprise-wise, smaller-enterprise-wide, and departmental BI is not a clear one.* Second, “departmental BI” has at least two major strains:

• Simple, pedestrian BI, implemented quickly.
• Investigative analytics.

*In particular, it has been the case since the 1990s that BI tools first get sold to departments, hopefully for fast implementations — think 4-6 weeks as a base case — and then spread out internally after their initial successes. I am frequently amused by vendors who claim to have pioneered that sales model sometime over the past decade, or even within the past few years.

That said, there are two main kinds of reason to do your BI departmentally, at arm’s length from central IT.

• Perhaps, for good reason or bad, IT is being insufficiently helpful at managing the data.
  • This can be a straightforward matter of politics and priorities — IT controls the data, but is slow about giving you access.
  • Also, you may want to include data that’s outside IT’s purview, be it third-party or just purely departmental.
• Further, you may want functionality that corporate-standard BI doesn’t offer. Potential examples include:
  • Cool analytic visualization.
  • “Real-time” data visualization.
  • The ability to play nicely with particular kinds of data sets.

I have a lot more to say about those points — but not in a post that’s already as long as this one.

• “Deliver products that really meet customers’ desires and needs.”
• “Successfully convince them that you’re doing so …”
• “… at an attractive overall cost.”

Vendors mentioned here are Oracle, SAP, HP, and IBM. Anybody smaller got left out due to the length of this post. Among the bigger omissions were:

• salesforce.com (multiple subjects).
• SAS HPA.
• The evolution of Hadoop.

A (lingering) issue for SAP and Oracle alike

As I noted in January of this year, integration of business intelligence into operational apps is making very slow progress. Even so, it’s a huge part of the apparent strategy at SAP and Oracle alike, as well it should be. Much of the benefit from automating routine desk work has already happened. The areas ripest for exploitation are the ones where analytics are part of the equation.

Given the lack of tangible progress, why do I think this is a genuine area of Oracle and SAP emphasis? Three reasons of many are:

• Why else did SAP buy Business Objects?
• If they’re not trying to integrate operational apps and analytics, why else does SAP’s emphasis on HANA make sense?
• Without business intelligence in the picture, how does Oracle’s integrated-stack story promise any direct user benefits?*

*As opposed to IT concerns — integration, administration, TCO (Total Cost of Ownership), etc.

After so many years of disappointment, I’m not going to forecast 2012 as a pivotal year for the integration of business intelligence into operational applications. But if one of SAP or Oracle ever does get a significant BI/operational app integration advantage over the other, it could be a major competitive advantage in those application market segments that are still up for grabs. It also is an opportunity for both vendors to gain BI market share in their respective application customer bases.

A more urgent issue for SAP

SAP has put huge amounts of credibility on the line for HANA, the integration of two different and not particularly mature in-memory database technologies. So far, it is difficult to find evidence that HANA is robust enough for widespread adoption. Whether or not SAP can fix that is a huge open question, which could have significant impact on the course of several technology areas: applications, business intelligence, in-memory DBMS, and maybe even hardware.

Based on current information, which is admittedly partial, I’m a short-term pessimist on HANA. Longer-term, I’m on record as saying that traditional databases will eventually wind up in RAM. SAP will surely get that technology right some day, whether or not the way it does so has anything to do with present-day HANA code.

Four more issues for Oracle

Oracle’s ambitions are near-endless, and so also therefore is its list of execution challenges. Four in the analytics area that I find particularly interesting are:

• True hybrid columnar DBMS. I was guessing that Oracle, like Teradata, would announce true hybrid columnar the week of Oracle OpenWorld. I was wrong. But if Oracle can’t bring out true hybrid columnar DBMS functionality relatively soon, Exadata will lose credibility as a competitor to more specialized analytic DBMS.
• Oracle Exalytics. With Exalytics in the mix, Oracle’s technology stack has HANA-like potential. But will Exalytics even ship in 2012? (I think so.) Will it be good for much in the first release? (I’m skeptical.)
• Oracle’s Big Data Appliance. I’m skeptical both about Oracle’s NoSQL product — a favorable InfoWorld review notwithstanding — and Hadoop appliances. But if I’m wrong, and Oracle can successfully embrace/extend the new non-relational paradigms, then it really might regain control over the evolution of data management.
• Oracle’s Endeca acquisition — will Oracle prove me wrong and integrate Endeca effectively into its overall analytic product line? If it does, we might finally see effective text (and eventually speech) navigation of enterprise software. (But as with all Oracle issues cited here, this is something that probably won’t amount to much in 2012 even if it does later go well.)

Three issues for IBM

Like Oracle, IBM is a huge company with many ambitions and hence many execution challenges. The biggest of those is surely: How effective can IBM be at selling outside its existing customer base? I don’t hear as much competitively about IBM DataStage, IBM SPSS or now IBM Netezza as I did when their vendors were independent companies. Even Cognos may not be much of an exception to the rule, although it has its own large customer base outside of IBM’s traditional one. (To lesser extents , the same is of course true of Netezza and numerous other IBM acquisitions.)

Another general issue for IBM is substantively integrating its various product lines, at least to the extent that makes sense. DB2/Netezza integration sounds good, but even that is a matter more of product marketing (the admirable part of that discipline) more than of actual technology. Other integrations (e.g. Cognos/DB2 in various bundles) have tended toward the dubious side.*

*I’m still waiting for IBM to get back to me with examples of how Cognos/DB2 joint tuning amounts to anything. It’s been more than a year, so I’m glad I didn’t hold my breath.

In a somewhat narrower vein, I wonder: Will IBM be able to gain traction for InfoSphere Streams? And if so, when and where will the traction be?

Will HP screw up Vertica?

Vertica has a very attractive product offering. It’s perhaps the most scalable analytic DBMS outside of Teradata, running on the hardware of your reasonable choice.  It’s also the one I recommend most often to clients in the 1-50 terabyte range.

So far HP doesn’t seem to have done much to leadfoot Vertica. (About all I’ve heard from competitors is that Vertica seems to have faded somewhat in the financial services market, and there could be multiple explanations if that is indeed true.) But if HP Vertica does somehow manage to botch things, opportunities will open up for a range of columnar analytic DBMS competitors.

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.

• LiveView is a business intelligence and alerting suite built on/in the rest of StreamBase’s technology, meant to operate on streaming data.
• LiveView is positioned by StreamBase as having a true push event-driven architecture rather than pull/poll.
• StreamBase LiveView is designed to query in-memory data and then have the results change in real time as the data set changes.
• The LiveView user interface is a rapidly changing work in progress.
• LiveView has other Version 1 limitations as well
• LiveView is targeted squarely at StreamBase’s financial trading core market until some of the Version 1 limitations are lifted.

The basic StreamBase LiveView pipeline goes something like:  

• Data comes into the system via multiple streams.
• Transformations upon data arrival can include but are not limited to:
  • Aggregations.
  • Joins to reference data.
  • Joins to other streams.
• The streams (transformed or perhaps otherwise) are output to tables …
• … which are continuously updated as more data streams through.
• The data in the resulting table can be consumed:
  • Via LiveView-provided BI capabilities.
  • Via an API.

When wearing my vendor consultant hat, I warmly encourage StreamBase to emphasize the lack of a batch step anywhere in this process. As an analyst, however, I’m more restrained about a claim like “We uniquely free you from batch.” I agree that avoiding batch jobs is a Very Nice Thing. But you also are spared most batch-cycle processing if you stream updates from your short-request database to an analytic DBMS, e.g. via some kind of near-real-time replication.

That said, the push-versus-pull continuous filtering part of the StreamBase LiveView story seems pretty real. I think having sub-second display updates is cool in all sorts of BI use cases, and seriously useful in some number of them. While I don’t have a clear opinion as to whether the StreamBase approach offers huge performance advantages for that kind of latency over “pull” alternatives, my guess is in the direction of “yes”.

Version 1 limitations on StreamBase LiveView include:

• You consume data one table at a time, with no possibility of a join after the data has originally been put into a LiveView table.
• While LiveView in principle offers rich alerting potential, you get at it via an API rather than much in the way of alerting-specific tools.
• The first LiveView UI StreamBase put together looks a lot like 1980s stock quote machines. The next one it added looks a lot like Panopticon. Much cool-looking enhancement remains to be done.

One competitive (non)-note: This all sounds something like what TIBCO has been pushing for years, but in fact I don’t have much knowledge of TIBCO’s efforts in the area. I had a meeting set up to learn about it some time ago, but it got canceled because TIBCO’s PR people:

• Didn’t want to let any kind of meeting happen without them, even though a serious CTO-type representative seemed happy to talk, but also …
• … didn’t want to work at dinner time.

I haven’t had substantive contact with TIBCO since.

• The upshot of my what to call CEP thread in August was that “streaming” and “event processing” are not the same concept, but it so happens that they have the most traction where they intersect. That said, I both observe and endorse an apparent shift from “event” to “stream” as the core of the terminology, in a reversal of my opinion of several years ago.
• IBM continues to throw a lot of resources at its System S/ InfoSphere Streams product, but I haven’t heard yet of much marketplace success. That said, I believe IBM is still pretty serious about Streams, as one would expect from an effort whose code name so cheekily references System R. In particular, Streams shows up prominently on IBM’s top-level analytic architecture slide.
• Sybase recently released its ESP (Event Stream Processor) 5.0, which it says is the full merger of the Aleri and Coral8 predecessors. You can still get Sybase ESP without buying into the full Sybase RAP stack, and Sybase has no plans to change that.
• Sybase has discontinued all the business intelligence types of products Aleri and Coral8 were developing. Rather, Sybase is OEMing Panopticon, which it reports has been well received. Other than the discontinuation of the BI efforts, there seem to be few Aleri or Coral8 features missing from the merged Sybase ESP product.
• Truviso continues to be out of the picture.
• I have more to say about StreamBase separately.
• I have more to say about Sybase and IBM, which I’ll get to when I can.
• I have nothing new on Progress Apama. I also know little about any of the open source efforts.

Meanwhile, if you want to see technically nitty-gritty posts about the CEP/streaming area, you may want to look at my CEP/streaming coverage circa 2007-9, based on conversations with (among others) Mike Stonebraker, John Bates, and Mark Tsimelzon.

• The term investigative analytics has gotten considerable traction.
• I generally contrast “investigative” and “operational” analytics, for example in the last line of the post linked above, or in my recent introduction to Odiago WibiData.
• It’s clear that I’m conflating several different things in the term. (See for example the operational analytics sections of my posts on eight kinds of analytic database or definitional challenges for 2011.)
• I’m pretty negative about the utility of alternate terms such as “operational BI”.

But as in all definitional discussions, please remember that nothing concise is ever precise.

Activities I want to call “operational analytics” include but are not limited to (and some of these overlap):  

• A lot of things that happen at the time of customer interaction:
  • Ad serving, web page personalization, and so on.
  • On-the-fly fraud assessment.
  • In general, much of what might be called “Next Best Action”.
• Most of automated price re-setting.
• Most of automated risk analysis.
• Algorithmic and/or high-frequency trading.
• Human beings taking specific actions as part of reasonably well-defined business processes, in response to exception conditions that they notice via something resembling a business intelligence tool.

However, I think it is usually unhelpful to stretch the term “business process” to include technical control kinds of activities (whether human or wholly automated) such as network security, network operations, power plant operations, etc. So I’m inclined to leave those areas out of “operational analytics” as well, although I’m not sure whether that distinction will hold up — and even it does, there surely will be border cases that are hard to exclude.

In simplest terms, what I mean by operational analytics is analytics being done on the fly as part of operational business processes. By way of contrast, investigative analytics is done at the speed of research, not the speed of operational business processes. But naturally there are border cases in this version of the dichotomy too, such as when the analytics are highly urgent yet otherwise investigative in nature.

To get to a somewhat more rigorous version, let’s start by recalling my definition of investigative analytics as

seeking (previously unknown) patterns in data.

The key concept there is that the patterns aren’t known until you investigate and find them.

By way of contrast, most of what passes for cognition and programmed behavior alike is the recognition of and response to known patterns. Indeed, when we consider what happens in microelectronics and neurons alike, it’s “pattern response all the way down.”* Machines and humans alike monitor situations, detect exceptions, and make decisions based on known patterns. So I’m going to say that the essence of operational analytics is

analytic pattern response included in operational business processes.

*For some years I’ve believed “pattern response” is a better way of putting the concept than just “pattern recognition”; the latter phrase says both too much and too little at once. Otherwise, I was referencing the meme “turtles all the way down”.

For now, I’ll take the Justice Stewart approach to defining “operational business processes” — we know them when we see them, and no further elucidation is needed. Even so, it might be helpful to observe that the processes can be:

• Wholly automated — examples included automated trading or web page ad serving.
• Primarily automated — for example, software might tell a call center employee what offer to make next.
• At considerable human discretion — for example, a human being automatically notified of an exception could have freedom to decide what to do next.

The technologies for identifying a pattern match are also varied. You can write an ordinary database application. You can use a “rules engine”. Something like PMML (Predictive Modeling Markup Language) can be in the mix. Or, especially in human-discretion cases, various forms of business intelligence tool (broadly defined) can be involved, either standalone or integrated with more transactional applications.

So what do you think? Is the definition of “operational analytics” sufficiently clear? Is it accurate? Is it useful?

Stefan reports that these capabilities are appealing to a significant fraction of enterprise or other commercial Hadoop users, especially the EtL and the BI. I don’t doubt him.