February 11, 2012

Applications of an analytic kind

The most straightforward approach to the applications business is:

However, this strategy is not as successful in analytics as in the transactional world, for two main reasons:

I first realized all this about a decade ago, after Henry Morris coined the term analytic applications and business intelligence companies thought it was their future. In particular, when Dave Kellogg ran marketing for Business Objects, he rattled off an argument to the effect that Business Objects had generated more analytic app revenue over the lifetime of the company than Cognos had. I retorted, with only mild hyperbole, that the lifetime numbers he was citing amounted to “a bad week for SAP”. Somewhat hoist by his own petard, Dave quickly conceded that he agreed with my skepticism, and we changed the subject accordingly.

Reasons that analytic applications are commonly less complete than the transactional kind include:

There are indeed scenarios in which incomplete analytic applications can be useful. For example:

But otherwise, I think the best opportunities for application-specific analytic technology aren’t really classical “analytic apps”. Rather, they arise in three sometimes-overlapping areas, adjacent to the analytic application core:

Operational applications have been enhanced with analytics for as long as we have had reports. Indeed, meeting that reporting need was the core business for Crystal Reports, the only business intelligence company ever to build a large OEM/VAR business (it was eventually merged into Business Objects). Analytic enhancement is also a major direction for application behemoths Oracle and SAP, but I won’t address that aspect in this post.

If you offer a service whose essence is tabular-structured information — e.g. a third-party data source or some stakeholder-facing analytics — then you also need to provide business intelligence capability to the information’s consumers. Too often, however, those BI capabilities are unimpressive, and there’s an “easy” improvement in upgrading them that should happen before more serious analytic-app capabilities are addressed.

What I’m most excited about right now is analytic-application-specific “platform” technology, an area in which I’ve sensed a groundswell of interest over the past 6-12 months. It’s at the heart of a significant fraction of the new startup ideas I’m hearing, and rightly so; on the other hand, it’s also been going on for decades. Here is a grab-bag of examples.

It will be fascinating to see how this all plays out.

Comments

