13 minute read

Automotive OEM Restructuring for Data Monetization and Innovation - Part 2

In Part 1 of this series, we explored how automakers globally — from Volkswagen and Mercedes-Benz to Tata Motors and Mahindra — spent the past decade reorganizing themselves into software-first, data-driven mobility companies. This shift redefined vehicles as upgradable platforms, positioning software and data at the core of future monetization.

In Part 2, we dive deeper into the execution: how OEMs decide what software and data capabilities to build internally versus source externally. We break down each OEM’s evolving architecture — from cloud stacks and simulation environments to digital platforms like MB.OS, Ultifi, and Arene. We examine how these strategic choices impact traditional suppliers, niche vendors, and big tech players, and we surface the new organizational designs, sourcing models, and innovation cultures taking root inside legacy auto giants.

This installment answers critical questions:

Who builds vs. who buys — and why?

What happens to legacy Tier-1 suppliers in a software-defined world?

What are the evolving sell-entry points for suppliers?

How do OEMs govern innovation portfolios, manage digital product teams, and monetize vehicle data responsibly?

Internal vs. External Software & Data Efforts by OEM (Comparative Matrix)

Each automaker has drawn the boundary between what they build in-house vs. source from external vendors somewhat differently. The following comparison outlines each OEM’s approach to software platforms, data infrastructure, simulation tools, and where they partner or buy instead of build:

Volkswagen Group (VW, Audi, Porsche, etc.):

  • Internal : CARIAD software unit building VW.OS and unified E³ electronic architecture for all brands. Developing in-house modules for infotainment, digital cockpit, ADAS/automated driving algorithms, EV energy management, etc., to reach ~60% software in-house. Created VW Automotive Cloud (with Microsoft) but using mostly in-house integration. Aggressively hiring developers; by 2021 had 4,500+ in CARIAD. Uses in-house Big Data platform (“Digital Accelerator”) for vehicle data and Big Loop machine learning (closing the loop with fleet data).*
  • External: Selectively partnering for non-differentiating components. E.g. Qualcomm for automotive SoC chips for autonomous driving, Microsoft Azure for cloud infrastructure (VW’s cloud is built on Azure), Bosch for co-developing automated driving software (since 2022). In China, partnering with Horizon Robotics (via JV) for AD software. Still relies on some Tier-1 suppliers for sensors and actuators, but increasingly on build-to-spec terms. Simulation: uses a mix of internal simulation environments and supplier tools (rumored to have built proprietary simulation for ADAS testing, while also using dSPACE and IPG CarMaker tools). Overall, VW’s stance is “build core, buy/partner for commodity or regional needs”, aiming to make CARIAD a Tier-1-like internal supplier. * Mercedes-Benz:
  • Internal: Developing MB.OS entirely in-house for the base vehicle software stack (integrating all domains: infotainment, AD, telematics). Built new software centers and plans to have ~10,000 internal software engineers. Writing its own middleware and vehicle cloud platform to ensure full control of data and customer interface. Runs a proprietary Mercedes Me cloud for connected services (initially on Azure, now a custom stack) and in-house AI teams for personalization (e.g. AI-based voice assistant, user behavior learning for car settings). Keeps cybersecurity and OTA update system development internal for safety. *
  • External: NVIDIA provides hardware (Orin chips) and some SDKs for MB’s ADAS and autonomous driving features, effectively a supplier under MB’s direction. Google is a navigation/maps partner – MB.OS will integrate Google Maps services, but under a Mercedes-branded UI (Mercedes keeps the data funnel). Uses Luminar for LiDAR hardware. For cloud, Mercedes uses a hybrid of Azure and on-premise for data storage/processing of vehicle data (as indicated by MB’s partnership with Microsoft for digital factory, likely extended to connected car data). Simulation & validation: Mercedes uses a mix – it invested in its own driving simulator center in Sindelfingen and also works with external simulation software (MSC Adams, IPG, etc.). It has partnerships for HD mapping (HERE maps co-owned) and had a partnership with BMW for Level-3 automation R&D (2019–20) that was paused, indicating Mercedes decided to pursue it more internally (with NVIDIA) instead. In sum, Mercedes insources the software “brain” and integration, and leverages top-tier tech partners for specialized tech building blocks (chips, map data), rather than buying complete systems. *

