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

Why so hard to break PLM into components?

Why so hard to break PLM into components?
Oleg
Oleg
8 April, 2014 | 4 min for reading

plm-componentizing

Product Lifecycle Management is not a software. It is business strategy and approach. One of my blog readers mentioned that in the discussion few days ago. Nevertheless, manufacturing companies are usually talking about PLM systems and platforms as something solid and unbreakable. The same picture you can see when looking on PLM online marketing materials and brochures. Despite recent changes in broad PLM acceptance and value proposition, companies still see PLM as a software mostly for engineering domain or driven by engineering IT. One of the dreams many PLM vendors developed for the last decade is how to reach the C-level management such as CIO and engineering executives. In other words, how to reach ERP level of acceptance and awareness.

Earlier today, my attention was caught by Toolbox.com article about modern ERP trends. Navigate to read ERP Trends: Shifting from Big ERP Systems to Componentized ERP Environments.  Cloud is changing the face of ERP. The technology is breaking ERP into pieces. One of the results – two tiers ERP configuration. Here is the explanation I captured from the article.

Because of the coinciding innovations in cloud technology, instead of deploying and implementing traditional ERP infrastructure, organizations started adopting a two-tier, or hybrid, ERP model. Two-tier ERP is a method of integrating multiple ERP systems simultaneously. For instance, an organization may run a legacy ERP system at the corporate level while running a separate ERP system or systems, such as cloud ERP, at a subsidiary or division level for back-office processes that have different requirements. To facilitate the adoption of the two-tier methodology, vendors increasingly opened core databases and application programming interfaces and provided customization tools, thus spurring the advent of self-contained, functional ERP components or modules.

So, what does it mean for existing and future PLM strategies and products. More specifically, it made me think about the possibility to break large and heavy PLM platforms into sets of re-usable components. ERP componentizing example speaks about splitting ERP system into modules such as – supply chain, financial, management, human resources. So what potential PLM split can look like? I can see two possible ways here – business process and lifecycle. The first one is something probably we can see a lot in existing PLM platforms. Requirement management, Design Collaboration, Change Management, NPI, etc. I’ve been thinking about Lifecycle as an alternative approach to the traditional business process oriented approach. Lifeycle approach means to develop applications to serve people with their everyday tasks based on maturity of product in the development or services. Think about manufacturing assembly line. Different tools and operations are applied to manufacturing product to bring it to life. Now think about PLM and software tools. PLM components will be used to create product (actually product data and related information).

Toolbox article also speaks about difficulties of componentized approach. The main one is a potential growth of TCO because of the need to integrated data coming from different modules. Here is the passage I specially liked:

The data from the second-tier cloud ERP or modules typically require normalization to integrate with the legacy ERP system at the corporate level. Although direct cost is associated with master data management to ensure consistency and no redundancy, by extending the life of the legacy system, the intention is to reduce the total cost of ownership (TCO) while meeting additional needs for flexibility and functionality. However, the shorter duration of implementing and deploying a two-tier ERP model can actually lead to increased TCO if the indirect costs, such as training, hiring staff, and vendor support, are not taken into to account, as well.

The same problem will arise if we try to break PLM into components. With no solid data foundation, ability to bring and integrate various PLM components will be questionable. The integration cost will skyrocket. Compatibility between PLM components versions will make it even harder. Nevertheless, I can see growing business requirements, customers’ demand and shorter lifecycle for software products as something that will drive future PLM technological changes. Componentizing will be one of them.

What is my conclusion? To break large and heavy PLM suites into configurable and flexible components is an interesting opportunity to satisfy today’s dynamic business reality. However, two fundamental technologies are required to make it happen – scalable open data platform and reliable integration technologies. Just my thoughts…

Best, Oleg

Recent Posts

Also on BeyondPLM

4 6
20 September, 2019

The weekend is coming and this is a time for some PLM dramas. Engineering.com and Verdi Ogewell is usually not...

25 May, 2010

A very interesting video presenting how you can track hand motion in the virtual 3D Model. The demo prepared by Robert...

28 June, 2017

I’m in Germany attending CONTACT Software Open World. My “State of PLM” keynote is tomorrow. However, I had a chance...

25 June, 2018

Last year I asked in one of my articles – Is PLM business Amazon Proof?  If you run a business,...

13 October, 2017

Graph is a very powerful paradigm. For many years, the idea of “graph” or “connection” was empowering software engineers to develop...

13 March, 2014

It has been 25 years of Internet anniversary yesterday. Lots of article covering this event were flown around earlier this...

21 May, 2017

PLM mega event is coming this week to Boston. PTC is hosting LiveWorx 2017 in Boston Exhibition and Convention Center...

23 December, 2010

Just a short note to wish everyone a great Holiday Season and Happy New Year! Best, Oleg

28 April, 2016

In software application programming interface (API) is a set of routines, protocols and tools to build a software. An API...

Blogroll

To the top