Conway’s Law in Enterprise PLM Implementations

Do you know what’s Conway’s Law? I didn’t… Until last week. I was learning how organizational structure can impact the outcome of engineering activity and found a few interesting references to Conway’s law. Any complex activity outcome can be presented as a system these days. A car is a system, a manufacturing company is a system and actually PLM is also kind of a system (to all analysts calling, PLM a strategic approach, please hold your breath here and give me few more minutes :))

Here is a general wording of Conway’s Law. It is named after computer programmer Melvin Conway, who introduced the idea in 1967. His original wording was:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

I captured an interesting passage from the archived page:

Conway’s law was not intended as a joke or a Zen koan, but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.

It made me think about information and communication structure I’ve seen many times in manufacturing companies and engineering teams implementing PLM systems. The most fundamental part of any PLM system is the data structure or data model. I found very interesting that the most efficient and reliable data models are reflecting the organization structure.

Think about mechanical, electronic and software components. Then add manufacturing planning, shop flow organization, procurement, maintenance. Each of these domains (or roles) will be represented by separate information structures – design or engineering BOM (As-designed), even presented as a single piece will be most probably separated into mechanical, electronic and software data structure. You go forward to manufacturing planning and you will have manufacturing BOM and planning. Each one will be represented as a different data structure (As-ordered, As-planned, and As-built). If a company does maintenance, be sure to find As-maintained (or As-service) BOM.

The reflection of the organization is interesting. What does it mean for us? What can we learn from this and how can we use it to make PLM system implementation successful? How to improve PLM implementations? Knowing what I’ve learned, you can think about how to make enterprise PLM data model and organization to reflect the organizational and product development structure. Another thesis is that any attempt to change this structure can be dangerous because it will create an organizational conflict.

The Bill of Materials is a fundamental element of enterprise PLM. Imaging EBOM and MBOM. The attempts to combine them together can be the scariest thing because it will create an organizational conflict. At the same time, giving engineering and manufacturing organization their own BOM can solve tons of problems and eliminate debates of who owns what and who can change things.

Unfortunately, things are not easy. Because at the moment, you create a feeling of peace by separating the data you eventually going to hit by the “silos” problem. Each data domain will create its own silo and integration between these silos will require a separate effort.

Here is my version of Conway’s Law for PLM:

The Number of BOMs managed by Enterprise PLM will be equal to the number of organizations and sometimes teams involved in the design, production, maintenance, and support.

The way to improve PLM system implementation is to create a structured process to reflect organizational structure and processes. And if you want to change it, you better start from organizational changes and process improvement.

What is the conclusion?

Organizational structure influences the PLM data model and communication. The way any PLM system is implemented is impacted by the way the organization works and how processes are organized. It can be a good thing because it gives us a way to plan PLM implementation by researching an organization, people, data and their relationships. This is could be a good method to build a stable PLM system. It has one caveat – business transformation. PLM implementation is an opportunity to transform an organization by forming an organizational strategy and introducing a better process. Knowing that you better start from organizational changes and then to bring a proper PLM system support. Together you can call it PLM strategic approach (sigh :)) Just my thoughts…

Best, Oleg

Disclaimer: I’m the co-founder and CEO of OpenBOM, a digital-thread platform providing cloud-native 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.