General Motors:

  • Internal: Ultifi platform developed largely in-house (common software layer enabling OTA updates, feature apps, and cloud connectivity across GM brands). OnStar Connect platform for telematics data – internal since the ‘90s but modernized for big data (GM built a new data center and data platform around 2018 to handle billions of OnStar data points for services like driver behavior-based insurance). GM writes its own firmware for its Vehicle Intelligence Platform (with help from chip vendors but GM has final control). AI and data science teams in-house for developing advanced driver assist (e.g. Super Cruise) and analyzing vehicle data for predictive features. Importantly, GM’s decision to drop CarPlay indicates it is internalizing the infotainment user experience, using an Android-based OS but custom integrating it to gather usage data itself. Cruise, while a subsidiary, is essentially internal (working on Cruise AV stack and the forthcoming “Ultra Cruise” for GM vehicles).
  • External: Android Automotive OS is used as a base infotainment operating system in many 2020+ GM models (built by Google), but GM customizes it and will layer Ultifi on top. Google Cloud is a key partner for connected vehicle services (since 2019) – GM co-develops integrated services with Google (Assistant, Maps) and hosts data in Google’s cloud. Microsoft is another partner: GM and Cruise received Azure cloud credits as part of Microsoft’s investment, and Azure is used for some development and simulation workloads at Cruise. Chip suppliers like Qualcomm (Snapdragon for infotainment, Snapdragon Ride for ADAS) provide hardware and reference software; GM integrates and may co-develop certain features with them. For simulation, GM uses both internal tools and external platforms (it acquired AI startup Voyage’s simulation team into Cruise, and uses Applied Intuition’s simulation software as a customer). Generally, GM is building an ecosystem with it at the center – it partners for essential pieces (cloud, base OS, silicon), but ensures those are tightly knit into GM’s proprietary systems and that GM captures the data and service revenue.

Toyota (incl. Lexus):

  • Internal: Through Woven by Toyota, developing Arene (an in-vehicle software platform/OS) internally. Has built a custom operating system for its latest vehicles (e.g. new Lexus interface is reportedly built on Toyota’s own Arene platform). Toyota Connected handles global cloud data management – an internal entity that built Toyota’s cloud services on AWS but proprietary to Toyota. They explicitly aim to monetize data via services: e.g., Toyota’s Mobility Services Platform + AWS collects connected car data globally to power new applications (rideshare, insurance).Toyota has internal big-data and AI teams (TRI in the US works on AI for both mobility and material science, Woven Core in Japan works on automated driving software). Also focusing on personalization internally: e.g. Toyota’s Driver Score, driver-specific settings stored in the cloud, etc., are developed by Toyota Connected.*
  • External: AWS is a foundational partner for cloud (Toyota leverages AWS IoT, storage, and analytics services to run its Mobility Services Platform, but Toyota architects the applications). Apex.AI – Toyota partnered with this middleware provider to incorporate a reliable RTOS kernel (Apex.OS) into Arene; Toyota thus didn’t build the entire OS from scratch but is integrating proven building blocks. Mapping: Toyota still buys HD maps externally (it acquired Carmera, but also partners with HERE and TomTom in regions). Autonomous tech: Toyota has a stake in Uber’s ATG (sold to Aurora) and likely uses some external tech from Aurora for future robotaxis – indicating a willingness to partner in high-risk domains to supplement internal efforts. Simulation: Woven Planet developed an in-house simulator (“Arene Virtual Testing”), but also uses external tools (it even open-sourced some tools and uses CARLA simulator for some research). Toyota’s general approach is cautious partnership: it internalizes what it can (especially where it touches the Toyota customer experience or core vehicle performance), but it’s not averse to buying solutions for speed – e.g., its late move to offer Android Auto/Apple CarPlay in 2018 was basically acknowledging that sometimes an external solution is acceptable for user convenience, even if data-sharing is a trade-off. (Notably, Toyota still offers CarPlay/AndroidAuto on its cars – unlike GM – reflecting a different view on that specific buy-vs-build choice.)*

