SDV Guide
digital.auto
  • Welcome
  • SDV101
    • Part A: Essentials
      • Smart Phone? No: Habitat on Wheels!
      • Basics: What is a Software-defined Vehicle
      • MHP: Expert Opinion
      • Challenges: What sets automotive software development apart?
      • SDV Domains and Two-Speed Delivery
    • Part B: Lessons Learned
      • Learnings from the Internet Folks
        • Innovation Management
        • Cloud Native Principles
          • DevOps and Continuous Delivery
          • Loose Coupling
            • Microservices & APIs
            • Containerization
            • Building Robust and Resilient Systems
      • Learnings from the Smart Phone Folks
    • Part C: Building Blocks
      • Foundation: E/E Architecture
        • Today`s E/E Architectures
        • Evolving Trends in E/E Architectur
        • Case Study: Rivian
      • Standards for Software-Defined Vehicles and E/E Architectures
      • Building Blocks of an SDV
        • Service-Oriented Architecture
          • The SOA Framework for SDVs
          • Container Runtimes
          • Vehicle APIs
          • Example: Real-World Application of SDV Concepts
          • Ensuring Functional Safety
          • Event Chains in Vehicle SOAs
          • Vehicle SOA Tech Stack
        • Over-the-Air Updates: The Backbone of Software-Defined Vehicles
        • Vehicle App Store: The Holy Grail of Software-Defined Vehicles
      • Summary: Building Blocks for Software-Defined Vehicles
    • Part D: Implementation Strategies
      • #DigitalFirst
      • Hardware vs Software Engineering
        • The Traditional V-Model in Automotive Development
        • Agile V-Model, anybody?
        • Key: Loosely Coupled, Automated Development Pipelines
        • The SDV Software Factory
      • Implementing the Shift Left
        • Simulation and Digital Prototyping
          • Early Validation: Cloud-based SDV Prototyping
          • Detailed Validation: SDVs and Simulation
        • Towards the Virtual Vehicle
          • Case Study: Multi-Supplier Collaboration on Virtual Platform
          • Long-Term Vision
        • Physical test system
        • De-Coupled, Multi-Speed System Evolution
        • Continuous Homologation
        • Summary and Outlook
      • Enterprise Topics
        • Variant Management
        • Engineering Intelligence
        • Enterprise Organization, Processes, and Architecture
        • Incumbent OEMs vs EV Start-ups
  • SDV201
  • ./pulse
    • SDV Culture
    • Lean Sourcing
      • LeanRM
        • Why so many Requirements?
      • SCM for SDVs
    • SDV Systems Engineering
      • LeanSE
      • SDVxMBSE
    • Digital First
    • Loose Coupling
      • API-first
      • Freeze Points
    • Automation and Engineering Intelligence
    • Continuous Homologation
    • Build / Measure / Learn
  • Glossary
Powered by GitBook

SDV Guide

  • Legal Notice
  • Disclaimer
  • Privacy Policy

(c) 2025 Dirk Slama

On this page
  • 1. End-to-End Responsibilities
  • 2. Use Shift-Left to Get End-User Feedback Early
  • 3. Use Shift-Left to Stabilize API Requirements and End-to-End Architecture
  • 4. Combining MBSE and Code-Centric DevOps
  1. SDV101
  2. Part D: Implementation Strategies
  3. Enterprise Topics

Enterprise Organization, Processes, and Architecture

PreviousEngineering IntelligenceNextIncumbent OEMs vs EV Start-ups

Last updated 6 months ago

The complexity of Software-Defined Vehicles (SDVs) requires a fundamental shift in enterprise organization, processes, and system architecture. This transformation is driven by the need to align teams, tools, and technologies to deliver faster, high-quality software updates while maintaining end-to-end consistency. To achieve this, enterprises must focus on three critical elements: end-to-end responsibilities, leveraging shift-left approaches for early feedback, and stabilizing API requirements and architecture.

Additionally, combining Model-Based Systems Engineering (MBSE) with code-centric DevOps becomes essential to balance big-picture organizational views with agile, iterative development.

1. End-to-End Responsibilities

In the SDV context, multi-skilled teams must take on end-to-end responsibility for delivering features and functions. These features are composed of artifacts contributed by multiple value streams, each with delivery pipelines operating at different speeds. For example, software components for cloud backends, embedded systems, and vehicle hardware evolve independently but must integrate seamlessly.

To succeed, teams must collaborate across domains, ensuring that ownership extends from feature conception to delivery and validation. By adopting end-to-end responsibility, organizations can:

  • Reduce handovers and delays between teams.

  • Improve the quality and consistency of delivered features.

  • Foster a systems-thinking mindset that considers the full lifecycle of a function.

2. Use Shift-Left to Get End-User Feedback Early

The shift-left approach emphasizes testing, validation, and user feedback earlier in the development process. For SDVs, virtual prototypes of end-to-end features and functions enable feedback loops long before physical prototypes are available.

By using virtual environments and simulation tools, teams can:

  • Validate feature behavior in diverse configurations.

  • Gather end-user feedback early to align with customer needs.

  • Identify and resolve issues before integration into real vehicles.

This iterative process allows organizations to de-risk development, accelerate time-to-market, and ensure that final features meet end-user expectations.

3. Use Shift-Left to Stabilize API Requirements and End-to-End Architecture

Stabilizing API requirements and the end-to-end architecture early in the development process is critical for managing SDV complexity. APIs define the interfaces between components across different systems (e.g., cloud, embedded software, and vehicle hardware), and any instability can lead to integration issues and delays.

By shifting-left, teams can:

  • Define and validate API requirements early through virtual prototypes and iterative feedback.

  • Ensure architectural consistency across value streams and delivery pipelines.

  • Minimize late-stage changes that disrupt development and testing.

A stable end-to-end architecture provides a robust foundation for integrating multi-speed delivery pipelines, ensuring that features and functions evolve cohesively across the SDV ecosystem.

4. Combining MBSE and Code-Centric DevOps

The integration of Model-Based Systems Engineering (MBSE) and code-centric DevOps addresses the dual challenge of maintaining a big-picture organizational and architectural view while adhering to agile, iterative development principles.

  • MBSE focuses on creating high-level system models, defining requirements, and ensuring that architecture and system-level decisions are validated against overall goals. It provides the "big picture" of system structure, behavior, and dependencies, which is essential for managing SDV complexity.

  • DevOps follows the agile principle of "code first," where development progresses iteratively with rapid prototyping, testing, and integration. Code-centric practices prioritize delivering working software and enabling continuous feedback loops.

Combining MBSE with DevOps allows organizations to:

  • Align architectural decisions with real-world software implementation.

  • Balance long-term systems thinking with agile responsiveness to changes.

  • Continuously validate system models against the delivered code to ensure traceability and consistency.

This approach ensures that the SDV development process remains both structured and flexible, enabling teams to deliver complex systems efficiently while maintaining alignment with organizational goals and customer requirements.

5. Building a Re-Usable SDV Platform

The ultimate target for SDV development is to establish a re-usable platform that enables software to be shared, customized, and tailored efficiently across multiple vehicle models and generations.

A reusable SDV platform provides:

  • Common, core software that serves as the foundation for all vehicles.

  • Tailored layers that adapt the core software to specific models, features, or customer requirements, as illustrated by tailored components in the diagram.

  • Interfaces and APIs that standardize communication across components, ensuring modularity and ease of integration.

By enabling software reuse and customization, organizations can:

  • Significantly reduce development costs and effort for new vehicle models.

  • Accelerate time-to-market for software features and updates.

  • Foster continuous improvements and innovation across platforms through shared software components.

In summary, the development of a reusable SDV platform is key to achieving scalability, cost efficiency, and innovation. By combining end-to-end responsibilities, shift-left approaches, and the integration of MBSE and DevOps, organizations can build a robust, flexible foundation that drives sustainable success in the SDV era.