Connections tell the Story

In my previous post, ‘Understanding the Impact of Changes‘, I used the analogy of flights, flight plans, gates, control towers to explain how difficult it becomes to manage changes and their dependencies. To address this, CM2 from the Institute for Process Excellence has a solution called the CM2 Baseline or a.k.a. the As Planned/As Released Baseline. And while the SAE-EIA-649C standard for Configuration Management in its latest revision hints at this type of baseline, it still has a lot to mature compared to the CM2 definition.

“This baseline not only contains the latest Released and the Effective configuration, but it also contains all planned changes against the configuration (in context). And not just as a tag that the item/node or dataset will change, it will allow you to show how the delta will impact the item, its structure, and its related datasets.”

If you read closely, you will see that structures and relations, or in other words, connections, are key to the CM Baseline. These connections and the related information/nodes are stored in different systems, or you might even have multiple nodes representing the same business object. The information in the various tools needs to be communicated to other tools to be of use in other processes. 

This brings me to the core of the problem:

Communication is merely an exchange of information, but connections tell the story.*

The exchange of information between tools is just that, a communiqué. It does not share the entire context, which is captured through connections. It is often limited to the information needed by a particular downstream process. But that can hide information relevant for doing impact analysis of changes to your product or when you want to make a roadmap for the configurations of your products and services. 

The CM Baseline addresses this problem by combining the Business Object Graph, Impact Matrices of changes, dependencies between changes, and planning of deliverables. The focus of this post will be on the Business Object Graph. Future posts will dive further into the other components.

Pyramid graphic by Martijn Dullaart. Picture of the Impact Matrix: Copyrights by IpX – Institute for Process Excellence from the CM2 courses. Pictures of the Business Object Graph, Dependencies, and Planning by Martin Haket.

Business Object Graph

Because multiple tools contain parts of the information and the connections are sometimes implicit, there is a need to expose the information as a business object graph. The business object graph gives you a holistic view of the product and all its connections that tell the entire story. This semantic graph, this business object graph, all nodes, and connections/relations are available in one place instead of 3 or 4 different tools. Such a graph allows for very fast querying by traversing the connections, from left to right, right to left, top to bottom, and bottom to top. It is also nothing new, different companies have already created such a business object graph. A nice example is Schleich as shared by Andreas Weber in his article/presentation: Semantic PDM: Using a Graph Data Model at Schleich

A simplified example of a Business Object Graph is shown below. Where you can see the path of connections from Requirement to Work Instruction.

The connections tell the story. Following its path and understanding, the meaning of the connections gives you a powerful capability to analyze the impact of changes to help plan future configurations. When you zoom in, you can see the story unfold:

“Part5 has an Engineering BOM that contains Part 2 and Part3, both with Quantity 1. Both Part2 and Part 2 are consumed by Operation1, described by Work Instruction1.”

And while this only shows a very simplified version of reality, it does show its potential.

Fundamental principles for the Business Object Graph

The following principles are essential to minimize the impact on current ways of working and maximize the usability of the CM Baseline:

  • The Business Object Graph shall be based on released data from the expert domain tools. 
  • Every time new information gets released in one of the (source) expert domain tools, it will be shared (real-time) with the CM Baseline. 
  • Only nodes, relations, and a limited set of metadata are shared. No content is shared, e.g., file content (a reference to the file can be shared if required). The graph needs to be lightweight.
  • The CM Baseline can only transform/translate the data into a business semantic data model but not modify the released data. Changing the data can only be done in the expert domain tools. 
 
For achieving all the benefits a CM Baseline has to offer, more is needed. Impact of changes, dependencies between changes and planning of deliverables are key to unleash the power of the Baseline. More on this in one of my next posts. In the meantime feel free to share your thoughts on this topic.
Header Photo by Tim Mossholder on Unsplash (flipped to the right). 
*Quote is inspired by the Quote: "Communication is merely an exchange of information, but connection is an exchange of our humanity." by Sean Stephenson, Get Off Your "But".

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept the Privacy Policy

This site uses Akismet to reduce spam. Learn how your comment data is processed.