Softwarearchitekten und Softwarearchitekturen. Technik <-> Mensch <-> Organisation

Transkript

1 Softwarearchitekten und Softwarearchitekturen Technik <-> Mensch <-> Organisation

2 Agenda Definition von Softwarearchitektur Softwarearchitekt Architekturentwurf Dokumentation Architekturpattern Agenda 1/1

3 Definition Softwarearchitektur Eine Softwarearchitektur besteht aus: Zerlegung des Problems in kleinere, verständliche und beherrschbare Komponenten Komponenten, deren Beziehungen zueinander und zur Umgebung Grundsätze, die Design und Entwicklung des Systems bestimmen Definition Softwarearchitektur 1/3

4 Definition Komponente Baustein eines Systems Kapselt ihr inneres Verhalten Kommuniziert mit anderen Komponenten über definierte Schnittstellen Ist wieder verwendbar und austauschbar Definition Softwarearchitektur 2/3

5

6 Softwarearchitekt -Ausbildung SEI (Software Engineering Institute) SOA, Architecture, ATAM The Open Group: TOGAF Zachman: Certified Enterprise Architect Oracle Certified Java EE 6 isaqb e.v. Softwarearchitekt 1/13

7 Aufgaben des Softwarearchitekten Anforderungen und Randbedingungen klären System strukturieren Systemzerlegung Bausteinstruktur Schnittstellen Übergreifende technische Konzepte erarbeiten / beschließen Dokumentieren und kommunizieren Softwarearchitekt 2/13

8 Nutzen und Ziele Bindeglied zwischen Analyse und Umsetzung Analyse Architekturentwurf Umsetzung Bauplan des Systems Verständlichkeit und Sicherheit schaffen Flexibilität und Effizienz gewährleisten Qualität garantieren, Risiken erkennen Softwarearchitekt 3/13

9 Stakeholder <-> Architekt Softwarearchitekt 4/13

10 Beziehungen: Architekt -Projektleitung Risikoüberwachung und Eskalation Entscheidungskompetenz für Entwurfsentscheidungen Auswahl und Beurteilung der techn. Fähigkeiten von Bewerbern und Mitarbeitern Auswahl von Tools und Technologien Organisation des Entwicklerteams entsprechend des Architekturentwurfs Softwarearchitekt 5/13

11 Beziehungen: Architekt Req. Engineer Festlegung der Anforderungen und Rahmenbedingungen Zusammenführung unterschiedlicher oder widersprüchlicher Interessen Kompromissfindung: Funktionale, nichtfunktionale Softwarearchitekt 6/13

12 Beziehungen: Architekt -Auftraggeber Verbreitung und Akzeptanz der Systemvision Einschränkungen und Vorgaben und Wünsche berücksichtigen Rückmeldungen einholen Softwarearchitekt 7/13

13 Beziehung Architekt -Entwickler Verbreitung der Akzeptanz der Architektur Training und Beratung des Entwicklerteams in den ausgewählten Werkzeugen und Technologien Moderation und Koordination an den Schnittstellen Durchsetzung der Architekturvorgaben Einholen von Rückmeldungen Softwarearchitekt 8/13

14 Beziehung Architekt QS / Tester Festlegung der Testinfrastruktur Sicherstellung einer Mindestqualität Festlegung des Qualitätsmerkmale Übergabe der Komponenten an die QS Unterstützung und Zusammenarbeit bei White-Box Tests Softwarearchitekt 9/13

15 Beziehung Architekt -Betrieb Sicherstellung der Betreibbarkeit Festlegung der Hardwareanforderungen Einschränkungen und Anforderungen festhalten und berücksichtigen Anforderung an SLA definieren Softwarearchitekt 10/13

16 Softwarearchitekt 11/13

17 Architekten im modernen Umfeld -Risiken Elfenbeinturm Risiken : Die Architektur kann nur aufwendig umgesetzt werden Die Architektur hat mit der Realität nichts zu tun Die Entwickler fühlen sich entmündigt Das Entwicklungsteam gestaltet die Architektur Risiken : Keiner fühlt sich verantwortlich Das erste was dem Team einfällt wird umgesetzt Architektur nach dem Prinzip : das haben schon immer so gemacht Keine einheitliche Architektur Softwarearchitekt 12/13

18 Architektur Best Practise Architekturen im Team entwickeln Alle Stakeholder einbinden und mitwirken lassen Architekturen iterativ entwickeln Komplexe Strukturen und große Risiken durch Szenarien und Prototypen absichern Softwarearchitekt 13/13

