October 6, 2013

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:

*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:

Much of what I work on boils down to those two subjects. For example:

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.


11 Responses to “What matters in investigative analytics?”

  1. Thomas W. Dinsmore on October 8th, 2013 7:47 pm

    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.

  2. Curt Monash on October 8th, 2013 8:33 pm


    I disagree. Not everybody has to be a programmer to be useful.

  3. Thomas W. Dinsmore on October 9th, 2013 9:21 am


    Unlike you, I’ve actually worked with this stuff.

  4. Vlad Rodionov on October 9th, 2013 4:34 pm

    Confirmed. Problems are usually to hard and complex to be easily described in visual GUI, even in SQL.

  5. Curt Monash on October 9th, 2013 5:40 pm

    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.

  6. Libraries in Teradata Aster | DBMS 2 : DataBase Management System Services on October 10th, 2013 7:40 am

    […] recently wrote (emphasis added): My clients at Teradata Aster probably see things differently, but I don’t think […]

  7. Foobarista on October 17th, 2013 2:50 pm

    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.)

  8. Curt Monash on October 17th, 2013 5:55 pm

    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).

  9. Some stuff on my mind, September 28, 2014 | DBMS 2 : DataBase Management System Services on September 28th, 2014 8:21 pm

    […] 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 […]

  10. Where the innovation is | DBMS 2 : DataBase Management System Services on January 19th, 2015 2:21 pm

    […] There’s a lot going on in investigative analytics. Besides the “platform” technologies already mentioned, in areas such as fast-query, […]

  11. Introduction to data Artisans and Flink | DBMS 2 : DataBase Management System Services on August 21st, 2016 5:16 pm

    […] Flink doesn’t have all the capabilities one would want for the kinds of investigative analytics commonly done on […]

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.