Mit modernen Methoden zur Organisation von Entwicklungsteams wie Team Topologies rücken die Einflussmöglichkeiten von Softwarearchitekten in den Vordergrund.
Scheinbar geht es bei Softwarearchitektur nur um die Strukturierung von Software und die Umsetzung von nicht funktionalen Anforderungen. Aber in Wirklichkeit ist die Software für Menschen da und Menschen schreiben die Software.
Daher ist es notwendig, sie als ein soziotechnisches System zu begreifen. Das hat Auswirkungen auf das Verständnis von Softwarearchitektur.Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices. Der Begriff Soziotechnisches System steht für eine organisierte Menge von Menschen und mit diesen verknüpfte Technologien, die in einer bestimmten Weise strukturiert sind, um ein spezifisches Ergebnis zu produzieren. Er geht auf Forschung unter anderem im Steinkohlebergbau in Großbritannien in den 1950er-Jahren zurück. Die Idee von soziotechnischen Systemen ist somit nicht neu und schon gar keine Mode. Eine Kernerkenntnis ist, dass der Erfolg eines Unternehmens davon abhängt, wie es als soziotechnisches System funktioniert, nicht einfach als ein technisches System mit ersetzbaren Individuen, die hinzugefügt werden und sich anpassen müssen. Die Bezeichnung sagt bereits, worum es geht: Das System besteht aus einer technischen Komponente und einer sozialen Komponente . Beide lassen sich nur gemeinsam betrachten, da sie eng miteinander verknüpft sind. Deswegen muss man auch menschliche Kommunikation neben der Mensch-Maschine-Kommunikation betrachten. Dieser Ansatz ist für Softwareentwicklung und -architektur gleich aus mehreren Gründen interessant: Erstens wird Softwareentwicklung oft als eine rein technische Aufgabe begriffen und betrieben. Das ist sie aber nur scheinbar. Software als soziotechnisches System zu behandeln, birgt die Chance, wesentliche Verbesserungen zu erreichen. Zweitens löst die meiste Software keine rein technischen Probleme, sondern muss für Anwenderinnen und Anwender sowie andere Stakeholder einen wirtschaftlichen Nutzen haben. Damit steht die Software in einem wichtigen Verhältnis zu dieser Personengruppe, da der Wert der Software sich an dem wirtschaftlichen Nutzen für diese Gruppe orientiert. Dieser soziale Aspekt ist zentral für den Erfolg eines Softwareentwicklungsprojekts. Und schließlich wird Software in Teams implementiert. Auch bei der Entwicklung gibt es also ein soziales Geflecht, das es zu verwalten gilt. Wenn man diese Aufgabe besonders gut erfüllt, wird man effektiv und effizient entwickeln. Tatsächlich steht Softwarearchitektur in einem engen Zusammenhang mit beiden sozialen Systemen – Entwickler und User . Softwarearchitektur muss eine technische Lösung finden, die Nutzerinnen und Nutzer ausreichend unterstützt. Dabei sind Qualitäten der Software wie Benutzerfreundlichkeit, Performance, Skalierbarkeit oder Sicherheit zu betrachten. Dieser Teil der Architektur ist daher nur im Zusammenspiel mit diesem sozialen System bewertbar. Eine Architektur lässt sich nur daran messen, ob sie ausreichende Qualitäten für die Benutzergruppe mit sich bringt. Was für einige Personen subjektiv unmöglich zu benutzen ist, kann für andere akzeptabel oder gar ideal sein – man denke nur an die Auseinandersetzungen zu Editoren wie Vim oder Emacs. Softwarearchitektur bietet für Developer eine Strukturierung des Codes und muss für User die Einhaltung der Qualitäten garantieren . Die Aufteilung eines Systems in Module dient dazu, die Komplexität des Systems beherrschbar zu machen. Damit ist die Modularisierung nur im Zusammenspiel mit dem jeweiligen Entwicklungsteam bewertbar. Auch eine scheinbar gute Modularisierung kann für das Team schwer verständlich sein und zu geringer Produktivität führen. Beispielsweise kann ein Team ein System ohne eine gute Übergabe von einem anderen Team übernommen haben, sodass das neue Team es trotz guter Modularisierung schwer verstehen und ändern kann.Es ist auch denkbar, dass das System zwar schlecht strukturiert ist, aber das Team sich über einen längeren Zeitraum an diese Struktur gewöhnt hat und daher das System ausreichend gut ändern kann. Dann kann das Team die Software schwerlich abgeben, weil ein neues Team Schwierigkeiten hätte, sie zu verstehen. Das ist weniger ein technisches Problem, sondern lässt sich als ein soziales Problem auffassen., dass eine Organisation ein System entwickeln wird, dessen Design die Kommunikationsstrukturen der Organisation kopiert. Für die Softwareentwicklung bedeutet das beispielsweise: Wenn zwei Teams zwei Aufgaben haben und darüber bei Bedarf miteinander kommunizieren, werden sie in der Software zwei Module aufbauen, die eine Schnittstelle haben. Klassisch hat man das Gesetz von Conway eher als ein Hindernis begriffen: Wenn Teams in einer bestimmten Art organisiert sind, können sie nur bestimmte Architekturen erstellen. Sind ein UI- und ein Backend-Team vorhanden, werden auch ein UI und ein Backend in der Architektur entstehen. Dabei wird jedoch das Organigramm mit Kommunikation verwechselt. Aber Menschen und Teams kommunizieren auch dann, wenn sie im Organigramm keine offensichtlichen Beziehungen besitzen. Zwar kann das Organigramm einen wesentlichen Einfluss auf die Kommunikation ausüben, aber es ist nicht deckungsgleich. Das ist auch eine gute Nachricht: Während das Organigramm statisch ist, kann jede involvierte Person die Kommunikationsflüsse im Projekt beeinflussen. Aus dem Zusammenhang zwischen Kommunikation und Architektur ergibt sich ein weiteres Problem: Wenn die Kommunikation nicht mehr effektiv ist oder zusammenbricht, leidet die Architektur des Systems darunter. Gerade bei großen Projekten ist es schwierig, eine gute Kommunikation zu bewahren. Daher kann es insbesondere hier dazu kommen, dass zunächst die Kommunikation schwierig und dann die Architektur in Mitleidenschaft gezogen wird. Solche Probleme hat Melvin Conway schon 1967 im ursprünglichen Paper zu seinem Gesetz beschrieben. Wenn Softwarearchitektinnen und -architekten die Qualität der Architektur erhalten oder gar verbessern wollen, müssen sie auf die Kommunikation im Projekt Einfluss nehmen und gewährleisten, dass sie funktioniert. hat sich im Rahmen der Microservices-Bewegung das Verständnis für das Gesetz von Conway gewandelt: Statt es als Hindernis zu verstehen, will man es nun für die Gestaltung der Architektur nutzen. Wenn Teams definiert werden und jedes eine bestimmte Verantwortung erhält, werden diese Teams voraussichtlich jeweils ein Modul oder einen Microservice implementieren, der ihrer Verantwortung entspricht. Das Aufstellen der Organisation auf eine bestimmte Weise definiert somit indirekt die Architektur. Das Inverse Conway Maneuver versteht Software demnach als soziotechnisches System und wirkt durch Maßnahmen auf der sozialen Seite auf die technische ein.Dieser Link ist leider nicht mehr gültig. Links zu verschenkten Artikeln werden ungültig, wenn diese älter als 7 Tage sind oder zu oft aufgerufen wurden.
IT Projektmanagement Softwarearchitektur Softwareentwicklung Soziotechnische Systeme Team Topologies
Deutschland Neuesten Nachrichten, Deutschland Schlagzeilen
Similar News:Sie können auch ähnliche Nachrichten wie diese lesen, die wir aus anderen Nachrichtenquellen gesammelt haben.
Stellantis patentiert Schaum-System gegen BatteriebrändeBatteriebrände könnten durch einen Schaum gelöscht werden, der sich im Akkupaket bildet, wenn eine spezielle Flüssigkeit mit Kühlmittel reagiert.
Weiterlesen »
Streaming-System: Shirin David stimmt Grönemeyers Kritik zuHerbert Grönemeyer ist genervt von den knauserigen Streamingdiensten. Der Kritik des Musikers stimmt nun eine unerwartete Verbündete zu.
Weiterlesen »
Diablo 4: Fans feiern neues Crafting-SystemDie Spieler von Diablo 4 sind begeistert vom neuen Crafting-System, das mit Season 11 eingeführt wurde. Trotz des Zufallsfaktors, der Teil des Systems ist, sehen die Fans darin eine willkommene Verbesserung gegenüber den vorherigen Systemen.
Weiterlesen »
Deutscher Sieg bei Biathlon World Team Challenge durch Hettich-Walz und StrelowJanina Hettich-Walz und Justus Strelow sichern Deutschland den ersten Sieg bei der Biathlon World Team Challenge seit neun Jahren. Das deutsche Duo dominierte den Massenstart und die Verfolgung in Gelsenkirchen vor Frankreich und Norwegen.
Weiterlesen »
World Team Challenge auf Schalke: Janina Hettich-Walz und Justus Strelow gewinnen in Gelsenkirchen vor FrankreichJanina Hettich-Walz und Justus Strelow haben bei der stimmungsvollen Biathlon-Show auf Schalke die neunjährige deutsche Durststrecke eindrucksvoll beendet.
Weiterlesen »
Bau: Chef zahlte Schwarzlöhne – Zoll deckt System aufSangerhausen (sa) - Ein Unternehmer aus dem Landkreis Mansfeld-Südharz ist wegen der Beschäftigung von Scheinselbstständigen und wegen Steuerhinterziehung
Weiterlesen »