„Am Anfang sollte man bewusst einen Vendor-Lock-in eingehen“

Das softwaredefinierte Fahrzeug ist seit einigen Jahren ein zentrales Thema in der Automobilbranche. Eine einheitliche Definition dessen, was genau ein SDV ausmacht, gibt es zwar nicht. Fest steht jedoch: Ein SDV endet nicht an der Karosserie.  Sensoren, Steuergeräte und Fahrzeugcomputer verschmelzend zunehmend mit Cloud-Plattformen und digitalen Diensten zu einer durchgängigen Chip-to-Cloud-Architektur. Damit stellt sich bei jeder neuen Anwendung die Frage, welche Funktionen lokal im Fahrzeug ausgeführt werden müssen und welche sich sinnvoll in die Cloud verlagern lassen.

Im Interview erklärt Alexander Stoltz, Senior Manager Cloud Services bei Bosch Engineering, welche Rolle Sicherheit, Latenz und Kosten bei dieser Entscheidung spielen. Er spricht darüber, wie sich Fahrzeugdaten über verschiedene Baureihen, Steuergeräte und Softwarestände hinweg eindeutig interpretieren lassen und wo die Grenze zwischen standardisierten Cloud-Bausteinen und kundenspezifischer Entwicklung liegt. Zudem erläutert Stoltz, warum Hyperscaler zwar leistungsfähige Services und Referenzarchitekturen bereitstellen, die automobile Integration und Absicherung aber zusätzliche Expertise verlangen. Beim Thema Anbieterabhängigkeit vertritt er eine klare Position: Statt eine neue Anwendung von Beginn an möglichst cloud-agnostisch zu entwickeln, sollten Unternehmen zunächst die Vorteile eines Anbieters konsequent nutzen. Erst wenn der Business Case funktioniert, sei es sinnvoll, den Vendor-Lock-in schrittweise zu reduzieren.

Herr Stoltz, mit welchem Mythos rund um die Cloud-Nutzung im Fahrzeug möchten Sie direkt zum Start aufräumen?

Mit den Sicherheitsbedenken. Das ist häufig das Erste, was OEMs sowie spätere Fahrzeugnutzer mit dem Thema verbinden. Früher war das Fahrzeug ein klar abgegrenztes System: Alles befand sich im Auto, und an der Fahrzeuggrenze endete die Datenverarbeitung. Heute werden Daten über Mobilfunk oder das Internet aus dem Fahrzeug übertragen, an anderer Stelle verarbeitet und teilweise wieder zurück ins Fahrzeug gespielt. Dadurch entsteht schnell die Sorge, die Daten könnten irgendwo unkontrolliert abfließen. Dafür gibt es aber klare Normen, Regeln und Standards. Es ist geregelt, wie Daten verarbeitet werden müssen, welche Datenschutzanforderungen gelten und wo sie gespeichert werden dürfen. Aus meiner Sicht ist das deshalb heute kein grundsätzlich ungelöstes Problem mehr. Entscheidend ist außerdem, dass die Daten nicht zum Selbstzweck übertragen werden. Durch ihre Verarbeitung außerhalb des Fahrzeugs können zusätzliche Funktionen und Services entstehen.

Das softwaredefinierte Fahrzeug wird zunehmend als durchgängiges Chip-to-Cloud-System gedacht. Nach welchen Kriterien entscheiden Sie, welche Funktionen im Fahrzeug bleiben und welche in die Cloud wandern?

 An erster Stelle stehen die Sicherheitsanforderungen. Das Fahrzeug muss auch ohne Internetverbindung autark, sicher und in seinen grundlegenden Funktionen betriebsfähig bleiben. Alles, was Bremsen, Lenken, Beschleunigen oder beispielsweise das Auslösen von Airbags betrifft, muss lokal im Fahrzeug funktionieren. Sicherheitskritische Funktionen dürfen nicht vollständig von einer Cloud-Verbindung abhängen. Der zweite wichtige Punkt ist die Latenz. Wenn ein Sensor etwas erkennt und das Fahrzeug innerhalb von zehn oder fünfzehn Millisekunden reagieren muss, kann ich die Verarbeitung heute nicht zuverlässig in die Cloud verlagern. Solche Funktionen müssen im Fahrzeug ausgeführt werden. Wenn eine Antwort dagegen erst nach hundert Millisekunden, einigen Sekunden oder noch später benötigt wird, kann eine Berechnung in der Cloud interessant werden.

