Beyond PLM examines organizational and architectural barriers to PLM adoption

AI-generated summary

PLM adoption problems reflect software architecture as well as organizational structures, argues Beyond PLM author Oleg. Responding to Jos Voskuil’s discussion of Conway’s Law, he accepts that departmental incentives can impede collaboration and that PLM is a strategy supported by federated systems, not one application for every discipline. However, Conway’s Law—which links system structure to an organization’s communication structure—does not establish that existing PLM approaches are usable or that reorganization is the only remedy. Voskuil’s clarification that organizational change and software can develop together frames the article’s central question: how can architecture help companies move from existing practices toward better collaboration? The author distinguishes technical feasibility from practical adoption. A PDM–ERP integration may be possible yet difficult to implement within available budgets and skills, preserve identities and revisions, diagnose failures, or maintain as connected systems change. Similarly, requiring an ERP part number before engineering can proceed may reflect either a legitimate business requirement or software demanding production-ready information prematurely. Adoption should therefore be designed into the architecture, with useful early outcomes and benefits for contributors—not extra engineering administration whose rewards accrue only downstream. Training cannot indefinitely compensate for repeated entry and unnecessary handoffs. The proposed alternative is a task-focused “seamless product context layer,” rather than a comprehensive single source of truth. It would assemble selected information from existing authoritative systems through integrations, imports, files, or references, while those systems retain their responsibilities. A sourcing review could connect BOM lines, quotations, inventory and spreadsheets; an engineering change could connect CAD revisions, configurations, tests and previous decisions. Initial integration would cover only the task’s requirements, expanding as value becomes evident. Nevertheless, the layer must preserve identity, version, configuration, provenance and acceptance status; graph relationships and semantic models could express these connections. Several vendor examples illustrate different architectural roles, not interchangeable products or demonstrated adoption outcomes. CoLab connects browser-based design reviews with Windchill and Teamcenter, tracking feedback and ownership and returning summaries or issues to PLM. PTC describes Jetstream as a cloud-native collaboration environment linking internal and external contributors with PLM, ALM and CAD; the author cautions that deployment experience remains to be assessed. Siemens describes Intelligence Center X as combining industrial ontologies, knowledge graphs, AI and workflow orchestration through Mendix, Graph Studio and AI Studio, with usefulness dependent on mappings and connections. Autodesk Platform Services’ Manufacturing Data Model APIs enable granular access to cloud design information without desktop authoring software, but developers must still build the surrounding context and application. OpenBOM’s Product Memory vision connects CAD/PDM, BOM, ERP, spreadsheet and supplier information through a Capture → Review → Flow cycle. Its BOM Review workflow combines deterministic checks on identifiers, required properties, quantities and structure with AI BOM Health observations such as near-duplicate parts or unusually long lead times. AI suggestions remain separate from validation errors, while findings can become comments and assigned tasks. The author, who discloses being OpenBOM’s co-founder and CEO, says his company must face the same test as other approaches: reducing review effort, preserving reasoning and supporting subsequent decisions. An illustrative build of twenty inspection-robot prototypes shows the approach in practice. A workspace would connect mechanical designs, controller and firmware references, the applicable BOM, quotations and available quantities. If purchasing proposes an unavailable controller’s replacement, contributors could assess enclosure fit, harness changes, tested firmware and schedule implications against the same intended build. The decision and supporting evidence would be retained, but accepted changes would still follow revision and publication controls: a new source version alone would not authorize procurement or establish compatibility. Over time, reviews, supplier discussions and test evidence could accumulate into Product Memory, including contributions delivered as spreadsheets, PDFs or STEP files. AI could extract supplier information, compare options and identify missing inputs, but should expose the evaluated product state, evidence and unresolved questions. Plausible answers can otherwise overlook configuration or qualification constraints. The author concludes that task-focused collaboration deserves testing, not unquestioned acceptance: identity resolution, access, mappings, record authority and maintenance remain substantial responsibilities. Leadership must still address incentives, while architecture should demonstrate lower total coordination costs and let practical results guide broader transformation.