[...] distribution channel to boot. And we’ve already seen cloud based BI such as Lucid Era fail to get off the ground indicating that this isn’t simple. But TideMark seems to have thought [...]

They have *all* failed. I was involved with #2 and #3 above, and the value prop just isn’t there. Its tedious development work to get a general purpose extraction built that handles enough variations. The customer balks at paying a six-figure price point which is needed to make it a viable business (from their point of view, it needs to be customized anyway – e.g. “Oh its great that you can decompose my GL COA into OLAP dimensions, but do you also handle stat accounts and sub-accounts?”). In any specific company’s case, their DBA can figure out the extractions in under a month, so the cost savings often cannot be communicated.

I’m not saying it can’t work, just that the deep solution has been proven as not the way to go time and time again.

Seth is right, the LucidEra deliverables were really pre-packaged analytic applications, not an open ended, general purpose BI platform. The early bet was that a standard schema structure and a standard BI stack (with data cleansing, data integration, storage, and ad hoc report generation capabilities) could be applicable to multiple pre-packaged business processes and problem areas. And, with a fixed set of fields to be populated for each app, the bet was that the integration and deployment costs could be brought down as the deployment staff’s experience grew. Furthermore, the assumption was that the operational reports delivered would then become a standard element of each customer’s process and hence would bring in good renewal rates for the SaaS vendor.

So, in summary, the bet consisted of 3 key elements:
1. A multi-purpose platform capable of supporting multiple pre-packaged analytic applications developed by LucidEra, or potentially by partners with the relevant domain expertise.
2. Enough data integration repeatability in terms of populating the same standard set of fields for each application to allow for a gradual drop in the deployment cost over time as the volume of customers increased.
3. Operational reporting applications that would be needed and used in an ongoing basis by customers and would thus deliver decent renewal rates.

I doubt that data integration complexity, as some have claimed, is what “tripped” this initiative. The company probably did not get far enough down the experience and cost curve to validate the theory that the data integration tasks for an analytic application would be sufficiently repeatable to bring in efficiency gains over time.

My guess is that the company faltered because it was forced to narrow its focus to a single analytic application area. This may have been due to limitations in the core platform that made supporting multiple application areas too time consuming and expensive, to the cost of building domain knowledge in the company around multiple process areas of expertise, or due to both. I don’t know. In any case, the company probably had no choice but to “double down” in one analytic application area, namely sales analytics. The total available market for this one analytic application area was simply not large enough to support the significant costs to build and sustain the full BI analytic application stack.

If someone can come up with a more cost effective way to build and support a versatile BI analytic application platform and potentialy enlist design partners with the relevant domain expertise to create the packaged applications, they may yet be able to prove the second and third elements of the LucidEra bet, namely that integration and deployment costs can indeed be reduced over time and that renewal rates for these types of pre-packaged applications can be strong.

Best of luck to Darren, Ken, and to the rest of the LucidEra team.
Alex

Darren

Seth