Category Archives: Enterprise

The Customer Acquisition Cost (CAC) Ratio: Another Subtle SaaS Metric

The software-as-a-service (SaaS) space is full of seemingly simple metrics that can quickly slip through your fingers when you try to grasp them.  For example, see Measuring SaaS Renewals Rates:  Way More Than Meets the Eye for a two-thousand-word post examining the many possible answers to the seemingly simple question, “what’s your renewal rate?”

In this post, I’ll do a similar examination to the slightly simpler question, “what’s your customer acquisition cost (CAC) ratio?”

I write these posts, by the way, not because I revel in the detail of calculating SaaS / cloud metrics, but rather because I cannot stand when groups of otherwise very intelligent people have long discussions based on ill-defined metrics.  The first rule of metrics is to understand what they are and what they mean before entertaining long discussions and/or making important decisions about them.  Otherwise you’re just counting angels on pinheads.

The intent of the CAC ratio is to determine the cost associated with acquiring a customer in a subscription business.  When trying to calculate it, however, there are six key issues to consider:

  • Months vs. years
  • Customers vs. dollars
  • Revenue on top vs. bottom
  • Revenue vs. gross margin
  • The cost of customer success
  • Time periods of S&M

Months vs. Years

The first question — which relates not only to CAC but also to many other SaaS metrics:  is your business inherently monthly or annual?

Since the SaaS movement started out with monthly pricing and monthly payments, many SaaS businesses conceptualized themselves as monthly and thus many of the early SaaS metrics were defined in monthly terms (e.g., monthly recurring revenue, or MRR).

While for some businesses this undoubtedly remains true, for many others – particularly in the enterprise space – the real rhythm of the business is annual.  Salesforce.com, the enterprise SaaS pioneer, figured this out early on as customers actually encouraged the company to move to an annual rhythm, for among other reasons, to avoid the hassle associated with monthly billing.

Hence, many SaaS companies today view themselves as in the business of selling annual subscriptions and talk not about MRR, but ARR (annual recurring revenue).

Customers vs. Dollars

If you ask some cloud companies their CAC ratio, they will respond with a dollar figure – e.g., “it costs us $12,500 to acquire a customer.”  Technically speaking, I’d call this customer acquisition cost, and not a cost ratio.

There is nothing wrong with using customer acquisition cost as a metric and, in fact, the more your business is generally consistent and the more your customers resemble each other, the more logical it is to say things like, “our average customer costs $2,400 to acquire and pays us $400/month, so we recoup our customer acquisition cost in six months.”

However, I believe that in most SaaS businesses:

  • The company is trying to run a “velocity” and an “enterprise” model in parallel.
  • The company may also be trying to run a freemium model (e.g., with a free and/or a low-price individual subscription) as well.

Ergo, your typical SaaS company might be running three business models in parallel, so wherever possible, I’d argue that you want to segment your CAC (and other metric) analysis.

In so doing, I offer a few generic cautions:

  • Remember to avoid the easy mistake of taking “averages of averages,” which is incorrect because it does not reflect weighting the size of the various businesses.
  • Remember that in a bi-modal business that the average of the two real businesses represents a fictional mathematical middle.

avg of avg

For example, the “weighted avg” column above is mathematically correct, but it contains relatively little information.  In the same sense that you’ll never find a family with 1.8 children, you won’t find a customer with $12.7K in revenue/month.  The reality is not that the company’s average months to recoup CAC is a seemingly healthy 10.8 – the reality is the company has one very nice business (SMB) where it takes only 6 months to recoup CAC and one very expensive one where it takes 30.  How you address the 30-month CAC recovery is quite different from how you might try to squeeze a month or two out the 10.8.

Because customers come in so many different sizes, I dislike presenting CAC as an average cost to acquire a customer and prefer to define CAC as an average cost to acquire a dollar of annual recurring revenue.

Revenue on Top vs. Bottom

When I first encountered the CAC ratio is was in a Bessemer white paper, and it looked like this.

cac picture

