Die SATURN 2015 des Software Engineering Institute (SEI) fand vom 27. bis 30. April in Baltimore statt. Die Konferenz war mit mehr als 200 Teilnehmern die bestbesuchte SATURN bisher und wurde ihrem Anspruch, eine Community für Praktiker zu sein, vollends gerecht. Eine gelungene Mischung aus Tutorials, eingeladenen Vorträgen, Keynotes und lustigen Events machte die Entscheidung schwierig, welche Session man am besten besuchen sollte.
Inhaltliche Schwerpunkte waren diese Themen:
- DevOps und Microservices
- Architektur im Spannungsfeld zwischen Business und Entwicklern
- Technical Debt und Modernisierung
- Agilität und Architektur
Netflix ist derzeit das meistzitierte Beispiel für den erfolgreichen Einsatz von Microservices. Getrieben durch Anforderungen wie niedrige Time-to-Market, schnelle Releasefähigkeit (Continuous Delivery) und hoher Parallelisierung der Entwicklung haben sich Microservices entwickelt und sind weiter auf dem Vormarsch.
Dabei sind Microservices weit mehr als ein weiterentwickelter Architekturstil (basierend auf Service-Orientierung), zumindest dann, wenn die genannten Anforderungen wirklich erreicht werden sollen. Microservices machen sehr stark deutlich, wie sehr es auf das Zusammenspiel von Systemarchitektur, Organisationsstruktur und Prozessen ankommt. Gemäß Conway’s Law gibt es eine Abstimmung zwischen Systemstruktur und Organisationsstruktur, nämlich die Zuordnung von Verantwortlichkeiten für Microservices auf Teams. Darüber hinaus ist dann ein Team nicht nur für die Entwicklung, sondern auch den Betrieb des Services zuständig, was dann unter dem Begriff DevOps bekannt ist. Dadurch dass mittlerweile die komplette Betriebsinfrastruktur als Cloud-Service bezogen werden kann, können sich die Entwicklungsteams somit rein auf den Applikationsbetrieb fokussieren.
Len Bass zeigte auf, was architekturell beachtet werden muss, um Microservices und DevOps umzusetzen, z.B. das Deployment von Microservices, die Abbildung auf Teamstrukturen oder der Umgang mit Upgrades,. Sam Newman (ThoughtWorks) stellte Prinzipien vor, die bei der Umsetzung von Microservices helfen, z.B. Modellierung nach Business Domains, Kultur für Automatisierung, Dezentralisierung, unabhängiges Deployment, Fehlerisolation und hohe Beobachtbarkeit.
Ein weiterer eng mit Microservices und DevOps verbundener Trend ist der Einsatz von Containern, in denen Ausführungsumgebung und Applikation gepackaged sind und dann einfach nur komplett auf Hardware deployed werden können (z.B. mit Docker). Dieser Trend setzt auf dem schon länger anhaltenden Trend zur Virtualisierung auf. Ein Vortrag von Google gab Einblicke in die Praktiken bei Google, wie dort die Verwaltung von Hardware und Infrastruktur durchgeführt wird. Große Teams sind nur für die Entwicklung Bereitstellung der Google-eigenen Infrastruktur zuständig, mit Hilfe derer dann riesige Mengen von Maschinen automatisch mit der richtigen Software versorgt werden können. Dazu kommen dann ganze „Produktionslinien“ zum Einsatz, um die entsprechend konfigurierten Container zu erzeugen („Image Bakery“). Unter dem Stichwort „Immutable Infrastructure“ versteht Google, dass solche Container nie wieder verändert, sondern immer wieder neu erzeugt werden.
Anhand der Beispiele Netflix, Google, etc. wird klar, dass sich insbesondere sehr große Firmen aus dem Internetbusiness derzeit leisten können, so massiv in die umgebende Infrastruktur und die Prozesse zu investieren, um Qualitätsattribute wie Time-To-Market zu erreichen. Trotzdem wird durch die immer besseren Cloudangebote auch ermöglicht, dass auch kleinere Firmen davon profitieren können.
Die Diskussion um Microservices war so stark präsent auf der SATURN, dass sie sich teilweise zum Running Gag entwickelte. Simon Brown (selbständiger Berater) hat das Thema in seinem Vortrag auch aufgegriffen und folgendermaßen diskutiert: „Wie möchten Firmen, die derzeit noch nicht einmal ihr System richtig strukturiert bekommen, das komplexe Geflecht aus Services, Prozessen und Organisationsstruktur meistern?“. Microservices kann man nicht als Technologie kaufen und man kann sie nicht von heute auf morgen einführen: Eine Organisation muss eine entsprechende Reife in der Architektur, in der Entwicklungsorganisation und in den Prozessen aufbauen und aufeinander abstimmen.
Gregor Hohpe (Allianz) charakterisierte in seiner Keynote einen Architekten unter anderem dadurch, dass er im Aufzug zwischen verschiedenen Ebenen eines Unternehmens unterwegs ist, die im Extremfall vom Vorstand bis zum einzelnen Entwickler reichen. Dabei ist es Aufgabe des Architekten, sich an die Bedürfnisse der jeweiligen Stakeholder anzupassen und mit Ihnen in Ihrer Sprache zu kommunizieren.
Jochem Schulenklopper (inspearit) stieg dazu provokant ein: „Why they just don’t get it: Communicating Architecture to Business Stakeholders“. Genauso provokant ging es weiter: Weil die Architekten es ihnen nicht richtig erklären können. Er berichtete von Architekten, die sich einfach nicht auf die Sprache von Nicht-Informatikern einlassen wollen und keine Empathie für ihr Zielpublikum haben. Er zeigte Vorschläge von Darstellungsformen, die sich an der Sprache von Managern orientieren. Insbesondere hielt er ein Plädoyer dafür, dass Kommunikation eine so essentielle Aufgabe von Architekten ist, dass man den Aufwand nicht scheuen darf, für einzelne Zielgruppen und Vorträge individuell angepasste Darstellungen zu erarbeiten. Wiederverwendung von Diagrammen aus dem Modellierungstool ist hingegen oft nicht die richtige Wahl.
Eltjo Poort (CGI) arbeitete auch die Beziehung von Architekten zum Management heraus. In seinem Vortrag legte er insbesondere Wert auf die Kommunikation von Wert und Risiken, die sich aus Architekturentscheidungen ergeben und für Managemententscheidungen besonders relevant sind.
Simon Brown betonte in seinem Vortrag „Software Architecture as Code“ besonders die Beziehung zwischen Architektur und Entwicklern und stellte die Entwickler als die wichtigste Zielgruppe von Architektur heraus, weil sie die geplante Architektur ja umsetzen müssen. Er bemängelte, dass sehr häufig in der Praxis Architekturdiagramme erzeugt werden, die sehr schwer bis gar nicht auf den Code abzubilden sind, z.B. weil sie nur Laufzeitstrukturen zeigen, aber keine Sicht auf die Implementierung. Mit seinen 4Cs (Context, Container, Component, Class) stellte Simon seinen Ansatz vor, um die Lücke zwischen Architektur und Code überwindbar zu halten. Dabei stellte er die Wichtigkeit von Architecture-Evident Coding Styles heraus, die es zum expliziten Ziel haben, eine erkennbare Abbildung der Architektur im Code zu erzeugen. Simons Ansatz erfordert in der Praxis allerdings auch eine Ergänzung um Laufzeitaspekte, Datenaspekte, etc., die nicht Bestandteil des Vortrags waren.
In der Praxis sind technische Schulden nicht zu vermeiden: Es geht nur um die Frage, wie eine Firma damit umgeht. Ipek Ozkaya (SEI) und Robert Nord (SEI) hielten dazu ein Tutorial, in dem sie das strategische Management von technischen Schulden beleuchteten.
Technische Schulden können vielerlei Ausprägung haben, z.B. schlechte Codequalität oder auch mangelnde Dokumentation. Die schlimmsten Auswirkungen (weil am schwierigsten und aufwendigsten zu beheben) haben aber Defizite in der Architektur.
Häufig sind technische Schulden das Ergebnis davon, dass schnelle Auslieferung Vorrang hatte vor langfristiger Qualität. Wenn dieser Kompromiss gemacht wird, dann sollte er zumindest bewusst gemacht werden. An dieser Stelle kommt Architekten eine wichtige Rolle zu: Sie müssen sich häufig dafür einsetzen, dass nicht zu viele technische Schulden gemacht werden und regelmäßig aufgeräumt wird („Schulden zurückzahlen“). Insbesondere agile Entwicklungsorganisationen legen häufig zu viel Wert auf schnelle Featureproduktion, mit dem Ergebnis dass die Architektur vernachlässigt wird.
Ipek und Robert zeigten im Tutorial Ansätze zur Messung von technischen Schulden und zum aktiven strategischen Management. Dabei kommen bewährte Ansätze aus dem Bereich Softwaremetriken und Architekturbewertung zum Einsatz. Wie immer ist der schwierigste Teil dabei die geeignete Interpretation der Ergebnisse und die Ableitung von Maßnahmen.
Agile Softwareentwicklung hat ihren Weg in sehr viele Entwicklungsorganisationen gefunden. Dass das Anwenden von Methoden wie SCRUM oder Kanban dabei nur die halbe Miete ist, hat sich mittlerweile herumgesprochen. Wie man agile Entwicklung aber um sinnvolle Engineering-Praktiken ergänzt ist weniger offensichtlich. Etliche Sessions haben sich auf dieses Thema fokussiert und Anregungen gegeben.
Eltjo Poort hat in „Agilizing the Architecture Department“ Anregungen gegeben, wie Architekten ihre Arbeit selbst mehr nach agilen Prinzipien gestalten können und wie sie ihre Architekturarbeit in den SCRUM-Prozess einbetten können.
Joseph Yoder (The Refactory) hat in Rückblick auf sein berühmtes Paper „Big Ball of Mud“ agile Prinzipien Revue passieren lassen und aufgezeigt, wie Entwickler mit viel Verantwortungsgefühl zu einer hohen Qualität beitragen können.
Mary Shaw (Carnegie Mellon University) gab eine Keynote „Progress Toward an Engineering Discipline of Software”. Darin verglich sie Software Engineering als Disziplin mit anderen Engineering-Disziplinen wie dem Bauingenieurswesen. Sie skizzierte die Historie der Gebäudearchitektur über mehrere Jahrtausende und analysierte ihre Entwicklung von Handwerk über die Kommerzialisierung bis hin zum heutigen Engineering auf Grundlage vielfältiger wissenschaftlicher Erkenntnisse.
„Es ist kein Engineering, wenn man sich einfach nur so arg anstrengt wie man kann!“ brachte Mary Shaw den Zustand vieler Software Engineering Projekte auf den Punkt. In ihrem Vergleich kam sie zum Schluss, dass die Zielsetzungen von sonstigem Engineering und Software Engineering nahezu Deckungsgleich sind. Woran es beim Software Engineering noch fehlt sind die fundierten Grundlagen zur Unterstützung von Entscheidungen, mit deren Hilfe reproduzierbare Ergebnisse geliefert werden können.
Gregor Hohpe gab eine Keynote „It’s good to be architect”. Darin verglich er einen Softwarearchitekten mit mehreren anderen Rollen: Master Planner (macht im Voraus einen guten Plan), Gärtner (greift lenkend ein und weiß, dass er nicht alles kontrollieren kann), Tour Guide (erklärt anderen die großen Zusammenhänge und manches Detail). Außerdem skizzierte er den „Architektenaufzug“, mit dem er die Fähigkeit eines Architekten beschrieb, sich auf unterschiedlichsten Abstraktionsebenen mit unterschiedlichsten Stakeholdern geeignet zu unterhalten.
Eine weitere Analogie war der Architekt als Barkeeper, der gerne mixt. Damit spielte Gregor auf die Rolle des Architekten an, in einem sich rasch wandelnden Feld aus Business und Technologie Gelegenheiten zu erkennen und Business und Technologie so zu „mixen“, dass neue Geschäftsmöglichkeiten entstehen.
Zusammen mit Ralf Carbon (John Deere) habe ich einen Vortrag gehalten, in dem wir unsere Erfahrungen zur Wichtigkeiten von Daten beim Design von mobilen Ökosystemen vorgestellt haben. Am Beispiel eines Projekts von John Deere und Fraunhofer IESE haben wir gezeigt, wie vielfältig die Anforderungen und geforderten Qualitätseigenschaften sich um Daten drehen, und welche Architekturentscheidungen dafür getroffen wurden. Der Vortrag zeigte auf, dass Daten beim Architekturdesign zu häufig vernachlässigt werden und erläutert Lessons Learned, die Praktikern helfen können, Daten geeignet zu berücksichtigen.
In einem Battledeck konnten 6 Sprecher einen Vortrag von 6 Minuten halten. Dazu hatten sie 10 Folien, die aber jemand anderes vorbereitet hatte und die sie im Moment des Vortrags zum ersten Mal gesehen haben.
Sam Newman und Simon Brown lieferten sich einen sehr provokanten Schlagabtausch zum Thema pro und contra von Microservices. Dabei ließen sie keine Gelegenheit aus, ihre Position ins Extreme zu ziehen und dem Gegner damit eine Steilvorlage zu liefern.
Len Bass berichtete von den Anfängen seines Berufslebens in den 60ern und war dabei wie immer extrem unterhaltsam und lustig.
Links
- Video zu unserem Vortrag
- Gregor Hohpes Blog-Beitrag zur SATURN.
- SEI’s SATURN Blog
- Folien zu den Vorträgen sind öffentlich beim SEI verfügbar.
- Alle Folien zum Sammeldownload
Neueste Kommentare