This week, I’m heading to the 2025 CIMdata PLM Market & Industry Forum in Ann Arbor, Michigan. Note, the Futuristic Base image generated by AI using DALL·E 3 and edited by me.
The theme this year—“Model-Based Systems Engineering: Optimizing Systems of Systems”—feels especially relevant and timely. CIMdata’s forum is always a valuable gathering of PLM solution providers checkpoint on the direction of the PLM software industry. A traditional update about the State of PLM industry, numbers, and theme discussion related to some element of business systems, business processes, development process, product lifecycle, engineering data – this year it is an exploration of Model-Based Systems Engineering (MBSE): what it is, what’s driving it, and where organizations are still facing challenges.
In my perspective MBSE resonates with the complexity I see everywhere in the product development. For some reason, my new kettle has a wifi card and reports to my phone that water has been boiled. Not sure why it is needed, but this level of complexity goes everywhere.
The MBSE focus resonates deeply with the growing realization across industries: managing today’s complex, connected products requires more than traditional, disconnected document-based methods. As product complexity scales, we need to think in systems—and systems of systems. It’s no longer just about tools or processes, but about reimagining how product information flows, evolves, and connects across the entire lifecycle. That brings me to a big question I’ve been thinking about lately- what model can manage this level of complexity in a scalable and robust way…
System Engineering and Model Based System Engineering
Systems engineering is a multidisciplinary approach to designing, developing, and managing complex systems throughout their lifecycle. It includes activities such as gathering and managing requirements, defining system architecture, coordinating across engineering domains, integrating components, and validating the final system. Traditionally, this work is done using documents, spreadsheets, and diagrams, which can become difficult to manage as system complexity grows.
Switching to Model-Based Systems Engineering (MBSE) means replacing those disconnected documents with formal, digital models that serve as the central source of system information. These models represent structure, behavior, requirements, and constraints in a consistent and traceable way. MBSE improves collaboration, reduces errors, and supports early validation through simulation and analysis. The transition requires new tools and processes, but it leads to better system understanding, improved efficiency, and stronger control over system development.
Common models used in MBSE include structural models (such as block definition and internal block diagrams), behavioral models (like activity, state machine, and sequence diagrams), requirement models (for traceability and verification), and parametric models (for performance analysis). These models work together to provide a complete, connected view of the system from different perspectives.
Popular modeling tools used in MBSE include Cameo Systems Modeler, Enterprise Architect, Capella, Rhapsody, and Simulink, among others. These tools support SysML (Systems Modeling Language) or other modeling standards, and often integrate with domain-specific tools for electrical, mechanical, and software design. By combining these tools with a model-driven process, engineers can manage complexity more effectively and deliver better systems faster.
The Legacy of Documents in Engineering and Manufacturing
For decades, engineering and manufacturing have revolved around documents. Whether it’s CAD files for mechanical design, simulation reports for performance testing, spreadsheets filled with BOM data, or change orders in PDF format—documents have been the core building blocks of collaboration and decision-making.
Product Data Management (PDM) and Product Lifecycle Management (PLM) systems origins go back handling these files. ERP systems were designed to digest structured reports derived from them. Collaboration? That meant emailing files, printing drawings, or uploading spreadsheets to shared drives. In a best way, it was about placing all info into a single SQL database.
This approach served its purpose for a long time. But as products evolved—becoming more complex, more connected, and increasingly software-driven—the cracks began to show. Engineering teams include mechanical, electronics, software groups. Contractors and suppliers are distributed across the globe. Teams and activities became disconnected. Data was scattered across siloed systems. Processes remained manual, error-prone, and slow. Traceability suffered. And any notion of digital continuity faded.
The Shift Toward Model-Based Thinking
This is where the model-based approach begins to make sense. Unlike the static nature of traditional documents, model-based systems focus on structured, semantic, and connected representations of information. These aren’t just diagrams or visualizations—they are dynamic, data-driven models that define how a product behaves, how it is built, and how it evolves.
But this shift invites an important question – was it a PLM Hole Grail that promised to connect everyone together with a single source of truth (SSOT) and “enable collaboration”? Unfortunately even most well developed (and unfortunately monolithic PLM platforms) are unlikely up to this job. And with distributed nature of engineering and manufacturing, the problem is becoming even more complex.
The goal should be to improve the model used by PLM (or to invent another type of systems) capable to provide a model to coordinate and connect everyone and everything together. And the question is there a universal model that can represent everything? The answer is no. And that’s perfectly okay. But then the question is what to do?
Why One Model Isn’t Enough
Modern engineering is far too diverse for a single model to capture every aspect of a product. To effectively manage the complexity of today’s products, what’s needed is a system of interconnected models—each tailored to a specific perspective or domain. These models collectively support the entire product lifecycle, from concept to delivery, enabling better collaboration, traceability, and decision-making across teams.
At the early stages, Functional Models define what the product is supposed to do. They capture user needs, high-level requirements, and intended use cases. Logical or Architectural Models then describe how the system is structured—breaking it into subsystems, components, and interfaces to align with the overall functionality. As the design matures, Physical or Design Models take shape, detailing CAD assemblies, schematics, and other 3D assets representing the product’s physical embodiment.
Once the structure is defined, Behavioral Models come into play, simulating how the system will perform under various conditions. These models are key to early validation and testing. Manufacturing BOMs (MBOMs) provide a view of how the product will be built—listing all parts, operations, and assembly steps. Meanwhile, Configuration Models handle the complexity of product variants, customization rules, and constraints, ensuring product options are managed efficiently.
To manage the journey of a product, Lifecycle and Process Models oversee its evolution—supporting releases, changes, and compliance. Data Models serve as the backbone of the digital thread, defining how items, BOMs, revisions, and relationships are organized and interlinked. Finally, Supply Chain Models bridge the gap between engineering and procurement by connecting product data to suppliers, cost structures, lead times, and sourcing decisions. Together, these models create a comprehensive, flexible, and scalable approach to product lifecycle management.SysML and Model-Based Systems Engineering (MBSE) play a foundational role in orchestrating the early phases of complex product development. MBSE leverages SysML to create formal, structured representations of system requirements, functions, behaviors, and architecture. Within the broader system of models, SysML is particularly effective in defining Functional Models, Logical Architectures, and Behavioral Models, allowing engineers to understand what the system must do, how it should be structured, and how it will behave under various conditions. MBSE encourages early validation and traceability, helping teams reduce ambiguity and ensure alignment across engineering disciplines.
From my perspective, SysML and MBSE represent just one layer in a much larger ecosystem of product models. While SysML is good for systems-level abstraction and early design, it must be complemented by other domain-specific tools and representations—like CAD for physical models, PLM/ERP for BOMs and manufacturing processes, configuration engines for product variability, and data models for managing digital continuity. MBSE provides the framework and rigor to manage system complexity, but realizing a true digital thread across the full product lifecycle requires integrating MBSE outputs with downstream systems such as design, production, and supply chain.
Why Graph Models and Why It Important
I’m bring of my favorite technological topic these days – a growing number of graph-based applications to solve the problem of complexity.
The graph model and graph database (Graph DB) approach is becoming a powerful solution for data abstraction and modeling, particularly in domains that involve complex relationships, such as PLM, digital thread, and supply chain. Unlike traditional relational databases, which require complex joins to represent many-to-many relationships, graph databases store data as nodes and relationships, allowing for a more natural representation of connected information. This model is especially effective when you need to represent product structures, dependencies, or lifecycle relationships, where each element can be directly linked to others through flexible and meaningful connections.
One of the most valuable aspects of graph modeling is its high level of abstraction, which mirrors how engineers and businesses think—through things and their interconnections. Whether you’re modeling a product’s lifecycle, a multi-view bill of materials, or a supply network, graphs make it easier to represent real-world complexity without forcing artificial structures or constraints. Each object (like a part, drawing, or supplier) becomes a node, and each relationship (such as “contains,” “depends on,” or “approved by”) becomes a link. This abstraction aligns perfectly with modern data-driven applications that demand traceability and dynamic connections.
Graph databases also support a schema-less or schema-light design, which is a major advantage in fast-changing engineering and manufacturing environments. New types of objects, relationships, or attributes can be introduced without requiring the entire model to be reworked. This flexibility allows organizations to evolve their data structures as business needs change, without waiting for long implementation cycles. It’s particularly useful when dealing with evolving product requirements, new compliance rules, or expanded supplier networks.
In terms of performance, graph databases are optimized for exploring connected data. Operations that are slow or complex in relational systems—such as traversing deep product structures or analyzing change impacts—are fast and intuitive in a graph. This capability is especially relevant when modeling dependencies across design, engineering, manufacturing, and service, enabling rich queries that go far beyond what traditional SQL can handle. The speed and depth of graph traversal make it a foundational tool for real-time decision-making.
Another strength of the graph model is its compatibility with modern architectures. It supports composable and federated approaches by allowing decentralized data to be linked without centralizing or duplicating it. This makes it ideal for connecting PLM, ERP, MES, and other enterprise systems into a unified, semantically-rich model. Rather than imposing a rigid structure, the graph serves as a connective tissue, enabling interoperability and data federation across the organization and beyond.
Finally, graphs are well-suited for powering AI and data intelligence applications. Because of their ability to model semantic relationships, they provide a foundation for recommendations, pattern recognition, and lifecycle insights. This makes them ideal for digital thread use cases, where you need to link data across time, departments, and suppliers to enable full product traceability and continuous improvement. In a world where everything is connected, graph models offer a fundamentally better way to represent and leverage the complexity of modern product development and manufacturing.
What is my conclusion?
Let’s connect the dots. We’re at a turning point for product lifecycle management, PLM tools development and organizing product development process, quality management, and supply chain management. The legacy of document management and document-based processes is giving way to the future of data-driven, connected models. And while there may never be a universal model, there is a universal approach worth embracing—model-based, connected, and purpose-built for the digital age.
The real value of a model-based approach isn’t in any single model—it’s in how these models connect. When models are linked in a unified, contextual network—a digital thread—they can support real-time collaboration across engineering, manufacturing, supply chain, and beyond.
Technologies like graph databases, semantic modeling, multi-tenant cloud platforms, and AI agents are critical enablers of this vision. They provide the infrastructure for managing product data not just as documents, but as living, evolving data structures.
As I prepare for the upcoming CIMdata Forum and think about MBSE, systems engineering, and the future of digital transformation, one thing is clear – we don’t need one model to rule them all—we need a system of models that can work together.
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a digital-thread platform providing cloud-native collaborative services including PDM, PLM, and ERP capabilities. With extensive experience in federated CAD-PDM and PLM architecture, I’m advocates for agile, open product models and cloud technologies in manufacturing. My opinion can be unintentionally biased
