PLM and ALM: How To Blend Disparate Systems?

I had chance to read an article in SD time – Organization works to blend application, product life-cycle management. Author discussing the need to integrate two separate domain – development of hardware and mechanical components and software. I think, the message is very timely made. There are lots of software in modern products. Author brings an example of OnStar in vehicle communication. However, it is possible to bring more examples, of course.

Integration between disparate application having completely different set of data, rules and behavior is always a very challenging use case. In this case, author discussing the future of common standard creation that will help to integration PLM components and components managing software lifecycle (i.e. Rational tools). This discussion made me think about potential pitfalls and opportunities on this way.

Heterogeneous Application Environment
In the real world, many applications used during the design, engineering and manufacturing process. Mechanical, Electrical and Software teams are normally separate and relation between them quite limited from the software sides. This is the reality. In my view, when it comes to software, the disconnection comes to the top level. What can be a system that controls software build level need to be placed in the particular vehicle or other mechanical product?

Does One Standard Fit All?
The author is discussing OLSC (Open Services for Lifecycle Collaboration). I found the following video funny. The idea of community is going very much aligned with modern social approaches.

There are three key fundamental principles – URL, Minimal Schema and REST services proposed to make this solution work. I’m thinking how much time people will spend before they will agree about minimal schema that fit all. At in the end, as film states everybody wants to be a little different.

Don’t Integrate, Just Connect Dots
Here is my point. We don’t need to invent a minimal schema. It is enough to agree about to interlink different product representation- mechanical, electrical, software. Think about URL only. In my view, it will be enough to get job done. Global data identification similar to what we have in the internet can move us in the right direction. One of the examples of such technologies can be PURL. “A persistent uniform resource locator (PURL) is a Uniform Resource Locator (URL) (i.e. location-based Uniform Resource Identifier or URI) that does not directly describe the location of the resource to be retrieved but instead describes an intermediate (more persistent) location which, when retrieved, results in redirection (e.g. via a 302 HTTP status code) to the current location of the final resource.”

What is my conclusion? The landscape of application involved in this product development is very large. The number of applications is growing. The ability to absorb the requirements of all applications into one minimal single standards schema seems impossible. The new and more efficient way to interlink data need to be proposed. We don’t need to bring software build and engineering bill of materials to a single representation. However, we need to be able to interlink data related to different applications to maintain data integrity.

Just my thoughts…
Best, Oleg

Share

Share

Share This Post