BMW Group:

  • Internal: BMW has long done a lot in-house: the famed iDrive infotainment system (since 2001) is largely BMW-designed software atop an OS kernel (often QNX or Linux). The current BMW Operating System 8 is an in-house UI/UX and framework. BMW writes its own driving dynamics and EV control software, and even developed its own battery management software. It operates data centers in Munich for connected car services and runs its ConnectedDrive cloud largely on in-house developed platform (with some services hosted on Microsoft Azure). For ADAS/AD development, BMW built the D³ (Data-Driven Development) platform internally, enabling it to process petabytes of driving data for machine learning. BMW also co-developed (with Daimler, 2017) the HERE-powered data standard to share live car sensor data (sensor-island), meaning it treats data platforms as strategic assets. Importantly, BMW tends to open-source or license non-differentiating code (they have contributed to open-source AUTOSAR Adaptive, etc.) but keep differentiators proprietary. *
  • External: BlackBerry QNX has been a supplier of the underlying OS kernel for many BMW systems (though BMW added a Linux-based stack for some new systems). Mobileye was a key partner for BMW’s early ADAS – BMW’s Level-3 automation plan (for 2021 iX) was built with Mobileye and Intel; however, BMW pivoted in 2022 to use Qualcomm/Arriver for its next-gen ADAS, effectively replacing an external system supplier (Mobileye) with a closer partnership where BMW has more say (Arriver’s vision stack can be customized for BMW). For semiconductors, BMW buys from Intel, Nvidia (for some HPC in iX), and Qualcomm – not developing its own chips (though it provides specs input). Cloud & AI: BMW uses Amazon Web Services and Microsoft Azure for different aspects (AWS for some connected car functions as per an AWS case study, Azure for enterprise IT and perhaps some ML workloads) – but those are infrastructure choices; the data architecture is BMW’s own. Simulation tools: BMW uses plenty of vendor tools (Simulink, CarMaker, etc.) but also has an internal simulator (they built a massive driving simulation center in 2020). Mapping/Navigation: BMW co-owns HERE, so effectively they externalized mapping but by owning the supplier collaboratively (with Audi and MB). In summary, BMW’s philosophy is “build what differentiates – buy or partner for the rest, but often take an equity stake or long-term partnership in key software suppliers.” *

Hyundai Motor Group:

  • Internal: Hyundai is establishing an Integrated Modular Architecture (IMA) with two core platforms (eM for EVs, eS for PBVs) by 2025, and each will run on an in-house developed Connected Car OS (ccOS). This ccOS and the server infrastructure around it are being built internally (likely with contributions from acquired firms like 42Dot for autonomous driving software, and with support from Hyundai’s global R&D). Hyundai set up a new Global Software Center to consolidate software development across vehicles and cloud – essentially mimicking the CARIAD/MB.OS model. It’s also developing many vehicle control software internally to improve integration (Hyundai cites the need to “enhance and internalize mobility technology capabilities” by investing heavily through 2030). *
  • External: NVIDIA is a significant external partner – Hyundai/Kia use NVIDIA Drive for infotainment and some ADAS controllers (an agreement since 2020 ensures standardized NVIDIA platforms in all models). This gives Hyundai a ready-made platform, but Hyundai writes the applications and UI on top (e.g. Genesis models have a unique GUI that Hyundai’s team built). For connectivity and cloud, Hyundai partnered with leading telcos (e.g. in Korea, with tech companies for connected car cloud). Hyundai has also invested in startups: it works with Aurora (it invested for a period) for some autonomous tech and Motional (its JV with Aptiv) for robotaxis – showing an inclination to partner in high-risk AV ventures rather than do everything internally. Simulation and AI tools are often sourced: Hyundai uses Ansys, Simcenter, etc., for vehicle simulations, but the new Software Center is likely to develop proprietary simulation environments for software validation. In effect, Hyundai buys proven tech building blocks (chips, base software) to accelerate timelines, but is adamant about converging them under an internally managed software architecture by 2025.*