In English, Bessemer defined the 3Q08 CAC as the annualized amount of incremental gross margin in 3Q08 divided by total S&M expense in 2Q08 (the prior quarter).

Let’s put aside (for a while) the choice to use gross margin as opposed to revenue (e.g., ARR) in the numerator.  Instead let’s focus on whether revenue makes more sense in the numerator or the denominator.  Should we think of the CAC ratio as:

  • The amount of S&M we spend to generate $1 of revenue
  • The amount of revenue we get per $1 of S&M cost

To me, Bessemer defined the ratio upside down.  The customer acquisition cost ratio should be the amount of S&M spent to acquire a dollar of (annual recurring) revenue.

Scale Venture Partners evidently agreed  and published a metric they called the Magic Number:

Take the change in subscription revenue between two quarters, annualize it (multiply by four), and divide the result by the sales and marketing spend for the earlier of the two quarters.

This changes the Bessemer CAC to use subscription revenue, not gross margin, as well as inverts it.  I think this is very close to CAC should be calculated.  See below for more.

Bessemer later (kind of) conceded the inversion — while they side-stepped redefining the CAC, per se, they now emphasize a new metric called “CAC payback period” which puts S&M in the numerator.

Revenue vs. Gross Margin

While Bessemer has written some great papers on Cloud Computing (including their Top Ten Laws of Cloud Computing and Thirty Q&A that Every SaaS Revenue Leader Needs to Know) I think they have a tendency to over-think things and try to extract too much from a single metric in defining their CAC.  For example, I think their choice to use gross margin, as opposed to ARR, is a mistake.

One metric should be focused on measuring one specific item. To measure the overall business, you should create a great set of metrics that work together to show the overall state of affairs.

leaky

I think of a SaaS company as a leaky bucket.  The existing water level is a company’s starting ARR.  During a time period the company adds water to the bucket in form of sales (new ARR), and water leaks out of the bucket in the form of churn.

  • If you want to know how efficient a company is at adding water to the bucket, look at the CAC ratio.
  • If you want to know what happens to water once in the bucket, look at the renewal rates.
  • If you want to know how efficiently a company runs its SaaS service, look at the subscription gross margins.

There is no need to blend the efficiency of operating the SaaS service with the efficiency of customer acquisition into a single metric.  First, they are driven by different levers.  Second, to do so invariably means that being good at one of them can mask being bad at the other.  You are far better off, in my opinion, looking at these three important efficiencies independently.

The Cost of Customer Success

Most SaaS companies have “customer success” departments that are distinct from their customer support departments (which are accounted for in COGS).  The mission of the customer success team is to maximize the renewals rate – i.e., to prevent water from leaking out of the bucket – and towards this end they typically offer a form of proactive support and adoption monitoring to ferret out problems early, fix them, and keep customers happy so they will renew their subscriptions.

In addition, the customer success team often handles basic upsell and cross-sell, selling customers additional seats or complementary products.  Typically, when a sale to an existing customer crosses some size or difficultly threshold, it will be kicked back to sales.  For this reason, I think of customer success as handling incidental upsell and cross-sell.

The question with respect to the CAC is what to do with the customer success team.  They are “sales” to the extent that they are renewing, upselling, and cross-selling customers.  However, they are primarily about ARR preservation as opposed to new ARR.

My preferred solution is to exclude both the results from and the cost of the customer success team in calculating the CAC.  That is, my definition of the CAC is:

dk cac pic

I explicitly exclude the cost customer success in the numerator and exclude the effects of churn in the denominator by looking only at the new ARR added during the quarter.  This formula works on the assumption that the customer success team is selling a relatively immaterial amount of new ARR (and that their primary mission instead is ARR preservation).  If that is not true, then you will need to exclude both the new ARR from customer success as well as its cost.

