For generations, automotive OEMs sought to distinguish themselves in the marketplace through the styling, quality, and performance of their cars. Another front, software development, is now a top priority. As cars have become more reliant on software to enable required systems and functions as well as to create a distinctive customer experience, conventional OEMs have struggled to keep up with development speed, quality, and cost—mainly due to their legacy setup.
Conventional OEMs are therefore urgently seeking to accelerate their software development process to remain competitive against the likes of Tesla, Nio, and BYD. Doing so successfully will require far more than simply copying the methods and processes of faster competitors. Broader car portfolios with both internal combustion engine (ICE) vehicles and electric vehicles (EVs), as well as the resulting set of legacy architectures, processes, and systems, increase complexity tremendously. Further, our research into the four phases of software development—requirements and architecture, electrical and electronic (E/E) development, feature development, and life cycle management—uncovered a range of root causes holding OEMs back.
Addressing these root causes would require OEMs to change their approaches across all four phases. This article lays out a handful of actions that can enhance visibility, coordination, and collaboration to accelerate the pace of software development specifically for conventional automotive OEMs.
Superior products through software from new entrants
Over the past decade, the automotive industry has undergone a vast array of technological advancements, particularly in the areas of electrification, connectivity, and autonomous driving, fueled by both consumer demand and regulatory pressure. Today’s cars feature a network of different electronic control units (ECUs), ranging from central to more-local controllers, which manage and monitor most of the car functions across all vehicle domains (for example, powertrain, motion, energy, infotainment, autonomous driving, and connectivity).
It has become increasingly prevalent for vehicles’ domain control units or central computers to have higher levels of E/E content (such as advanced infotainment systems and driver assistance technology), thereby enhancing luxury, safety, and performance features. In addition, the industry has seen the integration of seating, steering (steer-by-wire), and electronic systems, among others, as well as the adoption of global vehicle platforms to streamline production, innovation, and maintenance. The software supporting these ECUs can reach up to 100 million lines of code, making software development a top priority for OEMs.1
These developments have reshaped the competitive landscape. Innovative new entrants (especially those focusing on electric and autonomous vehicles, such as Tesla, Nio, and BYD) are increasingly capturing market share. Within a relatively short period of time, these entrants have reset industry standards—with an emphasis on shorter development cycles, new delivery models, and different operating models—by radically rethinking product development processes and leveraging the advantages of software-centered development and pure battery electric vehicles (BEVs). “Software speed” has become key for time to market at new entrants, which have established leading functionalities, especially in the autonomous driving and infotainment domains.
Collectively, these trends have left conventional OEMs and tier-1 suppliers drastically trailing on software development (Exhibit 1). They typically have long cycles that run 40 to 50 months from the beginning of the development project to software release. Following the requirements freeze, it may take more than 1.5 years to progress from architecture and base software development to the first integrated release, allowing for an initial user experience and complete end-to-end testing. From this point, it can still take one to four years to reach the final software release before market launch.
In comparison, innovative market entrants need just 24 to 30 months to design and develop a new vehicle. Advantages include earlier software deployment and more-robust software release cycles along the development process, a continuous deployment process before and after start of production (SOP), a high level of reuse, and rigorous deployment of a common software platform. The supplier space exhibits similar trends. Some Chinese companies are pushing through new e-drive platforms within two years at 20 to 30 percent of the cost of conventional suppliers in Europe, which typically take four years to bring a new platform to production.
Conventional OEMs often require long testing phases to debug their software and boost the release frequency during the testing phase, which results in the branching of software versions and challenges in fixing bugs. They also have fewer over-the-air (OTA) capabilities that would enable them to fix bugs once vehicles are in the field.
The difference in approaches between conventional and new entrants doesn’t end there. OEMs tend to deprioritize their long requirements and architecture phases in favor of ambitious testing and integration efforts, leading to poor-quality requirements and E/E and software architectures.2 New entrants are much more focused on proper but shorter requirements and architecture phases, an approach that speeds the initial software release and enables quicker software cycles, better OTA performance, and smoother testing and integration.
Structural and operational challenges
OEMs recognize they must chart a different course for software development to keep pace with new entrants, yet optimizing the software development process in their current environment presents challenges.
Traditional OEMs manage a diverse vehicle portfolio, including ICE vehicles, BEVs, and plug-in hybrid EVs. The difference in portfolio complexity between conventional OEMs and new entrants (based on car models offered) can deviate by a factor of 150. To accommodate this range, conventional OEMs developed multiple software platforms in parallel. The need to maintain and upgrade these diverse platforms simultaneously exacerbates the complexity and challenges with resource allocation.
The structure and culture that shaped OEMs over generations also make it difficult to adopt more-agile approaches. For example, conventional OEMs established a process for hardware-centric vehicles to enable the disaggregation of the vehicle into functional parts, which are developed by internal and external teams of traditional engineers in a waterfall model. This process, characterized by lengthy development cycles, lacks the nimbleness to facilitate rapid software innovation.
Conventional OEMs also struggle to attract top software talent. Their competition, international tech companies, can offer more-compelling compensation, culture, and processes. As a result, conventional engineers or technical project leads are often in charge of managing software development. While they can steer suppliers through the process, they lack core competencies in software engineering and development to collaborate or more effectively guide teams.
All of these factors combine to create an incredibly complex integrated hardware and software development process. The degree of difficulty increases further in cases when OEMs do not create systemic links between the right-hand and left-hand sides in the automotive V-model (Exhibit 2).
Beyond architectural inertia and entrenched processes, an additional fundamental challenge for many OEMs lies in the widening disparity in the pace of technology adoption. Market disruptors with agile foundations are rapidly integrating AI and cloud-native solutions. By contrast, traditional players are at a critical competitive disadvantage as they struggle to harness these transformative technologies.
Identifying the root causes of software development issues
To accelerate the software development process, OEMs must identify the underlying root causes driving their delays instead of just trying to fix the symptoms. Our analysis identified 11 discrete root causes. Four of them span the entire process, while others are concentrated in specific phases.
Overarching process
Opaque software delivery processes. OEMs commonly don’t invest sufficiently in release planning and tracking. Quality gates, which ensure software meets all requirements before moving to the next step, can be poorly defined and change frequently during the development process. Key metrics such as dependencies between functions, testing coverage, and the end-to-end system’s communication matrix or ticket backlog are often not sufficiently tracked or considered, leading to delays in SOP by months or even years.
Lack of state-of-the-art, end-to-end tool chain. The end-to-end tool chain enables consistency throughout the entire software development process—for example, for requirements definition and progress tracking across feature development and testing. Features such as automated interfaces reduce administrative effort and enable continuous integration and continuous deployment (CI/CD), making a high-performing tool chain a critical input. OEMs often draw on a broad set of suppliers for their tool chain, resulting in limited standardization and automation of interfaces, an underdeveloped end-to-end data backbone, and a shortage of required capabilities (such as for virtualized testing).
Deprioritization of proper project and risk management. Transparency on possible roadblocks and the overall critical path helps to steer complex software platform development. Without a systematic, overarching project plan that aggregates individual plans and interdependencies across all domains, roadblocks in domain-specific (for example, integration cycles or testing of individual features) and domain-spanning (such as the availability of sufficient testing resources) areas can go undetected. For instance, the existence of multiple or inconsistent plans for individual feature branches can impede project and risk management. That leaves OEMs unable to make a realistic assessment, including identifying risks for achievable software release dates and subsequent SOPs.
Job split along sequential waterfall. Development processes at conventional automotive OEMs typically adhere to the classic V-model and are shaped by a long history of waterfall model–based development focusing on hardware. If this behavior is applied to the four phases of software development and simply overlaid, it results in an inefficient job split. Teams defining requirements on the left-hand side of the V-model are not involved in testing the software against requirements on the right-hand side, leading to a lack of end-to-end perspective across the V-model.
Requirements and architecture
Loose requirements management. It is best practice to finalize requirements approximately two years before the final software release. When requirements are not sufficiently detailed at the outset, OEMs face delays in reaching initial milestones for freezing and evaluating the software portfolio. In addition, it’s not uncommon for new software functions to be added to the portfolio late in the process or after official freeze, resulting in required changes to the communication between ECUs (and, in the worst case, architectural changes), resource shortages, and inadequate time to properly evaluate requirements.
Inefficient supplier interaction and collaboration. At many OEMs, suppliers are invaluable contributors to software development, bringing in essential capabilities, expertise, and capacity. However, they are often integrated too late in the process (after the architecture freeze), so OEMs miss out on leveraging supplier platforms and knowledge in the architecture concept phase. Thus, technical solutions specified by the OEM can be expensive and complicated, pushing development and testing work downstream.
Lack of synchronization between software and hardware development. Conventional OEMs typically follow the classic V-model and waterfall development process for hardware, with timelines spanning three to seven years. In contrast, software development operates on rapid, iterative cycles, requiring frequent updates and flexibility. A critical issue is the lack of synchronization between hardware and software development, particularly in the early and late stages of the V-model.
E/E development and update
Long integration cycles and complex integration of software and hardware. At conventional OEMs, software–hardware integration cycles can become complex due to multiple parallel software branches, subpar requirements and integration management, and poor partitioning and fragmentation of the architecture. For example, ensuring stability of already developed software functionality in cases of required upgrades to the communication signals between ECUs, the controller area network (CAN), and the local interconnect network (LIN) can take more than 20 weeks. Poor management of change requests can lead to late detection or generation of new bugs, while teams may lack the visibility into the underlying root causes to fix software issues efficiently and holistically, further slowing software–hardware integration.
Feature development and integration
Release management. The high frequency of releases within a software delivery cycle, while well intentioned, can lead to version control issues and require additional effort for bug fixing and error management. When combined with a poor CI/CD tool chain, OEMs can end up devoting more resources to managing releases and manual integration than to developing software itself. The high release frequency also creates ambiguity in the scope of the release and overlapping software versions deployed in the testing fleet.
Make-or-buy decisions and code or IP ownership. Conventional OEMs still outsource a significant share of software engineering capabilities. Their reliance on suppliers and engineering companies can create challenges in the development cycle. For example, suppliers can deliver software without providing OEMs visibility into the source code, leaving them without transparency on the effort required to implement changes and update features. This information asymmetry also limits OEMs when negotiating costs for bug fixing and releases over the software life cycle.
E2E testing strategy. Effectively testing software at scale requires a comprehensive approach that covers the integration steps from component to system to vehicle. Further, the basic software and operating system must be developed first and harness test automation and virtualization, which calls for a state-of-the-art test infrastructure. Many conventional OEMs have relied on the collective experience of their engineers but do not leverage the vast amounts of data on customer behavior and product performance available in the field. Thus, they are falling short on data-enabled engineering and virtual-engineering capabilities.
How OEMs can accelerate software development
Based on these root causes, we see several actions that conventional automotive OEMs could take to accelerate software development. However, they will need their tier-1 suppliers to contribute as well. The proposed changes span the four phases of the software development cycle (Exhibit 3).
Optimized requirements definition
OEMs must meticulously optimize their requirements definition to manage changes effectively and ensure seamless software integration during the requirements and architecture phase. An important change is for OEMs to establish a strict requirements freeze based on a well-defined function baseline that can serve as a foundation for all subsequent development and software integration activities. Priority requirements should reflect a balanced, realistic view on costs, profits, and feasibility. While legal requirements are critical, functional requirements can be ranked by necessity for competitiveness, profit contribution, and desirability. Strong governance is essential to prevent the addition of broad requirements after the freeze and to enforce the prioritization of requirements. Supplier involvement at this stage is essential.
In addition, a robust and clearly defined change process for requirements post-freeze can handle any modifications without jeopardizing the overall delivery. Further, using advanced technologies such as gen AI to create requirements, draft descriptions, and specification derivations can speed up these tasks and ensure specifications adhere to industry standards.
Collaboration model with tier-1 suppliers
OEMs should engage their suppliers at the beginning of the requirements and architecture phase. This enables all parties to align and iterate on requirements as well as the adoption of technological concepts or platforms without complex adjustments or workarounds. The result can be solutions that are more cost-effective with shorter development cycles. However, to avoid becoming dependent on suppliers, OEMs should clearly outline code and IP ownership at the outset of the software development process.
Robustness and ‘delta’ process of ECUs communication network
A primary enabler of accelerated software delivery is an efficient architecture that integrates functionality to minimize “critical” changes in the communication matrix (the network of ECUs and their communications both within the vehicle and with external systems) over the development cycle. Changes qualify as critical if they affect components that require approval through new, lengthy road releases. OEMs should consider differentiating between faster internal certification through “delta” process assessments (evaluating changes and modifications in software code and processes to meet quality, safety, and compliance standards) and dedicated, lengthy road releases. This approach involves designing the system to isolate elements such as ECU configurations and safety-critical software modules, thereby reducing the need for frequent adjustments.
Sufficient OTA capabilities can further increase development speed during testing by accessing data and running simulations remotely.3 In addition, OEMs can use OTA to consistently push upgrades to vehicles in the field, as well as to offer functions on demand (FoD) and new functionalities. Such capabilities can enable efficient bug fixing and maintain the software’s competitiveness over the vehicle’s life cycle while relieving the pressure on OEMs to deliver complete, flawless software at SOP.
Software delivery cycles in integration and testing phase
Optimizing the frequency of software delivery cycles during integration and testing is crucial. OEMs commonly assume that fast testing is always better, but an excessively high (manual and isolated) testing frequency can lead to version control issues, increasing supplier costs and leading to recurring bugs and a more complicated, time-consuming bug-fixing process. To address these challenges, OEMs could reduce the frequency of deliveries, thereby minimizing software versions. Moreover, completing testing on one software version before testing the next can prevent duplicate bugs and enable more efficient, bundled bug fixing. These changes can streamline the testing process and reduce complexity, ultimately producing higher-quality, more reliable software.
Cloud-native architectures and containerization as foundational enablers
While CI/CD is essential, its full potential is realized only through a foundational shift toward cloud-native development architectures and pervasive containerization. This strategic move enables a true microservices approach, fostering superior modularity, resilience, and unparalleled scalability. The inherent flexibility and rapid deployment capabilities offered by container orchestration platforms (such as Kubernetes) directly translate to significantly shorter development cycles and more-robust, frequent software releases. This represents a dramatic shift from traditional infrastructure models, aligning OEMs with the agility and rapid iteration capabilities of leading software companies.
Role of architects in the process
Architects should be involved throughout the entire V-model development process, including the testing and integration phase. During E/E and feature development, architects can ensure solutions are developed in line with underlying architectural concepts and principles while helping to fix issues fast.
During feature development, architects can consider the dependencies of functions and features in the functional ramp-up and account for them during integration. In testing and integration, they can help to implement concept changes, lead vehicle integration and bug fixing, and enable efficient solutions with minimal architectural implications in line with the overall performance and architectural boundaries. In this way, they can ensure initially defined concepts are consistently followed throughout the release. OEMs should also consider including architects in life cycle management to contribute to OTA updates and verify sufficient computing power for future updates.
Leveraging AI and machine learning for accelerated development
To truly achieve next-generation development velocity, OEMs must proactively embed AI and machine learning (ML) across their entire software life cycle. This effort involves a strategic shift to harness AI-powered code generation tools, which can automate significant portions of routine coding, drastically reducing development timelines for new features. Furthermore, the adoption of intelligent, AI-driven testing frameworks will transform quality assurance, enabling proactive identification and resolution of defects far earlier in the cycle.
Beyond development and traditional maintenance, advanced AI and ML capabilities are ushering in a new frontier for in-vehicle intelligence. Applications include highly sophisticated, AI-driven advanced driver-assistance systems (ADAS) and foundational elements for autonomous driving platforms. These systems use real-time data fusion, complex perception algorithms, and predictive behavior modeling for not only safety but also continuous learning to enhance driving experiences and vehicle performance. This level of AI integration moves beyond merely adding features to instead reshape the very nature of interaction and capability over a vehicle’s lifetime.
More agile, systems engineering–based operating model
OEMs seeking to enhance software delivery should adopt an operating model that combines agile principles with a true systems engineering approach across all phases. This model breaks down the development process into manageable systems and subsystems, each requiring dedicated architects and integrators who ensure development cycles run smoothly within the overall development process. These teams must remain stable throughout the entire development cycle to facilitate continuous integration and alignment. To do so, OEMs must break their original sequential waterfall model. The consistent engagement of subsystem teams should be protected in a resource plan across all phases, preventing reprioritization of resources to other projects. A reference database can help OEMs plan team capacity more stringently based on benchmarks and make better-informed decisions related to the deployment of their own resources and contribution of suppliers in the process.
Adopting these changes would increase software development velocity across all phases. Our benchmarking analysis suggests OEMs could reduce the overall duration of software development cycles from 2.0 years to 1.5 years and shift the distribution of development phases as follows: Requirements and architecture could be optimized at 25 to 30 percent of the distribution (up from 15 to 20 percent currently); E/E development and update could be optimized at 15 to 20 percent (down from 35 to 40 percent currently); and feature development and integration could be optimized at 50 to 60 percent (up from 45 to 50 percent currently).
The longer architecture phase would give OEMs more time to specify, develop, and freeze requirements, leading to higher requirements stability. Similarly, a longer feature development phase would enable an earlier first release (minimum viable product) and more bottom-up testing.
However, OEMs adopting the described transformational measures would need to be vigilant about implementation across all domains. These changes will take time and should be incorporated across the entire development cycle. In addition, the impact of measures can be increased by breaking up legacy conventions and boundary conditions of respective OEMs, such as requiring two winter tests per development cycle.
Streamlining the software development process at conventional OEMs also calls for a comprehensive change-management strategy. Leadership could promote a mindset of innovation and continuous improvement, supported by a robust governance structure to oversee the process. KPIs can measure the impact of the changes, tracking progress and identifying areas for further improvement. OEMs could start with an end-to-end pilot of a new software project completely decoupled from existing projects, commit dedicated teams and tools for the pilot, and establish a clear steering model based on systems engineering principles.
Cultivating specialized software talent
The competition for general software engineers is intense, but the true strategic imperative for OEMs lies in cultivating specialized software talent. This initiative requires aggressive strategies to attract and retain individuals highly proficient in areas such as advanced AI and ML engineering, data science, cybersecurity, and expert DevOps (software development and IT operations) roles. Attracting these scarce specialists demands a compelling employer value proposition that transcends traditional compensation models. A parallel investment in robust and continuous upskilling and reskilling programs for existing engineering teams is non-negotiable. These programs ensure internal capabilities evolve with technological demands, empowering the workforce to implement and sustain the advanced, data-driven software solutions now becoming standard.
Software is already having an outsize influence on the automotive competitive landscape, a dynamic that will only become more acute in the coming years. For conventional OEMs, streamlining and speeding up software development is an imperative. This endeavor will require sustained resources and effort, but success could level the playing field.
One of the most powerful levers to close the gap with innovative market entrants might lie in large-scale collaboration. For example, what if a set of conventional automotive OEMs across Europe were to collaborate at scale, breaking down silos to develop the software foundation of tomorrow’s vehicles? Expanding initiatives such as Catena-X into a secure, shared network for OEMs, suppliers, and software developers could accelerate innovation, reduce integration costs, and enable the creation of smarter, safer vehicles.4
Another bold step would be the joint development of open-source automotive software. By sharing core software components (such as operating systems and customer-facing functions) and standardizing APIs and development tools, conventional European OEMs could unlock new business models, eliminate inefficiencies, and future-proof the entire automotive software ecosystem. One step in this direction is a recently published memorandum of understanding signed by 11 automotive companies (including OEMs, tier-1 suppliers, and software vendors) to collaborate in the development of open-source software, which was supported by the German Association of the Automotive Industry.5 This level of collaboration could not only strengthen the industry’s competitive edge but also foster a more agile and resilient ecosystem capable of shaping the future of mobility. The time for urgent action is now.
