Während Agilität mit dem de-facto Standard Scrum auf Teamebene oftmals relativ leicht umzusetzen ist, stellt Skalierung der agilen Vorgehensweisen Organisationen regelmäßig vor größere Herausforderungen. Viele Frameworks wie etwa SAFe oder LeSS liefern interessante und gute Ansätze hierfür. Jedoch scheitern Organisationen regelmäßig bei der Einführung dieser, aufgrund heterogener Teams, Anforderungen und Produktlandschaften. So ist beispielsweise ein Team, welches den Checkout-Prozess eines Onlineshops verantwortet, ganz anders zu betrachten als das Team, welches die interne Cloudplattform oder einen Data Lake entwickelt. Jedes dieser Teams hat unterschiedliche Anforderungen an eine teamübergreifende Planung und Zusammenarbeit. Aufgrund der abweichenden Herausforderungen benötigt es ein anpassbares Vorgehensmodell. 

Die Strukturierung und Interaktion von Teams ist eine der größten Herausforderungen in agilen Organisationen. Besonders in der IT müssen Teams häufig komplexe Aufgaben bewältigen und dabei flexibel bleiben. Matthew Skelton und Manuel Pais bieten mit ihrem Buch „Team Topologies“ eine klare Methode, wie Teams organisiert und ihre Schnittstellen gestaltet werden können, um Effizienz, Zusammenarbeit und Anpassungsfähigkeit zu maximieren.

Die Grundidee hinter Team Topologies

• Klare Verantwortlichkeiten: Jede Teamkategorie hat definierte Ziele und Aufgaben, was den Fokus und die Effizienz erhöht. 
• Verbesserte Zusammenarbeit: Gut durchdachte Kommunikationswege und Schnittstellen reduzieren Missverständnisse. 
• Schnelle Anpassung: Enabling-Teams helfen anderen Teams, neue Technologien oder Methoden schneller einzuführen. 
• Optimierte Ressourcennutzung: Plattform-Teams schaffen gemeinsame Infrastruktur, damit sich andere Teams auf ihre Kernaufgaben konzentrieren können.

Auf diese Weise soll der Ansatz der Teamkategorien eine praxisnahe und flexible Methode bieten, um skaliertes Agilitätsmanagement in komplexen Organisationsstrukturen zu implementieren und nachhaltig zu verankern.

In kurzen Worten: Team Topologies soll die Entwicklung von Organisationen im Laufe der Zeit unterstützen, wann immer sich die Bedingungen ändern. 
Moderne Organisationsprinzipien werden gefördert und Softwareanpassungen können schneller umgesetzt werden. In der Realität bleibt es bei der immer gleichen Herausforderung, den Teams dafür entsprechend Zeit zum Testen & Lernen einzuräumen.

Schauen wir uns das Konzept in der notwendigen Tiefe an, um zu erfahren, wie diese Konzepte auch in den eigenen Teams angewendet werden könnten: 

Inhalt:

1. Conway’s Law
2. Team First
3. Vier grundlegende Topologien
4. Team-Interaktionsmodi
5. Organisatorisches Gespür
6. Topologieentwicklung
7. Team-API

1. Conway’s Law

Conway’s Law besagt:

»Jede Organisation, die ein System entwirft, wird zwangsläufig einen Entwurf erstellen, der eine Kopie ihrer Kommunikationsstruktur ist.« 

Anders formuliert: Die Organisationsstruktur und die Kommunikationswege zwischen den Teams spiegeln sich direkt in der Systemarchitektur wider. Ein einfaches Beispiel dazu zeigt die folgende Grafik.

Während Conway’s Law oft als reine Beobachtung beschrieben wird, geht der Ansatz von Team Topologies einen Schritt weiter: Es wird als aktives Gestaltungsprinzip verstanden. Anstatt zu akzeptieren, dass die Architektur die bestehenden Teamstrukturen widerspiegelt, lassen sich Teams gezielt so gestalten, dass sie eine gewünschte Architektur aktiv fördern.

Möchte man beispielsweise eine modulare, lose gekoppelte Architektur, sollten die Teams entsprechend strukturiert werden. Dies gelingt durch den Aufbau autonomer, funktionsübergreifender Teams sowie durch die Etablierung klarer Schnittstellen und definierter Verantwortlichkeiten. Dieses Prinzip wird als Inverses Conway’s Law bezeichnet. In unserem Projektalltag begegnen wir diesem Phänomen immer wieder.

Ein Beispiel aus der Praxis: Selbst sehr erfahrene Entwickler entwerfen zum Teil monolithische, fehleranfällige Strukturen – nicht aufgrund mangelnden Könnens, sondern weil:

• Architekturbausteine mit zu viel Funktionalität überladen werden, da Entwickler in diesen Bereichen besonders vertraut sind.
• Hoher Lieferdruck führt dazu, dass eigentlich isolierte Funktionalitäten schnell in bestehende Strukturen integriert werden, statt sauber gekapselt zu werden.

Ob traditionelles oder inverses Conway’s Law: Das „Störgefühl“, wenn die Softwarearchitektur nicht mehr zur Teamstruktur passt, kennt fast jeder. Sich dieses Zusammenhangs bewusst zu sein, ist der erste Schritt, um sowohl die Architektur als auch die Organisation gezielt weiterzuentwickeln.

(Mehr dazu hier: Conway´s Law – EN  / Conway´s Law DE)

2. Team First

Bei Team Topologies wird ein Team als eine stabile Gruppe von Menschen betrachtet, die am gleichen Ziel arbeiten. Verantwortlichkeiten werden keinen Einzelpersonen zugewiesen, sondern Teams.

Die Anzahl der Teammitglieder ist entscheidend, um Vertrauen zu bilden. Ein effektives Team umfasst laut Team Topologies 7 bis 9 Personen. 

Bis eine einigermaßen geschlossene Einheit entsteht, dauert es bis zu drei Monate. Es ist kaum sinnvoll, Teams nach Abschluss eines Projekts, an dem sie ein halbes Jahr gearbeitet haben, neu zu strukturieren. Die emotionale Anpassung an die Arbeitsgewohnheiten und Sichtweisen neuer Kollegen hat einen gravierenden Einfluss auf die Leistung. Nur wenn das Vertrauen in eine Organisation hoch ist, ist ein Teamwechsel einmal im Jahr ohne negative Auswirkungen möglich.

Die Autoren betonen, dass es wichtig ist, die kognitiven Fähigkeiten des Teams zu maximieren, durch die Verbesserung der Arbeitsumgebung, des Führungsstils und die Minimierung von Ablenkungen.

Diese Ansicht wird bereits in vielen bekannten Team-Konstellationen angewandt, wie beispielsweise in Projektteams, Enabling oder Transformationsteams. Die Vorteile von Teams mit klarem Fokus ohne Ablenkungen von “außen” sind nicht von der Hand zu weisen. 

John Sweller bezeichnet Kognitive Belastung mit: „Die Gesamtmenge an geistiger Anstrengung, die im Arbeitsgedächtnis aufgewendet wird.“

Drei Arten der kognitiven Belastung werden benannt:

• Intrinsische kognitive Belastung – bezieht sich auf die Faktoren, die für die Lösung der Aufgabe bedeutend sind. Beispiel: Wie kreieren wir eine neue Methode?
• Externe kognitive Belastung – bezieht sich auf die Voraussetzungen, in der die Aufgabe ausgeführt wird. Beispiel: Wie konfigurieren wir diesen Service?
• Lernbezogene kognitive Belastung – bezieht sich auf Inhalte, die erlernt werden müssen, um die Aufgabe zu lösen. Beispiel: Wie funktionieren Bank Transfers?

Mehr dazu hier: Cognitive Load Theory – DE.

Team Topologies spricht davon, die Verantwortlichkeit des Teams so zu beschränken, dass es die maximale kognitive Belastung des Teams nicht überschreitet.

Aus unserer Sicht wird es entscheidend sein, wie viel Zeit den Teams eingeräumt wird, um zu lernen, wie alltägliche Herausforderungen gemeistert werden, ohne die maximale kognitive Belastung zu überschreiten. Der Lieferdruck auf Teams und das Problem, dauerhaft an zu vielen Aufgaben parallel zu arbeiten, macht evident, wie wichtig es ist, in den Teams zu lernen, die Verantwortlichkeiten klar zu definieren und zu beschränken.

 Das Lernen im Tagesgeschäft  “nein” zu sagen, erweist sich unter hohem Lieferdruck, meist als nicht überwindbares Unterfangen und wird selten vom Management in Drucksituationen akzeptiert. Die Akzeptanz auf Managementebenen ist aber maßgeblich, um die Theorie auch in der Praxis umsetzen zu können. Hier zeigt sich für uns klar, dass die gesamte Organisation “lernen” muss.   

Eine Möglichkeit könnte der Team-First-Ansatz sein. Durch den Team-First-Ansatz soll Mitarbeitern die Möglichkeit gegeben werden, in einer Organisation erfolgreich zu sein. Anstatt ein dickes Fell oder Belastbarkeit zu benötigen, um in einer Organisation zu überleben, haben Mitarbeiter in einer Team-First-Organisation den Raum und die Unterstützung, ihre Fähigkeiten und Praktiken zu entwickeln.

3. Die vier grundlegenden Teamtopologien

Es gibt sehr viele Teamtypen in Organisationen. Der Einfachheit wegen werden diese auf vier Haupttypen reduziert. Diese betrachten das Verhalten und die Fähigkeiten der Teams und lauten wie folgt:

Stream-aligned Team: Das Team, das auf die Geschäftsveränderung ausgerichtet ist, mit einem funktionsübergreifenden Kompetenzmix und der Fähigkeit, signifikante Inkremente zu liefern, ohne auf ein anderes Team warten zu müssen.

Enabling-Team: Das Team, das andere Teams bei der Einführung und Änderung von Software im Rahmen einer Übergangs- oder Lernphase unterstützt.

Complicated-subsystem Team: Das Team mit einer besonderen Aufgabe für ein Subsystem, das zu kompliziert ist, als dass es von einem normalen Stream-ausgerichteten Team oder Plattformteam bearbeitet werden könnte. Optional und nur dann verwendet, wenn es wirklich notwendig ist.

Plattform Team: Das Team, das an der zugrunde liegenden Plattform arbeitet und Stream-ausgerichtete Teams bei der Bereitstellung unterstützt. Die Plattform vereinfacht komplexe Technologie und reduziert die kognitive Belastung für Teams.

Nehmen wir hier nochmal als Beispiel ein klassisches Unternehmen aus dem e-Commerce Bereich:

• Ein Stream-aligned Team könnte den gesamten Checkout-Prozess des Onlineshops verantworten, einschließlich der Integration neuer Payment-Dienstleister und der UX-Optimierung.
• Das Unternehmen möchte verstärkt die Vorteile der Cloud-native Entwicklung nutzen. Ein Enabling Team könnte hierbei bei der Einführung der Technologie und notwendigen Architekturmuster helfen, beispielsweise durch Schulungen, Bereitstellung von Prototypen oder Definition von Architekturpattern.

• Als complicated-subsystem-Team entwickelt eine Gruppe von Spezialisten einen hochspezialisierten Empfehlungsalgorithmus, welcher Kundinnen und Kunden passgenaue Produktempfehlungen zur Verfügung stellt.
• Unser fiktives Unternehmen hat direkt zwei Plattform-Teams, welche zum einen die interne Developer-Cloudplattform und zum anderen einen Unternehmensweiten Data-Lake zur Verfügung stellen.

4. Team-Interaktionsmodi 

Ineffektivität wird in vielen Organisationen durch schlecht definierte Interaktionen verursacht. Laut TeamTopologies läuft die Beziehung zwischen den Teams auf zwei Dinge hinaus: Wird durch die Zusammenarbeit mit einem anderen Team ein Ziel erreicht oder bietet es dem Team einen Service an. Auf diese Weise werde drei Möglichkeiten festgelegt, wie Teams interagieren können:

