In case you missed the news, Israeli scientists have taught a goldfish how to drive.

Well, not exactly. They placed it in a bowl with various sensors and actuators, and it correlated its initially random movements to which movements moved it toward food.

The goldfish, that is, figured out how to drive the way DeepMind figured out how to win at Atari games.

This is the technology – machine-learning AI – whose proponents advocate using for business decision-making.

I say we should turn over business decision-making to goldfish, not machine learning AIs. They cost less and ask for nothing except food flakes and an occasional aquarium cleaning. They’ll even reproduce, creating new business decision-makers far more cheaply than any manufactured neural network.

And with what we’re learning about epigenetic heritability, it’s even possible their offspring will be pre-trained when they hatch.

It’s just the future we’ve all dreamed of: If we have jobs at all we’ll find ourselves studying ichthyology to get better at “managing up.” Meanwhile, our various piscine overseers will vie for the best corner koi ponds.

Which brings us to a subject I can’t believe I haven’t written about before: the Human/Machine Relationship Index, or HMRI, which Scott Lee and I introduced in The Cognitive Enterprise (Meghan-Kiffer Press, 2015). It’s a metric useful for planning where and how to incorporate artificial intelligence technologies, included but not limited to machine learning, into the enterprise.

The HMRI ranges from +2 to -2. The more positive the number, the more humans remain in control.

And no, just because somewhere back in the technology’s history a programmer was involved that doesn’t mean the HMRI = +2. The HMRI describes the technology in action, not in development. To give you a sense of how it works:

+2: Humans are in charge. Examples: industrial robots, Davinci surgical robots.

+1: Humans can choose to obey or ignore the technology. Examples: GPS navigation, cruise control.

0: Technology provides information and other capabilities to humans. Examples:Traditional information systems, like ERP and CRM suites.

-1: Humans must obey. Machines tell humans what they must do. Examples: Automated Call Distributors, Business Process Automation.

-2: All humans within the AI’s domain must obey. Machines set their own agenda, decide what’s needed to achieve it, and, if humans are needed, tell them what to do and when to do it. Potential examples: AI-based medical diagnostics and prescribed therapies, AIs added to boards of directors, Skynet.

A lot of what I’ve read over the years regarding AI’s potential in the enterprise talks about freeing up humans to “do what humans do best.”

The theory, if I might use the term “theory” in its “please believe this utterly preposterous propaganda” sense, is that humans are intrinsically better than machines with respect to some sorts of capabilities. Common examples are judgment, innovation, and the ability to deal with exceptions.

But judgment is exactly what machine learning’s proponents are working hard to get machines to do – to find patterns in masses of data that will help business leaders prevent the bad judgement of employees they don’t, if we’re being honest with each other, trust very much.

As for innovation, what fraction of the workforce is encouraged to innovate and are in a position to do so and to make their innovations real? The answer is, almost none because even if an employee comes up with an innovative idea, there’s no budget to support it, no time in their schedule to work on it, and lots of political infighting it has to integrate into.

That leaves exceptions. But the most acceptable way of handling exceptions is to massage them into a form the established business processes … now executed by automation … can handle. Oh, well.

Bob’s last word: Back in the 20th century I contrasted mainframe and personal computing systems architectures: Mainframe architectures place technology at the core and human beings at the periphery, feeding and caring for it so it keeps on keeping on. Personal computing, in contrast, puts a human being in the middle and serves as a gateway to a universe of resources.

Machine learning is a replay. We can either put machines at the heart of things, relegating to humans only what machines can’t master, or we can think in terms of computer-enhanced humanity – something we experience every day with GPS and Wikipedia.

Yes, computer-enhanced humanity is messier. But given a choice, I’d like our collective HMRI to be a positive number.

Bob’s sales pitch: is running the most recent addition to my IT 101 series. It’s titled The savvy CIO’s secret weapon: Your IT team | CIO .

Last week, posing as Tinkerbell, I asked you to let me know if you still find KJR valuable. Hundreds of readers took the time to answer in the affirmative.

For a writer, there’s no greater gift than having an audience. Thank you all for letting me know my weekly sermons are still useful.