Gibt es einen dritten Punkt?

Ja, der dritte große Faktor sind die Kosten. Technisch kann ich viele Berechnungen in der Cloud ausführen. Aber wenn ich alle paar Millisekunden Daten übertrage, sie dort verarbeite und das Ergebnis zurück ins Fahrzeug sende, entstehen laufend Kosten. Handelt es sich um eine einfache Berechnung, ist es häufig günstiger, sie direkt im Fahrzeug auszuführen. Je komplexer die Berechnung wird, je mehr Rechenleistung sie benötigt und je weniger kritisch Latenz und Verfügbarkeit sind, desto attraktiver wird die Cloud.

Können Sie das an einem Beispiel erklären?

Ein Beispiel ist unser Track Performance Assist, ein virtueller Fahrcoach für Sportwagen mit Straßenzulassung für die Rennstrecke. Funktionen, die unmittelbar auf eine Fahrsituation reagieren oder in die Bremse eingreifen, müssen im Fahrzeug beziehungsweise im ESP-Steuergerät laufen. Daneben gibt es komplexere Berechnungen, die nicht innerhalb weniger Millisekunden abgeschlossen sein müssen. Dazu gehört beispielsweise die hochgenaue Bestimmung der Fahrzeugposition auf der Rennstrecke. Dafür werden verschiedene Sensorinformationen miteinander fusioniert. Eine aufwendige Aktualisierung dieser Position muss aber nicht permanent erfolgen. Wenn das Ergebnis erst einige Sekunden später benötigt wird, kann der Algorithmus in der Cloud laufen. Im Fahrzeug bräuchte ich für die gleiche Berechnung unter Umständen einen leistungsfähigeren und damit teureren Zentralrechner. In der Cloud kann ich die benötigte Rechenleistung flexibel bereitstellen.

Braucht man für solche Anwendungen bereits ein vollständig softwaredefiniertes Fahrzeug?

Nein. Auch ohne ein vollständig softwaredefiniertes Fahrzeug kann man viele Cloud- und Konnektivitätsfunktionen umsetzen. Das geschieht seit Jahren. Ein einfaches Beispiel sind Navigations- und Infotainmentsysteme. Kartendaten oder Updates werden schon lange aus externen Systemen ins Fahrzeug übertragen. Das softwaredefinierte Fahrzeug erweitert die Möglichkeiten, ist aber keine Voraussetzung für jede Form der Cloud-Integration.

 Latenz, Rechenleistung, Kosten, Datenschutz und Verfügbarkeit sprechen nicht immer dieselbe Sprache. Welcher Zielkonflikt ist in der Praxis am schwierigsten aufzulösen?

Am Ende ist es in sehr vielen Fällen ein Kostenthema. Technologisch lässt sich heute grundsätzlich fast alles lösen. Wenn eine besonders hohe Verfügbarkeit verlangt wird, kann ich mehrere Verbindungen parallel vorsehen. Theoretisch könnte ein Fahrzeug Mobilfunkverbindungen verschiedener Anbieter und zusätzlich eine Satellitenverbindung nutzen. Irgendeine davon würde wahrscheinlich funktionieren. Das ist technisch machbar, aber wirtschaftlich kaum sinnvoll. Deshalb bestimmen die Kosten sehr häufig, welche Lösung umgesetzt wird. Bestimmte sicherheitskritische Themen sind durch Normen und Standards bereits so weit vorgegeben, dass sie nicht einfach in die Cloud verlagert werden dürfen. Bei vielen anderen Funktionen lautet die Frage dagegen: Welchen zusätzlichen Nutzen erhalte ich und wie viel darf dieser Nutzen kosten?

 Damit dieser Nutzen überhaupt entsteht, müssen die zugrunde liegenden Fahrzeugdaten verlässlich interpretierbar sein. Wie eindeutig ist die Semantik heute über verschiedene Baureihen, Steuergeräte und Softwarestände hinweg?

