• Part 1 is an overview of Kudu technology.
• Part 2 is a lengthy dive into how Kudu writes and reads data.
• Part 3 (this post) is a brief speculation as to Kudu’s eventual market significance.

Combined with Impala, Kudu is (among other things) an attempt to build a no-apologies analytic DBMS (DataBase Management System) into Hadoop. My reactions to that start:

• It’s plausible; just not soon. What I mean by that is:
  • Success will, at best, be years away. Please keep that in mind as you read this otherwise optimistic post.
  • Nothing jumps out at me to say “This will never work!”
  • Unlike when it introduced Impala — or when I used to argue with Jeff Hammerbacher pre-Impala — this time Cloudera seems to have reasonable expectations as to how hard the project is.
• There’s huge opportunity if it works.
  • The analytic RDBMS vendors are beatable. Teradata has a great track record of keeping its product state-of-the-art, but it likes high prices. Most other strong analytic RDBMS products were sold to (or originated by) behemoth companies that seem confused about how to proceed.
  • RDBMS-first analytic platforms didn’t do as well as I hoped. That leaves a big gap for Hadoop.

I’ll expand on that last point. Analytics is no longer just about fast queries on raw or simply-aggregated data. Data transformation is getting ever more complex — that’s true in general, and it’s specifically true in the case of transformations that need to happen in human real time. Predictive models now often get rescored on every click. Sometimes, they even get retrained at short intervals. And while data reduction in the sense of “event extraction from high-volume streams” isn’t that a big deal yet in commercial apps featuring machine-generated data — if growth trends continue as much of us expect, it’s only a matter of time before that changes.

Of course, this is all a bullish argument for Spark (or Flink, if I’m wrong to dismiss its chances as a Spark competitor). But it also all requires strong low-latency analytic data underpinnings, and I suspect that several kinds of data subsystem will prosper. I expect Kudu-supported Hadoop/Spark to be a strong contender for that role, along with the best of the old-school analytic RDBMS, Tachyon-supported Spark, one or more contenders from the Hana/MemSQL crowd (i.e., memory-centric RDBMS that purport to be good at analytics and transactions alike), and of course also whatever Cloudera’s strongest competitor(s) choose to back.

• Part 1 is an overview of Kudu technology.
• Part 2 (this post) is a lengthy dive into how Kudu writes and reads data.
• Part 3 is a brief speculation as to Kudu’s eventual market significance.

Let’s talk in more detail about how Kudu stores data.

• As previously noted, inserts land in an in-memory row store, which is periodically flushed to the column store on disk. Queries are federated between these two stores. Vertica taught us to call these the WOS (Write-Optimized Store) and ROS (Read-Optimized Store) respectively, and I’ll use that terminology here.
• Part of the ROS is actually another in-memory store, aka the DeltaMemStore, where updates and deletes land before being applied to the DiskRowSets. These stores are managed separately for each DiskRowSet. DeltaMemStores are checked at query time to confirm whether what’s in the persistent store is actually up to date.
• A major design goal for Kudu is that compaction should never block – nor greatly slow — other work. In support of that:
  • Compaction is done, server-by-server, via a low-priority but otherwise always-on background process.
  • There is a configurable maximum to how big a compaction process can be — more precisely, the limit is to how much data the process can work on at once. The current default figure = 128 MB, which is 4X the size of a DiskRowSet.
  • When done, Kudu runs a little optimization to figure out which 128 MB to compact next.
• Every tablet has its own write-ahead log.
  • This creates a practical limitation on the number of tablets …
  • … because each tablet is causing its own stream of writes to “disk” …
  • … but it’s only a limitation if your “disk” really is all spinning disk …
  • … because multiple simultaneous streams work great with solid-state memory.
• Log retention is configurable, typically the greater of 5 minutes or 128 MB.
• Metadata is cached in RAM. Therefore:
  • ALTER TABLE kinds of operations that can be done by metadata changes only — i.e. adding/dropping/renaming columns — can be instantaneous.
  • To keep from being screwed up by this, the WOS maintains a column that labels rows by which schema version they were created under. I immediately called this MSCC — Multi-Schema Concurrency Control — and Todd Lipcon agreed.
• Durability, as usual, boils down to “Wait until a quorum has done the writes”, with a configurable option as to what constitutes a “write”.
  • Servers write to their respective write-ahead logs, then acknowledge having done so.
  • If it isn’t too much of a potential bottleneck — e.g. if persistence is on flash — the acknowledgements may wait until the log has been fsynced to persistent storage.
• There’s a “thick” client library which, among other things, knows enough about the partitioning scheme to go straight to the correct node(s) on a cluster.

Leaving aside the ever-popular possibilities of:

• Cluster-wide (or larger) equipment outages
• Bugs

the main failure scenario for Kudu is:

• The leader version of a tablet (within its replica) set goes down.
• A new leader is elected.
• The workload is such that the client didn’t notice and adapt to the error on its own.

Todd says that Kudu’s MTTR (Mean Time To Recovery) for write availability tests internally at 1-2 seconds in such cases, and shouldn’t really depend upon cluster size.

Beyond that, I had some difficulties understanding details of the Kudu write path(s). An email exchange ensued, and Todd kindly permitted me to post some of his own words (edited by me for clarification and format).

Every tablet has its own in-memory store for inserts (MemRowSet). From a read/write path perspective, every tablet is an entirely independent entity, with its own MemRowSet, rowsets, etc. Basically the flow is:

• The client wants to make a write (i.e. an insert/update/delete), which has a primary key.
  • The client applies the partitioning algorithm to determine which tablet that key belongs in.
  • The information about which tablets cover which key ranges (or hash buckets) is held in the master. (But since it is cached by the clients, this is usually a local operation.)
  • It sends the operation to the “leader” replica of the correct tablet (batched along with any other writes that are targeted to the same tablet).

• Once the write reaches the tablet leader:
  • The leader enqueues the write to its own WAL (Write-Ahead Log) and also enqueues it to be sent to the “follower” replicas.
  • Once it has reached a majority of the WALs (i.e. 2/3 when the replication factor = 3), the write is considered “replicated”. That is to say, it’s durable and would always be rolled forward, even if the leader crashed at this point.
  • Only now do we enter the “storage” part of the system, where we start worrying about MemRowSets vs DeltaMemStores, etc.

Put another way, there is a fairly clean architectural separation into three main subsystems:

• Metadata and partitioning (map from a primary key to a tablet, figure out which servers host that tablet).
• Consensus replication (given a write operation, ensure that it is durably logged and replicated to a majority of nodes, so that even if we crash, everyone will agree whether it should be applied or not).
• Tablet storage (now that we’ve decided a write is agreed upon across replicas, actually apply it to the database storage).

These three areas of the code are separated as much as possible — for example, once we’re in the “tablet storage” code, it has no idea that there might be other tablets. Similarly, the replication and partitioning code don’t know much anything about MemRowSets, etc – that’s entirely within the tablet layer.

As for reading — the challenge isn’t in the actual retrieval of the data so much as in figuring out where to retrieve it from. What I mean by that is:

• Data will always be either in memory or in a persistent column store. So I/O speed will rarely be a problem.
• Rather, the challenge to Kudu’s data retrieval architecture is finding the relevant record(s) in the first place, which is slightly more complicated than in some other systems. For upon being told the requested primary key, Kudu still has to:
  • Find the correct tablet(s).
  • Find the record(s) on the (rather large) tablet(s).
  • Check various in-memory stores as well.

The “check in multiple places” problem doesn’t seem to be of much concern, because:

• All that needs to be checked is the primary key column.
• The on-disk data is front-ended by Bloom filters.
• The cases in which a Bloom filter returns a false positive are generally the same busy ones where the key column is likely to be cached in RAM.
• Cloudera just assumes that checking a few different stores in RAM isn’t going to be a major performance issue.

When it comes to searching the tablets themselves:

• Kudu tablets feature data skipping among DiskRowSets, based on value ranges for the primary key.
• The whole point of compaction is to make the data skipping effective.

Finally, Kudu pays a write-time (or compaction-time) cost to boost retrieval speeds from inside a particular DiskRowSet, by creating something that Todd called an “ordinal index” but agreed with me would be better called something like “ordinal offset” or “offset index”. Whatever it’s called, it’s an index that tells you the number of rows you would need to scan before getting the one you want, thus allowing you to retrieve (except for the cost of an index probe) at array speeds.

• Part 1 (this post) is an overview of Kudu technology.
• Part 2 is a lengthy dive into how Kudu writes and reads data.
• Part 3 is a brief speculation as to Kudu’s eventual market significance.

Cloudera is introducing a new open source project, Kudu,* which from Cloudera’s standpoint is meant to eventually become the single best underpinning for analytics on the Hadoop stack. I’ve spent multiple hours discussing Kudu with Cloudera, mainly with Todd Lipcon. Any errors are of course entirely mine.

*Like the impala, the kudu is a kind of antelope. I knew that, because I enjoy word games. What I didn’t know — and which is germane to the naming choice — is that the kudu has stripes.

For starters:

• Kudu is an alternative to HDFS (Hadoop Distributed File System), or to HBase.
• Kudu is meant to be the underpinning for Impala, Spark and other analytic frameworks or engines.
• Kudu is not meant for OLTP (OnLine Transaction Processing), at least in any foreseeable release. For example:
  • Kudu doesn’t support multi-row transactions.
  • There are no active efforts to front-end Kudu with an engine that is fast at single-row queries.
  • Kudu is rather columnar, except for transitory in-memory stores.
• Kudu’s core design points are that it should:
  • Accept data very quickly.
  • Immediately make that data available for analytics.
• More specifically, Kudu is meant to accept, along with slower forms of input:
  • Lots of fast random writes, e.g. of web interactions.
  • Streams, viewed as a succession of inserts.
  • Updates and inserts alike.
• The core “real-time” use cases for which Kudu is designed are, unsurprisingly:
  • Low-latency business intelligence.
  • Predictive model scoring.
• Kudu is designed to work fine with spinning disk, and indeed has been tested to date mainly on disk-only nodes. Even so, Kudu’s architecture is optimized for the assumption that there will be at least some flash on the node.
• Kudu is designed primarily to support relational/SQL processing. However, Kudu also has a nested-data roadmap, which of course starts with supporting the analogous capabilities in Impala.

Also, it might help clarify Kudu’s status and positioning if I add:

• Kudu is in its early days — heading out to open source and beta now, with maturity still quite a way off. Many obviously important features haven’t been added yet.
• Kudu is expected to be run with a replication factor (tunable, usually =3). Replication is via the Raft protocol.
• Kudu and HDFS can run on the same nodes. If they do, they are almost entirely separate from each other, with the main exception being some primitive workload management to help them share resources.
• Permanent advantages of older alternatives over Kudu are expected to include:
  • Legacy. Older, tuned systems may work better over some HDFS formats than over Kudu.
  • Pure batch updates. Preparing data for immediate access has overhead.
  • Ultra-high update volumes. Kudu doesn’t have a roadmap to completely catch up in write speeds with NoSQL or in-memory SQL DBMS.

Kudu’s data organization story starts:

• Storage is right on the server (this is of course also the usual case for HDFS).
• On any one server, Kudu data is broken up into a number of “tablets”, typically 10-100 tablets per node.
• Inserts arrive into something called a MemRowSet and are soon flushed to something called a DiskRowSet. Much as in Vertica:
  • MemRowSets are managed by an in-memory row store.
  • DiskRowSets are managed by a persistent column store.*
  • In essence, queries are internally federated between the in-memory and persistent stores.
• Each DiskRowSet contains a separate file for each column in the table.
• DiskRowSets are tunable in size. 32 MB currently seems like the optimal figure.
• Page size default is 256K, but can be dropped as low as 4K.
• DiskRowSets feature columnar compression, with a variety of standard techniques.
  • All compression choices are specific to a particular DiskRowSet.
  • So, in the case of dictionary/token compression, is the dictionary.
  • Thus, data is decompressed before being operated on by a query processor.
  • Also, selected columns or an entire DiskRowSet can be block-compressed.
• Tables and DiskRowSets do not expose any kind of RowID. Rather, tables have primary keys in the usual RDBMS way.
• Kudu can partition data in the three usual ways: randomly, by range or by hash.
• Kudu does not (yet) have a slick and well-tested way to broadcast-replicated a small table across all nodes.

*I presume there are a few ways in which Kudu’s efficiency or overhead seem more row-store-like than columnar. Still, Kudu seems to meet the basic requirements to be called a columnar system.

• The IT trade press is increasingly understaffed, and hence press releases can in some cases serve as a draft of the article you hope folks will write. (Whether articles of that form have any influence or credibility is a whole other matter.)
• Press releases are collateral support for whatever higher-class outreach you do.

So my current opinion is:

• You should write press releases primarily for a general online audience, but …
• … secondarily for the reporters at whom they are ostensibly aimed.

That fits with my general view that press releases:

• Should tell your story.
• Should read well.
• Shouldn’t do anything to actively embarrass you.

That brings me to the subject of this post: third-party press release quotes. For starters, I think the following are pretty obvious:

• Quotes in press releases serve two purposes:
  • Given how much space they usually take up, they had better be part of the general story-telling.
  • Further, at least some press release quotes are meant to show up directly as quotes in the resulting articles.
• To succeed in the latter role, they should be things that:
  • Reporters will want to quote.
  • If quoted, you want their readers to read.
• Quotes from non-company people (i.e. third parties) serve two general functions:
  • That the quote is there at all shows that this person likes you well enough to give you a quote.
  • Ideally, the quote also credibly persuades the readers of one or more beneficial-to-you specific points.

Generally, press release quotes are terrible. The core reason is over-ambition — press release writers take every point they want made (credible or otherwise), and stuff them into quotes. The resulting camels — i.e. horses designed by committees — come out clumsy, unnatural-sounding, and not at all persuasive. This applies both to company-personnel quotes and to quotes that are crafted by the company for third parties to lend their names to.

Third-party quotes face further problems:

• If they’re written by companies for outsiders, and if this fools anybody, it’s probably unethical. Also — who’s it going to fool?
• They can stress your relationships, in several ways.
  • You may cash in favors to get them. (This problem is only partly ameliorated by third parties’ desire for the attention of being quoted.)
  • If you get a quote wrong, you can have problems with an important supporter.
  • Occasionally, even a correct quote can lead to a backlash.

That said, third-party quotes are worth having. So here are some observations and best practices.

• There are three good ways to place third-party quotes in a release.
  • Recall that a primary purpose of the quote is to demonstrate that the third party has something nice to say about you. So place third-party quotes in the press release flow where your main point is “Third parties like us!”
  • If the third party endorses something specific about your technology, place the quote where you’re discussing specifics.
  • There’s always room to tack extra quotes onto the end of a release.
• Rather than trying to put your overwrought words into their mouths, encourage third parties to write their own quotes.
  • If quotes are more natural … well, then they’ll likely sound more natural. That’s good for credibility.
  • If they say “I think this is great because X” — well, that’s great! The support for X is a nice bonus, and adds credibility to the overall message “Third parties like us and you should like us too!”
• If you must write a quote for your third party, try not to make it turgid. If it must be turgid, at least keep it short. You should try to impose as little turgidity on your readers as possible.
• If your user gives a quote on how they use your product, that’s likely to be a good outcome, especially considering the alternatives. Specifics are better than generalities, just as in user-success-story collateral.

Finally, I need to write down my own quote policies, and this post is as good a place as any.

• Please never try to write a quote for me.
• Don’t even suggest edits to the quotes I write, except in spelling or grammar. If you don’t like what I wrote, get a quote from somebody else. My feelings won’t be hurt.
• Please show me a late draft of the overall release for my final approval. I don’t need to agree with everything in it, but I don’t want to seem to be endorsing your claims if I actually plan to slam them.
• As for attribution:
  • The standard is Curt Monash, president of Monash Research and editor of DBMS 2. You’re also welcome to use my middle initial — “A” — and/or my PhD if you choose.
  • Please include live links; every bit of SEO helps. If you’d rather use a link to a specific DBMS 2 that post you like, be my guest.

• My client Rocana is the renamed ScalingData, where Rocana is meant to signify ROot Cause ANAlysis.
• Rocana was founded by Omer Trajman, who I’ve referenced numerous times in the past, and who I gather is a former boss of …
• … cofounder Eric Sammer.
• Rocana recently told me it had 35 people.
• Rocana has a very small number of quite large customers.

Rocana portrays itself as offering next-generation IT operations monitoring software. As you might expect, this has two main use cases:

• Actual operations — figuring out exactly what isn’t working, ASAP.
• Security.

Rocana’s differentiation claims boil down to fast and accurate anomaly detection on large amounts of log data, including but not limited to:

• The sort of network data you’d generally think of — “everything” except packet-inspection stuff.
• Firewall output.
• Database server logs.
• Point-of-sale data (at a retailer).
• “Application data”, whatever that means. (Edit: See Tom Yates’ clarifying comment below.)

In line with segment leader Splunk’s pricing, data volumes in this area tend to be described in terms of new data/day. Rocana seems to start around 3 TB/day, which not coincidentally is a range that would generally be thought of as:

• Challenging for Splunk, and for the budgets of Splunk customers.
• Not a big problem for well-implemented Hadoop.

And so part of Rocana’s pitch, familiar to followers of analytic RDBMS and Hadoop alike, is “We keep and use all your data, unlike the legacy guys who make you throw some of it away up front.”

Since Rocana wants you to keep all your data, 3 TB/day is about 1 PB/year.

But really, that’s just saying that Rocana is an analytic stack built on Hadoop, using Hadoop for what people correctly think it’s well-suited for, done by guys who know a lot about Hadoop.

The cooler side of Rocana, to my tastes, is the actual analytics. Truth be told, I find almost any well thought out event-series analytics story cool. It’s an area much less mature than relational business intelligence, and accordingly with much more scope for innovation. On the visualization side, crucial aspects start:

• Charting over time (duh).
• Comparing widely disparate time intervals (e.g., current vs. historical/baseline).
• Whichever good features from relational BI apply to your use case as well.

Other important elements may be more data- or application-specific — and the fact that I don’t have a long list of particulars illustrates just how immature the area really is.

Even cooler is Rocana’s integration of predictive modeling and BI, about which I previously remarked:

The idea goes something like this:

• Suppose we have lots of logs about lots of things. Machine learning can help:
  • Notice what’s an anomaly.
  • Group together things that seem to be experiencing similar anomalies.
• That can inform a BI-plus interface for a human to figure out what is happening.

Makes sense to me.

So far as I can tell, predictive modeling is used to notice aberrant data (raw or derived). This is quickly used to define a subset of data to drill down to (e.g., certain kinds of information from certain machines in a certain period of time). Event-series BI/visualization then lets you see the flows that led to the aberrant result, which was any luck will allow you to find the exact place where the data first goes wrong. And that, one hopes, is something that the ops guys can quickly fix.

I think similar approaches could make sense in numerous application segments.

Related links

