Moderne Software-Plattformen für innovative Geschäftsmodelle zielgerichtet und nachhaltig entwickeln

1. itegia GmbH
IT Consulting
Leopoldstraße 244
80807 München
Tel: +49 (0)89 2080 39 38 -0
Fax: +49 (0)89 2080 39 38 -9
kontakt@itegia.de
http://www.itegia.de
Microservice-Architektur-Prozess
für Software-Plattformen
und Microservice-Ecosystems
Moderne Software-Plattformen für
innovative Geschäftsmodelle
- zielgerichtet und nachhaltig entwickeln

2. • SmartHome, Elektromobilität, IoT und
Digitalisierung erfordert spezialisierte,
wachsende Software-Plattformen und Software-
“Ökosysteme“
• Hersteller und Plattformbetreiber benötigen
Plattformen für die Umsetzung innovativer
Dienste und die Integration unterschiedlicher
Dritt-Anbieter
• Für die evolutionäre Entwicklung und ein
geordnetes Wachstum dieser Plattform und der
Dienste muss eine tragfähige Zielarchitektur
etabliert werden
Ausgangssituation
Plattform
Service
1
Service
2
Service
3
App
Web
System-
API
3rd
Party 1
3rd
Party 2
3rd
Party …
Eine Software-Plattform ist eine
Drehscheibe für die Integration
unterschiedlichster Dienste

3. Ausgangssituation – Anforderungen an die Zielarchitektur
• Hohe Skalierbarkeit
• Hohe Flexibilität gegenüber neuen Diensten,
Drittanbietern und Features
• Hohe Agilität und kurze „time-to-market“-
Phasen, um hohes Innovations-Tempo zu
ermöglichen
• Offenheit für künftige, neue
Anwendungsgebiete
Grundlegende Anforderungen an Zielarchitektur
Plattform
Service
1
Service
2
Service
3
App
Web
System-
API
3rd
Party 1
3rd
Party 2
3rd
Party …

4. Ausgangssituation – Risiken einer fehlenden Zielarchitektur
• Einzel-Lösungen sind nicht konsistent
• Mehrfach-Implementierungen von
Basisfunktionen
• Heterogene Einzelservices ohne
einheitliche Verwaltungs- und
Monitoring-Schnittstellen
• Wachsende Komplexität
• Unklare Vorgaben für Erweiterung /
Ergänzung von Lösungen
Risiken
Aktuell existiert noch keine verbindliche Definition einer Zielarchitektur
( „Leitplanken“ für die Entwickler von Lösungen)
• Problematische Wartbarkeit und
Weiterentwicklung
• Erhöhte Entwicklungsaufwände
• Probleme bei künftigen Umstellungen
• Probleme bei Interoperabilität zwischen
Komponenten
• Herausforderungen in Bezug auf
Administration / Management der
Plattform
• Skalierung des Entwicklerteams wird
Problematisch (Know-how-Transfer
aufwendig / Abhängigkeiten zwischen
Komponenten)
• Potentiell schwer überschaubare
Sammlung aus Einzeldiensten ohne
übergeordnete Strukturierung
Impact

5. Lösungsansätze
Beispielhaftes Vorgehen und mögliche Arbeitspakete

6. Vorgehen Zielarchitektur / Architekturprozess
Die Zielarchitektur stellt ein Rahmen für die künftige Entwicklung dar. Ein
Architekturprozess hilft, diese koordiniert zu entwickeln
Analyse Ist-Architektur
Anforderungs-Analyse
Querschnittsthemen /
Zentrale Komponenten
Bestandsaufnahme
UseCases
Technische Architektur Fachliche Architektur
Bestandsaufnahme
Nachbarsysteme
Clustering UseCases
Fachliche
Architektursicht
Technische Architektur /
Integrations-Architektur
Technologie-Stack,
Entwicklungsvorgaben
Technische
Architektursicht
Zielarchitektur,
Rahmen für künftige Evolution
Bestandsaufnahme Ist-Situation
als Basis für evolutionäre Entwicklung
Verfeinerung, Ausarbeitung Zielbild

