Design Software History: Concurrent Product Development and the Rise of PLM

Industrial Pressure Before the Software

Sequential Development Reached Its Practical Limit

The need for concurrent product development software did not begin with software vendors; it began on factory floors, in aircraft programs, in automotive platform planning rooms, and inside defense organizations that were discovering the limits of sequential engineering. In the postwar decades, products in aerospace, automotive, defense, and heavy machinery became too large, too interconnected, and too expensive to develop through isolated drawings passed from one department to another. A jet aircraft, a missile system, a turbine, a tractor, or a new automobile platform could involve thousands or millions of parts, each shaped by aerodynamics, structural loading, manufacturability, maintenance access, tooling limits, supplier capacity, and regulatory requirements. When design engineers worked for months before manufacturing engineers, tooling planners, procurement specialists, and service teams saw the emerging product in detail, late discoveries became financially destructive. A bracket that interfered with an access panel, a casting that required unrealistic tooling, or a fastener pattern that complicated assembly could force redesigns long after commitments had been made. Physical prototypes became bottlenecks because they were expensive, slow to build, and often revealed integration problems only after the organization had already invested heavily in the wrong assumptions.

The Cost of the Over-the-Wall Model

The classic “over-the-wall” model of engineering looked orderly on paper: concept design first, detailed design next, then analysis, drafting, tooling, manufacturing planning, purchasing, production, and service documentation. In practice, this model created a long chain of delayed feedback. General Motors, Ford, Boeing, Lockheed, McDonnell Douglas, and other large manufacturers all faced the same structural problem: departments optimized their own work while discovering too late that the total product system did not fit together economically. Manufacturing engineers might receive drawings after part geometry had hardened, only to find that the part required excessive machining setups or could not be assembled in the planned sequence. Procurement teams might discover that a specified material or vendor process threatened schedule risk. Service engineers might learn that a component could not be removed without disassembling half a subsystem. The issue was not simply poor communication; it was that drawings were weak carriers of evolving product intent. A drawing represented geometry and annotations, but it did not reliably expose dependencies, alternatives, decisions, responsibilities, and revision histories across the organization.

Postwar Complexity and the Rise of Systems Thinking

Postwar aerospace and defense programs intensified the demand for coordinated engineering because they forced organizations to manage products as systems rather than collections of parts. Aircraft manufacturers such as Boeing, Lockheed, and McDonnell Douglas operated in environments where aerodynamic surfaces, hydraulic routing, avionics packaging, structural frames, maintainability, and manufacturing tooling were tightly coupled. Defense programs sponsored by government agencies and military customers demanded traceability, configuration control, supplier coordination, and documentation discipline long before commercial software had elegant answers. Systems engineering thinking emerged partly because conventional drafting workflows could not capture the full logic of requirements, interfaces, verification, and change propagation. In early mainframe and minicomputer-based design environments, companies could create digital geometry, but they quickly discovered that the harder challenge was managing shared engineering data. A file might contain a drawing, a surface definition, or a part model, yet the organization needed to know who owned it, which version was approved, which assembly used it, which tooling depended on it, and whether a proposed change would invalidate downstream work.

Automotive Pressure and the Japanese Manufacturing Challenge

Automotive competition in the 1970s and 1980s made the weakness of slow sequential development especially visible. American and European manufacturers faced intense pressure from Japanese companies, most famously Toyota, whose lean production practices, supplier integration, quality discipline, and shorter development cycles challenged long-established assumptions about how cars should be engineered and built. Toyota’s influence was not merely a matter of factory efficiency; it demonstrated that development speed and manufacturability were strategic weapons. Automotive companies such as Ford, General Motors, Chrysler, Renault, and others had to reduce platform development time while coordinating body structures, powertrains, interiors, electrical systems, safety requirements, manufacturing lines, tooling, and supplier contributions. The old habit of freezing design before involving downstream teams became untenable. Engineering, manufacturing, procurement, quality, and service had to begin working in parallel, even when the product definition was still evolving. That shift created a clear need for shared product data, controlled revisions, early visualization, digital mockup, and workflow systems that could manage uncertainty without allowing engineering chaos.

