Achilles Heel of MBSE and PLM modeling

Achilles Heel of MBSE and PLM modeling

Aras’ presentation by Pawel Chadzynski MBSE and the Business of Engineering brings some interesting perspective of what Aras is thinking about model driven system engineering. I can see a growing interest in model-driven approach, but not much agreement how things supposed to work. In a nutshell, everyone agrees that model is a good thing and if we can apply ‘model’ to serve our needs, then organizations can get lot of benefits from variety of aspects – data traceability, early data exploration, change management and more.

Aras’ slide deck does an excellent job presenting complexity of production development. The visualization of circles and with colored nodes-network is really neat. I like it.

Things are getting a bit more complex when you go into some implementation slides mapping  MBSE models with PLM structures. I like the slide.

However, it made me think about few potential complexity challenges (1) change complexity; (2) organization complexity.

1- Change complexity

The static model looks nice and allows you to have full traceability of data. It gives you a tremendous value. However, I was trying to image the change in this structure and things were shaking because of multiple changes that can happen simultaneously in a model of connections, changes, revisions, versions and structures. This is a moment when change model can conflict with collaboration model. The transactions can be dead-locked or apply to old data. I’d was looking for change management diagram, but presentation doesn’t have one.

2- Organization complexity 

To apply organizational structure into this model can be even more interesting experiment. PLM and MBSE models are not mentioning organizational boundaries. Once applied, can trigger a question of database boundaries. If an entire structure is managed as a single tenant, it will most probably survive. But then everybody in an entire organization of OEMs, Tier 1…n, contractors and suppliers will be using the same PLM database. The reality might be different and it will introduce another level of complexity in the implementation (organizational silos).

What is my conclusion? I like the model of connecting PLM structures with extended information sets of system engineering domain. However, I’m curious how both change management and organizational complexity can be managed. Although, I can see a value even in a read only structure connecting domains of information. But, the notion of Enterprise ECM assumes some dynamic behavior and the reality of distributed work can demand companies to work in multiple databases or event more complex architecture to support it. How to solve these problems is a topic for another blog. 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.

Share

Share This Post

  • Pingback: GHZ Partners | IT Services, Software()

  • Pawel Chadzynski

    Great issue and a great question, as always! The co-dependency between product CM and enterprise ECM vs. distributed data bases goes to the heart of the true value of a PLM
    platform. The key is to realize that although the information itself is often
    scattered across the enterprise and across multiple data bases – a
    central (single) PLM platform should (given the right platform architecture) be
    capable of modeling the individual data models within these data bases
    including the local CM specifics and therefore be able to overlay a unified CM
    layer without content replication. That BTW is where various link-based
    approaches to distributed data basis fall short since a) they themselves become
    yet another unstructured set of information to be managed, and b) they link
    without the knowledge of the local data model and CM specifics on either side
    of the link. So let’s talk about the right PLM platform architecture as the
    answer.

    Pawel

  • beyondplm

    Pawel,

    Thanks for your comment! I’m interested to understand more the following comment about central PLM model vs. linked models.

    On one side, you say that central database (PLM platform) will overlay CM without content replication (which means links?). On the other side, you said “link-based approaches” fall short.

    Can you clarify, please?

    Best, Oleg

  • Pawel Chadzynski

    Oleg,

    Think of the data link as a one nightstand (easy to create but has a short life) and of the PLM relationship as a marriage (takes effort to define but tends to last). So a relationship has a behavior relative to what it connects – and PLM must understand context/semantics of all three. A relationship may be fixed (always pointing to a specific rev of items at either end even if they evolved), or floating (always bubbles to the last rev of what is connected). Data may be a structure (ex: a BOM) or a process (ex: ALM branch/merge). Effective CM depends on a single PLM platform capable of modeling this regardless of data location. In this environment, system model is just another specific model. Specific because one does not only trace “to/from it”, one also traces “through it” (ex: test and requirement it verifies). And because of handling 150% system model and variant configuration. BTW – your understanding of Aras is correct: it can be a single repository of all the data. But it can also federate databases (by modeling their structures) and it can be a central overlay to the deployed PLM solutions (by modeling data relationships and processes). So you don’t need to rip/replace the old PDM…

    Pawel

  • beyondplm

    Pawel,

    to be honest, link vs relationships comment is beyond my level of English. I’m sure my readers with English native speaking skills can appreciate the nuances. But I cannot… I Googled “link vs relation(ship)” and ended up with conclusion that link is synonym of relation (https://wikidiff.com/link/relation). Also, I found that relationships is usually applies to social connection. I’m not even trying to argue about English 🙂

    But, here is the thing.. the complexity of PLM is well know problem. If PLM vendors will require to take ESL classes before, the adoption can be a problem. Just my 2 cents.

    At the same time, I’m still trying to understand the difference between central PLM and linked approach? Does it mean central PLM model has “relationships” to other databases?

  • Pawel Chadzynski

    Don’t worry about English nuances, it is my 2nd language after all 🙂 so ESL is already part of PLM! In any case English is a living thing, is it not – so I’m having a bit of fun here with terminology. In that spirit a link is more like a URL which is not aware of the CM aspects of the connection or the items that it connects. Relationship on the other hand is aware of all of that. The importance of a central PLM platform (has to have the right architecture as opposed to a BOM managing PDM) is that it already has all the underlying CM services for everything that can be modeled using that platform (not only BOM structures). So yes, the central PLM model will have to have “relationships” to other databases. What else can be done? Create yet another database for links only? Or create direct linksbetween various databases that don’t themselves understand CM? So now one has to create new CM/lifecycle services around those links in the link database or in the linked databases? How is that simplifying implementation of CM and lifecycle management (traceability) across all abstractions and states of a complex system/product? That is a question for you :). Sounds like a great subject to explore with a panel
    discussion!

  • beyondplm

    Pawel, I will take a challenge to speak about “links” in a separate blog article. Let’s see how it will take us :). Watch my blog later this week.

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog PLM modeler software wasteland - Beyond PLM (Product Lifecycle Management) Blog()