7. Architektur-Prozess: Ist-Analyse und Anforderungs-Analyse
• Bestandsaufnahme aktuelle Lösung und bestehende
Architektur- und Design-Konzepte
• Bestandsaufnahme aktueller und künftiger Anforderungen
Zielsetzung
• Sichtung bestehender Dokumenten und ggf. Code-Analyse
• Interviews mit Entwicklern, Architekten, Projektleitern
• Diskussion möglicher künftiger Einsatzszenarien und
resultierenden Anforderungen
• Ggf. Planung/Durchführung Workshop „Zukünftige Szenarien und
High-Level-Anforderungen“
• Herunterbrechen der High-Level-Anforderungen auf
Detailanforderungen / technische Anforderungen
Vorgehen
• Dokumentation Ist-Stand und bestehendes Zielbild (PPT)
• Dokumenten-Sammlung relevanter Projektdokumente
• Übersicht zukünftige Szenarien (PPT oder XLS)
• Liste Anforderungen (XLS)
Lieferobjekte
Analyse Ist-Architektur
Anforderungs-Analyse
Querschnittsthemen /
Zentrale Komponenten
Bestandsaufnahme
UseCases
Technische Architektur Fachliche Architektur
Bestandsaufnahme
Nachbarsysteme
Clustering UseCases
Fachliche
Architektursicht
Technische Architektur /
Integrations-Architektur
Technologie-Stack,
Entwicklungsvorgaben
Technische
Architektursicht
Die Zielarchitektur soll bestehende Anforderungen unterstützen und flexibel gegenüber
künftigen Anforderungen sein

8. Architektur-Prozess: Querschnittsthemen, Zentrale Komponenten
• Identifikation und Konkretisierung zentraler Funktionen und
Komponenten
Zielsetzung
• Katalog notwendiger technischer Basisfunktionen/-komponenten
aus vergleichbaren Projekten
• Erarbeitung fachlicher Basisfunktionen/-komponenten auf Basis
der bekannten UseCases
• Workshop mit Architekten/Entwicklern
Vorgehen
• Architekturgrafik: Basis-Funktionen und Basis-Komponenten inkl.
Beschreibung (PPT)
Lieferobjekte
Analyse Ist-Architektur
Anforderungs-Analyse
Querschnittsthemen /
Zentrale Komponenten
Bestandsaufnahme
UseCases
Technische Architektur Fachliche Architektur
Bestandsaufnahme
Nachbarsysteme
Clustering UseCases
Fachliche
Architektursicht
Technische Architektur /
Integrations-Architektur
Technologie-Stack,
Entwicklungsvorgaben
Technische
Architektursicht
Begriffsklärung
Basis-Komponente: Zentraler Dienst, der von den Microservices
über Schnittstellen verwendet wird, Beispiel „Key-Management“
Basis-Funktion: Erforderliche Funktionalität, die in jeden
Microservice eingebettet werden muss, Beispiel „Logging“
Die Zielarchitektur bietet den Rahmen der künftigen Lösungen und stellt Standard-
Funktionalität und die Infrastruktur zur Verfügung.

9. Architektur-Prozess: Querschnittsthemen, Zentrale
Komponenten
Technische Basisfunktionalitäten sind Querschnittsdienste, die von den
Microservices generell verwendet werden.
Beispiele:
Basisdienste Analyse Ist-Architektur
Anforderungs-Analyse
Querschnittsthemen /
Zentrale Komponenten
Bestandsaufnahme
UseCases
Technische Architektur Fachliche Architektur
Bestandsaufnahme
Nachbarsysteme
Clustering UseCases
Fachliche
Architektursicht
Technische Architektur /
Integrations-Architektur
Technologie-Stack,
Entwicklungsvorgaben
Technische
Architektursicht
Basiskomponenten sind zentrale Dienste, die von unterschiedlichen
Lösungen/UseCases gleichermaßen verwendet werden.
Basiskomponenten
• Service Discovery
• Kommunikation und asynchroner
Datenaustausch
• Verschlüsselung / Sicherer
Datenaustausch
• Datenhaltung
• Logging
• Konfiguration
• Administrations-Schnittstellen
• Monitoring-Schnittstellen
• Access-Control
Beispiele technische Komponenten
• Service Discovery / Load-Balancing
• Big Data / Analytics
• Streaming / Contineous Data
Beispiele fachliche Komponenten
• User-/Identity-Management
• Vehicle-Management
• Key- und Certificate-Management
• Payment / Store

