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
28 August, 2009

Thinking more about PLM implementation during last few days, I’d like to come and discuss few aspects of PLM implementation...

2 April, 2012

Few weeks ago, back to my trip to Munich PLM Innovation Congress, I published post – Will Europe Adopt Cloud...

9 August, 2019

One of the most commonly used PLM sales scenarios is to sell it as an expansion of existing PDM system....

2 December, 2009

Extensive development of social trends and connection between social trend and product lifecycle management got me to think more about...

12 October, 2017

Market is transforming. New technologies and new business models are coming to PLM space changing the way business is done....

15 June, 2012

I’ve been attending SolidEdge University 2012 earlier this week in Nashville, TN. Inforbix (the company, I co-founded two years ago)...

19 December, 2013

The technology can make a difference. What technological approach can make a difference in the future of PLM? This is...

22 January, 2016

Old concepts are sticky. Think about QUERTY keyboard. It was designed almost 150 years ago with a special reason –...

15 January, 2022

As Artificial Intelligence (AI) and Machine Learning (ML) become more prevalent, many businesses are starting to ask how they can...

Blogroll

To the top