Complexity: How solutions end up as problems

Last time out I wrote about how snapshots have a visibility problem, meaning it’s difficult if not impossible to tell what’s inside them without having to look into each one.  Yet snapshots are a very effective way of capturing data quickly and often, especially for large data sets, so the use of snapshots continues to expand even while lack of visibility limits their effectiveness.

This limitation has not gone unnoticed, and work is being done to address it. But so far, the solutions I’ve seen suffer from an excess of complexity. There tend to be a lot of moving parts and multiple steps to get things done. Inevitably, when you have lots of parts and lots of connections between parts, things start to get brittle. A failure or mistaken configuration in one area can quickly cascade into problems everywhere, and then figuring out what went wrong can be incredibly difficult.

If you solve one problem (snapshot visibility) by creating another problem (complex, error prone infrastructure) are you really making progress?  

Complexity of IT architectures is a critically important element that sometimes gets overlooked. Certainly, IT vendors are never going to say their products are “complicated,” even when they are and when everyone knows they are. “Solutions” are always presented as easy to use, well integrated and so forth.  In fact, the very word “solution” is often an umbrella term hiding the fact that the “solution” consists of three or four different products (often acquired from other companies) loosely connected together in some way, which somehow always seems to require a month to get up and running correctly. But it all looks great on the PowerPoint slides!

Keep in mind: PowerPoint integration is easy. Real software and hardware integration is another matter.

And it’s not just getting it to work: it’s keeping it running without a staff full of PhD’s for every product you have. This staff problem is especially acute at smaller organizations that have a few IT generalists and can’t afford individual product experts. I was recently speaking to an IT manager at a small college. She told me how the product they were using for data protection required about six months of effort to become expert in. And then if that person happened to leave for another job, somebody new had to step in to the same learning curve.  It was an ongoing source of aggravation, to say nothing of high risk because until the new person got up to speed, backup and restore failures were all too common. And even when trained, data protection was complex enough to be a full-time job. For a small organization that should never be the case.

Complexity is definitely a problem in IT, and sometimes it’s made worse by something as simple as overly aggressive feature branding. Almost everything in an IT environment has a standard, well understood name. Yet some vendors just love giving their own unique names to common things. For example, a backup client is a backup client. Everyone handling data protection knows what “backup client” means. Then why do some vendors have to give it a special name to confuse the issue? It’s not the Product X Backup Client, it’s the Product X e-Protect Agent Source Node, which sends data to the e-Protect Target Receiver Grid Fabric, or whatever. (I just made up those names, so don’t go looking for this product!)

Jargon is always a bad thing. A great example of this is the hilarious spoof on bad jargon called “The Turbo Encabulator,” which was created at GMC Trucks in the 1970s. They were shooting some corporate videos when the actor hired to play an engineer decided to write up his own script filled with made up but realistic sounding jargon. It’s great fun. Here’s a tiny sample in text:

The original machine had a base-plate of pre-fabulated amulite, surmounted by a malleable logarithmic casing in such a way that the two spurving bearings were in a direct line with the pentametric fan. The latter consisted simply of six hydrocoptic marzelvanes, so fitted to the ambifacient lunar waneshaft that side fumbling was effectively prevented.

Ah yes, the hydrocoptic marzelvanes! I knew that.

Though fake, the Turbo Encabulator jargon is not wildly outside the realm of the believable, especially when you watch the actor presenting it in a deadpan, matter-of-fact way.  And it’s funny because we’ve all had to deal with confusing terminology before. But bad terminology is not funny because it really can create confusion that interferes with productivity and increases the chance of mistakes.

So vendors, keep it simple whenever you can. That might annoy someone in your engineering department or, for that matter, in your marketing department, someone who just loves giving unique names to everything. But better to annoy that person than to frustrate your customers.  

Computerworld's IT Salary Survey 2017 results
Shop Tech Products at Amazon