Agile überdenken

Conway 2.0: Wie Architekturstile agile Zusammenarbeit fördern oder behindern

Stefan Toth

© iStock / artishokcs

Die Architektur Ihres Systems ist nicht allein eine technische Frage. Die Strukturierung des Systems, das Kommunikationsdesign und andere architektonische Fragestellungen setzen Grenzen für die Möglichkeiten des agilen Arbeitens, beeinflussen, wie Teams aufgestellt werden können und bestimmen mit, wie sich Architekturarbeit organisieren lässt. Dieser Artikel zeigt, was agile Softwareentwicklung uns über Teams und Zusammenarbeit lehrt und wie die technische Architektur hier helfen kann.

1968 formuliert Melvin Edward Conway eine Beobachtung, die später als „Conway’s Law“ Berühmtheit erlangen wird: „Organisationen, die Systeme modellieren, […] sind auf Modelle festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“

Conways Überlegungen werden meist mit der Definition von Schnittstellen und der Systemstruktur in Verbindung gebracht. So versuchen z. B. manche Organisationen, lose Kopplung durch organisatorische Ferne zu fördern. In der momentanen Diskussion zu Systemarchitekturen nimmt Conway, fast fünfzig Jahre nach seiner Feststellung, wieder eine prominente Rolle ein. Wie schaffen es Firmen wie Spotify, Netflix oder Amazon, im Großen sehr effektiv zu arbeiten? Wie können dort hunderte Entwickler an einem Produkt arbeiten, ohne an Dynamik und Reaktionsvermögen einzubüßen? Für schnelle Reaktion auf Marktänderungen werden längst nicht nur Zusammenarbeitsmodelle und Kommunikationsstrategien entwickelt ‑ auch Architekturansätze werden als Teil der Gleichung erkannt. Henrik Kniberg sagt über Spotify: „The technical architecture is hugely important for the way we are organized. The organizational structure must play in harmony with the technical architecture. Many companies can’t use our way of working because their architecture won’t allow it.“

Ist es an der Zeit, nicht nur methodisch über agile Vorgehensmodelle nachzudenken, sondern auch die technische und fachliche Architektur der zu entwickelnden Systeme mit einzubeziehen? Immer mehr deutet darauf hin, dass die Antwort „ja“ lautet. In diesem Artikel werde ich deshalb zeigen,

  • welche Teamstrukturen für Flexibilität und Agilität wünschenswert sind.
  • wie Architekturentscheidungen agil getroffen werden können.
  • welche Architekturideen und -stile eine solche agile Arbeitsorganisation und Architekturarbeit fördern (oder behindern).

Da die gewonnene Flexibilität und Agilität stark mit Kompromissen und Herausforderungen verbunden ist, werde ich auch diese Seite nicht außer Acht lassen.

Teamaufstellung und agile Grundsätze

Agilität steht für schnelle Reaktion auf Veränderung, für stetiges Lernen und enge Zusammenarbeit auf vielen Ebenen. Für viele Unternehmen ist diese Idee charmant, verspricht sie doch Kundenzufriedenheit, schnelle Time-to-Market und die Minimierung typischer Projektrisiken. Bevor ich darauf zu sprechen komme, warum diese Versprechen mit vielen technischen Architekturen nicht eingelöst werden können, werfe ich einen Blick darauf, welche Projekt- und Teamorganisation überhaupt wünschenswert ist.

Teams sollten im agilen Sinne möglichst selbstorganisiert arbeiten. Das heißt, Teams sollen in der Lage sein, ihren Arbeitsmodus und ihre Entwicklungsarbeit selbstständig zu optimieren (vgl. Agiles Manifest – Prinzip 11). Qualität und Design liegen ebenfalls als Verantwortung beim Team. Direkte Kommunikation und lokale Entscheidungsmöglichkeiten sind zu fördern (vgl. Agiles Manifest – Prinzip 6).

