There is a bad word in PLM jargon and it is “customizations”. For years, customization was considered as a bad thing. Started decades ago, when PDM and PLM systems were merely toolkits and you needed practically manually to adjust database tables and change system software code to adjust PDM or PLM to the desired behavior in each specific company.
My attention was caught by the Transition Technology Blog article – Windchill PLM OOTB Configuration Or Customization and the discussion around the topic on LinkedIn. The article gives a good background and details about different levels of changes in PLM system behavior and what is classified as configuration or customization.
What is the configuration? Configuration (in a PLM system) covers all the changes you can do to a product from the User Interface perspective. PLM vendors usually include configuration tools, allowing you to change the system behavior to a limited degree.
What is the customization? Customization, on the other hand, is everything above and beyond configuration. Customization is any system change that requires modification or extension of the system’s source code (i.e. implementation, development), because the desired result cannot be achieved through configuration only.
The interesting trend in PLM (and not only) customization is the so-called “low-code” development. There is a good article about it from Lionell Grealou – The Future Digitalization Speaks Low Code. I also published a few articles about low code development that triggered a substantial amount of good comments and debates – thanks to everyone who shared your insights!
While Low code can be a potential lifesaver for PLM from messy customizations, I can have many questions about how is it real and what are the chances Low code can save PLM from customizations and make PLM more open. The biggest danger I found in PLM low code is PLM system architecture- it can really make all PLM low code initiatives dead on arrival.
Here are typical downsides of PLM customizations that makes it messy and complex:
- data model changes, the introduction of new tables, and changing of existing tables on DB level;
- SQL code injected on the database levels (for reports and triggers).
- applications communicating directly to the database and by-passing PLM system APIs.
- separate applications with a user interface which is by-passing application user experience
- custom import/export functions
- point-to-point integrations with other systems
What can bring a significant change and redefine PLM customization is modern SaaS technology and development. What is usually presented as a downside is actually a huge opportunity if and when it turns out that way by PLM SaaS vendors. Here are 5 reasons why I think SaaS has an opportunity to redefine PLM customizations.
1- Application mechanism to customize data schema. Usually, a user-friendly way to add properties, customize data layout, filters, views, and others. Here is an example of a flexible data model provided by OpenBOM (Disclaimer, I’m CEO and co-founder). You can find other examples of flexible SaaS architecture from other vendors (eg. Propel doesn’t have his data layer, but fully relies on Salesforce.com infrastructure for data management).
2- REST API layer for everything making literally no difference between system development and customization code. Combined with a flexible data model, it makes old fashion SQL customization not needed anymore. There is no need to communicate directly to the database. REST API calls can do the job and also protect everything you do making it compatible with the future system upgrades.
3- Out of the box mechanism to customize data and business logic, export, and import data. Because data is not accessible directly via servers and databases, there is an ultimate need to provide robust export and import functions (Example – OpenBOM exports to csv, pdf and xlsx formats).
4- Custom REST API code, scripting, and application enhancements. SaaS environment is usually very friendly to scripting and other modern ways of web customizations. An example of such an out-of-the-box scripting environment is Onshape Feature Script allowing to development of custom features. Many SaaS systems provide application store capabilities allowing to enhance systems with external applications. Check out Autodesk App Store, Onshape App Store, and example of how apps can enhance the core features of SaaS products ().
5- Automatic upgrades are taking care of everything. The killer of all customization is PLM system upgrade. It is a moment of time when SQL tables can be redefined, database structure changed, triggers eliminated and your custom export/import code stopped working. Also, it is not unusual that the API of on-premise PLM systems is not backward compatible. Here is the thing – SaaS redefines all these problems and flips it into advantages. SaaS vendors are usually taking full responsibility for an upgrade – it becomes transparent for users. The system just works. REST API and all other customization features are also backward compatible. So, unless you’re dealing with PLM cloud washing, you’re immune to upgrades.
What is my conclusion?
From a technical standpoint, SaaS architecture takes every single downside of old PLM customizations and turns it into an upside and opportunity to scale applications and make it more flexible and robust. At the same time, keep in mind that PLM is in the transition and you can (still) see a lot of cloud-washing when it comes to cloud, SaaS, and PLM. I hope the differentiators I mentioned above will give you a good idea of what questions you need to ask when interviewing your future SaaS PLM providers. Just my thoughts…
Best, Oleg
Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital network platform that manages product data and connects manufacturers and their supply chain networks.