An diesem Thema wird sehr intensiv gearbeitet. Die Automobilindustrie hat traditionell viel über Gremien, Normierungen und gemeinsame Standards gelöst. Auch bei Konnektivität und zentralen Fahrzeugarchitekturen gibt es Initiativen für einheitliche Signalkataloge und Schnittstellen. Ein konkretes Beispiel ist die Vehicle Signal Specification, kurz VSS, innerhalb von COVESA. Ziel ist es, Fahrzeugfunktionen und Signale einheitlich zu beschreiben und anzusprechen. Nehmen wir ein einfaches Beispiel: Wenn ich das Fenster hinten rechts öffnen möchte, sollte eindeutig definiert sein, wie dieses Signal heißt und wie die Funktion angesprochen wird. Ein Entwickler oder Cloud-Service sollte nicht für jedes Fahrzeug ein vollständig anderes Datenverständnis aufbauen müssen. Solche standardisierten Signalkataloge gibt es bereits. Bosch ist an der Arbeit innerhalb von COVESA beteiligt, ebenso verschiedene OEMs und weitere Unternehmen. Wir können dieses Wissen auch unseren Kunden zur Verfügung stellen und ihnen helfen, ihre Fahrzeugarchitekturen entsprechend aufzubauen.

Wie weit ist COVESA in der Praxis?

Grundsätzlich kann man sie verwenden. Wir befinden uns aber noch in einem relativ frühen Stadium. Mir ist derzeit kein Fahrzeug bekannt, das vollständig einem solchen Standard folgt. Das Problem ist erkannt und die Branche arbeitet daran. Die entscheidende Frage ist aber, welche der Initiativen sich am Ende durchsetzt und wer sich dann tatsächlich an den Standard hält und in welchem Umfang er eingesetzt. Ein offener Standard bringt den Herstellern Vorteile, weil Integration und Austauschbarkeit einfacher werden. Er kann aber auch als Einschränkung wahrgenommen werden, wenn ein Hersteller sich über eine eigene Lösung differenzieren möchte. Die vollständige Vereinheitlichung wird deshalb Zeit benötigen. Technisch ist vieles vorbereitet, aber die breite Umsetzung hängt nicht allein von der Technik ab.

Bosch Engineering spricht von modularen und konfigurierbaren SaaS-Lösungen. Welche Bausteine lassen sich standardisieren und an welchem Punkt beginnt die kundenspezifische Entwicklung?

Grundlegende Standardfunktionen lassen sich gut als wiederverwendbare Bausteine etablieren. Ein Beispiel ist eine Lösung für Firmware-OTA-Updates. Eine solche Lösung besteht aus mehreren Komponenten. Die grundsätzlichen Bausteine und Abläufe können wir aber für verschiedene Kunden wiederverwenden. Ähnlich sieht es beim Flottenmanagement aus. Ein OEM möchte seine Fahrzeuge verwalten, den Zustand seiner Flotte überblicken und Updates ausrollen. Viele dafür benötigte Funktionen lassen sich standardisiert abbilden. Kundenspezifisch wird es meist an den Schnittstellen. Ein Fahrzeughersteller beginnt in der Regel nicht bei null. Er verfügt bereits über Konnektivität im Fahrzeug, ein Flottenmanagement, Datenplattformen oder andere Systeme. Wenn ein Kunde beispielsweise unseren Track Performance Assist einsetzen möchte, könnten wir ihm grundsätzlich auch einen standardisierten Cloud-Anteil anbieten. Typischerweise möchte er die Lösung aber in seine bestehende Infrastruktur integrieren. Außerdem soll die Anwendung zu seinem Look-and-feel, zu seiner Marke und zur Art passen, wie seine Endkunden mit dem Fahrzeug interagieren. An diesen Stellen wird die Entwicklung sehr kundenspezifisch.

Bosch Mobility und Schwarz Digits planen Cloud-Partnerschaft

Bosch Mobility und Schwarz Digits haben ein Memorandum of Understanding unterzeichnet. Die geplante Partnerschaft soll Bosch eine europäische Cloud-Option für digitale Mobilitätslösungen eröffnen.

Können Sie das Verhältnis zwischen Standard und individueller Entwicklung ungefähr beziffern?