19 Architekturentwurf Anforderungen und Einflussfaktoren klären Architektur bewerten Risiken identifizieren Umsetzung begleiten Strukturen und technische Konzepte entwerfen Architektur kommunizieren Architekturentwurf 1/18

20 Beispiel Modul Artikel Stelle die Ressource Artikel, die im ERP System gepflegt wird anderen Systemen insbesondere Smart Sales (Verkauf) und Helios (Planung) zur Verfügung Sorge für den Import von Stücklisten (verkaufte oder verplante Artikel) in das ERP System Das System muss in vier Monaten fertig sein Architekturentwurf 2/18

21 Stakeholder Abteilungsleiter Projektleiter Requirement Engineer Verschiedene Fachabteilungen Externer ERP Dienstleister Architekturboard Team Architekturentwurf 3/18

22 Einflussfaktoren Das System muss in vier Monaten fertig sein Es soll ein Modul der Integrationsplattform Doris werden Das Zielsystem Smart Sales wird parallel entwickelt, die Schnittstelle kann sich hier ändern Das Quellsystem ERP wird ebenso parallel entwickelt. Evtl. haben die Entwickler zu wenig Zeit um sich um die Anpassungen zu kümmern Die Zusammenarbeit mit dem externen Dienstleister muss noch etabliert werden Architekturentwurf 4/18

23 Risiken Anforderungen teilweise unklar Kleines Team Hoher Zeitdruck Zielsystem wird noch entwickelt Verfügbarkeit des externen Dienstleiters unklar Es fehlt Erfahrung mit neu eingesetzten Techniken Architekturentwurf 5/18

24 Softwareentwurf Anforderungen und Einflussfaktoren klären Architektur bewerten Risiken identifizieren Umsetzung begleiten Strukturen und technische Konzepte entwerfen Architektur kommunizieren Architekturentwurf 6/18

25 Vorgehen beim Entwurf Kernaufgabe kurz beschreiben und mit den Stakeholdern abstimmen Folgende Fragen klären: Wer nutzt das System? Wie wird das System genutzt? Welche Schnittstellen gibt es? Welche Daten werden verwaltet? Wie wird das System gesteuert? Systemidee entwickeln und abstimmen Architekturentwurf 7/18

26 Beispiel Modul Artikel Anwender: Anlagenplaner, Vertrieb, Einkäufer, Projektverwalter Schnittstellen zu Dynamic AX, Smart Sales, Design System Daten: Artikel, Stückliste Integration des Modul in die Integrationsplattform Doris RESTFul Excel Import, Export Aufruf von den angeschlossenen Systemen, offline und manuell Architekturentwurf 8/18

27

28 Softwarearchitektur iterativ entwickeln Einflussfaktoren Anforderungen beeinflussen Architekturentwurf ändert ändert Umwelt & Projektbeteiligte Kunde Architekturentwurf 10/18

29 Grundlegende Konzepte Einfachheit So einfach wie möglich So komplex wie nötig Entwurf nach Verantwortlichkeiten Trennung von Technik und Fachlichkeit Modularität Konzentration auf Schnittstellen Berücksichtigung von Fehlern Architekturentwurf 11/18

30 Qualität Manager und Auftraggeber Kosteneffizienz Flexibilität Wartbarkeit Anwender Hohe Performance Einfache Benutzbarkeit Projektleiter Parallelisierbarkeit Gute Testbarkeit Architekturentwurf 12/18

31 Qualitätsmerkmale Funktionalität Angemessenheit Richtigkeit Zuverlässigkeit Fehlertoleranz Reife Benutzbarkeit Verständlichkeit Erlernbarkeit Architekturentwurf 13/18

32 Qualitätsmerkmale Fortsetzung Effizienz Zeitverhalten Verbrauchsverhalten Änderbarkeit Modifizierbarkeit Analysierbarkeit Übertragbarkeit Austauschbarkeit Konformität Architekturentwurf 14/18

33 Qualitätsmerkmale Modul Artikel Interoperabilität Modifizierbarkeit Stabilität Zeitverhalten Ausfallsicherheit Architekturentwurf 15/18

34 Szenarien -Beispiele Ein neuer Artikel muss innerhalb eines Tages dem System Smarts Sales zur Verfügung stehen Ein neues System muss innerhalb von 10 PT Artikel verarbeiten können Bei einem Ausfall des Systems muss das System innerhalb von max. 12 Stunden wieder online sein Architekturentwurf 16/18