Das gelingt bei Projekten mit nur einem Team meist gut – das Team muss allerdings auch die richtige Größe haben. Ist es zu klein, fehlen Ressourcen und Wissen, ist es zu groß, steigt der Aufwand für Kommunikation und Koordination, und eventuell bilden sich Subteams heraus (siehe Kasten: „Die ideale Teamgröße“).

Die ideale Teamgröße

Dr. Belbin schreibt über die Arbeit in der Europäischen Union, dass Entscheidungen effektiv nur in kleinen Gruppen möglich sind, und empfiehlt eine Gruppengröße von vier (siehe: Belbin, R. Meredith: „Management Teams: Why They Succeed or Fail“, Butterworth Heinemann, 3. Auflage 2010). Ringelmanns Studien zu Gruppenverhalten deuten darauf hin, dass größere Gruppen zu „Social Loafing“ neigen, der individuelle Einsatz durch eine Gruppe also kaschiert wird und deshalb abnimmt. Bekannt ist das Phänomen als Ringelmann-Effekt. Wittenberg nennt seine Studien zur optimalen Teamgröße „not conclusive“, legt sich jedoch auf einen Korridor von fünf bis zwölf Leuten fest, wobei sechs eine häufig genannte Zahl ist. Oft wird die ideale Teamgröße auch auf die berühmte 7+/-2-Formel zurückgeführt.
Fest steht: Ab einer zweistelligen Anzahl an Projektmitgliedern sollte man über die Aufspaltung in mehrere Teams nachdenken. Der teaminterne Effizienzgewinn ist dann meist höher als der Verlust durch die Hürde der Teamgrenze.

Erreichen Systeme eine Größe, die mehrere Teams rechtfertigt, stellt sich die Frage des Teamschnitts. Man möchte möglichst unabhängige Teams erreichen und landet im agilen Umfeld deshalb oft bei Featureteams. Ein Featureteam ist ein Team, das eine Reihe von Funktionalitäten umsetzen kann ‑ aus Kundensicht vollständig und eigenständig (siehe: Cohn, Mike: „Succeeding with Agile: Software Development Using Scrum“, Addison-Wesley, 2009). Dafür ist es disziplinübergreifend zusammengesetzt, erklärt technische Belange also zur Querschnittsaufgabe. Diese Belange sollten jedoch nicht überhand nehmen, um die eigentliche Idee der Unabhängigkeit von Teams zu fördern. Sind Scrum of Scrums zu häufig technisch motiviert, handelt es sich um ein Warnzeichen, dass System- und Teamstruktur nicht zueinander passen. Wirklich agile Organisationen versuchen diese Verletzung von Conways Law zu adressieren:

  • Auf organisatorischer Seite etwa durch querschnittliche „Gilden“ (vgl. Spotify) oder andere Architekturpraktiken, die Fokussierung von Kommunikation fördern (siehe nächster Abschnitt).
  • Auf technischer Seite durch die Verringerung von Querschnittsthemen, etwa mit lokaler Entscheidungsgewalt für Technologien und In-Kauf-Nehmen von technischen Inkonsistenzen (siehe Abschnitt: „Architekturkonzepte für mehr Lebendigkeit“).

Gelingt es Ihnen, kleine, unabhängige Teams zu schneiden, haben Sie im Sinne der Agilität schon einen großen Schritt getan. Andere agile Säulen, wie die enge Zusammenarbeit mit Fachexperten oder eine hohe Identifikation von Entwicklern mit dem Produkt, sind dann ebenfalls leichter umzusetzen.

(Architektur-)Entscheidungen agil treffen

