The Car Is Becoming a Software Business. Most Automakers Are Not Ready.

Software-defined vehicles require changes to architecture, validation, release management, organizational ownership, and business economics. Over-the-air updates alone are not enough.

An automaker does not become software-defined by adding screens, connected services or OTA updates. It gets there when its architecture and operating model let the vehicle change safely, predictably and economically for its whole life on the road.

That is a much harder thing to build, and most of the hard part is not code.

The OTA illusion

Shipping an update over the air is one capability. It is a delivery channel.

It does not tell you whether the software is modular, whether one domain can be released without retesting the whole car, whether validation keeps up with the release pace, or whether anyone clearly owns the outcome when an update goes wrong. A company can have OTA and still need months and a dozen sign-offs to change one function.

The question I ask is not "can you push an update?" It is "how long does it take to safely change one thing, and who decides?"

The architectural problem

Many vehicles still carry a large number of electronic control units, each with its own software, supplier and release cycle. Functions are spread across boxes that were never designed to change together.

The industry is moving toward centralized compute and zonal architectures, with software abstraction, middleware and stable APIs separating functions from the hardware underneath. Done well, that lets software evolve without rewiring the car.

There is no single right architecture. The answer depends on the vehicle lines, the legacy platforms still in production, the supplier base and how much the company is willing to own. What matters is that hardware dependencies are explicit and interfaces are stable enough that teams can move without breaking each other.

Software velocity meets automotive safety

Automotive software cannot copy consumer web release practices. A bad web release gets rolled back. A bad vehicle release can affect braking, steering or a driver's attention at speed.

Velocity still matters. It just has to be earned through the test system: continuous integration, simulation, hardware-in-the-loop testing, regression suites that run on every change, cybersecurity review, functional safety analysis and field monitoring after release. The faster you want to ship, the more of that has to be automated and trusted.

The release pace a company can sustain is set by its validation, not by its developers.

The organizational bottleneck

In many automakers, ownership of one feature is spread across vehicle programs, component engineering, suppliers, cloud teams, cybersecurity, validation and aftersales. Each has its own priorities and calendar.

When decision rights are unclear, releases slow down and accountability blurs. A defect turns into a discussion about whose part it is. A small change waits for the next program milestone.

Software-defined vehicles need software-defined ownership: a named owner for each function across its life, with authority to make release decisions and responsibility for what happens in the field.

The supplier relationship must change

The traditional model buys a component with its software sealed inside. That worked when software rarely changed after start of production.

If the vehicle is meant to evolve, the automaker and its suppliers have to agree on harder questions. Who owns the software? What are the interface contracts? Who is responsible for integration when two suppliers' functions interact? Who gets access to the data needed to find and fix problems? Who supports updates, and for how many years?

The commercial incentives matter as much as the technical ones. A supplier paid per unit has little reason to support software for a decade after the sale. Those terms have to be designed, not assumed.

ADAS exposes the real challenge

Driver assistance is where all of this meets the road. It depends on sensors, compute, vehicle hardware, software, data, validation and a safety case, all working together in conditions that keep changing: weather, lighting, road markings, a dirty camera.

Driver assistance is not autonomous driving. The driver remains responsible, and the system has to be designed around how real people actually pay attention.

An OTA update does not automatically make a system safer. A change to perception or control has to be validated against the safety case, tested across the conditions that matter and monitored after release. I wrote about the handoffs where these systems fail in Physical AI.

The economics of software-defined vehicles

The plausible upside is real: reuse of software across vehicle lines, faster fixes, lower warranty exposure when problems can be corrected in the field, and new services after the sale.

The costs are real too: development and validation of a shared platform, cloud and update infrastructure, cybersecurity response, and supporting software on vehicles for many years. Every vehicle in the field is a commitment.

It helps to separate business models that are plausible from revenue that has been demonstrated. Feature subscriptions and paid upgrades depend on customers adopting and paying for them. That has to be measured, not forecast into the plan as certain.

A practical executive scorecard

These are the questions I would bring to a review:

Question	What it tells you
How long from approved change to vehicles in the field?	Release lead time
How many defects are found after release versus before?	Defect escape rate
How much of the system is covered by automated regression tests?	Regression coverage
How many teams must coordinate for a typical change?	Cross-domain dependency
Can you see how software behaves across the fleet?	Fleet observability
How fast can you respond to a security vulnerability?	Cybersecurity response
What share of update attempts complete successfully?	Update success
Who owns each function, end to end?	Accountable ownership

None of these numbers mean much without clear definitions and a comparable baseline. Agree on how each is measured before using it to compare teams, programs or companies.

The strategic conclusion

Competitive advantage in software-defined vehicles comes from the whole software operating model: architecture, validation, ownership, supplier terms and economics. It does not come from a dashboard, a feature announcement or an OTA capability alone.

The car is becoming a software business. The companies that win will be the ones that organize like one, without forgetting that the software is still moving a two-ton machine.