35 Szenarien Vorlage Quelle des Auslösers Auslöser Umgebung Systembestandteil Antwort Antwortmetrik Architekturentwurf 17/18

36 Weitere Konzepte -SOLID Single Responsible Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle Architekturentwurf 18/18

37 Dokumentation Best Practise Template verwenden z.b. arc42 Vier Arten von Sichten verwenden Einfach halten Standards verwenden z.b. UML Dokumentenverzeichnis Stakeholder Wichtige Entscheidungen und ihre Gründe festhalten Dokumentation 1/2

38 Die Vier Sichten Dokumentation 2/2

39 Architekturpattern SOA Hexagonal Micro Service Layer / Monolith Architekturpattern 1/15

40 Architekturpattern Conways Law Conways Law Organisationen die Systeme modellieren sind auf Modelle festgelegt, welche die Kommunikationsstrukturen dieser Organisation abbilden Conways Corollary Ein Software System dessen Struktur die Kommunikationsstruktur der Organisation widerspiegelt, funktioniert besser Architekturpattern 2/15

41 SOA Beispiel Deutsche Post AG Motive: Investitionen sichern Neuentwicklung beschleunigen Zugriff auf Kerninformationen herstellen und vereinfachen Architekturpattern 3/15

42 SOA -Lösungsidee Unterstützung von Geschäftsprozessen durch fachliche Services, die miteinander interagieren Services sind technikunabhängig Bildung einer Servicearchitektur (statt Anwendungsarchitektur) Möglichst wenig Redundanzen für Funktionen und Daten Integration von bestehenden Applikationen Architekturpattern 4/15

43 Erneuerung der IT Landschaft Neuentwurf der Geschäftsprozesse Ableitung der IT-Anforderungen Entwurf des Business Domain Model Implementation Architekturpattern 5/15

44 Service Backbone (SBB) Architekturpattern 6/15

45 Standardapplikationen SBB kapselt Standardapplikationen wie SAP SBB stellt deren Funktionalität zur Verfügung Architekturpattern 7/15

46 Service Entwurf 1. Identifizieren aller potenzieller Consumer 2. Spezifizieren der Geschäftsfunktionalität 3. Vergleichen mit Business Domain Model und existierenden Services 4. Definieren und Starten der Implementation 5. Service Beschreibung, SLA, XML Schema 6. Service Provider mit SBB verbinden 7. Registrieren Architekturpattern 8/15

47 Motive der Hexagonalen Architektur Keine verteilte Business Logik Testbar in Isolation Verwendbar in Anwender Applikationen und Batch Systemen Wurde angewendet bei Flickr, Google Maps 9/15

48 Hexagonale Architektur Ports & Adapter 10/15

49 Motive -Schichtenarchitektur Schichten können unabhängig voneinander entwickelt werden Schichtenbildung minimiert Abhängigkeiten zwischen Komponenten Schichtenbildung ist ein leicht verständliches Strukturprinzip 11/15

50 Schichtenarchitektur GUI Schicht Mittelschicht Datenbankschicht Architekturpattern 12/15

51 Motive Microservices Klare Modularisierung Gute Skalierbarkeit Einfaches Deployment Teams können unabhängig voneinander arbeiten Aufteilung der Teams anhand von Fachlichkeit 13/15

52 Microservices 14/15

53 Best Practise Die Architektur sollte der Organisationsstruktur entsprechen Beides sollte der Problemstellung angepasst sein Auch für die Organisation gelten ähnliche Empfehlungen: Single Responsible Prinzip Konzentration auf die Schnittstellen Architekturpattern 15/15

54 Zusammenfassung Softwarearchitektur ist wichtig Die Arbeit kann von der Rolle Softwarearchitekt übernommen werden Teamarbeit ist wichtig Dokumentation pragmatisch angehen Man kann verschiedene Architekturpattern anwenden Organisation und Architektur hängen eng miteinander zusammen Zusammenfassung 1/1

55 Quellenverzeichnis Effektive Softwarearchitekturen Gernot Starke Arc42 Aim42 Knigge für Softwarearchitekten Peter Hruschka, Gernot Starke Software Architectur in Praxis Len Bass, Paul Clements, Rick Kazman Pattern Oriented Software Architecture (Volume 4) Frank Buschmann, Kevlin Henney, Douglas C. Schmidt Pattern of Enterprise Application Architecture Martin Fowler Literaturverzeichnis 1/2

56 Quellenverzeichnis SOA in der Praxis Nicolai Josuttis Enterprise SOA Dirk Krafzig, Karl Blanke, Dirk Slama Literaturverzeichnis 2/2