What’s the difference between a “Digital Twin” and a simulation? Or a model?

Not much, except maybe Digital Twins have a more robust connection between production data and the simulation’s behavior.

Or, as explained in a worth-your-while-if-you’re-interested-in-the-subject article titled “How to tell the difference between a model and a Digital Twin,” (Louise Wright & Stuart Davidson, SpringerOpen.com¸ 3/11,2020), “… a Digital Twin without a physical twin is a model.”

Which leaves open the question of what to call a modeled or simulated physical thingie.

Anyway, like models, simulations, and, for that matter, data mining, “Digital Twins” can become little more than a more expensive and cumbersome alternative to the Excel-Based Gaslighting (EBG) already practiced in many businesses.

If you aren’t familiar with the term EBG that isn’t surprising as I just made it up. What it is:

Gaslighting is someone trying to persuade you that up is the same as down, black is the same as white, and in is the same as out only smaller. EBG is what politically-oriented managers do when they tweak and twiddle an Excel model’s parameters to “prove” their plan’s business case.

Count on less-than-fully-scrupulous managers fiddling with the data cleansing and filtering built into their Digital Twin’s inputs so it yields the guidance the manager in question’s gut insists is right. Unless you also program digital twins of these managers so you can control their behavior, Digital Twin Gaslighting is just about inevitable.

Not that simulations, models, and/or Digital Twins are bad things. Quite the opposite. As Scott Lee and I point out in The Cognitive Enterprise, “If you can’t model you can’t manage.” Our point: managers can only make rational decisions to the extent they can predict the results of a change to a given business input or parameter. Models and simulations are how to do this. And, I guess, Digital Twins.

But then there’s another, complementary point we made. We called it the “Stay the Same / Change Ratio.” It’s the gap between the time and effort needed to implement a business change to the time the business change will remain relevant.

Digital Twinning is vulnerable to this ratio. If the time needed to program, test (never ignore testing!) and deploy a Digital Twin is longer than the period of time through which its results remain accurate, Digital Twinning will be a net liability.

Building a “Digital Twin,” simulation, or model of any kind is far from instantaneous. The business changes Digital Twinning aspires to help businesses cope with will arrive in a steady stream, starting on the day twin development begins. And the time needed to develop these twins isn’t trivial. As a result, the twin in question will always be a moving target.

How fast it moves, compared to how fast the Digital Twin programming team can dynamically adjust the twin’s specifications, determines whether investing in the Digital Twin is a good idea.

So simulating a wind tunnel makes sense. The physics of wind doesn’t change.

But the behavior of mortgage loan applicants, is, to choose a contrasting example, less stable, not to mention the mortgage product development team’s ongoing goal of creating new types of mortgage, each of which will have to be twinned as well.

Bob’s last word: You might think the strong connection to business data intrinsic to Digital Twinning would protect a twin from becoming obsolete.

But that’s an incomplete view. As Digital Twins are, essentially, software models of physical something-or-others, their data coupling can keep the parameters that drive them accurate.

That’s good so far as it goes. But if what needs updating in the Digital Twin is its logic, all the tight data coupling will give you is a red flag that someone needs to update it.

Which means the budget for building Digital Twins had better include the funds needed to maintain them, not just the funds needed to build them.

Bob’s sales pitch: All good things must come to an end. Whether you think KJR is a good thing or not, it’s coming to an end, too – the final episode will appear December 18th of this year. That’s should give you plenty of time to peruse the Archives to download copies of whatever material you like and might find useful.

On CIO.com’s CIO Survival Guide:6 ways CIOs sabotage their IT consultant’s success.” The point? It’s up to IT’s leaders to make it possible for the consultants they engage to succeed. If they weren’t serious about the project, why did they sign the contract?

For all its ambiguity and grammatical misclassification, “digital” as a noun … or “Digital” as a proper noun … has proven more durable than most of the management fads that preceded it.

It isn’t that digital businesses out-perform non-Digital (Analog?) competitors. The fact of the matter is, the definition of “Digital business” varies by commentator, while the definition of “successful Digital business strategy” often fails even such well known logical requirements as not equating correlation and causation.

Speaking of logical analysis, the situation is far worse than even that. As evidence:

According to the definitive source of such things, the Standish Group reports that only about 30 percent of all software projects are successful.

Meanwhile, the often-IT-illiterate Harvard Business Review reports that 70 to 95 percent of all digital transformations fail. Take into account that transformations of any kind are achieved with strategic programs, which in turn are composed of tactical initiatives, which in their turn are accomplished by the collective success of the multiple projects they charter, and you’ll conclude that Digital failures are an example of Sturgeon’s Law: 70 percent of Digital transformations fail because 70 percent of everything a company tries fails.

What’s made Digital as business strategy so durable is (in my awesomely humble opinion) that it has legitimized the pursuit of revenue as a strategic objective, making it more desirable than cutting costs. And, it is rooted in the proposition that information technology can provide a powerful path to more, and more profitable revenue.

In addition, Digital, along with IT’s successful employee-virtualization-response to COVID-19, turned the executive suite’s perception of IT from “where projects go to die,” to “the most important business function in the enterprise.”

Another factor in Digital’s executive suite staying power wasn’t something anyone would have predicted a decade or so ago: Unlike previous IT-driven requests for capital investment, by the time “digital” had acquired its capital D and had been turned into a noun, business executives had adopted Blackberries and loved them, right until they discarded them for smartphones accompanied by a wide variety of handy apps.

Add to that their unavoidable experience shopping for merchandise on Amazon.com and, for many, shopping for Kindle books there too, and strategy discussions didn’t have to start with “here’s what a smart product is” explained to skeptical executives reacting with thousand-yard stares. They started with “how can we make our products and services smarter?”

Bob’s last word: Some 60+ years ago, in his revolutionary Stranger in a Strange Land, Robert Heinlein introduced us all to the word “grok,” meaning to understand something deep in one’s kishkes (I’m paraphrasing).

Last week I wrote about ROI and its flaws, concluding that ROI’s utility is limited when it comes to writing successful project proposals, not to mention evaluating them.

At the same time, what’s been badly underemphasized when it hasn’t been ignored completely is how important it is to write proposals your company executives and governance councils can grok.

That’s because having to convince someone of something they already grok is a lot like having to persuade them that the tall green thing they’re looking at through their window is a tree.

Bob’s sales pitch: Looking for someone to keynote an event? After publishing a dozen or so books and some 1,800 or so columns, it’s safe to say I have a strongly held opinion about just about any subject you can name.

I’ll be happy to share a few of them from your podium.

Think of it this way: You’ll be choosing someone to give the keynote. Why not yours truly?

Now on CIO.com’s CIO Survival Guide: Why IT communications fail to communicate.” The point? Our tendency to use documentation to communicate, instead of recognizing that its role is to remind everyone of what they’ve already communicated.