Diese Seite enthält annotierte Literaturhinweise zum Artikel „Requirements für Messbarkeit und neue Jobs in der SW-Entwicklung“ von Martin Rösch im IT-Spektrum 1/2026.

Zum Artikel: https://www.sigs.de/artikel/requirements-fuer-messbarkeit-und-neue-jobs-in-der-sw-entwicklung/

Zu den Literaturangaben, in der Reihenfolge ihres Auftretens: [1] ISO 9000:1991 +++ [2] Funktionale Überprüfung +++ [3] ECOOP 2003 +++ [4] ISO-Norm 30173 (Digital Twins) +++ [5] Muss Software wirlich Fehler haben? +++ [6] Wissensorientierte Software-Entwicklung +++ [7] ATAM Light +++ DDD +++ [8] Evolutionary Architecture +++ Cynefin +++ [9] Amazon Big Mandate +++ [10] Blue Eagle +++ SAP-Chefin zu den Änderungen durch KI

Amazon [9] 

Diese Literaturangabe verweist auf eine Seite im Internet, auf der ein „API-Evangelist“ beschreibt, wie Amazon um das Jahr 2000 herum die Struktur seiner IT-Systeme an die Struktur des Unternehmens angepasst hat.

Link: https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/ (3 Minuten Lesezeit)

Für diese Anpassung hat Amazon Conway’s Law positiv interpretiert: „Es ist gut, wenn die Strukturen der IT-Systeme [für das Business] sich an Team-Strukturen [im Business] orientieren“. Sehe ich auch so: Das ist einfach gutes Business-IT-Alignment. Den Text in Klammern habe ich ergänzt.

Die übliche Interpretation von Conway’s Law durch Software-Architekten ist dagegen negativ: „Es ist schlecht, wenn die Strukturen der IT-Systeme [für das Business] sich an den Team-Strukturen [in der IT-Abteilung] orientieren“. Auch das ist richtig.

Conway’s Law stammt von 1968. Das ist 57 Jahre her. Und die Begrifflichkeiten waren ungenauer. So hat Conway z.B. nicht zwischen Teams im Business und Teams in der IT-Abteilung unterschieden.

Mittlerweile hat die Welt sich aber weiter gedreht. Deshalb sollten wir heute lieber auf die aktuelle Kognitionswissenschaft von heute schauen als auf die alten Informatik-Kamellen von vor 57 Jahren.

Also eigentlich nur ein Missverständnis, das durch die unpräzise Angabe zum Ort der Teams immer wieder neu aufgewärmt wird.

Wie Amazon sich selbst sieht

Der Blick von Amazon auf die eigene Struktur:

Beispiel: 12 Business-Teams, jedes mit einem eigenen Digitalen Zwilling für das eigene Arbeitsfeld

Das Innere jedes Digitalen Zwillings ist nur für das eigene Business Team sichtbar und nutzbar. Für alle anderen Business Teams bleibt es eine Black-Box. Wer Daten von einem anderen Team braucht, vereinbart mit diesem Team als Schnittstelle ein API. Über dieses API liefert der Digitale Zwilling des anderen Teams dann die Daten.

Lieferbeziehungen zwischen Business Teams. Genauer:zwischen deren Digitalen Zwillingen

Den genauen Anteil dieser Architektur-Entscheidung am weiteren Erfolg von Amazon kennen wir nicht. Wir wissen aber, dass sie den Übergang vom Buchhändler zum Alles-Händler erleichtert hat: denn Amazon hat die Digitalen Zwillinge seiner Business Teams auch nach außen, für externe Geschäftspartner, zugänglich gemacht.

ATAM Light [7]

Diese Literaturangabe verweist auf einen Artikel im IT-Spektrum 4/2023:

https://www.sigs.de/artikel/so-wird-atam-schlank-und-schnell-vorwaerts-rueckwaerts-kontinuierlich/

Die klassische Form der Architecture Tradeoff Analysis Method (ATAM) ist theoretisch leistungsfähig, aber praktisch nutzlos: zu schwergewichtig und zu langsam. Ich kenne bisher nur Berichte über unbefriedigende Einsätze.

Wenn man ATAM aber etwas modifiziert und mit neueren Erkenntnissen der Wirtschafts-Psychologie aufpeppt, dann wird daraus das glatte Gegenteil:

Ein schlankes, schnelles und praxistaugliches Risiko-Radar, das – praktisch live – die Aufmerksamkeit aller Stakeholder dort fokussiert, wo es „brennt“, und – dauerhaft aktuell – ein zusammenhängendes Lagebild liefert, für den gesamten Fluss des Wissens in immateriellen Produktionsprozessen.

Wie z.B. bei Prozessen der Wissensarbeit und ihren Spezialfällen, der Entwicklung von Software oder Prozessen oder software-intensiven Produkten. Mit und auch ohne KI.

(Ein Klick auf das Bild öffnet den Artikel)

Blue Eagle [10]

Diese Literaturangabe verweist auf einen Artikel in OBJEKTspektrum 3/2001.

Michael Wrede, Olaf Merkert, Constantin Szallies: Das Projekt “Blue Eagle”, OBJEKTspektrum 3/2001. Das Immobilienverwaltungs-Projekt, das zur Basis eines SAP-Hana-Moduls wurde.

(Wir arbeiten daran, auch diesen Artikel von 2001 wieder online zu stellen)

Cynefin-Framework

Das Cynefin-Framework beschreibt eine Typologie für Wissensgebiete (Kontexte bei der Wissensarbeit).

Es beschreibt eine praxistaugliche Abgrenzung der folgenden Begriffe:

• Einfach: Ich empfinde ein Wissensgebiet als einfach, wenn ich (1) eine Vorstellung (ein kognitives Modell) davon habe, (2) mühelos danach handeln kann und (3) alles immer so funktioniert, wie ich es erwarte.
• Kompliziert: Ich empfinde ein Wissensgebiet als kompliziert, wenn ich (1) eine Vorstellung davon habe, (2) mit mehr oder weniger Nachdenken danach handeln kann und (3) alles – sofern ich korrekt nachgedacht habe – immer so funktioniert, wie ich es erwarte.
• Komplex: Ich empfinde ein Wissensgebiet als komplex, wenn ich (1) eine Vorstellung davon habe, (2) mit mehr oder weniger Nachdenken danach handeln kann, ABER (3) immer wieder Überraschungen auftreten (wie Knüppel zwischen die Beine), die mir deutlich machen, dass meine Vorstellung doch noch nicht ganz zutreffend ist.
• Chaotisch: Ich empfinde ein Wissensgebiet als chaotisch, wenn ich keine zusammenhängende Vorstellung davon entwickeln kann, wie es funktioniert – und daher auch nicht in der Lage bin, gestaltend zu handeln.

https://de.wikipedia.org/wiki/Cynefin-Framework (öffnet ein neues Fenster)

DDD

ECOOP2003 [3]

Martin Rösch, „Verification of Software Composed From Components“

Der erste Beitrag im Workshop “Correctness of Model-based Software Composition (CMC)” zur European Conference for OOP 2003 (ECOOP 2003)

Dieser Konferenz-Beitrag wird im Artikel 3x referenziert:

1.  Als Quelle für eine (1) automatisch hergestellte, (2) gegenseitige und (3) immer aktuelle Cross-Referenz zwischen Anforderungen und den Elementen eines Objektmodells (=Kognitives Modell).
2. Er beschreibt die Metastruktur der Entwicklungsumgebung, in der das SAP-Hana-Modul für die Immobilienverwaltung entstanden ist.
3. Er zeigt, wie zusammenwirkende Komponenten verifiziert werden können.

Veröffentlicht durch das Karlsruher Institut für Technologie (KIT): https://publikationen.bibliothek.kit.edu/3152003/1533
(Der Link bietet einen Download der Proceedings-Datei an. Dateiname: “Volltext.pdf”  (1,9MB) )

Evolutionary Architecture [8]

Parsons, Ford, Sua: “Evolutionary Architectures”, 2017. Folien (120):

https://nealford.com/downloads/Evolutionary_Architectures_by_Neal_Ford.pdf#page=38

Benennt die Wissensgebiete hinter den verschiedenen Blickwinkeln auf ein System als “Dimensionen”. Kennt Akzeptanzkriterien (=Tests), unter dem Namen Fitness Functions. Requirements werden nicht erwähnt.

Funktionale Überprüfung [2] 

Martin Rösch, Korrekte Objektmodelle durch funktionale Überprüfung, OBJEKTspektrum 2/1994. Ein Bericht über die automatisierte Verifikation von Objektmodellen.

Zitat: „Durch die Möglichkeit der funktionalen Überprüfung von OOA-Modellen kann zudem noch sichergestellt werden, dass die OOA-Modelle die fachlichen Anforderungen auch wirklich erfüllen.“

Erläuterung

Mit „funktionale Überprüfung“ war gemeint, dass wir das OOA-Modell vollständig in Smalltalk implementiert hatten. Ebenso wie alle Akzeptanzkriterien (=Testfälle). Deshalb konnten alle Tests automatisiert ablaufen. In wenigen Sekunden. 

(Ein Klick auf das Bild öffnet den Artikel)

ISO 9000:1991 [1]

ISO 9000:1991. Diese frühe Version der ISO 9000 hatte den Vorteil, dass Laien wie ich und mein Team sie direkt verstehen und umsetzen konnten. Neuere Versionen der Norm sind leider komplizierter formuliert.

ISO 30173 Digital Twins [4]

ISO-Standard zur Terminologie für Digital Twins.

https://www.iso.org/standard/81442.html.

Liefert eine gute, weil kognitiv richtige Terminologie für das Beschreiben von Digitalen Zwillingen und ihren Gegenstücken, den Realen Zwillingen:

• Der Reale Zwilling ist eine Wahrnehmung (oder auch nur eine Vorstellung) einer betrachtenden Person von einem beliebigen Etwas. Die Norm nennt es „Target Entity“.
• Der Digitale Zwilling ist ein Digitalprodukt.

Vorsicht Bananenschalen:

• Fast alle Beschreibungen von Digitalen Zwillingen im Internet sind falsch. Genauer: irreführend. Wer sich an diesen Beschreibungen orientiert, erstellt Systeme, die Probleme verursachen.
• Ein Realer Zwilling muss immer aus der Sicht einer betrachtenden Person beschrieben werden. Warum? Weil er in deren Kopf zuhause ist. Ein Realer Zwilling ist immer eine Vorstellung. Und Vorstellungen sind immer in Köpfen. 
• Deshalb kann es zu einem physisch vorhandenen (d.h. materiellen) Gegenstand (den es immer nur 1x gibt, z.B. ein bestimmtes Fahrzeug) mehrere Digitale Zwillinge geben. Weil verschiedene Betrachter jeweils ihre eigene Vorstellung von einem physisch vorhandenen Gegenstand entwickeln können.
  • Beispiel: Ein Halter und eine Werkstatt haben unterschiedliche Vorstellungen von ein und demselben Fahrzeug. Daher gibt es in diesem Beispiel für das Fahrzeug zwei Digitale Zwillinge: 1 für die Werkstatt und 1 für den Halter.
  • Ob beide dasselbe Fahrzeug meinen, ist bei materiellen Objekten meistens leicht festzustellen.
• (Fast) daselbe gilt auch für immaterielle Objekte. Wie z.B. ein Risiko bei einer Bank, einer Versicherung oder einer technischen Anlage. Oder für ein Prozess. Oder seine Beschreibung. Alles immaterielle Objekte.
  • Auch für immaterielle Objekte gilt: Jedes von ihnen kann einen oder auch mehrere (bei mehr als 1 Betrachter) Digitale Zwillinge haben. Beispiel: Eine Instanz eines Software-Entwicklungsprozesses sieht für (a) beteiligte Entwickler, (b) Manager und (c) Controller jeweils anders aus, obwohl alle denselben Prozess meinen: den, der jetzt grade hier in der Abteilung läuft.
  • Vorsicht Bananenschale: Immaterielle Objekte existieren in JEDEM Kopf, der sie sich vorstellt.
  • Ob dann alle Vorstellungen hinreichend ähnlich sind, ist oft nicht so leicht und auch nicht so sicher festzustellen wie bei materiellen Objekten.

Muss Software wirklich Fehler haben? [5]

Martin Rösch, Muss Software wirklich Fehler haben?, OBJEKTspektrum 1/1998, 4 Seiten. Wie ein Beweis aus der theoretischen Informatik missverstanden wurde.

Damit meine ich das Halteproblem:

• Der Beweis ist theoretisch richtig, aber praktisch nicht relevant. Warum nicht? Weil uns nichts und niemand daran hindern kann, unsere Software so zu erstellen, dass sie alle Anforderungen erfüllt – solange sie sich nicht gegenseitig widersprechen und die Technik das Geforderte leisten kann.

(Ein Klick auf das Bild öffnet den Artikel)

SAP zu Änderungen durch KI

https://t3n.de/news/sap-chefin-erklaert-welche-entwickler-in-20-jahren-noch-gebraucht-werden-1701600/

Zitat: „Es geht nicht darum, ob es in 20 Jahren noch Entwickler geben wird, sondern wie wir sie für dieses neue Zeitalter befähigen. Daher müssen Unternehmen auch ihre Personalstrategie an das KI-Zeitalter anpassen. Nicht weniger Entwickler, sondern neue Fähigkeiten sind gefragt.“

(abgerufen am 20.09.2025)

Wissensorientierte Software-Entwicklung [6]

Martin Rösch, Fehlerfreie Software durch wissensorientierte Softwareentwicklung, OBJEKTspektrum 1/2001. Beschreibt Wissen als Produktionsfaktor und berichtet über frühe Erfahrungen auf dem Weg zu Software, in der Anwender keine Fehler mehr finden (können).

(Ein Klick auf das Bild öffnet den Artikel)