24 November 2013

Marky Mark and the Funky Bunch

So, who or what, the hell is MarkLogic? For one thing, it's sometimes Mark Logic and other times MarkLogic. Since I left my Clark Kent memorial fedora, complete with press pass, at Superman's phone booth, what follows (modulo my speculation) is gleaned from the InnterTubes. In sum: not so sure I'd bet the farm on these guys for an HIE style application. Somebody, whom I've not identified, is responsible for choosing them to run that "core" of healthcare.gov. Them new duds the Emperor's got sure impressed somebody.

Its site says it's been around since 2001, yet slurped $25 million more in VC money recently. Twelve years in being the greatest thing since high button shows, and still living off the VCs? That and the named managers, from CEO on down, turn over about as fast as "want fries with that?" voices at Mickey D's. Something's not quite right. Still private, so financials aren't available. By comparison (and MarkLogic's promotional lit goes after them), when Oracle was ten years out from its first release (1989) it was a public company with $584 million (in 1989 dollars, mind) revenue. "And you don't mess around with Jim."

Let's start with some promotional slides, circa 2011, here. The slides are marked "confidential". Hehe.

Slide 23 - they're touting the CMS Health Insurance Exchange: "Massive amounts of data at high velocity; highly transactional" not so much, when the rubber hit the road

Slide 34 - they admit (though likely not bright enough to know it) that they've re-invented IMS: "Information is stored as XML (hierarchical)" Kiddies just can't stop building pyramids; perhaps we should rename these Madoff Information Systems (MIS, rebooted from the 70s)

What the Kiddies don't get is that hierarchies (whether in semi-binary as IMS, or clear text as xml) are built to support *a single*, hard coded, optimized access path. And that's for reading. Any other path may be impossible, and will be at least difficult. Changing the structure of the hierarchy requires changing any code which uses said hierarchy, since some (even most) Stations of the Cross have been moved. Dr. Codd figured out the problem: with an easily fungible relational structure (and sensible queries) adding tables or columns will be transparent to existing queries; those that don't need the added data may ignore it. Orthogonal is a very good thing. Too bad the Kiddies never figured that part out. The Kiddies insist that re-inventing IMS is progress. Yeah, right.

The tenor of the deck (hard not to insert the obligatory r) is MarkLogic as a Master Data Management implementation, although that term is kind of passe' most places these days.

Another of their buzz sentences: "Database and search engine are the same" as if this were any different from real RDBMS, or IMS for that matter

Since I'm willing to risk being accused of ad hominum behaviour, here's what the founder, Christopher Lindblad, did before MarkLogic
Chris founded MarkLogic while working as an architect on Ultraseek Server, Infoseek's enterprise search application, which is now one of Autonomy's principal products following the acquisition of Verity.

Here's the dirt: Infoseek was crap, Ultraseek got passed around like a plate of week old baked beans until Autonomy ultimately ended up with it, and who was the mess that H-P way, way overpaid for. And, "principal product"?, no it isn't: "Under Autonomy, Ultraseek continues to be developed and marketed as Autonomy's entry-level keyword-based site search offering." Not something to brag about, no. "Try not! Do, or do not, there is no try" The point: HIE is an OLTP application, not a Google. If the only tool you have is a hammer, everything tends to look like a nail. Not do OLTP from a doc store; there is no try.

As I posited in an earlier post, Kiddies assume that search *is* computing and that hierarchies are the bee's knees of datastores; and they aren't. While there may be some part of ACA implementation that will benefit from blob/clob data bits, the guts are OLTP/POS. And they ain't nothing better than an industrial strength RDBMS for that. If it starts in Organic Normal Form™, morphing the schema as you go isn't such a big deal. Lots of schema migration apps out there to help, if you feel the need. Remember: orthogonal is your friend. Cleave to orthogonal; as the adverts used to say, "Calgon, take me away!" Hierarchies ain't, they're as mixed up as a Christmas fruit cake.

The really big deal here is the federation with Federal, state, and insurance company systems. That's the crunchy part. There are multi-database federation protocols out there, including in SQL-2003; it's called Foreign Data Wrappers in PG terms, SQL/MED (Management of External Data) officially. DB2 provides the most robust, cross-vendor federation (likely because it has to!). Oracle does too, of course using its own semantics (took them a while to wean themselves off CONNECT BY for CTE syntax, of course). Progress (you remember it, right?) offered federation in the early 90s.

This is a classic distributed database application. Full stop. No need for NoSql. There is no try.

No comments: