Einführung in Sociotechnical Engineering

In Softwareprojekten beeinflussen sich Individuen und technische Artefakte gegenseitig und bilden komplexe soziotechnische Systeme. Dennoch können solche Systeme ähnlich wie technische Systeme angegangen werden – durch Anforderungsanalyse, Design, Fehlersuche und Tests. Dieser Artikel führt einen Ansatz namens Sociotechnical Engineering ein, der die klassischen Kategorien und Prinzipien des Systems Engineering auf die Welt der Softwareprojekte als soziotechnische Systeme anwendet.

Softwareprojekte bestehen aus Menschen und den von ihnen produzierten technischen Artefakten. Diese Artefakte umfassen nicht nur Code, sondern auch Anforderungen, UI-Designs, Testfälle, User-Storys, Coding-Richtlinien, Architekturdokumentationen, CI/CD-Skripte und viele weitere Elemente. Artefakte werden nicht nur von uns Menschen beeinflusst, sondern beeinflussen umgekehrt auch uns. Ähnlich wie eine Ampel uns zum Anhalten bewegen kann, können zum Beispiel Coding-Richtlinien unsere Programmierstile prägen. Darüber hinaus dienen Artefakte als Kommunikationsmittel zwischen Menschen. Diese enge Verflechtung und Wechselwirkung zwischen Menschen und Artefakten legt nahe, beide Komponenten als ein zusammenhängendes System zu betrachten. Solche Systeme werden oft als soziotechnische Systeme bezeichnet.

Trotz ihrer Komplexität können soziotechnische Systeme ähnlich wie technische Systeme angegangen werden – durch Anforderungsanalyse, Design, Fehlersuche und Tests. Sociotechnical Engineering interpretiert klassische Prinzipien des Systems Engineering für den Bereich soziotechnischer Systeme neu.

Soziotechnische Systeme können nicht deterministisch entworfen werden, da sie von mehreren Ungewissheitsquellen beeinflusst werden, sich im Laufe der Zeit entwickeln und von Menschen bewohnt sind. Dennoch können wir die Bedingungen und den Kontext gestalten, in denen sich diese Systeme gemäß unseren Bedürfnissen entwickeln sollen.

Dieser Artikel führt die Leser durch die drei Hauptkategorien des Systems Engineering – Anforderungsanalyse, Systemdesign und Fehlersuche – und passt diese an soziotechnische Systeme an. Er zeigt, wie gängige Ansätze und Taktiken wiederverwendet werden können, um die Komplexität der soziotechnischen Herausforderungen zu bewältigen.

Anforderungen

Anforderungen leiten das Design. Sie schaffen Transparenz und ermöglichen strukturierte Diskussionen über Architekturentscheidungen. Gut definierte Anforderungen helfen dabei, Konflikte zwischen unterschiedlichen Bedürfnissen frühzeitig zu erkennen, sodass das Management Prioritäten setzen und kommunizieren kann, was am wichtigsten ist. Dies gilt gleichermaßen für technische wie für soziotechnische Systeme, beispielsweise Softwareprojekte.

Funktionale Anforderungen

Funktionale Anforderungen definieren, was das System tun soll. Für soziotechnische Systeme bedeutet dies die Produktion verschiedener Artefakte wie Code, Dokumentation, Konfigurationen, Projekthandbücher, UI-Designs und mehr. Nicht nur der Code in der Produktionsumgebung ist wichtig. Zwischenprodukte wie Business Cases, UI-Designs, Anforderungsdokumentationen und Testfälle sind keine bloßen Nebenprodukte; sie dienen als essenzielle Kommunikationsmedien zwischen Menschen und spielen daher eine entscheidende Rolle in soziotechnischen Systemen.

Durch das Auflisten aller erforderlichen Artefakte (z. B. Projekthandbücher, Systemanforderungen, Architekturentscheidungen, Code, Testfälle, Bereitstellungsskripte, Konfigurationen) können Unsicherheiten über den Umfang der Lieferungen reduziert und die Rollen, die für die Umsetzung des Projekts erforderlich sind, effektiv strukturiert werden.