I like this formula because it keeps you focused on what the ratio is called:  customer acquisition cost.  We use revenue instead of gross margin and we exclude the cost of customer success because we are trying to build a ratio to examine one thing:  how efficiently do I add new ARR to the bucket?  My CAC deliberately says nothing about:

  • What happens to the water once S&M pours it in the bucket.  A company might be tremendous at acquiring customers, but terrible at keeping them (e.g., offer a poor quality service).  If you look at net change in ARR across two periods then you are including both the effects of new sales and churn.  That is why I look only at new ARR.
  • The profitability of operating the service.  A company might be great at acquiring customers but unable to operate its service at a profit.  You can see that easily in subscription gross margins and don’t need to embed that in the CAC.

There is a problem, of course.  For public companies you will not be able to calculate my CAC because in all likelihood customer success has been included in S&M expense but not broken out and because you can typically only determine the net change in subscription revenues and not the amounts of new ARR and churn.  Hence, for public companies, the Magic Number is probably your best metric, but I’d just call it 1/CAC.

My definition is pretty close to that used by Pacific Crest in their annual survey, which uses yet another slightly different definition of the CAC:  how much do you spend in S&M for a dollar of annual contract value (ACV) from a new customer?

(Note that many vendors include first-year professional services in their definition of ACV which is why I prefer ARR.  Pacific Crest, however, defines ACV so it is equivalent to ARR.)

I think Pacific Crest’s definition has very much the same spirit as my own.  I am, by comparison, deliberately simpler (and sloppier) in assuming that customer success not providing a lot of new ARR (which is not to say that a company is not making significant sales to its customer base – but is to say that those opportunities are handed back to the sales function.)

Let’s see the distribution of CAC ratios reported in Pacific Crest’s recent, wonderful survey:

pac crest cac

Wow.  It seems like a whole lot of math and analysis to come back and say:  “the answer is 1.

But that’s what it is.  A healthy CAC ratio is around 1, which means that a company’s S&M investment in acquiring a new customer is repaid in about a year.  Given COGS associated with running the service and a company’s operating expenses, this implies that the company is not making money until at least year 3.  This is why higher CACs are undesirable and why SaaS businesses care so much about renewals.

Technically speaking, there is no absolute “right” answer to the CAC question in my mind.  Ultimately the amount you spend on anything should be related to what it’s worth, which means we need relate customer acquisition cost to customer lifetime value (LTV).

For example, a company whose typical customer lifetime is 3 years needs to have a CAC well less than 1, whereas a company with a 10 year typical customer lifetime can probably afford a CAC of more than 2.  (The NPV of a 10-year subscription increasing price at 3% with a 90% renewal rate and discount at 8% is nearly $7.)

Time Periods of S&M Expense

Let me end by taking a practical position on what could be a huge rat-hole if examined from first principles.  The one part of the CAC we’ve not yet challenged is the use of the prior quarter’s sales and marketing expense.  That basically assumes a 90-day sales cycle – i.e., that total S&M expense from the prior quarter is what creates ARR in the current quarter.  In most enterprise SaaS companies this isn’t true.  Customers may engage with a vendor over a period of a year before signing up.  Rather than creating some overlapped ramp to try and better model how S&M expense turns into ARR, I generally recommend simply using the prior quarter for two reasons:

  • Some blind faith in offsetting errors theory.  (e.g., if 10% of this quarter’s S&M won’t benefit us for a year than 10% of a year ago’s spend did the same thing, so unless we are growing very quickly this will sort of cancel out).
  • Comparability.  Regardless of its fundamental correctness, you will have nothing to compare to if you create your own “more accurate” ramp.

I hope you’ve enjoyed this journey of CAC discovery.  Please let me know if you have questions or comments.

Thoughts on the Jive Registration Statement (S-1) and Initial Public Offering (IPO)

I finally found  some time to read over the approximately 175-page registration statement (S-1) that enterprise social networking software provider Jive Software filed on August 24, 2011 in support of a upcoming initial public offering (IPO) of its stock.

In this post, and subject to my usual disclaimers, I’ll share some of my thoughts on reading the document.