Als grobe Einschätzung würde ich sagen: ungefähr 60 Prozent lassen sich standardisieren und rund 40 Prozent sind kundenspezifisch. Das ist keine feste Quote für jedes Projekt. Aber als Größenordnung trifft es unsere Erfahrung recht gut.

Bleiben wir beim Thema Standardisierung. Wie weit kann Automotive auf die Standarddienste großer Cloud-Anbieter zurückgreifen und wo entstehen die entscheidenden Aufwände erst durch die automobile Anpassung und Absicherung?

Die Hyperscaler bieten unterschiedliche Abstraktionsebenen an. Auf einer grundlegenden Ebene stellen sie im Prinzip ein virtuelles Rechenzentrum bereit. Dort bekomme ich Rechenleistung, Speicherplatz und weitere Infrastruktur und kann darauf meine Anwendungen aufbauen. Je nach Anbieter gibt es aber auch sehr viel weitergehende Dienste. Manche Plattformen bieten bereits Bausteine für ein vollständiges Flottenmanagement oder für eine Ende-zu-Ende-Anbindung bis ins Fahrzeug. Welche Standarddienste wir nutzen, hängt stark vom Kunden ab. Wenn er einen bestimmten Hyperscaler vorgibt, bauen wir die Lösung auf dieser Plattform auf. Je nach Anbieter und Projekt können wir viele vorhandene Services nutzen oder nur die grundlegende Infrastruktur.

Was fehlt dann noch, wenn die Cloud-Anbieter bereits so viele Bausteine und Referenzarchitekturen bereitstellen?

Die Hyperscaler liefern Services, Blueprints und Referenzarchitekturen. Sie zeigen beispielsweise, wie eine durchgängige technische Kette aufgebaut werden kann. Was sie in der Regel nicht vollständig liefern, ist die Absicherung dieser Kette für einen konkreten Automotive-Anwendungsfall. Sie geben mir nicht automatisch den vollständigen Blueprint dafür, wie ich die Lösung mit Automobilnormen, Datenschutzanforderungen und regionalen Regeln in Einklang bringe. Genau dort kommt unsere Expertise ins Spiel. Wir wissen, wie sich technische Cloud-Bausteine mit Anforderungen wie ISO 26262, der DSGVO oder anderen Datenschutzvorgaben verbinden lassen. Man kann es mit Legosteinen vergleichen: Die Hyperscaler stellen die Steine und vielleicht ein einfaches Beispielhaus bereit. Wir bauen daraus das Gebäude, das zum Kunden passt und zugleich die Vorschriften des jeweiligen Marktes erfüllt.

Wo hakt es heute am häufigsten in der Ende-zu-Ende-Kette zwischen Fahrzeugsoftware, Konnektivität und Cloud?

Sehr häufig hakt es in der Entwicklung und in der Zusammenarbeit. Auf der einen Seite gibt es Unternehmen mit großer Erfahrung in Cloud-Software, Cloud-Integration und IT-Systemen. Auf der anderen Seite stehen fahrzeugnahe Zulieferer mit viel Wissen über Steuergeräte, Sensoren, Fahrzeugfunktionen und Automotive-Prozesse, aber teilweise weniger Cloud-Erfahrung. Wenn ein OEM für eine durchgängige Lösung mehrere spezialisierte Unternehmen zusammenbringt, muss er das Gesamtsystem sehr genau spezifizieren. An den Übergängen entstehen dann Reibungsverluste. Wir sehen eine unserer Stärken darin, beide Welten zusammenzubringen. Wir verfügen über eine lange Automotive-Historie. Wir wissen, wie Steuergeräte und Sensoren funktionieren, was die Signale bedeuten und welche Normen und Regeln relevant sind. Gleichzeitig haben wir über viele Jahre Expertise bei Cloud und Konnektivität aufgebaut. Auch unsere Cloud-Architekten haben häufig einen Automotive-Hintergrund. Sie sehen nicht nur ein Datum, das in der Cloud verarbeitet werden soll, sondern verstehen, was dieser Datenpunkt im Fahrzeug bedeutet. Für den Kunden ist es attraktiv, wenn er nicht jede Schnittstelle zwischen mehreren Dienstleistern selbst im Detail spezifizieren muss. Er kann stärker beschreiben, welche Funktion er erreichen möchte, und wir entwickeln die durchgängige Lösung dafür.