• Rocana’s Hadoop stack presumably includes both Kafka and Spark Streaming.
• Back when Splunk still answered my email, I wrote about its inverted-list data management architecture.
• Ursula Le Guin’s debut novel Rocannon’s World has nothing to do with this post (although it does start with a really lousy bit of temporal analysis ). I just like making allusions to her work.

It seems fair to say that in most cases:

• Cassandra is adopted for operational applications, specifically ones with requirements for extreme uptime and/or extreme write speed. (Of course, it should also be the case that NoSQL data structures are a good fit.)
• Spark, including SparkSQL, and Solr are seen primarily as ways to navigate or analyze the resulting data.

Those generalities, in my opinion, make good technical sense. Even so, there are some edge cases or counterexamples, such as:

• DataStax trumpets British Gas‘ plans collecting a lot of sensor data and immediately offering it up for analysis.*
• Safeway uses Cassandra for a mobile part of its loyalty program, scoring customers and pushing coupons at them.
• A large title insurance company uses Cassandra-plus-Solr to manage a whole lot of documents.

*And so a gas company is doing lightweight analysis on boiler temperatures, which it regards as hot data.

While most of the specifics are different, I’d say similar things about MongoDB, Cassandra, or any other NoSQL DBMS that comes to mind:

• You can get any kind of data into them very fast; indeed, that’s a central part of what they were designed for.
• In the general case, getting it back out for low-latency analytics is problematic …
• … but there’s an increasing list of exceptions.

For DataStax Enterprise, exceptions start:

• Formally, you can do almost anything in at least one of Solr or Spark/SparkSQL. So if volumes are low enough, you’re fine. In particular, Spark offers the potential to do many things at in-memory speeds.
• Between Spark, the new functions, and general scripting, there are several ways to do low-latency aggregations. This can lead to “twinkling dashboards”.*
• DataStax is alert to the need to stream data into Cassandra.
  • That’s central to the NoSQL expectation of ingesting internet data very quickly.
  • Kafka, Storm and Spark Streaming all seem to be in the mix.
• Solr over Cassandra has a searchable RAM buffer, which can give the effect of real-time text indexing within a second or so of ingest.

*As much as I love the “twinkling dashboard” term — it reminds me of my stock analyst days — it does raise some concerns. In many use cases, human real-time BI should be closely integrated with the more historical kind.

DataStax Enterprise:

• Is based on Cassandra 2.1.
• Will probably never include Cassandra 2.2, waiting instead for …
• ….Cassandra 3.0, which will feature a storage engine rewrite …
• … and will surely include Cassandra 2.2 features of note.

This connects to what I said previously in that Cassandra 2.2 adds some analytic features, specifically in the area of user-defined functions. Notes on Cassandra 2.2 UDFs include:

• These are functions — not libraries, a programming language, or anything like that.
• The “user-defined” moniker notwithstanding, the capability has been used to implement COUNT, SUM, AVG, MAX and so on.
• You are meant to run user-defined functions on data in a single Cassandra partition; run them across partitions at your own performance risk.

And finally, some general tidbits:

• A while ago, Apple said it had >75,000 Cassandra nodes. The figure is surely bigger now.
• There are at least several other petabyte range Cassandra installations, and several more half-petabyte ones.
• Netflix is not one of those. Instead, it has many 10s of smaller Cassandra clusters.
• There are Cassandra users with >1 million reads+writes per second.

Finally a couple of random notes:

• One of the text search use cases for Solr/Cassandra is to — in one query — get at information that originated in multiple places, e.g. for reasons of time period or geography. (I hear this about text search across lots of database technologies, relational and non-relational alike.)
• As big a change as Cassandra 3.0 will be, it will not require that you take down your applications for an upgrade. That hasn’t been necessary since Cassandra 0.7.

• >2,000 named customers, the vast majority of which are unique organizations who do business with MongoDB directly.
• ~75,000 users of MongoDB Cloud Manager.
• Estimated ~1/4 million production users of MongoDB total.

Also >530 staff, and I think that number is a little out of date.

MongoDB lacks many capabilities RDBMS users take for granted. MongoDB 3.2, which I gather is slated for early November, narrows that gap, but only by a little. Features include:

• Some JOIN capabilities.
  • Specifically, these are left outer joins, so they’re for lookup but not for filtering.
  • JOINs are not restricted to specific shards of data …
  • … but do benefit from data co-location when it occurs.
• A BI connector. Think of this as a MongoDB-to- SQL translator. Using this does require somebody to go in and map JSON schemas and relational tables to each other. Once that’s done, the flow is:
  • Basic SQL comes in.
  • Filters and GroupBys are pushed down to MongoDB. A result set … well, it results.
  • The result set is formatted into a table and returned to the system — for example a business intelligence tool — that sent the SQL.
• Database-side document validation, in the form of field-specific rules that combine into a single expression against which to check a document.
  • This is fairly simple stuff — no dependencies among fields in the same document, let alone foreign key relationships.
  • MongoDB argues, persuasively, that this simplicity makes it unlikely to recreate the spaghetti code maintenance nightmare that was 1990s stored procedures.
  • MongoDB concedes that, for performance, it will ordinarily be a good idea to still do your validation on the client side.
  • MongoDB points out that enforcement can be either strict (throw errors) or relaxed (just note invalid documents to a log). The latter option is what makes it possible to install this feature without breaking your running system.

There’s also a closed-source database introspection tool coming, currently codenamed MongoDB Scout. 

• The name will change, in part because if you try to search on that name you’ll probably find an unrelated Scout.
• Scout samples data, runs stats, and all that stuff.
• Scout is referred to as a “schema introspection” tool, but I’m not sure why; schema introspection sounds more like a feature or architectural necessity than an actual product.

As for storage engines:

• WiredTiger, which was the biggest deal in MongoDB 3.0, will become the default in 3.2. I continue to think analogies to InnoDB are reasonably appropriate.
• An in-memory storage engine option was also announced with MongoDB 3.0. Now there’s a totally different in-memory option. However, details were not available at posting time. Stay tuned.
• Yet another MongoDB storage engine, based on or akin to WiredTiger, will do encryption. Presumably, overhead will be acceptably low. Key management and all that will be handled by usual-suspect third parties.

Finally — most data management vendors brag to me about how important their text search option is, although I’m not necessarily persuaded. MongoDB does have built-in text search, of course, of which I can say:

• It’s a good old-fashioned TF/IDF algorithm. (Text Frequency/Inverse Document Frequency.)
• About the fanciest stuff they do is tokenization and stemming. (In a text search context, tokenization amounts to the identification of word boundaries and the like. Stemming is noticing that alternate forms of the same word really are the same thing.)

This level of technology was easy to get in the 1990s. One thing that’s changed in the intervening decades, however, is that text search commonly supports more languages. MongoDB offers stemming in 8 or 9 languages for free, plus a paid option via Basis for other languages yet.

Related links

• BI for NoSQL (March, 2015)
• Uninterrupted DBMS operation (September, 2012)

Self-introductions occur at several different lengths, including but not limited to:

• Short enough to fit in the first paragraph of a press release without obscuring the main point.
• Short enough to fit into an elevator ride — — or in the boilerplate at the end of a press release.
• The first few paragraphs of the About and/or Product sections of your website.
• The beginning of a typical slide-aided presentation.

Usually, it makes sense to view the shorter ones as being abbreviations of the longer, more complete forms.

Your short summaries are necessarily incomplete, and even a bit inaccurate, for nothing concise is ever precise. Even so, there are a few questions you should almost always anticipate and answer — for if you don’t address them, then the rest of the conversation can’t really happen. The Big Three questions are:

• What do you offer? If somebody doesn’t know what you’re talking about, then there’s no conversation to be had.
• Why should somebody care? If there’s no reason to care … then there’s no reason to care.
• Why should I believe you might be better than the alternatives? If there’s no reason to believe you, then there’s no reason to listen.

The template I usually recommend for self-introductions is:

• The world has changed.
  • This sets up everything else you’ll say …
  • … but it doesn’t persuade on its own, so you should get through it very quickly.
  • Usually, it would insult your listeners’ knowledge to “educate” them as to how the world has changed; …
  • .. instead, you should briefly indicate which well-known changes are relevant to understanding your story.
  • Ideally, the change is more specific than “Big Data … Internet of Things … interactive speeds … competitive necessity … profit”.
• There’s a big new problem or need, which we address. This is crucial.
  • It starts the “What do we offer?” discussion.
  • It answers “Why should somebody care?”
  • It also starts the “We’re better” part of the story.
  • Popular problem types these days include chaos, confusion, and mess.
  • Popular need types include:
    • More personalized and targeted customer communication.
    • Gaining control over chaos, confusion and mess.
• We make _____________ (“What we offer.”) I’ve written about this area quite a bit, for example in my posts on naming, positioning and messaging to multiple audiences.
• It does ____________ (“Why you should care.”) If your story is strong, this should have several parts.
  • I illustrated why that’s so when I wrote about the marketing of both performance and productivity.
  • A common pattern these days is:
    • Helps make some aspect of IT easier and more efficient …
    • … and in doing so also makes IT more secure, which to many customers is the primary use case.
• Our technological uniqueness is ___________ . (“Why you should believe us.”) This goes all the way back to my first post on the layered messaging model, in 2008. If you don’t say what’s unique about you, you sound like everybody else.
• Social proof that we’re the right folks to do this includes_________ . (The other part of “Why you should believe us.”)
  • Social proof can be customers, investors, or just people’s resumes.
  • This part doesn’t have to go at the end of the pitch, and in an “elevator conversation” or presentation it probably wouldn’t. But wherever it goes, it’s somewhat outside the rest of the logical flow.

  The closest I’ve come to posting about this template in the past was perhaps when I wrote about how to start a presentation. I recommend that post as a companion to this one.

  Some of the classical stumbling blocks in all this are addressed in other posts, e.g. the previously cited on naming and multiple audiences. So let’s finish by tackling one I haven’t emphasized before, namely the tension between messaging for senior/strategic-level and more junior/tactical-level IT.

  From the standpoint of a prospect, you likely want your product to both:

  • Be worth a lot of money. This is best achieved by having a “big picture”, “strategic” story, of the kind that interests CIOs.
  • Have enthusiastic and convincing internal advocates. This is best achieved by offering concrete, hard-to-deny benefits in specific use cases.

  Let’s reframe that challenge a bit by noting:

  • You’re probably anyway following a land-and-expand sales strategy. Most vendors of “horizontal” or “platform” technology have been, for decades.
  • Your self-introduction (especially to prospects) needs to be good at teeing up the “land” part.
  • It should also be useful (especially when introducing you to possible investors, employees or senior IT executives) in teeing up the “expand”.

  The obvious approach is to have your “land” story be an obvious subset of your “land and expand” one. Revisiting the template, I’d say:

  • The world has changed is mainly about the broader story.
  • The big new problem or need is really big. Even particular examples are rather big. This includes the example(s) you’re addressing with your initial offerings.
  • You make something with a category name that reflects your broader vision.
  • It does specific things that are useful right now. Later it will do much more.
  • Your technological uniqueness supports the entire story.
  • Your social proof can usually be spun to support all levels of your story alike.

• Multi-model database management has been around for decades. Marketers who say otherwise are being ridiculous.
• Thus, “multi-model”-centric marketing is the last refuge of the incompetent. Vendors who say “We have a great DBMS, and by the way it’s multi-model (now/too)” are being smart. Vendors who say “You need a multi-model DBMS, and that’s the reason you should buy from us” are being pathetic.
• Multi-logical-model data management and multi-latency-assumption data management are greatly intertwined.

Before supporting my claims directly, let me note that this is one of those posts that grew out of a Twitter conversation. The first round went:

Merv Adrian: 2 kinds of multimodel from DBMS vendors: multi-model DBMSs and multimodel portfolios. The latter create more complexity, not less.

Me: “Owned by the same vendor” does not imply “well integrated”. Indeed, not a single example is coming to mind.

Merv: We are clearly in violent agreement on that one.

Around the same time I suggested that Intersystems Cache’ was the last significant object-oriented DBMS, only to get the pushback that they were “multi-model” as well. That led to some reasonable-sounding justification — although the buzzwords of course aren’t from me — namely:

Caché supports #SQL, #NoSQL. Interchange across tables, hierarchical, document storage.

Along the way, I was reminded that some of the marketing claims around “multi-model” are absurd. For example, at the time I am writing this, the Wikipedia article on “multi-model database” claims that “The first multi-model database was OrientDB, created in 2010…” In fact, however, by the definitions used in that article, multi-model DBMS date back to the 1980s, when relational functionality was grafted onto pre-relational systems such as TOTAL and IDMS.

What’s more, since the 1990s, multi-model functionality has been downright common, specifically in major products such as Oracle, DB2 and Informix, not to mention PostgreSQL. (But not so much Microsoft or Sybase.) Indeed, there was significant SQL standards work done around datatype extensions, especially in the contexts of SQL/MM and SQL3.

I tackled this all in 2013, when I argued:

• One database to rule them all systems aren’t very realistic, but even so, …
• … single-model systems will become increasingly obsolete.

Developments since then have been in line with my thoughts. For example, Spark added DataFrames, which promise substantial data model flexibility for Spark use cases, but more mature products have progressed in a more deliberate way.

What’s new in all this is a growing desire to re-integrate short-request and analytic processing — hence Gartner’s new-ish buzzword of HTAP (Hybrid Transactional/Analytic Processing). The more sensible reasons for this trend are:

• Operational applications have always needed to accept immediate writes. (Losing data is bad.)
• Operational applications have always needed to serve small query result sets based on the freshest data.(If you write something into a database, you might need to immediately retrieve it to finish the business operation.)
• It is increasingly common for predictive decisions to be made at similar speeds. (That’s what recommenders and personalizers do.) Ideally, such decisions can be based on fresh and historical data alike.
• The long-standing desire for business intelligence to operate on super-fresh data is, increasingly, making sense, as we get ever more stuff to monitor. However …
• … most such analysis should look at historical data as well.
• Streaming technology is supplying ever more fresh data.

But here’s the catch — the best models for writing data are the worst for reading it, and vice-versa, because you want to write data as a lightly-structured document or log, but read it from a Ted-Codd-approved RDBMS or MOLAP system. And if you don’t have the time to move data among multiple stores, then you want one store to do a decent job of imitating both kinds of architecture. The interesting new developments in multi-model data management will largely be focused on that need.

Related links

• The two-policemen joke seems ever more relevant.
• My April, 2015 post on indexing technology reminds us that one DBMS can do multiple things.
• Back in 2009 integrating OLTP and data warehousing was clearly a bad idea.

In many cases, installing an application allows enterprises to collect the underlying data, electronically, for the first time ever. In other cases the app organizes data that was already there in some previous form. Either way, applications tend to greatly change the way data is managed and stored.

My first group of examples don’t assume nice relational DBMS underpinnings, for several reasons:

• Before the mid/late-1980s rise in relational DBMS, application vendors commonly assumed their apps would run over flat files, e.g. IBM VSAM. In a file-based world, there were a lot of data silos.
• Some software vendors didn’t even assume IBM mainframe underpinnings. That could make their DBMS situation even worse.
• One of the early application categories to get started, bill of materials planning, was well-suited for pre-relational systems.

I don’t know how many applications there now are in SAP’s core suite, but it’s many 100s at least. Back when I became an analyst in 1981, however, few application software companies had as many as 10. Indeed, industry leader MSA ran an advertising campaign around its “Big Eight” apps, as wordplay on what was then the phrase describing the major accounting firms,* namely:

• General ledger
• Accounts payable
• Accounts receivable
• Purchasing
• Inventory
• Fixed assets
• Payroll
• Human resources

*Since reduced greatly in count, because of mergers and Enron.

But even those few applications, running in batch rather than interactive mode, weren’t integrated. Indeed, Payables, Inventory and Purchasing each had their own vendor files. A major feature in those days was the “Three-Way Match” between those applications, and I learned to challenge “our apps are integrated” claims with the question “How many vendor files do you have?” Not until the mid-1980s did I confidently expect the answer “One”.

Similarly, a major differentiator for retail banking application suites was when they had a halfway decent “customer information file”, pulling data from customer silos for some kind of very elementary customer-interaction functionality.

In yet another example — if you stipulate that data dispersed among multiple organizations is the biggest mess of all, then it’s easy to understand why Ordernet made such a large business out of connecting them.

And then there was Marcam, which I’ve cited before as having one of the most significantly patented technologies in the history of the software industry, and more generally the category of process manufacturing support. Manufacturing applications — starting with bill of material planning — generally assumed that discrete objects were manufactured out of discrete parts. But what if you made batches and flows of (generally liquid) stuff — orange juice, steel (which is molten in its early stages), or gasoline? Complications could ensue including:

• There would be multiple “byproducts” and “coproducts” — think of all the different outputs of an oil refinery.
• Inputs would be of varying quality and nature. One tanker of oil is not exactly like the next, and same goes for different truckloads of oranges.

Despite manufacturing applications generally being quite a big business already, their data models were lousy for process manufacturing, and hence different vendors were able to shine.

I’ve always supposed that SAP was early in process manufacturing, because I know a lot of its early traction came in the chemical and pharmaceutical industries — certainly in the US, and I presume in its German origins as well. But I don’t recall whether that supposition is actually correct.

Eventually — and I’d time this to early in the relational era — applications became pretty good at elementary database design. Still, room for significant differentiation remained. One example was central to the rise of PeopleSoft — it’s software was very good at rearranging hierarchies, especially of employee/management, and that database flexibility (instantiated via PeopleTools) had strong application benefits.* Another and more important example was SAP weaving business process/workflow into the heart of its applications.

*PeopleSoft was also early with a client/server architecture, but I count that as more of a UI advantage than anything else, even if a lot of database programming was technically involved. For one thing, early client/server programming, with its heavy dependence on server-side triggers and also on fat-client code — well, I think of it as a possible origin for the Flying Spaghetti Monster idea.

Finally, there’s my favorite example of all. By the early 1990s, MCI had risen to challenge AT&Ts dominance of the long-distance phone call market. It developed and spent massive national advertising dollars on its “Friends and Family” program, wherein you got significant discounts for calls to a named group of people. Amazingly, MCI rolled out the program, including doing application development, within 10 weeks of conceiving the plan. AT&T, which got hammered by the initiative, wanted to respond quickly — but couldn’t. This was a huge triumph based in large part on software agility, and database management was surely a non-trivial part of the whole.

To a first approximation, one would expect operational data to be rather clean. After all, it drives and/or records business transactions. So if something goes awry, the result can be lost money, disappointed customers, or worse, and those are outcomes to be strenuously avoided. Up to a point, that’s indeed true, at least at businesses large enough to be properly automated. (Unlike, for example — — mine.)

Even so, operational data has some canonical problems. First, it could be inaccurate; somebody can just misspell or otherwise botch an entry. Further, there are multiple ways data can be unreachable, typically because it’s:

• Inconsistent, in which case humans might not know how to look it up and database JOINs might fail.
• Unintegrated, in which case one application might not be able to use data that another happily maintains. (This is the classic data silo problem.)

Inconsistency can take multiple forms, including: 

