Devops and Continuous Delivery in PLM Customizations

Customization is a bad word in jargon of PLM implementations. The modern lingo brings us a new politically correct word – configuration. PLM vendors are splitting hairs trying to describe the difference between customization and configuration. You might remember my last year article – PLM: Customization vs Configurations – let’s sort it out. On a surface things seem to stay nice and simple. If you use tools to change system configuration provided by a vendor, you’re doing “configuration”. If you use code to change what system does, you’re customizing. But, what if you’re using APIs provided by a vendor? The difference between customization and configuration aren’t so clear.

The PLM State: Don’t Throw the Baby Out With the Bath Water — Restoring Balance to PLM brings an interesting opinion about PLM customization. The story is about a framework ZWS PLM Automation Suite, so a bit of marketing involved. Nevertheless, I found the following quote quite interesting:

Zero Wait-State recently conducted a webinar where the challenges of customization of PLM were discussed.  If you would like to see a replay of the webinar CLICK HERE.  Specifically, the presentation highlighted the proliferation of automation scripts, the cost of developing and maintaining automation and the difficulty upgrading to newer versions of PLM when you have extensive customization.

We experienced these same issues internally since we leverage PLM to deliver services and products to our clients.  We struggled to keep up with all of the process extensions we had created for clients and the ones we used internally. We also discovered a lot of redundancy in our coding since many of the PX’s were similar. We struggled with adoption of PLM by our non-technical users and with getting information out of PLM in a useable format.  Our solution was to create an automation framework that would allow us to quickly create and modify automation and customizations for PLM.  Now we are able to use this approach to streamline management of these customizations and it allows us to easily modify existing customizations to adapt to changing business requirements or to generate new solutions.  This approach eliminates the downside of customization since you now have a single point of maintenance and the creation of these solutions becomes much easier.

The article brings a point of automation as a way to solve complexity of customization. Which made me think about DevOps and continuous delivery methods.

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.[1] It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production.

DevOps and Continuous Delivery gained significant popularity in the last 5-7 years as part of agile development methods. Combined with micro-services architecture continuous delivery can significantly decrease risks involved into software development and implementations. Granular services can be deployed, altered and tested. However, one of the most interested factors in an increased popularity of continuous delivery is the number of automation tools involved in the process – code can be automatically build, tested and deployed.

You might tell ask – how continuous delivery can be related to PLM customization? It is all about software development.  Here is the thing… In many ways each PLM implementation can be considered is a micro-development brining some elements of system configurations to PLM software services. PLM software development is gravitating towards cloud technology and deployment. In such environment, web APIs is the only legitimate way to configure and customize a systems. Continuous delivery and automation tools can become a way for PLM systems to be deployed and configured for a specific customer. It can open some very interesting opportunity in which environments can be developed, tested and validated automatically before actual customer facing deployment will be happening.

What is my conclusion? PLM vendors will have to invest in technologies and methods to simplify deployment, flexibility and speed of implementations. By enabling such methods, vendors can bring new type of PLM infrastructure in place – agile, flexible and capable to adopt to specific requirements and customer needs. The cost of customization support and delivery in such systems will be a fraction of what vendors and service providers need to spend today to customize, deploy and test PLM systems. It will enable to customize PLM within the time and speed we never seen before. Just my thought…

Best, Oleg

Want to learn more about PLM? Check out my new PLM Book website.

Disclaimer: I’m co-founder and CEO of openBoM developing cloud based bill of materials and inventory management tool for manufacturing companies, hardware startups and supply chain. My opinion can be unintentionally biased.