Als Google noch hauptsächlich Suchmaschinenanbieter war und Apple vor allem Hersteller von Büro- und Unterhaltungselektronik, wäre niemand auf die Idee gekommen, dass diese Unternehmen die klassischen Autobauer einmal herausfordern könnten. Und doch: Google, Apple & Co. erobern Marktanteile mit IT-Geräten und -Lösungen, heute bei Connected-Car-Anwendungen und morgen wahrscheinlich mit kompletten Fahrzeugen. Da ihre IT-Entwicklung um Längen schneller und flexibler ist, verfügen sie über einen maßgeblichen Startvorteil. Das wissen auch die Automobilkonzerne, die deshalb in Sachen IT nun in die Offensive gehen. Zum Beispiel mithilfe von „Devops“.
Devops (kurz für: Development & Operations) erweitert den Ansatz der agilen Software-Entwicklung um den Betrieb. Zwar brachte „Agile“ ein großes Plus an Schnelligkeit, Flexibilität und Kundenorientierung in die Software-Entwicklung. Doch ihre eigentliche Bewährungsprobe bestehen auch die agil entwickelten Software-Produkte erst, wenn sie in Produktion gehen und der Markt über ihre Akzeptanz entscheidet. Wenn dieses Feedback allerdings nur zwei- oder dreimal im Jahr erfolgt, ist die während der Entwicklung gewonnene Geschwindigkeit und Kundennähe schon wieder dahin. Diese Erkenntnis führte zum Entstehen des Devops-Ansatzes, der neben der Entwicklung auch den Betrieb „agilisiert“.
Software-Updates jeden Tag
Bei Automobilherstellern und ihren Zulieferern ist es üblich, dass es pro Jahr nur wenige, dafür aber umfangreiche Software-Releases gibt. Devops zielt auf die radikale Verkürzung dieser Zyklen: etwa ein Update jeden Tag. Kommt eine Funktion am Markt nicht an, kann sie so am Folgetag einfach wieder abgeschaltet werden. Umgekehrt lassen sich Produktideen Schritt für Schritt erweitern, wenn sie bei den Anwendern auf Begeisterung stoßen: von der Idee in die Produktion innerhalb von 24 Stunden und dies dann durchaus auch mehrmals täglich. Dass diese kurzen Zyklen möglich sind, zeigen zahlreiche Unternehmen wie zum Beispiel Google, Apple oder Amazon, die es zum Teil sogar auf mehrere Tausend Software-Releases pro Tag bringen.
Wegen solcher Erfolgsgeschichten nimmt der Devops-Zug derzeit rasant Fahrt auf. Gestartet als Technologie, entwickelt sich Devops zu einer umfassend neuen Philosophie für die gesamte IT. Beispiel IT-Sicherheit: Was nützen agile Entwicklung und Betrieb, wenn die Sicherheitsrichtlinien noch dem altbekannten Wasserfallmodell folgen und sich Sicherheitslücken erst nach Wochen oder Monaten schließen lassen? Demgegenüber erlauben es tägliche Software-Updates, Sicherheits-Patches zeitnah bereitzustellen. Dementsprechend muss die gesamte IT agil werden.
Doch von welcher IT sprechen wir überhaupt in der Automobilindustrie? Grundsätzlich gibt es drei große Anwendungsgebiete:
- Fahrzeuggebundene IT-Applikationen wie Embedded Systems oder Connected-Car-Funktionen, die im Rahmen von Product Lifecycle Management (PLM) entwickelt werden.
- IT-Applikationen, die sich um die Autokunden drehen, wie zum Beispiel Verkauf, Aftersales, Customer Relationship Management (CRM) etc.
- Unternehmensanwendungen für Buchhaltung, Controlling, Personal etc.
Bedarf und Marktdruck für den agilen Devops-Ansatz betreffen vor allem die ersten beiden Anwendungsgebiete. Studien zeigen regelmäßig, dass agile Methoden (nicht nur) in der Autoindustrie zunächst bei der Weiterentwicklung des CRM Einzug gehalten haben, zu inzwischen fast 100 Prozent. Die Durchdringung bei PLM und Engineering liegt bei rund 40 bis 50 Prozent. Bei den Unternehmensanwendungen, die zumeist Standardprodukte sind, geht der Trend immer mehr zu Cloud-Lösungen, die ebenfalls immer schneller immer mehr neue Funktionen zu den Anwendern bringen.
Software-Update statt Rückruf
Die größte Herausforderung stellt sich natürlich bei allen fahrzeuggebundenen Produkten. Nehmen Autohersteller Devops ernst, finden sie sich mehr und mehr in der Position von Smartphone- und Mobile-App-Herstellern. Funktionen sind nicht einmal und dauerhaft verbaut, bis das Auto verschrottet wird, sondern befinden sich im ständigen (Update-) Fluss. Und wie es bei mobilen Endgeräten Hunderte bis Tausende verschiedene Endgeräteversionen gibt, sind auch bei Autos die unterschiedlichsten Modelle und Baujahre auf den Straßen unterwegs. Die Software-Plattformen in den Fahrzeugen müssen also grundlegend umgebaut werden, was praktisch nur mithilfe von Devops geht, dessen Ziel es ja ist, eine Flexibilität zu erreichen, mit der Updates schnell und reibungslos in Betrieb gehen können. Schließlich kann man nicht für jedes Software-Update eine Rückrufaktion starten.
IT-Architektur auf dem Prüfstand
Die Einführung von Devops besteht nicht nur aus der Einführung neuer Prozesse, sondern erfordert auch einen grundlegenden Umbau der generellen Software-Architektur. Wenn zum Beispiel die Marketing-Systeme auch auf eine alte Datenbank mit Ersatzteilen zurückgreifen, reicht es nicht, agile Devops-Prozesse nur im Marketing einzuführen. Zusätzlich gilt es auch, die bereits bestehenden Schnittstellen neu zu definieren. Auch ergibt Devops keinen Sinn, wenn zum Beispiel die Infrastrukturabteilung sechs Monate benötigt, um einen neuen Server zu implementieren.
Doch wie erreichen Unternehmen eine solche Beschleunigung auf breiter Front? Devops führt letztlich das Konzept der hybriden Cloud ins Unternehmen ein, also eine flexible Mischung aus Public Cloud, Private Cloud und traditioneller IT-Umgebung. Dabei entscheiden vor allem die Marktanforderungen und die Geschäftsrelevanz einzelner Anwendungen, welche dieser drei Domänen zum Einsatz kommt. Die Binnensicht der IT wird somit durch die Perspektive des Marktes abgelöst. Die Automobilindustrie hat dabei einen Vorteil gegenüber anderen Branchen, da sie im Bereich der klassischen Produktion bereits Kanban und ähnliche Prinzipien eingeführt hat. Die Frage lautet: „Wie kann ich Produkt-Features aus der Nachfrage am Markt ableiten?“ und nicht mehr „Was plane ich für die kommenden sechs Monate?“. Nun gilt es, diese Prinzipien aus der (Fahrzeug-)Produktion in die IT zu überführen.
Die Automobilindustrie hat es geschafft, Lagerzeiten für Einzelkomponenten drastisch zu reduzieren und am Markt auszurichten. Dies steht nun auch in der IT-Produktion an, wo jeder halbfertige Programm-Code zu den software-technischen Lagerbeständen zu rechnen ist. Für die Fortdauer der weiteren Entwicklungsarbeit wirken dann auch aufseiten der IT dieselben (Kosten-) Gesetzmäßigkeiten, wie sie aus der Welt der halbfertigen Industrieerzeugnisse hinlänglich bekannt sind. Mehr und mehr Software-Entwicklungsbereiche erkennen nun, dass sie diese Wirkprinzipien erst dann in den Griff bekommen, wenn sie ihre Architekturen modularisieren. Vor diesem Hintergrund bieten sich vor allem die sogenannten „Greenfield“-Bereiche für Pilotprojekte an. Bereiche also, wo die Software noch relativ frisch und ihre Komplexität überschaubar ist. Eine weitere Strategie zielt auf Zukäufe oder Kooperationen ab. So engagierte sich zum Beispiel General Motors mit 500 Millionen Dollar beim Fahrtenvermittler Lyft, Audi ist mit dem US-Mietwagen-Start-up Silverstone im Gespräch, und in Deutschland haben sich Daimler, Audi und BMW zu einer außergewöhnlichen Allianz zusammengetan, um den Kartendienst Here zu übernehmen. Diese Komponenten gilt es nun nahtlos in die vorhandenen Plattformen einzubinden.
Vom Hype zur Realität
Wie bei allen anderen Hypes haben sich auch bei Devops in Windeseile zahlreiche Anbieter in Stellung gebracht, die Devops fast immer „as a service“ anbieten. So argumentieren Hardware-Hersteller damit, dass ihre Hardware-Lösungen Devops erst ermöglichen. Die Systemintegratoren betonen, dass sie bereits breite Erfahrung mit „Agile“ haben und deshalb prädestiniert für Devops seien. Und aus ihrer Sicht haben sie auch sicher alle Recht. Doch die Anbieter selbst sind nicht die derzeitige Herausforderung der Autokonzerne. Diese müssen erst einmal Fragen wie die folgenden beantworten: „Was bedeuten die Prinzipien von Devops für meine Organisation?“, „Was muss ich als erstes ändern?“ oder „Was bedeutet eigentlich der Begriff ‚Gewerk‘ in der Devops-Welt?“. Erst wenn solche grundlegenden Fragen beantwortet sind, sollten die Konzerne an die bereits bestehenden sowie neue Software-Partner denken und SLAs, Verträge sowie Preismodelle an Devops anpassen.
Denn ungeachtet all der Vorteile die Devops mit sich bringt, darf das Vorgehen nicht als Allheilmittel betrachtet werden. Vor dem Einsatz sollte natürlich auch bei Devops die Analyse stehen: In welchen Einsatzgebieten ergibt Devops grundsätzlich Sinn, in welchen nicht? Für eine extrem sicherheitskritische Steuerungssoftware wohl weniger, für eine Entertainment-App hingegen mehr. Auch ist abzuschätzen, ob und wie weit die Implementierung von Devops zu einem positiven Return on Investment führt. Die Erfahrung zeigt, dass dieser bei innovativen Systemen wesentlich größer ausfällt als bei Bestandsanwendungen.
All diese Umstellungen funktionieren sicher auch besser, wenn die Unternehmen den Langfristnutzen im Blick behalten, den sie mit ihren Reformen erzielen. So wird die damit verbundene steigende Transparenz auch operationale Risiken deutlicher machen. Mehr und mehr automatisieren sich Prozesse in Entwicklung und Vertrieb, sodass sich schnell die Frage stellt, ob auch die IT-Zulieferer für diese Automatisierung Verantwortung übernehmen sollen. Insofern stellt Devops fast das gesamte derzeitige IT-Sourcing-Konzept auf den Prüfstand. All dies mithilfe externer Sourcing-Berater neu zu sortieren und an den eigenen Geschäftszielen auszurichten, sollte deshalb am Beginn einer jeden Devops-Initiative stehen.
Da die ersten Erfahrungen vorliegen, lassen sich bereits heute einige Aussagen über die wichtigsten Erfolgsfaktoren und generelle Trends treffen:
- Die Total Cost of Ownership wird transparenter, da Design, Entwicklung und Betrieb von Software enger miteinander verzahnt werden und so einen ganzheitlicheren Blick ermöglichen.
- Die Bedeutung von „Technical Debt“ steigt. So werden Software-Anbieter nicht mehr nur für eine funktionale Software sorgen müssen, sondern auch für eine, die sich schnell, einfach und kostengünstig anpassen lässt.
- Die Änderungsfrequenz innerhalb der IT nimmt zu, ohne dass die Qualität leidet.
- Nicht jede Software ändert sich in der gleichen Geschwindigkeit. In größeren Konzernen wird es mehrere Hundert verschiedene „Software-Geschwindigkeiten“ geben, die entsprechend unterschiedlich gemanagt werden müssen. Es gibt nicht nur – wie zum Beispiel Gartner behauptet – eine schnelle und langsame IT, sondern unzählige Abstufungen.
- Devops sieht in jeder Branche mit ihren spezifischen Geschäftsmodellen immer anders aus. Entsprechende Anforderungsanalysen sind deshalb unabdingbar.
- Nicht nur die IT-Anbieter selbst sollten das Devops-Vorgehen eines Unternehmens definieren. Vielmehr benötigt es zusätzlich einen unabhängigen Dritten, der den gesamten Sourcing-Mix unter Devops-Gesichtspunkten im Blick behält. Nur so kann aus dem Hype auch Wirklichkeit werden.
- Dieser unabhängige Dritte muss in der Lage sein, all das Sprechen der externen Anbieter von Technologie und Prozessen in konkreten Business-Nutzen zu übersetzen.
- Stimmt der Provider-Mix und das zugrunde liegende Sourcing-Modell, müssen Unternehmen Devops-Experten und ihr Wissen nicht unbedingt komplett einkaufen, sondern können dies von ihren Dienstleistern beziehen. Wenn der erwartete Nutzen klar vereinbart ist, kann sich die Automobil-IT auf die Rolle des Technologie-Brokers konzentrieren, anstatt ständig eigenes Know-how und neue Mitarbeiter aufbauen zu müssen.
Prashant Kelker ist Director bei der ISG Information Services Group Germany in Frankfurt/Main
Dieser Text entstand in Anlehnung an den Beitrag „Updates für die Automobilindustrie“ in der Automobil Industrie, Nr. 6 vom 9. Juni 2016.