• Variant names.
• Variant spellings.
• Variant data structures (not to mention datatypes, formats, etc.).

Addressing the first two is the province of master data management (MDM), and also of the same data cleaning technologies that might help with outright errors. Addressing the third is the province of other data integration technology, which also may be what’s needed to break down the barriers between data silos.

So far I’ve been assuming that data is neatly arranged in fields in some kind of database. But suppose it’s in documents or videos or something? Well, then there’s a needed step of data enhancement; even when that’s done, further data integration issues are likely to be present.

All of the above issues occur with analytic data too. In some cases it probably makes sense not to fix them until the data is shipped over for analysis. In other cases, it should be fixed earlier, but isn’t. And in hybrid cases, data is explicitly shipped to an operational data warehouse where the problems are presumably fixed.

Further, some problems are much greater in their analytic guise. Harmonization and integration among data silos are likely to be much more intense. (What is one table for analytic purposes might be many different ones operationally, for reasons that might span geography, time period, or application legacy.) Addressing those issues is the province of data integration technologies old and new. Also, data transformation and enhancement are likely to be much bigger deals in the analytic sphere, in part because of poly-structured internet data. Many Hadoop and now Spark use cases address exactly those needs.

Let’s now consider missing data. In operational cases, there are three main kinds of missing data:

• Missing values, as a special case of inaccuracy.
• Data that was only collected over certain time periods, as a special case of changing data structure.
• Data that hasn’t been derived yet, as the main case of a need for data enhancement.

All of those cases can ripple through to cause analytic headaches. But for certain inherently analytic data sets — e.g. a weblog or similar stream — the problem can be even worse. The data source might stop functioning, or might change the format in which it transmits; but with no immediate operations compromised, it might take a while to even notice. I don’t know of any technology that does a good, simple job of addressing these problems, but I am advising one startup that plans to try.

Further analytics-mainly data messes can be found in three broad areas:

• Problems caused by new or changing data sources hit much faster in analytics than in operations, because analytics draws on a greater variety of data.
• Event recognition, in which most of a super-high-volume stream is discarded while the “good stuff” is kept, is more commonly a problem in analytics than in pure operations. (That said, it may arise on the boundary of operations and analytics, namely in “real-time” monitoring.
• Analytics has major problems with data scavenger hunts, in which business analysts and data scientists don’t know what data is available for them to examine.
  

That last area is the domain of a lot of analytics innovation. In particular:

• It’s central to the dubious Gartner concept of a Logical Data Warehouse, and to the more modest logical data layers I advocate as alternative.
• It’s been part of BI since the introduction of Business Objects’ “semantic layer”. (See, for example, my recent post on Zoomdata.)
• It’s a big part of the story of startups such as Alation or Tamr.
• In a failed effort, it was part of Greenplum’s pitch some years back, as an aspect of the “enterprise data cloud”.
• It led to some of the earliest differentiated features at Gooddata.
• It’s implicit in the some BI collaboration stories, in some BI/search integration, and in ClearStory’s “Data You May Like”.

Finally, suppose we return to the case of operational data, assumed to be accurately stored in fielded databases, with sufficient data integration technologies in place. There’s still a whole other kind of possible mess than those I cited above — applications may not be doing a good job of understanding and using it. I could write a whole series of posts on that subject alone … but it’s going slowly. So I’ll leave that subject area for another time.

• We help people be more effective. (Productivity)
• We help computers run faster. (Performance)
• We help people be more effective at making computers run faster. (Performance via productivity, or vice-versa)

My views on the marketing of productivity benefits are similar to what I wrote about the marketing of performance: 

There are three kinds of benefits performance can offer:

• It can allow you to do things more simply and/or cost-effectively (e.g., with less hardware or less tuning).
• It can allow you to do things better. …
• It can allow you to do something that would be impractical otherwise (usually because of expense).

These benefits are easily confused.

… “simpler” is a benefit that should not be overlooked. It speaks to all of operational cost, operational risk, and resource availability. …

Overall, the most fruitful performance-related business-benefit positioning usually straddles “better” and “impractical without us.” For the richer or more sophisticated buyers, you’re “better”. For the laggards, you’re taking them by the hand and leading them to the Promised Land.

By way of contrast, I am skeptical of positioning better performance purely as a matter of cost savings.

Most of the same reasoning applies to productivity/personal effectiveness benefits as well. In particular:

• Doing the heretofore impossible is often a good thing …
• … but of course it wasn’t really impossible before, just impractical or too expensive.
• If the customer has already determined that something is important enough to invest in doing, then doing it better is likely to be appealing.
• Simplicity is great. People like to hear that their jobs will be easier, with reductions in scut work and/or in opportunities for failure.
• Cost savings are trickier. People don’t always like technology that eliminates jobs — especially their own.

Beyond that, selling and marketing software that helps people do their jobs better depends on:

• Who is directly helped by the software?
• Who cares about that?

For much enterprise application software, the answers are something like:

• Low-status workers do their jobs better with the help of the software.
• Their bosses like that idea, and hence buy the stuff.

That can work fine. But when users have enough status and agency to resist, things get trickier; if the stuff doesn’t get used, then it earns the label of “shelfware”, and further sales can be hard.

In particular, software that helps somebody invest effort so that somebody else can later do their job more easily can be problematic, because the users who are supposed to put in the initial effort keep finding reasons not to bother. Examples of categories that were sunk by this problem include (and these overlap):

• Knowledge management.
• Various things that help programmers avoid incurring technical debt.
• Various kinds of taxonomy builders.

Sales force automation (SFA) software is a particularly instructive case:

• When SFA was a tool for salespeople to fill out forms so that they could be managed more effectively, purchases were enthusiastic but adoption disappointed.
• When tools were added to makes the salespeople actually sell better, the SFA category prospered, and indeed laid the groundwork for CRM (Customer Relationship Management).

In contrast, software that obviously helps techies do their own jobs better can be very easy to market — just offer free trials, get the word out somehow, and let the prospects do the rest. Back in the 1980s, this made for a very nice telesales business model, at a time when most software had to be sold in person. And that was before the internet era; now, free downloads and trials are everywhere.

Of course, I’m making some assumptions here about the offering, specifically that:

• Price looks good against value.
• Price looks good against users’ available budgets.
• Costs and risks of adoption, other than price, are minimal.

But if those things are the case, the software business can be remarkably simple.

So to a first approximation:

• Software that helps people be more effective is an appealing proposition, but …
• … only if actual users are likely to cooperate.

Thus, user buy-in is central to productivity software success.

If you think about it, I just made the case — again — that product management is central to sales and marketing success. That could be a subject for a whole other post …

Related links

• I sometimes list three views of the essence of IT. Two of the three are about productivity.

Despite the cautionary evidence, I’m going to argue that SaaS and software can and often should be combined. The “should” part is pretty obvious, with reasons that start:

• Some customers are clearly better off with SaaS. (E.g., for simplicity.)
• Some customers are clearly better off with on-premises software. (E.g., to protect data privacy.)
• On-premises customers want to know they have a path to the cloud.
• Off-premises customers want the possibility of leaving their SaaS vendor’s servers.
• SaaS can be great for testing, learning or otherwise adopting software that will eventually be operated in-house.
• Marketing and sales efforts for SaaS and packaged versions can be synergistic.
  • The basic value proposition, competitive differentiation, etc. should be the same, irrespective of delivery details.
  • In some cases, SaaS can be the lower cost/lower commitment option, while packaged product can be the high end or upsell.
  • An ideal sales force has both inside/low-end and bag-carrying/high-end components.

But the “how” of combining SaaS and traditional software is harder. Let’s review why. 

Why it is hard for one vendor to succeed at both packaged software and SaaS?

SaaS and packaged software have quite different development priorities and processes. SaaS vendors deliver and support software that:

• Runs on a single technology stack.
• Is run only at one or a small number of physical locations.
• Is run only in one or a small number of historical versions.
• May be upgraded multiple times per month.
• Can be assumed to be operated by employees of the SaaS company.
• Needs, for customer acquisition and retention reasons, to be very easy for users to learn.

But traditional packaged software:

• Runs on technology the customer provides and supports, at the location of the customer’s choice.
• Runs in whichever versions customers have not yet upgraded from.
• Should — to preserve the sanity of all concerned — have only have a few releases per year.
• Is likely to be operated by less knowledgeable or focused staff than a SaaS vendor enjoys.
• Can sometimes afford more of an end-user learning curve than SaaS.

Thus, in most cases:

• Traditional software creates greater support and compatibility burdens than SaaS does.
• SaaS and on-premises software have very different release cycles.
• SaaS should be easier for end-users than most traditional software, but …
• … traditional software should be easier to administer than SaaS.

Further — although this is one difference that I think has at times been overemphasized — SaaS vendors would prefer to operate truly multi-tenant versions of their software, while enterprises less often have that need.

How this hard thing could be done

Most of the major problems with combining SaaS and packaged software efforts can be summarized in two words — defocused development. Even if the features are substantially identical, SaaS is developed on different schedules and for different platform stacks than packaged software is.

So can we design an approach to minimize that problem? I think yes. In simplest terms, I suggest:

• A main development organization focused almost purely on SaaS.
• A separate unit adapting the SaaS code for on-premises customers, with changes to the SaaS offering being concentrated in three aspects:
  • Release cadence.
  • Platform support.
  • Administration features, which are returned to the SaaS group for its own optional use.

Certain restrictions would need to be placed on the main development unit. Above all, because the SaaS version will be continually “thrown over the wall” to the sibling packaged-product group, code must be modular and documentation must be useful. The standard excuses — valid or otherwise — for compromising on these virtues cannot be tolerated.

There is one other potentially annoying gotcha. Hopefully, the SaaS group uses third-party products and lots of them; that’s commonly better than reinventing the wheel. But in this plan they need to use ones that are also available for third-party/OEM kinds of licensing.

My thoughts on release cadence start:

• There should be a simple, predictable release cycle:
  • N releases per year, for N approximately = 4.
  • Strong efforts to adhere to a predictable release schedule.
• A reasonable expectation is that what’s shipped and supported for on-premises use is 6-9 months behind what’s running on the SaaS service. 3-6 months would be harder to achieve.

The effect would be that on-premises software would lag SaaS features to a predictable and bounded extent.

As for platform support:

• You have to stand ready to install and support whatever is needed. (E.g., in the conversation that triggered this post, the list started with Hadoop, Spark, and Tachyon.)
• You have to adapt to customers’ own reasonably-current installations of needed components (but help them upgrade if they’re way out of date).
• Writing connectors is OK. Outright porting from your main stack to another may be unwise.
• Yes, this is all likely to involve significant professional services, at least to start with, because different customers will require different degrees of adaptation.

That last point is key. The primary SaaS offering can be standard, in the usual way. But the secondary business — on-premises software — is inherently services-heavy. Fortunately, packaged software and professional services can be successfully combined.

And with that I’ll just stop and reiterate my conclusion:

It may be advisable to offer both SaaS and services-heavy packaged software as two options for substantially the same product line.

Related link

• Point #4 of my VC overlord post is relevant  — and Point #3 even more so.

• I dislike the term “big data” but like the Vs that define it — Volume, Velocity, Variety and Variability.
• Though I think it’s silly, I understand why BI innovators flee from the term “business intelligence” (they’re afraid of not sounding new).

So when my clients at Zoomdata told me that they’re in the business of providing “the fastest visual analytics for big data”, I understood their choice, but rolled my eyes anyway. And then I immediately started to check how their strategy actually plays against the “big data” Vs.

It turns out that:

• Zoomdata does its processing server-side, which allows for load-balancing and scale-out. Scale-out and claims of great query speed are relevant when data is of high volume.
• Zoomdata depends heavily on Spark.
• Zoomdata’s UI assumes data can be a mix of historical and streaming, and that if looking at streaming data you might want to also check history. This addresses velocity.
• Zoomdata assumes data can be in a variety of data stores, including:
  • Relational (operational RDBMS, analytic RDBMS, or SQL-on-Hadoop).
  • Files (generic HDFS — Hadoop Distributed File System or S3).*
  • NoSQL (MongoDB and HBase were mentioned).
  • Search (Elasticsearch was mentioned among others).
• Zoomdata also tries to detect data variability.
• Zoomdata is OEM/embedding-friendly.

*The HDFS/S3 aspect seems to be a major part of Zoomdata’s current story.

Core aspects of Zoomdata’s technical strategy include: 

• QlikView/Tableau-style navigation, at least up to a point. (I hope that vendors with a much longer track record have more nuances in their UIs.)
• Suitable UI for wholly or partially “real-time” data. In particular:
  • Time is an easy dimension to get along the X-axis.
  • You can select current or historical regions from the same graph, aka “data rewind”.
• Federated query with some predicate pushdown, aka “data fusion”.
  • Data filtering and some GroupBys are pushed down to the underlying data stores — SQL or NoSQL — when it makes sense.*
  • Pushing down joins (assuming that both sides of the join are from the same data store) is a roadmap item.
• Approximate query results, aka “data sharpening”. Zoomdata simulates high-speed query by first serving you approximate query results, ala Datameer.
• Spark to finish up queries. Anything that isn’t pushed down to the underlying data store is probably happening in Spark DataFrames.
• Spark for other kinds of calculations.

*Apparently it doesn’t make sense in some major operational/general-purpose — as opposed to analytic — RDBMS. From those systems, Zoomdata may actually extract and pre-cube data.

The technology story for “data sharpening” starts:

• Zoomdata more-or-less samples the underlying data, and returns a result just for the sample. Since this is a small query, it resolves quickly.
• More precisely, there’s a sequence of approximations, with results based on ever larger samples, until eventually the whole query is answered.
• Zoomdata has a couple of roadmap items for making these approximations more accurate:
  • The integration of BlinkDB with Spark will hopefully result in actual error bars for the approximations.
  • Zoomdata is working itself on how to avoid sample skew.

The point of data sharpening, besides simply giving immediate gratification, is that hopefully the results for even a small sample will be enough for the user to determine:

• Where in particular she wants to drill down.
• Whether she asked the right query in the first place.

I like this early drilldown story for a couple of reasons:

• I think it matches the way a lot of people work. First you get to the query of the right general structure; then you refine the parameters.
• It’s good for exact-results performance too. Most of what otherwise might have been a long-running query may not need to happen at all.

Aka “Honey, I shrunk the query!”

Zoomdata’s query execution strategy depends heavily on doing lots of “micro-queries” and unioning their result sets. In particular:

• Data sharpening relies on a bunch of data-subset queries of increasing size.
• Streaming/”real-time” BI is built from a bunch of sub-queries restricted to small time slices each.

Even for not-so-micro queries, Zoomdata may find itself doing a lot of unioning, as data from different time periods may be in different stores.

Architectural choices in support of all this include:

• Zoomdata ships with Spark, but can and probably in most cases should be pointed at an external Spark cluster instead. One point is that Zoomdata itself scales by user count, while the Spark cluster scales by data volume.
• Zoomdata uses MongoDB off to the side as a metadata store. Except for what’s in that store, Zoomdata seems to be able to load balance rather statelessly. And Zoomdata doesn’t think that the MongoDB store is a bottleneck either.
• Zoomdata uses Docker.
• Zoomdata is starting to use Mesos.

When a young company has good ideas, it’s natural to wonder how established or mature this all is. Well:

• Zoomdata has 86 employees.
• Zoomdata has (production) customers, success stories, and so on, but can’t yet talk fluently about many production use cases.
• If we recall that companies don’t always get to do (all) their own positioning, it’s fair to say that Zoomdata started out as “Cloudera’s cheap-option BI buddy”, but I don’t think that’s an accurate characterization as this point.
• Zoomdata, like almost all young companies in the history of BI, favors a “land-and-expand” adoption strategy. Indeed …
• … Zoomdata tells prospects it wants to be an additional BI provider to them, rather than rip-and-replacement.

As for technological maturity:

• Zoomdata’s view of data seems essentially tabular, notwithstanding its facility with streams and NoSQL. It doesn’t seem to have tackled much in the way of event series analytics yet.
• One of Zoomdata’s success stories is iPad-centric. (Salesperson visits prospect and shows her an informative chart; prospect opens wallet; ka-ching.) So I presume mobile BI is working.
• Zoomdata is comfortable handling 10s of millions of rows of data, may be strained when handling 100s of millions of rows, and has been tested in-house up to 1 billion rows. But that’s data that lands in Spark. The underlying data being filtered can be much larger, and Zoomdata indeed cites one example of a >40 TB Impala database.
• When I asked about concurrency, Zoomdata told me of in-house testing, not actual production users.
• Zoomdata’s list when asked what they don’t do (except through partners, of which they have a bunch) was:
  • Data wrangling.
  • ETL (Extract/Transform/Load).
  • Data transformation. (In a market segment with a lot of Hadoop and Spark, that’s not really redundant with the previous bullet point.)
  • Data cataloguing, ala Alation or Tamr.
  • Machine learning.

Related link

• I wrote about multiple kinds of approximate query result capabilities, Zoomdata-like or otherwise, back in July, 2012.

• Money, in forms such as:
  • Ordinary licenses or sales.
  • Custom product development.
  • Equity investment.
• Credibility,* to audiences including:
  • Press and analysts.
  • Angel/seed/venture investors.
  • Potential customers who are just reading/hearing about you.
  • Potential customers who do detailed reference checks.
• Product feedback and advice.*

*Confusingly, both credibility and product feedback are sometimes called “validation”.

Questions of money are of course heavily influenced by how complete your product or service is. In particular:

• It is common not to get paid until your product works and is either in late beta or else early general availability.
• It is common for early customers to want big discounts even when they do pay you.
• Somewhat contradictorily, it is also not uncommon to get a lot of payment from your earliest customer(s). Reasons include:
  • They’re getting technology that is, at the moment, unique.
  • You’re willing to somewhat tailor the product to their needs, and to provide very high levels of attention and service.

Equity investment by your early customers and partners is problematic. In particular:

• The person in charge of buying from you is not likely to also be in charge of investing. So this really is two separate deals.
• When it comes to corporate governance, customers can be very biased shareholders.

And it probably is equity we’re talking about. Corporations with audited financials will be happier with straight equity (preferred or otherwise) than with convertible debt, because they’ll have fewer accounting headaches as to whether they can carry it on their balance sheets at full value.

Sometimes early customers will want to have exclusive rights to your technology, so that they may have a competitive advantage. My thoughts on that include: 

• Any such exclusive should be very narrow in scope and limited in time.
• It absolutely should be limited to a named set of potential customers, specified at contract time.
• I’d offer an exclusive against 2 named enterprises for 1 year.
• I’d settle for an exclusive against 3 named enterprises for 2 years.
• If I gave an exclusive, I’d definitely want payment of my development costs for industry-specific features I’m then limited from selling elsewhere in the industry.

And of course, be very skeptical about deals that give your customers any kind of intellectual property rights. One exception: Some kind of code escrow in case you go out of business could protect them without really hurting you.

As for credibility, the most important thing I have to say is in the form of a tip: Negotiate commitments to marketing and sales support up front. Examples could include:

• Permissions for PR up front. At a minimum you want permission for full disclosure that they are a customer (logo, mentions at your discretion, etc.), including in a press release.
• Permissions for a “success story” (document and/or video).
• Willingness to take reference calls.

The key point here is that big companies are much more generous with such permissions at deal time than later on, where they have many people who can say “No”. That principle is also why you need to negotiate any sales exclusives precisely up front, rather than leaving it open to later determination of who they do or don’t think are their important competitors.

Note: “Success stories” are often “We bought this because we expect great benefits after we deploy it” rather than “We bought this and have experienced great benefits already”.  As an analyst, I hate that. But for obvious reasons, it’s the form you can get earlier, and especially in the context suggested by this post, time can be of the essence.

As for product feedback and advice, I actually wrote about that in a post about startups last month. So in conclusion I’ll just quote myself here:

• Design partners have multiple roles.
• They give you guidance on what features to build in.
• Hopefully, they test your product.
• Hopefully, they use and/or buy your product, providing validation to investors, press and others.
• It is helpful if design partners are representative of a sufficiently large set of customers with sufficiently great willingness to pay.
• Very prestigious design partners are … prestigious. That’s useful. But some of them, such as elite internet companies, may not truly be representative of any kind of paying constituency.
• Even beyond that, elite companies sometimes have needs that more ordinary organizations do not.
• The right number of design partners is >= 2. A single partner will lead you down blind alleys, due to their unique needs and, even more, to the needs that they don’t have which many other organizations however do.
• Inherently, you’re working with a design partner over (at a minimum) many months. Their opinions may change over that time. (For one thing, their relevant personnel may change.) So a sale at the end of the process is unfortunately not assured.

This post can be construed as fitting into my “not-very-organized series” about the keys to success. In particular, it draws on my July, 2014 post about judging opportunities.

The product plan

A start-up product idea needs to satisfy multiple criteria. Awkwardly, they’re rather contradictory to each other.

• It should be obviously appealing to sufficiently many customers, and be worth sufficiently much money to them.
• It should be something the startup can do with very few resources …
• … but which much larger potential competitors cannot.

That usually means that the idea:

• Should be based on an architecture that is anti-strategic to incumbent players …
• … but which fits customers’ technology strategies just fine.

Criticisms I’ve made repeatedly of specific ideas include: 

• Yes, that’s a nice feature, but it doesn’t outweigh all the features in which you’ll be behind …
• … except, perhaps, to a niche market too small to matter.
• You’ve just declared that your target market is outfits that don’t want to pay established vendors’ prices, and indeed want everything to be FOSS (Free Open-Source Software). How much money do you think they’ll be willing to give you?
• To deliver the benefits you’re claiming, the features you’re proposing aren’t nearly strong enough.
• The incumbents can close the feature gap with you long before you establish any kind of traction — should it be the case than any customers actually care.

In essence, what’s needed is favorable-seeming answers on my strategic worksheet even for your 1st release, plus confidence that there will be 2nd, 3rd, 4th and further acts shortly thereafter. A product idea that can be regarded as meeting that test generally has the characteristics:

• It can be added to an existing technology environment without great disruption.
• (This generally overlaps greatly with the first point.) It doesn’t add much perceived risk. If it doesn’t work out, the customers can sadly stop using it, having wasted time and money, but not being otherwise worse off for having tried.
• It solves an acknowledged problem that is hard for existing technologies to deal with.
• There are lots of great features that can later be added to it. These features will probably also be unique in the marketplace when they first come out.
• In general, it will be hard for alternative products to achieve anything close to feature parity, due to some combination of:
  • Architecture.
  • The brilliance of the start-up’s engineers.
  • Intellectual property protection. (This one generally arises mainly in hardware businesses, since software patents are largely useless.)

Getting to a good plan

Entrepreneurs with interesting ideas can be overoptimistic about how the market will react. Market watchers like me stock ample supplies of chilled water in response. Pivoting to a more sensible plan can be aided by the same folks who trashed your first one, but beyond that you need direct interaction with potential users.

But please don’t fall iton the trap of, having abandoned your overoptimism about what a simplistic product will accomplish, becoming equally overoptimistic about how easily you can build out the more sophisticated new product concept you pivot to.

Gathering resources

The toughest thing about starting a company is neither good ideas nor good general execution. Rather, it’s gathering scarce resources of sufficient quality, in areas such as:

• Personnel.
• Investment.
• Attention from early design partners.

If you can’t recruit and lead a team of great engineers, you probably shouldn’t be starting a company, so let’s move on to “business” and financial concerns. Deadly yet common mistakes include:

• Being too willing to rely on businesspeople whose knowledge and experience don’t match your situation, or who are simply mediocre.
• Being too eager to please skeptical investors.

The latter has two sub-categories, by the way:

• Actual investors.
• Imaginary investors whose preferences who think you know because you’ve read or heard about them as a group.

As for the former, I outlined what kinds of experience may be most relevant in the post linked up top, when I wrote:

• High-end engineering skills (architecture, management, etc.) often draw on accumulated experience with similar technologies.
• Strategic marketing skills often draw on accumulated experience in similar markets.
• Sales skills often draw on accumulated experience with products at a similar level of maturity and customer impact.
• General entrepreneurial flair often transfers well from one kind of business to another.

Finally, my thoughts on design partners start:

• Design partners have multiple roles.
  • They give you guidance on what features to build in.
  • Hopefully, they test your product.
  • Hopefully, they use and/or buy your product, providing validation to investors, press and others.
• It is helpful if design partners are representative of a sufficiently large set of customers with sufficiently great willingness to pay.
• Very prestigious design partners are … prestigious. That’s useful. But some of them, such as elite internet companies, may not truly be representative of any kind of paying constituency.
• Even beyond that, elite companies sometimes have needs that more ordinary organizations do not.
• The right number of design partners is >= 2. A single partner will lead you down blind alleys, due to their unique needs and, even more, to the needs that they don’t have which many other organizations however do.
• Inherently, you’re working with a design partner over (at a minimum) many months. Their opinions may change over that time. (For one thing, their relevant personnel may change.) So a sale at the end of the process is unfortunately not assured.

With that, I’m conveniently out of space, so I’ll duck the subject of just how these essential resources might actually be gathered. But please stay tuned.

• Internet juggernauts — Google, Facebook and their younger siblings.
• The cheapskates at Amazon.
• Brogrammers.
• Etc.

Most of that is at the internet companies, although there are exceptions — any kind of companies can have ping-pong tables, beanbag chairs, and a bunch of dogs* running around the office.

*I mean literal pooches, not bad products. WibiData used to even post headshots of the dogs on their employee page.

But there was a time, before the internet era, when similar things could be said of enterprise IT companies. The biggest fuss about culture was perhaps made among the more buttoned-down crowd, including IBM (most famously), MSA (the example that made me think of this subject), and EDS (who commissioned a Ken Follett book about themselves). They are all I have space for in this post. But there were also the beginnings of recognizable Silicon Valley start-up culture, and I hope to discuss that in the future.

The dignity crowd

I still chuckle when I see an IBMer in a company-issued polo shirt, because there was a time when IBM had a strict dress code of conservative suits and ties. Along with that went never drinking alcohol in a customer setting, in an era when boozy business meals were the norm. The point of all these rules, I think, was twofold. First, IBM wanted to be seen as a trusted, dignified adviser to customer organizations. Second, IBM generally wanted some kind of rules so that the behemoth corporation would be a team.

And IBM was more than a collection of people; it was an organization. Employees with 20+ year service might average one city-to-city move per year. (Hence the joke that IBM stood for I’ve Been Moved.) But whoever was involved with your account — if your systems stopped working, IBM would do whatever it took to get you back running fast. And a large fraction of IBM’s sales effort was spreading FUD (Fear, Uncertainty and Doubt) as to whether rival vendors would care for customers equally well.

EDS (Electronic Data Systems, founded by Ross Perot) fancied itself as a cross between IBM and the US military. Even computer operators had to be clean-shaven and wear jacket and tie. A large fraction of hires were military veterans,* and an extreme “Do it now! No excuses for failure will be accepted!” ethos flowed through the company. 

*Indeed, generic college recruiting didn’t get serious until about a decade after EDS was founded; at least, that’s what Bob Sharpe once told me.

The extreme example, of course, is when two EDS employees were arrested and held by the failing Iranian government. Aspects of the story that I believe (some of which were documented in the Ken Follett book On Wings of Eagles) include:

• A dozen EDS employees, some of them then or later quite senior, volunteered to go into Iran and get their colleagues out.
• A requirement for being accepted onto that team was that you had killed somebody in combat.
• The leader was a well-known retired US officer, known for other prisoner extraction attempts.
• The team carefully rehearsed an armed extraction.
• The team infiltrated Iran, and discovered that their plan wouldn’t at all work. So they waited until the revolutionaries broke open the large Tehran jail in which the executives were being held. (Indeed, it is claimed a local Iranian EDS employee started the relevant riot.)
• (Part of) the team collected the execs and drove to Turkey.
• The team leader killed or persuasively threatened to kill (stories about that part differ) a recalcitrant Turkish border guard as they were entering the country.

That culture dissipated in the 1980s, after EDS was acquired by General Motors.

MSA (Management Science America, led by John Imlay) copied IBM’s demeanor, to the point that MSA’s logo was in the exact style of IBM’s — three letters compounded of many thin horizontal stripes. One exception: MSAers weren’t required to forgo alcohol. MSA print ads tended to feature senior and middle executives — many of whom I knew personally — “standing behind” the product. More on MSA is at the link above.

All three of my example companies had a strong interest in employee training.

• IBM is said to have trained lots of folks in IT, many of whom would leave the company and be IBM customers thereafter. (That’s sort of like McKinsey consulting today.)
• IBM also had a sales training program that included teaching you how to read upside down (in those days there were informative papers on people’s desks). My former colleague Jon Fram told me that part. Less clear is whether they taught lip-reading as well.
• EDS had a famed technical training program, somewhat modeled on military boot camp.
• MSA piggybacked on the EDS training program as best it could, as well as on sales training programs at other firms.

What does this all boil down to? Well, what these three examples share is:

• Strong focus on teamwork, and on whatever employee training, encouragement or uniformity seemed helpful in fostering it.
• Strong engagement with customers on the “Let us take care of your success” level.

That all worked well up through, say, the mid-1980s, when IT was still mysterious to most people, and post-WW2 business norms were widely accepted. Then it didn’t hold up as well in the face of more aggressive upstarts such as Microsoft and Oracle. But those are stories for another time.

• John was a jolly huckster. Of the entrepreneurs I’ve known with manic amounts of sales energy, he’s the one I can least imagine saying or doing an unkind thing. Indeed, the breathless bit about John’s “kindheartedness” toward the end of this 2010 article doesn’t ring too false.*
• John wasn’t technically the founder of MSA, but he might as well have been. (Analogy: Steve Case at AOL.) When he got there, it was Management Science Atlanta, a failing hodgepodge of tiny businesses. He turned into Management Science America, a leading software company of its day, and the one that “should” have become what SAP is today.
• My 2006 post on MSA Memories has 90 comments, the vast majority of which are from former MSA employees who loved working there.

*Not as persuasive is the story about the missed chance to buy Microsoft in 1981. I knew a LOT of folks at MSA in the 1980s, and nobody ever mentioned that. Also, the story has an obviously wrong Microsoft fat (what city it was in).

John Imlay was a showman, best known for giving speeches with live animals or other dramatic visual aids, as per this short 1994 New York Times interview. But he was also a tireless, lead-from-the-front seller. An MSA salesman who booked John into an exhausting schedule of sales calls could expect a return visit from his CEO soon, because he was using Imlay’s time optimally. Indeed, I didn’t really know John all that well, probably for a couple of reasons:

• He was rarely around when I visited; he was much more likely to be out on the road selling.
• This was back in my stock analyst days, and I generally spent more time with detail-oriented folks, numbers- and product-oriented ones alike.

But my personal experiences with him and the stories I heard from his colleagues paint a consistent picture of a genial-but-driven guy. And by the way, when he did give a talk for me at a conference, it was the second-funniest, behind only that of designated comic lunch speaker Larry Welke.

Memorable was the time when John got the chance to give a speech in London that somehow involved Prince Charles. We never heard the end of it, and it’s one of my strongest personal memories of him. Apparently, he was dazzled by royalty.

Like John Cullinane, John Imlay was a largely non-technical leader. That is of course common now just as it as it was then. But another aspect of his leadership approach was more distinctive — the famous “People are the key” mantra, supported by little Tiffany key lapel pins every MSAer was expected to wear. See for example the NYT interview above, which talks of the pins, and also reminds us that some of John’s top showmanship was delivered at in-house company meetings.

The culture-building worked. I knew a lot of MSA folks back in the day, and on the whole, they were smart, affable southerners. (Exceptions could be found in regional sales managers, who could for example be smart and affable Midwesterners, smart and affable New Englanders, or smart and affable Brits.) Whether this was, from a shareholder value perspective, the ideal culture to build is another question, that I’ll address in a separate post. But in any case, John Imlay was a likeable, successful character, and the planet is a poorer place now that he is no longer on it.

I’m surprisingly saddened by John’s passing. In simplest terms, I think the reason is that he was amazingly full of life.

For early-stage companies, I’d say:

• Even more than for larger companies, the essence of messaging is to achieve the contradictory goals of excitement and credibility.
• If one of those must be sacrificed, sacrifice excitement. It is by far the easier of the two to regain.
• Note: Both your product and your company need to be credible. When your company is new, both parts of that are formidable challenges.
• Notwithstanding how limited your resources are, don’t rely too much on outside PR. You need to control messaging and key influencer relations yourself.
• Notwithstanding how limited your resources are, you need to address multiple audiences, at least:
  • Investors.
  • Prospective employees.
  • Knowledgeable influencers.
  • Not-so-knowledgeable influencers.
  • Sales prospects (business folks).
  • Sales prospects (technical folks).

Of course, these subjects are much discussed in this blog. The top three overview posts for young companies are probably: 

• A strategy worksheet (one of my most influential posts ever).
• A survey of young-company marketing communication essentials, with some generalities at the end.
• A guide to stealth-mode marketing.

If you read those three posts and follow the links in them, you’ll see much of what I have to say about early-stage tech company marketing.

Expanding the list of recommended posts:

• Almost everybody makes mistakes in positioning. (April, 2013)
• There are at least five major kinds of PR and three kinds of PR-centric marketing. (February, 2010)
• I catalogued eight of the many kinds of influencer. (February, 2008)
• I offered some concrete tips on messaging to multiple audiences. (February, 2014)
• Early-stage companies often have exercises in naming. (November, 2013)

Above all, if you’re working with me — my core messaging paradigm is the layered messaging model.

• The goal of message crafting is to find the right message(s) for particular audiences.
• The goal of qualification is to find the right audiences for particular messages.

Recall the layered messaging model, whose wording I’ll update to:

• Differentiated business benefits …
• … which are achieved because of …
• … superior technical features or SLAs,* …
• … the differentiation of which is achieved and sustainable because of …
• … fundamental product design.

A good messaging stack works well on all five of those layers. 

*Service Level Agreements, aka speeds or other metrics.

The messaging/qualification duality is straightforward on the business, features and design layers alike. The messaging–>qualification direction looks like:

• When qualifying you check to see whether the prospects has already determined that they agree with some of your messages.
• You also check to see if, upon thinking about it, they quickly come to agree with (more or) your messages.
• If neither happens, you surely don’t qualify them as a good prospect.

The qualification–>messaging link starts with:

• If “Do you have application need X?” is a reliably good sales qualification, then “We’re uniquely good at meeting application need X” will surely be a good marketing message.
• If “Do you have feature need Y?” is a reliably good sales qualification, then “We’re uniquely good at providing feature Y” will surely be a good marketing message.
• If “Do you have SLA need Z?” is a reliably good sales qualification, then “We’re uniquely able to ensure SLA level Z” will surely be a good marketing message.
• The same goes for any product architecture hot buttons.

In summary, then:

• In one direction, the message of this post is that you should observe which messages work well in specific sales situations, then emphasize those in your messaging.
• But it goes a little further than that, because hopefully you have a (semi) rigorous process for setting sales qualification criteria.
• Conversely, your first draft of sales qualification criteria should be to take each of your individual marketing messages and append “Do you care?”

Of course, there’s a second set of qualifying questions that boil down to “If you decide you want this, do you have the money and ability to actually buy it?” But I don’t have anything special to say about those at this time.

You can’t sell effectively without listening. This is one of the basic facts of business, yet shockingly many people forget it. You can’t pitch effectively without understanding how the prospect frames what she hears, and you can’t judge that unless you listen to what she says.

from a 2013 post about “fluency”,

If you are a small startup with innovative technology, put as little as possible between your own people who can talk with passion about the stuff, and whoever you’re trying to get coverage from.

from a 2011 quoted journalist rant,

the right person to lead an important relationship is:

• Usually somebody who can truly speak for your company, and specifically:
• Has the knowledge and ability to respond to pushback.
• Knows the influencer well enough to argue back in turn.
• Occasionally an in-house press or analyst relations staffer.
• Almost never an outside PR person.

from a 2012 collection of marketing communications tips, which also makes the point that you should flat-out ask people how they like to work, and a variety of cautionary tales of how one can bungle meetings or other relationship moments.

The above can be summarized as:

• Respect the person you’re trying to impress.
• Treat the person you’re trying to impress as an individual.
• Listen to the person you’re trying to impress.
• Understand and cater to how the person you’re trying to impress thinks.

I could write a whole post on that last bullet point alone.

Here are some further tips for productive single-person marketing and persuasion.

• As in many kinds of relationships, trust is paramount. In particular:
  • Relationships should be managed by somebody the other party likes, trusts and respects. Trust is the most important, because if that is present one can work around the absence of one of the other two.
  • Trust is important in both directions. If you trust somebody enough, you can bend confidentiality when it helps with clarity or persuasion. Vendors are often too reluctant to do that.
  • When all three of trust, liking and respect are in place, you can say things like “What do I have to do to persuade you of X?” or “How persuasive did you find Y?” Those can be very valuable techniques.
• Do your homework. For example:
• If they’re writers, look at what they write.
• If they’re influencers, ask whether they have published “How to pitch me” guidelines.
• If they’re IT users, look at what they might have blogged or presented, and probably also at what their colleagues have.
• Strategize with your targets about how to get more of their attention. For example:
  • Some influencers like introductions to users who might offer insight into a variety of topics (not just the ones you want to pitch) — but they often are very picky as to which users those are.
  • I like to talk with vendors’ own most interesting employees, which to me means the ones who will teach me about technology, user adoption, and/or marketplace trends.
  • People have wildly different preferences about conferences and travel.
• Strategize with your targets about how to have the most impact on them. In particular:
  • The template “Here’s a list of topics I think are interesting; which would you like me to talk about?” can work well with people who believe that their time budget only allows them to consider a small fraction of all interesting subjects — e.g. reporters or portfolio managers. I used it a lot when I was a stock analyst.
  • It’s fairly common to ask people, before a call, for a list of questions. I think that’s a bit limiting and off-putting, but I also think it can be improved upon. Indeed …
  • … before briefings, I often take the initiative to communicate a list of questions, issues, confusions, discussion topics, personal biases, etc., and then encourage the vendor to organize the presentation as they see fit in light of my concerns. Vendors can and should take the initiative in that kind of comprehensive preparation themselves.
  • Salespeople have all sorts of sales-cycle-optimization techniques I know relatively little about.
  • More generally, if we stipulate that it’s your responsibility to manage a meeting or ongoing relationship process, I’d say:
    • Dictating everything isn’t ideal.
    • Neither is just asking “What would you like me to do?”
    • Better than either extreme is an inbetween approach like “One idea/The default course would be to do X, then Y, then Z — how would you like us to tweak that for you?”
    • Note: The open-ended “How would you like us to tweak that?” is meant to get a more accurate response than the binary “Is that OK with you, yes or no?”
• At many junctures your targets will want you to spend more time on some subjects and less on others, while you don’t want to omit those other topics altogether. Kknowing how to summarize is key. Brevity is the soul of not pissing the other person off.

And on that note — I think this post has gotten pretty long, so I’ll end it here.

• Presentations for small audiences (August, 2014)
• Short lists of concise claims (July, 2014)
• Faith, hope and clarity (May, 2013)

In the first post linked above, I wrote:

The most generic and reusable part of a slide deck is its beginning — the “setting the table” part. A natural sequence is:

• Whatever seems necessary to introduce and identify you.
• Some validation as part of the introduction — company size, customer logos, whatever.
• The big business problem/need you’re helping with.
• A little validation about the problem/need.
• Some common difficulties in satisfying the need, which are happily absent in your solution.
• Specifically how you meet the need.

Let’s drill into some of those points.

Tips for company validation include:

• If you’re big enough to have validation as a market leader, of course offer that. Analyst firms (industry or stock) are generally the providers of such validation, either directly (those stupid quadrant graphs) or indirectly (via market share numbers and the like).
• Customer logos are great.
• Also great are strong aggregate claims about customers, e.g. “over 70 of the Fortune 100″.
• Financial or fund-raising success is solid validation, and has the second benefit of suggesting you have the resources to deliver on your promises.
• Mere influencer mentions are a weak validation. Also, beware of insulting influencers by quoting competitive influencers at them.
• Founder resumes are validation only for companies so small they can’t be expected to have stronger kinds.

And you might as well disclose headcount. You can keep revenue secret, but not headcount.

Expanding on the last four points and the distinctions among them:

The big business problem/need is something like “making the right offer to the right customer at the right time, exploiting the kinds of data that are now available to support the decision.” I.e., it’s something everybody has heard of, and has probably deployed some kind of technology to try to at least partially meet. Of course, there may be many application areas for your technology; then recite some of them, either right before or right after you state some unifying theme.

Truth be told, this is a short part of the presentation companies usually get right, so let’s move on.

If the need is obvious, how and why should you validate it? I can answer the “how” part of the question in one word — “quickly”. As for why validate — speaking strictly logically, you don’t have to. But it can help with emotional buy-in, and also gives an excuse to get a little more specific than, for example “know your customer by leveraging big data”.

Where things commonly go wrong is … well, in discussions of where things commonly go wrong. Vendors much too often paint a picture of life without them that is inaccurately bleak. If you say that enterprises who don’t have your technology “sometimes” or “often” are mired in long turnaround times, high costs, bad performance, etc., that’s fine. If you say or imply it always happens, you’re digging yourself into an early credibility hole.

That such exaggeration is commonly part-sincere doesn’t help. Kidding yourself into actually believing the weak-competition nonsense is one of the major pitfalls for Pollyannas. Your optimistic and future-oriented sales pitch needs to be compared to other vendors’ optimistic and future-oriented sales pitches, not to proven reality in the few well-established (and hence not the newest) production implementations you have detailed insight into.

Finally, let’s suppose you’ve navigated all those shoals, and want to summarize how you avoid common problems, before diving into the true technical meat of the presentation. This is a great time to draw on the layered messaging model:

• You have unique aspects to your architecture, which you quickly describe.
• This lets you have unique combinations of features, which you quickly describe.
• These, in turn, overcome the challenges you chose to mention before.

And with that the introduction is finally over, and you have at least three good choices about how to proceed:

• Walk through some specific success stories.
• Go into technical depth.
• Shut up and allow your listener(s) to get a word in edgewise.

For starters, let me say:

• I met Larry Ellison the same year I learned of him, which was 1983. We were in fairly active touch until the late 1990s. Then we drifted apart. That period corresponds roughly to the eras I characterized in my Oracle history overview as Hypergrowth, Plateau, and Professionalism.
• With Larry as with other “larger than life” industry figures I’ve met, what you get in private and what you see in public are pretty similar. I’ve had high-intensity dinner conversations with Larry (numerous times), Bill Gates (a few times) and Ross Perot (once) that are quite in line with their public demeanors.
• With Larry, facts can be mutable things. The first time I met him, I came away with the impression he had a PhD. The second time, it was only a masters degree. Ten years later, he’d almost graduated from the University of Chicago, but had failed or not take a French exam. And I gather his educational resume has retreated a little further since.
• Larry is hilarious, in a scathing way, and an excellent story-teller. Unfortunately, his humor rarely translates well to out-of-context print.

Some anecdotes:

• Larry at one time told me he’d selected my firm PaineWebber for the Oracle IPO. When he told me he was reneging, part of the explanation of why he wanted top-brand firms like Goldman Sachs was the analogy of having the girl on your arm be the most beautiful one at the party. Even then, it was clear that being envied was important to him.
• By the late 1980s, Larry was famous for agreeing to appear at conferences and not showing up. I kidded him about this, saying that he’d acquired an international reputation for rude unreliability. In a mock-sad voice he replied “Yeah — I used to just piss off my close personal friends.”
• Larry is one of only two people ever to blow me off for a meeting at his house. But he was very gracious when he came to the door and apologized.*
• In the late 1980s Larry promised to seed-fund a venture of mine. When Oracle hit a financial rough patch, he faded on me. A few years later, despite the lack of any kind of written commitment, he gave me $25,000 in apology.*

I didn’t realize until I made that list how many stories I have about Larry breaking promises.

*Larry is generally very good at apologies, perhaps because he’s had so much opportunity to practice them.

Of course, Larry’s habit of missing meeting schedules can be brutal on his employees. But that major annoyance aside, my general sense of his employee dealings has been they were tough-but-fair.* The only one of the many Oracle firings I didn’t understand at the time was that of hugely successful COO Ray Lane – and truth be told, Ray hasn’t come close to his Oracle level of success since. There have been some hirings I thought were doomed when they happened, but that’s a different matter — business judgment, not ethics. Of course, it helps in treating people fairly when your stock skyrockets and makes a whole lot of them rich.

*And when a complaint is made to the contrary, I tend to disbelieve the complaint, even the sexual-harassment ones.

Another group of stories that stick in my mind boil down to Larry delegating or not as the case may be.

• That $25,000 check I referred to above wasn’t actually signed by Larry; his assistant Jenny Overstreet evidently had that level of signing authority over his account.
• On the other hand, well into the 1990s, Larry had to personally approve every Oracle hire and every expenditure over $5,000. (When Jenny finally retired, that limit quickly rose to $15,000.)
• It was even longer that Larry personally approved every Oracle press release.
• In the 1980s Larry kept trying to offload “business” types of considerations on other executives. After various failures, he told me he was looking at them more himself and actually was finding P&Ls and so on rather interesting. Ironically, this was around the time he hired Jeff Henley as CFO, and finally had somebody outstanding to delegate that stuff to.
• In the same time frame he said he kept expecting somebody to rise to the level of replacing him as CEO. But in his estimation that person never actually emerged.
• Larry once told me he was bestowing millions of dollars more on his third ex-wife than their prenuptial agreement had called for, without objection. As he framed it, she was looking after his children, and he regarded keeping her happy as being of the utmost importance.
• And then there was the time Larry had a headache before a major speech, and sent his PR staff scurrying to get him aspirin of his particular favorite brand (Bayer).

Yet another group of stories focuses around aggression and relentless energy. Most remarkable to me were a couple of times when Larry described a sales manager’s particularly energetic aggression to me with admiration and glee. Some of that was around the famous “Cut off their oxygen” phrase, originally applied to competitor Ingres and later repurposed for other rivals. But then there was also the time I heard about a 2-on-2 basketball game, featuring Larry, sales (and marketing?) chief Mike Seashols, and Mike’s direct report Gary Kennedy. Apparently, Gary shoved Mike around quite a bit during the game, and Larry cited that as a strong foreshadowing that Gary would soon also shove Mike aside for his job. And it’s from Larry that I first heard the Genghis Khan quote to the effect that the greatest pleasure in life is to see your enemy utterly defeated.

Finally, I’ve heard a lot of stories about Larry Ellison and attractive women — and except for the employee-harassment tales, I believe them all.

• All messaging needs to be Clear, Compelling, and Credible.
• Credibility depends upon, among other factors, Consistency.
• All collateral should be Cleanly Copy-edited.
• A presentation should always be tailored for the specific audience and purpose (it’s not a crazy stretch to call that Context).

And at the risk of drowning in excessive Cs, slide decks are a primary venue for a recent post topic: Short lists of Concise Claims.

Let’s talk a bit about that tailoring. Some things are shown only to very specific audiences. For example:

• Certain numbers are only for internal consumption.
• Other numbers are mainly for investors. (You don’t probably don’t want to show a sales prospect your estimate for Total Addressable Market.)
• Explicit sales qualification criteria are mainly for sales training, although they are occasionally relevant in other internal or investor contexts.

Even so, you’re unlikely to invest in entirely separate presentations for each of press, analysts, knowledgeable prospects, less educated prospects, etc. Rather, it’s often a best practice to:

• Build a slide deck that’s too long for any one particular meeting, and then …
• … pick and choose from it based on the interests of each particular audience.
• Adjust your verbiage greatly on a meeting-by-meeting basis.

Beyond the obvious, such as industry or enterprise size, how do you figure out what to tell each particular audience? In three words: Listen to them!! A good salesperson can and should do a lot of that in preliminary conversations; in influencer/investor kinds of meetings, however, you may rely more on feedback as the discussion progresses. Either way, focus on what the audience cares about, is interested in, or is likely to see as a good reason for (in)action. In any case:

• Don’t make the mistake of insisting that every presentation follow the same script.
• Also, don’t spend too much of each presentation anticipating and answering whichever questions arose in the last one.*

*I have too often been guilty of that error, in my stock analyst and startup CEO periods alike.

Generalities to bear in mind include:

• Different audiences have very different levels of technical depth and interest.
• But with that said:
  • Even non-technical audiences should be given some reason to think you have a sustainable technical advantage.
  • Even technical listeners should be reminded of the business-benefit reasons that you bother doing what you do.
• Different prospect organizations have different needs, so you don’t want to pitch the same features and benefits to all of them. However …
• … prospects like to hear that you can meet needs GREATER than theirs, so you might want to at least quickly mention why — for example — you’re scalable enough for large web companies, detailed enough for the Fortune 50, and secure enough for the financial services industry and the CIA alike.

Finally, I have some more specific tips about organizing decks and pitches. In particular:

• The most generic and reusable part of a slide deck is its beginning — the “setting the table” part. A natural sequence is:
  • Whatever seems necessary to introduce and identify you.
  • Some validation as part of the introduction — company size, customer logos, whatever.
  • The big business problem/need you’re helping with.
  • A little validation about the problem/need.
  • Some common difficulties in satisfying the need, which are happily absent in your solution.
  • Specifically how you meet the need.
• Only then should you turn to nitty-gritty such as:
  • Technical details (in a sales meeting).
  • Details of the latest product release (in a press meeting).
  • Specific customer success stories.
• Tread lightly when you validate the problem/need.
  • Ideally, your audience agrees on the need, so if you spend effort on proving it, you’re just undermining agreement that was already reached.
  • Quoting influencers is dangerous. Quoting influencers to other influencers can be downright insulting.
  • Quoting market size numbers is dangerous, unless you’re pitching investors. Most other kinds of audiences won’t care, except insofar as they recoil from your display of greed.
• Tread even more lightly in the area of head-to-head competitive claims. If you must make such claims at all, restrict them to conversation, rather that writing them on slides. And by the way, an assertion of uniqueness is a special kind of head-to-head competitive claim. I feel strongly about all this because:
  • You aren’t an expert on the competition.
  • You don’t want to be on record as saying something wrong.
  • You probably don’t want to talk about any competitors except the ones that will anyway come to your audience’s mind.
• In a sales pitch, the nitty-gritty should be heavily tailored to the specific prospect. If you can’t do that in the slides, definitely do it in the voiceover.
• It’s OK to have slides that the audience doesn’t care about — but only if you rush through them at warp speed. Of course, you should dwell lovingly on the parts of your pitch that do resonate with your listeners.

Related links

Some of my previous posts overlap in subject area with this one. Most can be found by following links in the marketing communications blog category or our highly popular strategy worksheet.

A number of independent mainframe-based pre-relational DBMS vendors “crossed the chasm”, but none achieved anything resembling market dominance; that was reserved for IBM. Success when they competed against each other seemed to depend mainly on product merits and the skills of individual sales people or regional sales managers.

IBM killed that business by introducing DB2, a good product with very good strategic marketing from a still-dominant vendor. By “very good strategic marketing” I mean that IBM both truly invented and successfully market-defined the relational DBMS concept, including such conceptual compromises as:

• Ted Codd’s 12 rules, not that anybody — even IBM — actually followed them all.
• SQL as the standard, rather than the probably superior QUEL.

In the minicomputer world, however, hardware vendors lacked such power, and independent DBMS vendors thrived. Indeed, Oracle and Ingres rode to success on the back of Digital Equipment Corporation (DEC) and other minicomputer vendors, including the payments they got to port their products to various platforms.* The big competitive battle was Oracle vs. Ingres, about which I can say for starters:

• Oracle won.
• Oracle was generally more energetic and aggressive, top to bottom.
• Oracle used SQL; Ingres used QUEL; this was important.
• In general, Ingres tried to give customers what they should want; Oracle tried to give them what they actually wanted.
• Both companies did a poor job on product quality, but somehow Oracle succeeded in seeming more mature, stable, complete and enterprise-ready.
• Rarely has a company grown as quickly as Ingres and still been an embarrassing “failure”.

*Ingres actually had more ports than employees, when both totals were in the 40s.

The next big RDBMS showdown was Oracle vs. Sybase, my views of which can be summarized as:

• Sybase was a late enough entrant to be at a significant disadvantage, but gave Oracle a good scare even so.
• Sybase’s core strength was messaging. In particular, Sybase assumed the mantle of client-server architectural leadership. One unfortunate side effect was that Sybase persuaded the industry to rely heavily on stored procedures; maintenance nightmares ensued.
• Sybase also had aggressively successful field execution.
• Sybase would up losing because of a particularly terrible product release — Sybase System 10 –and delusionally bad development execution in general.
• But Sybase managed to long prosper anyway in certain markets, especially Wall Street (where client/server was a particularly good fit) and China (where comeback CEO John Chen had cultural ties).

The Oracle vs. Informix battle was similar: Informix had a good architecture story, but eventually screwed up development strategy, specifically in an over-ambitious plan to integrate several disparate DBMS.

Through all this, Teradata prospered in its RDBMS niche, namely large-scale data warehousing. That story can be summarized as:

• In its niche, Teradata had massive architectural superiority.
• Only a limited number of large accounts cared, so Teradata could get by with good sales execution, and didn’t need much marketing visibility.
• Teradata was non-religious, switching from QUEL to SQL sufficiently early, and later minimizing the proprietary nature of its hardware, in both cases to obviate customer objections. (Ironically, Teradata’s biggest competitive problems later on came from Netezza and Exadata.)
• Teradata products for a long time were cool (best performance on the biggest jobs) but not weird (standard RDBMS).

Teradata’s success is particularly noteworthy because it survived being owned by two ponderous behemoths, AT&T and then NCR.

Progress Software also had some niche RDBMS success. Noteworthy aspects included:

• Progress led with its eponymous application development tool, while its RDBMS was a bit secondary, a strategy that made sense in the era.
• The RDBMS focused on “zero DBA” operation.
• Progress’ main niche was companies developing applications to sell to small/medium businesses.
• Progress had a large secondary niche in large-enterprise applications that were meant to be deployed to large numbers of remote locations.
• Progress’ non-glitzy persona was a good match to its customers. Even so, Progress’ extreme lack of marketing was costly.
• Informix was very competitive in Progress’ market, but refocused on the admittedly much larger large-enterprise general-purpose RDBMS sector. (I criticized the decision at the time; Informix’s low-end business was too good to just give up.)
• Progress defocused too, using its core business as a cash cow for various enterprise software ventures, which didn’t work out well.
• Progress was slow to address its core customer base’s need to switch from on-premise to SaaS (Software as a Service) delivery.

Object-oriented DBMS never got off the ground, Intersystems Cache’ eventually excepted. The core problems were:

• OODBMS were weird (very different application development paradigm) but not very cool (they had fizzled before object-oriented development got popular).
• OODBMS always seemed incomplete.

Considering the subsequent popularity of object-relational mappings and NoSQL, this can be viewed as a major strategic or execution failure. There should have been a way for OODBMS to prosper.

And that brings us to the end of the millennium, which is a good place to take a break. A companion post covers more recent developments.

1. My connections have always been much stronger with IDG (International Data Group) publications than with the analyst firm IDC that’s also part of the business.

2. I have at times been pretty connected to those pubs. For example:

• I’ve been a columnist for both Computerworld and Network World (the latter online-only).
• I’ve blogged for pay for both Computerworld and Network World.
• I’ve been outright interviewed by each, and quoted many times by them and other IDG publications as well.

3. Computerworld has probably always been the leading enterprise technology publication, including during the trade press’ glory years. Most memorably, pre-relational mainframe DBMS were claiming with some success to be “relational”. But when Computerworld reported Ted Codd’s “rules” for RDBMS, that was that — RDBMS were defined to be what Codd and Computerworld said they were, and the bottom dropped out of the market for DBMS that didn’t meet Codd’s criteria.

4. In line with its industry leadership, Computerworld had a classified ad section that ran dozens of pages. When I hired a research assistant in my stock analyst days, the obvious choice was to run the ad there.

5. To this day, if an ego-surf shows that I’ve been quoted in countries and languages around the world — Brazil, Australia, Iran or whatever — it’s usually something I said to IDG, which then translated and republished it around the world.

6. IDG is a big enough press organization not to be perfect.

• I left as a Computerworld blogger when I challenged my editor on his ethics, and he didn’t take it well.
• I thought IDG’s general counsel was too timid in the face of libel threats. He also conducted a conversation with me in such a manner that I briefly considered reporting him to the Bar Association.

7. Somewhere I have a bag of buttons passed out by Computerworld at trade shows with funny but sexually suggestive slogans such as “Nice computers don’t go down” and “Floppy now; hard later”. Those were also the days that nobody challenged the idea of scantily-clad booth babes. Yet it was also already the case that a number of Computerworld’s leading writers were women.

For all the concerns about tech industry sexism today, it used to be a lot worse.

8. What I said about Computerworld — and by implication other broadly-targeted IDG publications as well — in my 2009 post about the information ecosystem remains generally true.

1960s and 1970s

Modern IT is commonly dated from the introduction of the IBM 360 mainframe in 1964-5. But even before then, there was a growing industry in what we’d now call outsourced services, specifically in payroll processing; major players included Automatic Data Processing (ADP), the company that gave us Senator Frank Lautenberg, and a variety of banks. This was (and to this day remains) a comprehensive service, priced by unit of work (e.g., number of payroll checks cut).

IBM mainframes, which quickly came to dominate the market, were in the 1960s and 70s commonly rented. IBM software that ran on them was hence typically priced on a rental/subscription basis as well. The independent packaged software companies, however, often preferred to get paid up front,* and hence sold perpetual licenses to their software. Annual maintenance fees for the licensed software started in the range of 10% of the perpetual license or even less, but migrated up to today’s 20-22% range.

*There’s a famous story of Cullinane Software making payroll only because a customer’s check arrived. Less well known is one of MSA in the same bind, which salesman John Arnold got them out of by posing as a bank executive and providing his own financial-stability reference from a payphone.

At the same time, there was a large business in what then was called “time-sharing”. Much was what we would now call “Software as a Service” (SaaS), in that it delivered applications or analytic tools. Other was rawer access to compute power, more akin to today’s general cloud services. A major driver for the time-sharing/SaaS choice was simply that computers were very expensive. (And so were computer rooms, personnel, etc.)

Of the multiple kinds of time-sharing companies, the three most prominent were (and these categories overlap):

• Companies that wanted to own computers but were looking for some help with their costs. In particular, every major aerospace company — I specifically recall Boeing, Lockheed, McDonnell-Douglas and Martin Marietta — seemed to have a substantial computer services division. So did other large industrial companies such as GE and Xerox.
• Application and analytic software providers who chose to deliver in a time-shared format. Examples included:
  • Xerox Computer Services, a $100 million vendor in MRP (Material Requirements/Manufacturing Resource Planning).
  • Banking software/service providers. EDS had two divisions for this, one each for banks and credit unions. Systematics — the star of the Little Rock tech industry — was another major vendor.
  • Health care software/service providers, notably Shared Medical Systems.
  • Some insurance software providers, notably Policy Management Systems.
  • Gerry Cohen’s various ventures in analytic software.
• Networking services businesses. Tymshare/Tymnet was an early leader. Ordernet (later Sterling Commerce) was a special case.

Also noteworthy was the stock quote business. Quotron combined on-premises personal appliances, a network, and a data service, and had a significant business already in 1961; other contenders were Reuters and ADP. Starting in the 1980s, Bloomberg took much of that business.

1980s and 1990s

In the 1980s, multiple forces drove the industry towards a straightforward purchase-plus-maintenance model. In particular:

• Computers got more affordable. Most notably:
  • IBM offered cheaper mainframes, starting with the 4300 series.
  • Minicomputers, especially the DEC VAX, came into widespread business use.
  • Smaller computers yet, including PCs, became important.
• Vendors were eager to recognize revenue from product sales, as opposed to subscriptions over time, because pulling revenue forward made them look more profitable.

The larger general-purpose time-sharing companies generally fizzled, although some special cases survived or even prospered. (A lot of those could be called “Networked payment services”.) And in a tactic that probably should have been echoed more often since, minicomputer-based MRP vendors,* while preferring to sell software licenses (and often to resell minicomputers as well), also offered time-sharing to ease installation and adoption.

*Notably the leader ASK Computer Systems.

Some packaged software vendors did emphasize term licenses for their software, so as to later get more “recurring” revenue when the licenses were renewed. Unfortunately, some of the top practitioners of that strategy — notably Computer Associates — were caught in accounting shenanigans. And for those customers who really wanted to pay on an annual basis, hardware and even software leasing options emerged to accommodate them.

The 21st Century to date

This century, three major trends have pushed toward subscription or other pricing-over-time:

• Open source software. Since open source software almost always has a $0 license fee, to the extent it’s paid for, it’s priced on a subscription basis.
• The resurgence of SaaS and the rise of public cloud computing. SaaS is usually paid for on a subscription basis. (The rest of the time, it’s priced per unit of work.) Ditto public cloud computing. Ditto anything in between.*
• Enterprise license agreements. Large enterprises and vendors commonly negotiate “all you can eat” enterprise-wide product and support licenses. Agreeing on a price is terribly hard unless there are shared expectations as to the enterprise’s level of usage. That’s easier to achieve for a fixed term than for the entire future history of time.

Hence, even on-premises software vendors typically offer both perpetual and term pricing models. Annual fees are typically 50% or more of the perpetual price, with Oracle’s stated 42% probably an artifact of the company’s discount-negotiating strategy. Appliances are to my knowledge priced mainly on a purchase basis — but again, if that bothers customers, there’s always a lease option.

*Truth be told, I don’t pay much attention to the distinctions between, for example, SaaS, PaaS (Platform as a Service), IaaS (Infrastructure as a Service) or DBaaS (DataBase as a Service). Indeed, I expect an announcement next month for PPTaaS (Partridge in a Pear Tree as a Service).

And with that I think this post has gotten long enough. Please stay tuned for future discussions of a more forward-looking kind.

Related links

• Last May, I offered advice about the specifics of software pricing.
• Last March, I opined that enterprise computing was moving toward a combination of appliances, clusters, and clouds.

Now the term Business Intelligence has been tracked all the way back to 1865.

In the pre-relational days, it was common practice to buy products that hadn’t succeeded yet, and grow with them. Often these were programs written at enterprises, rather than third-party packages. Most of Cullinet’s product line, including its flagship DBMS IDMS, was came into the company that way. ADR, if memory serves, acquired the tiny vendor who created DATACOM/DB.

Then things slowed down. A Canadian insurance company oddly bought Computer Corporation of America, to utter non-success. (At least I got an investment banking finder’s fee on the deal.) Computer Associates, which did brilliantly in acquiring computer operations software, had a much rockier time with DBMS. It acquired Cullinet, Applied Data Research, and ASK/Ingres — among others — and didn’t have much growth or other joy with any of them.

Indeed, Ingres has been acquired three times, and hasn’t accomplished much for any of the acquirers (ASK, Computer Associates, Actian).

I used to think that Oracle’s acquisition of RDB provided key pieces of what became Oracle’s own extensibility technology. Andy Mendelsohn, however, disputed this vehemently — at least by his standards of vehemence — and his sources are better than mine. Rather, I now believe as I wrote in 2011:

… while Oracle’s track record with standalone DBMS acquisitions is admirable (DEC RDB, MySQL, etc.), Oracle’s track record of integrating DBMS acquisitions into the Oracle product itself is not so good. (Express? Essbase? The text product line? None of that has gone particularly well.)

Experiences were similar for some other relational DBMS pioneers. 

• Sybase did well with its acquisitions of what became the standalone products Sybase IQ and Adaptive Server Anywhere.
• Informix did well with its acquisition of what became Informix’s parallel offering XPS (the same technology Ingres passed up), but terribly with Illustra (which it unwisely tried to integrate into its other products).
• Microsoft has done very well with Sybase Adaptive Server Enterprise’s source code, which formed the basis for SQL Server.

IBM’s acquisition of Informix, however, didn’t accomplish much that I’ve been able to discern. Ditto various small deals such as Oracle/Sleepycat, Oracle/TimesTen, or IBM/solidDB. And no acquisition of an object-oriented DBMS vendor — of which there have been many — has succeeded in igniting that niche market.

Finally, let’s consider the recent merger wave in the analytic RDBMS sector.

• Microsoft went first, acquiring DATAllegro. Integration of DATAllegro and SQL Server technology didn’t go well; while PDW (Parallel Data Warehouse) has finally come to market, I believe it’s much less based on DATAllegro than Microsoft first hoped.
• IBM has sold a lot of Netezza into its installed base. Otherwise Netezza seems to be lagging. And it’s generally assumed that most noteworthy Netezza people have been or can be hired away. (Big exceptions: Phil Francisco, perhaps also John Metzger.) Wisely, IBM has made no moves to combine DB2 and Netezza into a single product.
• EMC/Greenplum has been the flashiest of these deals. Some early bumps notwithstanding, EMC poured resources into Greenplum, and EMC/Greenplum have been correspondingly active. Partnerships (VMware, GE), name changes (Pivotal) and so on have also kept the pot stirred.
• For the first 2 years after being acquired by HP, Vertica proceeded fairly independently, with what seems like decent growth, but also without a Greenplum-like flood of resources enjoyed by EMC Greenplum. I expect somewhat more integration going forward, perhaps an appliance strategy that somebody actually notices.
• The Teradata/Aster case is much like IBM/Netezza — separate products, focused on the Teradata customer base. Details, of course, differ.

• A small oligopoly dominating the conjoined businesses of mobile device software and search. The companies most obviously positioned for membership are Google and Apple.
• The continued and growing combination of search, advertisement/recommendation, and alerting. The same user-specific data will be needed for all three.
• A whole lot of privacy concerns.

My reasoning starts from several observations:

• Enterprise search is greatly disappointing. My main reason for saying that is anecdotal evidence — I don’t notice users being much happier with search than they were 15 years ago. But business results are suggestive too:
  • HP just disclosed serious problems with Autonomy.
  • Microsoft’s acquisition of FAST was a similar debacle.
  • Lesser enterprise search outfits never prospered much. (E.g., when’s the last time you heard mention of Coveo?)
  • My favorable impressions of the e-commerce site search business turned out to be overdone. (E.g., Mercado’s assets were sold for a pittance soon after I wrote that, while Endeca and Inquira were absorbed into Oracle.)
  • Lucene/Solr’s recent stirrings aren’t really in the area of search.
• Web search, while superior to the enterprise kind, is disappointing people as well. Are Google’s results any better than they were 8 years ago? Google’s ongoing hard work notwithstanding, are they even as good?
• Consumer computer usage is swinging toward mobile devices. I hope I don’t have to convince you about that one.

In principle, there are two main ways to make search better:

• Understand more about the documents being searched over. But Google’s travails, combined with the rather dismal history of enterprise search, suggest we’re well into the diminishing-returns part of that project.
• Understand more about what the searcher wants.

The latter, I think, is where significant future improvement will be found.

So how does a search engine understand what you want? It can listen to you directly, parsing your search string. It can ask for more clarity, through some kind of disambiguation interface. Or it can make inferences, based on — well, based on just about any kind of information that might exist about you and your online behavior.

Search strings are short, typically four words or less. That doesn’t leave room for a lot of innovative parsing. Not a lot of progress can be made until search strings get a lot longer, and that is unlikely except perhaps through the convenience of speech recognition.

Faceted/parameterized selection has its place. For example, when I search on Amazon.com, the site encourages me to also select a department from its dropdown menu; otherwise, it refuses to rank the search results. And when I buy shirts from Land’s End, I just click through and never search at all. Still, Google’s been around for 15 years, and about all its successes in searcher-does-the-work disambiguation boil down to is:

• A list of a few major subcategories to search (News, YouTube, etc.).
• Spelling correction.
• A desultory list of related/more specific searches, perhaps just longer search strings other people have recently entered.
• Well-hidden “Advanced Search” features, which look much like AltaVista’s and AllTheWeb’s similar features did late in the 20th Century.

Whatever the user attitudes and behaviors are that constrain Google’s or its competitors’ success in this area, I can’t imagine them changing much — except, once again, in the event that speech recognition leads to richer human-computer conversations.

I’ve now highlighted two different ways in which there’s a search-interface challenge that will be tough to beat without turning to speech recognition. But the case for speech recognition is even stronger than that. We’re moving to small, mobile devices, and:

• Traditional search interfaces work worse on mobile devices than on desktop computers. Typing is harder. So is dealing with picky forms.
• Speech may work as well or better on mobile devices than at your desk. If you have upgraded your Apple device to IOS 6, you have both a microphone and Siri. The same may not be true of your desktop gear.

And so I conclude that speech recognition is a big part of the future of search.

What will that allow? Since talking is easier than typing, speech is a way to get longer text strings as search inputs, or more of them. It’s plausible that people might speak queries as complex as:

• “I want to buy a recharger for an iPad 3 with delivery this week.”
• “Where is 10gen’s Northern California office?” … “Which nearby restaurants have good Yelp reviews?”
• “Tell me about the David Reed who went to the Kennedy School of Government around 1977, went to Dartmouth before that, and worked for the Federal Communications Commission.”

Getting search engines to the point that they can handle such queries will be difficult but straightforward — but even more progress is needed. Search results for various queries will be greatly improved if the search engine “knows” things like:

• The location of your home and office, and the distance you’re willing to go from them to eat or shop.
• Your tastes in food, clothing, and gadgetry.
• The level of sophistication at which you like to read about medicine, finance, or electronics.
• Which people are or might be in your extended social network.

And that will cement internet search squarely in the world of — for once I approve of the term — big data.

Let’s start with a breezy overview, setting the stage for more detailed posts to follow. As I see it, there have been four eras at Oracle, which between them reflect just about every tech company management theory I can think of.

Startup: This period comprised initial development, custom contract with the US military (CIA, I think, even though the demo database was always naval), and initial product release. This is the one phase of Oracle’s history I didn’t witness personally. But it seems to have been pretty much a story of “build a minimum viable product for a great vision, and hustle until somebody buys it.”

Hypergrowth: Roughly speaking, Oracle grew 100% per year on its way from $5 million in revenue to $1 billion. This period formed much of the basis for Geoffrey Moore’s famous “Crossing the Chasm” series of books. In line with Moore’s later observations, Oracle’s priorities in this period were:

• Sell.
• Ship good enough product to sell.
• Worry about the details later.

By the backhanded “good enough … to sell”, I mainly mean two things. First, Oracle quality was pretty questionable, across the board. Second, as I observed in a post on Oracle’s arch-rival Ingres,

Ingres was first to market with new features such as a 4GL or a truly distributed DBMS. Oracle, however, was the first to market with the features customers most cared about, at a level of completeness they found acceptable.

Plateau, Professionalization, and Conquest: Oracle then hit a wall. New “adult supervision” management came in to clean up everything from product quality to accounting. This is when Oracle got serious about competing with IBM and EDS. It’s when Mike Fields and I coined the label “Enterprise Data Babysitter”.

Regaining momentum, Oracle pulled irreversibly past the other independent DBMS vendors of the era, and in essence past IBM mainframes as well. Its application business also finally got some traction, albeit with a long way still to go. And most interesting to me, Oracle triumphed with a blend of product and professional services efforts in a way that hasn’t been seen before or since.

This was also the era during which I was most closely involved with Oracle myself. Oracle was my biggest consulting client for multiple years. I double-dated with Larry Ellison. Geoff Squire bought me an obscene statuette in Indonesia, and presented it to me at an Oracle analyst day.* I stayed for a week in Oracle PR chief Gail Snider’s house, and a night in Marc Benioff’s. Oracle VP Bob Jesse explained to me what raves were. (He later left Oracle to start a charitable foundation promoting drug use in the context of religion.) And Oracle analyst relations chief Daniel Sagalowicz didn’t even bother talking to me, on the theory I was getting along just fine without his help. Fun times.

*It was a lovely carving of two pigs fornicating. He said he saw it and instantly thought of me. I presume this was a reference to my Wall Street background.

Empire expansion: Now Oracle was atop the heap, selling complex, expensive products to complex, deep-pocketed customers. This left Oracle in what Clayton Christensen would call the Innovator’s Dilemma position, subject to disruption from below. And so Oracle adopted the Innovator’s Solution with a vengeance, by:

• Thickening its stack, to ensure that wherever the profit opportunity went, Oracle would be there.
• Going to great lengths to buy a leading disrupter, MySQL. (Oracle endured expensive delays in the Sun acquisition it could have averted by divesting MySQL.)

In particular, Oracle bought huge numbers of software vendors — PeopleSoft, Siebel, BEA, and many more. And then Oracle went further, bundling hardware as well — but that brings us pretty much to the present day.

Related link

• Wikipedia’s timeline for Oracle’s history is pretty reasonable overall, but there certainly are errors and omissions. For example, Wikipedia seems to think Mike Fields and Ray Lane joined Oracle the same year, when in fact Mike’s (and Geoff’s) replacement by Ray Lane was a key event in Oracle history.

A spectacularly failed upgrade has brought down DBMS2.com. I’m going to try to reproduce the error — or hopefully not — and also work toward a fix by messing with my other blogs. Please forgive any chaos that ensues.

To quote the owner of a popular sports fan discussion forum (emphasis mine):

The problem is several of the provisions in SOPA will force ISPs hosting websites (ie: the company that hosts our servers) to potentially disconnect us from the Internet if there’s a claim – unsubstantiated or not – that we’re infringing against copyright, regardless of if it has not been fully proved in court. The argument is that this would make it easy for someone to make false or weak claims against the site to take a us offline until we went to court.

That’s a headache I’m not prepared to deal with. The number of threats I get each year via e-mail from angry members from other teams we remove are pretty unreal and obviously you guys don’t see them, so giving any additional ammunition backed up by a law like this would be a potentially huge issue. I’ve been talking with other sites and it’s a very real concern that we’re all potentially going to be faced with if this goes through, unless it’s rewritten to better target the sites that are really the ones they’re looking to address.

And that’s just from the passions of sports fandom. The passions of the politics — or the commercial interests of those being criticized — are of even greater concern.

Indeed, SOPA-like legislation creates an easy way to take down any forum, blog, or other site that allows user-generated content: flood it with copyrighted content, then run to the regulators. We must never, ever, ever accept a legal regime in which publishers may be censored before they are PROVED to be guilty of wrongdoing.

the site-of-record for that startup root-system and everything that springs up from it, cycle-after-cycle

and mentor/investor/board member Mike Arrington simply called

to be the paper of record for Silicon Valley

That, I believe, is in the form a journalistic mission statement should take:

• “We (will) offer the best X about Y”, where …
• … “X” is something like news or analysis or opinion and …
• … “Y” is a particular subject area.

But there’s a problem with that template. One would ideally wish a mission statement of the form “We do the best A” to be followed up by “and, obviously, people will pay lots of money for A”. Journalistic mission statements don’t have that nice property.

Fortunately, at least in the case of tech blogging, they do tend to have a nice substitute. Let me explain.

TechCrunch and Pando Daily seem to have the same business plan:

• Create a popular and respected blog.
• Use the access provided by that popularity and respect to populate great conferences.
• Use the readership provided by that blog to promote the conferences.
• Ka-ching.

I have an analogous plan for DBMS 2:

• Create a popular and respected blog.
• Use the access provided by that popularity and respect to inform great consulting.
• Use the readership provided by that blog to promote the consulting.
• Ka-ching.

Other business models, such as GigaOm’s, would seem to be a hybrid of our two. All are what could be called “freemium” models, even if the other guys (and gals) sell a few ads as well. All seem to work.

Here’s what I think is the non-obvious part of our models:

Different parts of our readership are important for different reasons.

To a first approximation:

• Everybody who reads our work and benefits from it makes us feel good, and motivates us to do more.
• Everybody who reads our work and is influenced by it makes tech vendors want to be on our good side, talk to us, give us insight, please us by speaking at our events, and so on.
• A moderate fraction of our readers help us expand our readership by word-of-mouth.
• Only a small fraction of our readers chip in with helpful blog comments, insightful/tip-off e-mail, and the like, or by publicly throwing us links/tweets.
• Only a small fraction of our readers are likely to ever give us money.

I think a lot of successful journalistic (or quasi-journalistic) business models will be similarly layered.

Denis Pombriant obviously attended the same Marc Benioff session I did. Dion Hinchcliffe blogged the whole story in considerable detail.

It’s a cool story, and worthy of attention. But I’d like to step back and remind us that there are numerous different ways to use social technology in the enterprise, which probably shouldn’t be confused with each other. And then I’d like to discuss one area of social technology that’s relatively new to me: integration between social and operational applications.

Suppose we split up social technology use cases by saying it can help you:

• Communicate and collaborate internally …
• … and also with small groups of outsiders, such as your supply chain.
• Observe, listen to, and interact with consumers (and the world at large).

The biggest buzz, of course, is around social technology that reaches out to the buying public or world at large. You can use social technology to:

• Observe and listen to consumers — i.e., classic Voice of the Customer/Voice of the Market text analytics.
• Publish to consumers, influencers, etc., via blogging, broadcast-oriented Twitter, and other social media, or go even further and …
• … communicate with consumers interactively, whether through loosely-structured interaction (e.g. Twitter), or in the more structured ways that Attensity and others provide.

I support all that, and indeed participate ferociously myself. But for now, let’s move on.

On the internal collaboration/communication side, I’d say:

• Any communication tool useful for communicating with the public may be valuable internally as well — portals, blogs, Twitter-imitators, and so on.
• Pure email “push” may not always be the best tool for point-to-point internal communication.
• Text analytics on internal communication can have a variety of uses, e.g:
  • Compliance (yet another privacy intrusion, but sometimes a legitimate one).
  • Internal expert-finding. (In principle, this is the traditional genuine benefit of elaborate “knowledge management” implementations, but without the burdens of traditional knowledge management. In practice, that didn’t work out so great for Tacit Software.)
  • Project management.

That all gives plenty of scope for useful adoption, on both the email-replacement and text-analytic sides. But again, let’s keep going.

The relatively new to me — notwithstanding the “portals” link above — part of the social technology story is integration between social and operational applications. While at Dreamforce, I talked with two manufacturing application SaaS vendors — Kenandy and Rootstock Software. In both cases I asked “So what are you doing that’s an advance over where MRP was 20 years ago?” In both cases the main answer was “Now users can use social technology to track and communicate about particular orders or issues.”

*MRP stood for “Material Requirements Planning” and then “Manufacturing Resources Planning”, and is essentially the  forerunner of ERP. By “Kenandy” I specifically mean Kenandy’s founder — ASK Computer Systems founder and thus MRP legend Sandy Kurtzig.

Good point. Of course, it can be generalized; one can communicate and collaborate around almost any kind of business process. I’ve mentioned this before in analytic contexts; it’s an important concept on the monitoring-oriented side of business intelligence and — if Oliver Ratzesberger is to be believed — in investigative analytics as well. But the operational side may actually be more important.

Some things one does in the business world actually involve using one’s body, from manufacturing products to repairing power stations to standing in a store and serving customers. Most of the rest fits into one or more of three buckets:

• Creating (a product, a marketing plan, a marketing document, a compensation plan, a program for internal use, an analytic insight, …)
• Relating (to an employee, a sales prospect, a reporter, …)
• Participating in a fairly routine business process (data entry, accounting, mortgage approval, parts ordering, …)

And why can’t we just automate those routine business processes away? Because there’s so often a need for manual intervention. And when there’s a need for manual intervention, there’s usually also an element of communicating with other people. This is almost always true in cases of trouble-shooting or exception-handling (an order is late, a system is down, the automated result violates common sense). It may be present in other cases as well (the new account calls for a personal thank you note, the food order needs to be annotated with special requests). General email is commonly an awkward medium for these communications; automated messages are worse. Newer social technologies, however, have the potential to do much better.

So what do you think? Have I drunk too much Kool-Aid, or is this stuff for real?

*This is although I’ve spoken at four prior versions of the event, and responded to their request for free consulting as recently as this year.

OK, that might have been personal in some way — but Nick Patience tweets a very similar story. Even Seth himself tweets that

They have a business model that does not apply well to the IT conference space.

The Text Analytics Summit has been troubled for years, but evidently things have gotten worse.

This is more than an incidental problem. Interest in text data is exploding, and marketplace confusing about text analytic technology abounds. More clarity is needed, but too few folks have found an economic model for providing it. (The industry shares some of the blame for that.) I’m glad Seth is doing other conference work — notably on sentiment analysis — but yet more is needed.

If I get into the conference business — and it seems natural that I would — I’ll try to help fill the gap. But if somebody else beats me to the punch, more power to you, and please let me know how I can help.

• Understanding the opinions of customers, prospects, or other groups. This can be based on any combination of documents the user organization controls (email, surveys, warranty reports, call center logs, etc.) — in which case — or public-domain documents such as blogs, forum posts, and tweets. The former is usually called Voice of the Customer (VotC), while the latter is Voice of the Market (VotM).
• Detecting and identifying problems. This can happen across many domains — VotC, VotM, diagnosing equipment malfunctions, identifying bad guys (from terrorists to fraudsters), or even getting early warnings of infectious disease outbreaks.
• Aiding text search, custom publishing, and other electronic document-shuffling use cases, often via document augmentation.

For several years, I’ve been distressed at the lack of progress in text analytics or, as it used to be called, text mining. Yes, the rise of sentiment analysis has been impressive, and higher volumes of text data are being processed than were before. But otherwise, there’s been a lot of the same old, same old. Most actual deployed applications of text analytics or text mining go something like this:

• A bunch of documents are analyzed to ascertain the ideas expressed in them.
• A count is made as to how many times each idea turns up.
• The application user notices any surprisingly large numbers, and as result of noticing pays attention to the corresponding ideas.

Often, it seems desirable to integrate text analytics with business intelligence and/or predictive analytics tools that operate on tabular data is. Even so, such integration is most commonly weak or nonexistent. Apart from the usual reasons for silos of automation, I blame this lack on a mismatch in precision, among other reasons. A 500% increase in mentions of a subject could be simple coincidence, or the result of a single identifiable press article. In comparison, a 5% increase in a conventional business metric might be much more important.

But in fairness, the text analytics innovation picture hasn’t been quite as bleak as what I’ve been painting so far. While standalone, passively-reported text analytics is indeed the baseline, there are some interesting exceptions. For example:

• I once confirmed that SPSS customer Cablecom‘s statistical models for churn and the like absolutely included text data; Cablecom even assigned different weights to the same apparent level of emotion depending on whether the text was in German, French, or Italian. Vertica recently told me of a Vertica/Hadoop customer doing something similar, except for the multilingual aspect. And the end of a 2008 SAS-based paper makes similar claims.
• There long* have been some examples of fact extraction that don’t really fit into my three buckets above. For example, researchers mine collections of articles to try to determine biochemical or biological pathways that would not be apparent from examining single research studies alone.
• It also has long* been the case that some bad-guy-finding applications — especially in the anti-terrorism area — used text analytics to populate state-of-the-art graph-oriented data analysis tools.

*When it comes to text analytics, “long” means “at least for the past several years.”

In more recent examples:

• Greenplum built a document recommender for law firms that does hard-core statistical analysis to determine which .1% of a document set lawyers might actually want to see, and which then learns from users’ feedback after they respond to initial result sets.
• Information extracted from investment news gets included into automated trading algorithms. This was unusual technology a couple of years ago, but is more common today.
• After a series of mergers, Attensity now uses marketing-oriented text analytics in at least three different ways:
  • Attensity text analytics feeds marketing dashboards just as it always did.
  • Attensity text analytics triggers alerts, as I wish dashboards and business intelligence tools more often did, the false positives problem notwithstanding.
  • Attensity text analytics triggers concrete workflows, for example routing specific social media hits for priority response.
  • And in one example that did not actually get into production, a very large social networking company correlated word usage (e.g., choice among different synonyms) against user characteristics such as age and gender.

Finally there are some applications that, while fitting the standard template, just strike me as getting to unusually sophisticated levels of analysis. For example, Vertica told me of another Vertica/Hadoop case where VotM document analysis is carried out to the level of observing which order brand names appear in, and adjusting that for whether or not it was just an alphabetical list.

I suspect text analytics is about to become more interesting again.

Related links

• The enabling technology for text/tabular data integration has existed for years.
• In 2006, I listed major application areas for data mining/predictive analytics. It overlaps pretty closely with the similar list for text mining/text analytics.
• Before being acquired by IBM, SPSS boasted a rather large text mining user base.

• TechCrunch got sold, GigaOm raised money, and VentureBeat/MediaBeat provided a good starting link for both those stories and more.  Since TechCrunch and GigaOm are/were both private, financial details are murky, but:
  • TechCrunch is variously reported as having revenue in the $6-10 million range, probably mainly from events. (If you believe that they sell ~3000 total tickets at ~$2000 each to two annual versions of TechCrunch Disrupt, that makes sense.)
  • GigaOm reports >10,000 subscribers to market research sevice (sort of) GigaOm Pro, at $199, apparently concentrated on the vendor side.
• John Gruber straightforwardly posts both ad rates and circulation for his blog. It’s a simple $5000/week for readership that exceeds mine by >1 order of magnitude.
• The New Yorker points out Gawker Media may not yet have crossed $20 million in revenue.
• An “ASCAP for news” seems to finally be on the way.
• Business Week/Bloomberg notices a trend that social-media/Voice of the Customer/Voice of the Market text analytics firms are getting acquired by bigger marketing-oriented firms. Seth Grimes, however, argues that the same trend is already passe’.
• TechCrunch accused the Wall Street Journal of killing a story about sister company MySpace, then quickly running it after TechCrunch caught them.
• LinkedIn has a really cool-looking tech blog. One recent post describes LinkedIn’s approach to socially-informed search. I read about it in a thoughtful post on Daniel Tunkelang’s blog.
• Bill Simmons took 3843 words to explain the story of a two-word tweet — “moss Vikings.” Somewhere in there are a few interesting ruminations about media in the current age.
• Some notes and links that actually belong here instead went up on DBMS 2 a few weeks ago.
• About half of what I write about liberty and privacy is highly relevant to the subjects of this blog, including almost all of today’s post.

Dear friend, How are you recently? I bought a laptop from a China company T0SHPD last week(the site is :www.toshpd1.com), and I received it now. The products are high quality with a very low price. They also sell mobile phones, TV, games, and so on. They are from Korea, Japan. You can go to their site to have a look, I am sure you will get many surprise and benefits. Best regards. h–)