Ist fehlendes Domänenwissen auch der Grund, warum häufig große Datenmengen gesammelt werden, ohne dass daraus ein konkreter Nutzen entsteht?

Ja. Lange hieß es, Daten seien das neue Gold. Deshalb wurden Daten gesammelt, ohne vorher immer genau zu klären, warum man sie benötigt. Man kann natürlich zunächst alles sammeln und später versuchen, darin etwas Wertvolles zu finden. Das verursacht aber erhebliche Kosten. Es ist nicht sinnvoll, sämtliche im Fahrzeug erzeugten Informationen dauerhaft zu übertragen und zu speichern. Wenn ich von Anfang an weiß, welche Daten relevant sind und was ich daraus ableiten möchte, kann ich die Lösung zielgerichteter aufbauen. Dann geht es nicht um möglichst viele Daten also Big Data, sondern um Smart Data. Dafür benötige ich Domänenwissen. Ich muss verstehen, welche Signale etwas über den konkreten Anwendungsfall aussagen und welche keinen zusätzlichen Nutzen bringen. Dadurch wird die Lösung effizienter und wirtschaftlich interessanter.

Auch bei einer gezielten Datenauswahl wächst das System mit der Flotte. Wo liegen die größten Herausforderungen, wenn aus einem gut beherrschbaren Pilotprojekt eine Anwendung für Hunderttausende oder gar Millionen Fahrzeuge wird?

Die grundsätzliche Skalierbarkeit ist heute deutlich einfacher als früher. In eigenen Rechenzentren musste für zusätzliche Kapazität physische Hardware beschafft und installiert werden. In der Cloud kümmern sich die Hyperscaler um einen großen Teil dieser grundlegenden Skalierung. Das bedeutet aber nicht, dass es keine Engpässe mehr gibt. In einem Proof of Concept lege ich bestimmte Bandbreiten, Datenmengen oder Nutzerzahlen zugrunde. Das funktioniert zunächst gut. Sobald die Lösung stark skaliert, kann an irgendeiner Stelle trotzdem ein Bottleneck entstehen. Das ist auch eine wirtschaftliche Frage. Ich kann nicht jede Komponente von Anfang an so auslegen, dass sie theoretisch unbegrenzt skaliert. Das wäre zu teuer. Ein einzelner Service kann deshalb irgendwann an seine Grenze kommen. Der Vorteil der Cloud besteht darin, dass das Betriebsteam zusätzliche Instanzen kurzfristig bereitstellen kann. Ein weiteres Thema sind die Zugriffszeiten auf große Datenmengen. Bei wenigen Datenpunkten sind Datenbankabfragen relativ einfach. Wenn ich Millionen oder Milliarden Datenpunkte speichere, muss die Architektur so aufgebaut sein, dass ich weiterhin effizient darauf zugreifen kann. Gerade wenn auf Basis dieser Daten wieder eine schnelle Reaktion im Fahrzeug ausgelöst werden soll, wird das relevant.

Merken Sie solche Engpässe erst, wenn sie auftreten, oder können Sie sie vorher erkennen?

Wir müssen proaktiv handeln. Selbst bei einem großen OEM kommen nicht an einem einzigen Tag plötzlich Zehntausende neue Fahrzeuge hinzu. Die Flotte wächst schrittweise. Über Dashboards und Monitoring sehen wir, wenn wir uns einer Grenze nähern. Dann können wir vorsorgen. Im Normalfall erreicht das Problem weder den OEM noch den Endkunden. Das Betriebsteam erkennt es im Hintergrund und erweitert die Kapazität rechtzeitig.

Fahrzeuge bleiben häufig 15 Jahre und länger im Einsatz, während sich Cloud-Dienste und Schnittstellen deutlich schneller verändern. Wie verhindern Sie, dass die Backend-Entwicklung dem Fahrzeuglebenszyklus davonläuft?