Tata Motors / JLR:

  • Internal: JLR has set up an Electrified and Connected engineering hub in Ireland (2022) focusing on software-defined vehicle tech (this is effectively an internal center for writing vehicle OS and connectivity software). JLR’s upcoming Panthera EV platform is in-house hardware and they’re very likely pairing it with an in-house software platform (they have referred to a new “digital ecosystem” for Jaguar’s reboot). Tata Motors in India leans on Tata Consultancy for developing its Connected Vehicle Platform – which while technically external, is within the Tata group, essentially acting as an internal capability. Tata’s newest cars (e.g. Nexon EV) come with iRA connected tech developed by Tata’s digital teams. Tata also established a “Digital Factory” collaboration with Tata Technologies for PLM, and is exploring data monetization via Tata Communications (for connectivity services). *
  • External: NVIDIA Drive is the core of JLR’s vehicle computing from 2025 – they chose to buy this platform for AI and autonomous features rather than continue trying to develop it alone or use a myriad of suppliers. JLR has partnerships with CloudCar (since 2017) for infotainment apps and with BlackBerry QNX (which provides the base OS for current Land Rover infotainment). In India, Tata Motors partners with Microsoft for some connectivity solutions (e.g., a 2019 Tata-Microsoft partnership for an Azure-based connected car platform). Simulation and CAD: JLR uses Dassault Systèmes 3DEXPERIENCE for vehicle engineering (extended partnership in 2022), meaning a lot of its development data and simulation rely on that external platform. So Tata/JLR rely on outside tech for underlying platforms when it’s faster, but they steer the integration. They are reducing classic Tier-1 dependency: e.g., earlier JLR would buy infotainment systems from Bosch or Valeo; now it specifies the platform (NVIDIA-based) and might directly contract software development or do it in-house. The result is fewer black-box components from suppliers and more open development either internally or via tech partners.

Mahindra & Mahindra:

  • Internal: Mahindra is in earlier stages but has shown intent to internalize software in its EV products. It created a new Software Defined Vehicle architecture team (with help from Vector) to bring more software design in-house. It is building an internal OTA and telematics platform (with Sibros providing technology, but Mahindra will own the instance and customization). Mahindra’s Tech Mahindra division is effectively the internal IT arm that can develop custom software for Mahindra Auto – for example, Tech Mahindra offers an SDV framework that Mahindra Auto can leverage *
  • External: Mahindra continues to rely on external vendors for many implementations: it has used Bosch ECU software for combustion vehicles, and for EVs it partnered with VW for powertrain components (so software for battery management might come from VW’s toolbox). It’s collaborating with BYD (for battery tech) which likely includes some software components. In ADAS, Mahindra will probably buy solutions from suppliers (it’s using Bosch’s ADAS in some models). Essentially, Mahindra is following the industry playbook on a smaller scale – gradually building internal software capabilities (especially in user-facing apps and EV integration), while still buying a fair amount of ready-made tech due to resource constraints. Over time, we expect Mahindra to localize more software development via its Group resources. *

Key Takeaway:

Across OEMs, critical software and data platforms are being internalized, whereas hardware and lower-level components are often still sourced from specialists. Even when partnering, OEMs now insist on deeper control: co-developing (like MB with NVIDIA), equity stakes or JVs (VW-Horizon, Stellantis-Foxconn JV), or using open platforms they can extend (GM building on Linux, Toyota on Apex.OS). This reduces traditional Tier-1 suppliers’ role in owning software IP – many Tier-1s are repositioning to supply hardware or act as contract developers under OEM direction.

Impact on External Vendors and the Buy-vs-Build Dynamics

The shift to internal software and data platforms has significant ripple effects on the automotive supplier ecosystem and on the dynamics of “buy versus build” decisions:

Tier-1 Suppliers (Bosch, Continental, Denso, etc.): These suppliers historically delivered black-box systems (engine control units, infotainment systems, ADAS modules) with proprietary software. OEMs’ internalization means Tier-1s are increasingly kept out of the software loop or asked to become implementers rather than designers. For example, VW’s plan to do 60% of software in-house by 2025, implies Tier-1s’ share shrinks. Some Tier-1s have responded by transforming into software partners: Bosch, for instance, agreed to work with VW’s CARIAD to develop automated driving software as a partner, not just a supplier. Tier-1s are focusing on supplying hardware (sensors, ECUs) and middleware that is open (many support AUTOSAR Adaptive, etc.), letting OEMs add their secret sauce on top. They are also offering engineering services – essentially becoming an extension of OEM teams when needed. This can lead to new business models: time-and-material contracts instead of per-unit IP licensing, as OEMs want the IP ownership. In the long run, Tier-1s that provided primarily software (like navigation providers, infotainment software companies) face either integration into OEM (via acquisition or JV) or being sidelined. A case in point: Elektrobit (owned by Continental) historically provided infotainment software; now some OEMs use it as a development partner while others replaced it with internal OS or Android solutions. Overall, external suppliers must find a niche either in hardware, as platform providers that OEMs build on, or by serving lower-tier smaller OEMs who haven’t invested in software. The multitude of OEM-specific OSes also means Tier-1s may need to customize their offerings for each OEM’s platform, reducing economies of scale for them.