• Aerospace complexity made interface control and configuration management central engineering concerns.
• Automotive platform competition pressured companies to reduce development cycles and reuse product architectures intelligently.
• Lean manufacturing influence encouraged earlier manufacturing involvement and faster feedback loops.
• Defense procurement discipline reinforced the need for traceability, approval control, and formal change management.

From Drawings to Shared Product Data

Geometry Was Necessary but Not Sufficient

Concurrent product development depended on much more than digital geometry. CAD was essential because it allowed engineers to create precise drawings, surfaces, solids, and assemblies, but a product organization needed a richer information structure around that geometry. A part model had to be connected to a part number, a material specification, a bill of materials, a revision state, a release status, an owner, an approval history, a supplier, a manufacturing plan, and often a set of requirements or test results. Without those connections, CAD files could become another form of isolated documentation rather than a foundation for parallel work. A designer might modify a housing, an analyst might run a finite element model on an older version, a tooling engineer might prepare fixtures based on an unapproved file, and procurement might request quotes for a part that had already changed. The technical foundation of concurrent development was therefore product data management, not only computer-aided drafting. The central question changed from “Can the software draw or model this part?” to “Can the organization know what this part means, where it is used, and who is affected when it changes?”

The Shift from 2D Databases to Assemblies and Features

Early CAD systems often began as 2D drafting databases that accelerated drawing production, but concurrent engineering required more expressive digital product models. As 3D modeling matured, assembly modeling made dependencies between parts explicit: designers could see interferences, mating conditions, spatial envelopes, and packaging conflicts before building physical prototypes. Feature-based modeling then added another layer by capturing aspects of design intent. In systems such as PTC’s Pro/ENGINEER, introduced by Parametric Technology Corporation under the leadership of Samuel Geisberg and others, parametric and feature-based methods allowed dimensions, constraints, holes, bosses, rounds, patterns, and relationships to drive model behavior. This mattered for concurrent development because design changes could propagate through associated geometry, drawings, and sometimes assemblies, reducing the manual redrafting burden that had previously slowed iteration. Yet feature-based modeling also created new information-management challenges. If a feature failed after a parent reference changed, or if an update altered downstream manufacturing geometry, the organization needed workflows to control who could modify what, when, and under which approval authority. Engineering change management became a software problem because the model was no longer a static depiction but a living dependency network.

PDM as the Backbone of Coordination

Product data management systems emerged to impose order on this growing web of CAD models, documents, bills of materials, and revisions. Early PDM tools introduced check-in and check-out mechanisms so that engineers did not accidentally overwrite one another’s work. They maintained version histories, controlled access permissions, routed approvals, and linked product structures to files and metadata. Sherpa Corporation was one of the important early PDM vendors, helping establish the idea that engineering information required an enterprise-grade management layer. Metaphase, associated with SDRC and later EDS, became another influential platform in the evolution from engineering data management toward broader product lifecycle management. MatrixOne and Agile Software also contributed to the early PLM-related landscape, especially as manufacturers wanted stronger control over bills of materials, supplier collaboration, and change processes. These systems were not glamorous in the same way as solid modeling, but they addressed the organizational friction that made concurrent work possible or impossible. Check-in/check-out, workflow routing, access control, and revision discipline were the quiet mechanisms that allowed parallel development to occur without destroying trust in the data.

Neutral Formats and the Problem of Mixed Systems

Concurrent development also required moving product information across different software environments. Large manufacturers rarely used a single tool in every department or supplier organization. IBM and Dassault Systèmes developed CATIA in a world where aerospace and automotive companies needed advanced surface modeling, 3D definition, and eventually digital mockup. SDRC’s I-DEAS developed strong capabilities in design, analysis, and data management. McDonnell Douglas Automation’s Unigraphics, later associated with EDS and ultimately Siemens, became a major force in mechanical CAD/CAM and production engineering. These systems were powerful, but they also created islands of proprietary data. Neutral exchange formats such as IGES, first developed through efforts involving the U.S. National Bureau of Standards, Boeing, General Electric, and other industrial participants, helped move wireframe, surface, and drawing information between systems. Later, STEP, formalized as ISO 10303, pursued a more ambitious model for product data representation. Neutral formats could not eliminate all translation problems, especially when parametric features and system-specific modeling histories were involved, but they were essential to concurrent development because suppliers, analysts, tooling teams, and customers needed controlled ways to consume and reuse product data without rebuilding everything manually.

