Vorschläge für Curriculum bzw. Fragen

Guten Tag, ich beginne hier mal mit (wie vor einigen Wochen, nach dem Besuch der CPSAF Schulung, bereits angekündigt) mit einigen Vorschlägen für das Curriculum.

Abschnitt Voraussetzungen:

Dependency Injection - abseits der gängigen DI-Frameworks (Spring, Guice) sollte die Verwendung von keinem DI-FW mindestens genauso bekannt sein. Stichwort Constructor-Überladung (Beispiel Cake-Pattern).
Mutable- / Immutable-State - elementar bei der Gestaltung einer Software (bzw. sollte in gleichem Atemzug wie Parameterübergabe genannt werden) und deren Auswirkungen auf den Programmablauf und das immer mehr Programmiersprachen den immutable-State syntaktisch einführen.
Datenstrukturen - hier werden nur die "gängigen" Datenstrukturen genannt. Was ist mit Enumeratoren, Iterables, Streams? Vor- und Nachteile (Speicherverbrauch, Durchsuchbarkeit) usw. Gerade der Bereich der Streaming-Technologien ermöglicht komplett neue Gestaltungsmöglichkeiten beim Design von Software. Aber auch hier gibt es elementare Dinge die beachtet werden müssen (Stichwort State).
Diskussionswürdig - Es steht "Hilfreich für das Verständnis einiger Konzepte sind darüber hinaus: Grundbegriffe bzw. Unterschiede von imperativer, deklarativer, objektorientierter und funktionaler Programmierung" -> Für mich elementar bei der Planung (Architektur) einer Software ist der Einsatz des Programmierparadigma (nicht die Syntax), da ich Software, die bspw. funktional entwickelt wird anders gestalte als von mir aus imperativ. Daher sollte der Punkt m.M. nach höher gewertet werden.
Verteilte Datenbanken - Der Einsatz von verteilten Datenbanken (Stichwort Cassandra) hat ebenfalls erhebliche Einfluss auf die Architektur und das Design der Software. Und hier reicht es wenn man mitten in der Implementierung feststellt, dass man meistens (und hier spreche ich aus Erfahrung) noch einen Suchindex benötigt, weil die Selektionsmöglichkeiten einer vert. DB eben nur sehr eingeschränkt sind.
TDD - sollte zumindest als Ansatz für "das gibt es" erwähnt werden. Ich kenne jedoch keinen SW-Entwickler der das 100% einhält.
DDD - das Thema kommt m.M. nach viel zu kurz (bzw. wird fast nicht erwähnt). Und hier beziehe ich mich auf Domain Driven Design im Ganzen (von der Struktur der Software (auf Package-Ebene), der Struktur der Software (auf Applikations-Ebene) bis hin zur organisatorische Ebene. Ist zumindest in LZ 2-1 als R3-Thema genannt, für mich völlig unverständlich dass seit 2019 als niedrig einpriorisiert. Das ist in meinen Augen ein R1 Thema. @gernotstarke die Podcasts bringen es auf den Punkt https://www.heise.de/developer/artikel/Episode-59-Domain-driven-Design-DDD-4300844.html (und folgende).
Cloud-Architekturen - es reicht doch wenn Teile der Software-Architektur in die Cloud wandern. Das hat erheblichen technischen und organisatorischen Einfluss (ACL, Latenz, SLA) auf die Architektur (egal ob die Cloud nun private oder public ist).

Was fehlt (das jedoch im kompletten Curriculum):

Virtualisierung -> Eine Softwarearchitektur wird sehr viel komplexer, je mehr Abstraktions- / Laufzeitschichten sie beinhaltet. Wurde sogar als ehemaliges Bestandteil des Curriculums wieder herausgenommen.
Containerisierung -> Siehe Virtualisierung. Auch hier müssen die Unterschiede zwischen Virtualisierung und Containerisierung klar sein bzw. welche Auswirkungen diese auf die Architektur haben (shared Resssourcen, komplexeres Deployment, Testing usw.).
DevOps -> CI/CD/CT (als Buzzword-Beispiele) tauchen im Curriculum nicht wirklich auf, ist aber elementarer Bestandteil von Softwaresystemen (und damit auch Bestandteil der Software-Architektur).
Agile Softwareentwicklung --> XP, Clean Code, auch die kontroverse Diskussion der Rolle des SW-Architekten in agilen SW-Projekten usw. Die Erfahrung aus meinen letzten SW-Projekten hat gezeigt, dass unter den SW-Architekten eine große Verunsicherung herrscht ob sie überhaupt noch gebraucht werden. Meine Erfahrung ist: Gerade in der agilen SW-Entwicklung braucht es SW-Architekten, aber nicht wie es derzeit vermittelt wird. Es sind viel mehr (um das Beispiel eines Orchester heranzuziehen die Dirigenten, die den Rahmen vorgeben, schlichten, improvisieren), die Musik machen die anderen! ;) Wie ich in einer meiner Mails geschrieben hatte, das letzte große SW-Projekt (große eCommerce-Landschaft) wäre fast daran gescheitert weil es lange Zeit keine SW-Architektur gab. Als es die Architektur-Ebene gab funktionierte das Projekt (und wir haben damals kein einziges UML-Diagramm gemalt, trotzdem funktionierte es, man muss nur die gleiche Sprache sprechen).
Ebenfalls vermisse ich die Erwähnung von Neugier und Mut als grundlegende Eigenschaft des Software-Architekten. In der CPSA-F-Schulung wurde als positives Hauptmerkmal eines SW-Architekten "Erfahrung" genannt. Na gut, dann scheint das der Grund zu sein, warum immer mehr Start-Ups (und solche die es mal waren) auf den klassischen SW-Architekten verzichten können.

