SlideShare ist ein Scribd-Unternehmen logo
1 von 15
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
• 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
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 …
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
Lösungsansätze
Beispielhaftes Vorgehen und mögliche Arbeitspakete
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
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
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.
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
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
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
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
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
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
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

Weitere ähnliche Inhalte

Ähnlich wie Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ecosystems

Wiederholung Systementwurf - Einführung Build Prozesse
Wiederholung Systementwurf - Einführung Build ProzesseWiederholung Systementwurf - Einführung Build Prozesse
Wiederholung Systementwurf - Einführung Build Prozesse
Christian Baranowski
 
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
Aberla
 
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
FotiosKaramitsos
 

Ähnlich wie Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ecosystems (20)

Wiederholung Systementwurf - Einführung Build Prozesse
Wiederholung Systementwurf - Einführung Build ProzesseWiederholung Systementwurf - Einführung Build Prozesse
Wiederholung Systementwurf - Einführung Build Prozesse
 
Continuous Delivery as a Way of Life
Continuous Delivery as a Way of LifeContinuous Delivery as a Way of Life
Continuous Delivery as a Way of Life
 
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
 
AdminCamp2017 - ApplicationInsights
AdminCamp2017 - ApplicationInsightsAdminCamp2017 - ApplicationInsights
AdminCamp2017 - ApplicationInsights
 
02_Entwurf_Entwicklung_v7.0.pdf
02_Entwurf_Entwicklung_v7.0.pdf02_Entwurf_Entwicklung_v7.0.pdf
02_Entwurf_Entwicklung_v7.0.pdf
 
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
 
imatics FormEngine
imatics FormEngineimatics FormEngine
imatics FormEngine
 
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
 
2007 - Basta!: Nach soa kommt soc
2007 - Basta!: Nach soa kommt soc2007 - Basta!: Nach soa kommt soc
2007 - Basta!: Nach soa kommt soc
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
 
DNUG 2017 - ApplicationInsights
DNUG 2017 - ApplicationInsightsDNUG 2017 - ApplicationInsights
DNUG 2017 - ApplicationInsights
 
DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...
DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...
DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...
 
Chatbot Hackathon Slidedeck
Chatbot Hackathon SlidedeckChatbot Hackathon Slidedeck
Chatbot Hackathon Slidedeck
 
Automatisierungsmöglichkeiten beim Legacy-Reengineering - Andres Koch, Object...
Automatisierungsmöglichkeiten beim Legacy-Reengineering - Andres Koch, Object...Automatisierungsmöglichkeiten beim Legacy-Reengineering - Andres Koch, Object...
Automatisierungsmöglichkeiten beim Legacy-Reengineering - Andres Koch, Object...
 
Serverless Application Framework
Serverless Application FrameworkServerless Application Framework
Serverless Application Framework
 
Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...
Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...
Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...
 
CodeFluent Entities and AppSofa
CodeFluent Entities and AppSofaCodeFluent Entities and AppSofa
CodeFluent Entities and AppSofa
 
Industrie 4.0 Referenzmodell 2014
Industrie 4.0 Referenzmodell 2014Industrie 4.0 Referenzmodell 2014
Industrie 4.0 Referenzmodell 2014
 
IT-Ringvorlesung - Präsentation Comparex
IT-Ringvorlesung - Präsentation ComparexIT-Ringvorlesung - Präsentation Comparex
IT-Ringvorlesung - Präsentation Comparex
 
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
 

Microservice-Architektur-Prozess für Software-Plattformen und Microservice-Ecosystems

  • 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
  • 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