Gut beraten, gut entwickelt – Systemisch-agile Sofwareentwicklung
In seiner Arbeit von 1968 formulierte Melvin Conway die nach ihm benannte (empirische) Gesetzmäßigkeit: "Jede Organisation, die im weitesten Sinne ein System entwirft, wird ein Design erzeugen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist." [1] Diese Gesetzmäßigkeit – als Conways Law bekannt – kann auf unterschiedliche Arten und Weisen interpretiert werden (EuroPLoP). Seit einiger Zeit ist auch der Begriff des inversen Conway-Manövers (Inverse Conway Maneuver) bekannt, das sich als Werkzeug versteht, eine Organisation so zu formen, dass das Ergebnis einem formulierten Architekturwunsch entspricht: "Idealerweise sind die technologische Struktur und die Geschäftsstruktur zueinander isomorph." [2] Dieser von Conways Law konstatierte Isomorphismus, der eine strenge formale Gleichheit zwischen System(design) und der Kommunikationsstruktur im Unternehmen beschreibt, hat also zwei Richtungen. D.h. Änderungen in der Unternehmenskommunikation beeinflussen notwendig die Struktur des Softwareproduktes, und umgekehrt beeinflusst (und steuert) eine Software notwendig die Prozesse, die sie abbildet.
Doch wie lassen sich nun diese Strukturen finden und beschreiben, und welche Auswirkungen hat dies auf die Softwareentwicklung? Dieser Artikel will einen Vorschlag wagen: Gängige Vorgehensweisen aus der Softwareentwicklung, wie agiles Arbeiten und Entwicklung nach dem Prinzip des Domain-driven Design (DDD) wie es Eric Evans vorschlägt [3], werden mit einer soziologischen Theorie, der Systemtheorie nach Niklas Luhmann [4], und dem Konstruktivismus in Verbindung gebracht. Wir zeigen auf, wo hier Synergien bestehen, um das Softwareprodukt für den Endanwender sinnvoller zu entwickeln.
Nach unserer Auffassung offenbaren das DDD und die Systemtheorie bereits in ihrer Terminologie einen hohen Grad an Ähnlichkeit. Anhand eines realen Beispiels, dem Transportgeschäft von Containerwaren über Containerterminals im Binnenland von und zu den großen Seehäfen, wird das Potential in der Kombination dieser Theorien aufgezeigt.
Domänengetriebene Softwareentwicklung
Spätestens seit der (andauernden) Diskussion um den Architekturstil von Microservices ist DDD wieder allgegenwärtig und als gute Praxis in der Softwareentwicklung beworben. DDD ist eine Kategorie des modelgetriebenen Softwaredesigns. Wir beginnen mit einer kurzen Rekapitulation dieser Art der Softwareentwicklung.
Ein modelgetriebenes Softwaredesign (Modeldriven Softwaredesign, MDD) ist, nach Eric Evans, eines, in dem einige Elemente der Software eng an ein Modell gekoppelt sind, wobei Modell und Implementierung in stetigem Einklang gehalten werden (Evans). Das DDD ist hier ein Ansatz, der als Modell eine Domäne entwickelt und in Software abbildet (i. d. R. umgesetzt als ein objektorientiertes Klassenmodell), die der Domäne des Produktes entspricht (Evans). Konsens über das zu entwickelnde Produkt zwischen Entwicklerteam und Stakeholdern wird erlangt, indem über dieses Modell in einer einheitlichen Sprache (ubiquitous language) gesprochen und das Modell gemeinschaftlich entwickelt wird. In diesem Sinne ist ein Kontext ein Szenario, in dem ein Wort oder eine Aussage sinnvoll ist. Also kann auch über ein Modell nur in einem Kontext sinnvoll gesprochen werden. Ein begrenzter Kontext (bounded context) ist eine Beschreibung einer Grenze, innerhalb derer ein Modell definiert und anwendbar ist. In der Regel sind die Grenzen gegeben durch Systemschnitte oder das Team, das innerhalb dieses Kontextes arbeitet (Evans). Dies legt für einen Kontext auch einen Softwarearchitekturstil nahe, der eine gute Separation von Modell(-implementierung) und technisch notwendigen Mechanismen wie Speicherung, Reaktion auf Datenänderungen, Anzeige etc. zulässt, wie es beispielsweise eine hexagonale Architektur leisten kann (Richardson).
Ein Modell hat also innerhalb eines Kontextes eine ganz spezielle Bedeutung, die sich im Laufe der Zeit schärft und verändert. Durch die Abgrenzung werden Abhängigkeiten zu anderen Teams minimiert. Nur wo Information über die Kontextgrenzen hinweg ausgetauscht werden muss (sowohl in den Kontext eingehende als auch aus ihm ausgehende Informationen), muss sich Gedanken über ein gemeinsames Verständnis gemacht werden. Innerhalb eines begrenzten Kontextes aber werden Informationen vom Team unabhängig, im Rahmen des zugrundeliegenden Modells interpretiert und verarbeitet.
Diese Grundgedanken des DDD rücken in den aktuellen Trends wieder in einen starken Fokus. Die Idee, Teams zu entkoppeln, um sie handlungsfähiger zu machen, und ein kontinuierlicher Ausrollprozess (Continuous Delivery), sind beides Kernelemente kurzer Lieferzeiten und unabhängiger Wartung und Pflege von Softwarekomponenten unterschiedlicher Anforderungen.
Systemtheorie und Konstruktivismus – agil gedacht
Als nächstes widmen wir uns der Systemtheorie nach Niklas Luhmann, soweit wir diese für unsere Beispielanalyse benötigen. Dabei werden auch wichtige Ideen aus dem Konstruktivismus diskutiert.
Systemtheorie nach Luhmann
In der Systemtheorie nach Niklas Luhmann ist in sog. sozialen Systemen in letzter Konsequenz alles auf die elementare Operation der Kommunikation zurückzuführen. Dies macht diese universelle Theorie der Kommunikation zugleich schwer greifbar und reizvoll für die Untersuchung abstrakter Zusammenhänge.
Ein System wird dabei als "ein Satz von Elementen und Objekten zusammen mit den Beziehungen zwischen diesen Objekten und ihren Merkmalen"[5] verstanden, wobei wir uns in diesem Artikel auf soziale Systeme konzentrieren wollen. Kommunikation ist die kleinste Einheit in einem sozialen System, und bringt die Merkmale Information, Mitteilung und Verstehen mit sich, wobei der Empfänger in der Kommunikation das Verstehen bestimmt (was allerdings nicht mit Nachrichtenbedeutung gleichzusetzen ist). Kommunikation kann damit (fast) alles sein, von Mensch-zu-Mensch-Gesprächen über Beziehungen in Unternehmensabteilungen bis hin zu Printmedien, und findet immer und überall statt. Paul Watzlawicks erstes Axiom ergänzt diesen Gedankengang: "Man kann nicht nicht kommunizieren."[6] In der Kommunikation gibt es wiederkehrende Muster, die sog. Regelkreise. Diese haben eine ähnliche Wirkung wie sich ständig verstärkende Nervenbündel im Gehirn, sind also durch wiederkehrende Kommunikation sich selbst erhaltende und verstärkende (abstrakte) Orte von Kommunikation. In der Luhmannschen Theorie ist dies auch eine Kernidee: Ein soziales System will sich selbst aus sich heraus erschaffen und fortbestehen [7], wobei die Richtung der Entwicklung weder "notwendig noch unmöglich" ist (Kontingenz), und definiert sich selbst über Kommunikation als Abgrenzung von "allem anderen", der Außenwelt, welche wiederum aus anderen sozialen Systemen bestehen kann. Grundsatz ist hier die operationale Geschlossenheit eines sozialen Systems, die Annahme, dass kein soziales System Zugriff auf die Operationen eines anderen hat. Hängen soziale Systeme voneinander ab, so sind sie strukturell gekoppelt. Diese strukturelle Kopplung findet sich in einer weiteren grundlegenden Idee Luhmanns wieder: Die menschliche Psyche und deren Operationen (in Form von Gedanken) sind notwendige Umwelten für soziale Systeme. Das gilt auch für das organische System. Abb. 1 soll die Beziehungen zwischen sozialen Systemen und ihren Umwelten verdeutlichen. Ohne diese Umwelten könnten soziale Systeme nicht existieren, dennoch sind die Umwelten kein Teil von ihnen.
Kommunikation über Systemgrenzen hinweg findet, vereinfacht gedacht, nur als Reiz statt, der auf die Systemgrenze des sozialen Systems trifft, und dann im Rahmen der begrenzten Möglichkeit der Informationsverarbeitungskapazität in dessen Inneren losgelöst interpretiert wird. Dabei wird die Komplexität, d. h. "der Grad der Vielschichtigkeit, der Vernetzung und die Folgelastigkeit eines Entscheidungsfeldes" reduziert [8]. Komplexität als solche gibt es zwar nicht, allerdings ist aus Sicht eines Systems die Umweltkomplexität höher als die eigenen Möglichkeiten, diese im Inneren zu verarbeiten. Durch die Vielzahl an Operationsmöglichkeiten, die sog. Eigenkontingenz des Systems, entsteht Komplexität im Inneren des Systems, welche wiederum durch Strukturen und Prozesse autonom und selbstorganisiert reduziert wird. Auf der Inputseite von sozialen Systemen steht dabei die Frage nach Relevanz: "Was aus der Umwelt ist wirklich wichtig?" Auf der Outputseite steht die Frage nach der Strategie der Handlungsmöglichkeiten. Das zentrale Steuerungskriterium zwischen Input und Output in sozialen Systeme ist der Sinn [8].
Die Systemtheorie bietet somit einen weitreichenden Ansatz, um Gesellschaft im Allgemeinen, als soziale Systeme, aber auch Unternehmen oder einzelne Teams im Speziellen, zu beschreiben.
Konstruktivismus und Auswirkungen auf das Requirements Engineering
Um Luhmanns Ideen zu verstehen, ist es notwendig, noch einige Ansätze aus einer anderen zentralen Theorie, dem Konstruktivismus, einzuführen. Diese helfen uns, die Prozesse während des Requirements Engineering (RE) besser zu verstehen und lassen sich auch auf den Softwareentwicklungsprozess anwenden.
Soziale Systeme werden erst relevant in der Beobachtung. Beobachten heißt Unterscheidung treffen, heißt "etwas als dies, und nicht [als] das, zu bezeichnen"[9]. Allerdings gibt es keine Objektivität in der Beobachtung, denn keine Beobachtung kann sich im Moment der Beobachtung selbst beobachten. Der so erzeugte blinde Fleck rückt das "Wie" ("Wie konstruiert der Beobachter seine Realität?") in das Zentrum, nicht das "Was" ("Was beobachtet der Beobachter?"). Realität ist immer eine Konstruktion desjenigen, der sie beschreibt (Realitätskonstruktion), und damit sind auch verschiedene Beobachtungen derselben Sache in der Regel verschieden. Realitätskonstruktionen sind jedoch nicht beliebig. Sie ergeben sich zum einen aus den bereits gemachten Erfahrungen und deren Bewertungen (Historizität), zum anderen aus der Eigendynamik des wahrnehmenden Systems des Beobachters [10]. Damit die jeweiligen Realitätskonstruktionen für sich anschlussfähig bleiben können, müssen sie einer Überprüfung des eigenen Handelns standhalten und in der Erfahrung des Beobachters überleben (Viabilität) [11]. Denn nur so kann das Fortbestehen im Sinne der Autopoiesis sichergestellt werden.
Diese Ideen wollen wir nun auf das RE anwenden. Typischerweise wird im RE von "einer" Realität ausgegangen, die nur hinreichend gut und objektiv beobachtet werden muss. Es werden "reale" Prozesse analysiert, beschrieben und anschließend formalisiert. Die konstruktivistische Sichtweise hat nun starken Einfluß auf die praktische Durchführung und das Verständnis des RE. Abb. 2 zeigt einen erweiterten, systemisch-konstruktivistisch gestalteten Sachverhalt.
Eine Person des RE (rot dargestellt) beobachtet ein soziales System nicht nur "einfach", um daraus wichtige Anforderungen abzuleiten, sondern wird durch die Beobachtung selbst ein Teil des sozialen Systems. Folglich beobachtet die Person sich in der Interaktion mit dem sozialen System. Die daraus gewonnenen Beobachtungen, als Unterscheidungen verstanden, werden zu ihrer Realitätskonstruktion, und letztlich zu Anforderungen. Diese Anforderungen wiederum bilden die Grundlage für weitere Realitätskonstruktionen der jeweiligen Softwareentwickler, die diese Anforderungen in Software umsetzen sollen. Dies ist eine Realitätskonstruktion höherer Ordnung.
Eine weitere Konsequenz aus dem Konstruktivismus ist die Frage, wie ein einheitliches Verständnis zu einer Sache in einem sozialen System zu denken ist: Nämlich als die Schnittmengen verschiedener Realitätskonstruktionen. Dies resultiert aus der Viabilität von Realitätskonstruktionen. Im besten Falle kann also ein Realitätskonsens angestrebt werden, im Sinne "des gleichen Verstehens derselben Sache". Besteht ein hoher Realitätskonsens zu einer Sache in einem sozialen System, kann dieser Konsens mit dem zieldienlichen Gelingen der Sache korrelieren. Sind sich z. B. die Mitarbeiter einer Abteilung einig über gemeinsame Arbeitsabläufe, so werden diese von jedem gleich verstanden und ausgeführt. Auf das RE übertragen bedeutet dies, dass die Person vom RE einen hohen Realitätskonsens auf der Seite der Anforderungsbeschreibung anstrebt (vgl. Abb. 3).
Ähnliche Überlegungen gelten auch für die Softwareentwicklung (vgl. Abb. 4). Während ein hoher Realitätskonsens des zu beschreibenden sozialen Systems (blaues Venn-Diagram, RKM1-5) gut funktionierende Prozesse und Arbeitsabläufe vermuten lässt, spielt ein hoher Realitätskonsens der Softwareentwickler (gelbes Venn-Diagram, RKE1-5) eine maßgebliche Rolle für den Erfolg des Softwareproduktes. Jedoch bedeutet ein hoher Realitätskonsens unter den Entwicklern RKE1-5 nicht automatisch eine hohe Deckung mit dem Realitätskonsens der Mitarbeiter RKM1-5 (vgl. Abb. 4, Überlappung gelber und blauer Kreis). In den meisten Fällen ist eine hohe Überschneidung wünschenswert. Konkret hat das zur Folge, dass das Softwareprodukt aus Sicht des sozialen Systems Prozesse und Arbeitsabläufe der Mitarbeiter gut abbildet. Die Software wird als Unterstützung wahrgenommen und erfährt eine weitreichende Akzeptanz. Wie sich die Schnittmenge beider Kreise erhöhen lässt, soll im nächsten Abschnitt erläutert werden.
Systemische Agilität
Da alles Erleben immer Konstruktionen von Realitäten darstellt, kann eine Softwareentwicklung, die im Sinne eines Wasserfall-Vorgehens (Pflichten- und Lastenheft) gestaltet wird, i. d. R. nur wenig zielführend sein. Hoher Realitätskonsens innerhalb eines Softwareentwicklungsteams lässt sich nur durch erhöhte Kommunikation und Interaktion der Softwareentwickler erreichen. Ebenso braucht es kontinuierliches Feedback von Anwendern und Kunden, die die Software produktiv nutzen, um die Schnittmenge der Realitätskonsense zu erhöhen. Gleichzeitig muss der Prozess aber genügend Freiräume zum Lernen und für Veränderungen bereithalten. Hier kann ein agiler Softwareentwicklungsprozess zur Anwendung kommen.
Ziel agiler Softwareentwicklung ist es, möglichst schnell Kunden- und Anwendermehrwert zu erzeugen. Mit Hilfe kurzer, iterativer Produktionszyklen, sog. Sprints, wird kontinuierlich Mehrwert in Form von Softwareinkrementen ausgerollt und den Anwendern zur Verfügung gestellt. Durch den intensiven Austausch zwischen Kunden und Anwendern mit den Softwareentwicklern während der Produktentwicklung kann eine zielgerichtete Reifung des Produktes erfolgen und eine hohe Transparenz sichergestellt werden.
Abb. 5 verdeutlicht anhand des gemeinsamen Realitätskonsens von Anwendern und Softwareentwicklern, wie sich die Akzeptanz eines Softwareproduktes entwickeln und verändern kann. Während der ersten Iterationen wird in den meisten Fällen die Schnittmenge der beiden Realitätskonsense der Softwareentwickler und der Mitarbeiter der Organisation gering sein. Teile des Softwareproduktes können bei den Anwendern zu Irritationen führen, wenn beispielsweise Prozesse und Arbeitsabläufe der Software angepasst werden müssen (ggf. bewusst im Sinne eines inversen Conway-Manövers). Dies kann die Akzeptanz der Software beeinflussen, weswegen die Schnittmenge beider Realitätskonsense zunächst einmal geringer werden kann: Der blaue und der gelbe Kreis entfernen sich voneinander (vgl. Iteration N+1).
Mit fortlaufender Zahl an Iterationen kann jedoch die Schnittmenge beider Kreise sukzessive erhöht werden. Prozesse in der Organisation passen sich dem Softwareprodukt an, und umgekehrt bildet die Software besser die anerkannten Prozesse ab. Iteratives Arbeiten bietet die Chance, die verschiedenen Realitätskonstruktionen zielgerichtet zu harmonisieren, da die Software immer wieder einen "Realitätscheck" erfährt. Crossfunktional (von User-Experience über Entwicklung bis zum Betrieb) aufgestellte Entwicklerteams, kontinuierliches Ausrollen von Softwareinkrementen und kontinuierliche Qualitätssicherung der Software (CD und CI) sind nur einige Hilfsmittel aus dem agilen Entwickeln und der DevOps-Kultur, die hier gewinnbringend angewendet werden können (vgl. [12]).
Systemisch-konstruktivistische Domänenmodellierung
Bereits diese reduzierten Beschreibungen des DDD und der Luhmannschen Systemtheorie offenbaren starke Parallelen und sprachliche Ähnlichkeiten zueinander.
Sowohl DDD als auch die Systemtheorie behandeln abgeschlossene, sich über Unterscheidung und Relevanz definierende Kontexte, in denen (über Sprache) kommuniziert wird. Soziale Systeme und begrenzte Kontexte haben also starke Ähnlichkeit in ihren Definitionen. Kommunikation über System- und Kontextgrenzen hinweg findet über Reize statt, im Bereich der Softwareentwicklung in Form von Nachrichten. Gerade bei entkoppelten Teams ist hier kein (starker) Einfluss mehr darauf zu nehmen, wann und wie der Reiz, den eine Nachricht auslöst, verarbeitet wird. Die Reaktion auf einen Reiz ist, im Sinne der Domänenevents, wiederum eine Nachricht, also ein Reiz, der die Veränderung innerhalb der Domäne kommuniziert.
Wesentlich ist es an dieser Stelle, den Begriff des Modells zu verstehen. Häufig wird der Modellbegriff nach Herbert Stachowiak verwendet: Ein Modell ist hiernach "eine beschränkte und zielgerichtete Beschreibung der Realität" [12]. Im Sinne der Systemtheorie kann ein Modell aber nicht mehr als ein pragmatisch verkürztes Abbild eines Originals verstanden werden, da das Original selbst objektiv gar nicht fassbar ist. Damit gilt es, die Modelldefinition zu korrigieren: "Ein Modell ist eine beschränkte und zielgerichtete Beschreibung einer Realitätskonstruktion durch einen Beobachter".
Von (verteilten) Entwicklerteams wird damit eine (vom RE) konstruierte Realität beobachtet. Deren gemeinsame Realitätskonstruktion wird wiederum beeinflusst durch die Kommunikationsstruktur der Organisation (verstanden als soziales System), die die Software benutzen soll. Hier kommt Conways Law in die Betrachtung.
Anwendung: Ein Beispiel aus der Containerlogistik
Die Theorien sollen nun anschaulich im Rahmen eines Projektes aus der Containerlogistik im Hinterland erprobt werden. Verschiedene Teilnehmer partizipieren an einer Logistikkette für den Transport von Waren in Containern zu Kunden im Hinterland, respektive umgekehrt vom Kunden im Hinterland nach Übersee.
Abb. 6 zeigt schematisch den typischen Aufbau eines Containerterminals, wie es ähnlich an verschiedenen Standorten unterschiedlicher Unternehmen innerhalb Deutschlands zu finden ist. Bezeichnend für Prozesse auf Containerterminals sind immer wiederkehrende Kontexte und Handlungen. Ein Beispiel: Ein Kunde beauftragt die Salesabteilung eines Containerlogistikunternehmens für den Export seiner Ware nach Übersee – ein Auftrag entsteht. Ein Disponent reserviert daraufhin einen Truck, der den Container im Rahmen des Auftrags transportieren soll. Zum gegebenen Zeitpunkt verlässt dieser Truck dann das Containerterminal mit einem leeren Container und fährt ihn zum Ort der Beladung. Der beladene Container wird anschließend zum Terminal zurückgebracht. Am Gate (dem Einfahrtsort zum Terminal) werden Berechtigungen und Sicherheitsvorschriften geprüft. Ist alles wie vorgeschrieben, darf der Truck mit dem Container auf das Terminal. Der Container wird dann von einem sog. Stacker vom Truck gehoben und auf das Terminal genommen, um dieses in Richtung Seehafen, mit einem Binnenschiff, Zug oder anderen Truck, später wieder zu verlassen.
Zukünftig sollen möglichst viele Schritte im Containertransport in Verbindung mit einem gültigen Transportauftrag (voll)automatisch erfasst und so die Prozesse rund um die Containertransporte optimiert werden. Um dies zu bewerkstelligen, bedarf es einer adäquaten Beschreibung aller relevanten Prozesse, Abläufe und Handlungen, die den Transportauftrag betreffen. Klassisch ist dies die Aufgabe des RE. Die Systemtheorie, in Verbindung mit Ansätzen aus dem DDD, zeigt dabei bedeutsame Herausforderungen auf, die bereits beim RE berücksichtigt werden müssen. Zum einen kann "die Realität" nicht objektiv beschrieben werden, also können auch die fachlichen Prozesse und Abläufe an einem Terminal nicht objektiv erfasst werden: Der Beobachter "realer Prozesse" beobachtet immer sich selbst in Wechselwirkung mit dem System "Terminal" (vgl. Abb. 2). Weiterhin stellt sich die Frage nach den abgeschlossenen Kontexten auf einem Terminal: Sind Gate, Sales oder Disposition abgeschlossene Kontexte, oder müssen hier weitere relevante Interaktionen gefunden werden?
Die Theorie der sozialen Systeme besagt, dass sich soziale Systeme überall dort bilden, wo Kommunikation regelhaft wird. Dadurch bilden sich Strukturen und Prozesse aus, die Anschlusskommunikation und Autopoiesis des Systems ermöglichen. Die Systemgrenze des sozialen Systems muss sich dabei aber nicht auf offensichtliche (z. B. dem Organigramm des Unternehmens entstammende) Kontexte wie z. B. ein Gate begrenzen. Abgeschlossene Kontexte können sich auch, entsprechend der sozialen Systeme, auf einem Terminal finden lassen.
Kommunikation und Kontexte am Terminal
Um die Prozesse an einem Hinterlandterminal zu digitalisieren, ist es im RE unabdingbar, die bestehenden Prozesse zu analysieren und zu formalisieren. Das Ergebnis ist zunächst, unabhängig vom späteren Softwareentwicklungsprozess, eine schriftliche Ausarbeitung der Anforderungen (seien es Lasten- und Pflichtenhefte, User Stories oder anderes). Wesentlich ist hier, zu verstehen, dass der Erheber der Anforderungen unweigerlich auch die Anforderungen mitbestimmt! So gesehen beschreibt er nicht die gemeinschaftlich akzeptierte Wahrnehmung der Prozesse am Terminal, also den Realitätskonsens der Terminalmitarbeiter, sondern er beschreibt sich in Wechselwirkung mit den Mitarbeitern und den Prozessen auf dem Terminal (vgl. Abb. 3). Das Ergebnis der Anforderungsanalyse wird dann an Entwicklerteams gegeben, die sich um deren Umsetzung kümmern. Der Realitätskonsens eines Entwicklerteams bzgl. des von ihm umzusetzenden Teils der Anforderungen ist dann eine Realitätskonstruktion höherer Ordnung (vgl. Abb. 4, gelbes Venn-Diagramm).
Requirements Engineering und Realitätskonstruktionen
Anzustreben ist dabei, die Konsense der Mitarbeiter am Terminal und der Softwareentwickler in Einklang zu bringen. Dabei empfiehlt es sich im Sinne der agilen Softwarentwicklung vorzugehen, wie sie oben beschrieben ist. Weiterhin ist nicht zu vernachlässigen, dass die Software wiederum die Arbeitsprozesse am Terminal beeinflusst und verändert. Dies ist eine gute Chance, über die gefundenen abgeschlossenen Kontexte nachzudenken, denn oft orientieren diese sich am Organigramm, z. B. an der Organisationsstruktur des Terminals (vgl. Abb. 7).
Die relevante Kommunikation kann aber auch eine andere sein als die durch die Terminalstruktur vorgegebene, wobei die Relevanz von Kommunikation bestimmt wird durch die Häufigkeit in der sie stattfindet und den Beobachter, der diese Häufigkeit beobachtet. Überall, wo sich Regeln, Regelkreise oder Prozesse herausbilden, entsteht auch Relevanz.
So kann sich z. B. eine regelmäßige Kommunikation zwischen der Organisationsstruktur "Gate" und "Disposition" zu einem relevanten sozialen System mit eigenen Regeln, Regelkreisen und Prozessen herausstellen, das bei der Anforderungserhebung berücksichtigt werden sollte (vgl. Abb. 8, blaue Kreise): Ein Gatemitarbeiter meldet ihm bekannte Verspätungen von Trucks an die Disposition, damit der Disponent nachfolgende Transportaufträge dieses Trucks anders koordinieren kann. Weiterhin hält der Disponent Rücksprache mit der Salesabteilung, damit diese mit dem Auftraggeber zusammen die Konsequenzen und Kosten der Verspätung für den Warentransport klären kann (spätere Lieferung oder Direkttransport).
Gut gefragt ist viel geholfen
Da die reale Welt nicht erfassbar ist, ist die Kunst im RE nun, die relevante Kommunikation zu finden und zu verstehen, wo sie stattfindet und wie sie sich verändert. Dazu ist es naheliegend, sich an Techniken aus der systemischen Therapie bzw. dem systemischen Coaching zu bedienen (wie z. B. zirkulärem oder hypothetischem Fragen, Skalierungsfragen oder Wunderfragen). Da in der Systemtheorie das "Wie" und nicht das "Was" im Vordergrund steht, könnten die Fragen an ein Gatemitarbeiter wie folgt lauten:
- Angenommen, Ihr Kollege aus dem Gate trifft sich mit Ihrem gemeinsamen Vorgesetzten, wie würde er Ihre Arbeitsabläufe im Gate beschreiben?
- Woran würden Sie am Ende des Tages erkennen, dass Sie einen gelungen Arbeitstag hatten? Woran würde es Ihr Kollege aus der Disposition bemerken?
- Auf einer Skala von 1 bis 10: Wie gut können Sie Ihren Job ausführen? Wofür könnte dabei aus Ihrer Sicht die 1 und die 10 stehen? Was müsste in Ihrem Arbeitsalltag passieren, damit Sie einen Schritt weiter in Richtung der 10 gehen könnten? Was dürfte auf gar keinen Fall passieren, dass Sie einen Schritt in Richtung der 1 gehen?
- Angenommen, über Nacht würde ein Wunder geschehen und viele tägliche Herausforderungen Ihrer Arbeit würden einfach so verschwinden. Was würde sich für Sie und Ihre Kollegen im Gate ändern? Was würden Sie dann konkret anders als zuvor machen?
Diese Art des "klugen Fragens" zielt darauf ab, die Beziehungen zwischen sozialen Systemen besser zu verstehen, Handlungsweisen und Interaktionen aufzudecken, und die gewohnten Sichtweisen differenzierter zu betrachten. In der Konsequenz kann so weniger offensichtliche Kommunikation sichtbar gemacht und ihre Relevanz beurteilt werden. Diese Kommunikationen werden ggf. im Sinne abgeschlossener Kontexte in separate Softwareservices gegossen und in die Softwarelandschaft integriert.
Ausblick
Der Diskussionsraum kann nun um eine weitere interessante Betrachtungsebene erweitert werden: Die Softwarearchitektur. Entsprechend Abb. 9 lässt diese sich als eine weitere Ebene neben den folgenden hinzu denken: Die blaue Ebene (Realität) zeigt die zugehörigen relevanten sozialen Systeme, die rote Ebene (beobachtete Realität (RE)) das Erfassen der Anforderungen. Die gelbe Ebene (Softwareentwicklung), zeigt die verschiedenen Teams für die Umsetzung des Softwareproduktes und geht der Frage nach dem Realitätskonsens innerhalb und zwischen den Teams nach. Die zuvor beschriebenen systemisch-konstruktivistischen Ansätze könnten Einfluss auf die Softwarearchitektur nehmen. Z. B. können Services als soziale Systeme gedacht werden, und diese, je nach Architekturstil, auf unterschiedliche Arten und Weisen miteinander kommunizieren. Diese Kommunikation zwischen den Services kann dann als ein weiteres, übergeordnetes soziales System verstanden werden. Welche Bedeutung haben Konzepte wie die operative Geschlossenheit, Autopoiesis und Regelkreise in einer solchen Softwarearchitektur? Gerade im Hinblick auf die momentan viel geführten Diskussionen um serviceorientierte Softwarearchitekturen wie Microservices oder System-of-Systems-Architekturen [13] ist dies eine spannende Frage für weiterführende Gedankenkonstruktionen.
- M. Conway: How Do Committees Invent? In: F. D. Thompson Publications, Inc. (Hrsg.): Datamation. Band 14, Nr. 5, April 1968, S. 28–31
Wikipedia: Melvin Conway, Conways Law - Thoughtworks Technology Radar: Inverses Conway-Maöver
- E. J. Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison Wesley
Wikipedia: Domain-driven Design - N. Luhmann: Die Realität der Massenmedien, 1996
Wikipedia: Systemtheorie (Luhmann) - A. D. Hall, R. E. Fagen: Definition of System, 1956
- P. Watzlawick, J.H. Beavin, D.D. Jackson: Menschliche Kommunikation: Formen, Störungen, Paradoxien, 1967
- H.R. Maturana und F. J. Varela: Der Baum der Erkenntnis: Die biologischen Wurzeln menschlichen Erkennens, 2009
- H. Willke: Systemtheorie I: Grundlagen: Eine Einführung in die Grundprobleme der Theorie sozialer Systeme, 2007
- N. Luhmann: Die Selbstbeschreibung der Gesellschaft und die Soziologie, 1992
- P. M. Hejl, H. K. Stahl: Management und Wirklichkeit. Das Konstruieren von Unternehmen, Märkten und Zukünften, 2000
- E. Glasersfeld: Wissen, Sprache und Wirklichkeit. Arbeiten zum radikalen Konstruktivismus, 1987
- Wikipedia: Modell
- C. E. Cuesta, E. Navarro, U. Zdun: Synergies of system-of-systems and microservices architectures, SiSoS@ECSA '16 Proceedings of the International Colloquium on Software-intensive Systems-of-Systems at 10th European Conference on Software Architecture Article No. 1
Abbildungen:
www.freepik.com