Genug Text, ich würde mich freuen von Euch zu hören und über die Punkte zu diskutieren.

Im Folgenden würde ich einige Punkte (in getrennten Issues) zumindest hinterfragen, da sie in meinen Augen zumindest antiquiert wirken und mit der Rolle des SW-Architekten (wie mein Verständnis davon ist) konkurrieren.

Schöne Grüße von zu Hause, bleibt gesund,

Laszlo

danke Laszlo, das ist wirklich eine Menge an Ideen - danke DIr für Deine Mühe und Beschäftigung mit dem Thema!!

Zur Erläuterung einiger Sachverhalte:

Wir (Arbeitsgruppe Foundation Level) sehen für die Schulungen ein sehr deutliches Zeitproblem: 3 Tage haben höchstens 18h effektive Ausbildungszeit - und alle interessanten Themen der IT passen da leider nicht rein.
Daher haben wir an vielen Stellen Themen runterpriorisiert und an den Advanced-Level delegiert, beispielsweise die folgenden (ja, Du hast Recht - die Themen sind alle interessant, aber unsere Zeit ist beschränkt) DDD, das war ein paar Jahre mal höher priorisiert, bevor es das Advanced-Modul dazu gab, qualitative Analyse (AWERT, IMPROVE) und Container/Virtualisierung _> CLOUDINFRA, FLEX Agile Entwicklung -> AGILA
Ebenso müssen wir uns etwas abgrenzen von Senior-Developer-Know-How: Wir wollen und können aus dem Architekturtraining ja keinen Fortgeschrittenen-Programmierkurs machen (in dem viele der von Dir genannten Themen sehr wichtig wären).
Wir haben uns als Verein explizit dafür entschieden, technologieneutral zu bleiben. Daher fallen diverse Themen weg, die sehr spezifisch für konkrete Technologien sind (da sehe ich z.B. reactive streams)
DevOPS: ist (nur) für Informationssysteme relevant - bei Mobile-Apps, Embedded-, oder sehr hardwarenahen Systemen ist das überhaupt kein Thema... wir wollen aber im Foundation auch keinen Kurs nur für Web-Architekten geben.
Dito Verteilung (sowohl bezüglich Datenbanken wie auch verteilte Anwendungen) - das Thema ist für Web-Systeme relevant, aber für z.B. unternehmensinterne Systeme, embedded-Systeme wiederum nicht.

das gesagt - mach' gerne aus einzelnen Themen einzelne Issues, die wir dann in der gesamten Arbeitsgruppe zur Diskussion stellen...

danke nochmals, Gernot (gesund und auch im Homeoffice)

Hallo Gernot, danke für Deine Rückmeldung.

Du hast Recht, ich werde mich bemühen meine Erfahrungsbrille abzusetzen und das Thema SW-Architektur ein wenig allgemeiner betrachten.

Was mich aber dazu führt auf Deine Punkte einzugehen.

