People are beginning to trust machines (more precisely an AI) for answers, instead of another person.

There is a remarkable change that is happening in front of us, and it will affect how we do our jobs as tech leaders immensely.  This change isn’t entirely new, but it seems to be accelerating rapidly, and people are looking to us Tech Leaders for answers (at least for now, until machines replace us as well).

Let’s look at where we are coming from:

Over the last few decades, we have come to expect that we could rely on the “wisdom of the internet”, with search engines helping us find the most relevant human experiences and opinions on how to best set up a router, program a macro, formulate a derivative in Excel or make cioppino.  These human experiences were ranked on relevance and utility but were ultimately still very human in origin.   We live in a glorious age of being able to learn about anything we wish.  (Wanna learn how to make a handmade nail?  Here you go)

But we are not the only ones to learn from all of this human experience.  We have been training AIs to learn from us as well, and they are getting to a point that they know what they are talking about.  (Wanna see how an AI will tell you to make a handmade nail?  Here you go)

When you compare the two answers, is it clear which answer was human generated and which was synthesized by an AI?  In this case, yes!

Which answer is better?  I know that David (the person in the first link) grew up blacksmithing, and learned from his father and grandfather.  I also know that the AI has never actually made a single nail in the entire time that datacenter has been running. Which answer is better? Does the origin of this information matter to most people?  I can’t begin to tell you.

Based on this, I think I have figured out where AI will first emerge as utterly disruptive to companies, and that will be in Marketing, Marketing automation, and Search Engine Optimization (SEO).

The whole Marketing industry is based on the idea of trying to help others become aware of products and services that are relevant to one’s needs.  Marketing automation is being able to scale awareness, and (done ethically) helps more people connect with something that they want.  SEO (again, ideally, and ethically) is helping others find important and relevant information, written by others, to solve their problems.    (I hate having to use all of these qualifiers, but as one Marketing executive told  me, “Marketers ruin everything”).

What happens to a company that has invested scrillions of dollars in carefully created and curated content to position their solution accurately,  went through the effort of researching how others learn about their solution, making sure that they were in the right place  to be found, only to discover that a somewhat shambolic, hallucinating AI decides to answer user’s questions with whatever it scraped from a variety of sources?   The name for this condition is a  “Zero Click Search”, where the searcher is able to gain their answer without any further clicks, based the search tool “answering” the question directly in some manner.

Marketing departments and Marketing software companies are looking at the biggest challenge to their work in decades—with no understanding of how to make sure that their message (much less accurate or truthful messages) is delivered effectively, much less accurately.    To make a prediction, I think the Marketing industry will fight back.  To make another prediction, I think it needs to—Pharmaceuticals, Politics, and consumer safety situations demand some sort of basic accountability in communication, and I believe that we will find ways to ensure that make this happen.

Where do we go from here? Let’s talk about what is happening in Marketing Tech in an upcoming post.

While many are recovering from the CrowdStrike patch situation, it is probably good to reflect on the fact that the outcome could have been worse.

It was fascinating to see that certain industries suffered more, including travel and healthcare.  It seems that tribal affiliations or very targeted marketing (or both) gave CrowdStrike several industry specific installation bases that were impacted significantly.    Most of us have at least one story of a friend or colleague that couldn’t catch a flight home on Friday or a medical procedure that couldn’t be performed.

Monoculture IT has the same problems as monocultures in agriculture, politics and communities—Vulnerabilities are amplified, and have more consequences.  We can’t buy “Big Mike” bananas these days, and some of my ancestors moved here because of a potato fungus.  In both cases, farmers were growing the same exact genetic sibling or clone, only to be taken out by a highly specialized threat, at a huge cost to everybody.  We live in a time where deliberately or accidentally bad software has replaced fungi as a daily threat.  The analogy is shockingly close. Maybe we should stop talking about viruses and call them fungi instead?

Luckily, our diverse systems saved us from worse, and I think there are some lessons here for IT leaders.

Lesson #1- OS Diversity is a good thing.

The multitudinous flavors of Linux have more or less replaced all the commercial Unix operating systems and are varied enough to keep pests and predators as bay.   Non CrowdStrike Windows systems were not affected at all.  Neither were the remaining Big Iron systems affected either.   This isn’t a “Windows is bad / Linux is good” situation.  We can predict that next time it will be a Linux, or legacy Unix, or Apple OS that’s the culprit.

When you evaluate the alternatives – OS diversity vs OS monoculture – monoculture makes technical architecture management easier. Diversity makes risk management easier. See Lesson #3.

My opinion: The management challenges of multiple OS platforms seem to be worth it.  And to be sure we’re clear: I’m advocating OS diversity, not obsolescence. Lifecycle management still matters, as one big airline that’s still using some sort of patched up version of Windows 3.1 we found out (!)

 

Lesson #2- DevOps needs multi-environment testing and promotion.

Like many of you, we adopted a containerized, Kubernetes based DevOps approach over the years. Bad releases make people unhappy, lose confidence and vendor patches still need to be tested before promotion to Production as if they were your own development.   It was surprising to see so many companies that seem to have dropped multiple levels of environments and testing, and allowed the CrowdStrike patch to be installed directly on Production environments.   I am scratching my head about why this would happen- Was it because it was felt that this was an especially trusted vendor?  Was it because of the perceived risks of a Zero Day vulnerability? What was communicated to them from CrowdStrike about the release? Are there companies running enterprise systems without a “Dev/Test/QA/Prod” environment architecture, based on some perceived cost savings?  We often see environment architecture compromised due to cost.

Maybe it was confusing “Continuous Integration / Continuous Delivery” (good) with “Continuous Integration / Continuous Deployment” (bad). Or maybe it was just plain old complacency.

Regardless, IT leaders need to take this lesson to heart now.

 

Lesson #3-  Making things easier often makes them more risky.

This week’s column was originally going to be about AT&T and Snowflake.   Data warehouse security really should be at the top list of considerations (Note to self—fix this column).    In both cases, we see how the promise of “Easy” management of key systems introduced risks that were pronounced and, unfortunately, realized.   This seems to be the case with CrowdStrike customers that assumed that the automatic patching system could be entrusted with a Production system.   We are likely running similar risks with all the Cloud hosted offerings in our lives right now that some cloud-hosted vendors hide from view.

There may not be a great alternative to this risk, but awareness is a good place to start.  Or, if you’re big enough to have the requisite clout, ask your cloud-hosting vendors how often they undergo an ITSM audit, and to share the results of the most recent one.

Just because the root cause of the CloudStrike mess was bad patch management, that doesn’t mean patch management is the only poorly implemented ITSM practice that can create vulnerabilities.