Cloud Service Providers & Big Tech: The internalization trend has a nuanced impact on cloud and tech vendors like Google, Amazon, Microsoft. On one hand, OEMs are not building their own global data centers from scratch – they are relying on cloud infrastructure (AWS, Azure, etc.) to store and crunch vehicle data. For instance, Toyota’s entire connected vehicle backend is on AWS and VW partnered with both Microsoft (Automotive Cloud) and AWS (Industrial Cloud), indicating cloud providers gained significant business as automakers digitalized. However, OEMs insist on owning the applications and data on these clouds. The cloud providers have largely become behind-the-scenes enablers rather than consumer-facing players. The clearest example is in infotainment: Google Automotive Services (Google Maps, Assistant) are being integrated by some OEMs (GM, e.g., uses Google in lieu of CarPlay), but OEMs like Mercedes insist on a Mercedes-branded experience even if powered by Google in the back. Apple’s CarPlay and Google’s Android Auto – which once threatened to make car UI their domain – are being limited or negotiated on OEM terms (GM’s ban of CarPlay in EVs, Mercedes and others working on alternatives). This reflects OEMs’ determination to not cede the customer interface and data to Big Tech. As a result, tech companies pivot to offering enabling tech: Google sells Android OS or cloud services to OEMs, Amazon sells AWS and Alexa Custom Assistant for carmakers to integrate (e.g., GM’s OnStar assistant uses a custom Amazon Alexa), Microsoft invests in auto (e.g., Cruise) to be the preferred cloud. The net effect: Big Tech is still in the car, but more as subcontractors rather than as the product owner, at least for those OEMs who can afford to develop their own systems.

Niche Software Vendors (Simulation, Mapping, AI Tools): Simulation and AI tool providers (e.g., Applied Intuition, Ansys, dSPACE, Cognata) have both opportunity and risk. Opportunity because OEMs need advanced simulation to validate increasingly complex software – and not all OEMs can build those tools from scratch. Indeed, OEMs have become major clients of simulation software companies (buying licenses for virtual testing of ADAS, etc.). However, as OEMs set up internal simulation farms, they might develop proprietary scenarios and models, reducing reliance on off-the-shelf simulation products over time. Some OEMs have even acquired simulation startups to internalize that knowledge (GM acquired Voyage’s simulation team, Ford acquired SAIPS for AI which included simulation tech). Vendors providing data management and labeling for AI also feel the squeeze: OEMs are creating internal “data factories” and often prefer to develop sensitive AI models in-house (for IP and safety reasons). Yet, they still outsource certain tasks (like large-scale data labeling to companies like Scale AI or Tech Mahindra’s BPO division).

Generative AI Infrastructure: With the 2023 surge in GenAI (like GPT models), external vendors are pitching automotive-specific GenAI solutions (for example, for synthetic data generation, or conversational assistants in cars). But OEMs treating data as a product means they are cautious – they won’t send proprietary driving data to an external GenAI API without safeguards. Instead, they might buy specialized GenAI tools to run in-house (either open-source models or secure vendor solutions). This trend could hurt generic AI cloud service usage in favor of on-premise AI models that OEMs control. One example: Mercedes-Benz discussed using NVIDIA’s Omniverse and Generative AI for digital twin simulations in production– here they buy an AI platform (Omniverse) to use internally, rather than rely on a service. In summary, specialized software vendors must align with the OEM-as-customer model: providing tools and SDKs that OEMs’ own engineers use to build the final product, rather than delivering turnkey systems. Those who find the right collaboration model (like NVidia with its open DRIVE platform, or Apex.AI providing safe OS modules) can thrive; those who offered closed proprietary systems may find fewer takers.