It is in her Yahoo Mail Sent folder. It is not in the Sent folder for her desktop client (Outlook Express). Her computer passes a malware scan.

The site named first in the text looks to sell the kind of merchandise described. It has Whois record:

Domain Name: T0SHPD.COM
Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE
Whois Server: whois.melbourneit.com
Referral URL: http://www.melbourneit.com
Name Server: NS1.DNSPOOD.NET
Name Server: NS2.DNSPOOD.NET
Status: ok
Updated Date: 14-aug-2010
Creation Date: 14-aug-2010
Expiration Date: 14-aug-2011

Its Google footprint seems to be a few dozen copies of that spam message, plus the default hits one gets for any domain with a live site.

The site actually linked via the URL has Whois record:

Domain Name: TOSHPD1.COM
Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE
Whois Server: whois.melbourneit.com
Referral URL: http://www.melbourneit.com
Name Server: NS1.DNSPOOD.NET
Name Server: NS2.DNSPOOD.NET
Status: ok
Updated Date: 23-sep-2010
Creation Date: 23-sep-2010
Expiration Date: 23-sep-2011

Its Google footprint is very small.

The recipients are:

• Linda’s husband, daughter, daughter’s boyfriend, sister
• Linda’s close friend
• A mailing list to which Linda posts
• A friend with whom Linda has emailed exactly once in the past 3 decades
• A person whose name and address Linda doesn’t recognize

