My recent articles about low code in PLM triggered a good volume of debates and comments. Thanks, everyone for sharing your thoughts and comments. If you missed my blog, please check to catch up here:

PLM Honeycode
Low code – a sexy version of messy PLM customizations

Low code is not a unique PLM feature. I can see low code as an evolution of the software development and customization of application coming to improve application development and complex enterprise systems when it comes to the following use cases:

1- individual development and specific applications
2- Custom development, special processes, and company requirements
3- Complex process orchestration

The use cases are not specifically tied to PLM systems, but when it comes to complex PLM implementation, the infrastructure of low-code development can provide tons of advantages. Looking at what novel low-code platforms do (eg. Mendix) you can learn that tools available there are not unique and it is basically the same tools used in web/cloud development combined with well-known tools for process orchestration and enterprise integrations. What makes it especially attractive is modern cloud/SaaS infrastructure that can make these tools available to everyone without significant IT effort and (maybe) also optimized cost. It should result in fast ROI and super-efficient implementation time. Sounds good, right? Not really…

When it comes to existing PLM implementation for a specific enterprise customer, the low code tools are not living outside of realities of existing PLM, ERP, and other applications. This means new tools are great, but to make it work, you need to allow these modern low-code tools to be connected to existing PLM systems. Now, if the existing system is modern SaaS PLM, then the problem is minimal. But what if you’re dealing with a dinosaur PLM system and the system is heavily customized and last updated five years ago? Err… Huston, we have a problem.

As you can see, the overall system will be agile and efficient only to the level that all components (or participant systems) will be able to support. And if legacy PLM can only be customized using SQL code injection or some ugly old programming language, then not much modern low-code platform can do. You will be stuck for a long time developing wrappers and bridges.

Here is my quick shot for a list of criteria you would expect the PLM system to support in order to become a full citizen in a modern new low-code infrastructure.

1- DevOps support and continuous integration (CI).
2- REST API including event-driven architecture
3- Tenant architecture and authentication to connect between services.

Similar requirements will apply not only to your PLM system, but to all other systems involved in the process of low-code development.

What is my conclusion?

Low code brings tons of new cool stuff to application development and customization. It simplifies everything and seems to be everyone is in love with this. It is like Visual Basic in the 1990s. Everyone uses it and it promises to solve all problems of application development and customization. Guess what? Not all PLM systems will make it. So, check with your IT or contact me- I’m happy to help. Without proper support from existing systems, all your low-code initiatives might be DOA. 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.

The post Why PLM Low-Code Initiative Can Be Dead On Arrival? appeared first on Beyond PLM (Product Lifecycle Management) Blog.