Zusammenarbeit enge Zusammenarbeit mit anderen Teams. Dies ist besonders nützlich, wenn Teams neue Technologien oder Techniken erforschen. Die Zusammenarbeit ermöglicht die schnelle Entdeckung neuer Dinge, da kostspielige Übergaben vermieden werden. Am besten verwendet, wenn ein hohes Maß an Anpassungsfähigkeit zwischen zwei Teams erforderlich ist.

X-as-a-Service etwas mit minimaler Zusammenarbeit nutzen oder bereitstellen.
Dieser Interaktionsmodus kann die Liefergeschwindigkeit erhöhen. Team A braucht etwas, um seinen Wert zu liefern, Team B hat eine Dienstleistung ohne großen Aufwand bereitgestellt. Es sind keine langwierigen Gespräche, Besprechungen oder Vorbereitungen erforderlich.

Unterstützen: Einem anderen Team helfen und umgekehrt, Hindernisse zu beseitigen. Der unterstützende Interaktionsmodus eignet sich am besten in Situationen, in denen ein Team die Hilfe eines anderen benötigt. Das Enabling Team versetzt zum Beispiel ein anderes Team in die Lage, effektiver zu sein, schneller zu lernen, eine neue Technologie besser zu verstehen oder Hindernisse zu entdecken und zu beseitigen.  Domain-Driven Design kann hier ein gutes Hilfsmittel sein.

5. Organisatorisches Gespür

Mit “Organisatorisches Gespür” ist gemeint: die Situation zu erkennen und anzupassen. Unternehmen müssen flexibel sein, um sich an Veränderungen anzupassen. Dazu gehört die Anpassung der Struktur und Abläufe. Eine Organisation sollte in der Lage sein, die richtigen Teamstrukturen und Interaktionsmodi anzuwenden.

Woran erkennt man also, dass eine Organisation sich weiterentwickeln muss?

1. Die Software wird für ein Team zu komplex. Während am Anfang jeder ein umfassendes Verständnis davon hat, was vor sich geht, wird das immer schwieriger. Dadurch verlagert sich der Fokus von echten Prioritäten auf den Versuch, Leute zu finden, die kompetent genug sind, um ein bestimmtes Problem zu lösen.
2. Die Lieferfrequenz verlangsamt sich. Die Teammitglieder sehen, dass eine Lieferung mehr Zeit und mehr Schritte erfordert. Um dies zu vermeiden, müssen Teams autonom sein und dürfen nicht darauf warten, dass andere Teams eine neue Infrastruktur erstellen.
3. Mehrere Geschäftsdienste basieren auf einer großen Anzahl zugrunde liegender Dienste. In einigen Sektoren wie Finanzen, Versicherungen, Regierung usw. können hochrangige Dienste auf Dienste auf niedrigerem Niveau angewiesen sein. Die Lösung könnte darin bestehen, die Dienste auf niedrigerer Ebene zu “plattformisieren” und für jeden Dienst auf hoher Ebene Stream-ausgerichtete Teams einzusetzen.

Hier spricht man von der Kompetenz der OrganisationswahrnehmungDies ist die Fähigkeit, die Organisationsituation so zu erfassen oder zu spüren, dass das Überleben der Organisation sichergestellt wird. Einige der Dinge, die eine Organisation „spüren“ muss, sind:

• Müssen die Teaminteraktionsmodi geändert werden?
• Was behindert den Arbeitsfluss für ein bestimmtes Team?
• Sollen wir ein bestimmtes Tool bauen oder können wir es von einem Anbieter bekommen?

Es gibt nicht wenige Systeme, die über viele Jahre hinweg entstanden sind. Diese Systeme haben Abhängigkeiten, die nicht außer Acht gelassen werden können. Die Teaminteraktionsmodi passen sich an das System an und nicht umgekehrt. Die Frage, die sich stellt, ist: Was kann oder muss ich tun, um die Komplexität des Systems zu verringern, damit die Vorteile der Teaminteraktionsmodi zum Tragen kommen, und ist dies aufgrund der Größe des Systems überhaupt möglich?

6. Topologieentwicklung

Sobald eine Organisation auf neue Herausforderungen reagiert, ist davon auszugehen, dass Teams untereinander anders als zuvor interagieren werden.

Dies kann bedeuten, dass Teams neu strukturiert oder neu zusammengesetzt werden, um spezifische Probleme anzugehen oder neue Technologien zu implementieren. Gleichzeitig können sich die Arbeitsabläufe und Prozesse ändern, um die Zusammenarbeit zwischen den Teams zu verbessern. Das übergeordnete Ziel besteht darin, sicherzustellen, dass die Teams flexibel genug sind, um sich an veränderte Anforderungen anzupassen, und dass ihre Interaktionen effektiv sind, um die Ziele der Organisation zu erreichen. Dies erfordert eine kontinuierliche Bewertung und Anpassung der Teamstrukturen und -interaktionen im Einklang mit den sich ändernden Anforderungen und Zielen der Organisation.

7. Team-API 

Eine Beschreibung der Interaktionen mit dem jeweiligen Team: Code, Versionierung, Wiki und Dokumentation, Praktiken und Prinzipien, Kommunikation, Arbeitsinformationen und einiges mehr. Ziel ist es, anderen Teams transparent und in einem einfachen Überblick zu zeigen, an was, wie, mit wem, das Team arbeitet. Ein gutes Beispiel für eine Team API hat Team Topologies selbst auf Github.com veröffentlicht.

Zusammenfassung

Die sieben Grundideen von Team Topologies bieten Vorteile, die die Effektivität der Teamarbeit in Unternehmen steigern können. 

Die Fähigkeit zur Flexibilität und Anpassungsfähigkeit, denn durch die Strukturierung von Teams können Unternehmen schnell auf Veränderungen reagieren und neue Anforderungen integrieren. 

Das Übertragen von Verantwortlichkeiten an eigenständige Teams fördert die Autonomie und Eigenverantwortung, beschleunigt die Entscheidungsfindung und fördert agile Reaktionen auf Herausforderungen (siehe 3. Grundidee), wenn das Management mit einbezogen wird und Verantwortung an die Teams weitergibt.
Ferner ermöglicht Team Topologies die Bildung hochspezialisierter Teams, die sich auf bestimmte Aufgaben oder Technologien konzentrieren können, die Entwicklung von Expertise fördert und die Effizienz steigert. 

Teams dieser Art gibt es bereits zuhauf in Organisationen. Die große Herausforderung sind die Abhängigkeiten der Teams, des Produkts und nicht zuletzt, wie viel Zeit den Teams eingeräumt wird, um zu wachsen und die Fähigkeiten zu entwickeln, die es benötigt. 

Wenn spezialisierte Teams in ihren eigenen Bereichen isoliert arbeiten und den Informationsaustausch behindern, können Kommunikationsbarrieren entstehen. Das Entstehen von Silos innerhalb des Unternehmens, wenn einzelne Teams isoliert arbeiten und der Gesamtüberblick über Projekte verloren geht, steigt.
Dies kann die Synergien zwischen den Teams behindern und die Effizienz beeinträchtigen. Zudem kommt die zunehmende Komplexität und der Koordinationsaufwand, wenn eine Vielzahl spezialisierter Teams gleichzeitig agiert. Eine klare Fokussierung auf gemeinsame Ziele kann dieses Problem mindern. Hierbei könnten sich die Vorgehensweisen von Team Topologies als klarer Vorteil erweisen. Zwar sind nicht alle Ideen von Team Topologies neu, jedoch ermöglicht die globale Sicht auf die Teams eine einheitliche strategische Ausrichtung und ein gemeinsames Vokabular für IT-Projekte. 

Zusammenfassend hier eine Kurzübersichtskarte: QRC Team Topologies

Herausforderungen bei der Umsetzung

Die Theorie von Team Topologies ist vielversprechend, aber wie bei jedem Ansatz gibt es auch Herausforderungen:

• Management-Unterstützung: Ohne ein Management, das die Prinzipien von Autonomie und psychologischer Sicherheit versteht und fördert, wird es schwer, die Teams nachhaltig zu etablieren. Ein Führungsstil der Haltung “Servant Leadership” ist eine Grundvorraussetzung für den Erfolg und die Produktivität der Teams.
• Silos und Abhängigkeiten: Oft arbeiten Teams isoliert voneinander. Hier braucht es gezielte Interaktionsmodi, um Synergien zu fördern.
• Zeit und Ressourcen: Teams benötigen Raum und Zeit, um ihre Arbeitsweisen zu entwickeln und zu verbessern. Teams müssen mit entsprechenden Personen besetzt und “ausgebildet” werden. Dies wird häufig unterschätzt.

Schlussfolgerung und Einladung zur Diskussion zur Verbesserung ihrer Teams Team Topologies bietet eine mächtige Grundlage, um Teams effektiver, autonomer und besser miteinander vernetzt zu gestalten. Die Implementierung erfordert jedoch eine bewusste Anpassung an die jeweilige Organisation und ein Management, das diese Ansätze aktiv unterstützt.  

Diskussionsfragen an den Leser: 

• Wie sieht es bei Euch im Unternehmen aus? Welche Erfahrungen haben Sie mit der Strukturierung von Teams gemacht, und welche Ansätze haben bei Ihnen besonders gut funktioniert?
• Wie können Organisationen sicherstellen, dass ihre Teamstrukturen nicht nur effizient, sondern auch anpassungsfähig sind?
• Welche Herausforderungen sehen Sie bei der Implementierung der vier Teamarten in Ihrem eigenen Umfeld?

Kaschef Yawar

Geschäftsbereichsleitung »Handel« Prokurist

Kaschef Yawar ist ein erfahrener agiler Coach und Berater mit über 15 Jahren Erfahrung in der IT-Branche. In seinen Rollen als Scrum Master, Agiler Coach und Trainer hat er erfolgreich agile Methoden in verschiedenen Unternehmen und auf unterschiedlichen Ebenen eingeführt und begleitet. Sein Fokus liegt dabei hauptsächlich auf Scrum und Kanban, sowie der Arbeit in skalierbaren Frameworks wie SAFe, LeSS und Nexus. Besonders wichtig ist ihm die wertgetriebene Entwicklung, bei der er stets darauf achtet, dass die entwickelten Produkte und Dienstleistungen einen echten Mehrwert für die Kunden schaffen.

k.yawar@atra.consulting    

• LinkedIn

Unser Blogbeitrag »Die Wachstumsrate von Software« wurde als Fachartikel in der Fachzeitschrift OBJEKTspektrum veröffentlicht.

Die Fachzeitschrift OBJEKTspektrum »liefert zuverlässige Hintergründe, Trends und Erfahrungen zu Software-Management, -Architektur und -Engineering«. Unser Blogbeitrag »Die Wachstumsrate von Software« fand Anklang bei der Redaktion der OBJEKTspektrum und wurde in einer erweiterten Fassung in Ausgabe 1/2019 veröffentlicht.

Interessierte können sich den ganzen Artikel hier herunterladen.

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Inhalt:

• Bleeding-edge for the Enterprise
• Workshops
  • From Developer to Architect
  • Coaching the Team System
• Keynotes
  • Developers as a Malware Distribution Vehicle
  • A Brief, Opinionated History of the API
• Vorträge
  • Software Updates in an Orchestrated World
  • WebAssembly 101
  • Understanding Code Performance in Production
  • From Software Development to Machine Learning
  • Skype’s Journey From P2P
  • Explaining Artificial Intelligence to Schoolchildren
  • The Story of Teams, Autonomy, and Servant Leadership
  • AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web
  • Breaking Codes, Designing Jets and Building Teams
  • Empowering Agile Self-Organized Teams With Design Thinking
  • Software Is Eating the World, ML Is Going to Eat Software
• Einschätzung

Bleeding-edge for the Enterprise

Nach der QCon 2015 in San Francisco stand dieses Jahr New York für uns auf der Agenda. Mit dem Veranstaltungsort direkt am Times Square war die Konferenz im wahrsten Sinne des Wortes am Puls der Zeit. Die Veranstaltung ist »designed for senior software engineering leaders« und bot den über 900 Teilnehmern 117 Vorträge von 143 Rednern aus folgenden Themenbereichen:

© C4Media Inc | InfoQ.com

Ob nun jedes Thema oder jeder der genannten Themenbereiche wirklich »bleeding-edge« ist, hängt natürlich immer auch von der eigenen Positionierung innerhalb der »Technology Adaption Curve« ab. Unserer Einschätzung nach ist die QCon schon sehr nah am Puls der Zeit und das nicht nur geografisch. Tech Leads und ähnliche Rollen aus den Entwicklungsabteilungen von führenden Firmen im Software Engingeering wie Facebook, Netflix & Co. berichten hier über das, was jeweils wirklich schon im Einsatz ist. Ein schönes Beispiel hierzu ist das Thema Machine Learning. Während unserer Einschätzung nach die meisten Firmen, wenn überhaupt, noch dabei sind, das Thema zu verstehen, im besten Fall damit herum experimentieren, zeigte Facebook auf der Konferenz, wie sie es schon zur konkreten Produktivitätssteigerung in der eigenen Entwicklungsabteilung und zur Optimierung des Cache-Managements in der Infrastruktur einsetzen – Use Cases die wir so, zumindest vorher, noch nicht gesehen hatten.

Waren Microservices 2015 als sogenannte »Innovators« in QCons »Technology Adaption Curve« noch beherrschendes Thema, so befinden sie sich nun in der »Early Majority« (siehe Grafik oben). Folglich gab es zwar noch einen Track zum Thema, hier lag der Fokus der Vorträge dann aber auch auf sehr konkreten Anwendungs- und Betriebsthemen derselben.

Die beherrschenden diesjährigen Themenbereiche waren entsprechend auch wieder aus den Bereichen »Innovators« und »Early Adopters«, insbesondere Serverless, Chaos Engineering und Machine Learning sowie Blockchain, Rust, Web Assembly und Software Ethics. Wobei die Einstufung des letzten Themenbereichs innerhalb »Innovators« uns dann doch verwundert hat, da wir Ethik als relevante Dimension der Leistungsbeurteilung beispielsweise nun schon seit über 10 Jahren propagieren und nicht unbedingt als Innovation sehen würden.

Workshops

Die ersten zwei Tage der Konferenz waren ausschließlich Workshops gewidmet. Themen reichten von Serverless über die Programmiersprache Go und Python-basierte AI bis zu Microservices »in Aktion«. Neben diesen eher technologischen Themen gab es auch wieder Workshops zu den »weicheren« Aspekten rund um Softwareentwicklung.

From Developer to Architect

In diesem Workshop wurde aufgezeigt, was einen Softwarearchitekten von einem Softwareentwickler unterscheidet, beziehungsweise was die Rolle des Architekten an Aufgaben mit sich bringt. Die Wichtigkeit dieser Rolle in Softwareentwicklungsvorhaben haben wir ja bereits an anderer Stelle aufgezeigt.

Zunächst wurden hier die organisatorischen und kommunikativen Aspekte der Architektenrolle herausgestellt. Dass ein Architekt viel kommunizieren muss, mag einleuchten, bedeutet aber andererseits auch, dass er viel Zeit in Besprechungen verbringt. Interessant ist hier die Analogie, dass Architektur eine Geschichte ist, die erzählt werden muss. Wer das als Entwickler nicht mag, sollte sich eventuell überlegen, ob er wirklich Architekt werden möchte, beziehungsweise weiß die Arbeit, die der Architekt dem Entwickler damit abnimmt, dann vielleicht auch ganz anders zu schätzen.

Mit den organisatorischen Aspekten sind dann häufig auch Budgetfragen verbunden, die ein Architekt zu beantworten hat. Und wo es um Geld geht, wird es schnell politisch, weshalb ein Architekt auch wissen muss, wie er welche Botschaft wann an wen sendet. Hier kann Ben Thompsons Social/Communication Map helfen.

Auch wurde angesprochen, dass die Entwicklung zum Architekten in der Praxis ja (leider) häufig über Versuch und Irrtum erfolgt. Dass Architekten in ihrer Laufbahn aufgrund der tendenziell langläufigen Natur ihrer Arbeit häufig nur wenige Architekturen von Anfang bis Ende bearbeiten können, erschwert dies zusätzlich. Wobei der Referent dabei auch die interessante Frage stellte, was denn eigentlich die Definition-of-Done einer Architektur ist? Neal Fords Architektur Katas wurden als ein Element genannt, um Architekturentwicklung gefahrlos üben zu können. Denn ein guter Architekt wird man, in dem man an Architekturen arbeitet:

»How do we get great designers? Great designers design, of course.« –Fred Brooks

Ein weiterer Teil des Workshops war der Technologieauswahl gewidmet. Auch wenn Architektur nicht gleich Technologie ist, so ist die Technologieauswahl doch häufig Architektenaufgabe. Der Architekt sollte hierbei aber die eigentlichen Ziele nicht aus dem Auge verlieren. So ist beispielsweise die Testabdeckung in der Regel wichtiger, als welches Testing-Framework schlussendlich zum Einsatz kommt. Da Technologiefragen gerade unter Entwicklern gerne auch ideologisch geführt werden, ein guter Tipp vom Referenten:

»Avoid resume-driven decisions!« –Nathaniel T. Schutta

Üblicherweise verantwortet ein Architekt die sogenannten nicht-funktionalen Anforderungen, weshalb ein weiterer Block auch diesen sich häufig widersprechenden Attributen einer Software gewidmet war, wie zum Beispiel:

• Wartbarkeit
• Skalierbarkeit
• Verlässlichkeit
• Sicherheit
• Ausrollbarkeit
• Einfachheit
• Nutzbarkeit
• Kompatibilität
• Fehlertoleranz
• Modularität
• …

Aus Sicht des Referenten sollte ein Architekt hier aber besser von Qualitätsmerkmalen reden. Denn welcher Kunde zahlt schon gerne für etwas, das keine Funktion erfüllt und was er üblicherweise nicht direkt sieht?

Da Architekturentscheidungen getroffen werden, ob man es will oder nicht (»Accidental Architecture«), ist es wichtig, die Rolle des Architekten zu klären. Die besten Architekturen entwickeln sich nach aktuellem Kenntnisstand evolutionär (»Evolutionary Architectures«) durch

• Nutzung von Feature Toggles
• sowie hypothesengestützte Entwicklung,
• Einsatz von Fitnessfunktionen
• und Chaos Engineering.

In Anlehnung an Winstons Churchills Ausspruch zur Demokratie gab der Referent zum Thema Prozesse zum Abschluss noch ein Zitat mit Augenzwinkern auf den Weg:

»Agile is the worst form of software development, except all other.« –Nathaniel T. Schutta

Insgesamt ein solider Grundlagen-Workshop zur Rolle des Architekten, wenn auch nicht unbedingt »bleeding-edge«. Ein wenig mehr Bezug zu aktuellen Fragestellungen der Softwarearchitektur, wie beispielsweise Architektur im Kontext agiler Softwareentwicklung hätte den Workshop noch abgerundet.

Coaching the Team System

Teams verändern sich. Hilfestellungen hierzu bot dieser Workshop. Wurde früher versucht, Teams wie Systeme möglichst stabil zu halten (»Never change a running/winning…«), so setzt sich immer mehr die Erkenntnis durch, dass wir damit eher das Gegenteil erreichen, da wir so im Moment der Veränderung schlecht vorbereitet sind: Wie sollen wir gut in etwas sein, was wir nicht regelmäßig praktizieren?

»Teams change. Better get good at it.« –Heidi Helfand

Die Referentin zeigte zunächst auf, dass bereits wenn eine Person ein Team verlässt oder hinzu kommt, eine neue Teamsituation entsteht, auf die wir eingehen müssen. Veränderungen passieren dabei auch noch auf verschiedenen Ebenen:

• Person
• Team
• Gilde, Stamm, Tribe – Gruppierungen einzelner Rollen, beispielsweise »alle Entwickler«
• Abteilung
• Unternehmen

Außerdem folgen auch Veränderungen einem Zyklus. Dreht es sich während der Entstehung eines Teams beispielsweise eher um Fragen des Onboardings neuer Mitarbeiter, so stehen heranwachsende Teams vor anderen Herausforderungen. Hier muss dann zum Beispiel mit kulturellen Veränderungen umgegangen werden, wenn aus eher chaotischen Startups Hierarchien entwachsen. Reife und stabile Teams benötigen wiederum oftmals eher einen Impuls, um wieder Energie freizusetzen beziehungsweise Veränderungen anzustoßen. Zu jeder dieser Coaching-Herausforderungen gab die Referentin entsprechende Tools mit auf den Weg, beispielsweise die »Market of Skills«-Aktivität, beim Onboarding neuer Mitarbeiter oder die »First-Team«-Aktivität, wenn kulturelle Aspekte geteilt werden sollen.

Googles Projekt Aristotels hat dabei eindrucksvoll gezeigt, dass dies nichts Esoterisches ist, sondern dazu dient, das, was erfolgreiche Teams ausmacht, herzustellen: »psychologische Stabilität«.

Bleibt die Frage, wer im Unternehmen dann eigentlich diese wichtige Rolle des Coaches übernimmt. Die Rolle Teamleitung als »klassische« erste Anlaufstelle für diese Fragen sehen wir hierzu insbesondere in agilen Teams immer häufiger gar nicht mehr genug »auf dem Spielfeld«. Gleichzeitig reduzieren Unternehmen die Rolle des Scrum Masters häufig nach einiger Zeit zum Teil drastisch, da »Scrum ja dann eingeführt ist«. Wir haben schon erlebt, dass ein Scrum Master beziehungsweise agiler Coach für 10 und mehr Teams zuständig war. Idealerweise verfügt jedes Team über diese notwendigen Teamentwicklungs-Skills, aber auch dieser Zustand muss erfahrungsgemäß zunächst hergestellt werden. Und dann ändert sich das Team wieder. Booking.com hat im Vortrag »The Story of Teams, Autonomy, and Servant Leadership« vom Donnerstag (siehe unten) interessanten Einblick in ihren Ansatz dazu gegeben.

Keynotes

Jeder der drei folgenden Konferenztage begann jeweils mit einer Keynote, welche durch Themenwahl und Vortragenden auch immer zum Nachdenken anregen sollte.

Developers as a Malware Distribution Vehicle

Ein »guter« Softwareentwickler vereint bekanntermaßen die drei Eigenschaften Faulheit, Ungeduld und Überheblichkeit. In diesem Vortrag wurde aufgezeigt, dass gerade diese Kombination ihn aber auch besonders empfänglich für Hacker-Angiffe macht.

So hat XcodeGhost in 2015 beispielsweise über 4.000 Apps infiziert und bis zu 1,4 Millionen Opfer pro Tag geschädigt. Dabei wurde von Unbekannten eine infizierte Version von Apples IDE XCode hinter Chinas Great Firewall ausgerollt. Diese hatte prominente Apps wie zum Beispiel WeChat durch einen veränderten Compiler mit Schadcode versehen, wodurch die betroffenden Apps gleich mehrere Angriffsvektoren aufwiesen (Remote Control, Datendiebstahl und mehr). Der Referent brachte hier noch eine Vielzahl weiterer Beispiele, von versehentlich auf Github publizierten Zugangsdaten des Fahrdienstleisters Uber bis zu einem Phishing-Angriff auf einen Entwickler der Financial Times. Im ersteren Fall gelangten Millionen Daten von Millionen Fahrgästen und Fahrern von Uber an die Öffentlichkeit. Im letzteren Fall wurden zwar nur kurzzeitig falsche Meldungen über Twitter veröffentlicht, ein ähnlicher Fall bei der AP brachte aber beispielsweise den Dow Jones innerhalb von Minuten um 1 % nach unten. Jedes Mal waren Entwickler das Einfallstor für die Hacker. Salesforce.com führte nach Angaben des Referenten einen internen Phishing-Test durch und Entwickler hatten dabei die zweithöchste Klickrate.

Das Schlimme hieran: Compiler-Hacks wie der geschilderte XCodeGhost sind schon mindestens seit dem sogenannten »Ken Thompson Hack« von 1984 bekannt.

Open-Source Software hat dabei noch einen vermeintlich sicheren Status, da der Quellcode ja öffentlich einsehbar und somit nur schwerlich kompromittierbar ist. Aber wer weiß schon, ob das entsprechende npm-Package auch dem Sourcecode auf Github entspricht? Vergangenes Jahr wurden auf diesem Wege beispielsweise 39 infizierte Packages über zwei Wochen via npm verteilt. Und das zieht sich quer durch alle Technologien. So wurden gerade vergangenen Monat 17 infizierte Docker-Images offline genommen. Und Rubys Paketsystem RubyGem hatte in 2016 sein entsprechendes Sicherheits-Debakel. Das lokale Kompilieren des sauberen Quellcodes könnte hier helfen. Das machen aber nur die Wenigsten. Und dann war da ja noch die Sache mit dem Compiler-Hack…

»You cannot trust code which you do not totally control.« –Guy Podjarny

Der Referent konnte verschiedene Gründe aufzeigen, warum gerade Entwickler dazu neigen, Entscheidungen zu treffen, die negative Auswirkungen auf die Sicherheit eines Systems haben:

• Fokus auf Funktion: Sicherheit wird als Einschränkung wahrgenommen.
• Kognitive Beschränkung: Facebook hat seinen initialen Slogan »Move fast and break things« nicht ohne Grund zu »Move fast with a stable infrastructure« geändert.
• Einerseits fehlendes Wissen: Nicht jeder Entwickler versteht alle Sicherheitimplikationen seiner Arbeit.
• Andererseits fühlen Entwickler sich häufig zu sicher (siehe auch die eingangs erwähnten Eigenschaften eines »guten« Entwicklers) und sind damit beispielsweise dann auch schwerer zu schulen.
• »Das passiert mir doch nicht«-Mentalität, dabei passieren Sicherheitsvorfälle jedem.

Als mögliche Gegenmaßnahmen wurde Folgendes empfohlen:

• Systematisches Lernen aus vergangenen Fehlern
• Sicherheitskontrollen automatisieren
• »Make it easy to be secure«
• Zutritt »wie die Großen« managen, beispielsweise
  • Googles BeyondCorp
  • Microsofts Priviliged Access Workstations
  • Netflix’ BLESS

Die Keynote war ein gelungener Einstieg in den ersten Konferenztag und durchaus ein Augenöffner für gewisse Sicherheitsthemen.

A Brief, Opinionated History of the API

In der zweiten Keynote nahm sich Joshua Bloch, Chief Java Architect von Google, vormals Distinguished Engineer für Sun Microsystems und Autor unter anderem von Effective Java, die Geschichte der API (Application Programming Interface) vor und brachte dabei Erstaunliches zutage.

Bereits 1948 erwähnten Goldstine und von Neuman erstmals eine »Subroutine Library« in ihrer theoretischen (!) Abhandlung über das Programmieren eines sogenannten »Electronic Computing Instruments«. Wilkes hat dann 1951 mit Wheeler und Gill Programmbibliotheken mit dem ersten Text zur Computerprogrammierung überhaupt »Preparation of Programs for Electronic Digital Computers« praktisch eingeführt und wurde unter anderem dafür 1967 mit dem Turing Award ausgezeichnet. Schon damals stellten sie fest:

»Documenting [APIs] is hard.«

Außerdem sollten Programmbibliotheken schon damals Komplexität vor dem Nutzer verbergen. APIs sind natürlich keine Programmbibliotheken, sondern heute losgelöst von ihnen zu sehen. Eine Programmbibliothek hat aber eine entsprechende Schnittstelle (Interface), um die Applikation programmatisch einzubinden. Somit darf man die Programmbibliothek durchaus als Vorläufer der API ansehen. Selbiger Begriff wurde dann erstmals ab 1968 genutzt.

Der Wert einer (guten) API liegt darin, dass die Implementierung geändert werden kann, ohne dass der Nutzer davon etwas merkt. Der Lebenszyklus einer API ist also losgelöst von der Implementierung: »Write once, run anywhere«. Daraus ergibt sich auch der folgende »Test«, ob eine Schnittstelle als API zu verstehen ist oder nicht:

• Es wird ein Set an Operationen bereitgestellt, welche durch ihre Ein- und Ausgaben definiert sind.
• Re-Implementierung ohne Beeinträchtigung des Nutzers wird unterstützt.

Da das vielleicht etwas abstrakt ist, brachte der Referent dann historische Beispiele für entsprechende APIs, die vielleicht nicht jeder bisher auch als solche verstanden hat:

Viele der oben genannten Beispiele sind heute noch im Einsatz. Der Hayes AT Befehlssatz für Modems findet sich heute noch in fast allen Handys. Und die Standardisierung und Re-Implementierungsmöglichkeit des IBM PCs in Kombination mit MS-DOS haben die Ära der PCs der 1980er Jahre begründet, von der wir auch heute noch zehren. WINE ist wiederum ein schönes Beispiel für eine Re-Implementierung einer API ohne Beeinträchtigung des Nutzers, in dem Fall der Windows-32-API auf unixoiden Systemen. Genauso bilden die C-Standard-Bibliothek und die Unix System Calls das Fundament unserer heutigen digitalen Welt, findet sich doch dank Android ein (freies) Unix in mittlerweile Milliarden von Geräten:

»APIs are the glue that connect our digital universe.« –Joshua Bloch

Bislang war die Re-Implementierung von APIs rechtlich unproblematisch. Durch den Rechtsstreit von Oracle mit Google ändert sich die Situation zumindest in den USA derzeit. Oracle wirft Google vor, dass deren Re-Implementierung der Java Standard Edition Bibliothek für das Android Betriebssystem Oracles Copyright und Patentrechte verletze. Der Prozess läuft bereits seit 2012 und durch mehrere Instanzen. Der aktuellste Entscheid spricht sich für Oracle aus, wodurch APIs derzeit in den USA quasi Copyrightschutz besitzen und nicht ohne Zustimmung des Autors frei re-implementiert werden sollten. Sollte sich hieran nichts mehr ändern, wird unserem digitalen Universum das zusammenhaltende Element entzogen.

Der Referent war in den Gerichtsprozessen als Gutachter tätig und hat sich auch in diesem Vortrag entsprechend für die weiterhin freie Implementierbarkeit von APIs ausgesprochen, weshalb er den Vortrag auch als »opinionated« benannt hat.

Vorträge

Software Updates in an Orchestrated World

Dieser Vortrag lief innerhalb der »Sponsored Tracks«, wurde also von einem Produkthersteller und Sponsor der QCon, in diesem Fall der Firma JFrog durchgeführt.

Der Referent griff den für uns auf der Konferenz durchgängig erkennbaren Faden auf, dass es sicherer ist, oft und schnell zu releasen, als die Systeme stabil zu halten. Aufhänger hierfür war die zunehmende Komplexität der Systeme, die wir entwickeln. Insbesondere, da der Großteil eines Systems üblicherweise aus externer Software besteht, wie wir hier am Beispiel der freien, webbasierten Projektmanagementsoftware Redmine exemplarisch nachgestellt haben:

Die eigentliche Anwendung ist hier mit 200.000 Codezeilen beziehungsweise 1 % des Gesamtumfangs nur die Spitze des Eisbergs. 99 % der Anwendung sind Fremdcode, der aber auch verwaltet und insbesondere aktuell gehalten werden will. Die Abhängigkeiten machen die Situation dabei besonders brisant: löst man die rund 1.000 Abhängigkeiten von Kubernetes auf, so wächst allein diese Software schon auf stolze 35 Millionen Codezeilen an, wird also größer als das Betriebssystem.

Bei den exemplarischen 1.580 Abhängigkeiten des oben gezeigten Beispielsystems wäre man 4 Jahre mit Updates beschäftigt, würde man nur eine Abhängigkeit pro Tag aktualisieren. Natürlich bündelt man das in der Regel analog zu Microsofts Patchday. Trotzdem muss der gesamte Softwarestack nach Updates entsprechend getestet werden, was in der Regel einen Großteil des Aufwands ausmacht.

Artefakt-Repositories wie Sonatypes Nexus und JFrogs Artifactory helfen bei der Verwaltung dieser Vielzahl von Abhängigkeiten und somit letztlich bei der Fragestellung, wie man den Überblick über einen komplexen Softwarestack von tausenden von (Open Source) Systemen heutzutage behält. Dazu kommt jedoch noch die zunehmende Komplexität des Bereichs Cybersecurity, schön dargestellt anhand Henry Jiangs »Map of Cybersecurity Domains«. Hier wird erkennbar, dass es nicht mehr nur mit Updates der Fremdsoftware alleine getan ist. Risk-Management, Sourcecode Scans, Vulnerability Checks, Architectural Fit und so weiter wollen und müssen für den Fremcode ebenso bedacht sein:

© Henry Jiang | https://www.linkedin.com/pulse/map-cybersecurity-domains-version-20-henry-jiang-ciso-cissp

Die Produkthersteller erweitern ihre Portfolios natürlich entsprechend. So bietet JFrog beispielsweise mittlerweile auch Security Scans der Artefakte an. Der bisherige Platzhirsch Nexus wird dabei langsam von Artifactory überholt:

Der Vortrag hat deutlich gemacht, dass das Lifecycle-Management immer wichtiger, aber auch immer aufwändiger wird.

WebAssembly 101

WebAssembly könnte die Art und Weise, wie wir »Web Apps« schreiben, revolutionieren. Der Vortrag gab dem Namen (»101«) folgend einen guten Einstieg in das Thema.

WebAssembly ist ein binärer Befehlssatz, also eine Art Maschinensprache. Der Befehlssatz gilt allerdings nicht für einen speziellen Prozessor, sondern für eine virtuelle Maschine, welche von einer Arbeitsgruppe des World Wide Web Consortium (kurz W3C), dem Gremium zur Standardisierung der Techniken im World Wide Web, verabschiedet wird. Dadurch ist diese virtuelle Maschine auch bereits in allen modernen Browsern vorhanden, wodurch diese zusätzlich zu JavaScript eine weitere Laufzeitumgebung erhalten.

Da es in der Geschichte des Webs schon ähnliche Versuche gab, von Java Applets über Silverlight und Flash bis zu ASM.js und natürlich auch JavaScript, ist eine Abgrenzung hilfreich:

• WebAssembly ist keine Programmiersprache und kein neuer Browser;
  – es soll weder JavaScript ablösen, noch ist es so etwas wie Flash oder Java Applets.
• Ohne einen entsprechenden Host funktioniert die Technologie nicht,
  – wobei der Host nicht auf das Web beschränkt ist: alles kann ein WebAssembly Host sein.
• WebAssembly ist bislang noch im MVP-Status und dadurch
  – weder multi-threaded, was sich mit Web Workern aber umgehen lässt,
  – noch garbage-collected, was erklärt, warum Java noch nicht zu WebAssembly kompilieren kann.

Aufgrund der Eigenschaften von WebAssembly, wie zum Beispiel Geschwindigkeit, Portabilität, Effizienz und Sicherheit, sind Anwendungsfälle insbesondere im Umfeld Mobile, IoT sowie grundsätzlicher bei leistungsstarken Web-Anwendungen zu sehen.

Ziel ist dabei nicht, dass direkt in WebAssembly programmiert wird, da es sich wirklich um Binärcode handelt:

20 00

42 00

51

04 7e

42 01

05

20 00

20 00

42 01

7d

10 00

7e

0b

Es gibt zwar auch eine textuelle Entsprechung zu dem oben gezeigten Binärcode, also quasi Assemblercode, aber auch darin wollen wir heute nicht mehr wirklich direkt programmieren:

get_local 0

i64.const 0

i64.eq

if i64

    i64.const 1

else

    get_local 0

    get_local 0

    i64.const 1

    i64.sub

    call 0

    i64.mul

end

Ziel ist vielmehr, dass die gängigen Compiler neben den Prozessorarchitekturen, für die sie sowieso schon kompilieren können, also beispielsweise ARM32 oder x86-64 zusätzlich auch für WebAssembly kompilieren können. Für C/C++ und Rust sind bereits entsprechende Kompiler vorhanden. Das folgende C-Programm wurde beispielsweise entsprechend für WebAssembly kompiliert, um den voran gezeigten Binär- beziehungsweise Assemblercode zu erhalten:

int factorial(int n) {

  if (n == 0)

    return 1;

  else

    return n * factorial(n-1);

}

Der Ablauf, um ein Programm in WebAssembly zu erstellen und nutzen ist somit wie folgt:

1. Schreiben oder portieren eines Programms in einer Programmiersprache, welche WebAssembly unterstützt – derzeit C/C++, Rust und Go seit Version 1.11 zumindest experimentell.
2. Entsprechendes Kompilieren des Programms nach WebAssembly (WASM).
3. Das Kompilat wird dann über einen entsprechenden Webserver, der WebAssembly unterstützt, den sogenannten Host, ausgespielt
4. und kann dann, wie eine Webseite, von einem Browser, der WebAssembly unterstützt (Chrome, Edge, Firefox und WebKit/Safari), abgerufen werden.

Der Klassiker »helloWorld.c«

#include <stdio.h>

int main(int argc, char ** argv) {

  printf(„Hello, world!\n“);

}

kompiliert nach WebAssembly sieht als statische Seite im Browser natürlich noch unspektakulär aus:

Der in C geschriebene Editor VIM wurde aber auch schon erfolgreich nach WebAssembly kompiliert und ist darüber im Webbrowser lauffähig, was zeigt, welches Potential in der Technologie steckt:

Die Codebasis von VIM ist über 25 Jahre alt und umfasst mehr als 750.000 Zeilen, wurde aber in weniger als einer Woche von einem Entwickler nach WebAssembly portiert – inklusive Erlernen des notwendigen Toolings.

Im Vortrag »AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web« vom Donnerstag (siehe unten) gibt es weitere Details zu einem noch größeren Portierungsvorhaben. Die Spiele-Engine Unity ist wohl auch schon entsprechend portiert, »Tanks« lässt sich als WebAssembly-Demo zumindest schon im Browser spielen. Vielleicht ergibt sich so auch eine Lösung für das Cobol-Problem? Wir sind gespannt, ob und wann die ersten Cobol-Compiler WASM erzeugen können…

Understanding Code Performance in Production

Dieser Vortrag innerhalb der »Sponsored Tracks«, wurde von der Firma AppDynamics durchgeführt.

Produktive Umgebungen sind häufig anders als Entwicklungsumgebungen, da beispielsweise nicht jeder Entwickler auch zwangsläufig Zugang zu den entsprechenden Produktivsystemen seiner Applikation bekommt. Gleichzeitig verlagern sich die Erwartungen an den Betrieb von Applikationen durch Ansätze wie DevOps und You-Build-it-You-Run-it in Richtung Entwicklung. Hier kann sogenanntes Application Performance Monitoring dem Entwickler wichtige Informationen über das Verhalten seiner Software in Produktion liefern. Üblicherweise wird dabei bereits zur Entwicklungszeit eine entsprechende Software in die zu überwachende Applikation integriert, häufig in Form eines Agenten. Diese benötigen natürlich auch Ressourcen, weshalb sie mit bis zu 2 % Performance zu kalkulieren sind.

Am Markt haben sich mehrere Hersteller und Lösungen etabliert. AppDynamics ist dabei in Gartners Magic Quadrant für Application Performance Monitoring im Leaders-Quadranten eingestuft. Darüber hinaus war der Vortrag weitestgehend eine Produktvorführung.

From Software Development to Machine Learning

Bei diesem Vortrag handelte es sich um den Erfahrungsbericht der Transformation eines klassischen PHP-Software-Engineering-Teams hin zu Machine Learning aus Sicht der verantwortlichen Managerin. Der vorliegende Fall war sicherlich ein Extrembeispiel, da das Unternehmen sein Produktportfolio komplett umstellen wollte und die Entwicklung dementsprechend ebenso radikal umgestellt werden musste. Die Referentin hat das Unterfangen nicht ohne Grund mit einer Organtransplantation verglichen.

Die Transformation geschah dabei auf verschiedenen Ebenen:

• Individuum
• Team
• Unternehmen

Auf der Ebene des Individuums musste beispielsweise mit Python eine neue Technologie gelernt werden. Das mag sich zunächst nur nach einer weiteren Programmiersprache anhören, hat aber auch »soziale« Aspekte, da der Senioritätsgrad der Mitarbeiter damit quasi über Nacht abgestuft wurde, weil beispielsweise der vorherige PHP Senior Web Developer nun auf einmal Python Junior Engineer war.

Auf Team-Ebene muss man sich mit geänderten und ganz neuen Rollen auseinandersetzen. Aus einem Web Developer muss ein Machine Learning Engineer werden und aus einem Softwarearchitekt ein Data-Architekt. Ganz neu ins Spiel kommt der Data Scientist, nach Aussage der Referentin eine derzeit viel zu strapazierte Rolle, für die es bislang auch noch keine universelle Definition gibt. Außerdem können ihrer Meinung nach die wenigsten davon auf dem Level eines Software-Engineers entwickeln, da sie sich meist aus dem mathematisch-akademischen Bereich rekrutieren und damit zwar vielleicht gut in Algorithmen sind, aber nicht zwangsläufig wissen, wie man große, langlebige Systeme für den Produktiveinsatz entwickelt.

Aus eigener Projekterfahrung wissen wir, dass die Umstellung eines Teams auf eine neue Technologie zwar machbar ist, eine Organisation aber durchaus einige Jahre beschäftigen kann.

Wer sich selbst tiefer in das Thema Machine Learning einarbeiten möchte, findet hier eine gute Übersicht an Kursen.

Skype’s Journey From P2P

Dieser Vortrag zeigte Skypes Wandel von einer (»der«) P2P-Architektur hin zu einem Server- und Service-basierten Ansatz.

Mit dem ersten Release hat Skype 2003 eine der größten P2P-Architekturen ausgerollt. Jeder Client wurde dabei zu einem Knoten des P2P-Netzes, welcher weitestgehend losgelöst vom Backend operieren konnte. Das Backend bestand primär aus PostgreSQL-basierten Datenbank-Services, die Logik wurde überwiegend im Client implementiert.

Bezogen auf das CAP-Theorem, wonach in einem verteilten System von den drei Anforderungen Konsistenz (Consistency), Verfügbarkeit (Availability) und Partitionstoleranz nur zwei umfassend erfüllt werden können, konnte so maximale Verfügbarkeit und Partitionstoleranz (»AP«) sichergestellt werden.

Nach der Übernahme 2011 durch Microsoft wurde auch die Architektur hinterfragt. Dabei stellte sich heraus, dass die Welt beziehungsweise die Anforderungen sich geändert hatten. Desktop-Applikationen waren nicht mehr dominant, sondern mobile Anwendungen. Serverkosten hatten sich drastisch reduziert, dafür sollte Messaging beispielsweise auch offline möglich sein. Außerdem wurden Funktionen wie server-weites Suchen oder Vorschläge benötigt. Außerdem erschien es nicht mehr sinnvoll, die Logik im Client vorzuhalten. Die Funktionen des Skype-Clients wurden deshalb in mehreren Teilschritten auf eine verteilte Service-Architektur migriert, welche sich zum Teil natürlich auch bei bekannten Services von Microsoft bedient, beispielsweise MSA für Login:

Die Migration wurde dabei durch A/B Tests unterstützt, für welche eigens ein sogenannter Experimentation and Configuration Service (ECS) aufgebaut wurde, der mittlerweile bei ganz Microsoft im Einsatz ist.

Skypes ehemalige P2P-Architektur soll ab Herbst 2018 Geschichte sein. Interessant, dass auch ein IT-Gigant wie Microsoft für so ein Migrationsvorhaben immerhin 7 Jahre gebraucht hat.

Explaining Artificial Intelligence to Schoolchildren

Der Referent dieses Vortrags ist als Entwickler bei IBM für deren Programm Watson tätig und hat unter anderem eine web-basierte Lernumgebung rund um Machine Learning für Kinder erstellt. Da Machine Learning in immer mehr Bereiche vordringt, gab es für die anwesenden Entwickler auch gleich ein paar beruhigende Worte von einem, der seit Jahren in dem Umfeld professionell tätig ist:

»Artifical Intelligence adds to a developer’s toolbox, it doesn’t replace him.« –Dale Lane

Ihm ist es wichtig, aufzuzeigen, was Machine Learning als Teilbereich der Künstlichen Intelligenz (Artifical Intelligence) ist, was damit machbar ist und wo die Grenzen sind; und das möglichst auch schon Kindern, da diese zukünftig immer mehr mit entsprechenden autonomen Systemen konfrontiert sein werden.

»Machine Learning is…Learning how to perform a task from a collection of examples.« –Dale Lane

In der Lernumgebung werden Kinder auf spielerische Art und Weise durch die notwendigen Schritte für Machine Learning geführt:

• Sammeln von beispielhaften Daten (Bilder, Zahlen, Texte) für die Aufgabe
• Trainieren des Computers anhand der Beispieldaten (hier erfolgt das Lernen)
• Programmieren einer Anwendung, welche anhand des Gelernten entsprechende Aufgaben ausführt

Im ersten Schritt dreht es sich darum, entsprechende Daten für das jeweilige Vorhaben in ausreichender Menge zu sammeln – zum Beispiel Bilder von Gesichtern. Im zweiten Schritt wird das System dann trainiert. Beispielsweise werden die Bilder in zwei Gruppen von Menschen mit glücklichem und unglücklichem Gesichtsausdruck aufgeteilt. Im dritten Schritt wird über Scratch, die visuelle Programmiersprache für Kinder, welche in der Lernumgebung mit der API von Watson integriert ist, ein einfaches Programm geschrieben. Im genannten Beispiel würden neue Fotos anhand des Gesichtsausdrucks in glücklich oder unglücklich eingeordnet werden.

Wichtig ist dem Referenten dabei insbesondere auch immer wieder die Grenzen von Machine Learning aufzuzeigen. Konkret zum Beispiel die vielen Möglichkeiten, entsprechende Systeme bewusst oder unbewusst mit Vorurteilen anzulernen. Googles Bildersuche, die vor einiger Zeit die Bilder von zwei Afroamerikanern mit der Kategorie Gorilla versah, ist da nur ein Beispiel von vielen.

The Story of Teams, Autonomy, and Servant Leadership

Dieser Vortrag zeigte, wie Booking.com seine Entwicklungsteams im agilen Kontext aufgestellt hat und insbesondere wie die Entwicklung zum aktuellen Status Quo anhand von gesteuerten Experimenten faktenbasiert erfolgte. Dabei war der Fokus insbesondere auf der Rolle Teamleiter – nicht verwunderlich, da diese Rolle in den agilen Entwicklungsansätzen wie beispielsweise Scrum nicht weiter definiert ist, was von vielen so interpretiert wird, als bräuchte es gar keiner Führung im agilen Kontext. Das dem nicht so ist, zeigte der Referent, selbst Führungskraft bei Booking.com, entsprechend auf.

Booking.com ist von acht Mitarbeitern im Jahr 2000 auf aktuell über 15.000 angewachsen, wovon derzeit über 1.500 Mitarbeiter in der IT tätig sind. Um 2014 waren rund 500 Mitarbeiter in der IT. Jedes Team hatte dabei einen Teamleiter und einen Product Owner, die wiederum an einen Senior Teamlead (Abteilungsleiter) und einen Senior Product Owner berichtet haben, welche dann direkt entsprechend an den CTO und CPO berichtet haben:

Aufgabe des Teamleiters war zu rund ⅔ fachliche Mitarbeit im Team und zu rund ⅓ klassische Teamleitungsaufgaben wie zum Beispiel Prozesse, teamübergreifende Kommunikation, Mitarbeiterentwicklung und -leistung. Der Product Owner war für Aufgabenpriorisierung, Backlog-Verwaltung, Metriken und die Kommunikation mit dem Business beziehnungsweise Fachbereich verantwortlich.

Zwischen 2015 und 2016 setzte dann ein extremes Wachstum des Unternehmens ein, was zu einer Verdoppelung der Anzahl der Mitarbeiter in der IT auf rund 1.000 führte. Dies machte auch andere Führungsansätze notwendig, weshalb autonome Teams als Lösungsansatz untersucht wurden. Damit gemeint war, dass Teams ohne Teamleiter arbeiten und alle Teammitglieder gleichermaßen für entsprechende Aufgaben verantwortlich sind. Die bisher vom Teamleiter quartalsweise und 1:1 erfolgten Performance Reviews erfolgten jetzt beispielsweise in einer gemeinsamen Teamsitzung. Spannend, inwiefern das arbeitsrechtlich in Deutschland abbildbar wäre. Der Product Owner als Verantwortlicher für die geschäftlichen Aspekte blieb erhalten, die Teams berichteten innerhalb der IT jetzt direkt an den Senior Teamlead:

Das Ganze wurde als Experiment mit 26 von 84 Teams in der IT erprobt. Fokus war dabei auf der Effektivität der Teams analog zu Googles »Perfect Team« und den entsprechenden Metriken.

Booking.com stellte im Laufe des Experiments drei Hauptprobleme fest. Erstens konnte das angestrebte Wachstum in den autonomen Teams ohne entsprechende Unterstützung (durch die Teamleitung) nicht wie gewünscht sichergestellt werden. Zweitens verändern sich Teams (siehe hierzu auch weiter oben zum Workshop vom Dienstag »Coaching the Team System«) und brauchen auch dabei Unterstützung. Drittens waren die Senior Teamleads mit der Vielzahl an Teams, die direkt an sie berichteten, trotz der vermeintlichen Autonomie überfordert.

Den Problemen wäre vermutlich noch zu begegnen gewesen, die wesentliche Kennzahl für Booking.com, das Engagement der Mitarbeiter, ging in diesem Experiment autonomer Teams ohne Teamleitung allerdings erheblich zurück. Es musste also etwas verändert werden. Booking.com versuchte dabei, das Beste aus beiden Ansätzen zu nehmen und kam zu folgender Erkenntnis:

Es sollte also autonome Teams, aber mit Teamleiter geben. Hierfür wurde die Aufgabenbeschreibung und insbesondere das Skillprofil der Teamleitung in Richtung Servant Leadership geschärft. Die »neue« Teamleitung hat also keine beherrschende Macht mehr über das Team, sondern ist Teil desselben. Die Performance Reviews werden beispielsweise weiterhin analog zum autonomen Team in einer gemeinsamen Sitzung abgehalten, in der jetzt auch der Teamleiter mit bewertet wird und selbiger auch nur eine Stimme, wie jedes Teammitglied hat.

Die Teamleitung arbeitet nach wie vor fachlich mit, aber nur noch unter 50 % und verwendet zukünftig mehr als die Hälfte seiner Zeit auf Personalentwicklung:

Da es nicht leicht ist, solche Teamleiter zu rekrutieren, setzt Booking.com agile Coaches ein, um die Teamleiter hier entsprechend zu unterstützen und zu entwicken.

Wichtig auch die Erkenntnis, was Autonomie für Booking.com nicht ist:

• Alleine arbeiten,
• Anarchie oder
• Vernachlässigung.

Die Erkenntnis aus dem gesteuerten Experiment von Booking.com ist, dass Teams auch eine Teamleitung brauchen, andernfalls sinkt die Effektivität. Teamleitung ist hier aber keine beherrschende, sondern eine dienende Rolle mit entsprechenden Aufgaben.

AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web

Nach der interessanten Einführung in WebAssembly am Dienstag zeigte der Referent dieses Vortrags, wie AutoCAD mittels WebAssembly erfolgreich für das Web portiert wurde. Es handelt sich dabei um eine C/C++-Desktop-Applikation, deren Codebasis rund 15 Millionen Codezeilen umfasst und die bis ins Jahr 1982 zurückreicht.

Als die Entwicklungsmannschaft vor der Aufgabe stand, diese Applikation fit für das Web zu machen, wurde relativ schnell klar, dass ein Neuschreiben aufgrund des Umfangs keine Option war, da es weder nachhaltig ist, zwei Entwicklungslinien für so ein Produkt aufrechtzuerhalten, noch so ein Unterfangen auch nur ansatzweise schnell genug wäre. Ganz zu schweigen vom 2nd-System Effect. Deshalb wurde sich auf die Option der Cross-Kompilierung der Codebasis fokussiert. Es wurden verschiedene Ansätze (Flash, JavaScript, asm.js) probiert, bevor der Durchbruch mit WebAssembly gelang. Als Toolchain kommen dabei Emscripten und WebAssembly Binaryen zum Einsatz.

Mit einem einfachen Kompilieren einer so großen Codebasis war es natürlich nicht getan. Es mussten sowohl an der Codebasis als auch an der Toolchain Anpassungen vorgenommen werden, um folgenden Herausforderungen zu begegnen:

• Kompilier- und Build-Zeit der Codebasis
• Startzeit der Applikation
• Desktop- gegenüber Web-Paradigma.

Die beiden ersten der eben genannten Punkte hängen natürlich direkt mit der umfangreichen Codebasis zusammen. Aber gerade der letzte Punkt, die gegenläufigen Entwicklungsparadigmen zwischen Desktop- und Web-Applikationen, betreffen jeden, der eine entsprechende Software portieren möchte. Als Beispiel wurden synchrone und asynchrone Programmierprobleme im Web genannt. Die Behandlung von blockierenden Aufrufen ist in Desktop-Programmen anders als im Web. Und dann wurde noch Shared Memory angeführt. Desktop-Applikationen erlauben synchrone Schreibzugriffe, da es dort Shared Memory gibt, um Daten zu teilen – im Web gibt es das so nicht.

Für die genannten Probleme fanden die Entwickler bei AutoCAD aber Lösungen, vielleicht nicht in Tagen, so aber in der Regel doch in Wochen oder zumindest Monaten, was in keinem Vergleich zu dem mehrjährigen Neuschreiben der Software steht. Die Applikation steht durch Cross-Kompilierung mittels WebAssembly heute auch als Web-Applikation zur Verfügung.

Breaking Codes, Designing Jets and Building Teams

Dieser Vortrag hätte auch durchaus als Keynote laufen können. Der Referent, Randy Shoup, hat 25 Jahre Erfahrung im Engineering bei den Größen des Silicon Valleys, beispielsweise Director of Engineering bei Google, Chief Engineer bei eBay, Tech Lead bei Oracle und aktuell VP Engineering bei WeWork. Er ist aber auch der Sohn von Richard Shoup, Gründungsmitglied des berühmten Xerox Palo Alto Research Center. Damit hat der Referent natürlich Einblick in die Geschichte des (IT) Engineering wie wenig andere. Und dessen bediente er sich, um anhand von drei Beispielen für sehr effektive Engineering-Teams deren Gemeinsamkeiten herauszuarbeiten.

Sein erstes Beispiel für ein effektives Team betraf die Code-Brecher der britischen Militäreinrichtung Bletchley Park, welche den ersten programmierbaren digitalen Computer bereits 1943 vollständig im Geheimen bauten. Es wird geschätzt, dass dank Bletchly Park der zweite Weltkrieg um zwei Jahre verkürzt und somit 14 Millionen Leben gerettet werden konnten (=> Zweck). Trotzdem es sich um eine Militäreinrichtung handelte, gab es wenig Hierarchie und eine offene => Organisationskultur. Jedes Team war cross-funktional aufgestellt, zwischen den Teams herrschte allerdings absolute Geheimhaltung (also Unabhängigkeit). Aufgrund der sich ständig ändernden Codes mussten auch die Teams permanent lernen und iterieren (=> technische Exzellenz). Dabei waren die Teams extrem divers mit einer Frauenquote von bis zu 75 % (=> Menschen). Bekanntheit hat hierbei natürlich insbesondere Alan Turing erlangt, aber auch Ian Fleming, der Erfinder von James Bond, hat hier gearbeitet.

Als zweites Beispiel für außergewöhnliche Engineering-Leistungen wurde Lockheeds sogenannte “Skunk Works” Advanced Developments Gruppe aufgeführt. Seit Gründung 1943 wurden hier Generation um Generation der weltweit am schnellsten und höchsten fliegenden sowie geheimsten Flugzeuge entwickelt, wie zum Beispiel die F-117A Nighthawk. Entgegen dem im modernen Flugzeugbau wohl üblichen Vorgehen, erfolgten Design, Entwicklung und Bau hier innerhalb einer cross-funktionalen Einheit, wo alle beteiligten Rollen eng zusammen saßen (“Co-Location”) und beispielsweise auch der Testpilot eng in den Entwicklungsprozess involviert war (=> Organisationskultur). Dabei war jeder für Qualität verantwortlich:

We made every shop worker who designed or handled a part responsible for quality control. Any worker – not just a supervisor or a manager – could send back a part that didn’t meet his or her standards.

Es wurde schon sehr früh umfassend Gebrauch von Modellen, Simulationen sowie Mockups und Prototypen zum Verifizieren von Hypothesen gemacht (=> Technische Exzellenz). Und auch dieses Team war von Anfang an durch Diversivität geprägt. So war beispielsweise Mary G. Ross als erste amerikanische Ureinwohnerin Gründungsmitglied und Engineer der Skunk Works Group (=> Menschen).

Als drittes Beispiel führt Shoup das Xerox PARC an, welches 1970 gegründet wurde und dessen Erfindungen die Grundlage unserer heutigen digitalen Welt sind. Beispielsweise wurden hier Smalltalk als »Mutter der Objektorientierung«, das erste graphische Benutzerinterface mit überlappenden Fenstern als Basis für Apple und Microsoft Windows, die WYSIWYG Textbearbeitung, Ethernet oder auch der Laserdrucker genannt.

Kurzer Einschub an dieser Stelle: Die Erfindung der Computermaus wird auch gerne wahlweise dem Xerox Parc oder Doug Engelbart zugeschrieben, es scheint aber so, dass hier tatsächlich Telefunken aus Deutschland die Nase vorn hatte.

Die => Organisationskultur des Xerox PARC war flach, ohne Hierarchie und versammelte Talente wie Alan Kay, Adele Goldberg und Richard Shoup (=> Menschen) aus der Industrie und dem universitären Bereich.

Aus diesen drei Beispielen für extrem effektive Engineering-Einheiten konnte der Vortragende die folgenden gemeinsamen Eigenschaften als Prinzipien effektiven Engineerings ableiten:

• Zweck: Die Teams müssen »groß« denken dürfen, dabei aber fokussiert auf ein wichtiges und motivierendes Ziel für die Organisation sein.
• Organisationskultur: Cross-funktionale »Full Stack« Teams sind für diese Art von Arbeit am effektivsten, das Team muss maximale Autonomie bei minimaler Bürokratie und minimaler zentrale Kontrolle haben; Zusammenarbeit und eine Kultur des Lernens sind weitere Schlüssel zum Erfolg.
• Menschen: Unabhängig von ihrem Hintergrund sind die besten Leute für den jeweiligen Job zu engagieren, dabei ist Diversität wichtig; die Menschen sind gut zu behandeln – schlimm, dass das immer noch erwähnenswert ist, siehe hierzu auch unsere Definition von Leistung, die immer schon die ethische Komponente umfasste.
• Technische Exzellenz: Systemisches Denken und die Suche nach ganzheitlichen Lösungen sind der Schlüssel zu technischer Exzellenz. Dabei muss pragmatisch geliefert werden und konstantes Feedback in alle Prozesse integriert werden.

Vieles davon findet sich heute in den Prinzipien von Agile, Lean oder auch DevOps wieder, wurde dort aber nicht »erfunden«, sondern geht auf Beispiele wie die hier genannten zurück.

Empowering Agile Self-Organized Teams With Design Thinking

Dieser Vortrag gliederte sich in drei Teile. Zunächst stellte der Referent ausführlich seinen grundsätzlichen methodischen Rahmen vor. Anschließend ging er über eine Fallstudie der agilen Transformation einer konkreten Infrastruktureinheit auf Design Thinking für die Gestaltung von Organisationen ein. Abschließend stellte er das theoretische Gerüst von Design Thinking vor.

Der grundsätzliche methodische Rahmen des Referenten war geprägt von »Klassikern« agiler Management-Ansätze.

»People are already doing their best; the problems are with the system. Only management can change the system.« —W. Edwards Deming

»Every system is perfectly designed to get the result that it does.” ― W. Edwards Deming

Aus Sicht des Referenten gibt es nicht den einen und besten Weg, etwas zu organisieren und somit auch nicht »das eine« Organisationsdesign. Er spricht sich auch klar und deutlich gegen klassische autoritäre Managementansätze aus:

»Organizations that operate from the authoritarian, hierarchical, command and control model, where the top leaders control the work, information, decisions, and allocation of resources, produce employees that are less empowered, less creative, and less reductive.« –Creativity and Innovation: The Leadership Dynamics. Journal of Strategic Studies

Dabei hob er auch noch einmal die Quellen von Macht in Organisationen auf Basis von French und Ravens grundlegeneder Arbeit hierzu aus dem Jahre 1959 hervor:

• Legitime Macht durch formale Autorität in einer Hierarchie.
• Wissensmacht durch Expertenwissen auf einem Gebiet.
• Macht durch Vergabe von Belohnung wie beispielsweise finanzielle aber auch immaterielle Anreize (Lob, Erweiterung des Verantwortungsbereiches).
• Macht durch Zwang wie beispielsweise die Möglichkeit, Degradierungen oder Entlassungen vorzunehmen.
• Macht durch Identifikation setzt charismatische Persönlichkeiten voraus, mit denen man sich identifizieren möchte.
• Informationsmacht entsteht durch die Fähigkeit, den Fluss von Informationen und auch Desinformationen in Organisationen steuern zu können.

Womit er zum »Empowerment«, also der Ermächtigung von Mitarbeitern überging. Dies bedeutet für den Referenten, dass eine Gruppe von Mitarbeitern Entscheidungen in einem gewissen Rahmen eigenständig und ohne weitere Rückversicherung beim Management treffen kann. Dem Management kommt hierbei eine besondere Bedeutung zu, weshalb der Referent anhand des sogenannten »Leadership Continuums« verschiedene Führungsansätze diskutierte:

Beide Enden des dargestellten Kontinuums schnitten dabei nicht besonders gut ab. Diktatorische Führung führt dazu, dass Mitarbeiter sich nicht ermächtigt fühlen und ihnen die Möglichkeit genommen wird, selbst Lösungen zu suchen, welche in der Regel besser sind, da sie näher am Problem sind. Das andere Ende, also vollständige Ermächtigung der Mitarbeiter, ist dabei allerdings auch nicht der Königsweg. Der Referent spricht hierbei auch vom Hippie, der gerade noch Ziele vorgibt und dann verschwindet. Dabei ist für die Mitarbeiter dann häufig keine Strategie erkennbar und es wird wenn überhaupt noch lokal optimiert.

Der Lean Leader hingegen:

• Klärt die Vision und Absicht, also das Warum und Was,
• benennt dabei aber auch die Grenzen und
• vergibt Entscheidungsbefugnisse.
• Er lebt entsprechendes Verhalten vor und
• erzeugt Vertrauen.
• Er bevorzugt Experimente, die auch scheitern können, statt Lösungen vorzugeben.

Der erste Teil des Vortrags schloß mit dem folgenden Zitat ab:

»Individuals and teams closest to the problem, armed with unprecedented levels of insights from across the network, offer the best ability to decide and act decisively.« -General Stanley McChrystal

Interessanterweise spiegelt dieses Idealbild die Situation in Teilen der US-Armee, einer bis dato doch sehr hierarchischen Organisation wider, die sich aber aufgrund geänderter Rahmenbedingungen auch entsprechend an ein neues Führungs- und Organisationsprinzip angepasst hat.

Ausgangssituation der Fallstudie im zweiten Teil des Vortrags war folgendes, wohlbekanntes Spannungsfeld zwischen Fachbereich und IT-Infrastruktur-Entwicklungsteam eines großen Pharmaunternehmens, welches nach Wasserfall-Modell arbeitete:

»You deliver last years tech, in twice the time, for three times the price, and a fraction of the value!«

Nur sechs Wochen nach Umstellung auf eine agile Arbeitsweise konnten bereits folgende Erfolge vermeldet werden:

• Reduzierung der Lead Time für Services von 9 Monaten auf Tage, häufig Stunden.
• Reduzierung ungeplanter Arbeit von 64 % auf 28 %.
• Erhöhung der Zufriedenheit des Fachbereichs um 72 %.

Dies wurde folgendermaßen erreicht:

1. Aufsetzen eines Kanban-Systems
2. Visualisierung aller Arbeit im Team
3. Messen des Wertstroms
4. Identifizierung aller Schritte, insbesondere Verschwendung (Frei-/Übergaben)
5. Einbeziehung der Anwender
6. Einbindung relevanter Stakeholder (Compliance, Security, Finance, …)
7. Durchführung einer Designstudie für den neuen Prozess
8. Prototypisierung, Testen, Messen und Lernen für diesen neuen Prozess
9. Minimum Viable Services entwicklen
10. Iterieren, Testen, Messen, Lernen, Iterieren, Wiederholen

Der Wertstrom-Messung kam dabei eine besondere Bedeutung zu, denn darüber lässt sich:

• Der Grund für Falschbedarf erkennen.
• Verschwendung im System identifizieren, wie zum Beispiel
  – Warteschlangen
  – Unnötige Freigaben
  – Rückgaben und Nacharbeiten.

Den dritten Teil des Vortrags zum Hintergrund von Design Thinking leitete der Referent folgendermaßen ein:

»In practice it combines empathy to enable deep understanding and reframing of a problem in context, divergence to generate insights and solutions; visualization and prototyping to document, connect and test ideas, and rationality to analyze and assess the solutions outcome.« – TIM BROWN, IDEO

Hintergrund sind dabei die Grundlagen von Peter G. Rowe »Design Thinking« aus dem Jahr 1987 und Richard Buchanans »Wicked Problems in Design Thinking« von 1992. Wichtig ist dabei, analog zum Brainstorming, zunächst in einem sogenannten Divergence-Schritt möglichst viele Optionen zu generieren, um im folgenden Convergence-Schritt durch Entscheidungen den Lösungsraum wieder einzugrenzen:

Ohne das Problem richtig verstanden zu haben, kann auch keine gute Lösung gefunden werden, denn

»A problem well stated is mostly solved.« — CHARLES KETTERING

Hierzu ist wiederum eine empathische Herangehensweise notwendig, denn in jedem Problem, welches zu uns gebracht wird, steckt die Chance, im Rahmen von Design Thinking etwas zu verbessern.

»The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership.« – COLIN POWELL

Was dann alles zusammengefasst zum sogenannten Double Diamond Modell des Design Thinking führt:

Software Is Eating the World, ML Is Going to Eat Software

Der Referent dieses Vortrags ist Engineer im Developer Infrastructure Team von Facebook. Der Einblick ins Engineering bei Facebook und dass sie dort überhaupt genau so ein Team haben, welches Tools und Infrastruktur für Entwickler zentral bereitstellt, war dabei gleich die erste interessante Information.

Facebook möchte Machine Learning in jeder Schicht ihres Technologiestacks integrieren, um Entwickler produktiver und Prozesse und Infrastruktur effizienter zu machen. Machine Learning ist dabei für Facebook nur ein weiteres Tool, wie beispielsweise objektorientierte oder funktionale Programmierung, welche auch entsprechend tief in die Programmiersprachen und Entwicklertools, wie zum Beispiel IDEs oder Versionskontrolle integriert wird.

Machine Learning kommt da zum Einsatz, wo viele Daten anfallen, um Vorhersagen abzuleiten und Klassifizierungen sowie Cluster zu bilden. Der Referent nannte dabei zwei konkrete Anwendungsfälle in seinem Umfeld bei Facebook: zum einen das Cache Management in der Infrastruktur und zum anderen die Autovervollständigung ganzer Codeteile in der Entwicklung. Ausgangssituation für Letzteres ist dabei folgende Erkenntnis:

»70 % des Codes auf Github ist Copy & Paste.« – Joe Pamer

Da der meiste Code also sowieso kopiert wird, sollen Entwickler in ihrer IDE, ähnlich zur Autovervollständigung von beispielsweise Schlüsselwörtern der jeweiligen Programmiersprache, Vorschläge für ganze Codeteile, wie zum Beispiel Methoden oder Klassen bekommen, die an die jeweilige Stelle im Code passen könnten. Das geht dann über einfache Code-Suche, wie wir zum Codesharing mit Tools wie Sourcegraph und Searchcode skiziiert haben, hinaus und schon mehr in Richtung Deep Code Search, aber eben auf Basis der umfangreichen Codebasis von Facebook und mit Machine Learning, da Code ja auch nur strukturierte Daten sind. Mit diesem Ansatz konnte die Produktivität der Entwickler bei Facebook bereits um 14 % gesteigert werden. Bei geschätzten 10.000 Entwicklern, die für Facebook arbeiten, ist dies ein erheblicher Produktivitätsgewinn.

Einschätzung

Die Workshops waren unserer Einschätzung nach nicht ganz »bleeding-edge«, die Keynotes und Vorträge durchaus. Wobei die New Yorker QCon auf uns insgesamt etwas kleiner und vermutlich da eben nicht im Silicon Valley gelegen, auch nicht ganz so pulsierend wie die Veranstaltung in San Francisco gewirkt hat. Egal wo, die Veranstaltungen sind immer einen Besuch wert, denn auch wenn es heutzutage eigentlich dafür keinen Grund mehr geben sollte, so sind die Themen hier entsprechenden Veranstaltungen in Deutschland dann doch immer noch ein Stück voraus.

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Conways Law, welches bereits seit 1967 (!) intensiv diskutiert und viel zitiert worden ist, besagt, dass Systeme die Organisationsstrukturen der Einheiten reflektieren, in denen sie entstehen:

»Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.«

