Vortrag II Stichpunkte

Kernaussagen aus Ansgar Brauners Vortrag am 16.11.2018

1. Der erste Fokus liegt auf der Architektur der Teams, da, entsprechend Conways Law, sich die Architektur der Software in der Praxis der Organisationsstruktur annährt. Daher werden Teams so aufgebaut, dass die angestrebte Struktur abgebildet wird, selbst wenn diese noch nicht erreicht ist.

2. Die Arbeit muss so verteilt werden, dass die Teams weitgehend autonom arbeiten können. Die Reibungsverluste durch erforderliche Abstimmung und Kommunikation sollen minimiert werden.

3. Die Teams sollten für den gesamten Lebenszyklus der durch sie bearbeiteten Software zuständig sein. Das heißt sie sollen sowohl Entwicklung, Deployment, Betrieb als auch für die Stilllegung.

4. Die Softwarearchitektur sollte nicht klassisch horizontal geschnitten werden, sondern vertikal, sodass jedes Team für den gesamten Stack zuständig ist. Das heißt jedes Team kümmert sich um alle betroffenen Schichten, von der Datenbasis bis zur GUI.

5. Teams sollten aus Spezialisten für alle Bereiche, welche der Anwendungsfall des Teams berührt, gebildet werden. Beispielsweise Datenbank, GUI, usw.

6. Die einzelnen Services sollen unabhängig voneinander in Dockercontainer deployt werden können. Wichtig ist immer mindestens 2 Instanzen deployt werden, da viele Probleme sich erst dann zeigen.

7. Entscheidungen sollten, wenn möglich, immer an den Orten passieren an denen sie sich auch auswirken.

8. Entscheidungen sollten so getroffen werden, dass, falls möglich, niemand die Entscheidung ablehnt, es müssen nicht alle zustimmen.

9. Für jede Datenressource ist exakt ein Team zuständig, dieses besitzt jene dann auch.

10. Die unterschiedlichen Domänen können klassifiziert werden als „Core Domains“ – Domänen die das Kerngeschäft abbilden und zur Abgrenzung von der Konkurrenz dienen – „Supportive Domains“ – Domänen welche die Core Domains unterstützen und daher erforderlich sind und „Generic Domains“ – welche Basisfunktionen bereitstellen und als fertige Lösungen eingekauft werden können.

11. Es soll kein geteilter Zustand zwischen den einzelnen Services des Systems entstehen.

12. Wenn irgend möglich soll asynchron zwischen den Services kommuniziert werden.

13. Die Teams sollen bei der Entwicklung größtmögliche Freiheit genießen, es soll keine unnötigen Einschränkungen geben. Dies beinhaltetet die freie Wahl des Technologiestacks

14. Damit die Kernprinzipien eingehalten werden gibt es Leitlinien für die Teams, welche beachtet werden müssen, jedoch so abstrakt sind, dass sie die Freiheit der Teams nur gering einschränken, solche die beachtet werden sollten, gegen welche in begründeten Ausnahmefällen jedoch verstoßen werden kann und solche die den Status von Empfehlungen haben.

15. Die Leitlinien bestehen aus mehreren Bestandteilen jeweils für die gewünschten Designziele (Vertikale Grenzen, Dezentralisierung), die Architekturprinzipien (Autonomy, Automation, Communication) und Guides (wie wird Authentisierung gemacht, wie werden REST-APIs aufgebaut, wie funktioniert asynchrone Kommunikation, usw.)

16. Jeder Service sollte immer über alle Daten verfügen die er für die Erfüllung seiner Aufgaben benötigt. Es sollte nicht erforderlich sein bei anderen Services nachzufragen.