Das ist ein Thema, an dem man dauerhaft arbeiten muss. Ein großer Vorteil besteht heute darin, dass wir beide Seiten aktualisieren können. Natürlich entwickeln sich Cloud und Konnektivitätsstandards weiter. Gleichzeitig können wir aber auch auf der Fahrzeugseite über Firmware-Updates Anpassungen vornehmen. Trotzdem bleibt die Frage, wie lange alte Versionen und Schnittstellen unterstützt werden müssen. Bei europäischen OEMs und in vielen anderen etablierten Märkten wird stark darauf geachtet, dass Fahrzeuge 15, 20 oder noch mehr Jahre funktionieren. Wenn auf der Fahrzeugseite eine Anpassung notwendig wird, muss sie gegebenenfalls über ein Update vorgenommen werden. Das Problem ist nicht vollständig neu. Auch Navigationssysteme in älteren Fahrzeugen erhalten teilweise noch nach vielen Jahren Kartenupdates, obwohl sich die technische Infrastruktur im Hintergrund längst verändert hat.

Gibt es dabei Unterschiede zwischen europäischen und chinesischen Herstellern?

Ja, teilweise gibt es ein anderes Mindset. In China wird das Fahrzeug stärker wie ein schnelllebiges digitales Produkt betrachtet. Dort existiert zum Teil die Vorstellung, dass ein Fahrzeug für einige wenige Jahre funktioniert und anschließend durch eine neue Generation ersetzt wird – ähnlich wie bei einem Smartphone. In Europa würde dieser Ansatz nicht ohne Weiteres akzeptiert. Wer sich als chinesischer Hersteller langfristig im europäischen Markt etablieren möchte, muss berücksichtigen, dass Kunden hier eine deutlich längere Unterstützung erwarten. Die Hersteller müssen deshalb Schnittstellen über viele Jahre bereitstellen und mit Cloud-Anbietern arbeiten, die die Anforderungen des europäischen Marktes abdecken. Dabei können wir sie mit unserem Wissen über Automotive, Cloud und den europäischen Markt unterstützen.

Wenn Hersteller ihre Cloud-Strategie an unterschiedliche Märkte anpassen müssen, stellt sich auch die Frage nach der Wahl der Plattform. Sie arbeiten eng mit AWS zusammen, haben aber auch Erfahrung mit anderen Plattformen. Was empfehlen Sie Ihren Kunden: einen Anbieter oder mehrere?

Zunächst ist wichtig: Wir sind zwar AWS-Partner, arbeiten aber ebenso mit anderen Anbietern wie Microsoft Azure. Darüber hinaus gibt es die angekündigte Zusammenarbeit von Bosch mit Stackit, die Cloud der Schwarz Gruppe. Wir sind grundsätzlich unabhängig vom Cloud-Anbieter. Wenn ein Kunde einen bestimmten Hyperscaler vorgibt, können wir die Lösung auf dieser Plattform umsetzen. Wir haben mit verschiedenen Anbietern Erfahrungen gesammelt und können den Kunden bei der Auswahl beraten. Meine Empfehlung für ein neues Projekt ist allerdings klar: Am Anfang sollte ein Unternehmen bewusst einen Vendor-Lock-in eingehen.

Sie empfehlen also tatsächlich, sich zunächst eng an einen Anbieter zu binden?

Ja. Der Kostenvorteil ist am Anfang so groß, dass man ihn aus meiner Sicht nutzen sollte. Wenn ich von Anfang an vollständig unabhängig sein möchte, muss ich viele Dienste selbst entwickeln oder Drittanbieterprodukte verwenden, die auf mehreren Clouds laufen. Das verursacht erhebliche Kosten. Der sinnvollere Ansatz ist häufig der, den Softwareunternehmen und Start-ups seit Jahren verfolgen: Ich entscheide mich für einen Anbieter und nutze zunächst möglichst viel von dem, was er out of the box bereitstellt. Dadurch bin ich schnell am Markt und kann mich auf die Teile konzentrieren, mit denen ich mich gegenüber dem Wettbewerb differenziere. Ob mein Service, mein Konzept und mein Business Case funktionieren, weiß ich häufig erst nach ein oder zwei Jahren. Wenn das Produkt skaliert und wirtschaftlich erfolgreich ist, kann ich beginnen, die Abhängigkeit schrittweise zu reduzieren.

