Data Obfuscation is Very Real

Anyone who has been involved in any sort of enterprise data migration or integration project can relate to the frustrations associated with trying to get data out of the legacy system. Isn’t this your companies’ data? Why is it then locked away in obscure tables that only the software vendor can decode?

This is an old problem dating back to the initial coding of most PLM systems. In fact, not much has changed in the last 10 years since Aras published “What is PLM Data “Obfuscation” and I Why Should I Care?!?“ The blog cites examples of intentionally obscuring data, such as:

“The database table for the Part Master is not called / labelled “Part” – it’s labelled “0034543908543TG324” or something else confusing like that… the data are sometime split into different tables so that access is non-intuitive. This is “obfuscation” and it’s done by design. PLM systems have traditionally (and still are) very hard to get at the data and figure out, sometimes impossible.”

Fortunately, in the last 10 years customers have learned from previous projects and gotten somewhat savvy. Industry groups like the A&D PLM Action group, and the German initiative “the Code of PLM Openness“came together and demanded certain standards that are aimed at making data interoperable and portable.

Unfortunately, this has not changed the way in which legacy PLM systems are architected. In fact, the problem has become even worse. The problem is no longer just getting one PLM vendor to synchronize with another vendor but, due to mergers and acquisitions, many PLM vendors have ended up with a broad portfolio of data management tools that don’t even interface openly with each other.

In addition, as products have become more complex, it is more important than ever to manage requirements, mechanical data, electrical CAD, as well as software and simulation. While many vendors have a portfolio of products to address each of these needs, those products are not on the same platform. Buying all your software from a single vendor no longer means that those tools will work together.

Purchasing a “suite” of software now means complex and costly integrations with the rest of your enterprise IT ecosystem, but the implementation also requires custom integrations between tools in the suite itself. Since Aras Innovator is a platform rather than a “suite,” these internal integrations do not apply.

If you are wondering how complex the connectivity of a “suite” of software tools can be, look at the various licensing models. Are you paying one price per user for access to everything, or are users locked away from certain data according to their “roles?” Who is defining these roles? Is it your vendor's licensing scheme or is it your company’s admins based on your business needs?

In terms of migrating from one PLM tool to another, “vendor lock-in” is still very real. While all vendors have scrambled to achieve “Open” certifications, none have rearchitected their software to make it easier for users to extract their own data in an easily usable format. (If a PLM vendor requires the purchase of a “Toolkit” for access to their schema, they are not open.)
Fortunately, companies are beginning to ask about data exit strategies at the beginning of the buying journey. While most vendors have committed to the spirit of openness, few were architected to support it.

Before you get into a long-term relationship with a new PLM vendor, pay careful attention to how your company's IP will be handled when the relationship ends. After all, 100% of implementations are eventually replaced—either by migration or upgrade. Buyers are now able to choose how painful that process will be upfront in the buying cycle. Aras’ open APIs and logical schema ensure that YOU are the owner of your data.