Applications of an analytic kind
The most straightforward approach to the applications business is:
- Take general-purpose technology and think through how to apply it to a specific application domain.
- Produce packaged application software accordingly.
However, this strategy is not as successful in analytics as in the transactional world, for two main reasons:
- Analytic applications of that kind are rarely complete.
- Incomplete applications rarely sell well.
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:
- Transactional apps often serve to automate rigid business processes. Analytic technology use is inherently more flexible and varied.
- Transactional apps are often used by cheaper/lower-status people. Analytic technology may be used by managers who treasure the right of individualized decision making.
There are indeed scenarios in which incomplete analytic applications can be useful. For example:
- If a user has sufficiently simple needs, cookie-cutter analytic apps — perhaps offered on a SaaS (Software as a Service) — basis might suffice.
- Small teams of technical workers can kick-start their analytic efforts with pre-built booster kits. Two examples come to mind:
- SAS Institute has done quite well with statistical “applications” that really are just accelerators for custom statistical work of the usual kind.
- Starter-kit data models for data warehousing have some value as well.
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 enhanced with some analytics so as to improve routine business processes.
- Information services enhanced with some analytic technology that retrieves (and perhaps also helps analyze) the information.
- Analytic-application-specific “platform” technology.
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.
- Simulation and optimization have been around since the 1970s, if not before. One cool effort was by River Logic, which developed a visual programming language especially geared to profitability/logistics kinds of simulations in the 1990s. (While still around, the company unfortunately doesn’t seem to have done much for the past 1 – 1 1/2 decades.)
- Much more established is SAP’s APO (Advanced Planner and Optimizer), dating back to at least the 1990s. Given the magnitude of the mixed-integer programming problems it tackles, I would conjecture it includes some built-in domain-specific heuristics you might not find in a generic set of mathematical packages.
- The financial services industry has long featured domain-specific technology. From the 1800s through the 1970s, this was focused on communications, from stock tickers (one of Thomas Edison’s first important inventions) to networks of stock quote machines. In the 1980s, that expanded to include what we’d recognize even today as real-time business intelligence tools, and then also to complex security-valuation analytics.
- What’s more, the whole area of CEP/streaming has traditionally been focused on financial trading, for reasons including low latency, time series orientation, and the opportunity to parameterize queries across a broad set of ticker symbols.
- Despite a lot of application potential, general-purpose text analytics technology has floundered. But when text analytics technology is specifically extended for marketing applications, it does better. Indeed, marketing applications don’t use general-purpose text mining technology to its fullest power. But they do add the relatively new analytic techniques of sentiment analysis. They further add capabilities to analyze short, ungrammatical “verbatims”, such as text messages.
- My clients at Metamarkets — Mike Driscoll et al. — have built a pretty cool technology stack focused on real-time/in-memory BI, well-suited for digital advertising and similar markets. I question whether it has much applicability outside of that space, however, because every industry that I can think of that needs real-time BI needs something rather different.
- WibiData is focused in a similar area, but on actually personalizing things rather than on monitoring personalization’s effects. WibiData believes this requires aggressive use of derived data and the associated schema evolution.
- Log analyzer Sumo Logic probably doesn’t rely on an off-the-shelf machine learning engine.
- Other apparent examples showed up in the comment thread to my November, 2011 post on agile predictive analytics.
It will be fascinating to see how this all plays out.
Comments
17 Responses to “Applications of an analytic kind”
Leave a Reply
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 .
and I should add, a bunch from the Hyperion acquisition plus a bunch in the Industry vertical space…
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.
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
I think SaaS might suit departments and smaller enterprises that might have simple enough needs that they don’t feel compelled to customize.
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.
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.
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
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.
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.
[…] 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 […]
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!”
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.
[…] 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 […]
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.
[…] 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 […]
[…] Much of the action these days is in analytics. Analytic apps are problematic. […]