Nicht funktionale Anforderungen

Nicht funktionale Anforderungen definieren, wie das System seine Funktionalität erreichen soll. Klassische Attribute wie Verfügbarkeit, Leistung, Skalierbarkeit und Sicherheit sind ebenfalls relevant für soziotechnische Systeme.

Beispiel 1 – Entscheidungsfreiheit (Decision Sovereignty): Das Projekt sollte jederzeit in der Lage sein, technische und geschäftliche Entscheidungen unabhängig zu treffen. Diese Anforderung verhindert eine Lähmung, wenn wichtige Entscheidungsträger, wie Project Lead oder Lead Architect, nicht verfügbar sind. Sie ist vergleichbar mit der Sicherstellung der Systemverfügbarkeit, bei der das System auch dann betrieben werden kann, wenn einige Komponenten ausfallen. Soziotechnische Entscheidungen wie Rollendefinitionen und technische Entscheidungen müssen mit dieser Anforderung übereinstimmen.

Beispielsweise kann eine zentralisierte relationale Datenbank zwar technisch Konsistenz bieten, aber Entscheidungsengpässe verursachen, wenn nur eine Person ihre Komplexität versteht. Alternativ können mehrere Dokumentdatenbanken eine verteilte Entscheidungsfindung fördern, jedoch auf Kosten der technischen Konsistenz. Architekturentscheidungen sind immer Abwägungsentscheidungen (Tradeoffs). Sie benötigen transparente und formulierte Anforderungen als Leitlinie.

Beispiel 2 – Entwicklungsskalierbarkeit (Development Scalability): Das Projekt sollte in der Lage sein, seine Liefergeschwindigkeit zu erhöhen, indem es das Team aufstockt. Obwohl die Einstellung weiterer Mitarbeiter als offensichtliche Lösung zur Leistungssteigerung erscheint, können unvorbereitete soziale und technische Strukturen die Skalierbarkeit behindern. Erfahrungsgemäß bringen mehr Leute nicht die erwartete Beschleunigung.

Soziotechnische Systeme sind nicht von Natur aus für Skalierbarkeit ausgelegt. Warum auch? Eine Qualität in ein System einzubauen, ohne dass dies ausdrücklich gefordert wird, könnte die Leistung des Systems in anderen Bereichen beeinträchtigen. Wenn Skalierbarkeit nicht erforderlich ist, würde sie nur unnötige Entkopplung sozialer und technischer Strukturen erzwingen, was die Systemkomplexität erhöhen und die Konsistenz verringern könnte. Daher muss die Entwicklungsskalierbarkeit explizit angegeben werden, um sicherzustellen, dass geeignete Abwägungen getroffen werden.

Das frühzeitige Auflisten soziotechnischer Anforderungen hilft, persönliche Vorurteile zu vermeiden, politische Auseinandersetzungen zu reduzieren und Anforderungskonflikte zu identifizieren, wie wenn Verfügbarkeits- und Geschwindigkeitsanforderungen (Availability vs. Latency) miteinander kollidieren.

Design

Die zweite Hauptkategorie des Systems Engineering ist das Systemdesign.

Elemente soziotechnischer Systeme

In soziotechnischen Systemen arbeiten Menschen an Artefakten gemäß ihren Rollen. Drei zentrale Elementtypen definieren diese Systeme: Menschen, Rollen und Artefakte. Abbildung 1 schildert diese drei Elementtypen und deren Beziehungen.

Abb. 1: Elemente soziotechnischer Systeme

Zentrale Elemente sind:

• Menschen: Individuen wie Cassandra oder Hector agieren als Verarbeitungsknoten (computational nodes), auch wenn sie nicht deterministisch sind. Sie verarbeiten die Arbeitslast.
• Rollen: Diese sind vergleichbar mit Services und werden einzelnen Personen zugewiesen. Zum Beispiel wird die Rolle „Lead Architect“ Cassandra zugewiesen. Wenn Cassandra aufgrund von Krankheit oder Urlaub nicht verfügbar ist, ist der Service „Lead Architect“ nicht verfügbar. Wenn jedoch die Rolle mit einer gewissen Redundanz sowohl Cassandra als auch Hector zugewiesen wird, bleibt die Rolle auch dann betriebsbereit, wenn eine Person nicht verfügbar ist. Daher ist die Aussage „Die Rolle Lead Architect ist Cassandra zugewiesen“ flexibler als „Cassandra ist der Lead Architect“. Dieser Ansatz kann als „Role-as-a-Service“ (RaaS) bezeichnet werden.
• Artefakte: Dies sind die Verantwortlichkeiten, die mit Rollen verbunden sind. Zum Beispiel kann die Rolle „Lead Architect“ als Verantwortung für das Artefakt „Softwarearchitekturdokumentation“ (SAD) definiert werden. SAD fasst dabei alle relevanten Systemdesigns und technischen Entscheidungen zusammen. Artefakte haben Stakeholder – das sind die Service-Kunden. Zum Beispiel kann die Rolle „Software Engineer“ ein Stakeholder vom Artefakt SAD sein. Software Engineers sind somit Kunden des Service „Lead Architect“.

Der „Role-as-a-Service“-Ansatz, bei dem Rollen durch die Verantwortung für Artefakte definiert und einzelnen Personen zugewiesen werden, unterscheidet sich von anderen Ansätzen zur Rollenbeschreibung, wie dem Role Canvas , Role Model Canvas oder der RACI-Matrix. Diese Ansätze stellen Aktivitäten, Aufgaben und Fähigkeiten in den Mittelpunkt und bieten somit eine Whitebox-Sicht auf die Rolle.

Der „Role-as-a-Service“-Ansatz hingegen definiert die Rolle als Blackbox über ihr Public Interface – also die Artefakte, die diese Rolle für ihre Kunden bereitstellen soll. Wenn Rollen als Services betrachtet werden, dann sind die Produkte dieser Services – die Artefakte für die Service-Kunden – relevanter als die Tätigkeiten, die der Service ausführt.

Rollen-Artefakte-Menschen-Mapping

Das Rollen-Artefakte-Menschen-Mapping ist eine kollaborative Übung, um Abhängigkeiten zwischen soziotechnischen Elementen zu identifizieren. Abbildung 2 zeigt die Abhängigkeiten rund um das Artefakt SAD.

Abb. 2: Rollen-Artefakte-Menschen-Mapping

Aus Abbildung 2 kann man Folgendes ableiten:

• Die Rolle „Lead Architect of Product X“ hat eine geringe Verfügbarkeit, da sie nur Cassandra zugewiesen ist.
• Cassandra führt zwei Rollen aus: „Lead Architect of Product X“ und „Software Engineer of Team Y“.
• Kate, die Product Ownerin, ist Kundin von Cassandra, da die Rolle „Product Owner“ ein Stakeholder des Artefakts SAD ist. Diese Beziehung ermöglicht es Kate, ihre Informationsbedürfnisse an Cassandra zu kommunizieren. Falls Kate unzufrieden ist, kann das Diagramm als Leitfaden für Fehlersuche verwendet werden, zum Beispiel indem die Verfügbarkeit der Architektenrolle erhöht oder Verantwortlichkeiten neu zugewiesen werden.

Wiederverwendung von Mustern und Taktiken

Mithilfe einer Entwurfssprache für soziotechnische Systeme können Designentscheidungen, die zur Erfüllung soziotechnischer Anforderungen erforderlich sind, effizient entwickelt, diskutiert und kommuniziert werden. Es gibt zahlreiche Muster und Taktiken für verschiedene Designherausforderungen. Zum Beispiel katalogisiert das Buch „Software Architecture in Practice“ von Len Bass und anderen [1] Dutzende von Taktiken zur Erfüllung von Verfügbarkeitsanforderungen, siehe Abbildung 3.

Abb. 3: Verfügbarkeitstaktiken

Nicht alle Taktiken sind in jedem Szenario anwendbar, aber sie dienen als hilfreiche Referenzen zum Nachschlagen. Solche Kataloge sind nützlich, um bewährte Lösungen zu identifizieren und eine gemeinsame Sprache für die Kommunikation bereitzustellen. Es folgen zwei Anwendungsbeispiele der Verfügbarkeitstaktiken.

Selbsttest + Außerdienststellung (Self-Test + Removal from Service)

Problem: Man will wissen, ob eine Rolle nicht zu stark von einer einzelnen Person abhängt.

Lösung: Self-Test + Removal from Service

Selbsttest (Self-Test) ist eine Taktik, die das Ausführen von Verfahren zur Überprüfung der Korrektheit des Systembetriebs beinhaltet. Außerdienststellung (Removal from Service) bedeutet, dass eine Systemkomponente vorübergehend aus dem Dienst genommen wird, um potenzielles Fehlverhalten zu identifizieren. Diese Taktiken können kombiniert werden.

Zum Beispiel könnte das System für die Rolle „Lead Architect“, die Cassandra zugewiesen ist, ein Test-Szenario enthalten, das in einem BDD-Gherkin-Format formuliert wird, um die Verfügbarkeit sicherzustellen:

• Angenommen: Lead Architect (Cassandra) ist im Urlaub.
• Wenn: eine externe Überprüfung der Softwarearchitektur des Projekts angefordert wird,
• Dann: sollte die Überprüfung keine schwerwiegenden Mängel ergeben.

Dieses Szenario artikuliert klare Erwartungen an die Service-Qualität. Dieser Test kann auch ausgeführt werden, um die Leistung des Systems zu überprüfen und eventuelle Lücken zu schließen.

Redundant Spare und Shadow

Problem: Man möchte die Verfügbarkeit einer Rolle erhöhen und die Abhängigkeit von einzelnen Personen verringern.

Lösung 1: Redundant Spare

Die Taktik Redundante Reserve (Redundant Spare) stellt sicher, dass mehrere Komponenten dieselbe Funktionalität teilen, um bei einem Ausfall eine Absicherung zu gewährleisten. Auf das obige Beispiel angewendet, würde dies bedeuten, die Rolle „Lead Architect“ auf zwei Personen, zum Beispiel Cassandra und Hector, zu verteilen, siehe Abbildung 4.

Abb. 4: Redundante Reserve

Um eine konsistente Dienstleistung sicherzustellen, müssen die beiden Personen eine gemeinsame Wissensbasis und Autorität teilen. Dies kann durch regelmäßige Kommunikation, gemeinsame Teilnahme an Meetings und gegenseitige Überprüfung der Arbeit erreicht werden. Redundanz und die damit verbundene individuelle Ineffizienz sind Schlüssel zu einer besseren Verfügbarkeit. Durch eine klare Kommunikation solcher Taktiken können Personen, die großen Wert auf individuelle Effizienz legen, vom globalen Vorteil überzeugt werden.

Lösung 2: Schatten (Shadow)

Die Schatten-Taktik (Shadow) führt vorübergehend eine Backup-Komponente ein, bevor die primäre Komponente offline geht. Nach der Wiederaufnahme der primären Komponente wird die Backup-Komponente schrittweise zurückgezogen. Im Vergleich zur redundanten Reserve beinhaltet Schatten eine kürzere operative Überlappung, die sich auf eine reibungslose Übergabe der Verantwortung konzentriert, siehe Abbildung 5.

Abb. 5: Schatten

Ähnliche Kataloge von Mustern und Taktiken für andere Anforderungstypen wie Leistung (Performance), Skalierbarkeit (Scalability) und Sicherheit (Security) sind ebenfalls im Buch von Len Bass sowie in ähnlichen Architekturressourcen zu finden.

Fehlersuche (Troubleshooting)

Soziotechnische Systeme können, wie technische Systeme, schlecht, fehlerhaft oder sogar dysfunktional operieren. Während es keinen universellen Ansatz für alle Arten von Problemen gibt, können zwei Leitprinzipien bei der Fehlersuche in soziotechnischen Systemen helfen:

• Fehler sind relativ zu Anforderungen.
• Probleme in komplexen Systemen sind Symptome eines strukturellen Durcheinanders (mess).

Fehler sind relativ zu Anforderungen

Wenn ein System nicht wie erwartet funktioniert, handelt es sich nicht automatisch um einen Fehler. Ein Fehler wird als Verhalten definiert, das den festgelegten Anforderungen widerspricht. Betrachten wir die folgenden Situationen:

• Das Projekt verläuft zu langsam.
• Technische Schulden häufen sich schnell an.
• Es gibt zu viele Meetings.

Diese Situationen sind zwar problematisch, bedeuten jedoch nicht zwangsläufig, dass sie behoben werden müssen – es sei denn, sie stehen im Widerspruch zu spezifischen Anforderungen. Beispielsweise:

• Das Projekt könnte langsam voranschreiten, weil kein Budget für zusätzliche Teammitglieder verfügbar ist.
• Technische Schulden könnten entstanden sein, weil ein Prototypcode weiterentwickelt wurde, der ursprünglich nur schnell erstellt wurde, um die Zustimmung der Projekt-Sponsoren zu erhalten.
• Zu viele Meetings könnten die Folge sein, wenn die Abstimmung zwischen verschiedenen Funktionen im Projekt wichtiger ist als Projektgeschwindigkeit, zum Beispiel in sicherheitskritischen Bereichen.

Bevor solche Probleme gelöst werden, ist es wichtig, neue Anforderungen zu definieren, Konflikte mit bestehenden Anforderungen zu identifizieren und deren Auswirkungen zu bewerten. Dieser Ansatz stellt sicher, dass Änderungen bewusst vorgenommen, effektiv kommuniziert und mit den übergeordneten Projektzielen abgestimmt werden.

Probleme in komplexen Systemen sind Symptome eines strukturellen Durcheinanders

Der prominente Systemdenker Russell Ackoff stellte fest, dass Probleme in komplexen Systemen oft in einem größeren Durcheinander (mess) verwoben sind [2]. Das Lösen isolierter Probleme ist ineffektiv; stattdessen sollte der Fokus darauf liegen, das zugrunde liegende Durcheinander aufzulösen.

Beispiel: Zu viele Meetings

Ein häufiges Problem in soziotechnischen Systemen ist die Überlastung durch Meetings. Typische Lösungen, welche oft während Projekt-Retrospektiven vorgeschlagen werden, sind:

• Alle Meetings nur vormittags oder nur nachmittags einzuplanen, um ungestörte Fokuszeiten zu schaffen.
• Teammitglieder zu ermutigen, Meetings abzulehnen, bei denen sie nichts beitragen können.
• Moderatoren für jedes Meeting zu bestimmen und Agenden im Voraus bereitzustellen, um die Effizienz der Meetings zu erhöhen.

Während diese Strategien Symptome adressieren, lösen sie nicht die eigentliche Ursache für zu viele Meetings. Um das Durcheinander zu identifizieren, ist eine Analyse des soziotechnischen Designs erforderlich.

Beispielsweise könnten zwei Teams, Team A und Team B, an zwei eng gekoppelten Komponenten arbeiten und deshalb ständig kommunizieren müssen, um ihre Arbeit abzustimmen. Diese Kopplung erzeugt eine hohe Meeting-Last. Eine mögliche Lösung könnte darin bestehen, die Komponenten zu einer einzigen zusammenzuführen, sodass ein Team die volle Verantwortung übernimmt, siehe Abbildung 6. Die beste Lösung hängt natürlich vom spezifischen Kontext und den Anforderungen ab.

Abb. 6: Meeting-Durcheinander

Dieses Beispiel verdeutlicht die Bedeutung von Ursachenanalysen und der Nutzung visueller soziotechnischer Designwerkzeuge, um Lösungen zu diskutieren und zu kommunizieren.

Sociotechnical Engineering in der Praxis

Sociotechnical Engineering lässt sich auch produktiv in der Praxis einsetzen. In Systems-Engineering-Projekten gibt es oft die Rolle des „Lead Systems Engineer“ (LSE), der primär für zwei Artefakte verantwortlich ist: die Systemanforderungen und das Systemdesign. Ganz ähnlich kann in Projekten eine neue Rolle eingeführt werden: der „Lead Sociotechnical Engineer“ (LSTE). Diese Rolle trägt die Verantwortung für zwei soziotechnische Artefakte: die Soziotechnischen Anforderungen (Sociotechnical Requirements, STR) und das Soziotechnische Design (Sociotechnical Design, STD). Der LSTE ersetzt oder ergänzt dabei die klassische Rolle des Projektleiters oder Projektmanagers.

Der LSTE ist somit die zentrale Rolle, die die Brücke zwischen Organisation und Technik schlägt und den Raum sowohl für organisatorische als auch technische Entscheidungen absteckt. Die beiden Artefakte, STR und STD, werden während des Projekts kontinuierlich erstellt, diskutiert, angepasst und kommuniziert.

Zu Beginn des Projekts:

• Die funktionalen Anforderungen werden analysiert, um die notwendigen Artefakte und Rollen zu identifizieren.
• Diese Analyse erleichtert die Einschätzung, welche Personen und Kompetenzen für das Projekt benötigt werden.
• Alle Entscheidungen fließen in die STR-Dokumentation ein und werden für relevante Stakeholder zur Überprüfung bereitgestellt.

Nach Projektstart:

● Die nicht funktionalen Anforderungen werden analysiert und in Zusammenarbeit mit dem Team diskutiert.

● Mithilfe kollaborativer Artefakt-Menschen-Rollen-Mappings wird die soziotechnische Architektur des Projekts dokumentiert und kommuniziert.

● Dokumentierte Anforderungen, Entscheidungen und Designs werden während des Projekts regelmäßig aktualisiert und bei Bedarf angepasst. Die resultierenden Entscheidungen und Entwürfe werden in den STR- und STD-Dokumentationen hinterlegt, für alle sichtbar gemacht und zur Überprüfung bereitgestellt.

Im Falle von Problemen:

• Zwei Prinzipien der Fehlersuche können herangezogen werden, um soziotechnische Herausforderungen zu bewältigen.
• Wichtig ist dabei, dass die Lösungsansätze und Entscheidungen in STR und STD dokumentiert werden, sodass sie weiterhin überprüfbar und kommunizierbar bleiben.

Die Erstellung und Pflege der beiden Artefakte, STR und STD, liegt zwar in der Verantwortung des LSTE, erfolgt jedoch als gemeinschaftlicher Prozess. Je nach Kontext werden mehrere Stakeholder als Reviewer oder Contributors einbezogen.

Fazit

Soziotechnische Systeme bestehen aus Menschen und Artefakten. Sie sind komplex und dynamisch. Während sich der Mainstream-Diskurs zu soziotechnischen Systemen auf die Kongruenz zwischen sozialen Strukturen und Code-Strukturen konzentriert, erweitert dieser Artikel die Diskussion um zwei zusätzliche Dimensionen:

• die Wiederverwendung von Systems-Engineering-Ansätzen für soziotechnische Systeme,
• die Berücksichtigung einer breiteren Palette von Artefakten, die von Menschen erstellt werden – nicht nur von Code –, als relevante Elemente soziotechnischer Systeme.

Diese beiden Dimensionen werden in einem Ansatz namens „Soziotechnisches Engineering“ eingeführt, der klassische Kategorien und Prinzipien des Systems Engineering auf soziotechnische Systeme überträgt. Darüber hinaus führt der Artikel das Konzept der Rollen als Services (Role-as-a-Service) ein, um die Brücke zwischen Menschen und Artefakten zu schlagen.

Diese Ansätze ermöglichen nicht nur die Wiederverwendung bewährter Methoden des Systems Engineering zur Navigation von Komplexität, sondern bringen auch die etablierte Sprache des Systems Engineering in den soziotechnischen Bereich. Dies erleichtert die Kommunikation und Entscheidungsfindung in Softwareorganisationen und versetzt sie in die Lage, die Herausforderungen soziotechnischer Systeme effektiver zu bewältigen.

Literaturangaben

[1] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, Addison-Wesley, 4. Auflage, 2021

[2] R. L. Ackoff, Ackoff's Best: His Classic Writings on Management, Wiley, 1999