A blog by Oleg Shilovitsky
Information & Comments about Engineering and Manufacturing Software

How to replace PLM legacy systems and to move forward

How to replace PLM legacy systems and to move forward
Oleg
Oleg
8 February, 2016 | 4 min for reading

plm-legacy-swap

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.

branch-by-abstraction

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

Recent Posts

Also on BeyondPLM

4 6
20 September, 2021

Earlier today, I attended a traditional CIMdata PLM Industry and Market Forum, which CIMdata holds usually in multiple geographies. Today...

6 September, 2010

I decided to make an unusual post today. Because of holiday (Labor Day in USA), I spent most of the...

25 January, 2018

There are not so many pure PLM events in this world. Product Innovation (PI) formerly known as PLM innovation is...

14 February, 2012

Monday was my second day in San-Diego. SolidWorks World 2012 was officially launched with general session with presentations of SolidWorks...

23 June, 2017

Relational databases are the foundation of every traditional PLM system. Over the past 30 years, we’ve seen the evolution of...

30 October, 2011

I was reading Oracle journal early today. Navigate your browser to read a short article – Which Cloud Service Provider...

29 February, 2020

There are very few topics in PLM vocabulary that can raise fewer debates that these three letters – FFF, which...

29 January, 2021

The modern PLM industry is paying significant attention to the concept of Digital Thread. In a nutshell, a digital thread...

8 February, 2020

I’m coming to 3DEXPERIENCE World 2020 next week. It feels unusual, but also interesting and encouraging. For the last few...

Blogroll

To the top