Buy vs. Build Culture: The widespread internalization has changed how OEMs approach procurement. Previously, an automaker might issue requirements and purchase a complete subsystem from a supplier (buy). Now, automakers first ask: Can we develop this internally or with a strategic tech partner? The threshold for “build” has lowered as they’ve grown software teams and seen the long-term financial benefit (e.g. recurring revenue from software vs. one-time purchase from supplier). Build (in-house) is chosen for any area that touches differentiation, data, and customer experience. For example: user interface software, core driving algorithms, connectivity/cloud ecosystems, personalization features – all tend to be build or at least heavily customized. Buy (external) is still used for commoditized tech or fast-track needs: e.g., a ready-made cybersecurity solution (some use Argus Cyber Security externally), or standard software libraries (AUTOSAR stacks, operating system kernels). Notably, even when buying, OEMs negotiate for open interfaces and source code access so they aren’t locked in. The dynamic is shifting suppliers more into a role of tech collaborators rather than independent module providers. This is evident in how OEMs talk about partnerships instead of suppliers in strategic domains (e.g., “partnering with innovation leaders” is how Mercedes described integrating Google, NVIDIA into MB.OS). One potential downside for vendors is that as OEMs unify platforms, there are fewer “entry points” to sell into. An independent simulation company might have sold tools to each brand’s R&D department; now, an OEM’s central software division might pick one solution or build its own, cutting out others. Similarly, Tier-1s that delivered infotainment to 5 different brands of a car group now see that group consolidating on one platform (e.g., VW Group’s CARIAD provides one platform for VW, Audi, Porsche, etc.), so a Tier-1 either wins that entire business or loses all brands at once. On the positive side, the internalization race has sparked more standardization and cross-industry collaboration in some areas: multiple OEMs realized not everything is a differentiator and have started to collaborate on standards (for instance, Ford, GM, and others formed the Connected Vehicle Systems Alliance for common data standards; BMW, MB, others co-own HERE for mapping data). This opens the door for external vendors to offer industry-wide solutions that OEMs collectively adopt. A case is AUTOSAR Adaptive (a standardized middleware) – many OEMs and Tier-1s contribute to it, and then companies like Vector or Elektrobit implement it and sell the basic software to everyone. OEMs don’t see that as hurting their uniqueness, and it saves everyone effort. Thus, external providers who position themselves as neutral platform suppliers (like BlackBerry QNX as a common safe RTOS, or NVIDIA’s hardware+software stack adopted by multiple OEMs) can still flourish. They are essentially the “new Tier-1s,” but catering to the OEM software orgs rather than to traditional purchasing departments.

Organizational Design & Innovation Governance Changes

To execute these strategies, automakers have overhauled their organizational structures and innovation governance: Dedicated Software Units & Talent Transformation: As described, many OEMs created separate software companies or divisions (CARIAD, Woven Planet, etc.) to allow a start-up culture and attract top tech talent with different compensation models and workflows. These units often have more agile practices (e.g. open office “campus” environments like BMW’s Autonomous Driving Campus with scrum teams, or VW’s CARIAD offering tech-style perks and stock options in some cases). OEMs also instituted software academies and reskilling programs – Stellantis, for example, set up a Software Academy to retrain thousands of engineers, and nearly all OEMs are doing internal bootcamps on cloud, AI, cybersecurity, etc. The goal is to shift the engineering culture from a mechanical, slow-changing mindset to a digital, fast-release mindset. Mercedes stated that vertical integration of MB.OS allows a “continuous, iterative approach” to development, and indeed they now aim to develop features in weeks via sprints rather than years via model cycles. This required new governance: many automakers adopted a product management approach for software, setting up product owners for digital features, separate from the vehicle hardware PMs.

Portfolio Approach to Innovation: Automakers explicitly manage a dual innovation portfolio now:

Core/Platform Projects (High-Stakes): These are the moonshots – e.g. a unified software/hardware architecture, a fully autonomous driving system, a new EV platform. These tend to be managed at the top (CEO or board level oversight) with special funding and sometimes separate entities (Cruise under GM, Woven under Toyota, Argo AI was a separate entity jointly funded by Ford and VW). The governance here accepts that these projects may not ROI for many years but are essential to long-term survival. Often OEMs seek external investors or collaborators to share risk (as Ford and VW did with Argo, or Honda investing in GM’s Cruise).

Incremental & Low/Medium-Risk Innovations: These include connected services, new mobility business models (car-sharing, etc.), and feature enhancements to existing vehicles (like launching an in-car payment app, or a new driver assist feature using existing sensors). These are typically handled within the main business units or via corporate venture arms. For example, BMW and Daimler merged their car-sharing services into a joint venture (YourNOW) – effectively treating that as a separate medium-risk business so as not to distract the core engineering too much. Meanwhile, within vehicle programs, there are now processes for continuous improvement: over-the-air update capability allows feature rollouts every few months, so teams can innovate on software for a car that’s already in customer hands. Governance-wise, companies have set up digital product boards to prioritize these software updates and ensure they align with revenue goals (e.g., GM has a quarterly review of proposed OTA features that could drive subscription uptake).