Before jumping into financials, let’s look at their marketing / positioning.

  • Jive positions as a “social business software” company.   Nice and clear.
  • Since everyone now needs a Google-esque (“organize the world’s information”) mission statement, Jive has one:  “to change the way work gets done.”  Good, but is change inherently a benefit?  Not in my book.
  • Jive’s tagline is “The New Way To Business.”  Vapid.
  • Since everyone seems to inexplicably love the the tiny-slice-of-huge-market argument in an IPO, Jive offers up $10.3B as the size of the collaborative applications market in 2013.  That this implies about 2% market share in 2013 at steady growth doesn’t seem to bother anyone.  Whither focus and market dominance?

Now, let’s move to financials.  Here’s an excerpt with the consolidated income statement:

The astute reader will notice a significant change in 2010 when Jive Founder Dave Hersh stepped down as CEO and was replaced with ex-Mercury CEO Tony Zingale.  Let’s make it easier to see what’s going by adding some ratios:

Translating some of the highlighted cells to English:

  • Jive does not make money on professional services:  they had a -17% gross margin 2010 and -13% gross margin in 1H11.
  • In 2009,  a very difficult year, Jive grew total revenue 77% and did so with a -15% return on sales.
  • In 2010, Jive grew revenue 54% with a -60% return on sales, while in 1H11, Jive grew revenue 76% with a -64% return on sales.
  • In 2010, Jive increased R&D, S&M, and G&A expense by 127%, 103%, and 132% respectively.
  • In 2010, Jive had a $27.6M operating loss, followed by a $30.6M operating loss 1H11

To say that Jive is not yet profitable is like saying the Tea Party is not yet pro-taxation.  For every $1.00 in revenue Jive earned in 1H11, they lost $0.90. People quipped that the Web 1.0 business model was “sell dollars for ninety cents.”  Jive seems to be selling them for about fifty-three.

But that analysis is unduly harsh if you buy into the bigger picture that:

  • This is the dawn of a large opportunity; a land-grab where someone is going to take the market.
  • You assume that once sold, there are reasonably high switching costs to prevent a customer from defecting to a competitive service.
  • These are subscription revenues.  Buying $1.00 of revenue for $1.90 is foolish on a one-shot deal, but in this case they’re buying a $1.00 annuity per year.  In fact, if you read about renewal rates later on in the prospectus, they’re actually paying $1.90 for a $1.00 annuity that grows at 25% per year.

I’d say this is a clear example of a go-big-or-go-home strategy.  You can see the strategic tack occurring in 2010, concurrent with the management change.  And, judging by the fact that they’re filing an S-1, it appears to be working.

Before moving on, let’s look at some ratios I calculated off the income statement:

You can see the strategy change in the highlighted cells.

  • Before the change, Jive spent $1.16 to get a dollar of revenue.  After, they spent $1.90.
  • Before, they got $2.91 of incremental revenue per incremental operating expense.  After, they got $0.90.  (It looks similar on a billings basis.)
  • Before, they got $6.76 of incremental product revenue per incremental S&M dollar.  After, they got $1.73.

Clearly, the change was not about efficiency.  You could argue that it was either about growth-at-all-costs or, more strategically, about growth as a landgrab.

But we’re only on page 6 of the prospectus, so we’re going to need to speed up.

Speaking of billings and revenues, let’s hear what Jive has to say:

We consider billings a significant leading indicator of future recognized revenue and cash inflows based on our business model of billing for subscription licenses annually and recognizing revenue ratably over the subscription term. The billings we record in any particular period reflect sales to new customers plus subscription renewals and upsell to existing customers, and represent amounts invoiced for product subscription license fees and professional services. We typically invoice the customer for subscription license fees in annual increments upon initiation of the initial contract or subsequent renewal. In addition, historically we have had some arrangements with customers to purchase subscription licenses for a term greater than 12 months, most typically 36 months, in which case the full amount of the agreement will be recognized as billings if the customer is invoiced for the entire term, rather than for an annual period.

The following table sets forth our reconciliation of total revenues to billings for the periods shown:

