Main page Technology A cautious glance on engineering & IT

A cautious glance on engineering & IT

Once upon a time, IT departments of engineering/manufacturing companies had a pretty straightforward relationship with engineers and their drawings-based processes. Everything changed with the advent of the so-called 3D Model Based Definitions, which created a need to store electronic data for 50+ years, keeping it intact through avalanches of upgrades, blizzards of software glitches, swamps of custom code, and occasional volcanic layoffs.

Historically, Engineering IT grew out of engineers automating their Enterprise CAD and PLM daily tasks with guerrilla-style programming. Then their teams started collaborating on those tasks, and the resulting engineering data volume expansion necessitated requirements for integrity. Engineering IT are people who “own” and maintain the engineering tools and methods. This is a specialized group that sits between the engineers and the corporate IT.

The Engineering IT skill-set deviates from a conventional IT educational curriculum and experience: understanding of CAD/PLM becomes a baseline, while a detailed knowledge of engineering data requirements, processes and procedures is the key to success. Yet, it is difficult for a traditional IT person to justify investing years into learning engineering concepts. Altogether this creates a perpetual conflict between engineers and conventional IT.

This relationship was nicely exemplified in the 1991 classic “The Silence of the Lambsfeaturing Dr. Lecter as an engineer, Dr. Chilton as an old-time Corporate IT employee, Clarice Starling as a new Engineering IT employee, and Jack Crawford as an Engineering IT executive.

Dr. Lecter, presented by Antony Hopkins in the most bewitching manner, enjoyed understanding people and cracking them open – both metaphorically and gastronomically. Dr. Lecter also liked to proselytize and teach. He once taught an FBI agent, got caught in the process, and then further collaborated with the same agent from behind bars when an interesting case presented itself. In other words, Hannibal Lecter was a typical engineer: very smart, and always coming up with creative ways to “get the job done” no matter the cost.

Jack Crawford knew the lengths Hannibal Lecter could go with his little idiosyncrasies. He used that knowledge when he had a serious business need to catch Buffalo Bill. Jack Crawford put Clarice Starling, brilliantly played by Jodi Foster, as a totally innocent and unsuspecting bait right before Lecter under a fake pretense. Dr. Lecter immediately figured that out, but he was unable to resist from starting and then maintaining the conversation.

Dr. Chilton was rightly scared of Dr. Lecter. Likewise, Engineers typically keep the traditional IT on their toes, always forcing them to guess what the next big thing – a newly desired Engineering application – will be. Engineers are continuously pushing traditional IT teams to the limits of their comprehension and capabilities. Or, being out of patience, the engineers cook themselves a home-grown application out of VBA/Excel, MS Access, or some more advanced tools. These applications end up running business-critical processes, and then Corporate IT are forced to maintain them until a suitable replacement is found. Alternately, without dedicated Engineering IT, millions of hours and dollars are wasted by Corporate IT programmers trying to deliver that “thing” to Engineering.

Starling and Crawford are both equivalent to an Engineering IT, because they have a much deeper understanding of Hannibal Lecter. Paradoxically, Clarice Starling even learned to like her caged “colleague,” and he paid her back generously by not eating her upon his escape – which cannot be said about the sad fate of Dr. Chilton.

Crawford’s plot succeeded: the unlikely team caught Buffalo Bill. Interestingly, Dr. Lecter escaped the next day from a federal institution, fooling dozens of agents who were armed to the teeth but somehow entirely unprepared, even compared to Dr. Chilton.

It is also interesting to note that Dr. Lecter has done nothing intellectually remarkable while enjoying his newly found freedom: the gruesome scenes of the “Hannibal” sequel are not anywhere comparable to the witty dialogs of “The Silence of Lambs” and “Red Dragon.” His best moments apparently happened when he was still considered a model citizen and a scientist, helping to solve complicated cases and occasionally master-cookingterminally rude” individuals.

How can a corporation build a friendly cage for their own collective Dr. Lecter, providing everything to satisfy his intellectual needs and making him feel extremely comfortable, but with no way to escape and/or eat someone? How do we maintain engineering creativity, without making it financially destructive within a corporation – and how do we ensure a secure and stable Engineering IT environment without destroying creativity?

Modern PLM vendors are working to help their corporate clients to address these issues in multiple ways, such as by devising methods to protect the Corporate IT from engineers. The present drive to move the entire PLM infrastructure to the cloud offers engineering teams the flexibility to work remotely, empowering them to collaborate more effectively, enabling them to bring innovative ideas to life faster – while presumably also downsizing the Engineering IT by reducing the know-how required to support a more static system.

At the same time, there is a danger of the restrictive cloud PLM approach muzzling the engineering creativity and unique companies’ differentiators. Loss of control of engineering data crown-jewels is another concern. This might be acceptable to robotic startups and mid-size tool shops; it is a harder sell for large OEMs like Boeing or Lockheed Martin.

Perhaps the real focus for Corporate IT should be around moving their PLM systems to their own managed AWS or Azure infrastructure, combined with full containerization/K8s of these systems. Alternatively, I would not be surprised if PLM vendors soon begin to expose their cloud solutions beyond their public APIs, providing customers and partners with direct access to those cloud solutions’ infrastructure. Either way, this will help to dramatically reduce PLM systems’ running costs and required specialized knowledge, while keeping them up and running more reliably, while still having full control of the data and proprietary business logic.

This is certainly a road to be taken. Senticore can help bridging the gaps – and ensure nobody gets eaten. Talk to us about your PLM system move to the cloud and we will show you the way to have your cake, Dr. Lecter doing his magic, and everyone being safe and sound. Bon appétit!