Tom Friedman discovered the Internet ten years ago (The World is Flat, 2007). I’m sure you were as pleased for him as I was.

But to be fair to Friedman, he’s a smart feller who sometimes does have useful insights, like, for example, about Digital stuff. Without using the term once — and good for him, especially for not using it as a noun — he recently provided as neat a synopsis of how we should all be using the Digital adjective as I’ve seen (“Folks, We’re Home Alone,” New York Times, 9/27/2017).

Here’s the exact text:

We’re moving into a world where computers and algorithms can analyze (reveal previously hidden patterns); optimize (tell a plane which altitude to fly each mile to get the best fuel efficiency); prophesize (tell you when your elevator will break or what your customer is likely to buy); customize (tailor any product or service for you alone); and digitize and automatize more and more products and services. Any company that doesn’t deploy all six elements will struggle, and this is changing every job and industry.

Let’s take a closer look:

Analyze: In Friedman’s view this means finding patterns, presumably through the use of multivariate statistical techniques, leading to the well-known logical fallacy of thinking correlation proves causation.

For businesses, though, the framework of causality that leads to a pattern often doesn’t matter. If the data reveal a pattern — say, that the presence of fire fighters correlates with the presence of fires — it really doesn’t matter if the fire fighters are setting the fires or putting them out. What matters is that this is a good place to put a lemonade stand, because the data also reveal the pattern that fire fighters who are near fires are often thirsty.

Optimize: I know the route to the airport. But I still use Google Maps to get me there. Why? Google will route me around traffic snarls to get me there faster.

More broadly, we’re leaving the age of fixed-flow linear processes in favor of processes that dynamically adapt to changing situations. Take, for example, the OODA loop we’ve discussed in this space from time to time (observe, orient, decide, act).

More and more data (observe) means you need to use Digital technologies to analyze it for meaning (orient), followed by self-learning AI choosing a course of action (decide) and learning from the results (back to observe). Humans might or might not be involved in implementing the decision (act), depending on whether the action takes place in the physical or virtual world.

Prophesize: Look at the figure. It shows white noise. Since business first started eons ago, the best strategic decision-makers have learned to ignore noise, searching for the signal within it.

But as algorithmic traders have figured out, if you can make decisions fast enough the noise can be the signal. You just have to be able to respond to each change of direction fast enough. Do this and it counts as prophesy: “For the next x units of time we should expect our markets to follow this very short-term trend.”

Customize: Here’s something I’ve been writing about for years. Especially with increasing wealth stratification, the ability to tailor and customize, driven by affluent customers’ desire for uniqueness, will be a critical competitive differentiator. Luxury is, after all, relative, not absolute, which is why even the snazziest-looking Timex watch that keeps perfect time is not a luxury, while a Rolex, which, having a mechanical movement, keeps nothing resembling perfect time, is a luxury for those few who can afford one.

Digitize and Automate: I don’t know what the difference is between “digitize” and “automate.” I’m pretty sure one, the other, or both mean “have the computer do it, not human beings.”

Either way, the idea is that businesses can reconfigure themselves more quickly when everything is done in software. And they can, assuming modern application architecture, modern integration architecture, and short-cycle-time techniques like the Agile/DevOps combination.

Collaborate: This is a big one, and Friedman missed it. Individuals can’t do everything all by themselves. That takes teams, and teams of teams. Not groups. Teams. The difference: Members of a team trust each other and collaborate. Members of a group trust nobody, and negotiate. This slows everything to a crawl.

Companies can’t do everything all by themselves either, so the teams and teams of teams in question often consist of employees from more than one company. If they can and do trust each other they can collaborate. If they can collaborate they can deliver terrific results together. If they can’t they probably can’t.

So let me ask you: How much is your company willing to invest in trust?

We consultants have an easy life. For the most part our techniques are uncomplicated and our advice is, while good, pretty obvious. Even better, most clients don’t want our advice. They either want us to read a script, or they have a dozen reasons our advice is good in theory, but won’t work in the “real world.”

Personally, most of what I do is Undercover Boss except I’m not the boss. In my experience, employees know exactly what’s wrong with the organization, have a pretty good idea how to fix it, and have an accurate bead on why management will never make the repairs.

In the case of information security, it’s usually even easier than that: If companies would just:

> Patch: Now, please.

> Encrypt everything: Too expensive? Net the cost of the time needed to decide what should be encrypted and what doesn’t need to be against the cost of encryption. Encrypting everything costs less.

> Rotate keys: Rotate them at least as often as users are required to change their passwords because the data in your corporate databases is more sensitive than the data in individual laptops. What would you do without me?

> Phish: Subject everyone in the company to white hat phishing attacks. Everyone. Frequently. Model your attacks on real-world ones. Explain to employees who click what they fell for and how to spot the next one. Because the bad guys don’t bother trying to crack passwords any more. They just ask for them.

One more: Add “Don’t store this because we don’t need it and never will” to your company’s master data management practices. I spent much of my spare time over the past week trying to figure out what uses EquiFax might have for storing social security numbers in its credit records, and I’ve come up dry. My social security number has no bearing on my creditworthiness.

With this exception: It’s the only form of personal identification that won’t change over time.

The “never will” qualifier deserves a bit of explanation. I worked with a life insurance company once upon a time that routinely deleted a lot of information about applicants once they became policy holders because they didn’t need it anymore.

Until the time, a few decades later when the importance of customer analytics was becoming apparent.

So “never will” is a balancing act.

Which gets us to: In response to last week’s column proposing SSN 2.0, several correspondents and Commenters pointed out that when we who till the soil of corporate IT need to determine if someone should be allowed into a system, we establish a key value … the user ID … and one or two authenticators, of which passwords are the most prominent.

Social security numbers play both roles — they’re both identifier and authenticator, on the theory that only the holder of a social security number knows what it is.

It’s a quaint perspective, but seriously folks, haven’t we become just a wee bit more sophisticated in the 81 years since the Social Security administration issued its first batch of cards?

Not to mention since Woolworth became the first and possibly worst identity thief of all time? (You just have to read about this — click here.)

In an interesting way what we’re looking at is really a common IT problem: A system that elegantly solves a problem is expanded to solve additional related problems. Then it’s expanded again. And with every expansion the system’s architecture becomes another notch messier, until it reaches the point where it’s at risk of collapsing under its own weight.

When the subject is business applications this means it’s time for modernization, conversion, or a re-write, to a system designed from the beginning to handle the actual scope of the solution.

Here, the original problem was to uniquely identify citizens registered with the Social Security Administration, to which the IRS added taxpayer identification.

Now, the SSN is used by businesses asking the question, “Can we trust this person to hold up their end of the bargain when we sign a mutually binding contract?” It’s the public connecting point for all of a person’s financial records.

Whether my semi-whimsical SSN 2.0 proposal bears any resemblance to what a real solution would look like is anyone’s guess. What I am pretty sure of is that, if your company stores consumer information and doesn’t follow at least the practices described here and last week (no, not “best practices” — call them “barely adequate practices”), it will end up contributing to the problem.