Cloudbasierte Unternehmenstransformation bei der BMW Group

von Rostislav Markov, Carlos Antonio Perea Gomez, und Christos Dovas

Im Jahr 2020 gaben die BMW Group (BMW) und Amazon Web Services (AWS) eine strategische Zusammenarbeit[extern] bekannt, die darauf abzielte, das Innovationstempo bei BMW in allen Unternehmensprozessen zu beschleunigen, von der Fahrzeugentwicklung bis hin zu After-Sales-Services. Neben neuartigen Anwendungsfällen befasste sich die strategische Zusammenarbeit auch mit der cloudbasierten Transformation[EN] von Unternehmensanwendungen.

In diesem Blogbeitrag diskutieren wir sechs Schlüsselfaktoren, die BMWs cloudbasierte Transformation ermöglicht haben. Automobilhersteller können die hier beschriebenen Schlüsselfaktoren nutzen, um eine skalierbare Grundlage für ihre eigenen Cloud-Transformationsprogramme zu schaffen.

Schüsselfaktoren der Cloud-Transformation

Die Teams der BMW Group entwarfen eine sechsmonatige Migrations-Pilotphase [EN], die auf Unternehmensanwendungen in den Bereichen After-Sales, Ingenieurwesen und vernetzte Fahrzeuge abzielte. Die Pilotphase bewies, dass die Anwendungsteams der BMW Group ihre Anwendungen auf AWS modernisieren können. Es wurden erste Erfahrungen, Prozesse und Tools geschaffen, um nachfolgende Migrationen zu beschleunigen. Anschließend wendete BMW die Erkenntnisse und Schlüsselfaktoren aus der Pilotphase auf andere Geschäftsbereiche an. Die sechs sich herauskristallisierenden Schlüsselfaktoren entsprachen den Perspektiven des AWS Cloud Adoption Framework (AWS CAF). Sie wurden von funktionsübergreifenden Stakeholdern der BMW Group verantwortet. Die Schlüsselfaktoren und die dazugehörigen CAF-Perspektiven sind in Abbildung 1 unten zusammengefasst:

Abbildung 1: Schlüsselfaktoren auf dem Weg der cloudbasierten Transformation der BMW Group

Schlüsselfaktor 1: Teams um Produkte und Wertströme organisieren

Vor der Zusammenarbeit liefen die zentralen IT-Systeme bei BMW auf hochstandardisierter und kostenoptimierter Infrastruktur vor Ort. Es gab eine klare Aufgabentrennung zwischen Anwendungs- und IT-Infrastrukturteams (Abbildung 2). Um diese Grenzen zu überwinden, begann die Transformation der internen IT von BMW an der Spitze. Alle IT-Funktionen wurden auf Geschäftsprodukte ausgerichtet und trugen somit direkt zu einem spezifischen Geschäftsbedarf bei. Die daraus resultierenden BMW „BizDevSecOps“-Teams umfassen Teammitglieder aus den Bereichen Geschäft, Anwendungsentwicklung und IT-Betrieb. Diese Neuorganisation gibt den Teams mehr Autonomie und Entscheidungskraft und ermöglicht den Übergang zu einem produktbasierten Betriebsmodell[EN]. Diese Transformation[EN] hin zu Produktteams geht einher mit einem effektiven Supportmodell—unser nächster Schlüsselfaktor.

Abbildung 2: IT-Übergang der BMW Group von traditionellem Hosting zu einem produktorientierten Modell

Schlüsselfaktor 2: Ein effektives Supportmodell mit AWS und AWS-Partnernetzwerk aufbauen

Das AWS-Partnernetzwerk (APN) ist eine globale Gemeinschaft von Partnern, die AWS-Programme, Fachwissen und Ressourcen nutzen, um ihre Lösungen zu entwickeln, zu vermarkten und zu verkaufen. Nach einer Migrations-Pilotphase[EN] beauftragte die BMW Group fünf APN-Partner, um Support-Aktivitäten von allgemeinen Schulungen über Architekturberatung bis hin zu Migrationsunterstützung und verwalteten Plattformdiensten zu skalieren. Diese Support-Aktivitäten ermöglichten den Teams von BMW einen schnellen und einfachen Zugang zu spezialisierten Ressourcen. AWS arbeitete mit diesen Partnern zusammen, um fachliche Unterstützung durch AWS-Spezialisten zu bieten. Die Flexibilität, mehrere Partner zu haben, ermöglichte es BMW, die Partnerfähigkeiten für einen bestimmten Zeitraum zu nutzen, um das Change-Management und die neue Arbeitsweise voranzutreiben, ohne Geschwindigkeit und Stabilität kurzfristig zu beeinträchtigen. Das BMW Cloud Native Automation Team ist verantwortlich für die zentrale Bereitstellung der Cloud-Plattformarchitektur sowie von Schulungs- und Beratungsangeboten im Bereich Cloud für die BMW Group IT. Die Angebote zur Unterstützung von Cloud-Migrationen werden von den jeweiligen IT- oder Fachabteilungen in Auftrag gegeben, die für den betreffenden Anwendungsbereich verantwortlich sind. Diese Aufgabentrennung ermöglichte es den Teams der BMW Group, spezialisierte Unterstützung über die Organisation hinweg zu skalieren, als immer mehr Geschäftsanwendungen in die Cloud verlagert wurden. Abbildung 3 zeigt eine Übersicht über die Engagement-Bereiche der APN-Partner.