# # #

I guess I’ll have to publish it here.

You might have already seen the now-not-so-recent piece on The Wall Street Journal’s editorial page, titled “It’s Time to Get Rid of the IT Department.” (Joe Peppard, 11/27/2021).

It isn’t all that different from Nicholas Carr’s tiresome and business-illiterate “IT Doesn’t Matter,” which, in 2003, led to his earning the Rocky and Bullwinkle Wrongway Peachfuzz award for polar opposite prediction. After all, here in the present, IT saved the world economy by enabling remote work during the COVID-19 pandemic.

That was after it became the centerpiece of business strategy, driving the Digital revolution.

Highly visible yet profoundly wrong ideas, even if they’re mere rehashes, require rebuttal, but the WSJ, by editorial page policy, doesn’t accept rebuttals. I guess they don’t like to be contradicted.

So I’ll have to publish my nominees for Mr. Peppard’s wrongest propositions here. Feel free to share.

Proposition #1: IT is a box on the org chart, with its own management hierarchy and budget, and that’s a problem.

KJR rebuttal: If a box, managers, and a budget are problems, they’re problems for every business function in the enterprise. Why single out IT?

Proposition #2: IT-as-partner is a bad thing. And I quote, The problem starts with what I think of as the “partnership engagement model” … While intuitively appealing  this model positions the IT island as a supplier, mandated to build IT solutions and deliver services to the mainland.

KJR rebuttal: Say what? IT as partner … more precisely, IT as partner in achieving intentional business change … is the polar opposite of IT as supplier to internal customers.

Proposition #3: IT is measured on inputs, not outputs. Examples: money spent, system availability, project completion rates, and, OMG! deploying technology on time, on budget and meeting the specs. These don’t, Mr. Peppard tells us, correlate with success.

KJR rebuttal: So fix the metrics. The solution to measuring something wrong isn’t to eliminate what’s being measured. And oh, by the way, if the specs are right, meeting them does correlate with success. If the specs turn out to be wrong, fix the process used to create the specs.

Proposition #4: The Crystal Ball conundrum. And I quote: The partnership model also assumes that it’s possible for the various corporate units to define upfront and many months in advance exactly what they will need from the IT department. The assumption is reinforced by the demands of the traditional yearly budgeting process.

KJR rebuttal: The problem isn’t reinforced by the annual budgeting process. It’s caused by the annual budgeting process. Solution: Fix the annual budgeting process.

Proposition #5: Decentralizing technology also requires some centralization. And I quote, excerpted from an account of an organization that supposedly has eliminated IT: Everybody has to use the same security protocols and software programming languages, and conform to a prescribed architectural blueprint when building digital products and solutions. But within those guardrails, employees have the scope to do whatever is necessary to get the job done.

KJR rebuttal: Presumably, these security protocols, languages, and architectural blueprint are created and maintained by IT professionals, who also establish protocols for assuring compliance. Presumably, these IT professionals live in a box somewhere on the org chart. What should we call that box? Wait … I know! … my hand is raised – call on me! … let’s call it “Information Technology!”

Bob’s last word: Boil it all down, and Mr. Peppard’s proposition is that business departments are in a better position to figure out the information technology they need than a centralized IT organization.

That is sometimes correct, and when it is, IT ought to support DIY IT efforts for all the reasons I’ve written about over the past couple of decades (see, for example, “Stop stomping out shadow IT,” 9/4/2012).

But Mr. Peppard ignores the very real complexities associated with sound, secure, and compliant technical architecture, and especially with integrating what would otherwise result in inconsistent islands of automation.

So DIY IT gets a thumbs up. IT-supported DIY-IT gets two thumbs up.

Making all IT DIY IT gets a big thumbs down.

Even if it does look superficially persuasive on The Wall Street Journal’s editorial page.

Bob’s sales pitch: In response to last week’s column, one commenter pointed out that I don’t make subscribing to KJR easy enough.

And so … if someone has forwarded this to you and you like what you read, here’s where you can subscribe: Subscribe – IS Survivor Publishing.