Industrial engineering and software engineering both deal with systems that are too large to hold in one person's head. Both decompose complexity into hierarchies. Both manage dependencies between components that were designed by different teams at different times. Both require version control - a way of knowing which state of the system is authoritative at any given moment. Both produce artifacts (drawings, code) that describe a state the system should be in, not the state it currently is.
These structural parallels are not superficial. When a process engineer updates a PFD to reflect a change in the production rate requirement, she is doing something structurally identical to what a software engineer does when she updates a data flow diagram to reflect a change in throughput requirements. The vocabularies differ. The underlying operations - revise, review, approve, distribute, implement - are the same.
The reason this matters for construction technology is that the software industry has spent 30 years building sophisticated tooling for its version of these problems. Build systems, dependency graphs, continuous integration, automated testing, deployment pipelines - all of these are engineering responses to the problem of managing complex, interdependent artifacts that change over time and must remain consistent with each other.
Construction has developed its own responses to the same problems - design review processes, submittal workflows, RFI management, change control, but has not yet absorbed the degree of automation that the software world applies to equivalent processes. The gap is not conceptual; it is a matter of translation.
Once you see the structural parallels, specific mappings become precise rather than approximate:
| Factory / Construction | Software / Code | What they share |
|---|---|---|
| Process Flow Diagram (PFD) | Data flow diagram | Describes transformation of inputs to outputs through a system |
| Electrical single-line diagram | Network topology / dependency graph | Shows how nodes connect and what each depends on |
| Submittal log | Pull request queue | Artifacts awaiting review and approval before integration |
| Plan of Record (POR) | Production branch (main/master) | The authoritative state everyone builds from |
| Construction phasing | Deployment strategy with rollback | Staged activation with defined revert paths |
| As-built documentation | Production environment state | What was actually built, not what was designed |
| RFI | Issue / bug report | Question or discrepancy requiring resolution before proceeding |
| Equipment tag hierarchy | Object model / class hierarchy | Typed entities with attributes, relationships, and inheritance |
These are not analogies intended to make construction feel familiar to software engineers. They are structural equivalences that have direct implications for how project data should be modeled, stored, and queried.
This mapping is worth dwelling on because it has the most immediate practical consequence for how design management systems should be built.
In a software development workflow, a pull request represents a proposed change to the authoritative codebase. The PR includes the change itself, the context that explains why the change is being made, a review mechanism that routes the change to the right reviewers, a status that tracks where the review stands, and a merge action that integrates the approved change into the main branch.
A submittal functions identically. A vendor proposes a component or material that will be incorporated into the built work. The submittal includes the technical documentation, the specification reference it responds to, a routing mechanism that directs it to the relevant discipline leads for review, a status that tracks where the review stands, and an approval action that authorizes the vendor to proceed with fabrication or delivery.
The software world has built highly refined tooling for PR management: automatic reviewer assignment based on file ownership, status dashboards that surface stale reviews, integration with project management systems, automated checks that run before human review begins. The construction world has Smartsheet.
The point is not that construction should use GitHub. It is that the submittal workflow has the same structure as the PR workflow, and the automation that the software industry has developed for PR management could be adapted, not metaphorically, but architecturally - to submittal management. The data model is the same: a proposed artifact, a routing path, a set of reviewers, a status, an approval action, and a record of what changed at each step.
On a manufacturing program, the Plan of Record is the authoritative description of what the facility is supposed to be. It is the state against which all work is planned, all procurement is committed, and all construction is sequenced. When the POR changes, everything built on it must be re-evaluated.
Software engineers manage this problem with a production branch - a named, controlled branch in version control that represents the authoritative state of the software. Changes are not made directly to production; they are proposed in branches, reviewed, and merged. The branch history provides a complete audit trail of what changed and when.
Capital programs manage POR changes through a combination of formal change control processes, document revision histories, and informal communication. The audit trail is incomplete. The propagation of changes to dependent artifacts (procurement orders, construction work packages, inspection plans) is manual. The relationship between a change to the POR and all the downstream consequences is not tracked in any single system.
A data model that treats the POR as a versioned object - with explicit relationships to every procurement record, schedule activity, and design document that depends on it - would allow those downstream consequences to be computed, not discovered manually. When the POR changes, the system knows what to re-evaluate. This is not speculative; it is how well-designed software dependency managers work today.
Every piece of major equipment on a capital program has a tag - a unique identifier that links the physical asset to its specification, its procurement record, its installation drawings, its inspection tests, and its commissioning procedures. The tag hierarchy typically follows a system-equipment-component structure that mirrors how software engineers structure class hierarchies: a type that defines common attributes, instances that inherit those attributes, and specific overrides where individual components differ from the type.
The difference is that software object models are stored in a database that enforces the schema and can be queried programmatically. Equipment tags on most capital programs live in multiple disconnected systems: the equipment list in a spreadsheet, the procurement record in SAP, the drawing references in Aconex, the inspection records in Procore. The tag is the common key, but there is no system that joins the records and presents the complete picture of a specific piece of equipment - its specification, its procurement status, its installation status, its outstanding RFIs, its commissioning dependencies.
Building that system is a database design problem, not a novel research problem. The schema is not complex: equipment entities, document entities, procurement entities, schedule entities, inspection entities, and typed relationships between them. The challenge is the integration work - connecting systems that were not designed to share data - and the data quality work - ensuring that the same equipment tag is used consistently across all of them.
Fast-track construction programs frequently need to build, test, and hand over portions of a facility while other portions are still under construction. This is structurally identical to a staged deployment strategy in software: activating one module while others are still in development, ensuring that the live portion can operate independently, and defining the rollback path if the activation fails.
Software deployment strategies have become sophisticated because the cost of a bad deployment is high and immediate - users notice within minutes when software breaks. The analogous sophistication in construction phasing design - explicit identification of system dependencies across phases, pre-commissioning test procedures that validate phase-by-phase readiness, contingency plans for partial activation - exists in good practice but is not systematized the way deployment pipelines are.
The interesting opportunity is in the tooling. A construction phasing tracker that models inter-phase dependencies the way a deployment pipeline models inter-service dependencies - flagging when a Phase 2 construction activity depends on a Phase 1 system that has not been accepted - would surface sequencing conflicts before they become field problems. The logic is not different from what CI/CD pipelines do for software builds.
Every factory is a system. Every system can be understood. Every understanding can be codified. And every codification creates the foundation for automation that compounds in value across every subsequent program that runs on it.
The mapping is precise in its structural logic, but it has limits worth being clear about.
Software systems are deterministic in ways that physical construction is not. When a PR is merged, the change is applied exactly as specified. When a drawing revision is issued, the as-built state depends on dozens of field conditions - material substitutions, dimensional tolerances, subcontractor interpretations - that the drawing cannot fully specify. The gap between design intent and physical reality is a feature of construction that has no direct equivalent in software.
Software version control operates in milliseconds. Construction review cycles operate in days. The tempo difference means that automation patterns designed for software workflows need to account for the slower clock speed of construction without losing the discipline that makes version control valuable.
Software systems can be rolled back - a failed deployment can be reversed by deploying the previous version. A construction mistake cannot be unbuilt without cost. The asymmetry of consequences means that the error-correction mechanisms in construction must be more conservative than those in software, even when the structural logic of the workflow is the same.
These limits are real, but they argue for careful translation, not against translation. The right response to the tempo difference is to design workflows that are disciplined about when human review is required and automated where human review adds no value. The right response to the irreversibility of construction mistakes is to invest more in upstream validation - exactly the kind of automated checking that software CI/CD pipelines perform before a human ever sees the change.
The design manager who understands both the construction workflow and the data structure behind it is the person best positioned to build the systems that make that workflow faster and more reliable. Not because she needs to write code - she probably does not, but because she can specify what the system needs to do in terms precise enough for the engineers building it to implement correctly.
Vague requirements produce vague systems. "We need better submittal tracking" produces a system that is marginally better than the Smartsheet it replaces. "We need a submittal system where each record has a typed relationship to the specification section it responds to, the work package it enables, and the schedule activity that depends on it - and where overdue reviews surface automatically to the design manager ranked by schedule impact" produces a system that actually changes how the program operates.
The translation between blueprints and code is, at its core, the practice of describing physical systems with enough precision that a digital system can reason about them. The professionals who develop fluency in both vocabularies are the ones who will build the operating layers that capital programs need, not as a technology initiative, but as operational infrastructure that makes the program faster, more accurate, and more recoverable when things go wrong.