This says that billings is equal to revenue plus the change in deferred revenue.  Billings is a popular metric in SaaS companies, though often imputed by financial analysts, because revenue is both damped and seen as a dependent variable.  Billings is seen as the purer (and more volatile) metric and thus seen by many as a superior way to gauge the health of the business.

For Jive, from a growth perspective, this doesn’t strike me as particularly good news since billings, which were growing 99% in 2010, are growing at 59% in 1H11, compared to revenue which is growing at 76%.

Now we’re on page 8.  Happily the next 20 pages present a series of valid yet unsurprisingly risk factors that I won’t review here, though here are a few interesting extracted tidbits:

  • The company had 358 employees as of 6/30/11.
  • They plan to move from third-party hosted data centers to their own data centers.
  • Subscription agreements typically range from 12 to 36 months.
  • They do about 20% of sales internationally.
  • They recently completed three acquisitions (FiltrboxProximal,  OffiSync).
  • There is a 180 day lockup period following the offering.

Skipping out of page-by-page mode, let me pull some other highlights from the tome.

  • There were 44M shares outstanding on 6/30/11, excluding 15M options, 0.8M in the options pool, 0.9M shares subject to repurchase.  That, by my math, means ~59M fully-diluted shares outstanding after the offering.
  • Despite having $44.6M in cash on 6/30/11, they had a working capital deficit of $15.9M.
  • The Jive Engage Platform was launched in February 2007.  In August 2007, the company raised its first external capital.
  • The Jive Engage Platform had 590 customers as of 12/31/10, up from 468 at 12/31/09.  There were 635 as of 6/30/11.
  • The dollar-based renewal rate, excluding upsell, for 1H11 for transactions > $50K was over 90%.  Including upsell, the renewal rate was 125%.
  • Public cloud deployments represented 59% of product revenues in 1H11.
  • The way they recognize revenue probably hurts the professional services performance because they must ratably take the PSO revenue while taking the cost up-front.

One thing soon-to-be-public companies need to do is gradually align the common stock valuation with the expected IPO price to avoid a huge run-up in the weeks preceding the IPO.  Gone are the days where you can join a startup, get a rock-bottom strike price on your options, and then IPO at ten times that a few weeks later.  Companies now periodically do section 409a valuations in order to establish a third-party value for the common stock.  Here’s a chart of those valuations for Jive, smoothed to a line, over the 18 months prior to the filing.

This little nugget was interesting on two levels, bolded:

The core application of the Jive Engage Platform is written in Java and is optimized for usability, performance and overall user experience. It is designed to be deployed in the production environments of our customers, runs on top of the Linux operating system and supports multiple databases, including Microsoft SQL Server, MySQL, Oracle and PostgreSQL. The core application is augmented by externally hosted web-based services such as a recommendation service and an analytics service. We have made investments in consolidating these services on a Hadoop-based platform.

First, it seems to suggest that it’s not written for the cloud / multi-tenancy (which, if true, would be surprising) and second, it suggests that they are investigating Hadoop which is cool (and not surprising).

More tidbits:

  • 105 people in sales as of 6/30/11
  • 122 people in R&D as of 6/30/11
  • Executives Tony Zingale (CEO), Bryan LeBlanc (CFO), John McCracken (Sales), and Robert Brown (Client Services) all worked at Mercury Interactive.  The latter three were brought in after Zingale was made a director (10/07) but well before he was appointed CEO (2/10).
  • Zingale beneficially owns 7.5% of the company pre-offering.  This is high by Silicon Valley standards, but he’s a big-fish CEO in a small-pond company.
  • Sequoia Capital beneficially owns 36% of the company.  Kleiner Perkins owns 14%.
  • I think Sequoia contributed $37M of the $57M total VC raised (though I can only easily see $22M in the S-1).
  • If that’s right, and if Sequoia eventually exits Jive at a $1B market cap, that means they will, on average across funds, get a ~10x return on their investment.  $2B would give them 20x.

