Back in October I posted about the virtues of SQL and asked the question: what will replace it in a NoSQL/NewSQL hybrid world?

Don’t get me wrong: I dislike SQL as a programming language; I think it’s an awful kludge, and something inside me cringes every time I use it.  (Although, to be fair to SQL, I kind of feel that way about all the functional programming languages I’ve ever used: Prolog, (functional) LISP.  Functional programming bugs me the same way having to wait for the waiter to bring water bugs me when I’m thirsty and I can see the pitcher of water eight feet away at the waitstaff podium… but we disgress.)

But SQL has the virtue of separating the details of data storage and retrieval from the details of application logic, and we badly need something like that going forward.

As it happens, the relational paradigm itself is under attack from NoSQL approaches (or it should be; I never really liked the relational paradigm much, either; it has a heck of a time with anything “complex” (join-y, recursive-y, set-y), and doesn’t do such a great job on things that are simple, either.  But we digres…)

So maybe we can kill two birds with one stone: advance beyond the relational paradigm and start an API to data (even if not yet a language) that is agnostic about the structured-ness of the underlying data.

I guess I’m going to out completely here, and say that I also hate XML sublanguages by and large.  They are bloated, difficult to compute on, and PL/1-ish.  With exceptions, perhaps.

But something on the order of abstraction of RDF sounds like the “new relational” to me.  Even after the rise and fall of the “triples empire” some years ago.  A simple atomic relationship binding two entities together seems like a logical place to start.

As usual, I’m way out of my depth here.  I hope someone who actually knows something about these matters will step in.  But I do feel obliged to bring the matter up.

Your thoughts?

As I said in an article I wrote for the Cutter IT Journal in May, if I had lost my PC’s connection to the Internet even as late as 1999 or 2000 it would have been an inconvenience, but if I lost it today the thing would be close to a brick as far as its use for me.

Times have changed.

I’ve migrated, slowly but steadily, from thick-client PC-based applications to cloud-based applications that run on my PC, my Android phone, and my iPad.

I still love the rich interaction and aptness of the interaction in a good thick app.  Even today the JavaScript etc. interactive tricks don’t hold a candle to a good local interaction with both UI/UX and business logic right nearby rather than a variable-latency roundtrip away.

But today I prize the ability to run on all my clients more than I prize the excellence of the interaction on any of them.  And that factor — the need for sync — has driven me inexorably toward cloud-based apps.

Some of which are quite good.  Don’t get me wrong.  Apps like ToodleDo and Zite and even some of the Twitter client stuff are getting there.  But I’m using them on one platform because I want to access them on all.

Thoughts on your app migration towards the cloud?

I hate coining buzzwords.  And maybe I didn’t even coin this one.  But we need some phrase to describe the following problem:

Data now comes in two processable flavors: structured and unstructured.  And stacks now exist for processing either flavor.  But each world is undergoing transformation.  And how the two worlds will be combined is up in the air.

Unstructured data: whether or not the Hadoop ecosystem is The Answer, there is vigorous experimentation with how to work with massive amounts and velocities of unstructured data, and there are some emerging norms.  Other NoSQL approaches remain as alternatives, and there will probably be use cases for almost all of them.  We are not even near the end of the beginning when it comes to defining how unstructured data systems will interface with applications (where is the NoSQL SQL?), and we are IMHO still at the very beginning of understanding what storage systems are optimized for these workloads.

Structured data: with NewSQL databases, it is clear how to interface them with applications but far from clear how they work with storage systems, particularly SSD-based storage systems.  Jury is out as well on how to multiplex the different databases in a use case.

I call of this “data management infrastructure”, and it seems to me like an emerging big design problem.

Thoughts?  Who’s working on this?  Where should we invest?

I blogged here last week about my “big wind/capable team” heuristic for picking startup investments.  Today I’d like to go into a bit more detail about the “big wind” part.

A Big Wind is a transformation of a large customer spend from one category to another.  It’s almost the same thing as Geoffrey Moore’s idea of a “tornado”, which is a phase in a market when the (relatively) vast Early Majority group decides to adopt a new approach.  Moving suddenly from “show me” to “must have”, the Early Majority creates a “tornado” of demand.  Examples: the PC “revolution”, networked storage systems, scale-out servers.

Smartphones are in the midst of a tornado-like Big Wind.  Sweeping away RIM and Nokia and perhaps Microsoft.  Sweeping in Apple and Google.

