The idiom I put in the title of the blog is a cliché of the startup community. It is rooted in the idea of “iterative” software development – ship and fix and then ship it again. Opposite the idea of a long development cycle, the idea is gaining interest in PLM space as well. Agile (or phased) PLM deployment and implementation are getting more popular. Let’s talk about what impact PLM SaaS development will have different size PLM implementations.
PLM has many stories – some of them very successful and some of them are actually thrillers about PLM disastrous implementations, spent millions of dollars and lost PLM IT careers.
My attention was caught by Engineering.com – Dassault’s New Grip on the Jaguar Land Rover and Ericsson Problems. A few earlier stories from Engineering.com can be found here – Scary PLM thrillers and What to learn from Ericsson failure.
Here are a few passages that I especially liked:
The JLR case once again proves how hard it is to go live and successfully implement a complex platform based on new technologies. But let’s be clear on one thing; the responsibility for failure, or success, isn’t simply a matter of software problems or inconsistencies. It depends just as much on the organization within the company where the technology is implemented, the resources assigned, and the time frames that are applied, among other things. Normally a project like this is a matter of a “trinity” containing three or more major parties, where the company’s organization typically works together with the software developer and a third-party service provider.
It is not uncommon in large OEMs that it takes five to ten years to establish platforms carrying new technologies in the way that 3DEXPERIENCE did when the project was first launched at JLR around 2010. Five years was the original time frame JLR calculated; now we know that this time doubled, and a lot still remains.
Naturally, the technology itself must be taken into consideration, but the implementation approach is just as important in the case of JLR. JLR is a large organization—with 8,000 engineers employed directly, plus thousands of engineers and product developers in the partner network—containing internal departments and external development partners. The latter are of utmost importance, since they contribute up to 80 percent of the development work.
The stories of large PLM implementations are especially interesting because they can demonstrate the evolution and sustainability of systems. The customization of large PLM implementation is the core challenge. From one side, it is obvious that the system must be tailored to the needs of the customer. What does it mean for both vendors and customers from the side of software development and evolution remains unclear? A decade is a huge time, so I believe iterations are inevitable. In such a case, how to keep the development ongoing and how to adopt new updates of the system as you go? Ten years is a lot of time and systems can accumulate technical debt and preventing companies from making progress.
Here is an idea of how to solve the problem. And it goes back to building an airplane in the flight paradigm. Modern SaaS products developed using exactly these models. A typical cloud/SaaS system is developed using short development cycles. The upgrade and adaptation of the system is part of the natural software development cycle. New features can be rolled in the system and based on a system of feature introduction. New releases are continuously running regression tests against customer data. A continues development model is provides a foundation for improvements without disrupting an entire system. And the customer can take his own pace.
I’m learning these days how much wiliness, large manufacturing companies have to embark on the SaaS journey. You might remember my cloud trajectory diagram. Check it below.
The industry will be moving to multi-tenant global applications. I can see some initial rejection, but it might be no different in perspective of five years plan. Remember back in 2010, nobody believed that manufacturing companies will be ready for the cloud. And this is a reality of hosted PLM today. IT of large companies is hosting applications and servers on AWS. This is a reality of 2019…
What is my conclusion? An existing framework of PLM development is too old and contains too many vulnerabilities. One of the biggest one long development cycles and high risks of failure. At the same time, a new continues development model used by SaaS cloud providers can provide a solution to reduce risk and establish a new application development cycle. With more SaaS applications serving the PLM industry coming, I expect to see new PLM delivery models manufacturing companies will be leveraging. The value of SaaS models for small and medium manufacturing companies is almost obvious. But I can see how these SaaS models will be coming to large PLM implementations as well. Just my thoughts…
Best, Oleg
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.
Image by talha khalil from Pixabay
Pingback: Beyond PLM (Product Lifecycle Management) Blog Autodesk Forge DevCon 2019 - Microservices, API, DevOps and Data - Beyond PLM (Product Lifecycle Management) Blog()
Pingback: Beyond PLM (Product Lifecycle Management) Blog SaaS PLM, Tomcat Restart and Why PLM Vendors Need To Learn DevOps - Beyond PLM (Product Lifecycle Management) Blog()
Pingback: Beyond PLM (Product Lifecycle Management) Blog PLM Circa 2020 - How To Stop Selling Myths? - Beyond PLM (Product Lifecycle Management) Blog()