Sourcing and Partnerships Governance: The buy-vs-build decisions are now made at more strategic levels. Many OEMs created cross-functional “make or buy” committees early in a new tech’s development. For instance, for any new feature, they’ll decide: do we have capability internally? If not, do we partner, acquire, or outsource? This is different from the past when default was to send an RFQ to suppliers. We see more strategic collaborations: Mercedes collaborating with startup Luminar early (taking a small equity stake for LiDAR tech), or Hyundai outright acquiring 42Dot (autonomous software) to secure talent. These moves are approved at top executive levels because they tie into the long-term platform bets, not just a procurement need.

Monetization and Data Governance: Treating data as a product required new governance structures too. OEMs have created Data & Analytics offices and Chief Data Officers roles to govern how data is collected, stored, and monetized across the company. They ensure privacy compliance while also enabling data-sharing internally (e.g., engineering uses connected vehicle data to improve quality, marketing uses it to understand feature usage for upsells). Some have built data marketplaces: BMW’s CarData initiative (2017) set up a platform where customers could opt in to share car data with third-party service providers (insurance, etc.), with BMW brokering that exchange. This essentially monetizes data in a controlled way – BMW kept a governance role to ensure only approved third parties and use cases, thereby maintaining customer trust and a share of revenue. Similarly, automakers are entering insurance (GM’s OnStar Insurance, Toyota’s insurance, etc.) precisely to monetize driving data directly. To coordinate all this, companies have monetization strategy teams that align software roadmaps with revenue models – a new concept for OEMs that historically just sold cars and parts. For example, Stellantis in 2021 created a Software Business and Revenue department after announcing its software strategy, aiming to hit the €20B revenue goal by managing offerings across its 14 brands.

Cultural Challenges and Solutions: Bringing in thousands of software engineers has sometimes led to culture clash with traditional automotive engineers. Some OEMs initially separated the teams to shield the new culture (Woven Planet was physically separate in Tokyo, CARIAD is separate from VW’s Wolfsburg HQ). Over time, though, integration is needed to deliver results (Toyota found Woven too separate and is re-integrating it). So governance is evolving to create bridges between old and new: rotational programs (mechanical engineers doing a stint in software teams to learn Agile), joint leadership appointments (e.g., VW put experienced car executives alongside software experts in CARIAD’s new management). The ultimate goal is to embed the software mindset into the main organization. Ford’s reorganization into Model e (EVs/software) and Ford Blue (traditional) is an example where they structurally separated the innovative part to free it from old constraints, but kept a shared leadership at the top to ensure the innovations flow back into the whole company. In essence, automakers have had to become technology companies in organization and mindset, not just in rhetoric. This includes flattening hierarchies (to speed decision-making), adopting Agile project management at scale, using OKRs (objectives and key results) for software goals rather than traditional auto KPIs, and fostering external innovation networks (through accelerators and hackathons inviting developers to create apps for their new platforms). The result by 2025 is that most major OEMs are far more nimble and software-focused than they were in 2015, though each is at a different point on this journey and still working through growing pains.

Conclusion

By 2025, the automotive value chain has been fundamentally reshaped. What began as a defensive shift against Big Tech has become a deliberate reengineering of how OEMs innovate, organize, and create value.

Software and data are now core IP. OEMs are internalizing foundational layers (OS, cloud, data platforms) while tightly controlling the customer interface and monetization pathways.

Suppliers and tech partners must adapt. Tier-1s are evolving into engineering collaborators or losing relevance. Cloud and AI vendors have pivoted to providing customizable infrastructure rather than owning the product layer.

Organizational models have transformed. Agile software teams, dual-track innovation governance, and centralized product/data offices are replacing old-school procurement and waterfall engineering.

What emerges is a more vertically integrated, digitally fluent OEM — capable of shipping software in weeks, monetizing post-sale, and capturing more value from each vehicle across its lifecycle.

In Part 3, we will explore the implications for investors, ecosystems, and emerging markets. We’ll look at monetization models (subscriptions, app stores, insurance), new roles for simulation and AI startups, and how emerging OEMs (especially in India and Southeast Asia) might leapfrog into this software-first paradigm.

Comments

You May Also Enjoy