PLM over-engineering

“Two engineers. Three opinions”. You probably heard this joke before. This is a reality of engineering world. In my view PLM projects is a quintessence of the complexity and opinions about the requirements and how things should be implemented. Business requirements are exploding, discussions are endless and the result is bloated implementation with lot of features, options and constraints. The unfortunate outcome of this is a potential over-engineering of PLM software.

The article 10 Modern Software Over-Engineering Mistakes gives you an excellent set of examples how you can potentially over-engineer software and also provides some recommendation about how to avoid it. Read the article and share it with your team.

In my view, this is a “must read” article for PLM architects. Some of the examples made me chuckle and some them are mistakes I’ve seen in most of PLM products.

Here are two of my favorite examples:

1- Re-usable business functionality.

In my view, PLM software can set a top record in delivering such thing as “PLM platform” and trying to insure that all functional channels are under a full control and centralized. Here is a picture to demonstrate that.

2- General purpose tools and services.

The challenging path PLM systems are often following is to find or to create a generalized set of reusable functionality. Generic adapters, generic queries, generic data mapper (data modeller), generic request, generic executor, etc. Are you familiar with that? I’ve seen it so many times. Instead of trying to solve the business problem, we waste our time trying to find the perfect set of reusable services. The answer is so simple – stay shallow and make it usable.

3- An attempt to find a perfect abstractions.

The core element of any PLM system is functional data model. Everything starts and ends there. Every PLM system have created an abstraction for its own data model. Here is the thing – PLM vendors are paying huge price on developing of perfect abstractions and trying to follow them into implementation. Here is a passage from the article

Designs are always playing catch up to changing real world requirements. So even if we found a perfect abstraction by miracle, it comes tagged with an expiry date because #1 — The House wins in the end. The best quality of a Design today is how well it can be un-designed. Conversely, Duplication is sometimes essential for the right abstraction. Because only when we see many parts of the system share “similar” code, a better shared abstraction emerges. The Quality of Abstraction is in the weakest link. Duplication exposes many use cases and makes boundaries clearer.

What is my conclusion? PLM systems are paying huge price tag by over-engineering things, building sophisticated abstractions and bloated architectures. The result is that manufacturing companies are spending tons of time to find how to map their specific requirements into PLM software architecture. This is a problem with analog PLM I described in my earlier article. Simplicity is the ultimate sophistication. Future PLM systems will have to explore the simplification route in PLM software development and implementation architecture. Just my thoughts..

Best, Oleg

Want to learn more about PLM? Check out my new PLM Book website.

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.