The Thing with Transformation

There is a time for everything, and a season for every activity under the heavens. A time to develop, a time to deploy, a time to upgrade or migrate, and a time to heal those affected.

Digital transformation looks like a coil spring expanding infinitely towards better outcomes. It is a relatively new phenomenon in historical terms. However, those with experience in information technologies can easily identify with the words written three millennia ago.

At every coil some system’s end of life morphs into another system’s beginning via upgrade or migration. Although an upgrade presumes moving to a better version of the same system vs. a migration moving to a totally different system, in reality they may be quite similar in terms of effort, risk, and reward.

During each turn of the spring, the challenge is usually about comprehending its scale, complexity, and our own place there. Fortunately, Hollywood is quite helpful in visualizing several distinct types of transformations:

The 1994 “Mask” transformation comes from an external (ancient) mechanism that is distinctly separate from its host. It significantly enhances the host and amplifies his or her character traits at the time of the wear. The effect disappears when the Mask is off.
The 1982 “Thing” transformation comes from an external (alien) mechanism that merges with the host and becomes its inseparable part. This transformation replaces the host’s organs and personality, making it completely unrecognizable and extremely dangerous.
The 1998 “Godzilla” transformation comes to a small lizard from an extreme dose of radiation. The lizard becomes an enormous creature meandering around NYC to satisfy its primal instincts. While it has no evil intent, with all its uncontrolled power it becomes unacceptably destructive.
The 2002 “Spider-Man” transformation comes from an external mechanism when a genetically engineered spider bites a normal teenager. This causes a permanent change that significantly enhances the host whenever he needs it. Yet his on-demand capabilities are of a covert nature, with no negative change to his personality.
Finally, the 2008 “Kung Fu Panda” transformation comes without any external mechanism at all. Instead, it focuses on extensive positive development of the host itself in terms of physical capabilities, intellectual growth and mental resilience. Panda affects the world mostly through its own evolution, its teachings and its students.

Let’s be frank: in many modern engineering environments, the PLM host system, its data, configuration and customization usually fuse together, creating the inseparable and overarching Thing. This creature coexists relatively peacefully with the company and its user base until the company decides to move on, directly threatening the Thing’s survival. In the worst case, the only way to stop the madness is to use the flamethrower and dynamite, potentially losing access to all accumulated data, and succumbing to a freezing corporate death.

It is far from trivial to recognize your PLM has turned into the Thing, let alone to figure out all its elements and determine further remedial actions. The movie protagonists forced the Thing to fully expose itself by burning its seemingly unconnected pieces. In lieu of a flamethrower, PLM managers have to dig through tons of documentation and code, and talk to the anthill of folks to trace the decision-making about the monster’s current anatomy.

Controversy often starts with the current system’s core data: how many units of record and units of engagement can be moved to the new system or systems; what can be safely abandoned; and what will be unfortunately lost forever? Success hinges on the company’s prior discipline. For example, the ability to fully export design data into STEP or JT depends on the company never buying into CAD vendors’ most beautiful – but proprietary – features.

Then we come to the infrastructure surrounding the company’s core data. In a twist of the Conway law, companies often use configuration and customization to satisfy their own present organizational structure – instead of remaking themselves into an organizational structure of their software vendor. The ease of migrating such customized infrastructure rests on another case of the company’s discipline: it is always better sticking to “out the box” functionality, and to grow tentacles only when absolutely unavoidable.

Speaking of the new engineering environment to which the company wants to migrate, there is a major debate about building it around one huge Godzilla vs. a “connected” combination of a smaller, more domesticated Godzilla with many specialized Masks, and a few Spider-Men benevolently connecting everyone with their semantic webs. Naturally and unfortunately, there is always a danger of every Mask or Spider-Man or even Godzilla turning into the Thing despite best efforts – so, watch out!

Anyway, migrating the engineering systems infrastructure requires capturing the impact of almost every configuration setting, and tracing all the dependencies and peripheral data silos of the current environment. After that, it is necessary to decide which configuration settings will be possible to transition to the new system as is, which customization will be replaced by the new system’s out of the box functionality, which customization will be preserved in a jar to be reconnected to the new system later, and which customization will be re-created from scratch to complement whatever is missing in the new system.

There are already companies like PROSTEP that explicitly focus on easing the core data migration pain from the Thing to whatever comes next. There are ways to move product life-cycle data using 3DXML, PLMXML, or even the OSLC-style route. Yet, it seems the problem of infrastructure hasn’t been addressed properly so far.

At Senticore, we have been figuring out real Generative AI uses cases vs. hype, and we see that connecting documents via semantic identifiers can help to trace the infrastructure dependencies pretty quickly. For example, Generative AI proved to be quite efficient in mapping configuration settings between old and new systems. Finally, we definitely see graph technologies being very helpful for navigating the quagmire of out of the box and custom configuration settings, UI/UX components and other continuously mutating pieces.

By the way, Panda seems to be a good metaphor to the corporate Digital Engineering team. Ideally, that team continuously hones its own fighting skills, while also keeping watch over the landscape to prevent any re-emergence of the next Thing, or at least to oversee its safe handling.

A much bigger and probably rhetorical question is whether an organizational transformation that involves the appearance of Panda, and/or an overall change of heart along the lines of Scrooged and the Grinch, is a prerequisite to the company seeking a steady path into this new technology paradigm?

Consider talking to Senticore about the Sacred Peach Tree of Heavenly Wisdom – and make your next turn on the digital spring simple (again)!