Im agilen Sinne sind Entscheidungen am besten von denen zu treffen, die sie auch umsetzen – das gilt vor allem für technische Fragestellungen, in denen die Nähe zum Code begünstigend wirkt. Im Gegensatz zu zentral erarbeiteten technischen Konzepten sind die entworfenen Lösungsansätze oft realistischer, und die Reaktionsfähigkeit auf Überraschungen in der Umsetzung steigt. Größere Projekte oder Vorhaben in komplexen Domänen kämpfen jedoch mit sehr vielen technischen Fragestellungen, die nicht isoliert von einigen wenigen Entwicklern eines Teams getroffen werden können (oder sollten). Diese Gruppe von Entscheidungen bezeichnen wir gerne als architektonisch. Sie betreffen viele Projektmitglieder, haben externe Abhängigkeiten, beinhalten hohen finanziellen Einsatz oder hohes technisches Risiko.

Projekte werden häufig als agil bezeichnet, wenn sie Architekturentscheidungen trotz der Herausforderungen, die damit verbunden sind,

  • lokal treffen, also architektonische Fragestellungen an einzelne Teams oder Entwickler delegieren können.
  • mit Experimenten leiten, also Raum für Prototypen, Durchstiche oder Testimplementierungen schaffen.
  • mit Feedback aus der Produktion untermauern, also durch Realität funktionierender Lösungen und Probleme lernen.

Dieser Umgang mit Architekturentscheidungen gehorcht den weiter oben beschriebenen agilen Prinzipien und ermöglicht es Projekten, parallel (in mehreren Teams) und effektiv an der Softwarearchitektur zu arbeiten. In der Praxis ist dieser Arbeitsstil jedoch herausfordernd. Oft hilft ein Mix aus methodischen und technischen Mitteln bei der Adoption. In diesem Artikel betrachte ich die technischen Mittel etwas genauer (siehe Kasten: „Methodische Mittel für agile Architekturarbeit“).

Methodische Mittel für agile Architekturarbeit

Im Folgenden werden einige methodische Mittel für den agileren Umgang mit Architekturentscheidungen ausführlich beschrieben (viele dieser Praktiken finden Sie in Toth, Stefan: „Vorgehensmuster für Softwarearchitektur – Kombinierbare Praktiken in Zeiten von Agile und Lean“, Carl Hanser Verlag, 2. Auflage 2015):

Abstimmungsarbeit auf Architekturthemen fokussieren
Um die Entwicklungsgeschwindigkeit hoch und möglichst gute Reaktionszeiten in der Umsetzung zu halten, sollten teamübergreifende Abstimmungsaufwände gering gehalten werden. Fokussieren Sie technische Meetings oder Präsentationen auf architekturell wichtige (risikoreiche) Themen.

Entscheidungen gemeinsam verantworten
Architekturentscheidungen können von einzelnen Entwicklern oder im Pairing vorbereitet werden. Sie stellen eine Empfehlung vor, zu der prinzipiell jeder Entwickler begründete Vetos einbringen kann. Wer ein Veto einlegt, wird in die weitere Bearbeitung einbezogen, Uninteressierte tragen die Entscheidung still mit. So gelingt es vielen Projekten, die besten Leute für die jeweilige Fragestellung zu finden und das Not-invented-here-Syndrom zu vermeiden – schließlich sind alle Entwickler in die Entscheidungsfindung einbezogen.

Breites Feedback zu Entscheidungen
Neben den Entwicklern sollten im agilen Sinne auch fachliche Rollen oder Stakeholder aus der Organisation in Architekturentscheidungen eingebunden werden. Dafür werden technische Fragen fachlich ausdrückbar gemacht (etwa mit Qualitätsszenarien, siehe Toth, Stefan: „Vorgehensmuster für Softwarearchitektur – Kombinierbare Praktiken in Zeiten von Agile und Lean“, Carl Hanser Verlag, 2. Auflage 2015) und fachliche Kompromisse und Bedenken aufgenommen. Regelmäßige Architekturreviews helfen bei dieser Aufgabe.

Prinzipien als Leitfäden
Wenn Sie grundlegende Architekturideen in Form von Prinzipien ausdrücken, versetzen Sie mehrere „Entscheider“ in die Lage, konsistent zu entscheiden. Prinzipien können einen Arbeitsstil fördern, Präferenzen ausdrücken, auf die man sich geeinigt hat, oder dafür sorgen, dass ein gemeinsames Ziel nicht aus den Augen verloren wird. Getroffene Entscheidungen behindern sich so seltener, und die konzeptionelle Integrität der Software bleibt eher erhalten.

