Month: July 2024

I remember having a discussion with one of my executive buddies a while back, talking about this whole business of shoving IT up into the “Cloud” and away from in-house (local) processing.  My buddy, (who is still very active in business) stated that he would never, ever do that because of control concerns;  I went even further and said that were I the CEO of a corporation and an executive even suggested such an action to me, I’d fire him on the turn.

Here’s the reason for my intransigence, and it’s a topic I’ve banged on about before:  the allure of “convenience” without caring about (or intentionally disregarding) the risk of vulnerability.  Here’s an example in a microcosm.

Back in the late 1980s and early 1990s we still did a lot of paper printing, as email communication of large files and documents was beyond the ability of most systems to accomplish large-scale dissemination.  At the same time, though, systems were changing from stand-alone processing into networked systems, and the most obvious of these was in the area of shared printers (as opposed to each workstation having its own printer).

Of course, IT was all over the networked printing principle because, as one clueless IT person told me, “we only have to maintain and service one printer as opposed to dealing with several, so it’s more productive” — confusing, as I pointed out to him, their convenience with the user’s needs.

What, I asked him, was the point of sharing a single device when there’s a traffic jam of users waiting around the printer for their job to clear the queue?  How productive was that, in the corporate sense, when one service technician would save time while half a dozen other workers were doing nothing?  And even worse, of course, was the prospect of the printer failing altogether (for whatever reason), causing everybody to sit on their hands while the machine was being fixed or having its ink cartridge replaced;  how productive was that scenario?

As I was beating my head against a corporate brick wall, I did what I normally do in such circumstances:  I declared unilateral independence.  I bought myself one of those HP500 inkjet printers (and black-ink cartridges) out of my own pocket and remained outside the system altogether, to the consternation of IT.  (My boss, bless him, told them to go and fuck themselves — those exact words — when they asked him to strong-arm me into compliance.)

Then over the following six months I monitored the network printer activity and catalogued all the times it went down, then calculated the net cost to departmental productivity, and presented my findings to Management at our next inter-departmental meeting.  (Basically, if the five largest users of the printers in our department had each had their own HP500, the department would have saved literally thousands of dollars in lost productivity.  In fact, it would have been a zero-sum decision to equip each of those users with their own laser printer, never mind a cheapie HP500, and left “casual” printing — memos, etc. — on the network.)

I won the battle and lost the war, because IT took its revenge on me from then on by slow-walking all my projects — and I did a lot of those — through the system, using the “limited resources” argument because, I admit, my projects were resource intensive.

It did not help matters when personal computers came along.  Of course, I was the first one to get one (out of my own pocket, again), enabling me to do a huge amount of developmental work independently of IT.  The head of IT came into my office and asked me to give him a demonstration of my PC.  I agreed to do it, but only after inviting my boss to sit in.  Then I ran one of my routines on the PC and we sat for about ten minutes waiting for it to process.  Of course, the IT guy sneered at the pace of the process, saying that the mainframe could have done the same job in seconds.

I then pointed out to my boss that the last time I had submitted an identical job through IT, I’d eventually got the output some three days later.  (And yes, I had the documentation to substantiate it.)

My boss, bless him again, asked me if I could set up a PC for him because he too was sick of waiting for his jobs to get back to him.

A week later, Management received a proposal from IT to set up dumb terminals in all our offices so that we users would not have to become our own computer programmers.  It was accepted by all the department managers except mine, who had in the interim found room in the budget to buy PCs for all the account executives, and tasked me with developing and delivering the necessary training.  (I outsourced it to a buddy’s training company because I had things called “clients” who had greater need of my time.)

Anyway, I told you all that so I could talk about this.

You see, apart from any talk of productivity and convenience, the dirty little downside to Cloud-based single-source processing is that having a single source also means that there is an enormous risk when any bad actor or even incompetent actor (such as in the above case) gets to access the whole show.  Single source also means incredibly-dangerous universal failure scenarios.

Ask the airlines, banks and hospitals affected by the above.  And incidentally, state vehicle inspections in our area of north Texas were also affected in that their inspection equipment failed to operate — and the operators didn’t bother coming into work because why should they?  And even when the systems did start working again, there was still a delay while the operators came back from their absence — machines and systems working:  nobody to operate them.

As I discovered two days ago when I took my car in to be inspected, at two different locations hereabouts.

Now scroll back up and re-read the first paragraph of this post.