This post’s title is one of my favorite sayings because it perfectly captures our conflicting attitudes toward change. Intellectually, people know that change is necessary for advancement, but emotionally, most of us still don’t like it.
Happily, for companies like Mark Logic, there are always some brave souls willing to try changing the way they do things. Sometimes these people are driven to change by external forces (e.g., publishers who know that objects like Google in the rear-view mirror are indeed closer than they appear). Sometimes, they’re just adventurous spirits working in groups dedicated to technology exploration. Sometimes, they’re open to change simply because the mission is too important not to be (e.g., preventing terrorism).
The idea for this post came to me during a recent sales call. We were visiting a publisher which was looking to replace its search engine because it was expensive, hard to configure, and under-performing expectations. Moreover, the supplier was discontinuing support of the product, forcing a potential upgrade.
The good news was that these folks had found Mark Logic and were willing to hear what we had to say. But I was worried they were “wedged” in a search paradigm. As I said on the call:
If you’re just looking to replace your search engine the way you might change the oil filter in a car, then you should just go do that; there are plenty of them out there. If, however, you’re looking to change the way you build information products, to add enormous agility to that process, and to save the expense of buying and integrating a search engine and a DBMS to boot, then you should consider Mark Logic.
Look. The paradigm defines the outcome. If you spec a vehicle as requiring wooden wheels, a spring-loaded bench, leather reins, a hand brake, and a low hay/mile consumption rate, then you are never, ever going to come up with a car.
The fact is that disruptive technologies almost never have every feature of those they replace, especially at first. (Recall that it took about a decade for the relational DBMS to become production OLTP worthy.)
So if you want to stare at Mark Logic through an enterprise search engine lens, happily you will find that it has a lot of things that search engines don’t (e.g., read/write, transactions, database-style query language). But you’ll also find it’s missing a few things that search engines do have (e.g., a recent, now-neutralized example of this is proximity search – see aside below).
But that’s not the point. If you remove the search engine lens and frame the question not as “do you have reins and a hand brake” but instead as “what’s the best vehicle to get from A to B” — i.e., “what’s the best platform on which to build new information products” — then you’ll find the answer is most certainly Mark Logic and I can find about 30 happy publishers who’ll confirm that.
Time will tell where this customer ends up. They were great people, and we had a great meeting, so I hope they’ll choose to work with us. Either way, I feel for them since it’s never easy facing these sorts of challenges.
Like the headline says: change is good, but you go first.
Aside on Proximity Search
Proximity search is the name of a feature that lets you find all documents where word-A is within N words of word-B. It’s a popular search engine feature and until version 3, something that MarkLogic lacked. I like to talk about proximity because it provides a fascinating example related to disruptive change.
From a purist XML content server perspective, proximity search is a hack, a workaround to a problem that enterprise search engines face.
For example, if you want to find all contracts governed by Texas law, you could use your enterprise search engine to do a simple keyword search on “Texas” and “governing.” But say your company’s in Texas, so every contract has Texas in numerous address blocks. And every contract presumably also has a governing law section. So your query will return literally every contract in your database. Not so useful.
Proximity search addresses this problem by letting you say: find all documents where “governing” is within 10 words of “Texas”. It’s not a bad fix, if you’re enterprise search vendor.
But an XML person sees this problem differently: XML has structure, so use it. The search becomes: find all documents with a section-heading element that contains “governing” and that contain “Texas” in the first paragraph of the subsequent section. You don’t need proximity to answer this question in an XML content server.
So think about this: we get asked to add a feature in our product that was added to one of the technologies we’re replacing in order to fix a limitation in what they had. Wow. It’s a bit like asking for blinders for your car’s headlights.
But we did it. Why? Because proximity’s still useful in an XML content server, because XML-aware proximity is even cooler (find these elements near those elements), and because it’s about 10x easier to tell this story when our product contains proximity then when it doesn’t. Interesting, n’est-ce pas?