What’s left of my brain has officially melted at page F-11.  If I dig back in and find anything interesting, I’ll update the post.  Meantime, if you have questions or comments, please let me know.

As a final strategic comment, I’d say that investors should consider the possibility of an increased level of competition from Salesforce.com, given their massive push around “the social enterprise” at Dreamforce 11.

Goldman Sachs Smacks Software Stocks

See this story on SeekingAlpha (which might consider renaming itself SeekingShelter), entitled Goldman Slaps Most Software Stocks.

Excerpt on aggregate spending:

The worst of the IT-spending slowdown likely remains in front of us, as we start the clock on slashed 2009 budgets. We forecast 0 percent revenue growth for our group, below consensus at 5 percent, and 1 percent earnings growth, below Street at 2 percent.

The most interesting point addressed is whether the downturn will drive consumers to open source (i.e., nominally “free”) software:

There has been much discussion in the blogosphere about open source software and how it will see a surge of adoption do to its lower cost. Goldman quite rightly says this will not be the case. I have written that CIOs will hunker down and stick with the tried and true (which is not open source in most large-sized enterprises) and Goldman is in agreement, seeing a consolidation of functionality with big, established vendors and a moving away from the concept of seeking best-of-breed point solutions regardless of vendor.

On sectors:

So in terms of non-defense technology companies we are batting two for two: Neither hardware not software will be spared over the next several quarters as the outlook remains dim for both.

Happily for Mark Logic we have a large defense / intelligence business, which I believe will offer shelter from the storm. And, as I’ve argued before, for non-advertising-driven media companies, I believe that GDP growth (or lack thereof) is a second-order effect relative to seismic changes driven by the Internet and Google to which MarkLogic helps them respond.

Thoughts on Category Creation and Information Access Platforms [Revised]

[Revised 8/2/08; still working on cleaning up this consciousness stream.]

Back in the old days, it seemed easy to create a category in software. Look at the database market, for example:

  • IBM invents the relational DBMS (RDBMS) category
  • Oracle, Ingres, and Informix enter in a largely undifferentiated way, though Informix eventually drifts towards the low-end/cheap segment
  • Sybase creates the derivative category of high-performance OLTP RDBMS.
  • Arbor re-christens the failed multi-dimensional DBMS as the OLAP Server
  • Tandem creates the non-stop RDBMS with its superb fault tolerance
  • Illustra launches the universal DBMS and is quickly acquired by Informix
  • Sybase launches the bitmap-indexed DBMS with SybaseIQ
  • Teradata launches the data-warehouse DBMS category

And you can find just as many examples outside database-land.

  • ASK defines the manufacturing resource planning (MRP) category
  • SAP hijacks MRP, redefines it as ERP, and goes on to become the world’s largest applications software company
  • PeopleSoft invents the HRMS category
  • Gartner Group’s Howard Dresner invents the business intelligence (BI) category, re-christening and re-framing what was formally known as DSS or EIS.
  • Siebel pioneers the sales force automation (SFA) category
  • Scopus pioneers call center automation (CCA)
  • Companies like Rubric pioneer enterprise marketing automation (EMA)
  • Siebel, through acquisition, coalesces SFA, CCA, and EMA into a single category called customer relationship management (CRM)
  • Oracle and SAP work to coalesce CRM back into ERP. Such is the ebb and flow of categories.

(And I could go on and on — BPM, KM, CMS, WCM, ECM, LMS, DRM, SCM, PLM, ETL, DI, EII — but I think I’ll stop here with the initials list.)

People are still creating categories today, and sometimes it looks easy. Uber-categories have been quite popular in the past decade as people have focused on different ways of developing and delivering software:

  • SaaS as an uber-category has worked well, with a variety offerings in various SaaS sub-categories (e.g., Salesforce, NetSuite)
  • Appliances have done pretty much the same thing — i.e., offering an appliance alternative for a wide variety of existing categories (e.g., a data warehouse appliance a la Netezza)
  • Open source has also done the same thing — again serving as a different flavor/dimension for a wide variety of largely existing software categories.