Maybe tornadoes are the only kind of Big Wind that exists, but in any case, most of the examples I can think of are tornadoes.  Maybe the ERP implementation at the end of the last century was a Big Wind without being a tornado.  It was driven in large part by Y2K FUD, not by a transformation of the Early Majority to a new approach.

Great example of not a Big Wind: healthcare IT so far.  Big market, but no transformation of spend (yet).  Right now only early adopters are embracing end-to-end IT for their health businesses.  The early majority is hanging back, saying “show me.”  It may tip.

Your thoughts?

Watching the Euro community grapple with and fail (or so it seems) under the onslaught of treaty country performance, I’m minded of how I think about VC strategy, and what it means for what they’re doing.

I rate investments by two criteria: Is it a Big Wind, and is it a Capable Team.  There is a third as well, but it’s irrelevant to this discussion.

A Big Wind is a market opportunity where lots of money will change hands.  And Capable Team is a team that can seize the opportunity and ride it out despite all twists and turns (and there are always twists and turns).

So we invest, and things don’t go well.  Like Greece, the company’s income is less than its expenses.  Over time.  Repeatedly.  Without apparent hope of things turning around on their own.

I’ve developed a 2×2 grid for asking what to do with a company based on evolving circumstances.  It looks like this:

Presentation1.pptx
Download this file

If the wind is big and the team is capable, you don’t need to do anything: you let ’em rip.

If the wind is big but the team isn’t capable, you topgrade the team until they become capable.

If the wind is small but the team is capable, you pivot.  You find a new wind, or a better take on the existing wind.

If the wind is small and the team is incapable, you let it go.  You sell it, you shut it down.  You dispose of it.

The Euro community is foundering.  I don’t know enough to know if the wind is small or the team incapable, or both, but someone should make this analysis if they want the community to survive.

What the community is doing instead, and what a lot of VC firms do instead, is probably the worst of all possible worlds: put the incapable team on a starvation budget so they can’t possibly take advantage of a big wind, but at least they won’t go under right away.

It’s neither fish nor flesh nor fowl.  And it won’t serve the Euro community any better than the same strategy serves us in trying to get our startups to thrive.

Your thoughts?

I got an Arduino for Fathers’ Day from my son, and an Arduino Cookbook from my wife.

The Maker Movement just went personal for me.

In case you don’t know what the Maker Movement is, it’s a bottom-up movement of hardware tinkerers, largely hobbyists today, which I believe will revolutionize manufacturing and basically end the Industrial Revolution (or cause a new one, depending on how you look at it).

In case you don’t know what an Arduino is, it’s a popular open-source hardware module with a programmable controller and some I/O junk that sells for ~$20 and is pretty easy to program.

(That’s pretty easy for me to see; I haven’t programmed it yet.  Catch up with me a few weeks and see how easy I think it is.)

First application?  My son suggested I make a gizmo to automatically power-cycle my cable modem.  Not a bad idea, although my ISP says you should disconnect the coax cable as part of the process, which means some way to interrupt the coax.

First step in any project of this source: scour what my son calls “the InterTubes” for prior art.  I’ll start on that this week.

Very cool stuff, at least for me.

The Cutter IT Journal just published an article of mine along these lines.  I’m a big fan of analogies, and the ’80’s presents a lot of analogies to today’s world: new disruptive platform, specialized apps as the key, ultimate disruption of an entire IT paradigm.

Here’s a link to the Cutter IT Journal issue.  For some legacy-ish reason, Cutter Consortium will let you download a pdf of the journal but won’t put it online.

As always, let me know your thoughts.

I finally received a reply to my email to United/Continental re the Seat Snafu on May 18.

As one might expect, it was empty, impersonal, and non-committal:

CustomerCare@united.com customercare@united.com	11:46 PM (9 hours ago)
to me

We’ve started to think of our various digital media investments as ways of aggregating and/or monetizing a digital audience.  Obvious, perhaps, but leads us to think about things in new ways.

Consider ecommerce, for example.  From the standpoint of audience, ecommerce is a way of attracting an audience by interesting them in buying something.  An ecommerce site has, in this way, a lot in common with a content site:

• The research for the purchase is of course, great content in and of itself.
• The merchandising of the purchase, aside from not derailing the transaction, can please and delight the customer as well
• The cross-sell and up-sell options are opportunities to start new cycles of research, merchandising, and purchase

It’s a bit like playing cards for money as opposed to playing cards for fun.  The cards pull in the audience, and playing for money makes the cards more exciting.