This article asiginally published on LinkedIn on July 14 2026
Every software-defined program has a date that governs everything.
Inside the company, it is known. It is on the plan. It is the first physical build where the software has to enable the product — not in theory, not in simulation, not in a slideware maturity model, but in the real system.
That date is not the mystery. The mystery is why organizations so often underestimate what has to be true before they get there.
The interfaces have to be stable enough to use. The signals have to mean the same thing across teams. The software has to be integrated far enough to support the physical product. The validation environment has to be ready enough to separate a software issue from a system issue.
And yet, too often, the moment arrives with a kind of grim surprise.
It is the moment when the hardware is standing at the altar, and the software does not arrive ready.
Organizations keep arriving at that moment by surprise, and they keep being surprised for the same reasons.
This is an attempt to name those reasons.
The hardest parts of the software-defined transition are not technical but organizational. Platforms, operating systems, middleware, pipelines, cybersecurity, over-the-air updates: these are hard and expensive, but they are visible. They can be put on a roadmap and assigned to a workstream. But “organizational” is where most of these discussions stop, and it is too comfortable a place to stop.
The harder mass sits below the roadmap.
It sounds like something you cannot build, only feel your way toward over years. I would claim the opposite. The hard part is concrete. It is nameable. And it is buildable.
Software-defined programs do not collapse back into big bang because teams lack ambition. They collapse because the organization never built the operating system for integration: common tools, common rhythms, common definitions of done, and transparent systems-level ownership.
That is the real transition.
This is especially visible in the mechatronic supply base.
Component makers are connecting their products, or enabling them to be connected. Propulsion makers are expanding along the driveline, covering the path from propulsion output all the way to the wheels. Companies that historically delivered mechanically integrated components are now expected to deliver software-enabled systems.
This is not only a supplier problem. The same pattern exists at OEMs. But it may be even more exposed in the supply base, because many of these companies built their engineering strength around mechanical integration. They know how to converge parts, drawings, materials, tolerances, suppliers, and manufacturing processes into a physical product.
They have not always built the same discipline around software.
The whole argument that follows lives inside that gap.
I have seen this many times. A company develops and produces a product that was, at first, all mechanical. Over time it incorporates electronics, then software. The domain teams that grew up around that software did not follow the same approaches their mechanical equivalents did. They developed organically.
They used different version control systems. If they used model-based design and code generation, they used different tools. They used different issue tracking tools, different branching strategies, different release definitions, and different ways of proving that something was done.
That almost never happened in the same way on the mechanical side.
Over time, the mechanical side converged around a small number of common systems and disciplines. Common CAD. Common PLM. Common BOM discipline. Common change control. Common release discipline. Requirements and validation were not perfect, but they had a home.
The software world never had that moment.
Even where the “same” tools were used, they were often at different release versions, disconnected from one another, and living across different on-prem servers or different SaaS tenants. The endless debate about on-prem versus SaaS security often became a proxy for something deeper: the absence of a shared engineering operating model.
This is the submerged mass. Not “culture” in the abstract. A specific, un-converged set of tools, pipelines, practices, and habits that grew up around them.
The transition from one software ecosystem to another looks, at first glance, like it should not be hard. You are swapping one tool for another. At the first level, it appears that way.
Then you look closer.
There is almost always custom tooling and custom scripting wrapped around each toolchain to make it usable in an efficient manner. Over the years this accretes into many distinct pipelines, each one tuned to the team that built it, most of it undocumented.
Migration is not swapping a tool. It is unwinding years of automation that everyone depends on and few people fully understand.
That is hard. But it is at least visible once you decide to look.
The harder part is what those toolchains taught the teams to believe.
The other overlay is the way these teams actually work. How they plan their work. How they develop their software. When “code complete” means something. When an interface can be consumed by another team. When a signal is stable enough to be relied on.
This part is often harder than the tooling.
A discussion about why one team runs on an 8-week PI and another on a 12-week PI did not matter as much in a big-bang integration world. The teams could work locally, integrate late, and resolve many of the conflicts at the end.
That changes when the goal is to integrate slice by slice.
The mismatch is rarely about the number of weeks. It is about what the cadence implies. A team on a longer rhythm has organized its planning, dependencies, test points, and definition of “done” around that rhythm. The team next to it, running on a shorter rhythm, has done the same.
When you ask them to integrate against each other, you are not asking them to agree on a calendar. You are asking them to agree on when something is finished enough to be relied upon by someone else.
That is a much deeper alignment than it first appears.
There is also a quieter failure mode worth naming. An organization adopts the language and tooling of working in sync, but the underlying behavior does not change. Teams continue to optimize locally. They show green in their own dashboards. Then they reasonably petition to return to longer release cycles because shorter cycles feel inefficient to them.
Coaching that was meant to change how teams work gets redirected into inspecting what they have produced. The mechanics are followed and the intent is quietly lost.
The cadence chart looks aligned. The actual handoffs are not.
This is where the failure becomes visible.
One team delivers version one of a signal. Another team has already implemented against version five. A third team still believes version three is the stable definition because that was the last version visible in its planning cycle.
Each team may be able to explain its position. Each team may even be “green” in its own system.
The product does not care.
The product only sees whether the signal is defined, implemented, integrated, tested, and ready to support the system behavior that depends on it. Local progress is not the same as system progress. Local green is not system green.
This is one of the most difficult lessons in software-defined product development. Integration does not happen because every team is working hard. It happens because the organization has made the dependencies explicit enough, early enough, that the work can converge before the physical product needs it.
It helps to remember why big bang integration was survivable for so long.
For many years, the underlying architecture changed incrementally. More ECUs, more signals, more features, more variants — but still largely added to a system pattern the industry already understood.
A vehicle that once had on the order of a hundred messages on its buses grew to ten thousand and more. That growth was difficult, and I apologize to every system integration engineer for using the word “survivable.” But it was incremental. You were usually adding to something that already worked.
Incremental growth is forgiving.
A software-defined transition is not the same thing. It is not simply more software, more signals, or more compute. It is an architectural discontinuity. It asks the organization to change the vehicle architecture, the network topology, the software architecture, the release model, the validation model, and the ownership model at the same time.
That is a very different problem.
There is an objection worth meeting head-on.
The destination of a software-defined architecture is precisely to decouple software release from the hardware calendar. In the end state, the vehicle or product becomes a platform. Software can be released independently. Capability can evolve after launch. Hardware and software no longer have to meet only at one large integration event.
In the end state, yes.
But during the transition, the hardware calendar still rules.
The software-defined vehicle — or better, the software-defined system — is both an opportunity and a mandate.
It is an opportunity to modernize the way the product is architected, not only from a hardware perspective, but also in network topology, software architecture, interfaces, data flows, validation, and lifecycle management. It is a chance to redefine ten thousand and more messages into a more modern, organized, flexible architecture.
The opportunity is real.
The problem is where it lands.
It lands on organizations still carrying the un-converged tooling and unaligned rhythms described above. Then it asks them to do, all at once and under a deadline, the convergence they avoided for two decades.
That is why the transition collapses.
Not because software-defined is the wrong ambition. Not because teams do not understand the need. Not because engineers are unwilling.
It collapses because the organization tries to change the architecture of the product without first changing the architecture of the work.
So what does an organization do when it never drove its teams to common tools, never drove them to common rhythms, and never managed in the software world what it has managed in the mechanical world for decades?
It struggles.
Then it compensates.
Teams keep working locally. Integration gets deferred. Interfaces remain unstable. Signals are interpreted differently by different teams. Algorithms are implemented against assumptions that are no longer true. Test assets arrive late because the system behavior they are supposed to validate has not stabilized.
The slips compound.
At first, the issue looks like a planning problem. Then it looks like a tooling problem. Then it looks like a supplier problem. Then it looks like a validation problem. Eventually, it becomes a launch problem.
And in the end, it leads again to a big-bang integration point, forced into alignment with the moment the physical product has to come together for its first level of physical testing, enabled by the very software the teams are still struggling to have ready.
The loop closes on itself.
The organization adopts a continuous, slice-by-slice ambition and is quietly dragged back to the single integration moment it was trying to escape.
The answers all sound easy. They are not.
A common ALM tool is not enough. A CI pipeline is not enough. An agile cadence is not enough. A platform decision is not enough.
The real question is whether the organization can see, at any point in time, which requirement, interface, signal, function, API, software component, test case, and validation result are aligned — and which are not.
That is the missing discipline: integration readiness.
Integration readiness means knowing what is ready to be consumed by another team, what is simulated, what is validated, what is implemented only partially, and what is still aspirational. It means knowing not just whether a team is busy, but whether its output can safely become someone else’s input.
That requires planning in detail. It requires breaking down the product. It requires architecting and designing subsystems and components in a way that allows teams to integrate slice by slice rather than big bang.
It also requires investment in the roles that are easiest to underfund and hardest to replace later: systems engineers at the product and system level, validation teams with enough capability and authority to influence the plan early, and a strong TPM function whose job is to create real transparency.
Transparency about when every API will be available.
Transparency about when every signal will be stable.
Transparency about when every algorithm or function will be enabled by requirements, coded, integrated, and validated.
Transparency about whether the product is actually converging.
None of that is a tool you can buy. It is work. And it has to be built before the deadline rather than discovered at it.
The organizations that have built it know where their teams are.
The ones that have not are about to find out.
If you have not built the pipelines, if you have not built the planning and integration rhythms, and above all if you have not invested in the systems engineers, validation teams, and TPM function that hold the whole thing transparent, then you already know when the hardware will be standing at the altar, waiting for software that does not arrive.
It is the day the physical product is built, and waiting, for the software.
I work with Envorso, where we help organizations in automotive and beyond address these kinds of engineering-system challenges. These views are my own.