A seamless product context layer could make collaboration easier to adopt, starting with the work companies already do.
I read Jos Voskuil’s recent article, Conway’s Law – the PLM killer! – and it caught my special interest. Jos connects the difficulty of digital transformation to organizational structures that reward local performance. Engineering, manufacturing, purchasing, and service optimize their own work, while the business needs them to collaborate across boundaries.
He also makes an important distinction: product lifecycle management is a strategy supported by a federated infrastructure of systems. I agree with that direction. A single application cannot reasonably become the working environment for every discipline involved in a product.
But his conclusion made me pause. If companies struggle to adopt the strategy, why should we conclude that the organizations are the problem? Shouldn’t we also examine the software and the ideas we ask them to adopt?
In a follow-up to my comment, Jos clarified that organizational change should develop with the software, and does not necessarily have to happen first. He also emphasized the difference between making individual departments more efficient with AI and reshaping how the business operates across them.
That clarification helps. Our exchange brings the practical question into focus: how should the software and strategy help an organization develop new ways of working? An organizational explanation can be valid and still leave an architectural problem unresolved. My question is whether we have spent enough time designing a practical path between the organization we have and the collaboration we want.
Conway’s Law explains a constraint
Conway’s Law describes how the structure of a system reflects the communication structure of the organization that designs it. It gives us a useful lens for understanding why boundaries appear in products, processes, and software.
But that observation does not establish that a particular PLM strategy is appropriate, that its supporting software is usable, or that reorganizing a company is the only way forward.
There is another question we can ask through the same lens: what organizational assumptions are built into the software itself? Which roles, information ownership rules, and handoffs does it expect? How much flexibility does it give a company whose work does not match those assumptions?
These questions matter because companies arrive with existing products, installed systems, contractual obligations, and people who have jobs to complete. Those conditions form part of the problem the solution must address.
Organizational change may be necessary. A company cannot resolve conflicting priorities simply by installing a new interface. Leadership still needs to establish responsibilities and make decisions about incentives. At the same time, software can make coordination easier or harder. It deserves to be examined as part of the diagnosis.
Technical possibility is only the beginning
One statement in Jos’s article particularly caught my attention: “Technology has never limited a fluent PDM-ERP interaction.”
I understand the importance of agreeing on the business process before configuring systems. But an integration being technically possible tells us very little about the effort required to operate it reliably.
Can the company implement it with the skills and budget available? Can it preserve the intended identities and revisions? Can someone understand why a transfer failed? Can the connection survive changes to the systems on either side?
These are adoption questions as much as technology questions.
The part-number example Jos discusses is useful here. A company can have good reasons to control identifiers. Yet we should still examine a process that requires an engineer to obtain an ERP number before design work can proceed. Which step serves a real business requirement? Which step exists because a system expects production-ready information too early?
The answer may require changes to the process, software, or both. Describing the difficulty as organizational does not settle that question.
Adoption belongs in the architecture
When I think about a PLM strategy, I want to understand its first useful result. What can a team accomplish before the entire company has completed its transformation?
Perhaps engineering and purchasing can agree on the information needed for a prototype order. Perhaps two design disciplines can preserve the combination they reviewed for one product. Perhaps a manufacturer and a supplier can connect a drawing, a quotation, and a decision without everyone adopting the same authoring environment.
These are limited scopes, but they test something essential: whether the proposed approach improves actual work.
That improvement should be visible to the people contributing information as well as those receiving it. If engineering performs additional administration while every benefit appears somewhere downstream, resistance can be a rational response to the way the solution distributes effort.
This is why I think adoption belongs in the architecture. We need to design how information enters the environment, how people collaborate around it, and how the result returns to their work. A training program cannot compensate indefinitely for unnecessary handoffs and repeated data entry.
Building a seamless product context layer
This brings me to an idea I have been developing: a seamless product context layer built around the information a specific business application needs.
The distinction from a single source of truth is important. A context layer can use authoritative information from existing systems, but its purpose is to assemble useful context for a particular task. Its scope follows the business need, rather than an ambition to establish one complete representation of product truth across the company.
The context layer provides a mechanism to capture and connect any useful subset of information from any relevant combination of systems. A BOM review, a sourcing decision, a quality investigation, and an engineering change can each require a different subset. There is no requirement to connect every system or capture every record before the first application becomes useful.
For example, a sourcing review might combine selected BOM lines with supplier quotations, inventory quantities, and a purchasing spreadsheet. An engineering change review might bring together a CAD revision, the affected product configurations, a test result, and the decision recorded in an earlier discussion. Each application assembles the context needed for its purpose.
The information can come through integrations, imports, files, or references to source records. Existing applications retain their responsibilities, while the context layer connects the selected information and captures the discussions and decisions created around it. As I explored in Who Can Replace the Big Three PLM?, collaborative context workspaces can develop around existing systems of record.
This makes the approach agile. A company can start with one business application, the people responsible for it, and the information already available in their tools. The initial scope of mapping and integration is limited to what that application needs. Additional sources, relationships, and workflows can be introduced as their value becomes clear.
It also creates a practical fit with the existing organizational structure. Engineering, purchasing, manufacturing, and suppliers can contribute the relevant information within their current responsibilities and collaborate around a shared task. The experience can then provide evidence for changes in roles or processes as the scope develops.
A focused subset still needs clear meaning. The layer must preserve which product or component a record describes, which version or configuration applies, where the information came from, and what has been reviewed or accepted. Graph relationships and semantic models can make these connections explicit for the selected scope.
By seamless, I mean that people can follow the relevant product context across their work without repeatedly reconstructing it. The adoption opportunity is to make one useful business application easier to implement within the environment the company already has.
Different vendors illustrate parts of this direction
Several vendors provide useful examples, at different levels of the architecture. These examples help make the discussion concrete. They also need to be evaluated against the same adoption requirements.
CoLab illustrates a focused workflow around existing PLM. Its PLM companion approach connects design reviews to systems such as Windchill and Teamcenter. Reviewers can comment on models and drawings, and a review summary or issue list can be attached back in PLM. Its review workflow brings contributors into a browser environment and tracks feedback, ownership, and decisions. I see this as an example of starting with a specific collaboration problem: help people review a design together while preserving a connection to the formal product record.
PTC Jetstream points toward a broader collaboration environment. In its June 2026 announcement, PTC describes Jetstream as a cloud-native environment for internal and external teams to share product information, review it, and capture traceable feedback while staying connected to PLM, ALM, and CAD. The adoption question I would ask is whether this creates an easier place for people from different functions to contribute to a decision, with clear links to the relevant source information. The announcement establishes the intended direction; the experience of operating a particular deployment still needs to be assessed.
Siemens Intelligence Center X addresses the enterprise context foundation. Siemens describes a combination of industrial ontologies, knowledge-graph capabilities, AI, and workflow orchestration using Mendix, Graph Studio, and AI Studio, designed to work with existing enterprise and operational environments. My interpretation is that this tackles a different part of the adoption problem: making information understandable across domains and connecting it to governed work. Its usefulness for a particular organization will depend on the relevant data connections, mappings, and workflows.
Autodesk Platform Services provides building blocks for connected experiences. The Manufacturing Data Model APIs provide granular access to cloud-based design information and support reading, writing, and extending it without requiring a desktop authoring application. That can give developers a foundation for task-specific applications that make design information accessible to other participants. APIs alone do not assemble the full product context or deliver a finished adoption experience; the surrounding application and its connections still need to be designed.
OpenBOM builds shared product context from multiple systems and connects it to BOM Health review. Its Product Memory platform vision focuses on connecting information captured from CAD and PDM environments, BOMs, ERP systems, spreadsheets, and supplier inputs. This shared context connects product identities, structures, revisions, and review decisions across those sources. The Capture → Review → Flow cycle describes how that context is built, enriched through review, and carried into downstream work. The BOM Review workflow provides a focused entry point: deterministic checks identify issues in part numbers, required properties, quantities, and structure, while the AI BOM Health card adds observations such as near-duplicate parts or unusually long lead times. AI observations are informational suggestions, separate from rule-validation errors. Findings can become comments and assigned tasks, keeping follow-up connected to the BOM. For adoption, the relevant idea is to use information from existing tools in one shared review and accumulate further context through the work. I would apply the same test to OpenBOM, which I co-founded: does the workflow reduce review effort, preserve reasoning, and help the people responsible for the next decision?
These offerings have different scopes. A design-review workspace, a collaboration environment, an industrial intelligence platform, a developer data service, and a BOM-review workflow cannot be treated as interchangeable products. What makes them relevant here is my interpretation of the architectural opportunity: create useful ways to work across established boundaries. None should be exempt from the practical test of whether the resulting workflow reduces effort and improves decisions.
Start with one build decision
Consider an illustrative company preparing to build twenty prototypes of a small inspection robot.
The mechanical team manages the enclosure in CAD and PDM. An electronics partner supplies the controller definition. Firmware lives in a software repository. Purchasing has stock information and supplier quotations. Some working comparisons are still in Excel.
The immediate question is straightforward: can we build these twenty units using the engineering definition the team has accepted?
A focused workspace could assemble the applicable BOM, selected design states, drawing and derivative references, controller and firmware references, supplier information, and available quantities. It could identify missing evidence and direct each issue to the person responsible for resolving it.
Now purchasing reports that the selected controller is unavailable and proposes an alternative.
That proposal creates an engineering question. Does the alternative fit the enclosure? Does it require a harness change? Which firmware has been tested with it? Is the quoted lead time compatible with the prototype schedule?
The shared context gives each contributor a way to review the proposal against the same product and intended build. Mechanical engineering can contribute an assessment from its design environment. The electronics partner can supply the relevant board state. Purchasing can attach the applicable quotation. The team can preserve its decision and the evidence supporting it.
The accepted result can then follow the agreed revision and publication process. A new source version alone does not authorize a purchasing change or establish a compatible product configuration.
This workflow still needs ownership and review. But its initial organizational request is concrete: bring the people responsible for this build together around the information needed to decide. The company can evaluate the benefit before expanding the approach to other products and processes.
Context can accumulate as work happens
An engineering frontend provides one practical starting point for this approach. I use the term to describe a working environment that connects design contributions with Items, BOMs, revisions, and the engineering definition people are preparing for downstream use. Other starting points include design review, a sourcing decision, or a quality investigation. The appropriate entry point depends on the company’s immediate problem and existing environment.
The context can become richer as people work. A review captures why a component was accepted. A supplier discussion explains a sourcing restriction. A test result establishes the evidence behind a configuration decision.
This is the direction I call Product Memory: preserving connected product information together with the decisions, reasoning, and history needed to understand it later.
The context layer also needs to support familiar files. A supplier may continue sending a spreadsheet, PDF, or STEP file. The workspace should help establish what that contribution refers to, which state it represents, and how it participates in the current task. The exchange method can evolve as collaboration develops.
There is real implementation work here. Someone must resolve identities, establish access, map relevant information, and maintain connections. The context layer should be judged by whether it reduces the total effort of coordination, including that maintenance burden. My own context-layer proposal needs to pass this test just as much as any existing PLM architecture.
As I discussed in my analysis of the boundary between record and context layers, this boundary requires care. The context workspace may hold new review notes and decisions of its own. Its authority over those records must be explicit, alongside the authority of connected systems over theirs.
AI makes this approach more useful
AI offers ways to reduce the effort of assembling and using context. An assistant can help extract information from a supplier package, prepare a comparison, identify missing inputs, or summarize the questions requiring review.
Its usefulness depends on the product situation it can understand. In How a Correct AI Answer Can Still Be the Wrong Product Decision, I described how a technically plausible recommendation can overlook the applicable configuration, supplier restrictions, or earlier qualification evidence.
For the prototype build, a useful assistant should explain which product state it evaluated, identify the evidence behind its findings, and show unresolved questions. That gives people a reviewable starting point.
The same principle applies to adoption. We should evaluate whether the assistant saves effort in a defined workflow and helps users reach a better decision. A compelling demonstration is only the beginning of that evaluation.
What is my conclusion?
Jos is right to bring organizational structures and incentives into the PLM conversation. Leadership must address conflicting priorities and establish responsibilities across functions. His clarification that organizational change and software can develop together provides a useful starting point.
But the historical architecture of PLM software also belongs in this discussion. In Rethinking Monolithic PLM Architecture – Exploring What Comes Next, I argued that the ambition to build unified platforms around a single source of truth introduced its own adoption complexity.
The concern is how tightly the data model, lifecycle processes, integrations, and customizations depend on one another. When a focused improvement requires broad alignment or extensive changes across that environment, the software architecture expands the implementation burden. A company can find itself undertaking a much larger transformation than the immediate business application requires.
That leaves an important question: how much organizational change serves the company’s business goals, and how much is required to accommodate the assumptions and dependencies of the chosen software?
We should examine both. Some transformation reflects a necessary change in how the business operates. Some implementation effort may come from architectural constraints that deserve to be redesigned. Describing the difficulty as organizational does not tell us which is which.
A task-focused context layer offers a direction worth testing. It can capture the useful subset of information from the combination of systems a particular application needs, connect that information with its meaning and source context, and support a shared decision within existing responsibilities. The initial scope can remain focused while the organization learns where broader changes would create value.
That is the connection I want to make between architecture and transformation: create useful collaboration sooner, preserve what the team learns, and let that evidence inform the next change. The context layer must demonstrate that it reduces the total effort of adoption, including its own integration and maintenance costs.
Conway’s Law helps us understand the constraints. Good architecture should help people work through them.
Just my thoughts…
Best, Oleg
Disclaimer: I am the co-founder and CEO of OpenBOM, Collaborative Workspace Platform for PDM, PLM, Inventory, & Procurement. My opinion can be unintentionally biased.