• CAD models described geometry, topology, assemblies, and increasingly design constraints.
• Bills of materials connected engineering structures to procurement, planning, and production.
• Revision histories identified approved states and prevented obsolete definitions from driving downstream work.
• Manufacturing process plans linked design intent to tooling, operations, fixtures, and inspection strategies.
• Simulation and test data helped teams validate evolving designs before physical prototypes were available.

Concurrent Engineering Becomes a Software Category

From Methodology to Market Demand

By the 1980s, “concurrent engineering” had become a recognized management and engineering methodology rather than merely an informal desire for better coordination. It was closely connected to design for manufacturing, design for assembly, integrated product teams, quality engineering, and the broader movement toward compressing product development cycles. The phrase gained institutional weight in industry, academia, and government-sponsored research because companies could see that serial handoffs were increasing cost and schedule risk. Software vendors recognized that CAD alone could not solve coordination problems. A beautiful surface model or a precise solid model was valuable, but it did not automatically tell manufacturing planners that a part had changed, notify analysts that a load path had been revised, or prevent a supplier from using an obsolete drawing. The software category that emerged combined CAD, PDM, configuration management, document control, visualization, workflow automation, and enterprise integration. It was never simply “collaboration software” in the modern messaging sense. It was a deeper attempt to represent the engineering process itself as controlled, traceable, and concurrent.

CAD, CAM, CAE, and Digital Mockup Converge

The most important workflow change was the reuse of digital product data across disciplines. CAD data increasingly flowed into CAM systems for toolpath generation, reducing the gap between design geometry and manufacturing operations. CAD models were reused for finite element analysis in systems from companies such as SDRC, MSC Software, ANSYS, and others, allowing structural, thermal, vibration, and durability questions to be investigated before hardware was built. Digital mockup tools allowed engineers to detect interference, reach, clearance, service access, and packaging conflicts. IBM and Dassault Systèmes’ CATIA became especially significant in aerospace and automotive environments because it supported sophisticated geometry and large digital product definitions. Boeing’s 777 program became famous for using CATIA to support a digital product definition and reduce reliance on traditional physical mockups. Automotive companies including Chrysler, Ford, General Motors, and Renault adopted digital mockup practices to coordinate body, chassis, interior, powertrain, and manufacturing constraints earlier. The historical significance was not simply that models became three-dimensional; it was that the model became a common object around which multiple disciplines could work before the product physically existed.

Authority, Trust, and the Digital Product Definition

The cultural challenge was at least as difficult as the technical one. Engineers, manufacturing planners, suppliers, managers, and inspectors had to learn to trust digital models as authoritative. In drawing-centered organizations, the released drawing had legal, procedural, and cultural authority. Moving toward model-based product definition required changing approval workflows, inspection practices, supplier contracts, and internal habits. A digital mockup could reveal a clash, but the organization had to decide whether that discovery was actionable, who had authority to change the affected parts, and how the change would be communicated. Suppliers needed controlled access to evolving design data, but unrestricted access could expose sensitive information or create confusion about which versions were approved. This is why the phrase single source of truth became so influential and so difficult. It expressed a legitimate technical goal: one authoritative product structure, one controlled revision state, one reliable definition of what was being designed and built. But it also exposed an organizational struggle because different departments often had different definitions of truth: engineering truth, manufacturing truth, procurement truth, as-built truth, and service truth.

Major Industrial Environments and the Supplier Problem

Aerospace and defense programs intensified the need for controlled shared data because a single product could involve thousands of engineers and suppliers distributed across multiple organizations. Boeing, Lockheed, McDonnell Douglas, Northrop, and defense contractors working under strict customer requirements needed configuration management that could survive long development timelines and complex change authority. Automotive companies faced a similar but faster-moving problem: suppliers designed and manufactured major subsystems, yet the vehicle manufacturer had to maintain control over package space, safety targets, manufacturing sequences, cost objectives, and platform reuse. Concurrent product development software had to support internal collaboration and external visibility without losing control. This drove interest in permissions, vaulting, released versus work-in-process states, formal engineering change orders, and structured bills of materials. Systems such as CATIA, I-DEAS, Unigraphics, Pro/ENGINEER, Sherpa, Metaphase, MatrixOne, Agile, and later Windchill reflected different parts of this broader need. The vendors competed on modeling capability, data management, integration, performance, and enterprise reach, but the industrial demand underneath was consistent: organizations needed software that could coordinate many people working on interdependent definitions of a product.

• Design for manufacturing brought production constraints into engineering decisions earlier.
• Design for assembly encouraged part reduction, simplified fastening, and improved assembly sequence planning.
• Integrated product teams replaced isolated departmental review with cross-functional responsibility.
• Digital mockup reduced dependence on late physical discovery by exposing spatial and interface problems earlier.
• Configuration management protected complex programs from uncontrolled change and version confusion.

The Vendors That Defined the Infrastructure

IBM, Dassault Systèmes, and CATIA’s Enterprise Role

CATIA’s history is central to concurrent product development because it demonstrated how advanced geometry software could become part of a larger enterprise coordination strategy. Dassault Systèmes originated from Dassault Aviation’s internal need for sophisticated 3D design tools, and its partnership with IBM gave CATIA global industrial reach. Aerospace and automotive companies valued CATIA not only for surfaces and 3D modeling, but for its ability to support large assemblies and digital product definition in environments where shape, structure, packaging, and manufacturing had to be coordinated. CATIA’s evolution showed that high-end CAD was becoming inseparable from data management, visualization, and process control. IBM’s role mattered because enterprise computing relationships, mainframe and workstation infrastructure, and large-account sales channels were crucial in the early adoption of such systems. In large manufacturers, software decisions were never just about an individual engineer’s productivity; they affected supplier networks, data standards, training programs, release procedures, and long-term archival obligations. CATIA helped normalize the idea that a digital product model could be a central industrial asset rather than a drafting convenience.

SDRC, I-DEAS, Metaphase, and the Analysis Connection

SDRC, founded in 1967 by engineers associated with the University of Cincinnati environment, became especially important because it linked mechanical design, simulation, and data management ambitions. I-DEAS was not merely a CAD system; it had strong associations with finite element analysis, mechanical engineering workflows, and integrated product development. This mattered historically because concurrent engineering depended on analysis feedback arriving before designs were frozen. If simulation remained a disconnected specialist activity performed after drafting, it could not significantly shorten product cycles. By connecting design models with analysis preparation and engineering databases, systems such as I-DEAS reflected a broader industry realization: engineering computation had to become part of the design loop. Metaphase, which became associated with SDRC and later EDS, represented another step in turning product data management into an enterprise concern. It supported the management of parts, documents, product structures, and changes across organizations that required more than file folders and naming conventions. When EDS acquired SDRC and UGS, and later when Siemens acquired UGS, the historical thread continued into modern Siemens Teamcenter, one of the major PLM platforms descended from these PDM and enterprise data-management efforts.

Unigraphics, McDonnell Douglas Automation, and Manufacturing Integration

Unigraphics emerged from an environment deeply connected to aerospace and production engineering. McDonnell Douglas Automation helped develop and commercialize the system, and its later movement through EDS and UGS placed it at the center of CAD/CAM and PLM history. Unigraphics was significant because concurrent product development required manufacturing knowledge to be linked to design definition. A model that could shape a part but not support tooling, machining, or production planning left a major gap in the concurrent vision. CAD/CAM integration allowed manufacturing teams to begin planning earlier and to reuse geometry instead of reconstructing it from drawings. This helped reduce interpretation errors and supported a more continuous chain from design to toolpath to inspection. The manufacturing connection also exposed the need for rigorous version management. If a CAM programmer created toolpaths from one version of a model while design engineering continued to modify the part, the company needed software-mediated checks to prevent expensive mistakes. Unigraphics’ history therefore illustrates a central point: concurrent development software grew from the practical need to connect design decisions with the physical realities of making things.

PTC, Pro/ENGINEER, Windchill, and Parametric Change

PTC changed the competitive landscape when Pro/ENGINEER made parametric, feature-based solid modeling a central commercial force in mechanical design. Samuel Geisberg’s vision of associative, constraint-driven modeling appealed to companies that wanted faster iteration and more consistent updates across parts, assemblies, and drawings. In the context of concurrent engineering, parametric modeling was powerful because it allowed design alternatives to be explored quickly and related documentation to update more automatically. But this same power made controlled data management more urgent. When a dimension, feature, or assembly constraint could alter many downstream artifacts, organizations needed disciplined release procedures and change workflows. PTC’s Windchill, introduced later after PTC acquired Windchill Technology, addressed the web-based and enterprise data-management side of this problem. It represented the movement from CAD-centered productivity toward PLM-centered process coordination. Windchill helped establish that product structures, change objects, documents, and lifecycle states could be managed through networked systems rather than local file practices. PTC’s trajectory from Pro/ENGINEER to Windchill demonstrates how solid modeling innovation and enterprise process control became intertwined in the larger history of concurrent product development.

• Sherpa Corporation helped define early expectations for engineering document and product data management.
• Metaphase advanced enterprise-scale PDM concepts that later influenced PLM architectures.
• MatrixOne helped popularize collaborative product development and enterprise product information control.
• Agile Software became important in managing product records, change processes, and supply-chain-oriented product data.
• Windchill demonstrated the strategic move toward web-enabled lifecycle management around CAD and product structures.

Why the Single Source of Truth Was So Difficult

Engineering Truth Was Not One Simple Object

The phrase “single source of truth” sounds straightforward, but in product development it concealed a profound technical and organizational problem. A product is not only one geometry model or one bill of materials. Engineering may define an as-designed structure, manufacturing may manage an as-planned structure, production may record an as-built structure, and service may maintain an as-maintained structure over decades of operation. Aerospace programs, automotive platforms, industrial machines, and defense systems all require these views to relate to one another without becoming identical. A design engineer may think in terms of part function and spatial constraints, while a manufacturing planner thinks in operations, work centers, tooling, and assembly order. Procurement thinks in suppliers, alternates, lead times, and costed items. Service organizations think in replaceable units, manuals, diagnostics, and field configurations. Concurrent product development software had to respect these differences while preventing uncontrolled divergence. The hard problem was not only storing a CAD file; it was representing product structure in a way that multiple disciplines could use without losing traceability back to authoritative decisions.

Workflow Automation Became a Form of Engineering Memory

Engineering workflow systems became essential because change itself had to be documented as part of the product definition. A proposed change might originate from a failed analysis result, a manufacturing issue, a supplier constraint, a cost reduction effort, or a quality concern. The organization needed to capture the reason for the change, the affected parts and assemblies, the required approvals, the implementation date, and the downstream consequences. Workflow routing, electronic signatures, access permissions, and lifecycle states turned software into a form of engineering memory. Before these systems matured, companies often relied on manual forms, drawing stamps, vault clerks, and departmental procedures. Those methods could work at small scale, but they strained under distributed engineering teams and global supplier networks. PDM and PLM systems did not eliminate bureaucracy; in many organizations, they made bureaucracy more visible and enforceable. Yet that visibility was necessary because concurrent work means multiple activities proceed before every question is fully settled. Without controlled workflows, parallelism becomes disorder. With controlled workflows, parallelism becomes a managed engineering method.

Visualization Helped People Believe the Data

Product visualization played a major role in making concurrent development practical because many participants did not need full CAD authoring tools but did need to understand the evolving product. Lightweight visualization, digital mockup review, sectioning, interference checking, measurement, markup, and assembly navigation allowed manufacturing planners, managers, suppliers, service engineers, and analysts to participate earlier without editing the master model. This was a major cultural bridge. When non-CAD specialists could see the product in three dimensions, review clearances, identify assembly concerns, and comment on design alternatives, the digital model became a shared workplace rather than a designer’s private artifact. Systems from major CAD and PLM vendors, along with specialized visualization technologies, helped widen access to product data while maintaining control over authoring authority. Visualization also reduced the dependence on physical prototypes as the first moment of cross-functional understanding. A physical prototype still mattered for validation, ergonomics, testing, and manufacturing learning, but it was no longer the only practical way for different teams to discover whether a product could be assembled, serviced, packaged, or inspected.

From Concurrent Engineering to PLM and the Digital Thread

The Historical Continuity Is Clear

The central argument of concurrent product development history is clear: complex products could no longer be engineered through isolated drawings, disconnected departments, and late-stage handoffs. The software that emerged in response was not a single invention but a layered infrastructure built from CAD, assembly modeling, feature-based design, CAM, CAE, digital mockup, PDM, configuration management, workflow automation, visualization, and enterprise integration. PLM systems inherited the ambitions of concurrent engineering and expanded them across the lifecycle, from early requirements through engineering, manufacturing, procurement, production, maintenance, and retirement. Modern platforms such as Siemens Teamcenter, Dassault Systèmes ENOVIA, PTC Windchill, and other PLM systems continue to address the same historical challenge: how to keep product knowledge coherent while many people change it, analyze it, manufacture it, and support it. The terminology has changed, but the underlying project remains recognizable. Shared product structures, revision-controlled design data, and integrated engineering feedback are direct descendants of the concurrent engineering movement.

Cloud CAD Continues the Same Project

Cloud CAD and browser-based collaboration did not replace the historical problem; they made its continuation more visible. Systems such as Onshape, founded by former SolidWorks leaders including Jon Hirschtick and John McEleney, placed version control, branching-like concepts, database-driven CAD storage, and real-time collaboration at the center of mechanical design. Autodesk Fusion also reflects the movement toward connected design, simulation, manufacturing, and data management in a cloud-oriented environment. These modern tools differ technically from mainframe CAD, workstation CAD, and early PDM vaults, but they pursue the same goal that concurrent engineering identified decades earlier: reduce the friction between design activity and the broader product process. Browser access, centralized storage, permissions, comments, activity histories, and integrated manufacturing workflows are new expressions of old requirements. The difference is that hardware, networking, and software architecture have finally made some collaborative behaviors feel natural that once required heavy administrative systems. Even so, the difficult questions remain familiar: Which version is released? Who approved the change? Which suppliers can see it? Which manufacturing plan depends on it? Which simulation result is valid for the current configuration?

Model-Based Definition, Digital Twins, and the Digital Thread

Model-based definition, digital twins, and the digital thread are modern descendants of concurrent product development because they extend the idea of an authoritative living product model. Model-based definition attempts to place product and manufacturing information directly into the 3D model rather than treating drawings as the primary authority. Digital twins connect product definitions to operational data, simulation models, sensor feedback, and lifecycle behavior. The digital thread aims to maintain traceability across requirements, design, analysis, manufacturing, inspection, supply chain, operation, and service. These concepts are often presented as contemporary transformations, but historically they continue the same ambition that motivated PDM and concurrent engineering: make product knowledge connected, controlled, reusable, and visible across disciplines. The lasting technical legacy is not just better geometry. It is the recognition that product development is an evolving network of decisions. A hole pattern, a material choice, a tolerance, a supplier change, or a service requirement can ripple through cost, performance, schedule, tooling, compliance, and maintenance. Software has had to become capable of representing those ripples.

The Hardest Problem Was Always the Process

The history of concurrent product development shows that the hardest problem in design software was never only drawing geometry or modeling solids. Those achievements were extraordinary, especially considering the mathematical and computational foundations of splines, boundary representation, constructive solid geometry, parametric constraints, numerical simulation, and visualization. Yet the deeper industrial problem was teaching software to represent engineering work as a coordinated, evolving, multi-person process. That required the software industry to model not only shapes but responsibilities, approvals, dependencies, configurations, alternatives, and histories. It required companies to change how engineers, analysts, manufacturing planners, procurement teams, service groups, managers, and suppliers interacted with product knowledge. The modern language of PLM, digital thread, model-based enterprise, and digital twin may sound far removed from the early days of mainframe CAD and drawing vaults, but it belongs to the same historical arc. Concurrent product development software emerged because products became too interconnected for isolated intelligence. Its legacy is the continuing effort to make design software understand not just the object being designed, but the organization designing it.