Only a few genuinely new categories have emerged, virtualization being the most obvious example. (Though you could argue that virtualization is itself an uber-category covering storage virtualization, server virtualization, et cetera.)

Companies are still working to carve new categories, particularly in the database market:

Sometimes vendors and/or the analysts who cover them try to impose either a straight name change (e.g., from MD-DBMS to OLAP) or a strategic shift (e.g., from BI to analytic applications) in category. Sometimes they’re just bored. Sometimes a vendor’s trying to redefine the market in line with its strengths. Sometimes an analyst is trying to make his/her mark on the industry and earn the coveted “father/mother of [category name],” much as Howard Dresner successfully did with BI.

BI got bored with its name several times during my tenure at Business Objects. At one point both the analysts and Informatica were trying to re-dub the category “analytic applications” in an attempt to get a fresh name and raise the abstraction level from tools to applications. Informatica nearly died on that hill.

Later, analysts tried to redefine the category, dubbing it corporate performance management (CPM), and arguing that business intelligence needed to link with financial planning systems. While knowing actuals is good, knowing actuals compared to the plan is better, and using actuals to drive the future plan better still. Cognos nearly tripped over itself repositioning around the CPM, ultimately acquiring Adaytum, which in turn lead to SRC’s eventual acquisition by Business Objects.

In an art-imitates-life sort of way, one wonders if the analysts predicted a move in the market or provoked it? My chips are on the latter.

This stream-of-consciousness is a long way of winding up to a single question: are enterprise search vendors successfully repositioning themselves as “information access platforms” or not?

Background: the enterprise-search-related vendors (e.g., Fast/Microsoft, Endeca) and search/content analysts who cover them are in the midst of an attempted category repositioning:

  • The word “enterprise search” is now seemingly dead, having been contaminated by the Google Appliance. When a shark gets in the water, all the fish jump out.
  • The word “information” is increasingly being used as a unifying term to describe both data and content (aka, unstructured data)
  • Enterprise search vendors are increasingly calling themselves “information access platforms” (though not generally abbreviated as IAP, I will do so here for brevity).

For example, consider Endeca’s corporate boilerplate:

Endeca’s innovative information access software that helps people explore, analyze, and understand complex information, guiding them to unexpected insights and better dec
isions. The Endeca Information Access Platform, built around a new class of access-optimized database, powers applications that combine the ease of searching and browsing with the analytical power of business intelligence.

I have a number of concerns on and related to this attempted shift:

  • The important thing about categories is that they exist in the mind of the customer. Analysts and vendors can try to put them there — but they have to stick. In my mind, IAP is not sticking. I have never heard a customer say: “I need to go out and get an IAP.”
  • I do, however, believe that “information” might well stick as an overall term, meaning both data and content (aka, structured and unstructured data).
  • It is not clear to me why someone who desires a unified platform for “information” would turn to a search vendor. Search engines were designed as read-only indexes to help people find documents containing tokens; hardly ideal as an application development platform.
  • In my estimation, someone managing “special” data should turn to a database vendor. While databases have classically not handled “special” data well, databases were designed as application platforms, and there is a whole new class of specialized databases emerging for handling various “special” types of data.
  • While I think a unified platform is a dandy vision, I think no one is close to delivering a unified platform that handles all types of data equally well. Bolting Lucene and MySQL together isn’t a platform. Relational databases still do a poor job with both content and many types of data (e.g., sparse, hierarchical, or semi-structured). XML servers (like MarkLogic) handle XML brilliantly, but need work before they can match RDBMSs at classical relational data.
  • I believe that someone who needs a crawl-and-index the intranet value proposition should use the Google Appliance; so I think the search vendors are correct in their desire to flee, I don’t think that “information access platform” is a good refuge.

Overall, my chips remain on the don’t come line for the attempted category repositioning from “enterprise search” to “information access platform.” You can find my stack on the come line for the emerging “special-purpose database” category and “XML servers” as an instance of them.