Oder anders formuliert, man bekommt nicht zwangsläufig die Systeme, die am Whiteboard, Flipchart oder in UML designed wurden, sondern Systeme, die aussehen, wie das Organigram der sie umgebenden Organisation. Da Systeme und Organisationen i.d.R. anderen Änderungszyklen unterliegen und die jeweiligen Änderungen anders motiviert sind, laufen System- und Organisationsgrenzen irgendwann zwangsläufig auseinander:

Dies führt zu erheblichen Schwierigkeiten in Entwicklung und Betrieb entsprechender Software-Systeme, da sich die Verantwortung für ein System dann schnell über mehrere Organisationseinheiten hinweg erstreckt, was zu Abhängigkeiten, unklaren Verantwortlichkeiten, erhöhtem Abstimmungsbedarf, usw. führt.

Interessant ist zu sehen, was passiert, wenn man auseinander gelaufene System- und Organisationsgrenzen wieder in Einklang bringt, wie wir im folgenden Artikel an einem unserer Projekte in anonymisierter Form aufzeigen.

Hintergrund

Im konkreten Fall sollte der IT-Bereich eines Online-Unternehmens reorganisiert werden, da aufgrund des starken Wachstums der Firma, dieser den anstehenden Aufgaben nicht mehr gewachsen war. Das Unternehmen war einer klassisch-funktionalen Aufbauorganisation folgend strukturiert. Das nachfolgend vereinfacht dargestellte Organigram erschien auf den ersten Blick unauffällig:

Unsere der sog. [Theorie Z][4] folgende Analyse ergab u.a., dass die Mitarbeiter in der dortigen IT in einer eher technologischen Aufbauorganisation, welche nicht im Einklang mit der fachlichen, projektseitigen oder auch betrieblichen Realität stand, eine historisch gewachsene, [komplexe und komplizierte][5], monolitische Architektur mit einer Vielzahl an Technologien / Systemen und hohen technischen Schulden entwickelten und betrieben.

Selbst kleine Anpassungen führten zu hohen Aufwänden und regelmäßigem Überschreiten der vereinbarten Termin- und Budgetzusagen, da alles mit allem zusammenhing und eine Änderung an einer Stelle immer auch Anpassungen an einer Vielzahl von anderen Stellen bedeutete. Das Gesamtsystem war kaum noch beherrschbar.

Eine erste, qualitative Untersuchung der Makro-Architektur, insb. im Hinblick auf die wesentlichen Architektursichten brachte die in folgender schematischer Darstellung zusammengefassten Erkenntnisse:

Wie häufig war über die Architektursichten hinweg kein einheitlicher Systemschnitt zu finden. Die fachliche Anforderungssicht war bisher nur wenig ausgeprägt und folgte bspw. nicht der User bzw. Customer Journey eines Kunden im Portal. Die einzelnen Softwaresysteme waren »historisch gewachsen«, dabei aber zunehmend ihrem initialen, technologischen Ordnungsmuster der 3-Schichten-Architektur entflohen (»Architekturerosion«). Wenig verwunderlich, da die Gliederung in Frontend, Backend, und Datenhaltung (Persistenz) von Systemen i.d.R. wenig mit der Sicht des Anwenders gemein hat. Die Infrastruktur wiederum folgte einem ganz anderen Muster und war auch organisatorisch stark vernachlässigt, wie weiter unten zu sehen ist. In Folge kaskadierte sich eine einzelne fachliche Änderung auf zahlreiche Anpassungen diverser Systeme, welche wiederum weitere Änderungen anderer Systeme nach sich zogen.

Wobei an dieser Stelle auch eine Lanze für die Software-Architekten gebrochen werden muss: die einheitliche Durchsetzung einer Architekturidee über mehrere Architektursichten hinweg ist nach wie vor eine erhebliche Herausforderung. Bis dato kann der Architekt überwiegend retrospektiv und eher Dokumenten-basiert, also über Konzept-, Spezifikations- und Code-Reviews/-Analysen feststellen, ob (s)eine Architekturidee eingehalten und entsprechend umgesetzt wurde. Architektur-DSLs (Domain-Specific Languages) stellen hier einen interessanten Ansatz dar, die Wahrheit steckt aber schlußendlich im Code. Der Architekt ist in der Rücklage gegenüber der Software-Entwicklung, insb. im agilen Umfeld; nachträgliche Umbauarbeiten an den Systemen, um selbige wieder ins architekturelle Modell zu bekommen, sind nur selten gegen den üblichen Marktdruck durchsetzbar. Das Label »historisch gewachsen« haben wir schon an vielen anderen von uns untersuchten Architekturen gefunden. Die geschickte Kombination moderner Ansätze (Microservices-Architekturstil, Domain-driven Design, …) und das Verlassen etablierter Software-Engineering-Paradigmen, wie z.B. der zentralen Datenhaltung, aber bspw. auch das bewusste Akzeptieren von Redundanz, etc. verspricht hier Besserung, wie wir auch in folgenden Artikeln noch aufzeigen werden.

Im konkreten Fall war die gesamtheitliche Betrachtung von Architektur und Organisation, Conways Law aber auch unserem Ansatz von [IT-Management-Beratung][12] folgend, der nächste Schritt:

Weder die Aufbauorganisation der Fachbereiche noch der IT ließen sich in der Architektur verorten. Darüber hinaus standen aber auch die Strukturen der Fachbereiche, also der internen Kunden der IT, in keiner Beziehung zur Organisation des IT-Bereichs. In Folge setzte sich die schon auf Architekturebene gezeigte Abhängigkeitskaskade in der Organisation fort und verstärkte sich entsprechend. Eine einzelne Änderung führte nicht nur zur notwendigen Anpassung einer Vielzahl von betroffenen, abhängigen Systemen, sondern involvierte auch eine Vielzahl von Ansprechpartnern und Teams. Die Organisation war im permanenten Eskalationsmodus.

Die quantitative Auswertung der historischen Änderungsaufträge eines Jahres bestätigte die qualitative Betrachtung: in 50% der Fälle kam es zum sog. »Übersprechen«. Jeder zweite Änderungsauftrag führte im vorliegenden System- und Teamzuschnitt also zu Abstimmungen mit anderen Teams und entsprechenden Anpassungen weiterer Systeme.

Lösungsansatz

Welches Ordnungskriterium sollte nun aber angesetzt werden, um die erodierende Architektur wieder mit der divergierenden Organisation in Einklang zu bringen? Da Softwareentwicklung zumindest in den meisten Fällen kein Selbstzweck ist, sondern dem Kunden/Anwender dienen sollte, fängt auch unser Lösungsansatz mit der Fachlichkeit, also der Anforderung, dem Use Case oder der User Story an. Da Anforderungen häufig »organisationspolitisch« gefärbt sind, also von Interessen der Einheiten, die sie gestellt haben, geleitet werden, gingen wir im konkreten Fall zunächst noch einen Schritt weiter »zurück« in der Anforderungskette zum Anwender im Portal.

Insbesondere im kundennahen Online-Umfeld mit geringer Standardisierung und Wiederverwendbarkeit bei hoher Individualsierung durch die notwendige Differenzierung sollte der Fokus auch entsprechend extern, also auf den Kunden gelegt werden. Im Umfeld von ERP-Standardsoftware-Entwicklung bspw. mag der Fokus auch entsprechend eher intern auf Kostenoptimierung (Stichwort: Kostenführerschaft) gelegt werden.

In einem ersten Schritt analysierten wir dementsprechend innerhalb der fachlichen Architektursicht die User bzw. Customer Journey und leiteten daraus unter Hinzuziehung weiterer, unternehmensinterner Aspekte ein fachliches Domänenmodell ab. Eric Evans Domain-Driven Design, auf welches wir in einem separaten Beitrag eingehen werden, war hierbei natürlich mit in unserem Handwerkskoffer.

Dem Domänenmodell ordneten wir in einem nächsten Schritt die entsprechenden Softwaresysteme zu und es entstand eine fachlich getriebene Zielarchitektur, welche den Bebauungsplan für die notwendigen Umbaumaßnahmen der Systemarchitektur darstellte:

Anschließend richteten wir die Teams ebenfalls gemäß dem Domänenmodell neu aus. Das Produktmanagement stellte je Domänenteam einen Product Owner, der im agilen Sinne die Verantwortung dafür übernahm, was umgesetzt wird. Das Entwicklungsteam der IT verantwortete die technische Umsetzung, also das »Wie« und übernahm in seiner Domäne gemäß Werner Vogels (CTO Amazon.com) Ansatz »You build it, you run it« auch die Betriebsverantwortung.

Somit waren alle drei Architektursichten organisatorisch und technisch autark in jeweils einem Domänen-Team vereint, das Produktmanagement kapselte die Fachlichkeit, IT-Organisation und Fachbereichsorganisation sowie Architektur waren wieder im Einklang:

Die resultierende Matrixorganisation war dem Umstand der zwei beteiligten Linien-Organisationseinheiten geschuldet und in der konkreten Projektsituation das organisatorisch maximal Mögliche. Produktentwicklung hat ebenso wie Softwareentwicklung unserer Einschätzung nach einen langfristigen Charakter und sollte dementsprechend idealerweise auch in einer entsprechend langfristig ausgerichteten Linien-Produktentwicklungsorganisation erfolgen; dies werden wir in einem separaten Beitrag noch näher beleuchten.

Die anschließende quantitative Analyse der historischen Änderungsaufträge gegen die neue Architektur und Organisation ergab, dass das »Übersprechen« nur noch in 5-10 % der Fälle auftrat; gegenüber der Ausgangssituation mit 50 % also eine Verbesserung um ~80 %!

Neben unserer Erfahrung aus zahlreichen weiteren [IT-Management-Beratungsprojekten][18], insb. auch ähnlich gelagerten Vorhaben wie bspw. hier, fußte das Vorgehen und der Erfolg in diesem Projekt im Wesentlichen auf den genannten, etablierten (Conways Law; 1967) und neueren (Domain-Driven Design; 2003) Ansätzen; ganz nach dem Motto »Standing on the shoulders of giants«.

[1]: https://www.melconway.com/Home/Conways_Law.html

[2]: https://www.google.com/trends/explore#q=Conways%20Law

[3]: https://martinfowler.com/bliki/PolyglotPersistence.html

[4]: https://atra.consulting/blog/theorie-z/

[5]: https://atra.consulting/blog/wann-agil-und-wann-klassisch/

[6]: https://www.sigs-datacom.de/fileadmin/user_upload/zeitschriften/os/2011/Architekturen/tilkov_ghadir_OS_Architekturen_11.pdf

[7]: https://www.computer.org/csdl/proceedings/icse/2003/1877/00/18770740.pdf

[8]: https://de.wikipedia.org/wiki/Schichtenarchitektur

[9]: https://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/analyseentwurf/articles/98362/

[10]: https://www.sigs-datacom.de/fachzeitschriften/javaspektrum/archiv/artikelansicht/artikel-titel/liebe-deine-architektur-architekturmodellierung-und-automatisierte-ueberpruefung.html

[11]: Domain Driven Design

[12]: Über uns

[13]: https://www.bitkom.org/Publikationen/2011/Leitfaden/Leitfaden-EAM-Enterprise-Architecture-Management/EAM-Enterprise-Architecture-Management-BITKOM-Leitfaden.pdf

[14]: https://queue.acm.org/detail.cfm?id=1142065

[15]: https://www.computerwoche.de/a/t-systems-der-wankende-gigant,3070921

[16]: https://www.themanagement.de/Ressources/generische-strategien.htm

[17]: https://de.wikipedia.org/wiki/Matrixorganisation

[18]: Referenzen

[19]: https://inoio.de/blog/2014/09/20/technologie-sprung-bei-galeria-kaufhof/

[20]: https://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants

[21]: https://www.dokchess.de/_downloads/szoerner_SQD_2013_abhaengigkeiten.pdf

[22]: https://de.wikipedia.org/wiki/Customer_Journey

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn