How to replace PLM legacy systems and to move forward

The decisions about PLM system selection and implementation are slow. I took part in few of them during my last year consultancy practice. It is long and sometimes multi-year process. Once manufacturing company is making a decision about specific PLM system, it is very hard to change. It has too many dependencies.

Think about product development from engineering to manufacturing. The majority of software used by companies is 10-15 years old and a process of replacement is a nightmare. I won’t be surprised if some manufacturing companies are still using ALGOL and FORTRAN in production. It is hard to implement PLM systems, but it is even harder to replace it.

It is a clear conflict between business dynamics these days and slowing changing IT processes in product development. New system can provide a better support for new processes or fill the gap in existing system with a specific functionality. However, to make it happen is a big challenge manufacturing companies are facing these days.

Business is fast, PLM systems are slow to catch up 

Enterprise software is slow to make a progress. So, is there an approach that can help manufacturing companies to solve the problem? What of PLM software companies will make a shift towards new way of thinking about building new PLM software and replacing old legacy ones.

As we move towards cloud software and agile development processes, one of the technique used in software development can be applied to speed up the development of PLM systems. Slide below can give you an idea. See full presentation deck by  Rachel Laycock, Lead Consultant at ThoughtWork is here.

Martin Fowler’s article gives you a simple explanation of the method. Here is a passage explaining that:

We create an abstraction layer that captures the interaction between one section of the client code and the current supplier. We change that section of the client code to call the supplier entirely through this abstraction layer. We gradually move all client code over to use the abstraction layer until all interaction with the supplier is done by the abstraction layer. As we do this we take the opportunity to improve the unit test coverage of the supplier through this abstraction layer.

We build a new supplier that implements the features required by one part of the client code using the same abstraction layer [2]. Once we are ready we switch that section of the client code to use the new supplier. We gradually swap out the flawed supplier until all the client code uses the new supplier. Once the flawed supplier isn’t needed, we can delete it. We may also choose to delete the abstraction layer once we no longer need it for migration.

New cloud PLM services can absorb an existing system and replace it eventually

Legacy PLM implementation can be considered as an existing supplier code. New system or process can absorb an existing one, to insure that everything is working smooth. Then pull the trigger and remove old parts. Once replacement done, new service can be used to future optimize system behaviors and solve problems.

You can think about this process similar to building construction bridges. In building the new eastern span of the Bay Bridge, engineers didn’t tear down the old one and erect the new one in its place. They do it different by building the new span in addition to existing one, make sure the new bridge can handle the same traffic and then swap bridges. Modern cloud software is build exactly the same way to insure service is not interrupted.

Branch by abstraction is an elegant  concept that could be quickly applied to any programming language. In a world totally dependent on software code, much older pieces of enterprise software are still everywhere.

What is my conclusion? The core problem of PLM technologies and products today is related to their inability to adopt to existing processes. Each PLM implementation starts from the establishment of new data structures and building processes around it. This process is forcing company to make full circle of business process changes from the beginning. It is a very painful experience. New PLM implementation approach should be able to swallow existing product development processes and then to implement a set of gradual changes to improve it. It will benefit both PLM vendors and customers. It will help to get rid of old, outdated over-complicated software and support faster adoption of new business processes. Just my thoughts…

Best, Oleg