There is a lot of discussion about Engineering Standards lately. The big question is why? Why would the industry want standardization in software? The obvious answer is interoperability between internal systems and the capacity to synchronize easily with suppliers. From a vendor perspective this would be GREAT! Because they could apply the same techniques to their data integration across the board. What is good for vendors is also good for OEMs because it keeps prices down.
The Myth that Single Vendor Ecosystems are the most Robust
A lot of vendors take the approach that if everyone, vendors included, used their software end to end, the data would flow seamlessly. Ironically, these same vendors sell products with file formats that are incompatible with each other and point solutions that are on different platforms that require complex, custom integrations.
As most PLM providers continue to acquire new companies at an astonishing rate, many customers think “Great, now my electronic design system will work seamlessly with my PLM!” Well… historically it hasn’t really worked that way. The acquisition targets have installed bases that run off the software as it is, and it rarely, if ever, gets rewritten to have a common data model with the other technologies offered in the vendor’s “platform."
The implication is that their solution functions seamlessly out of the box, but it doesn’t really work that way. If they did provide a single unified platform wouldn’t they only have 1 item in their price book?
It Works Out of the Box
As discussed in Mark Reisig’s blog OOTB is Dead:
“According to one PLM vendor, customizing on brittle architecture is a mistake. They recommend using their product OOTB, so just dumb down your processes to fit a tool.”
Are you working for your software, or is your software working for you? Maybe vendor defined “standards” are actually proprietary formats to lock you into their licensing scheme.
Anyone who lived through the ‘80s remembers the VHS vs Betamax (Aka:Beta) wars. If you are post 1980’s, I recommend you catch up on 
all 3 seasons of Netflix’s Stranger Things.
Sure, Sony came out with the Betamax home recording device in 1975, but few consumers could afford it. Sony was advised that the rest of the industry was standardizing on the lower cost VHS format, but they moved forward with Beta to be first to market. It seems that the vendors who had more open standards and interoperability won out.
Works Across
The key to simple interoperability and easy synchronization, both inside and outside the enterprise, is openness. Some PLM vendors allow you to have some access to portions of their portfolio through partner programs that screen for “strategic alliances”. Non-strategic alliances (vendors who aren’t partners) basically have to hack into the backend of the software to access confusing data tables in an intentionally obscure and undocumented data model that may change between versions.
Aras uses services to enable integrations, so upgrades don’t affect your data model or established integrations. The service-oriented architecture separates the integration process from the core applications on the platform. This eliminates the need for recreating complex coding that is traditionally required to maintain established integrations during the upgrade process.
To make the Digital Thread work, OEMs need to work with different systems internally and externally to pass bidirectional electronic data between systems. Once this interface is developed a one way data exchange weakens the thread. Mutually agreed open interfaces are essential to a true digital thread.
Non-homogeneous Ecosystems
The typical IT ecosystem has more than one system used by various groups. While Aras can’t solve all of those integration problems, we are introducing Data Federation as a core service on our platform. Aras’ Data Federation Services will allow administrators to configure data synchronization data between Aras and other systems without complex custom code. This data can be merged with information from the Innovator data model to enable agreed interfaces between system.
Ultimately, it’s a buying decision.
So, did you develop your standard operating procedures, or did your software vendor inflict “standards” on you? Did you choose the way you work intentionally, or are you working around limitations in your software? Ultimately it is the buyer’s choice to support a vendor who locks away access to your data or to move forward with a platform built for openness and maximum interoperability.