Angenommen, ein Kunde möchte später den Cloud-Anbieter wechseln: Kann er seine Anwendung einfach auf eine andere Plattform übertragen?

Nicht unbedingt von einem Tag auf den anderen. Eine Anwendung muss aber auch nicht vollständig neu gebaut werden. Cloud-Anwendungen sind ohnehin nie endgültig fertig. Es kommen Sicherheitsupdates, neue gesetzliche Anforderungen, Änderungen an Normen und zusätzliche Kundenanforderungen. Im Zuge dieses kontinuierlichen Refactorings kann ich einzelne Services unabhängiger gestalten. Ich muss nicht plötzlich die gesamte Anwendung auf einen anderen Hyperscaler umziehen oder vollständig cloudagnostisch machen. Ich kann nach und nach einzelne Teile aus der engen Bindung lösen. Zu diesem Zeitpunkt weiß ich außerdem bereits, dass der Service funktioniert und sich die Investition in mehr Unabhängigkeit wirtschaftlich lohnt.

Welche Frage sollten Ihre Kunden Ihnen eigentlich viel häufiger stellen?

Eigentlich fehlt mir häufig eine ganz grundlegende Frage, noch bevor es um Roadmaps, Lastenhefte oder die konkrete Technologie geht: Können wir nicht einfach einmal anfangen? Viele Kunden sind noch stark in der traditionellen Automotive-Welt verankert. Dort plant man ein großes Projekt über viele Jahre. Man definiert einen SOP in vier oder acht Jahren, entwickelt eine umfangreiche Roadmap und versucht, möglichst alles bereits vorher vollständig zu spezifizieren. Das hat früher besser funktioniert, weil sich die Welt während eines Entwicklungsprojekts nicht so schnell verändert hat. Heute kann ich nicht zuverlässig vorhersagen, welche Technologien in acht Jahren zur Verfügung stehen werden. Deshalb wünsche ich mir häufiger die Haltung: Lasst uns etwas bauen, es auf die Straße bringen, Erfahrungen sammeln und anschließend weiterentwickeln. Wir müssen in einen Modus kommen, in dem wir einen ersten Schritt gehen, Grenzen erkennen und die Lösung danach erweitern. Anders formuliert: Kunden sollten häufiger fragen: Könnt ihr uns helfen, gemeinsam etwas auszuprobieren?

Sind chinesische Anbieter bei dieser Arbeitsweise schneller?

Definitiv. Sie haben häufig eine ausgeprägte Builder-Mentalität. Sie fangen an und bauen etwas. Dabei entstehen teilweise technologisch sehr gute Lösungen. Es gibt aber auch Anwendungen, bei denen wir aus unserer Automotive-Entwicklungsperspektive aufgrund spezifischer Qualitäts- und Sicherheitsstandards andere Ansätze verfolgen und eine differenzierte Sichtweise einnehmen.Das ist die andere Seite des Pendels. Die Unternehmen haben aber zumindest etwas gebaut und können daraus lernen. Diese Geschwindigkeit und Umsetzungsorientierung macht die Zusammenarbeit sehr interessant.

Gibt es noch eine weitere Frage, die Kunden häufiger stellen sollten?

Ja. Gerade bei grundlegenden Technologie- und Plattformentscheidungen sollten Kunden häufiger nach unserer Erfahrung fragen. Besonders neue Hersteller oder Unternehmen mit Start-up-Charakter kommen teilweise mit einer bereits festgelegten Entscheidung zu uns. Sie wollen beispielsweise bestimmte Technologien und Frameworksnutzen, weil ihre Entwickler damit vertraut sind oder weil sie sich auf Basis eigener Recherchen dafür entschieden haben. Aus meiner Sicht wird die vorhandene Erfahrung spezialisierter Partner dabei zu wenig genutzt. Wir haben über viele Jahre mit unterschiedlichen Lösungsansätzen und Anbieterngearbeitet und können einschätzen, welches Setupzu welcher Projektphase und zu welcher Situation eines OEMs passt. Die Frage „Was würden Sie in unserer Situation empfehlen?“ würden wir deshalb gern häufiger hören.