Experimente aktiv einplanen
Das Erproben unterschiedlicher Lösungsmöglichkeiten im Code (und eventuell sogar in Produktion) ist eine der effektivsten Strategien, um zu lernen. Im Architektursinn kann man diese Experimente als Risikominderungsmaßnahme verstehen – etwa für Unsicherheiten im Bereich des Laufzeitverhaltens. Planen Sie Zeiten für Experimente ein in dringenden Fällen auch parallel durch mehrere Entwickler betrieben, um den Erfahrungsaufbau radikal zu beschleunigen.

Gute Lösungen verallgemeinern
Neben dem Experimentieren mit Neuem ist das Ausnutzen von gut Gelungenem ein Zeichen guter Softwareentwicklung. Gut funktionierende Lösungen einzelner Teams können Referenzcharakter bekommen oder in verallgemeinerter Form in ein Framework einfließen, das alle Entwickler nutzen können. Geht das aufgrund des speziellen Charakters der Lösung nicht, können Sie vielleicht aus der Erarbeitung der Lösung etwas für künftige Probleme ableiten.

Architekturkonzepte für mehr Lebendigkeit

Bisher waren organisatorische und methodische Mittel im Fokus, um in architekturellen Fragen agiler zu werden. Es gibt allerdings auch technische Eigenschaften von Systemen, die eine agile, flexible und breit gestreute Arbeit an Architekturthemen erleichtern oder ermöglichen. Besitzt Ihr System bestimmte Strukturen und Architekturansätze, werden agile Entscheidungsprozesse effektiver möglich, sind agile Prinzipien auch mit weniger methodischen Kniffen umsetzbar. In der Praxis zeigen uns einige Vorreiter der IT-Branche, wie das geht. Amazon, Netflix oder Spotify ermöglichen ihren Entwicklern selbstorganisierte Arbeit, schaffen schnell reagierende, flexible Gruppen und geben ihnen Entscheidungshoheit, die über das pure Codedesign weit hinausreichen. Auch wenn diese Firmen selten von „Agilität“ sprechen, sind das genau die Eigenschaften, die weiter oben als besonders wichtig und interessant für agile Arbeit identifiziert wurden.

Domänenorientierte Struktur

Die flexible Reaktion auf Anforderungsänderungen wird in agilen Projekten groß geschrieben. Zentral sind hierbei die Priorisierung von Anforderungen und die iterativ inkrementelle Arbeit. Anforderungen, die noch nicht umgesetzt sind, sind auch nicht detailliert analysiert und können einfacher geändert werden. Was ist jedoch mit Anforderungen, die bereits analysiert und umgesetzt wurden? Hier muss die Software selbst einfach veränderbar sein. Konkret bedeutet das:

  • Die aufgrund der Anforderung zu ändernden Codeteile müssen schnell identifizierbar sein.
  • Änderungen sollten möglichst nur lokale Auswirkungen haben und sich nicht über enge Kopplung mit anderen Systemteilen fortpflanzen.
  • Die Änderungen sollten möglichst nur ein Team betreffen, also wenig übergreifende Kommunikation erfordern.
  • Die korrekte Funktion der Software nach der erfolgten Änderung muss gut testbar sein.

Alle genannten Punkte werden durch domänenorientierte Strukturierung von Software unterstützt. Das System wird rund um Begrifflichkeiten der Fachlichkeit entworfen. Gibt es in Ihrem Geschäftsumfeld ein „Produkt“, das angeboten wird, gibt es auch eine Domänenklasse „Produkt“ und in vielen Fällen größere Pakete, Komponenten oder Bausteine mit dem Namen „Produkt“, „Produktverwaltung“ oder „Produktsystem“. Organisationseinheiten, die neue Produkte kreieren oder Produktpflege betreiben, werden Anforderungen an diesen Systemteilen formulieren – sie wollen neue Produkte sichtbar machen, die Benutzerinteraktion mit Produkten festlegen, die Eigenschaften von Produkten anpassen usw.