There’s no news of a Yahoo Mail attack going around that I could detect.

The password on Linda’s Yahoo Mail account (since changed) was not ridiculous, not brilliant, and not specific to that site alone. So the simplest theory is that her account was hit randomly, with her password being either:

• Guessed
• Repurposed from some other site she registered at.

Do any other plausible theories come to mind?

Be careful out there, people.

In particular, he argues:

• The value of journalism can only be assessed in connection with how people use it …
• … and their lack of enthusiasm about New Media news is a warning sign.
• Technology and form factor matter; imitating old media is likely not the best way to go.
• Personalization and targeting need to be a lot better. In particular:
  • What’s most important is getting stories to the people who are likely to want to act on what’s in them. The true value of journalism lies in informing people’s choices and actions. (By contrast, he seems to denigrate the other main benefits of news, which are pure entertainment and/or the facilitation of social interaction.)
  • It’s OK and natural that the people inclined to act — on  a given story or indeed at all — are only a small fraction of the overall population.

I am in vehement agreement with much of what Stray has to say, although I think he understates the importance of general knowledge and the often serendipitous benefits of pursuing same. For example:

• I tend to assume that what we write affects people’s choices by supporting their informed judgments.
• I think it is neither necessary nor acceptable to let investigative reporting wane.
• I have witheringly negative opinions about vacuous “news.”

And I indeed try to practice what Stray preaches. Most of my own posts — especially when you weight them by length and/or time spent researching and writing them — are designed to help at least some people make on-the-job decisions.

• I do just mean “help,” the assumption being that people read my work as part of a general research process.
• That lots of you read more for general interest or education is great. I suspect you still like the standard of quality to which I aspire, namely that what I write should in most cases actually be informative even to people who have reason to be well-informed in the area already.

There are still some things we need to do to preserve and extend the societal benefits of investigative reporting. But they are straightforward and very likely to happen.

Specifically, I recommend: 

• Public-spirited law-oriented types should do a better job of popularizing tips for how to get information out of government (Freedom of Information Act and all that). And back it up with more pro bono or charitably-funded legal assistance – not just for specific causes, but for general corruption investigations as well.
  • I’m sure quite a bit of that is happening, but it should be much more visible and active.
• Domain-specific websites should be created and promoted that seek out and call attention to negative stories in their particular areas, especially for specific industries or geographical regions.
  • A lot of those exist targeted at specific large companies people have grudges against, but otherwise they’re much too hard to find.
• Reporters need to be in the habit of seeking out stories first uncovered by other people.
  • They do this already, but they need to get better.

Below, at considerable length, is why I think those developments are both necessary and sufficient to carry the tradition of investigative journalism forward into the new media era.

For there to be public benefit from reporting, three things generally need to occur:

• Disclosure or discovery of the raw facts. Without that, you don’t have reporting or news.
• Analysis or interpretation. This stage can be optional when the purpose of news is entertainment, societal bonding, or whatever. But it’s pretty central to investigative journalism.
• Distribution and popularization. It doesn’t do much good to uncover an important story unless people notice and care about it. Old media, with its emphases on writing, curation, and physical distribution, almost defines itself by this stage. (E.g., “paper” is part of the word “newspaper.”)

Disclosure and discovery come in two main forms:

• Serendipity.
• Spadework.

The serendipity part often seems to work well in the new media. Let’s go to some examples.

• Wikileaks is a hugely successful case – people send Wikileaks documents or other files (a process that only makes sense with modern technology), and Wikileaks posts them.
  • Note: There was an  article yesterday about “internal strife” at Wikileaks – but the gist turned out to be that Wikileaks, already highly influential, could be doing even more than it already is.
• Michael Arrington found out about a meeting of major angel investors – perhaps originally via a tweet – and kicked off a major technology industry news story now known as “Angelgate”.
• An anonymous tipster spent 2 ½ hours IMing with me to reveal the true cause of the JP Morgan Chase site outages.
  • Motivation: Because s/he felt Chase’s technology organization was being unfairly maligned by prior coverage.
  • Why me: Because my previous speculative post about the JP Morgan Chase outages had shown up in the search engines and looked pretty credible.)
  • Result: Enough accurate tech details of a major consumer embarrassment to create a “teachable moment,” even though the concerned parties were trying to cover them up.
• An assisted living/nursing home in Dublin, Ohio called Friendship Village misbehaved toward my parents and me. I blogged about the problem, and it’s in the search engines now. If this turns out to be a pattern of behavior rather than an isolated incident, they’ll have some deserved trouble.

The story on the spadework side is more mixed. For example, there’s evidence I did as good a job on the JP Morgan Chase story as conventional media could today – Computerworld ran a story based on my post, without being able to uncover a single detail I hadn’t already found. But perhaps in the old-media-economics days, perhaps Computerworld would have had the resources to try harder and find something I didn’t. (E.g., I screwed up and didn’t actually get the details of the specific Oracle bug.) A bigger problem is outlined in this story on the uncovering of massive corruption in the California town of Bell. To wit (emphasis mine):

The new media ecosystem, in which citizen bloggers, small news outlets and big old-school media outlets effectively draw upon one another’s work to collaborate, didn’t quite work out in this case.

One blogger actually has anonymously and exhaustively alleged corruption in Bell for years …

The paper’s reporters say the blogger gave them tips. Though he’s a bit frustrated not to get more credit, he says the newspaper’s reporting muscle and much bigger audience gave life to the story in a way his website simply couldn’t. He counts his readers in the scores; The L.A. Times has hundreds of thousands of subscribers …

… some residents said they had gone to city hall to get their own answers. In essence, they were trying to do their own reporting on why their tax bills were so high and on rumors city officials were making a ton of money.

They got nowhere. …

“As a common citizen, I don’t know what my rights are with the city. I don’t know really how to attack them,” Sanchez said. “The Times, they have their legal departments. Of course, they’re able to get it more than a regular Joe like me.”

The citizens of Bell needed some place to turn for help, other than the overworked LA Times reporters who eventually uncovered the story on their own. Hence my first recommendation near the top of this post.

In many ways, analysis and interpretation work well in the new media era already. After all, there’s a whole world wide-web of self-appointed volunteer analysts on any issue you’d care to name! Yes, there are legitimate concerns about fragmentation and echo chambers, in which people only listen to the analysis of those folks who shared their biases to begin with. But those are hardly a barrier to muckraking – if anything, quite the contrary, as illustrated by the bogus ACORN prostitute/pimp advice scandal. (If your politics lean to the conservative side, think instead of something like a Michael Moore film.)

Or returning to the examples above:

• Wikileaks’ biggest leaks are widely analyzed by all sorts of commentators, including top-flight mainstream media people and a broad variety of online commentators alike. I’ll confess I didn’t find any analysis of Wikileaks’ revelations about, say, Iceland or the Turks & Caicos Islands, but I’ll also confess to not looking very hard.
• For the technology news uncovered respectively by Arrington and me, pretty much the ideal people to analyze it were, respectively – well, they were Arrington and me.
  • In the case of Angelgate, much other analysis (and news) ensued.
  • Analysis of the JP Morgan Chase outage details hasn’t yet gone all that far past me – but I already turned it into a “don’t make the same mistake JP Morgan Chase did” lesson.
• The Friendship Village case is being used as a cornerstone of my slowly-unfolding analysis of the general problem with medical records.

And that brings us to distribution and popularization. The most brilliant sleuthing in the world doesn’t help people very much if they – or their lawmakers/regulators/advisers/whatever – don’t find out about it.

• Wikileaks has that problem solved for its biggest leaks, but perhaps not for the others.
• Arrington’s TechCrunch is a top news outlet in his area, so the problem was automatically solved for him.
• DBMS 2 is a fairly serious outlet for database-related news. But in any case the JP Morgan Chase story was picked up by general trade press and financial-industry-specific press alike.
• As noted in the story on Bell, CA, nobody was paying attention to a blogger who apparently had worked quite a bit of it out.
• And if there’s anything you found lacking in my list of analysis/interpretation examples – well, if a story were picked up more broadly, then analysis/interpretation might also be stronger as well.

Almost nobody would ever see my Friendship Village story if I didn’t happen to own some websites with strong search engine authority. And how high it stays in the rankings as it ages still remains to be seen.

Possible answers take two main forms:

• Aggregation and curation,* in which various contributions are bundled together at go-to websites or the like.
• A reporting feeding chain, in which journalists with broader reach:
  • Steal/borrow/take ideas from more specialized contributors.
  • Repackage them.
  • Perhaps add additional value in reporting, analysis, or presentation. (Several examples of this may be found in the links above.)

Investigative reporting needs more of each.

*The latter is the more high-falutin’ version of the former.

Consider my story about Friendship Village. Standing alone, it’s not going to influence much of anybody, except insofar as I can personally influence the course of medical database design or privacy law. But suppose one person each reported similar things at 20 different institutions. A journalist who wrote a story based on those reports could carry a lot of sway, perhaps:

• Influencing the course of medical information exchange in the United States, or at least
• Alerting people to the lengths they have to go to get proper information about and before their sick relatives.

Similarly, suppose there were a go-to website for complaints about assisted living facilities. Well, people considering moving into Friendship Village would have a little concern to address. Even better, the very existence of that site might help motivate people to share more stories. Bad institutions would need to reform, and bad practices might be reformed under the spotlight of public scrutiny.

If this isn’t my longest blog post ever, it’s surely close. So while I have much more to say on these subjects, I’ll stop here. Comments and examples are warmly encouraged.

To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;

but that’s just a longer way of saying the same thing.

Why does “securing … exclusive Right[s]” to the creators of things that are patented, copyrighted, or trademarked help make it a good decision for them to create stuff? Because it averts competition from copiers, thus making the creator a monopolist in what s/he has created, allowing her to at least somewhat value-price her creation.

I.e., the core point of intellectual property rights is to prevent copying-based competition. By way of contrast, any other kind of intellectual property “right” should be viewed with great suspicion.

Examples of my views include:

• In a recent comment I pooh-poohed an expansive interpretation of the GPL, even as I supported the GPL in core cases.
• I believe that most kinds of software patents are or should be invalid, but I’m willing to make an exception for innovative user experiences.
• I believe in copyright, even though I agree with consensus that in many cases copyright-holders’ business models will evolve away from the licensing of intellectual property. For example, I’m mightily annoyed when somebody claims my words as their own. But I give mine away for free. I just want to get the reputational benefit of what I write, and also to aggregate comments on my original blog posts rather than having them go to some other site.

The embeds of the future will work for the company, and be paid by the company to provide news about the company in a multitude of formats. Print, newsletter, video, blog, podcast, moving billboards, tattoos — whatever it takes. Because the bits and pieces of Corporate America that have a story to tell will still have their stories – just no ready outlets.

How is this different than what you have today? Surely there are corporate PR departments and external agencies already doing these things, right?

No.

What is required is an internal producer who writes in external voice — like the neutral point-of-view so often described by Wikipedia. People can smell marketing and propaganda coming around the corner, and they know when the pitches and puff pieces are missing that edge of neutrality. An accurate and fair piece is accurate and fair, no matter who writes it.

It’s an interesting theory, but it seems to presuppose dual marketing communication efforts, with separate departments of “Straightforwardness” and “Hype”. That may work at some companies, but in most cases I think it will be more practical to try to infuse straightforwardness through multiple parts of the marcom effort.

My more specific quick responses include:

• That sure sounds a lot like Robert Scoble in his Microsoft days.
• It also sounds like “community managers” at MMO game companies. (Both of the MMOs I’ve played have had great ones.) They often only use one or two channels (forums and the associated general website), but otherwise they fit the bill.
• Ike’s views fit very well with mine on the future of the information ecosystem.
• I’m getting ever more sympathetic to the idea that you need people whose main job is external communication of a straightforward kind. Reasons include:
  • Senior executives who write great blogs commonly don’t keep them up. And even when they’re active, the blogging is pretty sparse. E.g., among companies I follow closely, Vertica, Aster Data, and Netezza have all done some outstanding blogging in the past, but do very little of it now. Only Dave Kellogg at Mark Logic really keeps going.
  • It’s not obvious that senior executives are wrong to spend their time at something other than blogging. One of the greatest vendor blogs ever was Jonathan Schwartz’s at Sun.  Umm — how sure are we that he actually did much good for his company with that effort?
  • I frequently tell vendors “If you tell Story X in your own words, I’ll gladly point to it or post it for you.” They usually agree this is a wonderful idea — but then usually don’t free up the rather limited resources that would be required to take me up on it.
• That said, the kinds of people who provide customer support (pre- or post-sales) are often very well suited to fill the role Ike is describing. At least, that’s the case in enterprise tech companies.
• The media mix isn’t really as complex as Ike was suggesting. It basically falls into two groups: Text, and audio/video.
• That said, text/graphics and audio/video media people are increasingly the same. (Just think of sports media, where the newspaper folks make their big bucks on radio or TV. That’s a harbinger of the future. Or think again of Scoble.)
• One flaw of Ike’s idea is that in its pure form it only makes sense for companies large enough to have multi-person PR staffs. Other firms would have to use part-timers, or outsource.  And if you’re going to do that, might it not make more sense to pay part of the cost of sponsoring, you guessed it, an independent blog?
• I know that’s text/graphics-only, or at least text/graphics-mainly, but I happen to think audio/visual business news/PR is minor anyway. People may give enough attention to, for example, listen to audio from a company if it purports to teach them something. But news ABOUT a company? Who’s so interested in that to sit still for audio/video, unless they happen to be employees, or investors in its stock?

Bottom line: I think he’s wrong about some of his detailed views, but Ike Pigott is directionally very right in suggesting that newsmakers will increasingly become content creators for news about themselves.

• For starters, let me link to some of the posts I’ve made pointing to April Fool’s pranks in past years, including:
  • (2009) A wonderful spoof of the analyst business
  • (2009) Donald Farmer’s hilarious version of business intelligence
  • (2009) The Guardian’s translation of its news and archives to tweets (“OMG Hitler invades Poland, allies declare war see tinyurl.com/b5×6e for more”)
  • (2009) Google’s world-dominating, blog-writing AI with the personality of a pre-adolescent girl
  • (2009) Expedia’s space-travel offering
  • (2008) Netezza’s green box
  • (2008) LOTRO’s spoof quests — like other MMO folks, the Lord Of The Rings Online guys can be really funny. (But in retrospect I’m not so sure they were spoofs so much as a new comedic option in the game introduced on a cleverly-chosen date.)
  • (2007) My attempt to one-up Scoble et al., without much success.
  • (2002) A classic: Google PigeonRank
• I found a couple of sites that catalog April Fool’s pranks around the world (not just techie ones). The Museum of Hoaxes offers a curated approach, so their list is pretty funny. Another site lists just about every web hoax anybody bothers to submit, so it’s quality is more mixed (and a lot of the links now don’t work).
• While thinking about this post, I recalled and posted about some software industry pranks. The MSA/M&D ones still boggle my mind, but I couldn’t think of much else to match them.
• And then, of course, there was the time this blonde joke made, as it were, the rounds.

Stancle had been accused of creating a Facebook profile belonging to a nonexistent teenage girl and then, between approximately the spring of 2007 and November of 2008, using it to convince more than 30 of his male classmates to send in nude photos or videos of themselves.

Stancl then reportedly threatened to post the photos or videos on the Internet if they didn’t engage in some sort of sexual activity with him. At least seven of them have said they were coerced into sex acts, which Stancl documented with a cell phone camera.

Stancl’s victims were teenage boys focused on sex — not exactly the world’s clearest thinkers. Even so, I find it remarkable that multiple people would:

1. Send nude photographs of themselves to a stranger.
2. Be so concerned about those photographs getting published online that they would submit to sexual blackmail.
3. Allow the results of their sexual blackmail to be photographed.

Literally — WTF??

• The generalities I posted a few years ago still apply (and, I think, are a good read in any case about the realities of analyst coverage).
• The updates a year and a half ago are still very accurate, although I might name different specific clients today.
• The partial client list from half a year ago is still pretty accurate, although Microsoft and Kognitio have dropped off, Clearpace changed its name to RainStor, and non-RDBMS analytic data management/analysis contenders Cloudera and Splunk have been added.
• While I have user clients, I have nothing to disclose about them.

One new development is that for the first time since 2001, I’ve taken stock in a private company. It’s Petascan, a seed/stealth-stage outfit with some very innovative ideas about how to use Flash memory in support of analytic data processing.  I’d like to do more of this, with conflicts evaluated on a case-by-case basis.  For example, I bet I could bring a lot of value to vertically-oriented analytics start-ups, who would at worst compete with only a small fraction each of the business of the more horizontally-oriented companies I generally write about.

For the past several years, we’ve had an annual refresh of our vendor service offerings, always unveiled in the fall. This year has seen more change than usual, and so I’d like to share some of the highlights with you here. A revampimg of our services for users is in the works as well, and I’ll share that too with you when it is finalized.

Aspects that haven’t changed much include:

• We ask all vendor clients to join a program called the Monash Advantage.
• Monash Advantage members get effectively unmetered quick-inquiry consulting, and more in-depth advice sessions as well.
• Our speaking and writing services, which vendors like to use for lead generation and general image-buffing, are generally restricted to Monash Advantage members
• The entry-level Monash Advantage price is $10,000/year

The biggest change from prior years is that there are now three tiers of the Monash Advantage, up from one.

• The Monash Advantage Lite is for small, tightly-focused companies with severe budget constraints. We offer suggestions and help them think through their most pressing issues, a few times each year.
• The Monash Advantage Basic is for more typical technology companies. We help them with anything and everything.
• The Monash Advantage Custom is for companies that want us to serve as core strategic advisors.

The early response to this tiering has been very positive, and we have had multiple sign-ups for 2010 at each of the three levels.

Another change is that we no longer require companies to join the Monash Advantage on a strict calendar-year basis. Now, it’s calendar quarters, and for Custom members we’re completely flexible.

Finally, we’re open to doing stock deals with seed-stage companies, at least ones that don’t compete closely with our other clients. For example, I’ve just started advising one stealth start-up in a hardware area that complements analytic DBMS, and I’m having a blast.  I’ll disclose the names of any companies I have private stock in, as well as offering at least a capsule of what is publicly known about what they’re pursuing.

]]> Monash Research highlights http://feedproxy.google.com/~r/monashreport/feed/~3/BSLBBn5q1QA/ I prepare most of my blog posts in OpenOffice. Most of the rest I write directly online in WordPress. I almost never use Microsoft Word. The reason, simply put, is cruft. When I copy a post from OpenOffice to WordPress, I invariably get a line at the top that looks like <!–         @page […] http://www.monashreport.com/?p=208 Thu, 03 Sep 2009 10:09:53 +0000 I prepare most of my blog posts in OpenOffice. Most of the rest I write directly online in WordPress. I almost never use Microsoft Word.

The reason, simply put, is cruft.

When I copy a post from OpenOffice to WordPress, I invariably get a line at the top that looks like

<!–         @page { size: 8.5in 11in; margin: 0.79in }         P { margin-bottom: 0.08in }     –>

I delete that, which according to OpenOffice stats amounts to exactly 100 characters; I fiddle with the bullet points a bit; I add a title, categories, and a MORE separator; and I’m basically good to go.

By way of contrast, in a recent post I copied a sentence from a press release I’d recieved across Google Mail in .DOC format, forgetting to stage it into OpenOffice first.  The cruft I needed to delete consisted of 6489 characters, namely:

<!– /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0; mso-font-charset:2; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:0 268435456 0 0 -2147483648 0;} @font-face {font-family:”MS Mincho”; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-alt:”ＭＳ 明朝“; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-536870145 1791491579 18 0 131231 0;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-format:other; mso-font-pitch:auto; mso-font-signature:3 0 0 0 1 0;} @font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1593833729 1073750107 16 0 415 0;} @font-face {font-family:”\@MS Mincho”; panose-1:2 2 6 9 4 2 5 8 3 4; mso-font-charset:128; mso-generic-font-family:modern; mso-font-pitch:fixed; mso-font-signature:-536870145 1791491579 18 0 131231 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:””; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; mso-layout-grid-align:none; text-autospace:none; font-size:12.0pt; font-family:Arial; mso-fareast-font-family:”MS Mincho”; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:JA;} h2 {mso-style-next:Normal; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; mso-outline-level:2; mso-layout-grid-align:none; text-autospace:none; font-size:12.0pt; font-family:Arial; mso-fareast-font-family:”MS Mincho”; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:JA; font-weight:normal;} h3 {mso-style-next:Normal; margin-top:12.0pt; margin-right:0in; margin-bottom:3.0pt; margin-left:0in; mso-pagination:widow-orphan; page-break-after:avoid; mso-outline-level:3; mso-layout-grid-align:none; text-autospace:none; font-size:13.0pt; font-family:Arial; mso-fareast-font-family:”MS Mincho”; mso-fareast-language:JA; font-weight:bold;} p.MsoCommentText, li.MsoCommentText, div.MsoCommentText {margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; mso-layout-grid-align:none; text-autospace:none; font-size:10.0pt; font-family:Arial; mso-fareast-font-family:”MS Mincho”; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:JA;} p.MsoHeader, li.MsoHeader, div.MsoHeader {margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; tab-stops:center 3.0in right 6.0in; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:”Times New Roman”; mso-fareast-font-family:”Times New Roman”;} p.MsoFooter, li.MsoFooter, div.MsoFooter {margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; tab-stops:center 3.0in right 6.0in; mso-layout-grid-align:none; text-autospace:none; font-size:12.0pt; font-family:Arial; mso-fareast-font-family:”MS Mincho”; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:JA;} span.MsoCommentReference {mso-ansi-font-size:8.0pt; mso-bidi-font-size:8.0pt;} a:link, span.MsoHyperlink {color:blue; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {color:#606420; text-decoration:underline; text-underline:single;} p {margin-right:0in; mso-margin-top-alt:auto; mso-margin-bottom-alt:auto; margin-left:0in; mso-pagination:widow-orphan; font-size:12.0pt; font-family:”Times New Roman”; mso-fareast-font-family:”Times New Roman”;} p.CommentSubject, li.CommentSubject, div.CommentSubject {mso-style-name:”Comment Subject”; mso-style-parent:”Comment Text”; mso-style-next:”Comment Text”; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; mso-layout-grid-align:none; text-autospace:none; font-size:10.0pt; font-family:Arial; mso-fareast-font-family:”MS Mincho”; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:JA; font-weight:bold;} p.BalloonText, li.BalloonText, div.BalloonText {mso-style-name:”Balloon Text”; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; mso-layout-grid-align:none; text-autospace:none; font-size:8.0pt; font-family:Tahoma; mso-fareast-font-family:”MS Mincho”; mso-bidi-font-family:”Times New Roman”; mso-fareast-language:JA;} span.stylearial10ptblack {mso-style-name:stylearial10ptblack;} span.body1 {mso-style-name:body1; mso-ansi-font-size:7.5pt; mso-bidi-font-size:7.5pt; mso-ascii-font-family:Verdana; mso-hansi-font-family:Verdana;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:-2; mso-list-type:simple; mso-list-template-ids:1315765622;} @list l0:level1 {mso-level-start-at:0; mso-level-number-format:bullet; mso-level-text:*; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:0in; text-indent:0in;} @list l1 {mso-list-id:508636615; mso-list-type:hybrid; mso-list-template-ids:775071060 1270362110 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:.25in; mso-level-number-position:left; margin-left:.25in; text-indent:-.25in; mso-ansi-font-size:9.0pt; font-family:Symbol; color:windowtext; mso-ansi-font-weight:normal; mso-ansi-font-style:normal;} @list l2 {mso-list-id:809203047; mso-list-type:hybrid; mso-list-template-ids:1745241986 1270362110 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} @list l2:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:.25in; mso-level-number-position:left; margin-left:.25in; text-indent:-.25in; mso-ansi-font-size:9.0pt; font-family:Symbol; color:windowtext; mso-ansi-font-weight:normal; mso-ansi-font-style:normal;} @list l3 {mso-list-id:1376927774; mso-list-type:hybrid; mso-list-template-ids:323012810 -557689488 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} @list l3:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:12.0pt; mso-bidi-font-size:11.0pt; font-family:Symbol; color:windowtext;} @list l0:level1 lfo1 {mso-level-numbering:continue; mso-level-text:; mso-level-tab-stop:none; mso-level-number-position:left; mso-level-legacy:yes; mso-level-legacy-indent:.25in; mso-level-legacy-space:0in; margin-left:0in; text-indent:0in; font-family:Symbol;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} –>

That’s a whole other level of annoying.

Meanwhile, this is as good a time as any to offer lyrics and music/video for the classic Leslie Fish filk song “Banned from Argo.”

Our proper, cool first officer was drugged with something green
And hauled into an alley, where he suffered things obscene
He sobered up in sickbay and he’s none the worse for wear
Except he’s somehow taught the bridge computer how to swear

Actually, this version has better sound and image quality, but the video part doesn’t speak to me.

Also:

• A collection of Dr. McCoy clips.
• A song combining Star Trek and The Hobbit.
• A video (large download) to Julia Ecklar’s beautiful song God Lives on Terra, with Star Trek:TNG clips interspersed with views of Wrentham, MA.  (I previously linked a hilarious parody of that song.)
• Another Bob Kanefsky parody song, this one based on a specific Star Trek episode. (Melody and performance by Leslie Fish.)

Overall, the interview went a lot better than my last one with the same station.