Verteilte Anwendungen / Datenbanken: Mag sein dass das für embedded Systeme nicht relevant ist, allerdings im unternehmensinternen / Enterprise- Umfeld ist das Thema ausgesprochen relevant. Und gerade bei ressourcensparenden Embedded-Systemen sehe ich ein riesiges Feld für verteilte Anwendungen. Und für mich ist das ganze Docker-Thema nichts weiter als eine Embedded-Softwarelösung. Und ja, eine Waschmaschine wird weiterhin ein relativ isoliertes System bleiben, was wenig mit verteilten Anwendungen / Datenbanken zu tun haben wird, allerdings ist das wirklich das Kerngebiet der SW-Architektur?

DevOps: Du schriebst, dass embedded / hardwarenahe Systeme nicht DevOps relevant sind. Aber hier stelle ich tatsächlich die Frage: Wie allgemeingültig sind diese Art von Systemen für Software-Architektur. Hardwarenahe / embedded Softwareentwicklung ist IMHO ein absolutes Randgebiet. Informationssysteme nehmen nach meiner Erfahrung den weit größten Teil der SW-Architektur ein (und hier beziehe ich bspw. mal den kompletten Automotive- / Medical-Sektor mit ein). Und gerade hier fallen m.M.n. (reactive) Streams als Kommunikationsmedium zwischen Services rein.

Architektur und Software-Entwicklungs-KnowHow: Auch hier bin ich Deiner Meinung dass es eine Abgrenzung zwischen beiden Gebieten geben muss. Allerdings ist es um Systeme entwerfen zu können (komplex oder nicht komplex spielt dabei keine Rolle) wichtig (nach meinem Verständnis) ein sehr tiefes technisches SW-KnowHow zu besitzen. Äquivalent zur Gebäudearchitektur um das mal als Metapher zu verwenden, wird der Architekt auch ein tiefes Verständnis von Baumaterialien, deren Verwendung und Kombinationsmöglichkeiten haben, auch wenn der Architekt nicht derjenige ist, der das Haus zusammensetzt.

Auf jeden Fall stimme ich zu, das 3 Tage für die allgemeine Vermittlung von SWA-KnowHow sehr wenig Zeit ist. Das versuche ich mal bei der Erstellung von Issues / Anmerkungen zu berücksichtigen.

Ich wünsche Dir, wenn wir uns nicht mehr hören, frohe Ostern und bleib gesund.

Viele Grüße, Laszlo

@sippsack please comment on this issue

Das sind sehr viele spannende Punkte, aber wie Gernot in seinem Kommentar schon geschrieben hat, können wir vieles davon nicht einfach so im Foundation Lehrplan unterbringen. Das hat verschiedenen Gründe:

Das Foundation Ausbildung ist auf einem sehr grundlegenden Level, bei dem insbesondere das schematische Vorgehen bei der Entwurfsarbeit vermittelt wird. Und das muss in 3 oder 4 Tage passen.
Viele Themen werden über die Advanced-Seminare abgedeckt und können dann von Fortgeschrittenen dort vertieft werden
jeder Trainer bringt andere Erfahrungen und Wissen mit, von daher ist es nicht verboten, die hier vorgeschlagenen Themen in der Schulung trotzdem zu behandeln (sofern es in dem zeitlichen Rahmen machbar ist). Aber es im Lehrplan vorzuschreiben (auch als R2 oder R3) halte ich trotzdem für das falsche Signal. Der Lehrplan ist eine Art Standard und der kleinste gemeinsame Nenner von verschiedenen Schulungsanbietern. Wir werden nie die eierlegende Wollmilchsau-Lösung erreichen, weil die dann keiner mehr implementieren kann.
die verschiedenen Systemtypen (Web, Information und Embbeded) haben tatsächlich ganz unterschiedliche Anforderungen und daher sollten möglichst nur die Dinge enthalten sein, die für alle Gruppen relevant sind (weil es in offenen Seminaren auch gemischte Teilnehmer-Gruppen geben kann)

Da es sich hier um eine relativ große Ansammlung von verschiedenen Themen handelt, schließen wir das Ticket hier zunächst. Wir behalten uns vor, einzelne Aspekte herauszunehmen und in separaten Tickets weiter zu verfolgen.

@LaszloLueck: Du darfst natürlich für Dich besonders relevante Themen auch nochmal jeweils ein gesondertes Ticket anlegen, so dass wir es dann gezielt diskutieren können. Sollte es bereits Tickets geben, dann sollten wir die hier noch verlinken.

English short form:

Closed because of too many topics that don't fit in the curriculum anyway. So if they are still relevant or essential we should open new issues for each topic separately.

isaqb-org / curriculum-foundation

Vorschläge für Curriculum bzw. Fragen #125