Abbildung 3: Support-Aktivitäten mit AWS APN-Partnern bei der BMW Group

Schlüsselfaktor 3: Cloud-Initiativen mit einer zukunftsorientierten Softwareentwicklungsplattform orchestrieren

In den anfänglichen Migrations-Pilotprojekten boten wir eine individuelle Rundumbetreuung an, bei der Geschäftsanwendungen gemeinsam mit den Anwendungsteams neu aufgebaut wurden. Ziel dieser Phase war es, Standards und wiederverwendbare Assets entlang verschiedener Migrationspfade zu entwickeln. Um die DevOps-Softwareentwicklung in den Folgephasen zu skalieren, bündelte das Cloud Native Automation Team die Referenzarchitekturen, wiederverwendbaren Assets und Playbooks im BMW Developer Portal. Dies beinhaltete:

• Self-Services für neue Projekte, einschließlich Kollaborationssoftware und AWS-Konten
• Entwicklungstools einschließlich CI/CD-Artefakte mit integrierten Tests zur Codequalität und Sicherheit
• Kodierte Bausteinvorlagen
• Betriebsintegrations-Assets, z. B. vordefinierte Monitoring-Dashboards (Abbildung 4)

Das “Self-Service” Model wurde durch folgende Elemente unterstützt:

• Vorab aufgezeichnete Lernmodule und technische „How-to“-Sessions
• Regelmäßige „Walk-in“-Sitzungen und
• Beratungsangebote wie bedarfsorientierte Architekturberatung im Bereich Cloud

Abbildung 4: Komponenten der DevOps-Softwareentwicklungsplattform der BMW Group

Das BMW Developer Portal entwickelte sich zu einem „One-Stop-Shop“ für Bausteine, die dabei helfen, den initialen Aufbau, z. B. von containerbasierten Anwendungen, zu beschleunigen.

Schlüsselfaktor 4: Einen nahtlosen Onboarding-Prozess für Teams etablieren, um den Cloud-Verbrauch zu vereinfachen

Als zentrales Team, das Migrationsunterstützung bietet, war es das Ziel des BMW Cloud Native Automation Teams, die Interaktionen mit den Anwendungsteams so reibungslos wie möglich zu gestalten. Erfolgreiche Engagements erforderten die Vereinfachung des Onboarding-Prozesses für die Anwendungsteams. Das Cloud Native Automation Team etablierte einen einfachen Prozess, der in sechs Schritten AWS-Ressourcen für Teams bereitstellte (siehe Abbildung 5 unten):

Abbildung 5: Cloud-Onboarding-Prozess für BMW-Teams

1. Festlegung der besten Zielarchitektur und des Landing Zone Designs (V1 AWS Design) durch eine Cloud-Architekturberatungssitzung.
2. Onboarding des Teams und des Anwendungsfalls auf neuen AWS-Konten über das Cloud Self Service Portal
3. Bereitstellung der CI/CD-Tools über die Selbstbedienungsmodule im BMW Developer Portal
4. Konfiguration der Bausteine, die die Zielarchitektur ermöglichen, über das BMW Developer Portal
5. Konfiguration der GitOps-Pipeline zur Bereitstellung der vorkonfigurierten AWS-Ressourcen

Schlüsselfaktor 5: Sicherheitseinhaltung in großem Maßstab mit wiederverwendbaren Infrastruktur-Code-Modulen aufrechterhalten

Im Rahmen der Migrations-Pilotphase[EN] von BMW kodierten wir die Cloud-Zielarchitekturen in wiederverwendbare Module. Diese Module bieten eine Vorlage dafür, wie die jeweilige Infrastrukturkomponente von der BMW Group sicher bereitgestellt werden kann. Die Wiederverwendbarkeit der Module reduzierte die Zeit bis zur ersten Bereitstellung auf eine Woche und beschleunigte die Lernkurve für Teams, die neu in der Cloud waren. Die Module bestehen aus Bereitstellungsvorlagen, die über eine zentrale Modul-Repository referenziert werden. Das Cloud Native Automation Team verwaltet den Konfigurationsstatus und veröffentlicht neue Versionen der Module. Anwendungsteams erstellen „Wrapper“-Skripte, die verschiedene Module enthalten, darunter eine GitOps-Pipeline für die Bereitstellung in mehrere Entwicklungsumgebungen. So werden automatisierte Bereitstellungen der Anwendungsinfrastruktur vom ersten Tag an ermöglicht. Das Design dieser Module wird in Abbildung 6 unten erläutert:

Abbildung 6: Konzeptionelles Design der wiederverwendbaren Infrastrukturmodule

Schlüsselfaktor 6: Cloud-Infrastruktur-Betriebsmodelle an das neue Geschäftsmodell anpassen

Um mit der organisatorischen Transformation hin zu BizDevSecOps Schritt zu halten und den verschiedenen Anwendungsarten, einschließlich Drittanbieter-Software, gerecht zu werden, adressierte die Migrations-Pilotphase Anwendungen mit stark verbreiteten Technologien (z. B. Java/Payara/Oracle). Die ersten Erfahrungen aus der Migrations-Pilotphase[EN] lehrten uns, dass es keine Allzwecklösung gab. Gemeinsame Muster ließen sich jedoch leicht auf die Reifegrade verschiedener Anwendungs-Teams und die von ihnen betriebenen Anwendungstypen übertragen. Heute unterscheidet und fördert das BMW Cloud Native Automation Team vier Ziel-Infrastrukturmodelle bei BMW. Abbildung 7 gibt einen Überblick über die Ziel-Infrastrukturmodelle und die zugehörigen Anwendungsfälle:

Abbildung 7: Cloudbasierte Zielinfrastrukturmodelle bei BMW

1. Umstellung auf Amazon Elastic Compute Cloud (Amazon EC2) für Anwendungs-Komponenten, die dedizierte virtuelle Maschinen (VM) erfordern, z. B. aufgrund spezifischer Lizenzanforderungen.
2. Containerisierte Anwendungen auf Amazon Elastic Kubernetes Service (Amazon EKS) und AWS Fargate: insbesondere für Anwendungsteams, die bereits die Standard-Webarchitekturen der BMW Group in Kombination mit Tools aus dem Kubernetes-Ökosystem verwenden.
3. Einfache Umstellung auf Container mit Amazon Elastic Container Service (Amazon ECS) und AWS Fargate, insbesondere wenn Teams keine Vorkenntnisse darüber haben, wie Anwendungen bereitgestellt oder Infrastrukturen verwaltet werden.
4. Umstellung auf funktionsbasierte Entwicklung für azyklische Workloads, die auf Anfrage oder im Batch-Betrieb arbeiten, unter Verwendung von AWS Lambda.

Geschäftsanwendungen werden auf eine container- und „serverless-first“ Strategie umgestellt, um den Verwaltungsaufwand zu reduzieren und den Übergang zur Produktteam-Verantwortung sowohl für Anwendungen als auch die zugehörige Infrastruktur zu ermöglichen. VM-basierte Migrationen stellten eine Ausnahme dar—für Anwendungsfälle, die in keines der beiden Paradigmen passen.

Fazit

Die strategische Zusammenarbeit[EXTERN] zwischen AWS und BMW zielte darauf ab, das Innovationstempo bei BMW in allen Unternehmensprozessen zu beschleunigen. Eines der Ergebnisse dieser Zusammenarbeit war die cloudbasierte Transformation[EN] von Unternehmensanwendungen. Mit vorkonfigurierten Bausteinen können Geschäftsverantwortliche bei BMW nun fundiertere Entscheidungen treffen, ohne mehrere Iterationen über mehrere Wochen hinweg durchführen zu müssen. DevOps-Teams bei der BMW Group können auf architektonische Grundlagen und wiederverwendbare Artefakte zurückgreifen, um ihre Microservices mit minimaler Reibung bereitzustellen.

BMW erzielte diesen Erfolg, indem es eine sechsmonatige Migrations-Pilotphase[EN] entwarf, die auf Unternehmensanwendungen in den Bereichen After-Sales, Engineering und Connected Car abzielte. Durch sechs Schlüsselfaktoren ebnete das Programm den Weg für Skalierbarkeit, sodass Hunderte von Anwendungsteams in den nachfolgenden Phasen profitieren konnten. Infolgedessen wechselten 2022 über 350 BMW-Anwendungen zu Containern auf AWS.

Wenn Sie bereit sind, Ihre eigene Migrations-Pilotphase zu starten, wenden Sie sich an AWS Professional Services, erkunden Sie die AWS Migration Competency Partner oder kontaktieren Sie einen AWS-Migrationsspezialisten.

Über die Autoren