What matters in investigative analytics?
In a general pontification on positioning, I wrote:
every product in a category is positioned along the same set of attributes,
and went on to suggest that summary attributes were more important than picky detailed ones. So how does that play out for investigative analytics?
First, summary attributes that matter for almost any kind of enterprise software include:
- Performance and scalability. I write about analytic performance and scalability a lot. Usually that’s in the context of analytic DBMS, but it also arises in analytic stacks such as Platfora, Metamarkets or even QlikView, and also in the challenges of making predictive modeling scale.
- Reliability, availability and security.* This is more crucial for short-request applications than analytic ones, but even your analytic systems shouldn’t leak data or crash.
- Goodness of fit with legacy systems. I hate that one, because enterprises often sacrifice way too much in favor of that benefit.
- Price. Duh.
*I picked up that phrase when — abbreviated as RAS — it was used to characterize the emphasis for Oracle 8. I like it better than a general and ambiguous concept of “enterprise-ready”.
The reason I’m writing this post, however, is to call out two summary attributes of special importance in investigative analytics — which regrettably which often conflict with each other — namely:
- Agility. People don’t want to submit requests for reports or statistical analyses; they want to get answers as soon as the questions come to mind.
- Completeness of feature set — for a particular use case, that is. There’s no such thing as an investigative analytics offering with a feature set that’s close to complete for all purposes; even SAS, IBM and other behemoths fall short.
Much of what I work on boils down to those two subjects. For example:
- I recently suggested that navigation is a huge part of business intelligence differentiation. That’s because good navigation pretty much equates to BI agility. With luck, a BI tool that has the right navigation on the right data will get you to the result set you want, all within a few minutes.
- There’s an obvious demand for agile predictive analytics. But if agility were all that mattered, KXEN — which excels in agility — would probably have done a lot better; KXEN’s problem was that it didn’t offer enough algorithmic breadth to meet enough users’ demands or needs.
- Conversely, SAS has an exceptionally broad feature set. But few parts of the SAS product line offer much in the way of agility.
- I’ve argued that analytic apps need to be continually customized, which is about as strong a pitch for agility as one can make. And that’s one of the major reasons that packaged analytic apps can’t really be feature-complete.
- On the other hand, if you view incomplete predictive modeling apps as agility-enhancing application quick-starts — well, you’ve just described some of the most agile and also some of the most important parts of the SAS product line.
- From an agility standpoint, the integration of predictive modeling into business intelligence would seem like pure goodness. Unfortunately, the most natural ways to do such integration would have very limited predictive features.
- My clients at Teradata Aster probably see things differently — Edit: indeed they do — but I don’t think their library of pre-built analytic packages has been a big success. The same goes for other analytic platform vendors who have done similar (generally lesser) things. I believe that this is because such limited libraries don’t do enough of what users want.
- I noted in July that complex, multi-stage predictive modeling is increasingly in vogue. Well, if predictive modeling is much more complicated than before, then things have to happen to make each step — or at least the average step — a lot easier and faster. I think that’s a core part of the value proposition for startups such as Ayasdi.
And finally: It is easier to be feature-complete — or at least feature-rich — for particular markets than across-the-board. That’s why I’ve steered a number of full-stack BI or predictive modeling technology clients toward vertical strategies.
Comments
11 Responses to “What matters in investigative analytics?”
Leave a Reply
As a practical matter, investigative analytics — also known as ad hoc analytics or situational analytics — requires a programming language and a skilled investigator. That’s because investigative analytics seeks to answer questions that are, by nature, non-repeatable and strategic.
Most analysts who do this kind of work use the SAS Programming Language, not SAS’ higher level applications, or they use R, or they write SQL queries, or they write their own MapReduce.
KXEN’s tooling is fast and easy to use for a limited set of use cases, but it is not agile in the same sense as analytic programming languages are agile.
In most organizations, investigative analytics account for 60-80% of the total effort expended in analytics. Which likely explains why nobody bought KXEN.
Thomas,
I disagree. Not everybody has to be a programmer to be useful.
Curt,
Unlike you, I’ve actually worked with this stuff.
Confirmed. Problems are usually to hard and complex to be easily described in visual GUI, even in SQL.
You guys may naturally focus on the kinds of problems where your skills are required.
That doesn’t mean there aren’t also other use cases in which your skills are not as necessary.
[…] recently wrote (emphasis added): My clients at Teradata Aster probably see things differently, but I don’t think […]
The company I’m at does fraud detection analytics. We aren’t a pure “tech play” – we sell a packaged data browser and backend that processes data sourced from the customer. We also sell fraud analyst services. Scoring is done by a model-driven scoring engine as the data streams in, with lots of secondary mining done later.
In addition to the core product team, we have two interesting groups: a bunch of “quants” who create and maintain models (they’re statistics/R/SQL types), and fraud analysts who are hired by customers. The analysts aren’t particularly technical; they come from fraud detection or investigative law enforcement backgrounds.
Our experience is it’s hard to come up with pure technical approaches, particularly since we have an “active enemy” who’s always changing the approaches they take as they figure out what you’re doing. Our fraud investigators provide a crucial feedback loop with the techies to help us quickly identify new types of attacks and get them in the modeling. (It also helps that we’re a relatively small company where the fraud team can meet techies without a lot of organization in the way.)
I’ve been focusing on the full-technology-stack approach to vertical analytics, but you’re right that blending technology and services makes a lot of sense as well.
The trick will be scaling and efficiency for the services part of the business. http://www.softwarememories.com/2010/10/03/ray-lane-and-the-integration-of-software-and-consulting-at-oracle/ speaks to related issues (the consulting in that post is more in the way of software development).
[…] ClearStory. This is unsurprising, as ClearStory exemplifies several trends I believe in, including robust analytic stacks, strong data navigation, Spark, and the incorporation of broad varieties of […]
[…] There’s a lot going on in investigative analytics. Besides the “platform” technologies already mentioned, in areas such as fast-query, […]
[…] Flink doesn’t have all the capabilities one would want for the kinds of investigative analytics commonly done on […]