Durch die Orientierung der Software an den Begrifflichkeiten und Konzepten der Domäne ist Änderungsbedarf an der Software leichter identifizierbar. Möchten Sie die Änderungen lokal und innerhalb einzelner Teams halten, ist es sinnvoll, die Domänenorientierung nicht nur in einzelnen Bausteinen sichtbar zu machen, sondern sie zum führenden Strukturierungsmittel zu erheben. Das stellt auch die Schichtung als führenden Architekturstil Ihrer Applikation in Frage.

Abb. 1: Schichten vs. vertikale Architekturstile

Abb. 1: Schichten vs. vertikale Architekturstile

Abbildung 1 zeigt die Konsequenz dieser Überlegungen. In der klassischen Schichtenarchitektur formt die Technologie den Architekturstil. Eine physische Trennung der Applikation ist eher entlang der Grenzen von Präsentation, Geschäftslogik und Datenbank üblich. Alle Domänen teilen sich die technologische Basis und üblicherweise auch den Prozess und das Datenmodell.

Bei vertikalen Architekturstilen steht hingegen die Domäne im Vordergrund. Technologieentscheidungen werden innerhalb der Domänenstrukturierung getroffen, die einzelnen „Vertikalen“ (auch „Domänenservices“, „Subsysteme“ oder „Self-contained Systems“ genannt) sind voneinander möglichst unabhängig. Das gelingt etwa durch Replizierung und Umformung von Daten, Frontend-Integration und die lose Kopplung über Service Registrys. Änderungen an einer Vertikalen schlagen (potenziell) nicht so häufig auf andere Vertikale durch. Wählt man auch die Teamaufstellung entsprechend, sind Teams für ganze Vertikale verantwortlich und können so domäneninterne Anforderungen vollständig umsetzen ‑ agil geforderte, lokale Entscheidungsmöglichkeiten inklusive.

Polyglotte Technologie ermöglichen

Ein weiterer Schritt in Richtung Unabhängigkeit von Teams, die in einer Vertikalen arbeiten, ist die Aufhebung technischer Restriktionen. Laufen Domänenservices in unterschiedlichen Prozessen, sind sie auch technologisch variabel – Plattformen und Frameworks können in unterschiedlichen Versionen verwendet werden oder sogar gänzlich variieren. Der weiter oben erwähnte Produktservice könnte seine Daten etwa anders ablegen und aufbereiten als ein sehr dateneffizienter Reportingservice.

Durch diese Variabilität können Entscheidungen gezielter auf Domänenbedürfnisse abgestimmt werden und Technologieumstellungen können schrittweise erfolgen. Anders als bei einer monolithisch gelebten Schichtenarchitektur muss nicht das Gesamtprojekt auf eine neue Java-Version gehoben werden oder einer Änderung des Basisframeworks zustimmen. Neue Technologien können isoliert an einer Stelle des Systems ausprobiert werden ‑ am echten Beispiel und produktiv. Ausgehend von dieser Lernerfahrung kann man für andere Teile des Systems entscheiden, was zu tun ist.

In der Konsequenz können Technologieentscheidungen iterativ, inkrementell getroffen werden. Unabhängige Teams können lokaler und mit weniger Kommunikationsoverhead entscheiden. Beides fördert agiles Vorgehen in größeren Projekten.

Die genannten Vorteile der Domänenorientierung und polyglotten Technologie erhält man jedoch nicht umsonst. Die beschriebene Flexibilisierung erfordert hohe Verantwortungsübernahme in den Teams, es kommen mehr Entwickler mit technischen Herausforderungen in Berührung, und ein Wechsel von einem Team zum anderen kann auch mit Technologie- oder Programmiermodelländerung einhergehen. Um diese Effekte etwas zu mindern, steuern die meisten Firmen mit zentralen Prinzipien nach, die als Eigenschaften des Systems trotz der technologischen Freiheit unumstößlich wichtig sind. Auch werden favorisierte Technologien über Abstraktionen und eigene Frameworks in der Verwendung so stark vereinfacht, dass die meisten Teams sich einfach an diese Option halten. Da Abweichungen dann mit Mehraufwand und Risiko verbunden sind, gibt es sie nur, wenn es wirklich notwendig und sinnvoll ist. Erlaubt sind Abweichungen aber in jedem Fall.

Kleine Softwareeinheiten

Mit den beschriebenen Ansätzen können Systeme in recht unabhängige Teile gefasst werden. Was jedoch, wenn eine grobe Auftrennung des Systems in Vertikale noch immer zu viele Entwickler innerhalb der Domänengrenze erfordert, um im agilen Sinne effizient zu sein (siehe Abschnitt „Teamaufstellung und agile Grundsätze“)?

Ein großer Trend der letzten Jahre ist es, in diesem Fall einfach weiter aufzuspalten. Statt ganzer Domänen (wie „Produktsystem“) entstehen kleinere Services, die sich spezialisiert um die Produktsuche oder auch nur um die Darstellungsreihenfolge der Suchergebnisse kümmern. Diese kleineren Services werden meist als „Microservices“ bezeichnet, auch wenn die tatsächliche Granularität dieser Services noch ein offener Punkt in der Diskussion ist (und bleiben wird).

Für die kleiner geschnittenen Services gelten die gleichen Regeln wie für die oben beschriebenen Vertikalen. So laufen auch sie in separaten Prozessen, sind vom technischen Aufbau her potenziell eigenständig und werden von dezidierten Teams betreut. Durch die kleinere Aufspaltung wird die Schrittlänge bei strukturellen und technischen Änderungen weiter verringert, problematische Systemteile können einfacher ersetzt werden, anstatt sie aufwändig zu refactoren. Microservices können von wenigen Entwicklern erstellt, ausgeliefert und gepflegt werden. Große Teams und der Ringelmann-Effekt sind damit seltener ein Problem.

Die große zusätzliche Herausforderung besteht darin, dass kleinere Services auch eine größere Anzahl an Services bedeuten. Netflix steht momentan z. B. bei fast 700 Stück. Diese Menge ist nicht mehr zentral steuer- oder orchestrierbar. Es braucht folglich funktionierende dezentrale Ansätze, um Architektureigenschaften zu erreichen und Chaos zu verhindern. Die vorher erwähnten Prinzipien sind nur der erste Schritt ‑ automatisierte Tests und häufiges, feingranulares Deployment sind der zweite.

Feingranulares Deployment

Kann man die Entwicklung des Systems nicht zentral steuern, müssen die Entwickler selbst mehr Verantwortung übernehmen, um für die nötige Qualität zu sorgen. Das ist auch ganz im agilen Sinne – das agile Manifest erinnert in einem Prinzip daran, dass die beste Software durch die Arbeit selbstorganisierter Teams entsteht. Ein häufiges Problem in der Praxis ist jedoch, dass Entwickler zu wenig Überblick haben, um übergreifende Entscheidungen gut zu bearbeiten. Auch sind sie oft zu entkoppelt vom fertigen System (organisatorisch und technisch). Eine Vielzahl kleiner Services verbessert den Überblick der Entwickler sicherlich nicht, kann jedoch für direkteres Feedback genutzt werden.