10. Architektur-Prozess: Technische Architektur & Vorgaben
• Spezifikation der technischen Zielarchitektur
• Konkretisierung der Zielarchitektur mit Fokus „Entwickler
Microservices“
Zielsetzung
• Ausarbeitung der technischen Architektur. Insbesondere:
– Anatomie von Microservices, Blueprint Standard-Service
– Schichtung, APIs
– Darstellung UI-Integration
– Skalierung/Clustering/Laufzeit-Sicht
– Bei Bedarf: Darstellung der Lösungsmuster für Standard-Themen wie
Sichere Kommunikation, Authentifizierung, Asynchrone
Kommunikation, Logging/Tracking für Big Data Analyse, ….
• Definition Technologie-Stack: Vorgabe Libraries / Versionen
• Erstellung bzw. Erweiterung Entwicklerrichtlinien
– Vorgaben Aufbau Microservices
– Vorgaben für die Verwendung von Basisdiensten und -komponenten
– Lösungsmuster für Standard-Themen (siehe Technische Architektur)
– Code-Beispiele, Referenzimplementierungen
Vorgehen
• Architekturgrafik: Basis-Dienste
und Basis-Komponenten inkl.
Beschreibung (PPT)
• Dokument Entwicklerrichtlinien
(Word, Confluence o.ä.)
Lieferobjekte
Analyse Ist-Architektur
Anforderungs-Analyse
Querschnittsthemen /
Zentrale Komponenten
Bestandsaufnahme
UseCases
Technische Architektur Fachliche Architektur
Bestandsaufnahme
Nachbarsysteme
Clustering UseCases
Fachliche
Architektursicht
Technische Architektur /
Integrations-Architektur
Technologie-Stack,
Entwicklungsvorgaben
Technische
Architektursicht
Die technische Architektur definiert, wie neue Services implementiert werden zur
Sicherstellung einer einheitlichen, wartbaren und operativen Lösung

11. Architektur-Prozess: Bestandsaufnahme Use-Cases & Nachbarsysteme
• Dokumentation bestehende fachliche Architektur
Zielsetzung
• Ausarbeitung der Ergebnisse aus der Anforderungs-Analyse
• Verfeinerung konkreter UseCases
• Ausarbeitung weiterer, denkbarer UseCases
• Identifikation von aktuellen und künftigen Nachbarsystemen
(interne BMW-Systeme und Drittanbieter-APIs)
Vorgehen
• Kurzbeschreibung UseCases inkl. Verfeinerung (XLS oder PPT)
Lieferobjekte
Analyse Ist-Architektur
Anforderungs-Analyse
Querschnittsthemen /
Zentrale Komponenten
Bestandsaufnahme
UseCases
Technische Architektur Fachliche Architektur
Bestandsaufnahme
Nachbarsysteme
Clustering UseCases
Fachliche
Architektursicht
Technische Architektur /
Integrations-Architektur
Technologie-Stack,
Entwicklungsvorgaben
Technische
Architektursicht
Die UseCases und zu Integrierenden Systeme stellen die Basis der fachlichen
Architektursicht dar