16 Responses to “Applications of an analytic kind”

  1. shrikanth shankar on February 11th, 2012 9:18 pm

    Oracle already has an analytic app business (for some definition of analytic app) – This came in through the Siebel acquisition and have grown to cover more of the Oracle portfolio and is built on top of the OBIEE (the old Siebel Analytics) stack .

  2. shrikanth shankar on February 11th, 2012 9:21 pm

    and I should add, a bunch from the Hyperion acquisition plus a bunch in the Industry vertical space…

  3. Curt Monash on February 11th, 2012 10:02 pm

    That’s the kind of thing I’m generally underwhelmed by, or else that I judge to be “really” operational apps with some analytic enhancements. Of course, it could be that there’s cool stuff out there I’ve simply overlooked.

  4. shrikanth shankar on February 11th, 2012 10:19 pm

    Curt,
    thats fair. One interesting example /use case for these apps is the Retek product which has an analytic component used to drive operational behavior. But lets leave Oracle aside for now. – One thing that strikes me in this domain is that I believe there has usually been a significant need for customization of these analytic apps at the customer side (usually to add new sources or because well known sources are also customized by the client). Apps become more of a starter kit then . How do you think the SAAS model for txnal apps changes this or does it?

    Shrikanth

  5. Curt Monash on February 11th, 2012 11:40 pm

    I think SaaS might suit departments and smaller enterprises that might have simple enough needs that they don’t feel compelled to customize.

  6. Thomas W Dinsmore on February 12th, 2012 7:49 am

    Several comments and observations:

    (1) Analytic apps may not have worked out so well for BI vendors, but that’s because what most BI vendors call “analytic apps” are simply predefined reports

    (2) In any case, it’s apples and oranges to compare prebuilt BI to SAP. More relevant to compare to total BI market

    (3) SAS’ prebuilt “solutions” (their terminology) amount to a fraction of total revenue, but dominate new sales, which relates to the next point

    (4) It may be hard to sell an incomplete solution, but it’s even harder to sell a bunch of tools.

    (5) Before we dismiss the track record of analytic apps, bear in mind that Google is an analytic app.

  7. Curt Monash on February 12th, 2012 6:37 pm

    Thomas,

    Re your #1: Correct. When one writes an OLTP app one is basically determining a data structure and then building a straightforward UI to go with it. Even workflow capabilities really fit under that rubric.

    Building an analytic app the same way is less useful than doing the same thing in the OLTP world.

    Re your #3 and #4: No argument.

    Re your #5: Another good example of my distinction between the traditionally lame way to build analytic apps and the technologically deeper one.

  8. Ken on February 13th, 2012 3:11 pm

    Curt,
    Spot on as usual (re: challenges of offering analytic apps).

    Thanks for the mention (I think).

    Looking forward to providing you with evidence of our applicability outside of digital advertising.

    Best,
    Ken

  9. Dave Duggal on February 13th, 2012 8:52 pm

    Folks need to think differently – Analytic Apps that drive contextualized operational activities with ‘next-best action’ requires real-time semantic work integration based on a schema-less extensible architecture – that’s what we do. Fast, scalable and adaptive.

  10. Walter R Smith on February 14th, 2012 2:31 pm

    Another perspective is how applications (transactional vs analytic) are used for sensemaking / decision-making.

    If the context is routine (ordered structure), then much of it can be modeled & automated as workflows with human interaction that require minimal analytical thought. Transactional apps fit here.

    If the context is complex (unordered structure), then the human must create and manage custom or tailored models (or model fragements) of the context. Analytic apps fit here since the human is attempting to bridge the gap between context and app by configuring the app (ie, modeling the context).

    Since humans don’t instinctively do formal modeling (ie, we make sense of a context with recently triggered patterns grounded in micro-narratives), any context that requires the creation and maintenance of models will put a premium on tools that simplify work that is cognitively expensive and difficult.

    Seems like the only widely used model creation tool is the spreadsheet … and it’s mostly used for quick & simple modeling.

    See Dave Snowden’s discussion of Cynefin if you’re interested in this aspect of application design.

  11. Enterprise application software, past and present | Software Memories on February 17th, 2012 1:38 am

    [...] recently wrote a long post on the premise that enterprise analytic applications are not like the other (operational) kind. That begs the question(s): What are operational enterprise applications [...]

  12. Greg Kemnitz on February 20th, 2012 10:23 pm

    I’ll admit to being a bit skeptical about this sort of thing as a general tool business. The market problem is that most people don’t realize they have an “analytic application problem” as much as they have “Business Problem X”, which may lend itself to solution by analytic tools. And if you’re trying to argue that “people need to look at their data differently”, you’re basically saying you won’t have a market until you educate your potential market that it needs you. That’s hugely expensive.

    The “pre-packaged solutions” approach deals with this problem by selling problem-specific solutions instead of tools. It’s tough to do in a startup in that you need in-house domain expertise in each solution area, and tends to be poorly-scaling (from the perspective of growing the company fast) “consultant-ware”, but it’s more promising than trying to say “we have a way-cool killer tool with a super-fancy analytic language – if only you’d look at your data differently, you could use it!”

  13. Curt Monash on February 20th, 2012 10:54 pm

    Greg,

    The form “Business Problem X” often takes is “I want to know Numbers Y and Z, after which is will be much clearer what to do.” Application-style packaging isn’t that much of a help there; but specialized platform technology could be.

    Hence the third of my three categories.

    If the problem is “I want to know W”, that can also be the second of my three categories.

    If the problem is “I want the information I already have to actually be reflected in business operations”, that’s the first of my three.

  14. How important is BI flexibility? | DBMS 2 : DataBase Management System Services on July 12th, 2012 12:42 pm

    [...] too, notwithstanding that its limited form factor detracts from analytic flexibility. And despite the problems with analytic applications, there’s clearly still an appetite for them. If nothing else, prebuilt data models, as [...]

  15. Barney Finucane on October 13th, 2012 8:40 am

    I think the main problem with analytic applications is that vendors tend to view them as a solution to the problem, instead of a partial solution.

    To get from a predefined template to a real solution, you are always going to need consultants who understand the business needs of the customer. But few vendors make a concerted effort to deliver productivity tools to non-technical consultants so they can tweak the templates. Instead they take an all or nothing approach — either you accept the predefined app as is or you bring in technical people to fix it.

  16. Analytic application subsystems | DBMS 2 : DataBase Management System Services on February 21st, 2013 2:15 am

    [...] vendors are taking general technology and applying it to identifiable problem domains. Even so, I’ve disagreed with that phrasing in the past. For when you compare what WibiData or MarketShare offers to what we normally think of [...]

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:

Login

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.