The Downside of On-Demand

Several thoughts are swirling through my mind just now. Some are actually printable. One is this notion of “on demand” customer analytics, and what it says about the concept of “on demand” software in general. The other is the separation of analytic and execution systems, a fundamental distinction that seems increasingly questionable.

Thoughts of on demand analytics are of course prompted by yesterday’s purchase of Loyalty Matrix by Responsys, which Responsys described as a step toward becoming an “on demand marketing company.” Loyalty Matrix and Responsys are both “on demand” in the sense of delivering their services over the Internet. Maybe that’s all they mean by the label, and in that sense it’s certainly correct.

But I have come to associate “on demand” with “instant deployment,” and was at least initially intrigued at the prospect of services I could turn on almost immediately. (I’m not suggesting that Loyalty Matrix or Responsys make this claim.) Such speed is a major appeal for on demand systems in general. It is valid for products that don’t take much configuration or integration with other enterprise systems.

But customer history is important to customer management. That history is usually constructed by combining and standardizing data from multiple sources, and must be updated carefully to continue to make sense. Although traditional approaches could be improved upon, I don’t think the process can ever be removed altogether or made trivially simple. So it will always take a significant amount of time to deploy a customer database, even if it does become possible to instantly attach execution systems such as email senders.

Here’s where that distinction between analysis and execution systems comes in. Ever since people started building data warehouses, accepted wisdom has been that they should be separate. But analytics are increasingly embedded within execution systems to drive customer-specific treatments. My question is this: if the customer data portion of analysis systems can’t be delivered on demand, can analytically-enriched execution systems not be delivered on demand, either?

The obvious answer is: turn on the non-analytical portions of those systems at once and build up the analytical components later. Well, maybe. In the real world this would seem to mean doing the equivalent of a second implementation and not many people are going to like that idea. They’re more likely to either not use the analytical capabilities at all (pretty common, I suspect), or to delay implementing the system until they’re in place.

Sorry if I’m rambling a bit here—it’s the end of a long week. What I’m suggesting is we might need to look more carefully at whether the on demand model builds unrealistic expectations for deployment speed, and then leads to poor results as people sacrifice the sophistication to complete the project. Of course, such compromises are common with all sorts of systems. But if the on demand mindset makes them especially likely, we should bear that in mind when assessing on demand systems' value.