12. Architektur-Prozess: Clustering UseCases
• Definition von fachlichen Komponenten
Zielsetzung
• Clustering der UseCases in Anwendungsgruppen (z.B.
Ladesteuerung, Energiemanagement, Querschnittsdienste, …)
• Spezifikation der Teil-Komponenten dieser Cluster
• Klassifikation der Komponenten. Beispiel:
– Adapter (Komponenten zur Integration von Drittsystemen)
– Atomare UseCases (Prozesse betreffen nur einen Baustein, eine
Komponente)
– Prozess UseCases (Prozesse sind komponenten-übergreifend)
Vorgehen
• Fachliche Architektur-Sicht (siehe Beispiel nächste Seite)
Lieferobjekte
Analyse Ist-Architektur
Anforderungs-Analyse
Querschnittsthemen /
Zentrale Komponenten
Bestandsaufnahme
UseCases
Technische Architektur Fachliche Architektur
Bestandsaufnahme
Nachbarsysteme
Clustering UseCases
Fachliche
Architektursicht
Technische Architektur /
Integrations-Architektur
Technologie-Stack,
Entwicklungsvorgaben
Technische
Architektursicht
Durch ein Clustering der UseCases ergeben sich sinnvolle fachliche Komponenten und
entsprechende Erweiterungspunkte für den künftigen Ausbau

13. Beispielhafte Referenzarchitektur, fachliche Sicht
Lade
Management
Energie-
Management
…
Basis-/Querschnittskomponenten
Fachliche Komponenten / Lösung
Externe Systeme, Inbound API
Connected
Drive
User-Portals
&Apps
3rd-Party
InboundAPIs
Home
Automatizati
on,SmartTV,
…
…
Dashboards
Interne Systeme
Dashboards
Dashboards
Administration
VehicleData
System
Service Discovery
Streaming, Contineous
Data
Big Data / Analytics
External API Management
Logging
Administration,
Configuration
…
Externe Systeme, Outbound API
Zentrale Komponenten
Vehicle
Management
User
Management
Key-
/Certificate-
Management
Payment / Store
…
…
…
Lade-Infrastruktur
Ladesäulen-
Betreiber1
Ladesäulen-
Betreibern
…
IoT/Home-Automatisierung
NEST
Tado
… …
Die fachliche Sicht liefert einen Überblick über die Komponenten und definiert
Erweiterungspunkte für neue Funktionalitäten / Lösungen
Legende
ErweiterungpunktE
E
EE E
E

14. Beispielhafte Referenzarchitektur, technische Sicht
Atomare
UseCases
… …
Adapter
Lademanagement
Prozess
UseCases
…
Lade-
säulen
NEST
Tado
…
IoT Home
Lade-
säulen
…
Externe
Systeme
Communication Layer (e.g. REST, MQTT), Identity-, Access-, Session-Management
… …
ConnectedDrive
User-Portals&Apps
3rd-PartyInboundAPIs
Service Discovery
Zentrale Dienste
Key-/Certificate
Management
Streaming, Contineous
Data
Big Data / Analytics
External API Management
Legende
Micro-Service
Komponenten-Cluster
Logging
Administration,
Configuration
…
HomeAutomatization,
SmartTV,…
…
…
Interne Frontends
Dashboards
AdministrationFrontends
User-,Vehicle-,Key-
Management
VehicleData
Interne
Schnittstellen
…
Diese technische Sicht definiert das Innenleben der Komponenten. Weitere Sichten sind
je nach Fragestellung erforderlich

15. Vielen Dank für Ihr Interesse
Kontaktieren Sie uns, wenn Sie
Bedarf an Unterstützung in
Architektur-Themen haben
Kontakt und Ansprechpartner
ITEGIA GmbH
Leopoldstrasse 244
D-80807 München
Tel: 089 / 2080 3938-0
Fax: 089 / 2080 3938-9
Web: http://www.itegia.de
Email: kontakt@itegia.de
Ansprechpartner
Peter Schrey
Geschäftsführer
Mobile: 0173 - 2 777 802
Email: peter.schrey@itegia.de