Succeeding with feature-oriented platforms

The term Software-Defined Vehicle (SDV) is often thrown around, but what does it actually mean? Florian Rohde is one of the most sought-after consultants in this area and proposes feature-oriented platforms as a more meaningful description — when software development is decoupled from rigid hardware timelines, enabling continuous iteration and improvement.

Having worked extensively within traditional automotive companies, Rohde has seen the long development cycles, rigid architectures, and pre-defined functionality that dominate the industry. When he first moved to Silicon Valley, he experienced the opposite—a fast-paced, agile development approach with frequent pivots in priorities. Now his company iProcess helps automotive companies merge both worlds —ensuring the speed of software innovation without compromising safety and reliability.

What are the unique challenges in automotive software development?

Traditional automakers are still stuck in the mindset of trying to have everything ready by SOP (Start of Production). The problem is that they lack the processes and culture for continuous development and improvement. This isn’t primarily a technical issue—it’s a cultural challenge. 

What really matters in continuous feature development is to enable developers to use the car as a platform for development and innovation. As it is now, development engineers work on predefined hardware and functionality locked in years ahead.

In a feature-oriented platform, developers should be able to continuously iterate and improve existing products—not just wait for the next vehicle generation. But the industry hasn’t figured out how to structure development around this. Right now, nobody owns a feature from idea to customer delivery. Decision-making is fragmented between release managers, service centers, and mechanically-focused project managers. In contrast, Tesla has sprint PMs— who act as gatekeepers to decide which features make it into production and ensure continuous software improvements post-launch. That mindset shift is critical.

At iProcess, we offer structured assessments to evaluate where companies stand—from test execution in labs down to the technical and process layers. We then provide a clear roadmap with actionable steps for moving forward towards their goals.

You often say integration is the biggest hurdle in automotive software. Why?

Because writing code isn’t the bottleneck in automotive—integration is. I’d say in my experience that up to 80% of software issues are integration-related on system level in complex mechatronic systems. The problem is that testing happens in silos until it’s too late. Engineers wait weeks or even months before discovering issues, and by then, fixing them is expensive and time-consuming. In traditional automotive, Continuous Integration (CI) is missing its most important counterpart: Continuous Validation (CV). Automotive teams need to test earlier in a virtual environment, ensuring components work in larger system environments before full integration.

A lot of OEMs try to solve everything at once – testing too much, too late, and in an inefficient way. A smarter approach is to split testing into three layers:
1️⃣ Fast and precise regression tests – Quick feedback loops, ensuring baseline stability.
2️⃣ Large-scale automated testing – Regression testing to catch system-wide issues.
3️⃣ Manual validation & stress testing – Corner cases, robustness tests, and final integration.

The goal isn’t to run a week-long test for every minor change—it’s to create a smart test suite that provides quick feedback while maintaining safety and reliability.

How are the automotive toolchains affecting these challenges and hurdles?

I’d say it is typical in automotive with a ton of different solutions addressing the same problem in similar ways, but no communication between the tools. To keep engineers happy, which is key to success, my recommendation is to let people use the best tool that works for them but hold them accountable to an interface. If you are not going to build your own tools as in the example with Tesla, then ensure only to choose tools developed with API-first strategy which means that user interfaces are secondary and everything is scriptable, building on top of the API. No tool does everything, but it has to integrate with other tools without adding a lot of complexity, and it needs to integrate with both machines and humans.

Final thoughts: your key tips for succeeding with feature-oriented platforms?

The shift toward feature-oriented platforms is inevitable. Companies that succeed will be those that:

• Test earlier and integrate continuously.
• Adopt a culture of continuous improvement instead of locking everything by SOP.
• Break silos by using flexible, API-first toolchains.
• Invest in smart test suites that balance speed with safety.

In my work as a consultant, I work with various tools that support this transition. I’ve been in contact with RemotiveLabs’ since I recognized how RemotiveTopology allows teams to collaborate using their preferred tooling while still maturing their vehicle platform in one common place —which is crucial for enabling feature-oriented platforms / SDV development.