When Zombie Aerostats (or IT Projects) Attack!

Being from eastern Pennsylvania, I was surprised to find myself watching the news a week ago as an unmanned runaway blimp (yes, you read that right) became untethered from its station point in Maryland and floated north over my home state for several hours before finally crashing back to earth.

There was definitely some entertainment value and novelty to all of this. Notwithstanding the poor people who lost electricity for a while when its tether cable knocked into powerlines, a rogue aerostat just isn't something you see every day.

But the larger story — and one that made me think of our coverage at Waters — is really around what the blimp was supposed to be doing, and why it wasn't doing that thing, as part of the military's experimental Joint Land Attack Cruise Missile Defense Elevated Netted Sensor System, or JLENS.

The best summary I've read of the sordid history and travails of JLENS comes from the Los Angeles Times. I highly recommend that anyone interested in bad defense spending or tech gone wrong read David Willman's definitive account of it.

In short, the multi-billion-dollar project should've died long ago (and finally, this week, the plug was pulled) but managed to hang on as a so-called "zombie" project for years because of shrewd lobbying, the support of key ranking military personnel and the evident need for better air surveillance tools after the September 11 attacks.

Key dependencies (or interdependence) are still a massive challenge to solve for, and this is especially the case for technologies whose purpose is to monitor multiple vectors at once, and disciminate between potential problems and false positives. As young platforms are built out for new problems of this variety, such as cyber security, it has to be top of mind.

JLENS was supposed to provide this. How? The simple explanation is that airborne radar can track a much wider area than radar on the ground or at sea. But JLENS never got there, in part because of technology problems.

The company contracted to manage the project, Raytheon, could never get the communications (netting) software to work right, so JLENS never properly integrated into the military's larger surveillance operations. This also meant one of the blimps, which were designed to work in pairs, was rendered useless. And even when the system was functional, it had trouble discriminating between benign and potentially dangerous low-flying objects.

Apparently the kevlar tethers weren't so great, either.

Fear Zombies

I never thought I would be comparing financial technology to an ill-fated surveillance system that relied on unmanned blimps, but there are some decent lessons to be learned here. And aerostats do make for good finance metaphors.

First and foremost, any chief technologist will be familiar with the zombie concept. Almost every large asset manager and bank has a few of these failed, costly and yet seemingly interminable projects in their shop.

Why? To me, it all goes back to bad project conceptualization and fitting square pegs in round holes. The LA Times article makes the point that the kinds of problems JLENS could solve for evolved over time, eventually to even include things like truck bombs parked in Times Square.

Similar wandering of purpose has often dogged financial IT projects, from book-of-record (IBOR, PBOR) implementations to trying to break down data governance silos. In most of these cases, the failure occurs when ambition doesn't match wherewithal. When something is suddenly the solution for everything, that should raise an eyebrow.

The second lesson is about design. The more embattled JLENS got, the more it began to be treated as a black box. Strangely, you could say the longer it stuck around, the less chance it actually had of being properly netted. And the interdependence of one blimp's function to the other meant neither could be useful.

Obviously in our context, this lesson has been learned many times over. Proponents of anything-as-a-service will cheer. But key dependencies (or interdependence) are still a massive challenge to solve for, and this is especially the case for technologies whose purpose is to monitor multiple vectors at once, and discriminate between potential problems and false positives. As young platforms are built out for new problems of this variety, such as cyber security, it has to be top of mind.

Of course ...

A third and final item: Murphy's Law tends to affect crappy projects disproportionately, or at least it feels that way. Of course the blimp's tether was going to snap; of course the program would become the butt end of jokes for a few days, and prove an embarrassment in its demise.

Most good technologists have an eye for a white elephant or zombie when they see one, and being conservative as most of them are, they'll hedge and take preventative measures before one gets caught in the wind and flies away on them.

Still, the better idea is to just avoid that from the word 'go' with narrowly-defined concept and simple design, and by tuning out the persuasion of entrenched interests.

Perhaps also: avoid anything floating in the air at low orbit. But even for finance, that is easier said than done.