Produkthersteller, die Microservices nutzen, verfügen auch über gut automatisierte Build- und Deployment-Pipelines. Das Ziel ist es, Entwicklern möglichst schnell nach dem Check-in von Codeänderungen eine möglichst umfassende Rückmeldung zu geben. Dazu gehört nicht nur die Korrektheit des eigenen Codes, sondern auch das effiziente Zusammenspiel mit anderen Services zur Laufzeit, die Beibehaltung der gewünschten Systemstabilität usw. Erreicht wird diese Rückmeldung zum Beispiel über ein effizientes Staging im Deployment und/oder über ein feinmaschiges Monitoring im Produktivsystem. Letzteres ist sicher die Königsdisziplin der Deployment- und Betriebsfähigkeit, bringt sie Entwickler doch direkt mit dem Produkt in Kontakt. Das System muss sich durch Robustheit, hohe Fehlertoleranz und gute Selbstheilungsfähigkeiten auszeichnen. Schlägt etwas fehl oder funktioniert das System nach dem Deployment nicht mehr, wird automatisch zurückgerollt, und das Team kann analysieren, woran es gelegen hat.

Durch automatisierte Deployment Pipelines sind die Entwickler mit dem Endergebnis ihrer Arbeit verbunden. Wichtig ist nun noch, dass die Rückmeldung häufig kommt und Fehler gut als die eigenen identifizierbar sind. Nun hilft es sogar, dass Microservices recht klein und unabhängig sind. Sie ermöglichen so relativ unkoordinierte Deployments und liefern bei Fehlern eine klare Zuständigkeit. Änderungen am System müssen generell rückwärtskompatibel sein, bzw. die alte Version einer Schnittstelle weiterhin anbieten. Macht ein eigenes Deployment irgendetwas am System kaputt, ist man definitiv zuständig. Größere Deployments mit vielen Änderungen würden diese Zuständigkeit verwischen, die Verantwortlichkeit verwässern und den Ruf nach Koordination stärken. Äußerst unagil …

Fazit

In diesem Artikel habe ich einen Bogen gespannt von agilen Grundsätzen bis zur technischen Architektur des Systems. Im Rahmen eines Artikels ist es nicht möglich, jedes der genannten Konzepte im Detail zu besprechen, allerdings sollte ein Gefühl dafür entstanden sein, dass Flexibilität und Agilität auch technisch unterstützt werden können. Change-Projekte in Konzernen adaptieren häufig einfach agile Praktiken, ohne die gewünschten Erfolge manifestieren zu können. Natürlich kann jedes Projekt und jedes Unternehmen Scrum machen, aber echte Dynamik entsteht dadurch selten. Es braucht eine gesamtheitliche Betrachtung des Themas, die auch die architektonische und technische Seite mit einschließt.

Domänenorientierte Systemaufstellung, die Ermöglichung polyglotten Technologieeinsatzes, die feingranulare Aufspaltung von Systemen und automatisiertes, häufiges Deployment fördern die Dynamik. Hier docken auch viele aktuelle Trends wie Microservices, DevOps oder polyglotte Persistenz und CQRS an. Sie zielen alle in eine ähnliche Richtung und fördern zentrale agile Ideen. Bei all der Klarheit, mit der sich moderne Projekte in diese Richtung bewegen, sei jedoch angemerkt, dass die gewonnene Flexibilität und Dynamik nicht geschenkt kommt. Viele kleine selbstorganisierte Teams funktionieren nur gut mit klaren technischen Prinzipien, guter Automatisierung von Test und Deployment, hoher Verantwortungsübernahme der Entwickler und neuen, dezentralen Managementkonzepten. Wie man es auch dreht und wendet: Unternehmensphilosophie, Projektmethodik und Architektur spielen eng zusammen.

Geschrieben von
Stefan Toth
Stefan Toth
Stefan Toth arbeitet als Entwickler, Softwarearchitekt und Berater bei der embarc GmbH. Seine Schwerpunkte liegen in der Konzeption und der Bewertung mittlerer bis großer Softwarelösungen sowie der Verbindung dieser Themen zu agilen Vorgehen. Er ist Autor zahlreicher Artikel und des Buchs "Vorgehensmuster für Softwarearchitektur". Kontakt: st@embarc.de
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Conway 2.0: Wie Architekturstile agile Zusammenarbeit fördern oder behindern"

avatar
400
  Subscribe  
Benachrichtige mich zu: