Software Architecture Alliance 2024

Software-Architektur ist real, sie bedeutet Praxis. Jedes System profitiert von – oder leidet unter ihr. Unsere Speaker geben hierzu spannende Einblicke.

Spark Streaming, Flink, Storm, Kafka Streams – das sind nur die populärsten Vertreter einer stetig wachsenden Auswahl zur Verarbeitung von Streaming-Daten in großen Mengen. In diesem Artikel soll es um die wesentlichen Konzepte hinter diesen Frameworks gehen und die drei Apache-Projekte Spark Streaming, Flink und Kafka Streams kurz eingeordnet werden. <h2>Warum Stream Processing?</h2>Die Verarbeitung von Streaming-Daten gewinnt durch die stetig wachsende Anzahl von Datenquellen, die durchgehend Daten produzieren und zur Verfügung stellen, zunehmend an Bedeutung. Neben dem omnipräsenten Internet of Things sind dies zum Beispiel Klickstreams, Daten im Werbegeschäft oder auch Geräte- und Serverlogs. Nun sind unendliche und kontinuierliche Daten kein neues Phänomen. Auch jetzt entsprechen schon viele Daten diesem Schema. Zum Beispiel treten auch Änderungen an Stammdaten kontinuierlich auf, allerdings nur in geringer Frequenz. Stammdaten werden nach dem klassischen Request/Response verarbeitet. Bei zeitunkritischen Änderungen oder größeren Volumen werden die Daten auch gerne gesammelt gespeichert und dann regelmäßig durch Batchprozesse verarbeitet. Diese laufen dann beispielsweise jede Nacht oder auch in kürzeren Intervallen. Tägliche Intervalle reichen aber häufig nicht mehr aus. Gefragt ist Geschwindigkeit: Analysen und Auswertungen werden zeitnah erwartet und nicht Minuten oder gar Stunden später. An dieser Stelle kommt das Stream Processing ins Spiel: Daten werden verarbeitet, sobald sie dem System bekannt sind. Begonnen hat dies mit der Lambda Architektur (vgl. [1]), bei der die Stream- und Batch-Verarbeitung parallel erfolgen, da die Stream-Verarbeitung keine konsistenten Ergebnisse garantieren konnte. Mit den heutigen Systemen ist es auch möglich, nur mit Streaming-Verarbeitung konsistente Ergebnisse nahezu in Echtzeit zu erreichen. (vgl. [2])<h2>Time Matters</h2>Ein wichtiger Aspekt beim Streaming ist die Zeit. Dabei kann im Wesentlichen zwischen drei Zeiten unterschieden werden:<ul><li>Eventzeit: Zeitpunkt, zu dem ein Event tatsächlich auftrat</li><li>Ingestionzeit: Zeitpunkt, zu dem das Event im System beobachtet wurde</li><li>Verarbeitungszeit: Zeitpunkt, zu dem das Event vom System verarbeitet wurde</li></ul><a href="https://media.graphassets.com/doUmMyq0RnMFLNkpcPA4"><img src="https://media.graphassets.com/doUmMyq0RnMFLNkpcPA4" alt width="875" height="252" /></a> Abb. 1: Exemplarische Darstellung von Eventzeit und Verarbeitungszeit. Mit verspäteten (Gelb, Grün, Rot) und Out-of-order Events (Blau)In der Praxis ist vor allem Eventzeit im Vergleich zur Ingestion- & Verarbeitungszeit interessant. Die Differenz zwischen der Eventzeit und der Verarbeitungszeit kann stark schwanken. Die Gründe dafür sind vielfältig: Netzwerk-Latenzen, verteilte Systeme, Hardware-Ausfälle oder auch eine unregelmäßige Datenanlieferung. Wenn nach der Verarbeitungszeit verarbeitet wird, ist dies nicht wichtig: Die Daten werden auf Basis der Systemzeit der Verarbeitung analysiert: Wenn ein Event um 12 Uhr eintrifft, ist es irrelevant, dass es bereits um 11 Uhr aufgetreten ist. Der normale Use Case ist dies aber nicht: Wenn ein Event um 11 Uhr auftritt, möchte ich es in der Regel auch zeitlich so betrachten. Die Frage hier ist dann: Wann weiß ich, dass ich alle Events bis 11 Uhr bekommen habe? Wie lange warte ich auf Events? Hier helfen Strategien wie Watermarks, Trigger und Akkumulatoren: <ul><li>Watermarks: Wann habe ich alle Daten zusammen?</li><li>Trigger: Wann soll ich die Berechnung auslösen? </li><li>Akkumulation: Wie füge ich einzelne Berechnungen zusammen, beispielsweise wenn nachträglich Daten folgen?</li></ul>Über diese drei Konzepte ließe sich problemlos ein eigener Artikel schreiben. Tyler Akidau, der Kopf hinter Streaming bei Google, hat dies bereits hervorragend zusammengefasst. Deshalb sei an dieser Stelle für Details sein Artikel empfohlen [3].<h2>State & Window</h2>Jede nicht triviale Anwendung wird eingehende Events miteinander korrelieren. Dafür ist ein Zustand nötig, in dem vorherige Events zwischengespeichert werden. Dieser State kann unendlich gespeichert werden oder explizit zeitlich begrenzt. Ein Beispiel für einen unendlichen gespeicherten State ist eine Lookup-Tabelle mit Metadaten. Ein zeitlich begrenzt State ist beispielsweise ein Window.Bei einem Window werden Daten für einen bestimmten Zeitraum zusammengefasst und analysiert. Dies ist in fast jeder Anwendung nötig, da der Datenstrom ja nie endet. Dabei gibt es verschiedene Typen von Windows:<ul><li>Tumbling Window: nicht überlappende, fixe Zeitabschnitte</li><li>Sliding Window: überlappende, fixe Zeitabschnitte</li><li>Session Window: nicht überlappende Zeitabschnitte unterschiedlicher Länge; definiert durch bestimmte Events oder durch Überschreiten einer bestimmten Zeit zwischen zwei Events</li></ul><img loading="lazy" src="https://media.graphassets.com/jMIWsYHTSdqB1gMIVRe5" alt width="760" height="237" />Abb. 2: Tumbling und Sliding Window bei einem Zeitfenster von vier Sekunden und ein Sliding Intervall von zwei Sekunden beim Sliding Window. Innerhalb eines jeden Fensters werden die Werte summiert. <img loading="lazy" src="https://media.graphassets.com/m2AyHaoQ7meYWoB9Mhqg" alt width="681" height="139" />Abb. 3: Sessionwindows bei einer Inaktivität von mindestens zwei Minuten zwischen zwei Events für einen Key.Für die Definition von Windows ist die Unterscheidung zwischen Event- und Verarbeitungszeit wichtig: Windows basierend auf Verarbeitungszeit sind sehr einfach zu realisieren, Windows basierend auf Eventzeit benötigen die oben genannten Strategien zur Eventzeit, um nicht unendlich zu wachsen. <h2>API & Laufzeitumgebung</h2>Erste Unterschiede bei den Frameworks lassen sich bei der API und dem generellen Verarbeitungsmodell feststellen. Unterscheiden lässt sich zwischen einem nativen Streaming-Ansatz und dem Microbatching. Beim nativen Streaming werden eingehende Daten direkt verarbeitet wohingegen beim Microbatching die eingehenden Daten zunächst für eine bestimmte Zeit (typischerweise 1 – 30s) gesammelt und anschließend zusammen verarbeitet werden. Der nächste Microbatch kann dann entweder direkt nach dem Abschluss des vorherigen Batches gestartet werden oder erst nach Verstreichen des fixen Intervalls. In beiden Fällen erhöht Microbatching die Latenz, dafür ist das Fehlerhandling etwas einfacher zu realisieren. Der früher häufig genannte Vorteil des sehr hohen Durchsatzes kann heute aber auch von nativen Streaming Frameworks erreicht werden. Zudem bieten diese mehr Flexibilität bei Windows und States.Sichtbar für den Entwickler ist vor allem die API. Auch hier kann zwischen zwei Varianten unterschieden werden: einer komponentenbasierten und einer deklarativen, high-level API. Bei ersterer wird der Fluss durch verschiedene Komponenten beschrieben (Quelle -> Verarbeitung 1 -> Verarbeitung 2 -> Senke), bei letzterer werden die Operationen auf Daten beschrieben ( map, filter, reduce), ähnlich wie bei Scala Collections oder Java 8 Streams. Die Beschreibung von Komponenten bietet mehr Flexibilität bei der Verteilung der Datenströme, während die deklarative API häufig bereits höherwertige Funktion bereitstellt und automatisch Optimierungen vornehmen kann. Zuletzt bleibt noch die Frage: Wo werden die Anwendungen ausgeführt? Auch hier kann man – Überraschung 🙂 – zwei grundsätzliche Alternativen unterscheiden. Einige Frameworks brauchen ein spezielles Cluster bestehend aus Master Nodes und Worker Nodes. Diese Cluster kümmern sich dann auch um das Ressourcenmanagement und Fehlerbehandlung, können dies aber auch auslagern an andere Tools (zum Beispiel YARN oder Mesos). Andere Frameworks kommen als einfache Bibliothek daher, die sich in die eigene Anwendung einbinden lässt. Das Ausführen und Skalieren der Anwendung muss dann von anderen Tools übernommen werden. Hier hat man die volle Flexibilität vom Ausführen eines Jar Files über Docker-Lösungen bis hin zu Mesos & Co.<h2>Verteilte Systeme sind unzuverlässig!</h2>Alle drei Frameworks sind spezialisiert auf die Verarbeitung großer Datenmenge und lösen dies durch horizontale Skalierung. Diese verteilten Systeme sind inhärent unzuverlässig: Einzelne Nodes können ausfallen, das Netzwerk ist inkonstant oder die Datenbank, in der die Ergebnisse geschrieben werden sollen, ist nicht erreichbar. Aus diesem Grund hat jedes Framework unterschiedliche Mechanismen, um bestimmte Garantien zu erreichen. Diese reichen vom Microbatching, bei dem kleine Batches wiederholt werden, über Acknowledges für einzelne Datensätze bis hin zu transaktionalen Updates auf Quelle und Senke. Die erreichten Garantien sind dann in der Regal At-Least-Once, also mindestens einmal verarbeitet, oder Exactly-Once, genau einmal verarbeitet. Da Exactly-Once häufig nur schwierig und mit großem Aufwand zu erreichen ist, sind At-Least-Once-Garantien mit idempotenten Operationen häufig ausreichend sowohl in Bezug auf Geschwindigkeit als auch auf Fehlertoleranz. <h2>Gibt’s da nichts von Apache?</h2>Zeithandling, State & Windows, eine Laufzeitumgebung und das alles in verteilten Systemen: Streaming-Anwendungen sind komplex. Es gibt eine Reihe von Projekten die bei diesen Problemen helfen sollen. Drei davon kurz vorgestellt:Apache Spark (Streaming) Apache Spark ist aktuell eines der populärsten der Projekte im Streaming-Bereich. Gestartet als besseres MapReduce folgte später auch eine Unterstützung für Streaming-Daten. Spark Streaming setzt dabei auf Microbatching mit einer deklarativen API. Aktuell wird dabei nur die Verarbeitungszeit vollständig unterstützt, mit der neuen Structured Streaming API wird seit der Version 2.0 allerdings auch die Unterstützung für Eventzeit-Verarbeitung sukzessive ausgebaut. Das gleiche gilt für die Unterstützung von Windows. Der State wird lokal in Memory oder auf Disk gehalten und per Checkpointing regelmäßig gesichert. Da Spark inzwischen mit jeder Hadoop Distribution ausgeliefert wird, ist die Verbreitung sehr hoch. Ebenso existiert ein großes Ökosystem mit vielen Tools und Konnektoren. Apache Flink Wenn es um Eventzeit-Verarbeitung geht, ist Apache Flink aktuell die erste Wahl. Unterstützt werden Watermarks und Trigger ebenso wie unterschiedliche Window-Operationen. Flink verfolgt dabei einen nativen Streaming-Ansatz und erreicht somit niedrige Latenzen. Ebenso wie bei Spark Streaming wird eine deklarative API genutzt, mit der Möglichkeit sogenannte Rich Functions zu nutzen, in denen beispielsweise ein State genutzt wird. Im Gegensatz zu Spark können verschiedene State-Implementierungen genutzt werden: In-Memory, Festplatte oder RocksDB. Flink ist etwas jünger als Spark, gewinnt aber zunehmend an Verbreitung. Ebenso wachsen die Community und das Ökosystem stetig, sind allerdings noch nicht so groß wie bei Spark. Apache Kafka Streams Das Streaming Framework aus dem Kafka-Ökosystem ist der jüngste Vertreter in dieser Übersicht. Es basiert auf vielen Konzepten, die bereits in Kafka enthalten sind, wie beispielsweise die Skalierung durch Partitionierung der Topics. Auch aus diesem Grund kommt es als leichtgewichtige Bibliothek daher, die in eine Anwendung eingebunden werden kann. Die Anwendung kann dann nach belieben betrieben werden: Standalone, in einem Applikationsserver, als Docker Container oder über einen Resourcen Manager wie Mesos. Flink & Spark hingegen benötigen immer ein Cluster, entweder ein mit den Boardmitteln der Frameworks gebautes oder aber YARN/Mesos. Kafka Streams ist allerdings beschränkt auf Kafka als Quelle und auch als Senke. Die Konnektivität zu anderen Systemen wird dann über Kafka Connect hergestellt. Ansonsten besitzt Kafka Streams neben einer deklarativen auch eine komponentenorientierte API, eine rudimentäre Unterstützung von Eventtime sowie RocksDB als State-Implementierung. Während Kafka selbst schon sehr reif ist und häufig auch in Verbindung mit Flink und Spark genutzt wird, ist die Streaming-Komponente noch recht jung. So ist auch die Community eher klein und die Verbreitung eher gering. Es ist aber zu erwarten, dass beides zeitnah wachsen wird.Update:Kafka Streams nutzt die Konzepte des Beam Models, um den Herausforderungen des Eventzeit Handlings zu begegnen. Streams wird entwickelt auf dem Konzept von <a href="http://docs.confluent.io/3.2.0/streams/concepts.html#duality-of-streams-and-tables">KTables und KStreams</a> , welches genutzt wird, um Eventzeit Verarbeitung zu unterstützen.<h2>Und was passt zu mir?</h2>Nun bleibt zum Schluss die Frage: Welches Framework passt zu mir? Wenn Eventzeit-Verarbeitung benötigt wird, führt aktuell fast kein Weg an Flink vorbei. Ein weiterer Pluspunkt ist die niedrige Latenz. Die wichtigsten Umsysteme (Kafka, Cassandra, Elasticsearch, SQL-Datenbanken) können relativ einfach integriert werden.Die niedrige Latenz und einen einfach zu nutzenden Eventzeit Support ermöglicht auch Kafka Streams. Wenn also Kafka bereits im Einsatz ist <s>und die Verarbeitung eher einfach ist, ohne komplexe Anforderungen an Eventzeit-Verarbeitung</s>, ist Kafka Streams eine gute Alternative. Dafür muss ich hier noch die Umsysteme über Kafka Connect anbinden und mich um die Laufzeitumgebung kümmern. Dies kann aber auch ein Vorteil sein, wenn ich vorhandene Tools, zum Beispiel aus dem Docker-Ökosystem, nutzen kann.Und Spark? Wenn Eventzeit nicht relevant ist und auch Latenzen im Sekundenbereich akzeptabel sind, ist Spark die erste Wahl. Es ist stabil und fast jedes beliebige Umsystem kann einfach eingebunden werden. Außerdem ist es bei Hadoop-Installationen schon vorhanden. Zudem kann der Code, der für Batch-Anwendungen genutzt wird, bei Bedarf auch für die Streaming-Anwendungen verwendet werden, da die API dieselbe ist. Lediglich bei sehr großen States im Terrabyte-Bereich kann es bei Spark zu Problemen kommen. Die Unterstützung für Eventzeit wird mit Spark 2.1 deutlich erweitert.<h2>Fazit</h2>Stream Processing Frameworks vereinfachen die Verarbeitung großer Datenmengen signifikant. Die vorgestellten Frameworks lösen dabei vor allem Probleme im Bereich der verteilten Verarbeitung wodurch einfach zu skalierende Lösungen entwickelt werden können. Ebenso wichtig sind die unterschiedlichen Aspekte der Zeitverarbeitung, die alle Frameworks unterstützen. Hier unterscheiden sich Systeme auch am deutlichsten von Bibliotheken wie Akka Streams, RxJava oder Vert.x. Die vorgestellten Frameworks sind vor allem im Big- und Fast-Data-Bereich angesiedelt, während mit den Bibliotheken auch einfach kleinere reaktive Anwendungen gebaut werden können – dann allerdings in der Regel ohne native Unterstützung für Eventzeit und Clustering.So bleibt festzuhalten, dass die vorgestellten Framework allesamt bei aktuellen Herausforderungen im Fast-Data-Bereich unterstützen können und dabei auch neue Architekturen jenseits der bekannten Lambda-Architektur unterstützen. Dabei ist die Komplexität dieser verteilten System allerdings keinesfalls zu unterschätzen. Dennoch ist davon auszugehen, dass die Verbreitung der Systeme ebenso wie die Funktionalität weiter zunehmen wird. Dieser Artikel erschien zuerst im <a href="https://www.codecentric.de/wissen/softwerker/">Softwerker</a> , dem kostenfreien Magazin der codecentric.<h2>Links</h2>[1] <a href="http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html" target="_blank">http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html</a> [2] <a href="https://www.oreilly.com/ideas/questioning-the-lambda-architecture" target="_blank">https://www.oreilly.com/ideas/questioning-the-lambda-architecture</a> [3] https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102

Verteilte Stream Processing Frameworks für Fast Data & Big Data – Ein Meer an Möglichkeiten

Mit dem neuen Release von Spark 2.1 wurden die Eventzeit-Fähigkeiten von Spark Structured Streaming ausgebaut. Höchste Zeit also den Stand der Unterstützung genauer unter die Lupe zu nehmen und mit Apache Flink – ausgestattet mit einem breiten Support für Event-Time-Verarbeitung – zu vergleichen. In diesem Artikel werde ich beschreiben, wie die drei grundsätzlichen Lösungskonzepte für Eventzeitverarbeitung – Watermarks, Trigger und Akkumulatoren – funktionieren und dann ihre Implementierung in Spark und Flink vergleichen. Basis des Vergleichs ist Spark in Version 2.1 und Flink in Version 1.2.Für einen weitergehenden Vergleich der Frameworks sei auf <a href="https://blog.codecentric.de/2017/03/verteilte-stream-processing-frameworks-fuer-fast-data-big-data-ein-meer-moeglichkeiten/">Verteilte Stream Processing Frameworks für Fast Data & Big Data – Ein Meer an Möglichkeiten</a>  verwiesen. Dort werden auch weitere Grundlagen beschrieben, die in diesem Artikel vorausgesetzt werden, beispielsweise zum Stafeful & Window Stream Processing sowie zum Unterschied zwischen Event und Verarbeitungszeit.Zentrales Problem der Eventzeitverarbeitung sind unsortierte sowie verspätete Events. Ereignisse werden nicht exakt zur der Zeit vom System beobachtet zu der sie auftreten. Die Differenz zwischen Eventzeit und Verarbeitungszeit ist dabei nicht konstant. Insbesondere bei zeitlichen Auswertungen erhöht dies die Komplexität des Systems und damit auch der Pogrammierung. Wenn beispielsweise alle Ereignisse zwischen 12 und 13 Uhr verarbeitet werden sollen (eine typische Window Operation), stellen sich mehrere Fragen: Wie soll mit verspäteten Events umgegangen werden? Wie lange soll auf verspätete Einträge gewartet werden? Wie soll das Resultat bei verspäteten Events aktualisiert werden? Google hat mit der Dataflow API, die nun in Apache Beam aufgegangen ist, verschiedene Lösungskonzepte für diese Probleme vorgestellt. Sowohl Spark und Flink implementieren nicht explizit die Dataflow API, allerdings sind die Konzepte ähnlich und können deshalb verglichen werden.Die Dataflow Konzepte sind ein Weg denen Problemen bei der Eventzeit Verarbeitung zu begegnen. Zum Beispiel nutzt Kafka Streams andere Strategien für den Eventzeit Support. Mehr dazu hoffentlich in einem folgenden Blogpost.<h2>Watermarks</h2>Um zu ermitteln, bis zu welcher Zeit Events bereits verarbeitet wurden, gibt es Watermarks. Diese zeigen – wie bei einem Wasserstand –  den bislang erreichten “Zeitpegel” an. Beim Erreichen eines Watermarks wird das Ergebnis der Berechnung dann materialisiert. Wenn beispielsweise der Watermark als der Zeitpunkt des neusten Events abzüglich eines fixen Puffers von 30 Sekunden definiert ist, bedeutet dies “Es wird angenommen, dass nun alle Events bis zum Zeitpunkt x angekommen sind. x ist in diesem Fall der Watermark definiert als Zeitpunkt(neuestes Event) – 30 Sekunden”Zudem gibt es noch heuristische Watermarks, bei denen der Puffer – zum Beispiel basierend auf empirischen Messungen – dynamisch angepasst wird. So könnte das System beobachten, dass Events nachts immer mit deutlicher Verzögerung empfangen werden. Der Puffer könnte auf dieser Grundlage erhöht werden. Ebenso könnte aus der Verzögerung der letzten Stunde die erwartete Verzögerung extrapoliert werden. Außerdem gibt es noch den – zumeist unrealistischen – perfekten Watermark, bei dem die Verarbeitung des Event direkt beim Auftreten des Events stattfindet.Häufig wird im Zusammenhang mit Watermarks auch die “allowed lateness “ genannt – auf Deutsch „die erlaubte Verspätung“. Bei Spark beispielsweise bezeichnet diese den oben beschriebenen Puffer bei den Watermarks. Im Dataflow Model hingegen ist die allowed lateness eine zusätzliche Zeitspanne nach dem Watermark, in der Events nicht ignoriert werden, sondern nachträglich das Ergebnis beeinflussen können. Dazu wird in der Regel über Trigger definiert, wie und wie oft Events verarbeitet werden sollen, die innerhalb der allowed lateness auftreten.Unabhängig von der Interpretation der allowed lateness müssen alle Daten für die Berechnung des Ergebnisses so lange gespeichert bleiben, bis die allowed lateness verstrichen ist, um die Ergebnisse aktualisieren zu können. Anschließend werden die Daten automatisch gelöscht.<h2>Trigger</h2>Während Watermarks den aktuellen Stand der eingegangen Daten anzeigen, lösen Trigger die Berechnung aus. Der Watermark Trigger ist dabei der Einfachste: Dieser wird ausgelöst, sobald der Watermark das Ende des Zeitfenster erreicht – zum Beispiel 13 Uhr bei einem Fenster von 12 bis 13 Uhr. Mit dem oben definierten Watermark mit einem fixen Puffer von 30 Sekunden wird dies um 13:00:30 der Fall sein.Weitere Trigger sind möglich:<ul><li>auf der Verarbeitungszeit, zum Beispiel alle 2 Minuten</li><li>auf der Eventanzahl, beispielsweise alle 100 Events</li><li>bei speziellen Events, zum Beispiel das Ende einer Datei, einem technischen Flush Event oder auch basierend auf dem Inhalt des Events.</li><li>Kombinationen aus den vorherigen dreien</li></ul>Trigger werden typischerweise genutzt, um bereits vor Erreichen des Watermarks Zwischenresultate zu ermitteln oder um die Ergebnisse bei verspäteten Events zu aktualisieren. Möglich wäre es zum Beispiel bei einem Fenster von 10 Minuten, jede Minute zu triggern, dann noch einmal beim Watermark und letztendlich bei jedem verspäteten Event bis die allowed lateness erreicht ist.<h2>Akkumulatoren</h2>Wenn nun das Ergebnis durch die Nutzung von Triggern mehrmals berechnet wird, muss der Entwickler definieren wie mit den einzelnen Teilergebnissen umgegangen wird. Dafür gibt es drei Varianten:<ul><li>Discarding: Bei jedem Trigger wird nur das neue Teilergebnis weitergegeben und die bis hierhin ermittelten Resultate werden anschließend gelöscht.</li><li>Accumulating: Bei jedem Trigger wird das aktuelle Ergebnisse aktualisiert und weitergeben. Das Teilergebnis wird nicht gelöscht.</li><li>Accumulating & Retracting: Wie Accumulating mit der zusätzlichen Information über das vorherige Ergebnis, sodass nachfolgende Operationen ihre Ergebnisse einfach korrigieren können. Dieser Modus ist zwar im DataFlow Model vorgesehen, wird bislang aber von keinem Framework implementiert.</li></ul>Die Wahl des passenden Akkumulators hängt stark von der nachfolgenden Verarbeitung und letztendlichen Senke ab. Wenn diese in der Lage ist Ergebnisse zu aktualisieren, kann der Accumulating Modus genutzt werden. Wenn allerdings jedes Teilergebnis nur einmal als Input für den nächsten Schritt dienen darf, muss der Discarding Mode verwendet werden.<h2>Unterstützung in Spark</h2>Spark benötigt  keinen speziellen Modus zur Eventzeitverarbeitung. Intern unterscheidet sich zunächst nichts von der Verarbeitungszeit. Um in Spark ein Fenster für die Eventzeit zu definieren, muss als Erstes nach dieser gruppiert werden:<div>

```scala
val words = ... // streaming DataFrame mit dem Schema { timestamp: Timestamp, word: String }
// Gruppieren nach Window und Word, berechnen der Anzahl für jede Gruppe
val windowedCounts = words.groupBy(
 window($"timestamp", "10 minutes", "5 minutes"),
 $"word"
).count()
```

</div>Dies unterscheidet sich nicht wesentlich von einem groupBy nach einem Schlüssel nur dass der Schlüssel ein Zeitfenster ist. In diesem Fall ist es ein Zeitfenster von 10 Minuten mit einem Sliding Intervall von 5 Minuten. Zusätzlich können die Einträge noch nach einem fachlichen Key gruppiert werden, in diesem Fall das „word“. Durch das anschließende Zählen erhält man einen WordCount für ein 10 Minuten Fenster.Im obigen Beispiel werden alle Daten unendlich lange gespeichert, damit auch bei verspäteten Events das Ergebnis noch aktualisiert werden kann. Mit Watermarks kann diese Zeit begrenzt werden:<div>

```scala
val windowedCounts = words
 .withWatermark("timestamp", "10 minutes")
 .groupBy(
 window($"timestamp", "10 minutes", "5 minutes"),
 $"word")
 .count()
```

</div>Nun wartet Spark nur 10 Minuten auf verspätete Daten. Anschließend werden die Daten für diese Fenster gelöscht. Aktuell kann nur ein Watermark mit einer fixen erlaubten Verspätung genutzt werden. Bei Spark ist der Watermark aktuell gleichbedeutend zur allowed lateness.Spark implementiert aktuell zwei verschiedene Modi zur Ausgabe des Ergebnisses:<ul><li>Beim Append Mode wird das Ergebnis des Fensters nach Erreichen des Watermarks, hier also 10 Minuten nach dem Ende des Zeitfensters, ausgegeben. Der Watermark fügt hier eine zusätzliche Latenz hinzu.</li><li>Beim Complete Mode wird das bislang errechnete Ergebnis bei jedem Trigger ausgegeben. Allerdings unterstützt Spark bislang nur Trigger auf Basis der Verarbeitungszeit. Zeitunabhängig oder gar zusammengesetzte Trigger werden aktuell noch nicht unterstützt.</li></ul>In Verbindung mit Watermarks kann zudem nur der Append Mode genutzt werden, da für den Complete Mode alle bisherigen Daten vorhanden sein müssen und dementsprechend nicht nach Erreichen des Watermarks gelöscht werden können.Spark bietet somit eine rudimentäre Unterstützung für Watermarks (nur fixe Verspätung) und Trigger (nur auf Verarbeitungszeit). Bei den Akkumulationen entsprechen die implementierten Output Modes von Spark am ehesten dem Accumulating Modus der Datastream API, da immer das komplette Ergebnis für ein Zeitfenster nach Ablauf der erlaubten Verzögerung ermittelt wird.<h2>Unterstützung in Flink</h2>Flink muss zunächst mitgeteilt werden, dass die Verarbeitung nun nach der Eventzeit erfolgen soll. Dies geschieht per<div>

```scala
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTIme);
```

</div>Abhängig von der Zeit-Charakteristik verhalten sich beispielsweise die verschiedenen Window Implementierungen unterschiedlich. Außerdem wird die Eventzeit der Stream Quelle berücksichtigt. Falls die Quelle keine Eventzeit bereitstellt, muss die Eventzeit manuell aus dem Event extrahiert werden mittels Timestamp Assignern. Ebenso muss der Watermark für diese Events festgelegt werden.<div>

```scala
stream.assignTimestampsAndWatermarks(new TimestampAndWatermarkAssigner());
```

</div>Der Entwickler kann den Assigner dabei vollständig selber implementieren oder vordefinierte Implementierungen erweitern. So sind insbesondere für die Watermarks unterschiedliche Implementierungen möglich:<ul><li>mit einem fixen Abstand</li><li>mit einem dynamischen, aber begrenzten Abstand</li><li>oder basierend auf bestimmten Events.</li></ul><div>

```scala
class FixedWatermarkGenerator extends AssignerWithPeriodicWatermarks[SomeEvent] {
 
 override def extractTimestamp(element: SomeEvent, previousElementTimestamp: Long): Long = {
 element.getEventTimestamp
 }
 
 override def getCurrentWatermark(): Watermark = {
 // the watermark is 10s behind the current time
 new Watermark(System.currentTimeMillis() - 10000)
 }
}
```

</div>Der Watermark wird genutzt, um den Zeitpunkt zu bestimmen, an dem die meisten Daten verarbeitet wurden. Zu diesem Zeitpunkt wird dann eine Berechnung durchgeführt. Im obigen Beispiel liegt der Watermark immer 10 Sekunden hinter der aktuellen Zeit. Zusätzlich zum Watermark kann noch eine allowed lateness angegeben werden. Diese bezeichnet die Zeit, die ein Event nach einem Watermark verspätet sein darf. Definiert wird die allowed lateness immer zusammen mit einer Window Operation.<div>

```scala
stream
 .assignTimestampsAndWatermarks(new TimestampAndWatermarkAssigner());
 .keyBy(event -> event.someKey)
 .window((SlidingEventTimeWindows.of(Time.minutes(15), Time.minutes(5)))
 .allowedLateness(Time.minutes(2))
 .apply()
```

</div>Der obige Auszug zeigt ein Sliding Window mit einer Länge von 15 Minuten, einem Slidingintervall von 5 Minuten und einer allowed lateness von 2 Minuten.Wenn es um die Berechnung eines Fensters geht, bietet Flink neben dem Watermark weitere Trigger. Diese Trigger können sowohl auf die Zeit (maßgebend ist die definierte Charakteristik, siehe oben), auf eine bestimmten Anzahl (zum Beispiel alle 100 Events) oder auch auf  eine Mischung aus beiden reagieren. Ebenso können auch dynamisch Trigger registriert werden, die in der Zukunft ausgeführt werden, beispielsweise eine bestimmte Zeit nach einem Event.Bleibt zuletzt noch die Frage nach den Akkumulatoren: Standardmäßig werden die vollständigen aktualisierten Daten an nachfolgende Operationen innerhalb der Streaming Anwendung weitergegeben. Stattdessen kann auch ein Fire and Purge Trigger genutzt werden, bei dem alle aktuellen Daten nach dem Trigger gelöscht werden und alle weiteren Trigger nur die neuen Daten weitergeben. Dies ist dann effektiv ein Discarding Akkumulator.Flink bietet somit mit den unterschiedlichen Watermarks und den flexiblen Triggern sowie Windows umfangreichen Support bei der Eventzeit Verarbeitung. Trotz der Flexibilität ist es ohne größeren Aufwand möglich Standardfälle zu implementieren.<h2>Zusammenfassung und Empfehlung</h2>Es ist offensichtlich, dass Flink schon deutlich länger an der Unterstützung für Eventzeit Verarbeitung arbeitet. So ist es auch zu erklären, dass deutlich mehr Konzepte bereits unterstützt werden. Flink arbeitet zudem kontinuierlich daran, die Dataflow Konzepte vollständig zu unterstützen, beispielsweise mit der <a href="https://issues.apache.org/jira/browse/FLINK-6047">Implementierung des Retracting Akkumulators</a> . Spark hingegen hat erst mit Structured Streaming begonnen die Eventzeitverarbeitung zu unterstützen. Bislang wurden vor allem die Grundlagen geschaffen und mit der Version 2.1 wurde erste Konzepte implementiert. Es ist zu erwarten, dass Spark im Laufe des Jahres die wesentlichen Funktionen implementieren wird. Wer aktuell allerdings Stream Processing mit Eventzeitverarbeitung benötigt, sollte mit Flink starten.

Event-Zeit-Verarbeitung in Apache Spark und Apache Flink

Machine Learning und künstliche Intelligenz sind aktuell in aller Munde und versprechen vielfältige Einsatzmöglichkeiten im Unternehmen. Trotzdem tun sich viele Unternehmen aktuell noch schwer, das Potential der Technologie zu nutzen. „Der Fokus liegt aktuell noch zu sehr auf der Qualität der Machine-Learning-Modelle“, sagt Matthias Niehoff, Head of Data & AI bei codecentric. In der neuen Folge Eine Mate mit berichtet er, was nötig ist, um Mehrwert mit Machine Learning zu schaffen, wie man auch als Mittelständler von den neuen Technologien profitieren kann und welche Entwicklungen in der Zukunft großes Potential haben.
<a href="https://www.youtube.com/watch?v=6pWnLolFxPU" target="_blank"><img src="https://media.graphassets.com/PNOkC16jS7eKOCh9aSJF" alt="YouTube" />
zum Video "Data Science & AI | Eine Mate mit Matthias Niehoff #EineMateMit"</a>
<div></div>
 

Eine Mate mit ist ein Format, in dem verschiedenste Menschen aus der IT-Branche aus ihren Projekten und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei der codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Die Gemeinsamkeit der Interviews: kurz, knackig, auf den Punkt.<h3>#Eine Mate mit – IT-Wissen kurz und erfrischend</h3>Eine Mate mit möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.Wir freuen uns auf eure Kommentare hier im Blog, auf Twitter unter #EineMateMit oder auf YouTube. Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen. Jeweils hier auf dem codecentric-Blog und auf YouTube. 

 <h3>Mehr zum Thema Data, Machine Learning & künstlicher Intelligenz</h3>Interesse am Thema Machine Learning? Dann seht euch doch mal unser <a href="https://www.codecentric.de/wissens-hub/webinare/webinar-data-science-projekte" target="_blank">Webinar</a> zum Thema an! Direkt jetzt abrufbar. Ihr habt Redebedarf? Dann bestellt euch einen „<a href="https://info.codecentric.de/data-lunch" target="_blank">Brown Paper Bag Lunch</a> “ Tech Talk ins Haus – oder auch remote.

Machine Learning in der Praxis. Eine Mate mit … Matthias Niehoff #EineMateMit

Bei der Verarbeitung von Streaming-Daten reichen die Rohdaten aus den Events häufig nicht aus. Meist müssen noch zusätzliche Daten hinzugezogen werden, beispielsweise Metadaten zu einem Sensor, von dem im Event nur die ID mitgeschickt wird.In diesem Blogpost möchte ich auf verschiedene Möglichkeiten eingehen, dieses Problem in Spark Streaming zu lösen. Ich gehe in meinen Beispielen davon aus, dass die zusätzlichen Daten zunächst einmal außerhalb der Streaming-Anwendung liegen und über das Netzwerk – zum Beispiel in einer Datenbank – gelesen werden können. Alle Beispiele und Techniken beziehen sich auf Spark Streaming und nicht auf Spark Structured Streaming. Die wesentlichen Techniken sind<ul><li>Broadcast: für statische Daten</li><li>MapPartitions: für volatile Daten</li><li>MapPartitions + Connection Broadcast: effektives Connectionhandling</li><li>MapWithState: Geschwindigkeit durch einen lokalen State</li></ul><h2>Broadcast</h2>Spark besitzt einen integrierten Broadcast-Mechanismus, mit dem beim Start der Anwendung Daten auf alle Worker Nodes übertragen werden können. Dies hat insbesondere bei großen Datenmengen den Vorteil, dass die Übertragung nur einmal pro Worker Node erfolgt und nicht bei jedem Task.Da die Daten allerdings im weiteren Verlauf nicht aktualisiert werden können, ist dies nur eine Option wenn die Metadaten statisch sind. Das heißt, es dürfen keine zusätzlichen Daten, zum Beispiel Informationen über neue Sensoren, hinzukommen, und es dürfen auch keine Daten verändert werden. Zudem muss das übertragene Objekt serialisierbar sein.In diesem Beispiel soll jeder Sensor-Typ, gespeichert als numerische ID (1,2,…) im Stream Processing durch einen Klartextnamen ersetzt werden (Reifentemperatur, Reifendruck,..). Es wird davon ausgegangen, dass die Zuordnung Typ ID -> Name fix ist. <div>

```scala
val namesForId: Map[Long,String] = Map(1 -> "Wheel-Temperature", 2 -> "Wheel-Pressure")
stream.map (typId => (typId,namesForId(typId)))
```

</div><h6>Ein Lookup ohne Broadcast. Die Map wird für jeden Task serialisiert und auf die Worker Nodes übertragen, auch wenn vorher schon Tasks auf dem Worker ausgeführt wurden.</h6><div>

```scala
val namesForId: Map[Long,String] = Map(1 -> "Wheel-Temperature", 2 -> "Wheel-Pressure")
val namesForIdBroadcast = sc.broadcast(namesForId)
stream.map (typId => (typId,namesForIdBroadcast.value(typId)))
```

</div><h6>Die Map wird über einen Broadcast auf die Worker verteilt und muss anschließend nicht mehr für jeden Task übertragen werden.</h6><h2>MapPartitions</h2>Die erste Möglichkeit nicht statische Daten zu lesen, ist in einer map() Operation. Dabei sollte allerdings nicht map(), sondern mapPartitions() aufgerufen werden. Diese wird nicht für jedes einzelne Element aufgerufen, sondern für jede Partition, die dann mehrere Elemente enthält. Dies ermöglicht es, die Verbindung zur Datenbank nur einmal pro Partition aufzubauen und dann für alle Elemente wieder zu verwenden. Für die Abfrage der Daten gibt es zwei verschiedene Möglichkeiten: Die Nutzung einer Bulk API, um alle Elemente der Partition gemeinsam zu verarbeiten, oder eine asynchrone Variante. Dabei wird für jeden Eintrag eine asynchrone, nicht blockierende Query abgesetzt und die Ergebnisse im Anschluss eingesammelt.<div>

```scala
wikiChanges.mapPartitions(elements => {
 Session session = // create database connection and session
 PreparedStatement preparedStatement = // prepare statement, if supported by database
 elements.map(element => {
 // extract key from element and bind to prepared statement
 BoundStatement boundStatement = preparedStatement.bind(???)
 session.asyncQuery(boundStatement) // returns a Future
 })
 .map(...) //retrieve value from future
})
```

</div><h6>Ein Beispiel für den Lookup von Daten, gespeichert in Cassandra, mit mapPartitions und asynchronen Abfragen</h6>Das obige Beispiel zeigt schematisch einen Lookup mittels mapPartitions: Teure Operationen wie das Herstellen der Verbindung erfolgen nur einmal pro Partition. Für jedes Element wird eine asynchrone, nicht blockierende Query abgesetzt und anschließend die Werte aus den Futures ermittelt. Einige Bibliotheken zum Lesen aus Datenbanken nutzen im Wesentlichen dieses Muster, so beispielsweise das<a href="https://github.com/datastax/spark-cassandra-connector/blob/master/doc/2_loading.md#using-joinwithcassandratable" target="_blank"> joinWithCassandraTable aus dem Spark Cassandra Connector</a> .Warum wird die Connection nicht einmal zu Beginn des Jobs erstellt und dann für jede Partition genutzt? Dafür müsste die Connection serialisiert werden, um dann für jeden Task an die Worker übertragen zu werden. Die Datenmenge dabei wäre in der Tat nicht zu groß, allerdings sind die meisten Connection-Objekte nicht serialisierbar. <h2>Broadcast Connection + MapPartitions</h2>Trotzdem ist es eine gute Idee, die Connection nicht für jede Partition neu aufzubauen, sondern nur einmal pro Worker. Um dies zu erreichen, wird nicht die Connection gebroadcastet, da diese nicht serialisierbar ist (siehe oben), sondern eine Factory, die beim ersten Aufruf die Connection aufbaut und bei allen weiteren aufrufen diese Connection dann zurück gibt. Diese Funktion wird dann in mapPartitions() aufgerufen, um die Verbindung zur Datenbank zu erhalten.In Scala ist es nicht nötig, dafür eine Funktion zu verwenden. Hier kann ein lazy val genutzt werden. Der lazy val wird innerhalb einer Wrapper-Klasse definiert. Diese Klasse ist serialisierbar und kann somit gebroadcastet werden. Auf den Worker Nodes wird dann beim ersten Aufruf eine Instanz der nicht serialisierbaren Connection-Klasse erzeugt.<div>

```scala
class DatabaseConnection extends Serializable {
 lazy val connection: AConnection = {
 // all the stuff to create the connection
 new AConnection(???)
 }
}
val connectionBroadcast = sc.broadcast(new DatabaseConnection)
incomingStream.mapPartitions(elements => {
 val connection = connectionBroadcast.value.connection
 // see above
})
```

</div><h2>mapWithState()</h2>Alle bislang gezeigten Lösungsansätze holen die Daten bei Bedarf aus einer Datenbank. Dies bedeutet in der Regel einen Zugriff über ein Netzwerk für jeden Eintrag oder zumindest für jede Partition. Effizienter wäre es, die Daten direkt in-memory verfügbar zu haben.<a href="https://media.graphassets.com/Lxtm7ADtS2OEXqTmEvEj"><img src="https://media.graphassets.com/Lxtm7ADtS2OEXqTmEvEj" alt="Stateful stream procssing within an operation" width="277" height="211" /></a> Spark selbst bietet mit mapWithState() eine Möglichkeit, Daten mittels einen States zu verändern und im Gegenzug ebenfalls den State anzupassen. Der State wird dabei anhand eines Schlüssels verwaltet. Mittels dieses Schlüssels werden die Daten im Cluster verteilt, sodass nicht auf jedem Worker Node alle Daten vorgehalten werden müssen. Ein eingehender Stream muss dementsprechend auch als Schlüssel-Wert-Paar aufgebaut sein.Dieser keyed-State kann auch für einen Lookup genutzt werden. Mittels initialState() kann ein RDD als initialer Zustand übergeben werden. Jegliche Updates können dann allerdings nur noch basierend auf einem Schlüssel durchgeführt werden. Dies gilt ebenso für das Löschen von Einträgen. Es ist nicht möglich, den State komplett zu löschen oder neu zu laden.Um den State zu aktualisieren, müssen zusätzliche Notification Events im Stream vorhanden sein. Diese können beispielsweise aus einem separaten Kafka Topic kommen und mit dem eigentlichen Datenstream zusammengeführt werden (union()). Die gesendete Datenmenge kann dabei von einer einfachen Benachrichtigung mit einer ID, die dann für das Lesen der neuen Daten genutzt wird, bis hin zu dem kompletten neuen Datensatz reichen. Geschrieben wird in das Kafka Topic zum Beispiel wenn Metadaten aktualisiert oder neu angelegt werden. Außerdem können zeitgesteuert Events in das Kafka Topic eingestellt werden oder aber durch einen Custom Receiver in Spark selber erzeugt werden.<a href="https://media.graphassets.com/ickxYXvSeaDhMOnAr61N"><img loading="lazy" src="https://media.graphassets.com/ickxYXvSeaDhMOnAr61N" alt="Data Lookup in Spark Streaming using mapWithState" width="644" height="358" /></a> Eine einfache Implementierung kann so aussehen. Zunächst werden hier die Streams von Kafka gelesen und die Schlüssel zusätzlich mit einer Markierung des Datentyps ergänzt (data oder notification). Anschließend werden beide Streams zu einem gemeinsamen Stream vereint und in mapWithState() verarbeitet. Der State wurde zuvor spezifiziert indem die Funktion des States angegeben wurde.<div>

```scala
val kafkaParams = Map("metadata.broker.list" -> brokers)
val notifications = notificationsFromKafka
 .map(entry => ((entry._1, "notification"), entry._2))
val data = dataFromKafka
 .map(entry => ((entry._1, "data"), entry._2))
val lookupState = StateSpec.function(lookupWithState _)
notifications
 .union(data)
 .mapWithState(lookupState)
```

</div>Die lookupWithState Funktion beschreibt die Verarbeitung im State. Folgende Parameter werden dabei übergeben:<ul><li>batchTime: die Startzeit des aktuellen Microbatches</li><li>key: der Schlüssel, in diesem Fall der Originalschlüssel aus dem Stream, zusammen mit der Typmarkierung (data oder notification)</li><li>valueOpt: der Wert zum Schlüssel im Stream</li><li>state: der Wert, der im State zum Schlüssel gespeichert ist</li></ul>Zurückgegeben wird ein Tupel bestehend aus dem Originalschlüssel und dem Originalwert sowie einer zufälligen Zahl, die aus dem State entnommen wird oder – falls noch nicht im State vorhanden – zufällig gewählt wird. <div>

```scala
def lookupWithState(batchTime: Time, key: (String, String), valueOpt: Option[String], state: State[Long]): Option[((String, String), Long)] = {
 key match {
 case (originalKey, "notification") =>
 // retrieve new value from notification or external system
 val newValue = Random.nextLong()
 state.update(newValue)
 None // no downstream processing for notifications
 case (originalKey, "data") =>
 valueOpt.map(value => {
 val stateVal = state.getOption() match {
 // check if there is a state for the key
 case Some(stateValue) => stateValue
 case None =>
 val newValue = Random.nextLong()
 state.update(newValue)
 newValue
 }
 ((originalKey, value), stateVal)
 })
 }
}
```

</div>Zudem kann auch noch der timeout-Mechanismus des mapWithState() genutzt werden, um Events nach einer bestimmten Zeit ohne Aktualisierung aus dem State zu entfernen.<h2>Fazit</h2>Das Laden zusätzlicher Informationen ist ein häufiges Problem in Streaming-Anwendungen. Mit Spark Streaming gibt es eine Reihe von Möglichkeiten, dies zu bewerkstelligen. Am einfachsten ist der Broadcast statischer Daten beim Start der Anwendung. Für volatile Daten ist das Lesen per Partition einfach zu implementieren und bietet bereits eine solide Performance. Bei der Benutzung der Spark States kann die Geschwindigkeit noch gesteigert werden, allerdings ist es insgesamt aufwendiger zu entwickeln.Optimalerweise liegen die Daten immer aktuell direkt auf dem Worker Node vor, auf dem die Daten verarbeitet werden. Dies ist beispielsweise bei der Benutzung des Spark States der Fall. Kafka Streams verfolgt diesen Ansatz noch konsequenter. Hier wird eine Tabelle als Stream behandelt und – vorausgesetzt die Streams sind identisch partitioniert – genauso im Cluster verteilt wie der originale Stream. So sind lokale Lookups möglich.Auch bei Apache Flink wird an effizienten Lookups gearbeitet, hier unter dem Titel <a href="https://cwiki.apache.org/confluence/display/FLINK/FLIP-17%3A+Side+Inputs+for+DataStream+API" target="_blank">Side Inputs</a> .

Datenlookup in Spark Streaming

“Data is the new oil” ist inzwischen ein alter Hut. Jedes Unternehmen versucht, Daten besser zu nutzen, sei es, um die eigenen Prozesse zu optimieren, die Kunden besser zu verstehen oder neue Produkte anzubieten. Dabei stellen fast alle fest: Wir haben viele Daten, wissen aber kaum, wo sie zu finden sind. Insbesondere zwischen den produzierenden und den nutzenden Teams fehlt es an Transparenz. Das hat organisatorische Gründe, erfordert aber auch technologische Lösungen.

Die sozio-technische Idee des Data Mesh hat in den letzten Monaten stark an Popularität gewonnen. Auch hier ist das Ziel der einfache, teamübergreifende Austausch und somit die wertigere Nutzung von Daten im Unternehmen. Das Data Mesh sieht deshalb explizit die “Federated Data Governance” vor. Ziel ist es, die Daten im Unternehmen möglichst nahtlos verwenden und kombinieren zu können. Erreicht werden soll das mit einer Standardisierung – ohne dabei aber die Agilität beim Nutzen und Bereitstellen aus zu bremsen - eine Gratwanderung für Unternehmen auf verschiedenen Ebenen.

Neben organisatorischen Regelungen stehen hier auch Technologien im Fokus. Experten nennen vor allem Datenkataloge, die die Daten katalogisieren, auffindbar machen und zusätzliche Metainformationen anbieten – zum Beispiel zu Ansprechpartner, Qualität oder Abstammung von anderen Daten. Einige Lösungen ermöglichen auch die Abbildung vom Berechtigungsprozess – inklusive des Konzepts eines Datenwarenkorbs, der dann von den Verantwortlichen freigegeben wird. Anschließend geht es ohne Umwege in das Analyse-Tool der Wahl. Zur Auswahl gibt es eine Reihe an Open-Source-Lösungen (z. B. Apache Atlas oder Datahub) und natürlich auch Kaufsoftware. Aber auch in diese Systeme müssen die Informationen erst einmal eingepflegt werden. Bei den Integrationsmöglichkeiten dieser Systeme ist die Entwicklung noch lange nicht abgeschlossen.

Aus technologischer Sicht gibt es also eine Reihe von Werkzeugen, die die Demokratisierung von Daten unterstützen. Wie bei einer agilen oder digitalen Transformation muss die nötige Veränderung zu einem datengetriebenen Unternehmen aber auch in den Köpfen stattfinden.

*Dieser Artikel erschien am 21.10.2022 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr [den Newsletter hier abonnieren](https://blog.codecentric.de/#newsletter-anchor).*

Data Governance: Wie können wir Daten demokratisieren?

Plattformen sind aktuell ein sehr populäres Konzept, insbesondere in der Softwareentwicklung von Unternehmen. Viele sagen aber auch: So neu ist das doch gar nicht. Wir bieten unseren Entwicklern seit Jahren alle relevanten Tools und Werkzeuge, damit sie sich auf das Wesentliche konzentrieren können: Mehrwerte für Kunden schaffen.

Ist Plattform Engineering also alter Wein in neuen Schläuchen? Ein klares Jein.

Auch klassische IT-Service-Plattformen in Unternehmen versuchen, die nicht differenzierenden, aber notwendigen Arbeiten zu vereinfachen. Bereitgestellt werden CI/CD-Pipelines, Datenbanken, Container-Orchestratoren und Ähnliches. Jedes Team kann sich dann die benötigten Services wie in einem Katalog aussuchen und bekommt sie dann (irgendwann) zur Verfügung gestellt.

Eine interne Entwicklerplattform geht weiter: Verglichen mit den oben beschriebenen IT-Services steht ein Self-Service-Gedanke im Vordergrund und eine einfache, unkomplizierte Nutzung – also kein Ticketsystem mit tagelanger Wartezeit.

Zentral ist auch das Betrachten der Plattform als ein Produkt: Das Angebot richtet sich nach den Bedürfnissen der Nutzer, abgeleitet aus der bisherigen Nutzung und dem Feedback. Sie hilft dem Nutzer das Rad nicht neu zu erfinden, sie nimmt ihm Entscheidungen ab und reduziert so die kognitive Beanspruchung. Und auch wenn viele Nutzer die Plattform nutzen wollen, wird sie nicht zum Bottleneck.
Außerdem ist die Plattform nicht nur eine lose Sammlung von Werkzeugen, sondern ein Mix aus Methoden, Prozessen, Tools und Wissen, der benötigt wird, um schnelle Use Cases umsetzen zu können. Inklusive eines Golden Path, ein klar definierter, schneller, einfacher Weg, bis hin zur produktiven Software – ohne notwendige Compliance-Anforderungen außer Acht zu lassen.

Ein Angebot, das Entwicklungsteam aktiv nachfragen und nicht eines, zu dem sie gezwungen werden. Ein Angebot, das auf die Bedürfnisse der Teams und des Unternehmens zugeschnitten ist und so nicht einfach bei einem der Public-Cloud-Provider verfügbar ist – aber trotzdem auf diesen aufbaut, mit Unterstützung durch Frameworks (z. B. Backstage) und Tools (z. B. Humanitec).

Plattformen bauen schon viele. Aber interne Entwicklerplattformen, als Produkt, mit Fokus auf die Nutzer, mit Golden Path und Self-Service: Das ist immer noch selten.

*Dieser Artikel erschien am 21.10.2022 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr [den Newsletter hier abonnieren](https://blog.codecentric.de/#newsletter-anchor).*




 Platform Engineering – Machen das nicht alle schon?

Infrastructure as Code (IaC) ist inzwischen ein alter Hut. Frameworks wie Terraform, Ansible und andere haben Standards geschaffen. Kaum jemand provisioniert produktive Systeme heute ohne IaC – sei es in der Cloud oder auf der eigenen Infrastruktur.\nUnd doch ist die Technologie für viele Entwickler oft noch eine Hürde beim Benutzen. Einer der Gründe: Die meisten Tools verwenden eine eigene, deklarative Domain-specific language (DSL), häufig auf Basis von JSON oder YAML oder sogar eine eigene Sprache wie HCL bei Terraform. Schöner ist es doch, die gleiche Sprache zu verwenden, in der auch die eigentliche Software entwickelt wird: TypeScript, Python oder Java.\nDas Cloud Development Kit (CDK) von AWS ermöglicht genau das: Mittels einer verbreiteten Programmiersprache wird die für das Projekt notwendige Infrastruktur beschrieben. Dabei können wir auch die Vorteile einer modernen Sprache nutzen. So ist ein Parameter nicht einfach nur eine Zeichenkette in einer DSL, sondern zum Beispiel ein Wert eines Enum. IDE-Support gibt’s ohne Zusatzaufwand und auch Tools wie Test-Frameworks können einfach verwendet werden.\nEs hat sich zusätzlich ein reichhaltiges Ökosystem gebildet. Unter \nhttps://constructs.dev/\n finden sich eine Vielzahl von Paketen für verschiedene Service-Provider. Mit CDK kann ich dabei auf verschiedenen Granularitäten arbeiten. Von Low-Level Cloud Formation (in das CDK Code bei AWS übersetzt wird) bis hin zu TypeScript-Skripte mit wenigen Zeilen in ein AWS Lambda mit API umwandeln. Und die CDK CLI nimmt mir dabei auch noch Packaging und Deployment ab.\nViele der bereitgestellten Constructs sind natürlich für AWS. Aber mit CDK TF gibt es auch eine Bibliothek, die CDK Code in die Terraform DSL übersetzt und so die Anbindung von Lösungen mit Terraform-Providern ermöglicht. Außerdem gibt es CDK8s mit dem Ziel, CDK für Kubernetes bereitzustellen.\nWeitere spannende Werkzeuge aus dem CDK-Kontext: \nProjen\n mit dem Ziel, nicht nur Infrastruktur, sondern das ganze Entwicklungsprojekt und den Workspace als Code zu beschreiben. \njsii\n ermöglicht CDK in vielen Sprachen zu nutzen – obwohl es intern nur in Typescript geschrieben ist. \nEs ist nicht so, dass für jegliches Provisionieren CDK genutzt werden sollte. Auch mit Terraform lassen sich zum Beispiel Konstrukte wiederverwenden oder parametrisieren. In CDK sind diese Möglichkeiten aber besser in das Framework integriert. \nEin Kritikpunkt, der mehrmals genannt wurde: Entwickler bekommen mit CDK zu viele Freiheitsgrade, was die Wartung des Infrastruktur-Codes massiv verschlechtert. Insbesondere, wenn ein Softwareprodukt vom Entwicklerteam zu einem Betriebs- oder Wartungsteam übergeht, sind klare Grenzen in der Flexibilität durchaus von Vorteil. Wenn auf der anderen Seite ein Entwicklerteam während des gesamten Softwarelebenszyklus für ein Produkt verantwortlich bleibt, sind diese Aspekte ggfs. weniger wichtig. \nZuletzt sei auch noch auf Pulumi hingewiesen, ebenfalls ein IaC-Werkzeug mit ähnlichen Konzepten wie CDK: deklarativ, beschreibt den Zielzustand und nicht den Weg dorthin, Modularisierung und Higher-Level-Abstraktionen. Pulumi ist dabei allerdings nicht auf AWS festgelegt, sondern unterstützt viele weitere Cloud- und SaaS Anbieter. Beim Interpretieren des Code interagiert Pulumi direkt mit den APIs der Cloudanbieter. Bei CDK dient hingegen die AWS CloudFormation als Zwischenschicht. Sowohl Pulumi als auch CDK sind aber eine Weiterentwicklung beim Thema Infrastructure as Code, die eine große Verbreitung finden wird.\nEine Orientierung bei der Auswahl der passenden IaC geben \ndie Kollegen in ihrem Blogbeitrag\n.

AWS Cloud Development Kit – Infrastructure as Code on Steroids

Seit 2017 unterstützen moderne Browser bereits WebAssembly (Wasm), seitdem ist der Hype mal größer, mal kleiner. Aber was ist WebAssembly überhaupt und warum wurde es geschaffen?

WebAssembly ist ein standardisierter Bytecode, der in einer leichtgewichtigen virtuellen Maschine ausgeführt wird, zum Beispiel im Browser. Wer da jetzt direkt an Java, die JVM oder gar Java Applets denkt, ist auf den ersten Blick nicht so falsch unterwegs. Allerdings ist Wasm deutlich leichtgewichtiger, ohne lange Ladezeiten und in einer sicheren Sandbox. Der initiale Fokus auf den Browser legt nahe, dass es ein Ersatz für JavaScript sein soll. Es ist aber vielmehr eine Ergänzung.

Unterstützt wird Wasm vor allem durch die Sprachen C/C++, Rust und Go. Diese Sprachen können direkt in Wasm-Bytecode übersetzt werden. Für andere Sprachen wurde die Runtime nach Wasm übersetzt und sie können so den eigentlichen Code ausführen, z. B. C# oder Python (noch nicht stabil).

2019 wurde mit WASI (WebAssembly System Interface) ein Standard für eine Stand-Alone-Laufzeitumgebung vorgeschlagen, die eine Nutzung auch außerhalb des Browsers erlaubt. Auch die GraalVM unterstützt inzwischen WASI/Wasm. Einige versprechen sich von WASI aufgrund der Portabilität und Geschwindigkeit auch die nächste Stufe bei der Entwicklung von Software für die Cloud.

Als Antwort auf die Ankündigung von WASI twitterte Solomon Hykes, einer der Miterfinder von Docker, dass Docker wohl nicht entstanden wäre, wenn es Wasm bereits gegeben hätte. Im Vergleich zu Docker sieht man allerdings die Schwächen des neuen Standards deutlich: Tooling und User/Developer Experience sind stark ausbaufähig. Auch die Berichte der Early Adopters (unter anderem für die Mediaplayer der BBC und Disney oder auch Google Earth und Figma) sprechen neben den Erfolgen (Geschwindigkeit, Portabilität) immer auch von eigenen Systemen oder Hacks, die hinzu gebaut werden mussten. Mit Wasm ist Stand jetzt auch kein Zugriff auf das DOM einer Webseite möglich. Das muss weiterhin über JavaScript geschehen und diese Kommunikation ist noch hakelig.

Insgesamt ist die Kommunikation rund um WebAssembly sehr von Technik geprägt. Es geht schnell in spannende und herausfordernde Details, es fehlt aber oft der – für die weite Verbreitung notwendige – Überblick über Technologie sowie konkrete Einsatzmöglichkeiten.

Szenarien für den Einsatz gibt es durchaus: Neben den bereits erwähnten Mediaplayern ist das zum Beispiel die Portierung von großen Desktopanwendungen in den Browser, bei der die Logik im Browser ausgeführt wird und um ein modernes Frontend ergänzt wird. Außerdem gibt es Anwendungsfelder im Bereich Gaming, AR/VR sowie Audio- und Videobearbeitung. Im Vergleich zu JavaScript, wo der komplette Code zunächst heruntergeladen und interpretiert werden muss, verspricht Wasm hier durch die bereits erfolgte Kompilierung und Optimierung eine zuverlässige, hohe Performance.

Wasm will mehr als ein Webstandard sein und in Zukunft auch die Cloud ins Visier nehmen. Aus technischer Sicht bringt es dafür bereits vieles mit, aber die Reife des Projekts und des Ökosystems verhindern – aktuell – eine größere Verbreitung jenseits der großen Webanwendungen.

*Dieser Artikel erschien am 02.122022 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr [den Newsletter hier abonnieren](https://blog.codecentric.de/#newsletter-anchor).*


WebAssembly – Mehr als nur ein Web-Standard 

Rechenleistung und Speicher kosten nicht nur Geld. Sie verbrauchen auch Mengen – potenziell klimaschädlicher – Energie. Das überrascht die Wenigsten, im kollektiven Bewusstsein ist es aber bislang kaum angekommen.

Sehr wohl bewusst ist es natürlich den Public-Cloud-Anbietern selbst. Für sie ist das Thema „Green Cloud“ irgend etwas zwischen bewusstem Fokus auf Nachhaltigkeit, Kosteneffizienz und Marketing. Folglich haben alle großen Anbieter ihre Strategien zum Umgang mit Emissionen, Treibhausgasen und Nachhaltigkeit.

Unterscheiden kann man dabei zwischen den Fragen „Was macht der Anbieter selber?“ und „Was bietet er seinen Nutzern?“. Ein Beispiel: Natürlich ist es super, wenn der Anbieter seine Emissionen um 70 % reduziert. Wenn ich als Unternehmen dann aber Server in der Cloud nur zu 20 % auslaste, habe ich einen ebenso großen Hebel zur Verbesserung. AWS nennt dies explizit „Shared Responsibility“ und beschreibt es als „AWS ist verantwortlich für die Nachhaltigkeit der Cloud“ und „Der Kunde ist verantwortlich für die Nachhaltigkeit in der Cloud“.

Die Anbieter versprechen, in absehbarer Zeit (2025-2030) ausschließlich erneuerbare Energien zu nutzen. Ebenso wird an den Rechenzentren gearbeitet, um beispielsweise eine effizientere Stromnutzung oder eine Weiternutzung der Abwärme zu gewährleisten. AWS hat auf der re:Invent im November gar angekündigt, ab 2030 „Water-positive“ sein zu wollen, also mehr Wasser zurückzugeben als selbst genutzt wird.

Für die Nutzer werden vor allem Dashboards angeboten. Hier kann man sehen, welche Emissionen angefallen sind, grob strukturiert nach geografischen Regionen und genutzten Services. Auch ein Vergleich mit einem „üblichen“ On-Premises Datacenter darf nicht fehlen – schließlich muss der positive Nutzen der Cloud auch hier gezeigt werden. Diese Daten sind immer retrospektiv. Teils gibt es sogar bis zu drei Monate Verzug – eine Tatsache, die zeigt, dass hier bislang nicht so viel investiert wird. Positiv zu erwähnen ist Google, immerhin mit einem „Lowest CO2“-Zeichen bei der Auswahl der Region – und damit bevor die erste Cloud-Ressource erstellt wird.

Sinnvoll wäre es, wenn Nachhaltigkeit bereits beim Entwurf der Lösung in der Cloud eine größere Rolle spielte. Genau so, wie bereits jetzt ganz selbstverständlich Performance und Kosten betrachtet werden (und im späteren Verlauf gerne durch Experteneinsätze weiter optimiert werden). Zumal diese Themen oft Hand in Hand gehen. Hier helfen Blue Prints und Best Practices, effiziente Architekturen und Lösungen, auch unter Berücksichtigung der Umwelt. AWS hat hier mit dem Sustainability Pillar in seinem Well-Architected Framework eine Vorreiterrolle eingenommen.

Unternehmen stehen beim Klimaschutz in der Verantwortung. Die Erwartung ist, dass die Anbieter auf ihrer Seite noch mehr machen, aber ebenso die Kunden in die Lage versetzen, selbst mit wenig Aufwand aktiv zu werden, um so ihre Emissionen zu verwalten und zu reduzieren. Die Cloud-Anbieter arbeiten also daran, aber damit die Cloud wirklich kein Umweltsünder bleibt, müssen Unternehmen das Thema aktiv vorantreiben.

PS: Wenn ihr lernen wollt, wie ihr bei den großen Anbietern eure Emissionen messen könnt, solltet ihr [unseren Blogbeitrag zum Thema lesen](https://blog.codecentric.de/emissionen-cloud-architektur-messen).

*Dieser Artikel erschien am 16.12.2022 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr [den Newsletter hier abonnieren](https://blog.codecentric.de/#newsletter-anchor).*


Ist die Cloud der große Umweltsünder? 

Sicherheitslücken in Software und Bibliotheken werden immer auftreten, unabhängig davon, wie viel Energie aufgebracht wird, um sie zu vermeiden. An die als Log4Shell bekannte Schwachstelle vor gut einem Jahr werden sich Viele noch schmerzhaft erinnern.

Das Problem: log4j wird in sehr vielen Werkzeugen und Anwendungen eingesetzt. Damit bauen Entwickler wiederum andere Software. Diese Kette von Abhängigkeiten war und ist natürlich unbegrenzt fortsetzbar. Als Folge durchsuchten unzählige Entwicklerteams ihre Software nach Abhängigkeiten zu gefährdeten Bibliotheken. Es gab Unternehmen, die dafür 15 Minuten brauchten – was bei manchen Managern das Gefühl auslöste: Die nehmen das nicht ernst!

Was machen diese Unternehmen anders? Sie haben für ihre Software und SaaS-Angebote Bills of Material (BOMs) erstellt. Materiallisten, mit allen Paketen und Bibliotheken, die diese Lösungen nutzen. Minimal umfassen diese Listen die Bibliotheken inklusive der Version. Besser noch: zu jeder Bibliothek eindeutige IDs, um öffentliche CVE-Listen zu scannen und Informationen über die Lizenz der Bibliothek zu erhalten. Aus diesen Informationen lassen sich dann mit Tools bekannte Schwachstellen inklusive Bewertung und konkreten Maßnahmen zur Behebung anzeigen, zum Beispiel ein Update auf eine andere Version. Diese Informationen stehen dann im Bedarfsfall schnell zur Verfügung.

An welchen Punkten sind die BOMs relevant? Zunächst natürlich während des klassischen CI/CD-Prozesses. Hier werden die Materiallisten erstellt, registriert und bei Bedarf für externe Kunden und Nutzer veröffentlicht. BOMs sind aber keine Black- oder Whitelists. Das Prüfen der BOMs nach dem Erstellen kann beispielsweise auf Ebene eines Artefakt-Repositorys durchgeführt werden, aus dem die Bibliotheken bezogen werden. Eine einmalige Prüfung nur im CI/CD-Prozess reicht natürlich nicht aus. Während des ganzen Lebenszyklus einer Software muss kontinuierlich auf Sicherheitslücken geprüft werden. 

Eine Umsetzung der Prüfung sowohl im Build als auch im Anschluss lässt sich häufig mit einem einfachen, zusätzlichen Schritt im Build und einem Tool wie dependencytrack erreichen. Und doch wird dies selten umgesetzt, da die Priorität auf den Features liegt, die für Nutzer sichtbar sind. 
Gesetzliche Vorgaben aus Brüssel zur Gewährleistung bei digitalen Gütern und damit auch Software sind ein Grund, sich mit dem Thema zu beschäftigen. Außerdem erwarten Softwarekunden ein aktives Risikomanagement von Herstellern: proaktiv, zeitnah und zielgerichtet informieren, wenn Lücken auftreten. Damit hebt man sich von der Konkurrenz ab und steigert das Kundenvertrauen bei verhältnismäßig geringem Kosteneinsatz.

Natürlich gibt es auch Herausforderungen. BOMs schaffen Transparenz. Wenn Lücken gefunden werden, wissen Leute Bescheid, dass sie da sind. Ignorieren ist dann keine Strategie mehr. Das Anti-Pattern „Security by Obscurity” funktionierte aber sowieso noch nie. Ebenso werden manche Lücken schlicht nie behoben. Das heißt, es wird immer ein Grundrauschen von Meldungen geben. Eine zeitnahe Risikoabschätzung der einzelnen Meldungen ist immer essenziell. Das Erkennen selbst hängt stark von der Qualität des Package Managers (die großen wie maven, npm oder pip sind kein Problem) sowie den CVE-Listen ab. Auch bei Containern gibt es (noch) Herausforderungen, wirklich alle Komponenten zu identifizieren, die auf der SBOM landen sollen. Trotzdem sind SBOMs heute aus Security-Sicht wichtiges Handwerkszeug, um bei der stetig wachsenden Anzahl bekannter CVEs zeitnah und zielgerichtet reagieren zu können.

*Dieser Artikel erschien am 06.01.2023 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr [den Newsletter hier abonnieren](https://blog.codecentric.de/#newsletter-anchor).*

Schneller handeln bei Software-Schwachstellen 

SQL ist weiterhin aus der Datenanalyse nicht wegzudenken – es ist vergleichsweise einfach zu lernen und Anwender können es ohne zusätzliche Werkzeuge auf einer Datenbank ausführen. Entsprechend ist es bei vielen Datenanalysten und Engineers beliebt. Es hat aber auch Schwächen, die besonders im Vergleich zu Python auffallen. Dort gibt es neben den bekannten Machine-Learning-Frameworks auch für Datenpipelines eine Reihe von Werkzeugen, ob zur Datenvalidierung oder Orchestrierung. Dinge, die mit SQL allein gar nicht oder nur mühselig abzubilden sind.

Zudem ist bei Datenplattformen Python oft der Standard für die Verarbeitung von Daten. Da mit SQL aber vergleichsweise gut Transformationen auf Daten ausgedrückt werden können, findet man dann häufig folgendes Pattern: Python-Glue-Code wird geschrieben, der dann SQL-Statements ausführt. Im Extremfall ist das Ganze auch noch über Notebooks verteilt.

[dbt (data build tool) ist ein Kommandozeilentool](https://www.getdbt.com/), um mit SQL solche Datenpipelines strukturiert aufzubauen. Ebenso ermöglicht es die Validierung der Daten direkt in der Pipeline. Es hilft auch bei der Historisierung von Stammdaten, die regelmäßig aus operativen Systemen abgezogen werden. Als Ergebnis gibt es nicht nur saubere und gefüllte Tabellen in einer Datenbank, sondern auch Dokumentation und Abhängigkeitsgraphen.

Mit SQL und dbt lassen sich nicht nur Daten aufbereiten. Auch die darauf folgenden, regelmäßigen Analysen und Auswertungen lassen sich so bequem automatisieren. Inklusive Rückverfolgbarkeit, welche Analyse welche Daten benutzt. Und wenn die Basisdaten inhaltliche Fehler aufweisen, werden die Auswertungen, die darauf basieren, gar nicht erst aktualisiert.

Was muss man dafür tun? Weiterhin SQL schreiben. Außerdem ist ein wenig Konfiguration in YAML notwendig. Optional lassen sich auch Jinja2-Templates verwenden, um komplexere oder wiederkehrende Aufgaben zu lösen. Zudem gibt es eine Reihe von Bibliotheken, die sich unkompliziert einbinden lassen, zum Beispiel für erweiterte Tests auf den Daten. Ausgeführt wird das SQL dann direkt auf der konfigurierten Datenbank. Konzepte für die Trennung von Entwicklung und Produktion sowie die parallele Entwicklung am gleichen Datenmodell sind ebenfalls vorhanden.

dbt ermöglicht es, (Data) Engineering Practices auch für SQL-Datenpipelines anzuwenden. Wer Datenpipelines mit SQL schreibt, sollte es dringend verwenden. Gearbeitet wird aktuell auch an einer Integration von Python. So soll es möglich sein, manche Teile der Pipeline in SQL, andere in Python zu implementieren.  

*Dieser Artikel erschien am 20.01.2023 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr [den Newsletter hier abonnieren](https://blog.codecentric.de/#newsletter-anchor).*

Bessere SQL-Datenpipelines mit dbt 

Die Frage, was ein Nutzer in einer Anwendung darf, besteht oft aus komplexen Regeln und Konfigurationen, gespeichert in Datenbanken. Regelwerke werden in großen IT-Landschaften in verschiedenen Anwendungen häufig redundant implementiert, teils auch in unterschiedlichen Sprachen. Das führt fast zwangsläufig zu Inkonsistenzen und so zu potenziellen Sicherheitslücken.\nDer Open Policy Agent (OPA) ist eine generische Policy-Engine zum Definieren und Durchsetzen von Regeln. Die Idee ist es, Autorisierungslogik (Policies) und die dazu notwendigen Daten zentral zu verwalten, aber dezentral auszuwerten. Durch einen „Policies as Code“-Ansatz lassen sich technologieneutrale, wiederverwendbare Policies definieren, die einfach ausgewertet und getestet werden können.\nEin konkretes Beispiel: Eine mögliche Autorisierungsanfrage an OPA besteht aus dem aktuellen Benutzer und der Funktion, die aufgerufen werden soll. In den Regeln steht, dass diese Funktion von allen Usern aufgerufen werden darf, die in einer bestimmten Gruppe sind. In
der zusätzlichen Konfiguration steht, in welchen Gruppen ein User ist. Mit den
Informationen aus der Anfrage, den Regeln und der Konfiguration kann OPA eine
Entscheidung treffen.\nIn gängigen Web-Frameworks beschränkt sich die Unterstützung bei der Autorisierung bislang häufig auf die Prüfung von User, Gruppen, Rollen oder Berechtigungen. OPA ist hingegen flexibel in der Ausgestaltung der Regeln. Unterstützt werden zum Beispiel auch Regeln der Art: „Diese Funktion dürfen alle Support-Mitarbeiter ausführen, allerdings nur werktags zwischen 9 und 18 Uhr.“ \nInteressant wird OPA im Zusammenspiel mit der sogenannten Relation Based Access
Control (ReBAC). Hier wird die Berechtigungsprüfung als „Graph Traversal“-Aufgabe gelöst. Ein Beispiel: Die verschiedenen Elemente (Dokumente, Ordner, Ablagen, Gruppen, Benutzer) und Beziehungen (Eigentümer, Bearbeiter, Kommentator) in einem Google Drive werden als Graph modelliert. Wenn ich nun prüfen möchte, ob ein User ein Dokument lesen darf, prüfe ich, ob es einen Pfad durch den Graph vom Dokument zum User gibt (z. B. das Dokument liegt in einem Ordner, der Ordner ist freigegeben für eine Gruppe, der User ist Teil der Gruppe). Falls ja, wird der Zugriff gestattet. Über dieses Konzept lassen sich Prüfungen auch über eine große Zahl von Elementen abbilden, die von Nutzern erstellt werden. \nIn komplexen Anwendungsszenarien mit feingranularer Autorisierungslogik und datengetriebenen Berechtigungsstrukturen ist die Kombination von OPA und einem ReBAC-basierten Modell (z. B. OpenFGA) denkbar. Die Kombination ermöglicht es, die Flexibilität der Regeln in OPA mit den Skalierungsmöglichkeiten der datengetriebenen Autorisierung von ReBAC zusammenzubringen. Mit topaz gibt es auch schon Implementierungen dieser Idee.\nDie zentrale Autorisierung mittels OPA ist vor allem bei verteilten Anwendungen mit unterschiedlichen Stacks interessant. Ebenso bei Software, die einmal entwickelt wird und für unterschiedliche Einsätze unterschiedliche Regeln zur Autorisierung bekommt, zum Beispiel beim Einsatz in anderen Unternehmen. Die Verbindung von OPA mit ReBAC ist ein interessanter Ansatz, insbesondere für Anwendungen mit hohen Anforderungen bezüglich Skalierbarkeit.\nDieser Artikel erschien am 03.02.2023 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr \nden Newsletter hier abonnieren\n.\n\n


Wie Open Policy Agent Entwickler befähigt, Autorisierungen einfach umzusetzen 

Dass die Aufbau- und Ablauforganisation eines Unternehmens wichtig für eine schnelle und flexible IT ist, ist kein Geheimnis. Folglich gibt es eine Reihe von Ansätzen, die hier für Verbesserungen sorgen sollen: agile Ansätze, SAFe und alles, was es rund um das Thema DevOps gibt. Aus dem DevOps-Umfeld kommen auch die Team Topologies, die Manuel Pais und Matthew Skelton 2019 in ihrem gleichnamigen Buch beschreiben.\nSobald eine gewisse Anzahl unterschiedlicher Teams und Interaktionen zwischen ihnen erreicht wurde, ist es sinnvoll, die Teams und Erwartungshaltungen an eben diese klar zu benennen und zu kommunizieren. Ebenso muss die Zusammenarbeit zwischen den Teams geklärt werden und welche Schnittstellen zwischen ihnen genutzt werden sollen. Ziel ist es, dass die Teams ihre Energie in die Lösung der eigenen Herausforderungen stecken, und nicht in die Reibung dazwischen.\nSkelton und Pais haben dafür vier verschiedene Teamtypen definiert: Stream-Aligned, Enabling, Complicated Subsystem und Plattform. Ziel ist es, die crossfunktionalen value-stream-aligned Teams, die eigenständig für ein Produkt zuständig sind, zu unterstützen. Zunächst gibt es da die Enabling Teams, die den Stream-Aligned Teams in Form von Coaching und Mentoring helfen, zum Beispiel zum Thema Security. Sie bauen aber selbst keine Lösungen, die sie betreiben und anbieten.\nDas ist Aufgabe der Plattform-Teams, die aktiv die Infrastruktur vereinfachen. Sie lohnen sich erst, wenn mehrere (5-7) Teams die gleiche Funktionalität benötigen. Dabei sind sie immer auf den Nutzen für den Kunden, die Stream-Aligned Teams, ausgerichtet (s. die Diskussionen rund um das Thema Platform Engineering). Bei Bedarf können dann auch noch Complicated-Subsystem-Teams gebildet werden, die keinen direkten Kundennutzen schaffen, sondern an Problemstellungen arbeiten, die ein tiefes technisches Wissen benötigen. \nNeben den Teamtypen werden auch drei Kollaborationstypen definiert:\n1) Collaboration: Eine enge gemeinsame Zusammenarbeit. \n2) X as a Service: Ein Team bietet eine Dienstleistung als Produkt für die anderen Teams an.\n3) Facilitation: Der Fokus liegt auf dem Enabling eines Teams.\nDie zeitliche Komponente ist dabei wichtig. Zu Beginn kann Collaboration zwischen Teams gewünscht und richtig sein. Mit der Zeit ist eine solche Kollaboration aber eher ein Zeichen für ein organisatorisches Problem. Mittels der Team- und Kollaborationstypen kann man also Teaminteraktionen auch im Laufe der Zeit betrachten und verstehen.\nDie Team Topologies sind für uns eine State-of-the-Art-Methode zum Thema Teamorganisation und werden von uns regelmäßig als Gedankenmodell verwendet. Scrum, Kanban und SAFe fokussieren im Vergleich dazu mehr das Vorgehen und notwendige Rollen. Sie ergänzen die Topologies, insbesondere Kanban passt hervorragend mit den Ideen zusammen. Die Topologies sind sehr fundiert. Hauptsächlich auch, da sie auf Beobachtungen zu DevOps-Antipatterns basieren. Mit „Unfix“ steht schon der nächste Ansatz zum Thema vor der Haustür. Es ist abzuwarten, ob es mehr ist als eine Evolution der bisherigen Herangehensweise. \nDieser Artikel erschien am 17.02.2023 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr \nden Newsletter hier abonnieren\n.

Team Topologies: Ein Gedankenmodell für leistungsstarke Teams 

APIs spielen eine zentrale Rolle bei der Digitalisierung. Extern angeboten, ermöglichen sie das Erschaffen von Ökosystemen und neuen Geschäftsmodellen. Unternehmen wollen gerne selbst als Plattform gesehen werden, auch hier sind APIs unerlässlich. Intern, innerhalb der Unternehmen, dienen APIs nicht nur der Vernetzung unterschiedlicher IT-Systeme, sondern ermöglichen im Optimalfall auch den schnellen, programmatischen Austausch zwischen ganzen Domänen. \nWenn es um das Design von APIs geht, kommt diese Wichtigkeit oft nicht zum Tragen: Die Innensicht der IT-Systeme wird nach außen getragen, es fehlt der Fokus auf die Personengruppe, die die API nutzen wird – und die Frage, welches Problem überhaupt gelöst werden soll, wird nicht beantwortet.\nUnter API Experience versteht man die Anwendung von Consumer-Centric- und UX-Methoden auf das Thema API. Dafür werden zum Beispiel die Ideen des Design-Sprints und Design Thinking adaptiert, um eine API zu schaffen, die den Anforderungen der Konsumenten genügt. Nachdem man das für einige APIs durchgeführt hat, lassen sich daraus grundsätzliche Guidelines für APIs ableiten, spezifisch für den eigenen Kontext. Generische Guidelines können dabei als Grundlage dienen, sollten aber zwingend an die eigene Situation angepasst werden, zum Beispiel an verwendete Architektur- und Technologiekonzepte wie REST vs. Messaging. Konzepte wie Paging, Filtering, der Umgang mit großen Payloads oder langlaufenden Operationen sowie Rate Limiting sind nicht in allen Kontexten sinnvoll. \nBevor man sich konkret über die API und deren Ausgestaltung Gedanken macht, muss geklärt sein, in welcher Rolle man selbst in der API Economy auftritt: Bin ich Anbieter oder vor allem Nutzer? Biete ich meine APIs öffentlich für alle an, nur für eine begrenzte öffentliche Nutzerschaft oder sogar nur intern? Welche Mehrwerte will ich meinen Nutzern anbieten? Hier kommen wir wie schon beim Platform Engineering oder Data Mesh zu dem Punkt, etwas „as a Product“ zu betrachten, in diesem Fall eine API. Themen wie Ownership, Dokumentation und Messen der API, z. B. mittels eines API-Gateway und -Catalog, fließen also auch hier mit ein.\nDer zentrale Teil einer API ist das Datenmodell. Dieses sollte gemeinsam mit den Konsumenten beschrieben werden. Ein möglicherweise bereits vorhandenes Datenmodell, beispielsweise aus einem Data Catalog oder einem Master Data Management, kann dabei als Basis genommen werden. Dieses Vorgehen bedeutet aber nicht, dass zwingend „API First“ gearbeitet werden sollte. Im Gegenteil, für viele Anbieter ist das deutlich schwieriger, da sie aufgrund von Legacy-Systemen, die die Anfragen am Ende beantworten, Einschränkungen haben.\nMit der API Experience sollen der Nutzer und der Nutzen wieder mehr in den Vordergrund gerückt und Organisationen befähigt werden, konsistent und mit wenig Aufwand gute APIs bereitzustellen. Insbesondere für Endpunkte, die von außerhalb der Domäne oder Organisation genutzt werden, eine sinnvolle Sache. \nDieser Artikel erschien am 03.02.2023 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr \nden Newsletter hier abonnieren\n.

Experience: Jetzt auch für APIs 

Crossplane ist ein plattformübergreifendes Kontrollsystem (Control-Plane), das das Management von Cloud-Ressourcen vereinfachen und automatisieren soll. Das Tool ermöglicht es, verschiedene Cloud-Provider und lokale Ressourcen, z. B. Kubernetes-Cluster, als einheitliche Infrastruktur zu verwalten.\nDas Hauptproblem, das Crossplane löst, ist die Herausforderung, verschiedene Cloud-Provider und lokale Ressourcen zu integrieren und zu automatisieren. In einer zunehmend hybriden Cloud-Umgebung ist es schwierig, die Komplexität und Heterogenität der Cloud-Infrastruktur zu managen. Crossplane stellt eine einheitliche API und einheitliche Tools zur Verfügung, um verschiedene Cloud-Provider und lokale Ressourcen effizient zu verwalten. \nRealisiert wird das durch das Verwenden von Composite Resource Definitions (CRD) und damit der Kubernetes-API. Und man ahnt es bereits: Damit das Ganze funktioniert, braucht man ein Kubernetes-Cluster als Management-Cluster (ein minikube ist ausreichend). Ich nutze also Crossplane, um Ressourcen in der Public-Cloud ähnlich zu konfigurieren, wie ich es auch mit Pods und Services in Kubernetes mache. Ist man dadurch, dass man Kubernetes und nicht AWS CloudFormation/CDK, GCP Deployment Manager oder Azure Resource Manager nutzt, auch direkt nicht mehr an den Anbieter gebunden? Wohl kaum, schließlich unterscheiden sich die Services der Cloud-Provider teils deutlich – und auch mit Crossplane werden Services provisioniert, nicht abstrakte Patterns. Das ist ein Ansatz, den beispielsweise dapr.io verfolgt.\nInteressant wird Crossplane so insbesondere in Verbindung mit einer Developer-Plattform. So können die CRDs inklusive Composite und Managed Resources von den Plattform Engineers detailliert konfiguriert und für die Anwendungsentwickler bereitgestellt werden. Diese nutzen dann nur noch die aus dem Kubernetes-Ökosystem bekannten Claims, um die bereitgestellten Ressourcen, zum Beispiel Datenbanken oder Load Balancer, in ihrer Anwendung zu nutzen. Crossplane bietet schon eine Reihe von vordefinierten Ressourcen in Form von Providern, zum Beispiel für die drei großen Cloud-Anbieter. Diese Provider laufen als schlanker Container im Management-Cluster.\nIch nutze also Kubernetes, um Services zu provisionieren. Das klingt nach einem ziemlichen Overkill. Wenn man Kubernetes schon nutzt, kann das Sinn ergeben, da man kein anderes IaC-Tool (z. B. Terraform, Pulumi, CDK) lernen muss. Man bleibt bei der Kubernetes-API, die inzwischen als Industrie-Standard gesehen werden kann. Wenn man Kubernetes noch nicht hat, bekommt man mit Crossplane dann eben jenen Standard statt eine weitere IaC-API. Die Frage, ob das die bessere Alternative ist, muss jeder für sich selbst entscheiden.\nNeben dem Provisionieren von Services in einem Hybrid-Cloud-Szenario wird für Crossplane inzwischen auch der bereits beschriebene Plattform-Engineering-Ansatz verstärkt in den Fokus gesetzt. Aktuell ist die Technologie eher bei den Early Adoptern zu finden und es gibt in der API auch immer nochmal größere, meist non-breaking, Änderungen. Aber mit diesen Änderungen gelingt vielleicht noch eine erfolgreiche Positionierung im Bereich Platform Engineering.\nDieser Artikel erschien am 21.04.2023 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr \nden Newsletter hier abonnieren\n.\n

Crossplane: Eine Lösung für hybride Cloud-Herausforderungen? 

Observability, also die Möglichkeit, das Verhalten von Anwendungen in Echtzeit zu überwachen, Fehler schnell zu identifizieren und Probleme proaktiv anzugehen, ist ein unverzichtbares Element für erfolgreiche digitale Unternehmen. OpenTelemetry ist eine Open-Source-Initiative, die Entwicklern dabei helfen soll, dies in ihren Anwendungen zu implementieren.\nOpenTelemetry ist aus der Zusammenlegung von OpenCensus und OpenTracing entstanden und wird von der Cloud Native Computing Foundation (CNCF) unterstützt. Es stellt eine Reihe an APIs, SDKs und Tools bereit, die es Entwicklern ermöglichen, Metriken, Traces und Logs in Echtzeit zu sammeln und zu transportieren. Durch die Unterstützung einer Vielzahl von Sprachen, Plattformen und Cloud-Anbietern ist es insbesondere für das Distributed Tracing, also dem Einsatz in komplexen, verteilten, heterogenen Landschaften, bestens geeignet.\nDer Hauptvorteil von OpenTelemetry besteht darin, dass Entwicklern eine einheitliche, standardisierte Schnittstelle sowie ein Verfahren für das Sammeln relevanter Informationen in Anwendungen und Systemen bereitgestellt werden. Dies kann sowohl in Form von Agents, als auch mittels SDKs erfolgen. \nDas Zusammenführen, Visualisieren und Auswerten dieser Informationen erfolgt dabei weiterhin in einem der bekannten Backend-Systeme wie Instana, Datadog oder anderen. Die meisten der Anbieter unterstützen dabei inzwischen auch das Sammeln von Informationen mittels OpenTelemetry. Auch in vielen Application-Frameworks sowie -Servern ist OpenTelemetry inzwischen schon von Anbietern integriert.\nMit dem Werkzeug wird die Lücke zwischen Dev und Ops beim Thema Observability zunehmend kleiner. Interessant wird sein, ob die Cloud-Anbieter die Unterstützung für den Standard weiter ausbauen (z. B. eine Integration in Lambdas/Functions) oder sie dort weiter auf die eigenen Angebote setzen. Bei OpenTelemetry liegt der Fokus darauf, die Verbreitung auszubauen, neben den Cloud-Anbietern beispielsweise auch in Form von SDKs für andere Sprachen jenseits von Java/TypeScript. Ebenso ist Observability im Frontend bislang noch wenig standardisiert. \nMöglicherweise gibt es irgendwann auch mal eine Referenzimplementierung für das Zusammenführen und Auswerten, ein Standard ist hier aber nicht zu erwarten. Hier gibt es also noch viele Differenzierungsmöglichkeiten für die Anbieter der diversen Werkzeuge. Nur weil die Daten nun einfacher gesammelt werden können, heißt das nicht, dass auch die Analyse einfach von der Hand geht – und auch nicht, dass die Daten auch tatsächlich gesammelt werden in den Anwendungen. Hier gilt es einen „Golden Path“ vorzugeben, der das Sammeln relevanter Informationen in neuen Systemen von Anfang an berücksichtigt und einfach implementiert. \nDieser Artikel erschien am 26.05.2023 im Rahmen des codecentric-Innovations-Newsletters. Wenn ihr immer direkt über die neusten IT-Trends und -Techniken informiert sein wollt, könnt ihr \nden Newsletter hier abonnieren\n.\n

Zukunftssichere Observability mit OpenTelemetry  

Spark Streaming, Flink, Storm, Kafka Streams –  that are only the most popular candidates of an ever growing range of frameworks for processing streaming data at high scale. This article is about the main concepts behind these frameworks. Furthermore the three Apache projects Spark Streaming, Flink and Kafka Streams are briefly classified.<h2>Why Stream Processing?</h2>The processing of streaming data is gaining in importance due to the steadily growing number of data sources that continuously produce and offer data. In addition to the omnipresent Internet of Things, these include, for example, click streams, data in the advertising business, as well as device and server logs.Infinite and continuous data is not a new phenomenon. Even now, many data correspond to this scheme. For example, changes to master data occur continuously, but only at low frequency. Master data is processed according to the classic request / response pattern. In the case of non-time-critical changes or larger volumes, the data are often stored collectively and then processed regularly by batch processes. These then run, for example, every night or at shorter intervals.However, daily intervals are often not sufficient. Speed is needed: analyzes and evaluations are expected promptly and not minutes or even hours later. At this point stream processing comes into play: data is processed as soon as they are known to the system. This has started with the lambda architecture (cf. [1]), in which the stream and batch processing takes place in parallel, since the stream processing could not guarantee consistent results. With today’s systems, it is also possible to achieve consistent results in almost real-time with streaming processing only (cf. [2]).<h2>Time Matters</h2>An important aspect of streaming is the time. Essentially three different times can be distinguished:<ul><li>Event time: Time at which the event actually occurred</li><li>Ingestion time: Time at which the event was observed in the system</li><li>Processing time: Time at which the event was processed by the system</li></ul><a href="https://media.graphassets.com/doUmMyq0RnMFLNkpcPA4"><img src="https://media.graphassets.com/doUmMyq0RnMFLNkpcPA4" alt width="806" height="232" /></a> Abb. 1: Exemplary representation of event time and processing time. With late (yellow, green, red) and out-of-order events (blue)In practice, the event time is particularly interesting compared to the ingestion and processing time. The difference between the event time and the processing time can vary greatly. The reasons are numerous: network latencies, distributed systems, hardware failures or even irregular data delivery. When being processed by the processing time, this is not important. The data is analyzed based on the system time of the processor: if an event arrives at 12 o’clock, it is irrelevant that it has already occurred at 11 o’clock.But this is not the normal use case: If an event occurs at 11 o’clock I would like to treat it in the time it occurred. The question here is: When do I know that I got all the events until 11am? How long do I wait for events? There are several strategies and concepts to solve those problems. On of them is the Dataflow/Beam Model. Here, concepts such as watermarks, triggers and accumulators help:<ul><li>Watermarks: When did I collected all the data?</li><li>Trigger: When should I trigger the calculation?</li><li>Accumulation: How do I merge individual calculations, for example when data is subsequently added.</li></ul>It is easy to write a separate article about these three concepts. Tyler Akidau, the head behind streaming on Google, has already summed this up. Therefore it is recommended to read his article for details [3].<h2>State & Window</h2>Any non-trivial application will correlate incoming events with each other. This requires a state in which previous events are stored temporarily. This state can be stored indefinitely or explicitly limited in time. An example of an infinite stored state is a lookup table with metadata. A temporally limited state is, for example, a window.A window is used to aggregate and analyze data for a specific period of time. This is necessary in almost every application, since the data stream never ends. There are different types of Windows.<ul><li>Tumbling Window: Non-overlapping, fixed time segments</li><li>Sliding Window: Overlapping, fixed time segments</li><li>Session Window: Non-overlapping time segments of different length. Defined by certain events or by exceeding a certain time between two events</li></ul><img loading="lazy" src="https://media.graphassets.com/jMIWsYHTSdqB1gMIVRe5" alt width="686" height="214" />Abb. 2: Tumbling and sliding window with a time window of 4 seconds and a sliding interval of 2 seconds with the sliding window. Within each window the values are summed.<img loading="lazy" src="https://media.graphassets.com/m2AyHaoQ7meYWoB9Mhqg" alt width="598" height="122" />Abb. 3: Session windows with an inactivity of at least two minutes between two events for a key.For the definition of windows, the distinction between event and processing time is important: windows based on processing time are very simple to implement; windows based on event time need the above event time strategies, in order not to grow infinitely.<h2>API & Runtime Environment</h2>First differences in the frameworks can be found within the API and the general processing model. Differentiating between a native streaming approach and microbatching. In native streaming, incoming data is processed directly while microbatching collects the incoming data for a certain time (typically 1 – 30s) and then processes it together. The next microbatch can then be started either directly after the completion of the previous batch, or only after the fixed interval has elapsed. In both cases, microbatching increases latency, but the handling of errors is somewhat easier. The frequently mentioned advantages of the very high throughput can now also be achieved by native streaming frameworks. They also offer more flexibility for windows and states.Visible to the developer is mainly the API. Here, too, a distinction can be made between two variants: a component-based and a declarative, high-level API. For the former, the flow is described by several components (source -> processing 1 -> processing 2 -> sink), the latter describes the operations on data (map, filter, reduce) similar to Scala Collections or Java 8 streams . The description of components provides more flexibility in the distribution of data streams, while the declarative API often already provides higher-order functions and automatic optimization.Finally, the question is: Where are the applications running? One can distinguish between two – surprise 🙂 – basic alternatives. Some frameworks need a special cluster consisting of master nodes and worker nodes. These clusters then also deal with resource management and error handling, but can also outsource this to other tools (for example, YARN or Mesos). Other frameworks come as a simple library, which can be integrated into your own application. Running and scaling the application must then be taken over by other tools. Here you have the full flexibility from running a jar file via docker up to Mesos or YARN.<h2>Distributed systems are unreliable!</h2>All three frameworks are specialized in processing large amounts of data and solve this by horizontal scaling. These distributed systems are inherently unreliable: single nodes can fail, the network is inconsistent, or the database in which the results are to be written is unavailable.For this reason, each framework has different mechanisms to achieve certain guarantees. These range from microbatching, in which small batches are repeated, via acknowledgments for individual data sets, to transactional updates on source and sink. The guarantees achieved are then usually at-least-once or exactly-once. Since exactly-once is often difficult to achieve, at-least-once guarantees with idempotent operations are often sufficient in terms of both speed and error tolerance.<h2>Isn’t there something that can help us?</h2>Time handling, state & windows, a runtime environment, all in a distributed fashion: streaming applications are complex. There are a number of projects to help with these problems. Three of them briefly presented:Apache Spark (Streaming) Apache Spark is currently one of the most popular projects in the streaming field. Started as a better MapReduce, support for streaming data was added later. Spark streaming relies on microbatching with a declarative API. At the moment, only the processing time is fully supported, but with the new Structured Streaming API the support for event time processing has also been gradually expanded since version 2.0. The same is true for supporting windows. The state is stored locally in memory or on disk and is regularly backed up by checkpointing. Since Spark is now distributed with every major Hadoop distro, the overall distribution is very high. There is also a large ecosystem with many tools and connectors.Apache Flink When it comes to event-time processing, Apache Flink is currently the first choice. Watermarks and triggers are supported as well as different window operations. Flink pursues a native streaming approach and thus achieves low latencies. As with Spark Streaming it offers a declarative API, with the possibility to use so-called rich functions, in which, for example, a state can be utilized. Unlike Spark, the state implementations can be chosen from different implementations: in-memory, hard disk or RocksDB. Flink is slightly younger than Spark, but is gaining in popularity. Likewise the community and the ecosystem is growing steadily, but is not yet as big as with Spark.Apache Kafka Streams The streaming framework from the Kafka ecosystem is the latest representative in this overview. It is based on many concepts already contained in Kafka, such as scaling by partitioning the topics. Also for this reason it comes as a lightweight library, which can be integrated into an application. The application can then be operated as desired: standalone, in an application server, as docker container or via a resource manager such as mesos. Flink & Spark, on the other hand, always need a cluster, either built with the equipment of the frameworks or YARN / mesos. Kafka Streams, however, is limited to Kafka as a source and also as a sink. But you can connect a Kafka topic to other systems through Kafka Connect, with over 60 available connectors. Apart from a declaratory, Kafka also has a component-oriented API, a rudimentary support for event time, and RocksDB as a state implementation. While Kafka is already very mature and often used in connection with Flink and Spark, the streaming component is still quite young. So the community and the spread is rather small. It is, however, to be expected that both will grow rapidly. Update:It should be noted that Kafka Streams does not use the concepts of the Beam Model to tackle the challenges of event time processing. Streams is built on the concept of <a href="http://docs.confluent.io/3.2.0/streams/concepts.html#duality-of-streams-and-tables">KTables and KStreams</a> , which helps them to provide event time processing.<h2>And what suits me?</h2>Finally, the question is: Which framework suits me?  If event-time processing is required and you do not mind working with the concepts of the Beam Model, you could go with Apache Flink. Another advantage is the low latency. The most important systems (Kafka, Cassandra, Elasticsearch, SQL databases) can be integrated relatively easily.The low latency and an easy to use event time support also apply to Kafka streams. So if Kafka is already in use <s>and the processing is rather simple, without complex requirements for event processing</s> (Streams can also be used for more complex stream processing), Kafka Streams is a good alternative. For this you have to connect the other systems, like databases, via Kafka Connect and care about the runtime environment. This can also be an advantage if I can use existing tools, for example from the Docker ecosystem.And Spark? If event time is not relevant and latencies in the seconds range are acceptable, Spark is the first choice. It is stable and almost any type of system can be easily integrated. In addition it comes with every Hadoop distribution. Furthermore the code used for batch applications can also be used for the streaming applications as the API is the same.Only with very large states Spark can cause problems. The support for event time is expanded with Spark 2.1.<h2>Conclusion</h2>Stream processing frameworks significantly simplify the processing of large amounts of data. The presented frameworks primarily solve problems in the area of distributed processing, whereby easy-to-scale solutions can be developed. Equally important are the different aspects of the time processing, which all frameworks support in some way.That is what  distinguishes those systems from libraries such as Akka Streams, RxJava, or Vert.x. The presented frameworks are mainly located in the Big and Fast Data area, while the libraries can also be used to build smaller, more reactive applications, but usually without native support for event time and clustering.It remains to be noted that the presented framework can all help with current challenges in the fast data area and also support new architectures beyond the well-known lambda architecture. However, the complexity of these distributed systems is in no way to be underestimated. Nevertheless, it is to be assumed that the spread of the systems as well as the functionality will continue to grow.<h2>Links</h2>[1] <a href="http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html">http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html</a> [2] <a href="https://www.oreilly.com/ideas/questioning-the-lambda-architecture">https://www.oreilly.com/ideas/questioning-the-lambda-architecture</a> [3] <a href="https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102">https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102</a>

Distributed Stream Processing Frameworks for Fast & Big Data

With the new release of Spark 2.1, the event-time capabilities of Spark Structured Streaming have been expanded. It is time to take a closer look at the state of support and compare it with Apache Flink – which comes with a broad support for event time processing. . In this article, I will describe how three basic solutions for event processing – watermarks, triggers and accumulators – work and then compare their implementation in Spark and Flink. Base of the comparison is Spark in version 2.1 and Flink in version 1.2.For a broader comparison of the frameworks refer to <a href="https://blog.codecentric.de/en/2017/03/distributed-stream-processing-frameworks-fast-big-data/" target="_blank">Distributed Stream Processing Frameworks for Fast & Big Data</a> . The linked article also describes further basics, which are presupposed for this comparison, for example stafeful & window stream processing as well as the difference between event and processing time.The central problems of event processing are unsorted as well as delayed events. Events are not observed by the system exactly at the time they occur. The difference between the event time and the processing time is not constant. Especially in the case of temporal evaluations, this increases the complexity of the system and thus also the coding. If, for example, all events between 12 and 13 o’clock are to be processed (a typical window operation), multiple question arise: How to deal with late events? How long to wait for delayed entries? How to update the result in case of delayed entries? Google has presented various solutions for these problems with the Dataflow API, which has now been released in Apache Beam. Both Spark and Flink do not explicitly follow the Dataflow API, but the concepts are similar and therefore can be compared.The concepts used in the Dataflow API are one way to tackle event-time processing problems. Kafka Streams for example takes other strategies for event-time support. More on this hopefully in a following blog post.<h2>Watermarks</h2>To determine up to which time events have already been processed, there are watermarks. These show – as with a water level – the so far reached “time level”. When a watermark is reached, the result of the calculation is materialized. For example, if the watermark is defined as the time of the latest event minus a fixed buffer of 30 seconds, it means “It is assumed that now all events have arrived until the time x”. x is in this case the watermark defined as time(newest event) – 30 seconds.There are also heuristic watermarks where the buffer is dynamically adapted, for example based on empirical measurements. Thus the system could observe that events are always received at night with a clear delay. The buffer could be increased on this basis. Likewise, the expected delay could be extrapolated from the delay of the last hour. In addition, there is also the – mostly unrealistic – perfect watermark, where the event is processed directly when it occurs.In the context of watermarks, the “allowed lateness” is often mentioned. For Spark, for example, this is the watermark buffer described above. In the Dataflow Model, however, allowed lateness is an additional period after the watermark, in which events are not ignored, but can subsequently influence the result. Therefore rules are defined – for example by means of triggers – how and how often events are to be processed that occur within allowed lateness.Regardless of the interpretation of allowed lateness, all data for the calculation of the result must remain stored until the allowed lateness has elapsed in order to update the results. The data is then automatically deleted.<h2>Trigger</h2>While watermarks display the current state of the data received, triggers materialize the calculation. The watermark trigger is the easiest way to do this: it is fired as soon as the watermark reaches the end of the window – for example, 1:00 pm with a window from 12 am to 1 pm. With the watermark defined above with a fixed buffer of 30 seconds, this will be the case at 13:00:30.Other triggers are possible:<ul><li>On the processing time, for example, every 2 minutes</li><li>On the event number, for example every 100 events</li><li>At special events, for example the end of a file, a technical flush event or based on the content of the event.</li><li>A combination of the three above</li></ul>Triggers are typically used to determine intermediate results before the watermark is reached, or to update the results for delayed events. It would be possible, for example, with a window of 10 minutes to trigger every minute, then again at the watermark and finally at each delayed event until the allowed lateness is reached.<h2>Accumulation</h2>If the result is calculated more than once by the use of triggers, the developer must define how the individual partial results are handled. There are three variants:<ul><li>Discarding: With each trigger, only the new partial results are passed on and the results obtained up to this point are subsequently deleted.</li><li>Accumulating: The current results are updated and passed on each trigger. The results are not deleted.</li><li>Accumulating & Retracting: Like accumulating with the additional information about the previous result so that subsequent operations can easily correct their results. This mode is provided in the DataFlow model, but is not yet implemented by any framework.</li></ul>The choice of the appropriate accumulation strategy depends strongly on the subsequent processing and the final sink. If this is able to update results, the accumulating mode can be used. If, however, every partial result must only serve once as input for the next step, the discarding mode must be used.<h2>Support in Apache Spark Streaming</h2>Spark does not need a special mode for event processing. Internally, nothing is different from the processing time. To define a window for the event time in Spark, you must first group it by the window<div>

```scala
val words = ... // streaming DataFrame with schema { timestamp: Timestamp, word: String }
 
// Group by window and word, calculate the count for each group
val windowedCounts = words.groupBy(
 window($"timestamp", "10 minutes", "5 minutes"),
 $"word"
).count()
```

</div>This is not significantly different from a groupBy on a key, but with a time window as key. In this case it is a window of 10 minutes length with a sliding interval of 5 minutes. In addition, the entries can still be grouped by a non-technical key, in this case the “word”. With the count at the end you get a word count for a 10 minutes window.In the example above, all data is stored indefinitely so that the result can be updated even in the case of delayed events. With watermarks this time can be limited:<div>

```scala
val windowedCounts = words
 .withWatermark("timestamp", "10 minutes")
 .groupBy(
 window($"timestamp", "10 minutes", "5 minutes"),
 $"word")
 .count()
```

</div>Now spark only waits 10 minutes for delayed data. The data for this window is then deleted. Currently only a watermark with a fixed allowed delay can be used. At Spark, the watermark is currently equal to the allowed lateness.Spark currently implements two different modes to output the result:<ul><li>In the case of the append mode, the result of the window is output after reaching the watermark, ie 10 minutes after the end of the time window. Early triggers, ie when reaching the end of the window, are not possible. The watermark adds an additional latency.</li><li>In the case of complete mode, the previously calculated result is output with every trigger. However, Spark currently only supports triggers based on the processing time. Time-independent or even composite triggers are currently not supported.</li></ul>In conjunction with watermarks, only the append mode can be used, since all the existing data must be available for the complete mode and can not be deleted after reaching the watermark.Spark thus offers a rudimentary support for watermarks (only fixed delay) and triggers (only on processing time). For the accumulations, the implemented output modes of Spark most likely correspond to the accumulating mode of the DataFlow API, since the complete result for a time window is always determined after expiration of the allowed delay.<h2>Support in Apache Flink</h2>It must first be indicated to Flink that the processing is to take place on the event time. This is done by<div>

```scala
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTIme);
```

</div>Depending on the time characteristic, for example, the different window implementations behave differently. In addition, the event time of the stream source is taken into account. If the source does not provide an event time, the event time must be manually extracted from the event using timestamp assigners. The watermark must also be defined for these events.<div>

```scala
stream.assignTimestampsAndWatermarks(new TimestampAndWatermarkAssigner());
```

</div>The developer can completely implement the assigner himself or extend predefined implementations. In particular, different implementations are possible for watermarks:<ul><li>With a fixed distance</li><li>With a dynamic but limited distance</li><li>Or based on specific events.</li></ul><div>

```scala
class FixedWatermarkGenerator extends AssignerWithPeriodicWatermarks[SomeEvent] {
 
 override def extractTimestamp(element: SomeEvent, previousElementTimestamp: Long): Long = {
 element.getEventTimestamp
 }
 
 override def getCurrentWatermark(): Watermark = {
 // the watermark is 10s behind the current time
 new Watermark(System.currentTimeMillis() - 10000)
 }
}
```

</div>The watermark is used to determine the time when most of data for a window was processed. At this time, a calculation is executed. In addition to the watermark, an allowed lateness can be specified. This is the period of time that an event may be delayed beyond the watermark. The allowed lateness is always defined in conjunction with a window operation..<div>

```scala
stream
 .assignTimestampsAndWatermarks(new TimestampAndWatermarkAssigner());
 .keyBy(event -> event.someKey)
 .window((SlidingEventTimeWindows.of(Time.minutes(15), Time.minutes(5)))
 .allowedLateness(Time.minutes(2))
 .apply()
```

</div>A sliding window with a length of 15 minutes, a sliding interval of 5 minutes and an allowed lateness of 2 minutes.When it comes to calculating a window, Flink offers additional triggers besides the watermark. These triggers can react to a certain number (for example all 100 events), to the time (either event or processing time) or to a mixture of both.. It is also possible to dynamically register triggers, which are executed in the future, for example a certain time after an event.Last but not least the question about the accumulators: By default the complete updated data is passed on to subsequent operations within the streaming application. Instead, a fire and purge trigger can be used, in which all current data is deleted after the trigger and all other triggers only pass on the new data. This is then effectively a discarding accumulator.As a result, Flink offers extensive support during event processing with its various watermarks and flexible triggers as well as windows. Despite the flexibility, it is possible to implement standard cases without major effort.<h2>Summary and recommendation</h2>It is obvious that Flink has been working much longer on support for event processing. So it is to be explained that significantly more concepts are already supported. In addition, Flink continuously works on supporting the dataflow concepts, for example with the <a href="https://issues.apache.org/jira/browse/FLINK-6047">implementation of the retractable accumulator</a> . Spark, on the other hand, has only started to support event processing with Structured Streaming. So far the basic principles have been created and the first concepts have been implemented with version 2.1. It is to be expected that Spark will implement the essential functions in the course of the year. But if you need stream processing with event processing now, you should start with Flink.

Event time processing in Apache Spark and Apache Flink

When processing streaming data, the raw data from the events are often not sufficient. Additional data must be added in most cases, for example metadata for a sensor, of which only the ID is sent in the event.In this blog post I would like to discuss various ways to solve this problem in Spark Streaming. The examples assume that the additional data is initially outside the streaming application and can be read over the network – for example in a database. All samples and techniques refer to Spark Streaming and not to Spark Structured Streaming. The main techniques are<ul><li>broadcast: static data</li><li>mapPartitions: for volatile data</li><li>mapPartitions + connection broadcast: effective connection handling</li><li>mapWithState: speed up by a local state</li></ul><h2>Broadcast</h2>Spark has an integrated broadcasting mechanism that can be used to transfer data to all worker nodes when the application is started. This has the advantage, in particular with large amounts of data, that the transfer takes place only once per worker node and not with each task.However, because the data can not be updated later, this is only an option if the metadata is static. This means that no additional data, for example information about new sensors, may be added, and no data may be changed. In addition, the transferred objects must be serializable.In this example, each sensor type, stored as a numerical ID (1,2, …), is to be replaced by a plain-text name in the stream processing (tire temperature, tire pressure, ..). It is assumed that the assignment type ID -> name is fixed.<div>

```scala
val namesForId: Map[Long,String] = Map(1 -> "Wheel-Temperature", 2 -> "Wheel-Pressure")
stream.map (typId => (typId,namesForId(typId)))
```

</div><h6>A lookup without broadcast. The map is serialized for each task and transferred to the worker nodes, even if tasks were previously executed on the worker.</h6><div>

```scala
val namesForId: Map[Long,String] = Map(1 -> "Wheel-Temperature", 2 -> "Wheel-Pressure")
val namesForIdBroadcast = sc.broadcast(namesForId)
stream.map (typId => (typId,namesForIdBroadcast.value(typId)))
```

</div><h6>The map is distributed to the workers via a broadcast and no longer has to be transferred for each task.</h6><h2>MapPartitions</h2>The first way to read non-static data is in a map() operation. However, not map() should be used but mapPartitions(). mapPartitions() is not called for every single element, but for each partition, which then contains several elements. This allows to connect to the database only once per partition and then to reuse the connection for all elements.There are two different ways to query the data: Use a bulk API to process all elements of the partition together, or an asynchronous variant: an asynchronous, non-blocking query is issued for each entry and the results are then collected.<div>

```scala
wikiChanges.mapPartitions(elements => {
 Session session = // create database connection and session
 PreparedStatement preparedStatement = // prepare statement, if supported by database
 elements.map(element => {
 // extract key from element and bind to prepared statement
 BoundStatement boundStatement = preparedStatement.bind(???)
 session.asyncQuery(boundStatement) // returns a Future
 })
 .map(...) //retrieve value from future
})
```

</div><h6>An example for an lookup on data stored in Cassandra using mapPartitions and asynchronous queries </h6>The above example shows a lookup using mapPartitions: expensive operations like opening the connection are only done once per partition. An asynchronous, non-blocking query is issued for each element, and then the values are determined from the futures. Some libraries for reading from databases mainly use this pattern, such as the <a href="https://github.com/datastax/spark-cassandra-connector/blob/master/doc/2_loading.md#using-joinwithcassandratable" target="_blank">joinWithCassandraTable from the Spark Cassandra Connector</a> .Why is the connection not created at the beginning of the job and then used for each partition? For this purpose, the connection would have to be serialized and then transferred to the workers for each task. The amount of data would not be too large, but most connection objects are not serializable.<h2>Broadcast Connection + MapPartitions</h2>However, it is a good idea not to rebuild the connection for each partition, but only once per worker node. To achieve this, the connection is not broadcasted because it is not serializable (see above), but instead a factory that builds the connection on the first call and then returns this connection on all other calls. This function is then called in mapPartitions() to get the connection to the database.In Scala it is not necessary to use a function for this. Here a lazy val can be used. The lazy val is defined within a wrapper class. This class can be serialized and broadcasted. On the first call, an instance of the non-serializable connection class is created on the worker node and then returned for every subsequent call.<div>

```scala
class DatabaseConnection extends Serializable {
 lazy val connection: AConnection = {
 // all the stuff to create the connection
 new AConnection(???)
 }
}
val connectionBroadcast = sc.broadcast(new DatabaseConnection)
incomingStream.mapPartitions(elements => {
 val connection = connectionBroadcast.value.connection
 // see above
})
```

</div><h6>A connection creation object is broadcasted and then used to retrieve the actual connection on the worker node.</h6><h2>MapWithState()</h2>All solution approaches shown so far retrieve the data from a database, if necessary. This usually means a network call for each entry or at least for each partition. It would be more efficient to have the data directly in-memory available.<a href="https://media.graphassets.com/Lxtm7ADtS2OEXqTmEvEj"><img src="https://media.graphassets.com/Lxtm7ADtS2OEXqTmEvEj" alt="Stateful stream procssing within an operation" width="277" height="211" /></a> With mapWithState() Spark itself offers a way to change data by means of a state and, in turn, also to adjust the state. The state is managed by a key. This key is used to distribute the data in the cluster, so that all data must not be kept on each worker node. An incoming stream must therefore also be constructed as a key-value pair.This keyed state can also be used for a lookup. By means of initialState(), an RDD can be passed as an initial state. However, any updates can only be performed based on a key. This also applies to deleting entries. It is not possible to completely delete or reload the state.To update the state, additional notification events must be present in the stream. These can, for example, come from a separate Kafka topic and must be merged with the actual data stream (union()). The amount of data sent, can range from a simple notification with an ID, which is then used to read the new data, to the complete new data set.Messages are published to the Kafka topic, for example, if metadata is updated or newly created. In addition, timed events can be published to the Kafka topic or can be generated by a custom receiver in Spark itself.<a href="https://media.graphassets.com/ickxYXvSeaDhMOnAr61N"><img loading="lazy" src="https://media.graphassets.com/ickxYXvSeaDhMOnAr61N" alt="Data Lookup in Spark Streaming using mapWithState" width="644" height="358" /></a> A simple implementation can look like this. First, the Kafka topics are read and the keys are additionally supplemented with a marker for the data type (data or notification). Then, both streams are merged into a common stream and processed in mapWithState(). The state was previously specified by passing the function of the state to the StateSpec.<div>

```scala
val kafkaParams = Map("metadata.broker.list" -> brokers)
val notifications = notificationsFromKafka
 .map(entry => ((entry._1, "notification"), entry._2))
val data = dataFromKafka
 .map(entry => ((entry._1, "data"), entry._2))
val lookupState = StateSpec.function(lookupWithState _)
notifications
 .union(data)
 .mapWithState(lookupState)
```

</div>The lookupWithState function describes the processing in the state. The following parameters are passed:<ul><li>batchTime: the start time of the current microbatch</li><li>key: the key, in this case the original key from the stream, together with the type marker (data or notification)</li><li>valueOpt: the value to the key in the stream</li><li>state: the value stored in the state for the key</li></ul>A tuple consisting of the original key and the original value as well as a number will be returned. The number is taken from the state or – if not already present in the state – is chosen randomly.<div>

```scala
def lookupWithState(batchTime: Time, key: (String, String), valueOpt: Option[String], state: State[Long]): Option[((String, String), Long)] = {
 key match {
 case (originalKey, "notification") =>
 // retrieve new value from notification or external system
 val newValue = Random.nextLong()
 state.update(newValue)
 None // no downstream processing for notifications
 case (originalKey, "data") =>
 valueOpt.map(value => {
 val stateVal = state.getOption() match {
 // check if there is a state for the key
 case Some(stateValue) => stateValue
 case None =>
 val newValue = Random.nextLong()
 state.update(newValue)
 newValue
 }
 ((originalKey, value), stateVal)
 })
 }
}
```

</div>In addition, the timeout mechanism of the mapWithState() can also be used to remove events after a certain time without updating from the state.<h2>Conclusion</h2>Loading additional information is a common problem in streaming applications. With Spark Streaming, there are a number of ways to accomplish this.The easiest way is to broadcast static data at the start of the application. For volatile data, read per partition is easy to implement and provides a solid performance. With the use of the Spark states, the speed can be increased further, but it is more complex to develop.Optimally, the data is always directly present on the worker node, on which the data is processed. This is the case, for example, with the use of Spark states. Kafka streams pursue this approach even more consistently. Here, a table is treated as a stream and – provided the streams are identical partitioned – distributed in the same way as the original stream. This makes local lookups possible.Apache Flink is also working on efficient lookups, here under the title<a href="https://cwiki.apache.org/confluence/display/FLINK/FLIP-17%3A+Side+Inputs+for+DataStream+API"> Side Inputs</a> .

Lookup additional data in Spark Streaming

Head of Data

Talk "Datenarchitektur in der Realität"

Nur ein Gedanke …Vor ein paar Tagen habe ich das folgende Zitat gelesen:<blockquote>„Perfektion entsteht offensichtlich nicht dann, wenn man nichts mehr hinzuzufügen hat, sondern wenn man nichts mehr wegnehmen kann.“ (A. Saint-Exupéry)</blockquote>Ich habe ein wenig darüber nachgedacht und bin für mich zu dem Schluss gekommen, dass eine Menge Wahrheit und Weisheit in diesem kurzen Satz steckt. Aber dann fing ich an, über die IT nachzudenken … Man sollte denken, dass wir in Zeiten, in denen wir mit mehr und mehr Komplexität konfrontiert werden, nach dieser Art von Perfektion streben sollten, indem wir alles entfernen, das wir nicht unbedingt zur Erreichung unseres Ziels benötigen. Zumindest denke ich das. Schaue ich mich aber um, dann sehe ich die meiste Zeit das genaue Gegenteil davon. Wir stapeln mehr und mehr Komplexität um uns herum auf, egal ob wir sie benötigen oder nicht. Um einfach einmal ein paar Beispiele zu nennen:<ul><li>Um Dinge lückenloser gestalten zu können, erfinden wir jeden Tag ausgefeilte Templates für alle und jedes, beginnend mit superpräzisen Anforderungs-Templates und endend mit Support Prozessen, deren Beschreibung schon hunderte oder gar tausende Seiten dick ist … Templates und Regeln, die zu verstehen schon Wochen in Anspruch nimmt und die sicherstellen, dass der eigentliche Inhalt wesentlich schwerer zu verstehen ist als er es vorher war … zumindest für die „normalen“ Menschen.</li><li>Um Unklarheiten zu vermeiden, erstellen wir Modelle, die eine ganze Wand benötigen um sie darzustellen. Kein Mensch versteht sie mehr in ihrer Gesamtheit, aber wir erstellen sie trotzdem. Und sollte das noch nicht ausreichen, erstellen wir zusätzlich Metamodelle und Meta-Metamodelle und stellen so sicher, dass wir die letzten paar Leute abhängen, die noch eine ungefähre Idee von dem Modell hatten.</li><li>Wir versuchen, Dinge einfacher erledigt zu bekommen, indem wir Produkte einsetzen, die so viele Features haben, dass wir höchstwahrscheinlich niemals mehr als 3% davon nutzen werden … und wir integrieren solche Produkte auch noch in unsere Anwendungslandschaften.</li><li>Um ein paar Tastendrücke zu sparen, packen wir so viel Zeug in unsere IDEs, dass niemand mehr weiß, was da alles im Hintergrund passiert und wir von der ganzen geschehenden „Magie“ regelmäßig ausgetrickst werden.</li><li>Und ebenfalls in unserer niemals endenden Suche nach einfacherer Erledigung von Aufgaben erzeugen und nutzen wir so viele Frameworks, wie wir irgendwie in eine Anwendung gepackt bekommen. Als Ergebnis sind wir ununterbrochen damit beschäftigt, die ganze Technologie zu verstehen und die daraus entstehenden Integrationsprobleme zu lösen und haben überhaupt keine Zeit mehr, uns mit der eigentlichen Aufgabenstellung der Anwendung auseinanderzusetzen – Ihr wisst, dieses „Fachzeugs“.</li><li>Mit all diesen Tools erzeugen wir dann Anwendung einer solchen Komplexität, dass niemand mehr wirklich versteht, was die Anwendung genau tut, weder die Anwender noch die armen Entwickler, die versuchen, irgendein ein neues Feature innerhalb dieses Code-Alptraums zu realisieren, ohne die ganze Anwendung kaputt zu machen.</li><li>Und nur, weil wir es können und irgendjemand aus dem Fachbereich denkt, das könnte irgendwann einmal nützlich sein, verbinden wir alles und jedes in unserer Anwendungslandschaft miteinander, egal ob es irgendeinen Geschäftsnutzen hat oder nicht und erzeugen so ein Netz aus Abhängigkeiten, das keiner mehr so recht versteht.</li></ul>Ich könnte noch stundenlang weitermachen, aber ich denke, Ihr wisst, was ich meine und Ihr könntet bestimmt wie aus der Pistole geschossen weitere Beispiele ergänzen. Wir schaffen es sehr oft, etwas eigentlich Einfaches in etwas Kompliziertes zu verwandeln, indem wir mehr und mehr Dinge hinzufügen, egal ob es dem Ziel dient oder nicht, bis es irgendwann komplexes Verhalten entwickelt, d.h. bis es unverständlich und unvorhersehbar in seinem Verhalten wird.Bei unseren Versuchen, mit den Grenzen unserer Gehirne umzugehen oder manchmal auch nur aufgrund unserer Faulheit oder Angst vor Entscheidungen wählen wir sehr oft die schlechteste Alternative: Wir fügen Komplexität hinzu anstatt sie zu entfernen.Wenn ich mir diesen Trend in der IT ansehe, dass alles immer komplexer und komplexer wird, denke ich mir, dass es an der Zeit ist, das Ruder herumzureißen. Anstatt über die wachsende Komplexität um uns herum zu jammern sollten wir versuchen, sie zu vermeiden, wo immer wir können. Um auch hier ein paar Beispiele zu nennen:<ul><li>Niemand zwingt uns, Dinge so formal wie Maschinen zu machen. Wir sind Menschen und wir sollten wie Menschen interagieren. Ja, wir machen Fehler (das ist Teil unserer Natur), aber wir machen insgesamt nicht weniger Fehler, wenn wir versuchen, uns wie Maschinen zu verhalten und so zu kommunizieren, d.h. immer formaler und formaler.</li><li>Niemand braucht Modelle, die keiner versteht. Zuallererst dient ein Modell der Kommunikation, der Weitergabe von Wissen; und wenn niemand das Modell versteht, gibt es nichts weiterzugeben. Im Zweifelsfall bevorzuge ich ein einfaches Modell, das ich jedem problemlos erklären kann, anstatt ein komplexes Modell zu benutzen, das ich niemandem nahebringen kann, egal wie akkurat es ist.</li><li>Niemand zwingt uns, jedes verfügbare Plugin in unserer IDE und jedes verfügbare Framework in unserer Anwendung zu verwenden. Vor vielen Jahren, als Design Patterns gerade „in“ waren, hatte ich einmal einen Kollegen, der uns eines Tages ganz stolz erzählte, dass er es geschafft hätte, alle Design Pattern des „Gang of Four“-Buches in seinen Code zu integrieren. Davon alarmiert hat sich der Rest des Teams seinen Code angeschaut. Das Ende vom Lied war, dass wir uns dazu entschlossen hatten, den gesamten Code wegzuwerfen, den der Kollege jemals für das Projekt geschrieben hatte und alles von Grund auf neu zu schreiben, weil der Code extrem fragil, voll von Fehlern und komplett unwartbar war. Das Gleiche gilt in der Regel für IDEs und Source Code, in denen zu viele Plugins, Frameworks oder was auch immer stecken.</li><li>Und müssen wir wirklich unbesehen jede einzelne Anforderung umsetzen, die irgendein Fachbereichsmitarbeiter formuliert? Ja, es ist das ganz spezielle Recht eines Fachbereichs, beliebige Dinge anzufordern, ohne sich Gedanken über die möglichen technischen Konsequenzen zu machen. Es ist nicht ihre Aufgabe, sich darüber Gedanken zu machen und meisten verfügen sie dafür auch nicht über das benötigte Wissen. Aber es ist unsere Aufgabe, mit ihnen darüber zu reden, ihnen die Konsequenzen aufzuzeigen (bitte in einer nicht-technischen Sprache), ihnen Alternativen aufzuzeigen und ihnen zu helfen, die bestmögliche Entscheidung zu treffen, indem man ihnen hilft, das ganze Bild zu sehen. Meistens werden sie dann die beste Alternative wählen, und sehr oft ist das eine Alternative, die wesentlich weniger komplex ist als die initiale Anforderung.</li></ul>Nun denn, dies ist keine „Schwarz oder Weiß“-Geschichte. Es gibt nicht „die“ Lösung für unser Problem und Vereinfachung bis zur Unbrauchbarkeit hilft auch nicht weiter. Aber ich denke, dass es an der Zeit ist, Komplexität zu vermeiden, wo immer wir sie nicht unbedingt benötigen, dass wir versuchen, uns zurück auf den Komplexitätslevel zu bewegen, den unsere Gehirne noch verarbeiten können. Oder, um dies mit einem weiteren Zitat zu beenden, das ich sehr mag:<blockquote>„Weniger ist mehr!“ (Mies v.d. Rohe)</blockquote>Wie ich bereits eingangs geschrieben habe: Nur ein Gedanke …

Perfektion in der IT – oder „weniger ist mehr“

Welche Geschichte hört man typischerweise über Agilität? Genau, meistens klingt es in etwa folgendermaßen: Agilität wurde von einigen frustrierten Entwicklern erfunden, die die Nase von nicht funktionierenden Prozessen voll hatten und von Dutzenden an Artefakten, die nicht die Bohne zum finalen Produkt beigetragen haben. Sie bekämpften all die schrecklichen V-Modelle, RUPs und wie auch immer diese schwerfälligen und überladenen Prozess-Monster hießen, indem sie einige schöne leichtgewichtige und agile Prinzipien erfanden, die sie dann Scrum, XP und so weiter nannten. Und seitdem haben sie nicht von ihrem heroischen Kampf abgelassen, die Entwickler von ihrer tonnenschweren Prozesslast zu befreien und die Agilität in diese Zentren der Rückständigkeit zu tragen, d.h. in das Management und die Fachbereiche, mit dem Ziel, eines Entwicklers Leben wieder lebenswert zu machen. Das ist doch die Geschichte, die wir so kennen, oder? Nun, hier bei codecentric kennen wir eine ganz andere Geschichte. Indem wir bereits seit längerer Zeit agil Software entwickeln, hatten wir schon einige Male die Gelegenheit, Teil des ersten agilen Projekts zu sein, das die jeweiligen Kunden umgesetzt haben. Meistens mussten die Kunden eine harte Terminvorgabe einhalten oder etwas ähnliches, das mit ihren normalen Prozessen nicht funktioniert hätte und sie hatten etwas über die Produktivitätserhöhung durch Agilität gehört. Nun, um die Geschichte abzukürzen: Zu irgendeinem Zeitpunkt waren wir dann mit dabei, um das entsprechende Projekt auf eine agile Art und Weise umzusetzen. Aber während der Umsetzung dieser Projekte machten wir dann Erfahrungen, die häufig ganz anders waren als die, die man auf Basis der „bekannten Geschichte“ erwartet hätte:Die Fachbereiche *liebten* die Agilität! Sie waren superglücklich über die kurzen Feedback-Zyklen und dass sie jemand hatten, der bereit war, wirklich mit ihnen zu kommunizieren, anstatt sie bei jedem Problem oder Anforderung immer nur aufzufordern, ein weiteres formales Dokument zu schreiben. Sie liebten es, wenn sie sehen konnten, wie ihre Vision in kurzen Iterationen heranwuchs und sie die Möglichkeit hatten, ihre eigenen Ideen dabei nachzujustieren. Sie fanden es sogar klasse, wenn sie bemerkten, dass sie mit ihren ursprünglichen Ideen auf dem Holzpfad waren, da sie die Möglichkeit hatten, diese Fehler einfach zu korrigieren und so das finale Produkt massiv verbessern konnten. Sie waren schlicht und ergreifend glücklich und hätten sie die Wahl gehabt, hätten sie nie wieder ein nicht-agiles Projekt gemacht.Das Management mochte Agilität auch recht gerne. Das Management der Fachseite mochte es, weil seine Fachbereiche es liebten und das IT-Management mochte es, weil sich das Management der Fachseite nicht mehr über zu späte Liefertermine, zu hohe Belastung für ihre Leute oder ähnliches beschwerte. Okay, es war nicht immer Liebe auf den ersten Blick beim IT-Management. Oftmals waren sie schon recht misstrauisch gegenüber dem ganzen agilen Kram, weil sie keine Ahnung hatten, was auf sie zukommen würde, wenn das ein richtig dicker Erfolg werden sollte. Manchmal wünschten sich diese Manager hinter vorgehaltener Hand, dass das Projekt scheitern würde, denn dann hätten sie den ganzen Fachbereichs-Leute gezeigt, dass dieser agile Kram auch nicht funktioniert und man deshalb bei dem altbekannten und etablierten Vorgehen bleiben kann.Und dann waren da noch die Entwickler, diese Leute aus den IT-Abteilungen des Kunden, die nach all den Jahren überglücklich sein sollten, dass sie endlich agil arbeiten durften, nicht wahr? Überraschenderweise waren die meisten von ihnen überhaupt nicht glücklich! Sie liebten ihre Prozesse und Artefakte sehr und die meiste Zeit drängten sie auf „mehr Formalismus“. Sie fühlten sich sicher in der Welt, die sie sich über die Jahre geschaffen hatten. Wann immer in den vergangenen Jahren etwas schiefgegangen ist, haben sie ein weiteres Stück Formalismus hinzugefügt, einen weiteren Prozessschritt, ein weiteres Artefakt. Sie hatten sich ihre eigene, sehr komfortable Welt innerhalb der Grenzen ihrer Prozesse geschaffen. Alles hatte seinen Platz und seine Ordnung. Alles war in ihren Prozessen beschrieben und Dinge, die nicht in den Prozessen beschrieben waren, waren schlicht und ergreifend verboten. Und das Beste daran: Niemand musste wirklich Verantwortung für irgendeinen Fehler übernehmen. Solange man sich an die Prozesse gehalten hat, hat man alles richtig gemacht und wenn etwas schiefgegangen ist, musste es der Fehler von jemand anderen sein. Also, tue einfach brav, was immer der Prozess Dir vorschreibt und Du bist sicher! Uff, was für eine Erleichterung!Man kann sich sicherlich vorstellen, dass Agilität mit seinem Fokus auf Ergebnissen anstatt Prozessen, mit eigenverantwortlichen Teams, die Verantwortung für das Ergebnis übernehmen, mit seinem Druck, mit Fachbereichsleuten zu sprechen, um Dinge zu klären anstatt einfach eine Spezifikation zurückzuweisen, dass dieses ganze seltsame agile Ding nicht wirklich das war, auf das diese Entwickler gewartet haben. Tatsächlich hat es ihnen richtig Angst gemacht! Sie fühlten sich verdammt unwohl damit. Sie wussten nicht, wie sie damit umgehen sollten und hatten immer dieses angsteinflößende Gefühl, dass sie schuld sein könnten, falls irgendetwas schief gehen würde. Nein, sie waren überhaupt nicht glücklich!Okay, ich gebe zu, dass ich es ein wenig überspitzt dargestellt habe, um den Punkt herauszuarbeiten, aber: Das ist kein spezifisches Problem irgendeines unserer Kunden; das ist ein Phänomen, das man quer durch die ganze Branche beobachten kann. Wir hatten eine Menge Unterhaltungen und Diskussionen mit vielen anderen agilen Protagonisten, die uns unsere Beobachtungen bestätigt haben. Und es ist nicht so, dass die beschriebenen Entwickler Agilität nicht mögen, weil sie „böse“ oder „ewiggestrig“ oder was auch immer wären. Sie fühlen sich schlicht unsicher. Sie haben sich über Jahre hinweg ihre wohlorganisierte Komfortzone aufgebaut oder sind in diese Komfortzone hineingedrängt worden und sie haben einfach noch nicht gelernt, mit dieser Agilität umzugehen.Und was ist die Moral von der Geschicht‘? Ja, es bedarf einer Menge Change Management, um Agilität erfolgreich in einem Unternehmen zu etablieren, aber … *aber* ziemlich häufig sind es nicht die Fachbereiche, die wir auf die Agilität vorbereiten müssen; es sind die IT-Abteilungen, die wir auf die Agilität vorbereiten müssen. Seltsam, oder? … 😉PS: Ich rede nicht über *alle* Entwickler. Ich weiß, dass viele von Euch agil denken und es lieben, in einer agilen Weise zu arbeiten. Aber auf der anderen Seite gibt es immer noch diese große Masse an Entwicklern, die nicht agil arbeiten wollen oder zumindest nicht wissen, wie sie sich dahin entwickeln sollen und ich denke, es sind diese Leute, auf die wir unsere Veränderungsbemühungen konzentrieren müssen, nicht auf die Fachbereiche.

Das Märchen vom agilen Entwickler

Mittlerweile tobt seit längerem eine hitzige Debatte über die Frage, ob Architektur und Design die gleiche Sache sind oder nicht. Die Vertreter der „Beides ist das Gleiche“-Fraktion sagen, dass Architektur eigentlich einfach nur die erste Phase des Designs ist, während die Gegner dieser These darauf beharren, dass Architektur und Design zwei vollständig verschiedene Aufgaben sind, die nur eine mehr oder minder unscharfe gemeinsame Berührungslinie teilen. Tja, wer von den beiden hat denn nun recht?Ich bin der Meinung, dass es sehr schwer ist herauszufinden, wer recht oder unrecht hat … tatsächlich glaube ich, dass das weitestgehend unmöglich ist. Sogar in unserer kleinen Firma finden wir keinen gemeinsamen Konsens darüber, was genau Architektur und was Design ist. Und wenn es schon nicht möglich ist, einen Konsens unter so wenigen Leuten zu erzeugen (selbst wenn einige davon recht starke Persönlichkeiten sind … 🙂 ), wie soll es dann möglich sein, einen Konsens in der gesamten IT Community zu erzeugen? Das ist höchstwahrscheinlich unmöglich.Deshalb versuche ich erst gar nicht, eine präzise Antwort auf die Frage zu finden. Stattdessen werde ich versuchen, das Thema von einem anderen Standpunkt aus zu betrachten. Zunächst: Warum ist es so schwer, die Frage zu beantworten? Ich denke, ein großer Teil des Problems liegt darin, dass es keine zufriedenstellende Definition für die beiden Ausdrücke gibt, weder für Architektur noch für Design. Wann immer sie mit einer anderen Person über Architektur oder Design reden, können Sie sich deshalb schon nahezu sicher sein, dass die andere Person über etwas anderes spricht als Sie.Es gibt *jede Menge* Definitionen, aber die meisten davon sind meines Erachtens entweder so spezifisch, dass sie das Thema nicht wirklich erfassen oder sie sind so vage, dass sie einem überhaupt nicht weiter helfen. Nur ein Beispiel: Robert Martin (der nebenbei gesagt eine Menge sehr schlauer Dinge gesagt und geschrieben hat) hat einmal gesagt „Bei Architektur geht es um die wichtigen Dinge; was auch immer das ist.“. Nun, das sagt alles und nichts. Bedeutet das, dass es bei Design um die unwichtigen Dinge geht? Wahrscheinlich nicht. Und, wenn Kaffee für die Entwickler ein sehr wichtiges Thema ist (was es fast immer ist), bedeutet das, dass es bei Architektur um Kaffee geht? Wahrscheinlich nicht. Wie Sie sehen können, bringt uns diese Definition nicht weiter.Ich verzichte darauf, andere Definitionen näher zu betrachten, weil ich denke, dass das nirgendwohin führt. Es wird nicht möglich sein, eine Definition für Architektur und Design zu finden, der alle zustimmen *und* die uns hilft, den Unterschied zwischen Architektur und Design herauszufinden. Insbesondere glaube ich, dass es nicht möglich sein wird, eine klare Trennlinie zwischen Architektur und Design zu finden, wo das eine endet und das andere beginnt. Jeder zieht die Linie an einer anderen Stelle und viele Leute haben wahrscheinlich eher eine Art unscharfer Wolke als eine klare Linie in ihrem Kopf. „Irgendwo innerhalb dieser Wolke endet Architektur und beginnt Design“ werden sie sagen.So weit, so gut. Aber es muss doch etwas geben, das uns weiterhilft. Oder zumindest sollte es etwas geben …Vielleicht hilft es, die Frage für einen Moment beiseite zu schieben. Im Laufe der Zeit habe ich herausgefunden, dass es zwei grundsätzliche Aufgaben gibt, aus denen diese ganze „Architektur-und-Design-Sache“ besteht (ohne zu versuchen, eine Trennlinie zu finden). Insgesamt geht es bei der Sache darum, alle existierenden Anforderungen in eine Lösung zu transformieren. (Und sollte jemand fragen, wo dabei die Codierung geblieben ist, möchte ich es demjenigen überlassen, die Trennlinie zwischen Design und Codierung zu finden; ich denke, dass ist eine ähnliche Fragestellung … 😉 ).Im ersten Teil dieser Transformation geht es darum, die ganzen Anforderungen zu verstehen (nicht nur die Anforderungen der Fachbereiche und Anwender, sondern auch die Anforderungen des Managements, der Projektleitung, des Entwicklungs-Teams, des Betriebs, der Systemplanung, der Sicherheitsabteilung, der Tester, und so weiter), die Anforderungen wirklich zu verstehen, sie auszubalancieren (es gibt immer widersprüchliche und inkonsistente Anforderungen über die verschiedenen Domänen und Stakeholder hinweg, mit denen man umgehen muss) und eine geeignete Lösungsidee für all diese ausbalancierten Anforderungen zu finden. Ich pflege diesen Teil der Arbeit „Alignment“ oder auch „Einklang“ zu nennen.Der zweite Teil der Transformation in eine funktionierende Lösung besteht daraus, die Lösungsidee in eine geeignete Struktur zu bringen, die Wartbarkeit und Änderbarkeit unterstützt und diese Struktur weiter und weiter bis herunter auf Code-Ebene zu verfeinern, ohne die zuvor beschriebenen Eigenschaften zu verlieren. Diesen Teil der Arbeit pflege ich „Strukturierung“ oder einfach nur „Struktur“ zu nennen.Nun, ist es wichtig, diese beiden Aufgaben zu unterscheiden? Ich denke, ja! Der Grund dafür ist, dass ich bemerkt habe, dass diese beiden Aufgaben sehr unterschiedliche Skills erfordern. Während Einklang viel mit Kommunikations- und Konflikt-Management-Skills zu tun hat, erfordert Struktur eher formale Stärken. Einklang erfordert auch ein recht breites Wissen über all die verschiedenen Anforderungsdomänen, während Struktur ein eher tiefes Wissen in der Lösungsdomäne erfordert. Als eine Konsequenz daraus findet man nur relativ wenige Personen, die beide Aufgaben mit der gleichen Stärke wahrnehmen können (oder wollen), und wenn man eine der beiden Aufgaben vernachlässigt, erhält man höchstwahrscheinlich kein befriedigendes Ergebnis.Okay, kommen wir zurück zu initialen Fragestellung. Helfen uns Einklang und Struktur, eine Trennlinie zu finden. Nun, ich denke, in gewisser Weise …Aus meiner Sicht ist Einklang auf jeden Fall Teil einer guten Architektur und Struktur ist auf jeden Fall Teil eines guten Designs. Man kann kein guter Architekt sein, ohne viel an Einklang zu arbeiten und man kann kein guter Designer sein, ohne viel an Struktur zu arbeiten. Wie viel Struktur zusätzlich in Architektur benötigt wird und wie viel Einklang in Design – ich denke, das ist gewissermaßen eine Geschmacksfrage und darauf wird es keine endgültige Antwort geben.Zusammenfassend kann ich auch nicht „die“ Antwort auf die initiale Fragestellung bieten. Aber ich weiß, wenn jemand über Architektur redet, ohne über Einklang zu reden, macht er etwas falsch und wenn jemand über Design redet, ohne über Struktur zu reden, macht er auch etwas falsch. Und das ist das Wichtigste aus meiner Sicht …PS: Ein dickes „Sorry“ an Robert Martin, weil ich ausgerechnet auf seiner Architektur-Definition herumgehackt habe. Wie ich bereits zuvor geschrieben habe, hat er eine Menge sehr schlauer Dinge gesagt und geschrieben, auch wenn ich nicht allen davon zustimme. Wenn Sie also die Gelegenheit haben sollten, etwas von ihm zu lesen oder einen Vortrag von ihm zu hören, dann tun Sie es! So, das sollte genug der Wiedergutmachung sein … 😉

Was ist der Unterschied zwischen Architektur und Design?

Gestern habe ich den Agile Day auf der JAX 2009 in Mainz besucht. Es würde nicht viel Sinn machen, wenn ich irgendwelche Bewertungen zu den Vorträgen abgeben würde, da ich einer der Speaker war … 😉 … aber ich möchte hier einige persönliche Eindrücke weitergeben, die ich gesammelt habe.Als erstes war ich sehr überrascht, wie viele Besucher der Agile Day hatte. Es waren mindestens 300 Leute, die den ganzen Tag über dageblieben sind. Das hat mir auf eindrucksvolle Weise gezeigt, wie sehr die Leute derzeit an dem Thema Agilität interessiert sind. Bei einer kurzen Umfrage hat etwa die Hälfte der Teilnehmer gesagt, dass sie einige agile Praktiken nutzen, aber nicht wirklich agil sind. Von der anderen Hälfte haben die meisten Leute gesagt, dass sie derzeit gar nichts in Sachen Agilität machen, aber an dem Thema interessiert sind. Nur eine Handvoll Leute hat angegeben, dass sie wirklich agile Software-Entwicklung betreiben und die meisten von ihnen waren Speaker. Mir hat das gezeigt, dass noch eine weite Reise im Bereich Agilität vor uns liegt, aber dass sich viele Leute mittlerweile auf den Weg gemacht haben, was ein gutes Zeichen ist.Die zweite für mich interessante Sache war eine Pecha Kucha Session. Stefan Roock hatte diese Session organisiert. Es waren 6 Speaker, von denen jeder eine Präsentation mit exakt 20 Folien gezeigt hat, von denen jede genau 20 Sekunden angezeigt wurde, zusammen 6 Minuten und 40 Sekunden. So sind die Regeln für eine Pecha Kucha Präsentation. Das war für mich ziemlich interessant, eine solche Session zu besuchen. In der Vergangenheit habe ich zwar schon darüber gelesen, aber gestern habe ich das erste Mal an einer solchen Session teilgenommen. Gefallen hat mir die Dauer der Präsentationen. Sie zwingt die Vortragenden, sich auf eine oder maximal zwei Ideen zu fokussieren und hält sie davon ab, langwierig über dutzende Dinge zu reden. Auf der anderen Seite fand ich das strikte Format recht ablenkend. Meistens sind die Folien ein wenig zu lang oder zu kurz für den vorgetragenen Inhalt des Speakers angezeigt worden. So mussten sie wechselweise oft warten oder sich sehr beeilen. Zusätzlich war ich stark abgelenkt, da ich irgendwie immer darauf gewartet habe, wann die nächste Folie angezeigt wird. Zusammenfassend war es eine recht interessante Erfahrung für mich, aber ich denke, dass dieses sehr strikte Format nur in wenigen Fällen wirklich hilfreich ist. Meiner Meinung nach sind kurze Sessions – 10 Minuten oder weniger – ein gutes Format, aber sie sollten nicht so strikt sein.Meinen letzten interessanten Eindruck hatte ich bei dem Speaker Panel am Ende. Es war nicht die Panel Diskussion an sich, davon habe ich mittlerweile eine Menge gesehen. Es war vielmehr die Tatsache, dass selbst die agilen Experten, die dort gestanden haben, recht unterschiedliche Ansichten und Auffassungen zu dem Thema Agilität hatten. Okay, auf der einen Seite ist das sicherlich ziemlich normal für viele Themengebiete, aber auf der anderen Seite ist es immer wieder recht überraschend, das live in einer Panel Diskussion zu erleben. Für mich bin ich zu dem Schluss gekommen, dass Agilität insgesamt ein noch nicht sehr gut erforschtes Gebiet ist und dass sich das Thema in den nächsten Jahren noch ziemlich weiterentwickeln wird.

JAX 2009 – Agile Day

Am 27. November hat unser drittes Meet the Experts stattgefunden, dieses Mal zum Thema Architektur. Trotz einer Reihe krankheitsbedingter Absagen (der beginnende Winter fordert seinen Tribut) haben wieder über 80 Interessierte ihren Weg nach Solingen gefunden.Das Motto war „Architektur in Zeiten von Agilität“ und die vier Speaker Dr. Gernot Starke, Stefan Zörner, Martin Lippert und Uwe Friedrichsen haben das Motto jeweils von einem bestimmten Standpunkt aus beleuchtet.Uwe Friedrichsen hat in dem ersten Vortrag des Tages auf die Wichtigkeit von Wartbarkeit und Weiterentwicklung als Architekturziel hingewiesen – insbesondere im Rahmen agiler Entwicklung.Martin Lippert hat in seinem folgenden Vortrag Modulsysteme betrachtet, welche wertvollen Beiträge sie zu flexiblen Systemen liefern können und welche Lehren wir daraus für unsere tägliche Architektur- und Designarbeit ziehen können.Nach der Mittagspause übernahm Stefan Zörner den undankbarsten Slot des Tages, bei dem die Teilnehmer gut gesättigt vom Mittagessen zuhören und stets latent einschlafgefährdet sind … 😉 . Stefan hat die Herausforderung aber souverän gemeistert und launig über den Sinn und Zweck von Architekturdokumentation erzählt und wieviel man davon in der Praxis benötigt.Er hat mit „Jar-Schlampe“ auch den Ausdruck des Tages geprägt (Umschreibung für eine Person, die sich bei der Nutzung vieler Frameworks und Bibliotheken gerne einmal einschleichenden Jar-Abhängigkeiten nicht mehr im Griff hat). Der Ausdruck hat neben spontanem Applaus so viel Eindruck hinterlassen, dass er zu einer gut besuchten Open Space Session am Abend mit dem Arbeitstitel <a href="http://blog.codecentric.de/2009/11/meet-the-experts-architektur-open-space-verwaltung-des-jar-chaos/">„Hilfe! Ich bin eine Jar-Schlampe! Was tun?“</a> geführt hat … 😉Abgeschlossen wurde der Vortragsteil des Meet the Experts von Dr. Gernot Starke, der auf Basis eines realen Beispiels erläutert hat, wie man Architekturentscheidungen in der Praxis trifft und – aufbauend auf dem Vortrag von Stefan Zörner – wie man diese geeignet festhalten kann. Er hat das auf Basis des <a href="http://www.arc42.de/">arc42-Templates</a> getan, was nicht wirklich verwunderlich ist, da er das Template ja maßgeblich selbst entwickelt hat … 😉Nach den Vorträgen ging es dann mit den <a href="http://de.wikipedia.org/wiki/Open_Space">Open Space</a> Sessions weiter. Als Neuerung gegenüber den früheren Meet the Experts wurde das Open Space Konzept schon direkt am Morgen vorgestellt und die Teilnehmer hatten den ganzen Tag Zeit, eigene Themen auf einer bereitgestellten Pinwand einzutragen. Nachdem die Möglichkeit bis zum Mittagessen noch nicht genutzt worden ist, hat die Mittagspause offenbar genügend Zeit und Raum zur Reflektion geboten, denn nach der Mittagspause füllte sich die Pinwand zusehends.Auf Basis der Einträge wurde dann in den einzelnen Open Space Sessions wieder kräftig diskutiert, überlegt, debattiert, argumentiert und natürlich auch zugehört, bevor man den Abend langsam bei einem guten Essen und angeregter Unterhaltung ausklingen ließ – nicht zu vergessen diverse harte Kickerturniere, bei denen sich nichts geschenkt wurde und einige heiße Gitarrengefechte bei Guitar Hero an der Wii … 😉Das Feedback der Teilnehmer während und nach der Veranstaltung war durchweg sehr positiv und wir freuen uns schon auf das nächste Meet the Experts. Einige Impressionen von der Veranstaltung sind in der folgenden Fotogallerie zu sehen.

meet the experts – architektur | 27. November 2009 – Eine Nachlese

Viele „klassische“ Projektmanager stehen Scrum sehr reserviert oder gar ablehnend gegenüber. Einer der Gründe dafür ist, dass sie sich in Scrum nicht wiederfinden. Es gibt keine Rolle „Projektmanager“ in Scrum. Im Rahmen unseres Meet the Experts – Agilität hatte ich die Gelegenheit, mich mit <a href="http://borisgloger.com/">Boris Gloger</a> ein wenig über das Thema zu unterhalten.Zuvor hatte Boris in einem OpenSpace einmal seine Sicht auf die Rolle Product Owner dargelegt. Bei dieser Darstellung ist mir klar geworden, dass die Rolle wesentlich mehr Elemente der klassischen Projektmanager-Rolle hat, als ich vorher wahrgenommen hatte. Ich hatte den Eindruck, dass die Aufgaben des klassischen Projektmanagers in gewisser Weise auf die Rollen Product Owner und Scrum Master verteilt worden sind. Mit diesem Eindruck habe ich Boris angesprochen und er hat mir diesen Eindruck bestätigt, genauer sogar noch etwas erweitert: Nach seiner Einschätzung ist die klassische Projektmanager-Rolle eigentlich überfrachtet und es gibt kaum eine Person, die diese Rolle in allen geforderten Aspekten gut ausfüllen kann. In Scrum hingegen ist die Rolle folgendermaßen aufgeteilt worden:<ul><li>Der Product Owner ist für die Richtung (die Vision), die inhaltliche Steuerung (Product Backlog) und das Budget verantwortlich. Er ist derjenige, der die Richtung vorgibt und inhaltlich treibt. Ebenso versucht er, das meiste aus dem ihm zur Verfügung stehenden Budget herauszuholen. Da – egal wie das Vorhaben im Detail aussieht – für die Features, die den höchsten Geschäftswert versprechen, im Verhältnis auch das meiste Budget zur Verfügung steht, ergibt sich durch das Streben, das meiste aus dem Budget herauszuholen, automatisch eine Priorisierung der Features nach Geschäftswert. Das klingt zwar nicht so richtig „edel und rein“, funktioniert aber in der Praxis erstaunlich gut … 😉</li><li>Das Team ist für die Planung der Umsetzung und die Einhaltung der Planung verantwortlich, d.h. den ganzen Detailplanungs- und Controlling-Anteil. Durch Sprint-Planung, Commitment auf die abgestimmten Sprint-Inhalte und Team-Verantwortung für die Umsetzung ist besser als in vielen klassisch aufgestellten Projekte gewährleistet, dass Erwartungshaltungen und Ergebnisse zueinander passen.</li><li>Der Scrum Master letztlich ist der „Kümmerer“: Er holt die Pizza, wenn es spät wird, räumt die Hindernisse aus dem Weg … ist aber auch derjenige, der dem Team über die Schulter schaut und es bei Bedarf an seine Commitments erinnert. Er stellt sicher, dass alle ihrer jeweiligen Rolle gerecht werden und sorgt für die bestmöglichen Arbeitsbedingungen.</li></ul>So verteilen sich die Aufgaben des klassischen Projektmanagers auf recht natürliche Weise auf die drei Scrum-Rollen. Wenn man nun als Projektmanager den Schritt Richtung Scrum wagen will (oder manchmal auch muss), so ist die Wahl einer Rolle eigentlich relativ einfach. Man sollte ehrlich in sich selber hereinhorchen, welchen Teil der Projektmanager-Rolle einem am besten liegt:<ul><li>Treibt man ein Projekt gerne inhaltlich und hat ein gutes Händchen für Budgets, dann sollte man die Product Owner-Rolle wählen.</li><li>Ist man hingegen eher der „Kümmerer“ und hat Spaß daran, dafür zu sorgen, dass ein Projekt rund läuft, dann sollte man am besten die Scrum Master Rolle wählen.</li><li>Wenn man aber nur Projektmanager geworden ist, weil man seinen früheren Entwicklerjob zu gut gemacht hat, darüber irgendwie in die Verantwortung hineingerutscht oder -gewachsen ist, dann sollte man am besten wieder Teil des Teams werden und Spaß daran haben, das Projekt durch seine eigene Leistung nach vorne zu bringen.</li></ul>Insgesamt macht diese Darstellung von Boris für mich viel Sinn. Vor allem glaube ich, dass durch diese Art der Rollenaufteilung die für den Erfolg eines Projektes kritischen Anteile der klassischer Projektmanager-Rolle gut auf die drei Scrum-Rollen verteilt sind und durch die Aufteilung umfassender gelebt werden können als wenn sie von nur einer Person wahrgenommen werden sollen.Einen Punkt hat Boris in seiner Darstellung allerdings nicht erwähnt: Es gibt eine häufig anzutreffende Art von klassischen Projektmanagern, die ich gerne „reine Projektmanager“ nenne. Diese zeichnen sich dadurch aus, dass sie auf rein formal Weise jede Art von Projekt managen, ohne genauere Kenntnis von den Projektinhalten zu haben. Sie beschränken sich darauf, Planungen (von wem auch immer erstellt) sowie Eskalationen zu verwalten und besitzen ausgeprägte Controlling-Kenntnisse, manchmal auch gute politische Kenntnisse. Sie machen in Anlehnung an das „Management by Spreadsheet“ (Management nur auf Basis von Kennzahlen unter Vernachlässigung der zugrundeliegenden Inhalte) ein „Project Management by Spreadsheet“ und manche dieser Projektmanager sind auch noch stolz darauf, dass sie nichts von den Inhalten verstehen, die sie verwalten („Ich kann jedes Projekt managen. Der Inhalt ist mir vollständig egal.“).Nun, für diesen Typus Projektmanager gibt es in Scrum tatsächlich keine Verwendung. Getreu des Lean-Prinzipies „Eliminate Waste!“ vermeidet Scrum nämlich jede Art von Ballast und fokussiert sich ausschließlich auf die Aspekte der Projektmanager-Rolle, die Mehrwert bieten, d.h. zum Projekterfolg beitragen. Und da echter Erfolg letztlich nur auf Basis der produzierten Inhalte beurteilt werden kann, wird eine Person, die nichts zu den Inhalten, zum eigentlich Ergebnis beitragen kann, in Scrum nicht benötigt. Es bleibt nur die Frage, ob solche Personen außerhalb von Scrum benötigt werden …

Der klassische Projektmanager in Scrum

Eine Reihe interessanter bis erschreckender Erfahrungen in meiner beruflichen Laufbahn im Zusammenhang mit dem Messen bzw. Nichtmesssen von „Qualität“ hatte mich dazu bewogen, einen Vorschlag für eine entsprechende Session bei der <a href="http://www.sea-con.de/">SEACON 2010</a> einzureichen, in der ich über meine Erfahrungen mit dem Thema sprechen wollte. Der Vorschlag wurde zu meiner Freude angenommen und in der Folge ging ans Vorbereiten der Session.Da die Veranstalter und der Fachbeirat der SEACON aktiv zu Formaten jenseits des klassischen Vortrags ermutigen, insbesondere zu interaktiven Formaten, die auch das Publikum einbeziehen, habe ich mich zu einem „Experiment“ entschlossen: Anstatt einen klassischen Folienvortrag vorzubereiten, wollte ich versuchen, zusammen mit dem Publikum ein „moderiertes Streitgespräch“ zu führen. So weit, so einfach, aber wie setzt man so etwas um? Gar nicht so einfach. Also überlegte ich hin und her, entwarf und variierte einige Ideen und landete schließlich bei einem relativ elaborierten Konzept mit Gruppenarbeit, abwechselndem Entwurf und Kurzdiskussion von Argumenten für die Pro- bzw. Contra-Position, gefolgt von einer Bewertung über das gesamte Publikum und Festhalten eines „Punktstandes“ am Ende der Session.Mit dem Konzept im Gepäck bin ich dann zur SEACON gefahren. Nun, das Ganze wäre wahrscheinlich fürchterlich in die Hose gegangen, wenn ich nicht glücklicherweise am Vortag schon eine Fishbowl zum Thema „Selbstorganisation von Teams“ moderiert hätte. Während der Fishbowl ist mir nämlich wieder aufgefallen, wie kurz 45 Minuten für eine Diskussion sind, gerade wenn es sich um ein potentiell kontroverses Diskussionsthema handelt. Mein ursprüngliches Konzept ging also gar nicht, war viel zu aufwändig, massive Vereinfachung war angesagt. Also zurück zum Zeichenbrett und neu nachgedacht! Das Ergebnis der Überlegungen war ein radikal vereinfachtes Konzept:<ul><li>Es gibt zwei Flipcharts, eines für Argumente, warum Qualität messbar ist und das andere für Argumente, warum nicht.</li><li>Ich biete eine „Reibungsfläche“ zum Entzünden der Diskussion, indem ich mich massiv auf einer der beiden Seiten positioniere und das mit einer Reihe von Argumente für diese Seite unterlege.</li><li>Danach geht es direkt in eine von mir moderierte Diskussion mit allen Teilnehmern und ich halte die wichtigsten Argumente auf den beiden Flipcharts fest.</li></ul>Mit diesem Minimalkonzept bin ich dann in die Session gestartet: Kurz in das Thema eingeführt, das Format erklärt und dann ging es auch schon zur „Reibungsfläche“. Ich habe mich auf die Seite „Qualität ist nicht messbar“ geschlagen und dafür die folgenden Argumente angeführt:<ul><li>Sobald man etwas misst, geht es um Zahlen und Mengen, d.h. um Quantität und nicht mehr um Qualität.</li><li>Qualität dient der Erfüllung von Bedürfnissen von Stakeholdern. Diese sind immer subjektiv und emotional und können nicht à priori auf objektiv messbare Zahlen heruntergebrochen werden. Oder anders herum ausgedrückt: Die Erfüllung à priori vereinbarter Messgrößen bedeutet noch lange nicht, dass ein Stakeholder dem fertigen System eine gute Qualität bescheinigt.</li><li>Das Problem der „metrischen Verzerrung“, basierend auf Arbeiten des Harvard-Professors Robert Austin: In Kurzform stellt jede Metrik in der Regel eine extreme Vereinfachung der eigentlich zu beobachtenden Größe dar, d.h. es werden jede Menge Informationen eliminiert, die diese Größe charakterisieren. Das Problem, das sich daraus ergibt ist, dass man nur noch die (stark trivialisierende) Messgröße optimiert und nicht mehr die (komplexe) zugrundliegende Größe, in diesem Fall „Qualität“.</li><li>Ein sich daraus ergebendes Risiko ist, dass man sich durch die Metriken in falscher Sicherheit wiegt und im schlimmsten Fall komplett falsche Impulse liefert, d.h. das System in die komplett falsche Richtung „optimiert“, weil man nur die vereinfachte Messgröße beobachtet und nicht mehr die eigentlich zu optimierende, komplexe Größe.</li><li>Letztlich bergen Metriken das Risiko, zum Selbstzweck zu verkommen, insbesondere bei Personen, die nicht genügend Fachwissen über das Messobjekt haben, um die Messgröße inhaltlich hinterfragen zu können. Wer hat noch nicht erlebt, dass ausgehend von einer guten Idee irgendwann nur noch Reports und Excelsheets „optimiert“ wurden anstatt das zugrundliegende Produkt?</li></ul>Nach der Präsentation der bewusst sehr einseitig gehalten „Reibungsfläche“ habe ich sicherheitshalber einmal nachgefragt, wie die Verteilung der „Befürworter“ und „Gegner“ von Qualitätsmessungen im Publikum ist. Wären nämlich fast alle oder womöglich sogar alle Teilnehmer einer Meinung gewesen, hätte die Diskussion ziemlich langweilig werden können. Glücklicherweise war die Verteilung sehr ausgewogen und die Diskussion konnte beginnen. Einige Teilnehmer wollten meine Argumente erfreulicherweise nicht einfach unkommentiert im Raum stehen lassen und so entspann sich eine angeregte Diskussion. Dabei habe ich versucht, die wichtigsten Argumente für die beiden Standpunkte an den beiden Flipcharts festzuhalten (siehe die beiden Bilder).<div><a href="https://media.graphassets.com/TfyyykA1TtnybJyJkBXU"><img title="29062010370" src="https://media.graphassets.com/TfyyykA1TtnybJyJkBXU" alt="Flipchart: Qualitaet ist nicht messbar, weil ..." width="300" height="225" /></a> Flipchart: Qualitaet ist nicht messbar, weil ...</div><div><a href="https://media.graphassets.com/o6kbeYX2TOeZGnZZhLQc"><img loading="lazy" title="29062010368" src="https://media.graphassets.com/o6kbeYX2TOeZGnZZhLQc" alt="Flipchart: Qualitaet ist messbar, weil ..." width="300" height="225" /></a> Flipchart: Qualitaet ist nicht messbar, weil ...</div>Nicht jeder Diskussionsbeitrag führte zu einem Punkt am Flipchart:<ul><li>Einige Teilnehmer hatten bereits genannte Argumente weiter untermauert und bestärkt.</li><li>Einige Teilnehmer wollten sich nicht auf eine der beiden Positionen limitieren, sondern haben eine Position „in der Mitte“ eingenommen.</li><li>Einige Teilnehmer warfen außerdem einen Blick über die Grenzen der Fragestellung hinaus.</li></ul>So wurde zum Beispiel die Frage gestellt, wie man Qualität überhaupt definiert, weil dies die Diskussion über die Messbarkeit maßgeblich beeinflussen würde. Andere Teilnehmer haben die Frage gestellt, wie man denn Qualität sicherstellen könne, wenn man sie nicht misst. Dazu gab es die sehr interessante Aussage, dass man Qualität gut „fühlen“ könne. Man müsse Qualität gar nicht messen, weil man über das Feedback der Stakeholder sehr schnell und wesentlich besser eine Rückmeldung über die Qualität des betroffenen Systems bekäme und in einem konkreten Projekt hätte das auch sehr gut funktioniert.Nach diesem letzten Beitrag musste ich die Diskussion dann leider abbrechen, weil wir die vorgesehene Zeit bereits um fünf Minuten überzogen hatten. Es gab noch eine Menge Wortmeldungen, die ich sehr zu meinem Bedauern nicht mehr berücksichtigen konnte und ich denke, wir hätten noch locker eine halbe Stunde oder Stunde weiter diskutieren können. Ein klares Fazit gab es erwartungsgemäß nicht, auch kein Patentrezept für den Umgang mit Metriken im Zusammenhang mit Qualität. Aber es gab eine Menge guter Ideen und interessanter Sichtweisen und Anregungen, die dem ein oder anderen vielleicht einen neuen Denkanstoß zu diesem nicht einfachen Thema gegeben hat … und das ist schon eine ganze Menge für die kurze Zeit.Trotzdem hier ein Versuch, die Sichtweisen der 45 Minuten zusammenzufassen:<ul><li>Es ist möglich, aber sehr schwer, geeignete Kriterien zu finden, die einen unterstützen, Qualität zu beurteilen.</li><li>Es ist nicht möglich, allgemeingültig „richtige“ Kriterien festzulegen. Man muss dies immer situativ bezogen auf die Aufgabenstellung und das Ziel tun.</li><li>Man muss sich stets der „metrischen Verzerrung“ bewusst sein und der Tatsache, dass jede Metrik auch eine „Schattenseite“ besitzt.</li><li>Entsprechend muss man die gemessenen Zahlen immer kritisch interpretieren und darauf achten, dass sie nicht zum Selbstzweck werden.</li><li>Insbesondere darf man sich durch die Metriken nicht in falscher Sicherheit wiegen. Man muss sich stets der Tatsache bewusst sein, dass Metriken immer nur einen (häufig kleinen und teilweise auch verzerrten) Teil des Gesamtbildes darstellen.</li><li>Selbst wenn einem Metriken vielleicht nicht helfen, Qualität zweifelsfrei nachzuweisen, so können sie doch zumindest sehr gut helfen, das Fehlen von Qualität festzustellen.</li><li>Gar nichts tun ist auch keine Lösung. Man muss sich auf jeden Fall explizit um Qualität kümmern, ob nun mit Hilfe von Metriken oder mit Hilfe anderer Mittel.</li></ul>Wie man sieht, hat sich trotz des bewusst polarisierenden Konzepts des Workshops ein recht differenziertes Gesamtbild ergeben, was ganz klar ein Verdienst der hohen (nicht gemessenen 😉 ) Qualität der Teilnehmerbeiträge war. Apropos „Teilnehmer“: In Summe hat mir die Session sehr gut gefallen. Für mich war das Format ja ein gewisses Risiko, da ich mich auf die Mitarbeit der Teilnehmer verlassen musste und die Qualität (oder Nichtqualität) der Session nicht mehr selbst in der Hand hatte. Die Teilnehmer sind auf das Diskussionsangebot aber hervorragend eingegangen, besser als ich es mir je erhofft hätte. Dafür auch an dieser Stelle noch einmal ein herzliches Dankeschön von mir an alle Teilnehmer, insbesondere auch an die, die aufgrund der Menge der Beiträge in der Kürze der Zeit nicht zu Wort gekommen sind. Mit so einem tollen Publikum mache ich gerne noch einmal eine solche Session!Ein kurzer Disclaimer zum Schluss: Ich habe versucht, die Session und die darin getätigten Aussagen nach bestem Wissen zusammenzufassen. Da das aber aus dem Kopf heraus passiert ist, ist es natürlich möglich, dass ich hier etwas falsch wiedergegeben haben. Das ist dann keine böse Absicht von mir und ich bitte die Teilnehmer, das zu korrigieren, z.B. in Form eines Kommentars. Danke!

Ist Qualität messbar? – Ein „moderiertes Streitgespräch“ auf der SEACON 2010

Inline-Kommentare im Code sind „böse“ und jeder, der heutzutage noch immer Inline-Kommentare verwendet, ist ein sehr, sehr schlechter Entwickler und man sollte ihm dringend seine Lizenz entziehen. Das ist es, was allgemeiner Konsens in der Entwicklergemeinde zu sein scheint … oder zumindest innerhalb des Teils der Entwicklergemeinde, der sich „Up to Date“ wähnt.Schön, aber ich behaupte, dass wir mehr Inline-Kommentare benötigen. Ja, was ist denn los mit mir? Habe ich jetzt endgültig den Verstand verloren?Nun, während die Beantwortung der letzten Frage eine durchaus diffizile Aufgabe sein könnte … 😉 … meine Gedanken bzgl. der Inline-Kommentare sind relativ einfach:Wenn Du irgendeine Art von Lösung verstehen willst, etwa wenn Du ein neues Feature in einer bestehenden, Dir bislang aber noch unbekannten Code-Basis implementierten sollst, dann musst Du mindestens die Antworten zu den folgenden drei essentiellen Fragen kennen:<ul><li>Was?</li><li>Wie?</li><li>Warum</li></ul>Wie bekommt man diese drei Fragen beantwortet, wenn der ursprüngliche Entwickler nicht mehr verfügbar ist?<ul><li>Das „Wie“ ist einfach. Das ist der Code an sich. Aus diesem Grund macht es auch definitiv Sinn, Code so verständlich wie möglich zu schreiben, damit jeder andere das „Wie“ so einfach wie möglich verstehen kann.</li><li>Das „Was“ ist normalerweise die Domäne der Klassen-/Methoden-/Funktions-/… Header. Der Kommentar-Header beschreibt, „Was“ das folgende Stück Software tun soll. In Java ist das die Domäne von Javadoc, andere Programmiersprachen haben ihre eigenen Mittel oder Konventionen dafür.</li><li>Aber wo bleibt das „Warum“? Der Code an sich kann diese Frage aus naheliegenden Gründen nicht beantworten und Javadoc, etc. sind auch nicht dafür gedacht. Diese sollten sich auf das „Was“ fokussieren. Man könnte das „Warum“ jetzt in ein separates Artefakt packen, ein Extradokument wie etwa ein Design-Dokument. Das ist aber recht umständlich. Außerdem ist die Wahrscheinlichkeit sehr hoch, dass irgendwelche Änderungen, Refactorings, etc. im Code nicht ihren Weg in das Dokument finden würden, so dass es sehr schnell veralten würde. Deshalb ist es eine wesentlich bessere Idee, die Antworten zu den „Warum“-Fragen genau an die Stelle zu setzen, an der Du den Effekt der zugehörigen Entscheidung unmittelbar sehen kannst, nämlich direkt neben den Code, der einem zeigt, „Wie“ die Entscheidung der „Warum“-Frage implementiert worden ist.</li></ul>Dafür kommen einem Inline-Kommentare gerade zupass. sie bieten ein perfektes Mittel, um die Begründung für bestimmte Entscheidungen zu liefern, die man im Code findet. Wann immer Du denkst „Warum um Himmels Willen hat er oder sie dieses Stück Code auf diese Weise implementiert?“, wäre es doch wunderbar, einen Inline-Kommentar direkt neben dem Stück Code zu finden, der einem diese Frage beantwortet, oder? Heutzutage sucht man aber leider meist vergeblich nach diesen Antworten. Stattdessen muss man versuchen, den ursprünglichen Entwickler zu fragen, sollte er noch greifbar sein und sich auch noch an diese Entscheidung erinnern oder das Wissen ist verloren und man muss den Grund erraten.Aus diesen Gründen ist die Domäne von Inline-Kommentaren für mich die Beantwortung von „Warum“-Fragen und aus meiner Erfahrung ist das Verstehen des „Warum“ aus einer Wartbarkeits- und Änderbarkeitsperspektive (hier kommt der Architekt in mir wieder durch … 😉 ) wesentlich wichtiger als das Verstehen des „Was“ … und das „Wie“ steht sowieso im Source Code.Darum sage ich, dass wir mehr Inline-Kommentare benötigen<ul><li>nicht, um das „Was“ zu erklären, das ist die Domäne der Header-Kommentare</li><li>nicht, um das „Wie“ zu erklären, das sollte der Code an sich beantworten</li><li>sondern um diese „Warum“-Fragen zu beantworten, um die Begründungen für Design- und Implementierungsentscheidungen zu liefern, die man meistens vergeblich sucht.</li></ul>Und deshalb ist meine abschließende Empfehlung:Schmeißt die Regel<blockquote>„Du darfst keine Inline-Kommentare verwenden“</blockquote>aus Euren Coding Standards und ersetzt sie durch<blockquote>„Du sollst Inline-Kommentare ausschließlich verwenden, (nicht-offensichtliche) Design- und Implementierungsentscheidungen zu erklären („Warum“-Fragen) … und vergiss nicht, sie dafür auch zu verwenden!“</blockquote>

Wir brauchen mehr Inline-Kommentare!

Auf der <a href="http://jax.de/wjax2010/">WJAX 2010</a> habe ich einen Vortrag mit dem Titel „Der agile Machiavelli oder wie kippe ich ein agiles Projekt?“ gehalten. Da meine Folien sehr minimalistisch waren und man auch nach fast 10 Jahren agilem Manifest noch überraschend viele „Worst Practices“ in agilen Projekten beobachten kann, hatte ich den Zuhörern versprochen, dass ich das Thema hier im codecentric-Blog noch einmal aufnehmen wollte.Okay, es hat etwas länger gedauert, bis ich jetzt endlich dazu gekommen bin, damit zu beginnen und anstatt mich mit dem Schnee oder dem Weihnachtsstress herauszureden, gibt es dafür erst einmal ein dickes „Sorry!“ von mir an alle, die schon länger darauf gewartet haben und vielleicht bereits mehrfach hier vorbeigeschaut haben.In dem Vortrag ging es um „Agile Worst Practices“. Eine Worst Practice ist das Gegenteil einer Best Practice, d.h. es geht um Praktiken, die sich im agilen Umfeld als schlecht erwiesen haben. Das reicht von Praktiken, die die Produktivität ungünstig beeinflussen bis hin zu absoluten „Killern“, die eine sinnvolle agile Arbeit komplett unmöglich machen.Eine solche Worst Practice kann man jetzt unter verschiedenen Gesichtspunkten betrachten und verwenden. Man kann sie einfach zu verstehen versuchen und aufpassen, dass man sie nicht in seinen eigenen Projekten verwendet. Bei einigen dieser Practices ist es nämlich so, dass sie gar nicht so offensichtlich schlecht sind, sondern dass sich ihr destruktives Potential erst bei genauerem Hinsehen offenbart.Eine andere Verwendungsweise ist – wie ironisch im Untertitel geschrieben – die Anwendung der Practices mit dem Ziel, das jeweilige Projekt zu kippen. Um jetzt evtl. Missverständnissen vorzubeugen: Das mag zwar aus persönlichen oder machtpolitischen Gründen in bestimmten Situationen opportun erscheinen, aber trotz des gewählten Untertitels war der Vortrag natürlich kein Aufruf zu solch einem aus rein egoistischen Motiven getriebenen Vorgehen.Umgekehrt kann man sich aber auch überlegen, was man gegen eine solche Practice unternimmt, wenn man mit ihr in einem Projekt konfrontiert wird, d.h. wie man sie „unschädlich“ macht.Diese verschiedenen Betrachtungs- und Verwendungsweisen spiegeln sich in der Beschreibung der einzelnen Worst Practices wider. Zunächst einmal werde ich die Practice möglichst einprägsam benennen und ihre Funktionsweise beschreiben. Danach werde ich die Konsequenzen darstellen, d.h. welche Wirkung hat die Practice. Abgeschlossen wird die Beschreibung von möglichen Maßnahmen, um der Practice entgegenzuwirken.Alle Practices entstammen übrigens realen Projekterfahrungen. Ich hatte unter meinen Kollegen – allesamt mit reichlich agiler Projekterfahrung ausgestattet – einmal herumgefragt, welche Worst Practices ihnen denn im Laufe ihrer vielfältigen Projekte begegnet seien und es sprudelte nur so. Auf diese Weise entstand eine Liste von ca. 80 Worst Practices und auch nach Bereinigung der Redundanzen blieb eine beindruckende Sammlung übrig. Das zeigt aus meiner Sicht, wie wichtig und praxisnah das Thema immer noch ist.Natürlich ist diese Sammlung nicht vollständig oder deckt das gesamte Themenspektrum gleichmäßig ab, aber das ist auch gar nicht mein Ziel. Mein Ziel ist es, eine Menge lebensnahe, dem realen Projektgeschäft entstammende Worst Practices vorzustellen und so dafür zu sensibilisieren. Es gibt auch weitere Quellen, die sich dieses Themas annehmen. Ein paar Referenzen werde ich noch am Ende der Blog-Serie nennen.Um die ganzen hier beschriebenen Practices ein wenig zu strukturieren, sind sie – soweit möglich – nach Rollen geordnet. Primär werden hier die Scrum Rollen verwendet, d.h. Product Owner, Scrum Master und Team, aber auch eine Reihe umgebender Rollen wie Kunde, Manager, User sowie der Agilitäts-Berater bzw. Coach.So, und damit das jetzt nicht nur ein „Teaser Post“ wird, hier noch die erste Worst Practice. Ich freue mich auf Eure Kommentare, Anmerkungen und Ergänzungen, aber auch über Eure eigenen Erfahrungen.Beginnen wir mit den Team Practices: Bevor wir mit dem ausgestreckten Finger auf andere Leute zeigen, ist es zunächst sicherlich sinnvoll zu schauen, welche Worst Practices uns als Team-Mitgliedern zur Verfügung stehen. Viele dieser Practices sind dabei nicht exklusiv auf das Team beschränkt, sondern können auch von anderen Personen angewendet werden.Team Worst Practice #1: Mein Wissen gehört mirBeschreibung: Anstatt mein Wissen mit anderen Team-Mitgliedern zu teilen, halte ich es sorgfältig unter Verschluss. Wenn es Aufgaben auf meinem Spezialgebiet gibt, schnappe ich sie mir sofort und passe dabei auf, dass kein anderer versteht, wie ich das gelöst habe. Meine Position im Unternehmen festige ich weiter, indem ich geeignete neue Themen annektiere, bei denen sich noch niemand auskennt und so weitere Wissensmonopole auf mir vereine. Bei all dem Konkurrenzdruck im Unternehmen und der Gefahr durch Outsourcing/Offshoring muss ich ja sehen, wo ich bleibe und meinen Arbeitsplatz sichern.Konsequenz: Es entsteht eine Wissensinsel. Eine vernünftige Selbstorganisation ist nicht mehr möglich und auch die freie Priorisierung von Tasks ist nicht mehr möglich. Alles muss rund um die „kritische Ressource“ organisiert werden und ist der Mitarbeiter mal nicht da, ist häufig gleich die ganze Iteration gefährdet. Typischerweise ist der Mitarbeiter chronisch überbucht und wird aufgrund seines Spezialwissens zwischen mehreren Projekten aufgeteilt, was eine vernünftige Team-Arbeit in den einzelnen Projekten deutlich erschwert.Maßnahmen: Wissensinseln sind schwer zu bekämpfen, weil sie zunächst einmal für alle bequem sind. Man hat sowieso mehr als genug zu tun und ist froh, dass da jemand ist, der sich um Aufgabe X kümmern kann und man sich selber nicht auch noch um das (neue) Thema kümmern muss. Die damit verbundenen Probleme versteht man meistens erst, wenn es zu spät ist.Deshalb ist es wichtig, die Probleme mit Wissensinseln frühzeitig zu erklären (Verständnis für das Problem schaffen). Hier ist insbesondere der Scrum Master gefragt, für Transparenz zu sorgen und die möglichen Konsequenzen aufzuzeigen. Neben der Transparenz sollte er auch noch darauf hinwirken, dass Maßnahmen ergriffen werden, die solchen Wissensinseln entgegenwirken. Solche Maßnahmen könnten z.B. sein:<ul><li>Aufstellen einer Team-Regel, dass jedes Thema von mindestens 2, besser 3 Personen verstanden sein muss.</li><li>Pair Programming für kritische Themen zur Regel machen.</li><li>Wenn der Scrum Master eine Wissensinsel bemerkt, auf die das Team nicht reagiert, kann er von den Team-Mitgliedern Maßnahmen einfordern, wie sie einen evtl. Ausfall von dem Mitarbeiter kompensieren wollen. Dabei kann er sie auf ihr Sprint Commitment erinnern (klingt erst einmal nicht nett, hilft aber sehr gut, die inhärente „Es wird schon gutgehen“-Attitüde zu durchbrechen).</li></ul>Das einfach mal als ein paar Ideen. Wissensinseln sind ein sehr schwieriges Thema, auch in traditionellen Projekten und es gibt keine echten Patentrezepte. Hat man sie aber erst einmal als Problem erkannt und dies für alle Beteiligten transparent gemacht, ist der erste wichtige Schritt getan.So, dieses war der erste Streich … den nächsten Post in dieser Serie findet Ihr <a href="http://blog.codecentric.de/2011/01/agile-worst-practices-2/">hier</a> .PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind immer herzlich willkommen!

Agile Worst Practices – Teil 1

So, nach einer kleinen Pause über die Feiertage und den Jahreswechsel begrüße ich Euch zum nächsten Post aus der Serie Agile Worst Practices, die ich mit <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">diesem Post</a> begonnen hatte. Wir bleiben bei den Worst Practices für das Team:Team Worst Practice #2: Wer zu spät kommt, gewinntBeschreibung: Und noch ein Meeting. Und das jeden Tag! Als wenn ich nicht etwas Besseres zu tun hätte! Na gut, ich komme dann halt, auch wenn es nichts bringt, aber dadurch lasse ich mich nicht bei den wichtigeren Dingen, wie z.B. dem Entwickeln stören. Und wenn ich dann erst fünf Minuten später komme, dann ist das halt so. Und Zeit für eine neue Tasse Kaffee vorher muss sowieso sein, egal ob es dem Scrum Master nun passt oder nicht.Konsequenz: Das Daily Scrum ist, wie es der Namen schon sagt, ein Meeting, das jeden Tag stattfindet und die Akzeptanz eines täglich stattfindenden Meetings steht und fällt extrem mit der Dauer des Meetings. Dabei kommt es auf Minuten an. 10-15 Minuten werden in der Regel problemlos akzeptiert, 20 Minuten werden schon kritisch und spätestens bei einer durchschnittlichen Dauer von 30 Minuten ist es mit der Akzeptanz ganz schnell vorbei.Wenn die pünktlichen Teilnehmer durch das regelmäßige Warten auf einen chronischen Zuspätkommer dann immer erst 5-10 Minuten warten müssen, bevor das Meeting anfängt, dann dauert das Meeting für sie entsprechend länger, d.h. in der Regel zu lang. Zusätzlich ist ein tagtägliches Warten sehr entnervend, allein schon unter dem Gesichtspunkt, dass – wenn nicht dagegen gesteuert wird – die pünktlichen Team-Mitglieder durch das erzwungene Warten „bestraft“ werden, während der Zuspätkommer in seiner Handlungsweise bestätigt wird, da er als einziger nicht warten muss.Die Konsequenz ist eine wachsende Unzufriedenheit bei den anderen Team-Mitgliedern für das Daily Scrum, die sich zur Unlust oder im Extremfall bis zur vollständigen Ablehnung auswachsen kann.Maßnahmen: Wie bereits geschrieben ist ein regelmäßiges Zuspätkommen beim Daily Scrum absolut keine Option. Entsprechend ist es Aufgabe des Scrum Masters, da aktiv gegenzusteuern. Er muss auf einen pünktlichen Beginn bestehen und regelmäßige Zuspätkommer entsprechend verwarnen. Auch das Team darf den Zuspätkommer in die Pflicht nehmen, schließlich ist es auch ein Zeichen mangelnden (positiven) Respekts gegenüber den Kollegen, wenn man sie regelmäßig warten lässt.Eine weitere wichtige Maßnahme ist, pünktlich zu beginnen, zum einen, um der sinkenden Akzeptanz des Meetings entgegenzuwirken, zum anderen aber auch rein psychologisch, denn so werden die Pünktlichen für ihre Pünktlichkeit „belohnt“, während die Zuspätkommer das Nachsehen haben.Sollte der Zuspätkommer überhaupt kein Einsehen zeigen, dann empfiehlt sich als Ultima Ratio darüber nachzudenken, die Person aus dem Team zu entfernen, da sie in dem Fall nüchtern betrachtet für ein agiles Team eigentlich nicht tragbar ist … aber so pathologische Fälle sollten hoffentlich nur selten vorkommen.Zum Abschluss des Posts noch ein wenig Verlinkung:<ul><li>Den Link zum ersten Post dieser Serie findet Ihr <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">hier</a> .</li><li>Den Link zum nächsten Post dieser Serie findet Ihr <a href="http://blog.codecentric.de/2011/02/agile-worst-practices-3/">hier</a> .</li></ul>PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind wie immer herzlich willkommen!

Agile Worst Practices – Teil 2

Willkommen zum nächsten Post aus der Serie Agile Worst Practices, die ich mit <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">diesem Post</a> begonnen hatte. Wir bleiben bei den Worst Practices für das Team und greifen ein häufiges Missverständnis im agilen Umfeld auf:Team Worst Practice #3: Alles ist selbstorganisiertBeschreibung: Wir als Team sind ja selbstorganisiert. Uns hat keiner etwas vorzuschreiben und wir wissen selber am besten, was für uns gut ist. Feste Regeln gelten für uns nicht, sondern wir klären basisdemokratisch, was wir unter agilem Vorgehen verstehen und wie wir das machen wollen. Auch Scrum ist ja eher so eine Art Empfehlung als eine Methode und wir diskutieren ausführlich in jedem Sprint, wie wir das machen wollen. Schließlich sind die Retrospektiven doch dafür da, dass wir unsere Methode nach jedem Sprint (und bei Bedarf auch während des Sprints) ändern können, oder?Konsequenz: Das Konzept der Selbstorganisation ist vielfach falsch verstanden worden und wird leider auch bis heute noch vielfach falsch vermittelt. Zunächst einmal bedeutet Selbstorganisation nicht komplette Anarchie und Team Empowerment bedeutet auch nicht Basisdemokratie. Es gibt sehr wohl feste Regeln und Ziele, die von außen vorgegeben werden und die ein Team erfüllen muss. Die Selbstorganisation findet innerhalb dieser Regeln und Ziele statt. Die Regeln und Ziele hingegen sind fest und können vom Team nicht nach Belieben umdefiniert werden.Ein einmal gewähltes Vorgehen wie z.B. Scrum gehört zu den festen Regeln und kann (und sollte auch) nicht nach Belieben geändert werden. Es ist Aufgabe des Scrum Masters, dafür zu sorgen, dass die entsprechenden Regeln eingehalten werden. Tut man das nicht, hat man das große Problem, dass die initiale Lernphase fehlt, in der man versteht, welche Wirkungen die verschiedenen Regeln von Scrum haben. Nicht ad hoc offensichtliche Auswirkungen von Regeln werden nicht verstanden, sie werden mangels Verständnis in der Regel frühzeitig verworfen und es werden typischerweise bequemere, aber auch suboptimale Alternativen eingesetzt.In Summe führt das Vorgehen typischerweise zu geringerer Produktivität, einmal weil viel Zeit und Energie für die Diskussionen über das Vorgehen verbraucht werden und andererseits, weil das Vorgehen weniger gut ist. Zusätzlich birgt das Vorgehen die Gefahr, dass sich das Verfahren nicht stabilisiert, sondern zu einem dauerhaften Ausprobieren führt.Maßnahmen: Hier ist insbesondere der Scrum Master gefragt. Er muss die nicht diskutierbaren Anteile des Vorgehens klar kommunizieren und die Einhaltung forcieren. Bei den ergänzenden Anteilen (z.B. das verwendete Schätzverfahren) muss er auch dafür sorgen, dass sich zunächst auf ein Verfahren geeinigt wird und das auch eine Zeitlang ohne Diskussion gelebt wird. Zusätzlich sollte er das Team auf eine Lernphase ohne Diskussion der Vorgehensweise einschwören.Für ein erstes Scrum-Projekt sind dafür mindestens 6 Sprints, eher noch einige Sprints mehr zu empfehlen. Nach dieser Lernphase hat das Team dann genug Erfahrung mit der Methode sammeln können, um qualifiziert beurteilen zu können, an welchen Stellen Optimierungen möglich und sinnvoll sind. Aber auch dann noch muss der Scrum Master darauf achten, dass keine von außen vorgegebenen Regeln und Ziele angefasst werden, denn diese sind wie bereits geschrieben fest bzw. müssen in Fällen von Problemen in Form von Impediments angegangen werden und können nicht einfach eigenmächtig vom Team angepasst werden.Zum Abschluss des Posts wie immer noch ein wenig Verlinkung:<ul><li>Den Link zum ersten Post dieser Serie findet Ihr <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">hier</a> .</li><li>Den Link zum nächsten Post dieser Serie findet Ihr <a href="http://blog.codecentric.de/2011/02/agile-worst-practices-4/">hier</a> .</li></ul>PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind wie immer herzlich willkommen!

Agile Worst Practices – Teil 3

Willkommen zum vierten Post aus der Serie Agile Worst Practices, die ich mit <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">diesem Post</a> begonnen hatte. Wir bleiben bei den Worst Practices für das Team und greifen ein Problem auf, das es auch außerhalb der agilen Welt gibt, im agilen Kontext aber noch größeres Schadenspotential entwickelt:Team Worst Practice #4: Bloß keinen KundenkontaktBeschreibung: Diese Worst Practice gibt es in verschiedenen Ausprägungen. Allen gleich ist die Grundeinstellung: „Ich weiß eh am besten, was der Kunde braucht“. Entsprechend ist es ja nicht notwendig, mit dem Kunden, dem Anwender oder auch nur dem Product Owner zu sprechen – alles vertane Zeit, in der man ja schon etwas programmieren könnte. Mehrwert produzieren ist doch die goldene Regel der Agilität, oder?Und da lenken Kunden und ähnliche Nicht-Experten einfach nur ab. Nicht nur, dass sie die Dinge einfach nicht vernünftig formulieren können, sie wissen doch gar nicht, was sie wollen. Da muss doch einfach mal ein Experte ran und denen zeigen, was sie brauchen.Gleiches gilt auch für Fachkonzepte und ähnlichen Ballast (im Lean-Jargon auch gerne „Waste“ genannt oder von den ganz hippen Agilisten „Muda“ – japanisch für sinnlose Verschwendung). Wozu sollte ich meine Zeit damit verschwenden, womöglich auch noch vor einer Schätzung? Ich weiß es eh besser!Konsequenz: Man muss kein Hellseher sein, um vorauszusagen, dass das Ergebnis bei einem solchen Verhalten mit hoher Wahrscheinlichkeit nicht den Erwartungen des Kunden entsprechen wird. Auch wenn der Kunde bzw. Anwender sich in der Tat manchmal schwertun, ihre Vorstellungen „auf den Punkt“ zu bringen und sie (aus verschiedenen, meist nachvollziehbaren Gründen) während der Entstehung einer Funktionalität auch einmal ihre Meinung ändern, so sind sie letzten Endes dennoch die einzigen, die sagen können, was sie benötigen, um ihre Aufgabe zu erfüllen.Bezieht man sie bei der Umsetzung nicht in die Lösungsfindung mit ein, so wird man normalerweise eine suboptimale Lösung realisieren, die dem Kunden/Anwender nicht oder nur eingeschränkt hilft, seine Aufgaben möglichst effizient und effektiv zu erfüllen.Häufig führt ein solches Vorgehen auch zu geringerer Qualität des Ergebnisses, weil benötigten Qualitätsanforderungen nicht wahrgenommen und damit auch nicht umgesetzt werden. Oder um es einfach zu formulieren: Das Ergebnis ist technisch vielleicht top, aber fachlich ein „Flop“.Maßnahmen: Häufig ist der Grund für eine solche Einstellung nicht Arroganz, wie man zunächst vermuten könnte, sondern eher Unsicherheit. Es besteht eine große (gefühlte) Distanz zwischen dem Kunden/Anwender und dem Entwickler im Team. Und da viele Leute sich schwertun, eine solche Distanz von sich aus abzubauen, sollte man da unterstützen.Eine gute Maßnahme ist z.B. ein gemeinsames Kick-Off, möglichst in einem nicht zu formalen Rahmen, damit die Leute Zeit haben, sich gegenseitig ein wenig kennenzulernen. Auch ein gemeinsames Projekt-Event nicht zu spät während des Projektes wirkt oftmals echte Wunder.Eine etwas kleinere Maßnahme ist, das Team zu den Sprint-Demos mitzunehmen und es die Demo selber durchführen zu lassen, inklusive der Diskussionen, die sich häufig bei der Demo ergeben. Nebenbei ist das sowieso meistens eine gute Idee, wird nur häufig nicht gemacht, weil sich die Kosten dafür über die Sprints hinweg summieren, vor allem, wenn der Kunde nicht um die Ecke sitzt. Diese Kosten werden dann gerne eingespart und nur der Scrum Master oder der Product Owner, ggf. mit einem weiteren Senior machen die Demo. Lässt man das Team die Demo machen, so fungieren Scrum Master bzw. Product Owner nur als Moderator.Und sollten diese Maßnahmen nicht fruchten und die Distanz wird vom Team oder einzelnen Personen daraus aufrecht erhalten, kann man ggf. auch noch ein fachliches Design einfordern, um die betreffenden Personen mehr oder minder dazu zu zwingen, sich mit der Fachlichkeit und den Anforderungen auseinanderzusetzen. Natürlich muss in dem Fall auch sichergestellt sein, dass jemand zur Verfügung steht, der dieses Design auch validieren kann.Zum Abschluss des Posts wie immer noch ein wenig Verlinkung:<ul><li>Den Link zum ersten Post dieser Serie findet Ihr <a href="http://blog.codecentric.de/2010/12/agile-worst-practices-1/">hier</a> .</li><li>Den Link zum nächsten Post dieser Serie findet Ihr hoffentlich in Bälde hier … 😉</li></ul>PS: Feedback, Ergänzungen, eigene Erfahrungen, usw. sind wie immer herzlich willkommen!

Agile Worst Practices – Teil 4

Ich lese immer wieder Aussagen wie „wirklich neu ist Cloud nicht“ oder härter formuliert „das ist doch nur alter Wein in neuen Schläuchen“.Ja, das kann man so sehen, aber ich tue mich etwas schwer mit diesen Aussagen. Warum?Disruptive Innovationen (also Innovationen, die wirklich etwas verändern) benötigen keine grundlegend neue Ideen. Tatsächlich bestanden die wenigsten Innovationen, die wirklich etwas verändert haben, aus komplett neuen Ideen.Egal, ob Ford T, der PC, das viel geliebte und gehasste MS Windows oder die Smartphones … alles keine neuen Ideen, sondern eine Rekombination bekannter Ideen zum richtigen Zeitpunkt, d.h. der Markt war reif dafür, sowohl von der Bedarfsseite als auch von der Fähigkeit, das „neue“ Produkt in hinreichender Qualität zu liefern. Als Gegenbeispiel war z.B. der Apple Newton sicherlich ein tolles Gerät, aber der Markt war noch nicht reif dafür.Das „revolutionäre“ an der Cloud sind also nicht die Bestandteile, sondern deren Kombination und der Zeitpunkt.Für mich ist das wirklich innovative an der Cloud diese Kombination aus Elastizität, flexiblen Preismodellen (bis hin zum häufig genutzten Pay-per-Use), Customer self service und Instant delivery. Ja, jede einzelne Idee gab es früher schon, aber in dieser Kombination ist es neu, eine echte Innovation mit disruptivem Potential.Das ist ein wenig so wie mit einem hervorragenden Essen: Die Zutaten sind alle altbekannt, kann sich jeder auf dem Markt oder im Supermarkt seines Vertrauens besorgen, aber ihre Kombination und die Zubereitung machen es zu etwas Außergewöhnlichem. Ich weiß, der Vergleich hinkt ein wenig, weil ein hervorragendes Essen nicht wirklich einen geeigneten Zeitpunkt benötigt. Da wären wir dann eher beim Fast-Food, was zu seiner Zeit eine disruptive Innovation war … nur, ob das viel mit hervorragendem Essen zu tun hat? … 😉Aus den genannten Gründen tue ich mich mit den eingangs genannten Aussagen etwas schwer. Der Innovationscharakter einer Idee hängt nicht von der Innovativität der Bestandteile, sondern von ihrer Kombination ab … und natürlich stark vom Zeitpunkt.So gesehen erfüllt die Cloud für mich die Voraussetzungen für eine echt disruptive Innovation. Ob sie es letztlich auch sein wird, werden wir sehen, wenn sich der sie umgebende Hype-Nebel ein wenig gelichtet haben wird …

Ist die Cloud innovativ oder alter Wein in neuen Schläuchen?

Es sind die Weihnachtsfeiertage und wie viele andere Leute nutze ich die Zeit, um ein wenig abzuschalten – keine großen Verwandschaftsbesuche, keine große Urlaubsreise, nur ein wenig zu Hause abhängen und dabei darauf achten, nur nicht zu viel zu tun. Aber wie viele andere Leute beginne ich nach den ersten Tagen, seltsame Dinge zu machen, konkret hier und da Dinge aufzuräumen, die die ganze Zeit liegengeblieben sind. So habe ich heute morgen Zeit damit verbracht, mein Büro zu Hause ein wenig auszumisten.Dabei bin ich über einige Notizen gestolpert, die ich mir 2008 bei der <a href="http://www.irmuk.co.uk/eac2008/" target="_blank">Enterprise Architecture Conference in London</a> gemacht habe. Auch wenn es eine großartige Konferenz gewesen war, habe ich entschieden, dass ich die meisten der Notizen nicht mehr benötige und sie in den Müll geworfen. Aber ein Satz auf einer der Seiten ließ mich für eine Zeitlang innehalten. Ich glaube, es war ein Satz aus einer Keynote, die David Robertson, ein Professor aus der Schweiz gehalten hat. Der Satz erschien mir damals offenbar so wichtig, dass ich ihn mir notiert habe (Ich bin kein großer Notizen-Schreiber, deshalb muss mir der Satz wichtig erschienen sein).Der Satz lautete: „Architektur ist ein Kompass, kein Blueprint“. In Klammern hatte ich noch „Überdenken!“ dazugeschrieben, als ein Hinweis für mich, noch einmal über diesen Satz nachzudenken. Nun hat es letztlich mehr als 3 Jahre gedauert, bevor ich dazu gekommen bin, über den Satz noch einmal nachzudenken und aus heutiger Sicht bin ich der Meinung, dass der Satz wirklich wichtig ist – einer dieser zeitlos wahren Sätzen.Aus meiner heutigen Wahrnehmung beschreibt der Satz perfekt, was Architektur sein sollte und was nicht. Architektur sollte eine Orientierungshilfe in Richtung der richtigen Lösung sein, in einer fürchterlich komplexen Umgebung, in der bereits „richtig“ eine extrem komplexe Sache ist, die alles andere als offensichtlich und nur schwer zu bestimmen ist. Daher sollten wir die Umgebung von Zeit zu Zeit von verschiedenen weiter entfernten (d.h. abstrakteren) Standpunkten betrachten, einzig und allein mit dem Ziel, danach zurückzukommen und zu sagen „Basierend auf dem, was ich da drüben gesehen habe, denke ich, dass es eine gute Idee ist, diesem Pfad da eine Weile zu folgen“.Danach machen wir dann die nächsten Schritte und dann schauen wir wieder, um über die nächsten Schritte zu entscheiden und so weiter: Architektur als ein Kompass. Wir können in der Regel zu Beginn keine vollständige Karte (d.h. einen Blueprint) von unserer Umgebung erstellen. Die Umgebung ist dafür viel zu komplex. Und üblicherweise benötigt man diese große, umfassende Karte auch überhaupt nicht. Üblicherweise reicht es, sich ein paaer Aufzeichnungen über die grundlegenden Wahrnehmungen von den verschiedenen, weiter entfernten Standpunkten zu machen (Überblicksbilder und High-level Konzepte) plus Begründungen für die wichtigsten Entscheidungen – für den Fall, dass man einmal zu der Stelle zurückkommt und nachvollziehen möchte, warum man sich damals so entschieden hat.Architektur als Kompass hat auch noch eine zweite Bedeutung: Architektur ist dynamisch, nicht statisch. Architektur ist kein Ziel oder Ergebnis, sie ist Teil eines Wegs. Sie verändert sich über die Zeit. Sie entwickelt sich. Sie verändert sich, wenn sich die Umgebung verändert, sie verändert sich, wenn Du etwas aus Deinen vorherigen Schritten dazugelernt hast. Während eine veraltete Karte keinerlei Nutzen mehr hat, bleibt ein Kompass immer hilfreich – aber natürlich nur, wenn man akzeptiert, dass er keine Lösung ist, sondern nur ein wertvolles Hilfsmittel, um den richtigen Weg auf einer Reise durch unbekanntes, komplexes Terrain zu finden.Ich denke, wir könnten auch einige dieser ermüdenden Diskussionen über Architektur beenden – insbesondere im Zusammenhang mit Agilität – wenn wir alle diesen einen Satz akzeptieren würden: „Architektur ist ein Kompass, kein Blueprint“. Architektur ist keine Karte zur Lösung, sie ist ein Hilfsmittel, um den richtigen Weg zu finden.Es gäbe sicherlich noch eine Menge mehr über diesen Satz zu schreiben, aber es sind die Weihnachtsfeiertage und ich wollte nicht zu viel tun … 😉

Architektur ist ein Kompass, kein Blueprint

Ihr fragt Euch vielleicht, was emergente Architektur mit Skalierbarkeit und Fehlertoleranz zu tun haben. Nun, um ehrlich zu sein: Gar nichts. Mit diesem kurzen Blog Post möchte ich nur kurz auf ein paar meiner kürzlich gehaltenen Vorträge hinweisen, die ich jetzt endlich auf Slideshare hochgeladen habe.Da ist zunächst eine neue Präsentation über Muster für fehlertolerante Systeme im Kontext von Scale-Out-Lösungen: <div> <a href="http://www.slideshare.net/ufried/no-crash-allowed-fault-tolerance-patterns" target="_blank">No crash allowed – Fault tolerance patterns</a> <div><div><div>Klicken Sie auf den unteren Button, um den Inhalt von www.slideshare.net zu laden.<a href="#">Inhalt laden</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>Vor einigen Tagen habe ich außerdem eine verwandte Präsentation über Muster für hochskalierbare Systeme hochgeladen:<div> <a href="http://www.slideshare.net/ufried/scalability-patterns" target="_blank">Scalability patterns</a> <div><div><div>Klicken Sie auf den unteren Button, um den Inhalt von www.slideshare.net zu laden.<a href="#">Inhalt laden</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>Und letztlich möchte ich noch eine Präsentation über die Möglichkeiten und Grenzen emergenter Architektur erwähnen, die ich ebenfalls vor einigen Tagen hochgeladen habe:<div> <a href="http://www.slideshare.net/ufried/emergent-architecture-12620741" target="_blank">Emergent architecture</a> <div><div><div>Klicken Sie auf den unteren Button, um den Inhalt von www.slideshare.net zu laden.<a href="#">Inhalt laden</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>Wie immer fehlt die „Tonspur“, aber ich habe versucht, die Folien auf eine Art und Weise zu gestalten, dass sie ohne den begleitenden Text nicht komplett nutzlos sind.Und ebenfalls wie immer bin ich an Eurer Meinung und Feedback interessiert. Solltet Ihr also irgendwelche Kommentare zu den Folien haben – immer her damit …

Skalierbarkeit, Fehlertoleranz und emergente Architektur

Vom 5.11.2012 bis zum 9.11.2012 öffnete wie bereits seit mehreren Jahren die W-JAX in München ihre Pforten – fünf Tage randvoll mit Vorträgen, Tutorien, Diskussionen, Ausstellung und Neuigkeiten rund um Java-basierte Enterprise- und Web-Anwendungen im weitesten Sinne.Ich hatte dort die Gelegenheit, mehrere Vorträge zu halten, von denen 3 aufgenommen worden sind und die demnächst online gestellt werden. Die Links dazu werde ich nachreichen.Außerdem hat Mirko Schrempp, seines Zeichens Chef-Redakteur des BusinessTechnology Magazins, ein Interview zu den Themen agile Architektur und den Konsequenzen des Wirtschaftsdarwinismus auf die Software-Entwicklung mit mir geführt. Das Ergebnis findet Ihr <a href="http://it-republik.de/jaxenter/news/Hektische-Zeiten-fuer-Architekten-065578.html" target="_blank">hier</a> . Zwischen meinen Vorträgen und vielen spannenden Unterhaltungen und Diskussionen mit vielen interessanten Personen hatte ich noch die Gelegenheit, mir den ein oder anderen Vortrag anzuschauen. Sehr erfreulich fand ich dabei, dass kein einziger Totalausfall bei den Vorträgen dabei war. Ich war durchweg positiv von der Qualität der Vorträge angetan. Natürlich hätte ich mir bei dem ein oder anderen Vortrag noch etwas mehr Tiefe gewünscht, aber bei durchschnittlich 60 Minuten pro Vortrag ist häufig einfach nicht mehr möglich.Meine persönlichen, garantiert komplett subjektiven Highlights waren:<ul><li>Manuel Küblböck und Doreen Timm von it-agile erzählten im Rahmen des Agile Day von ihren Erfahrungen mit einem Start-Up-Experiment, in dem versucht wurde, ein neues Produkt nach den Ideen von Lean Startup zu entwickeln. Der Vortrag bestand aus einer gut balancierten Mischung aus „Theorie“, sprich einer Vermittlung diverser Lean-Startup-Konzepte und „Praxis“, d.h. Erfahrungen, die sie in ihrem Selbstversuch gesammelt haben.</li><li>Stefan Tilkov (innoQ) und Gernot Starke haben einige Nicht-Mainstream-Sprachen, nämlich Prolog, Clojure, Erlang und Node.js (Java-Script auf einer speziellen Server-Engine) vorgestellt und dabei versucht zu vermitteln, was man aus diesen Sprachen und den damit verbundenen Laufzeitumgebungen für den Mainstream mitnehmen kann. Nun, 4 Sprachen in 60 Minuten waren eh schon eine Herausforderung. Dazu kam dann noch die Begeisterung, die die beiden Vortragenden ganz offensichtlich für die genannten Sprachen hegten, so dass sie die 60 Minuten locker gerissen haben … was ihnen aber niemand übel genommen hat. Die Begeisterung war ansteckend und außerdem konnte jeder die ein oder andere neue Idee für sich mitnehmen. Ich als alter Lisp-Liebhaber habe mir mal wieder auf meinen Merkzettel geschrieben, mir jetzt endlich mal Clojure in Ruhe anzuschauen. Seit gut eineinhalb Jahren nehme ich es mir immer wieder vor, aber immer kommt mir irgendwas dazwischen … aber nach dem Vortrag: Jetzt aber wirklich … 😉</li><li>Und noch einmal Stefan Tilkov, der über fortgeschrittene REST-Konzepte erzählt hat. Primär ging es in dem Vortrag um das HATEOAS-Konzept (Hypermedia As The Engine Of Application State). Ich spare mir jetzt, das genauer zu erläutern (Google hilft da besser als ich es jemals könnte), aber der Vortrag hat mir noch einige Anregungen gegeben, wie ich die derzeitige <a href="https://www.centerdevice.de/" target="_blank">CenterDevice</a> -REST-API in eine selbsterklärende, HATEOAS-konforme API transformieren könnte. Nebenbei könnte ich so auch das enervierende Pflegen der API-Dokumentation loswerden, indem alle Dokumentation letztlich in den Code wandert, mit dem netten Nebeneffekten, dass zum einen die Dokumentation genau beim Code steht und zum anderen, dass die Kollegen der CenterDevice-Entwicklung eher einmal bereit sind, die Dokumentation mit nachzupflegen, weil es dann auch möglich ist, ohne die geliebte IDE zu verlassen … mal sehen, was die Kollegen dazu meinen, wenn ich ihnen meine Ideen erzähle … 🙂</li><li>Am Mittwoch gab es gleich zwei interessante Keynotes. Zuerst hat Wolfgang Henseler über Natural User Interfaces (NUI) erzählt, die Art von Benutzerschnittstellen, die sich mit Smartphones und Tablets etablieren. Seiner Meinung nach wird der Übergang von GUI zu NUI ähnlich weitreichende Auswirkungen für die Mensch-Maschine-Schnittstelle und die Art, wie Menschen mit Programmen interagieren, haben wie seinerzeit der Übergang von der Kommandozeile zum GUI. Auch ich denke, dass da noch einiges an Umlernen bzw. Dazulernen (bzw. Verlernen der jahrelang antrainierten GUI-Best-Practices) gefordert ist, damit wir richtig gute NUIs entwickeln werden. Die zweite Keynote war übrigens von Dierk König und Gerrit Grunwald (bei Canoo), die in einer Neuauflage eines Formats, das sie bereits auf der JAX verwendet haben, zwei ihrer persönlichen IT-bezogenen Steckenpferde vorgestellt haben – jede Menge Spaß inklusive.</li><li>Last, but not least gab es am Donnerstag noch eine Keynote über Git Culture von Matthew McCullough. Auch wenn Matthew in seinem ungezügelten Redefluss ganz offensichtlich vergessen hatte, dass er vor einem non-native-Publikum gesprochen hat und damit sicherlich den ein oder anderen Zuhörer überfordert hat, so hat er doch einige interessante Konzepte von GitHub erzählt, das praktisch ohne Management geführt wird. Mir hat sich da die Frage gestellt, wie weit man das auf andere Unternehmen übertragen kann und ob es dafür bestimmte Voraussetzungen bei den Mitarbeitern gibt. Von der organisatorischen Seite her sind aus meiner Sicht auf jeden Fall die vollständige Transparenz (inklusiver aller Finanzdaten) und die volle kommerzielle Verantwortung bei allen Mitarbeitern kritische Schlüsselfaktoren. Ohne vollständige Informationen und volle Verantwortung bei allen Mitarbeitern kann es nicht funktionieren – nach dem Motto: „Bei uns ist jeder CEO“. Wie geschrieben, bin ich mir ehrlich gesagt nicht sicher, inwiefern ein solcher Ansatz auf eine beliebige Personengruppierung übertragbar ist, aber spannend finde ich den Gedanken allemal.</li></ul>Das waren meine persönlichen Highlights. Das heißt jetzt nicht, dass die Vorträge, die ich nicht erwähnt habe, schlechter gewesen wären … so eine Liste ist halt immer sehr subjektiv … spannend waren die ganzen Tage, ob mit oder ohne Vorträge.

W-JAX Nachlese …

Derzeit sind drei Megatrends auszumachen, die die IT zu einem dramatischen Wechsel zwingen:<ul><li>Wirtschaftsdarwinismus</li><li>Digitalisierung</li><li>Disruptive Technologien</li></ul>Alle drei sind außerordentlich wichtig und Firmen, die diese Trends ignorieren, werden früher oder später hinter ihren Konkurrenten zurückbleiben (zumindest solange diese Firmen in einem effizienten Markt leben – nichteffiziente Märkte sind eine andere Geschichte).<h2>Märkte im Wandel</h2>Kommen wir zum ersten Trend und beginnen mit einer kurzen Erläuterung: „Darwinismus“ bedeutet kurz gesagt „Nur die Besten überleben“ (Survival of the fittest) – der „Beste“ ist nicht der Stärkste, sondern derjenige, der sich schnell genug an die Anforderungen der Umgebung anpassen kann.<div><a href="https://media.graphassets.com/lIroTVhXTJSEzAyV3cNo"><img src="https://media.graphassets.com/lIroTVhXTJSEzAyV3cNo" alt="Wirtschaftsdarwinismus, Digitalisierung und disruptive Technologien setzen die IT unter Druck" width="250" height="188" /></a> Mega-Trends setzen die IT unter Druck und erzwingen damit einen fundamentalen Wandel</div>Das gilt auch für Firmen: Nur die Firmen, die sich schnell genug an die sich ändernden Ansprüche und Forderungen ihrer Kunden anpassen können, werden auf lange (oder auch nur kurze) Sicht überleben.Nun könnten Sie fragen: „Hey, was ist daran neu? Das ist doch schon immer so in der Wirtschaft.“ Und Sie hätten recht.Entscheidend ist, dass die Märkte, in denen die meisten Firmen agieren, vor einigen Jahren einen drastischen Wandel erfahren haben. Fast ein Jahrhundert lang waren die meisten Märkte weit, nahezu unbeschränkt und träge: Die Nachfrage war immer größer als das Angebot und die größte Herausforderung für die Firmen in diesen Märkten war es, die Produktion ihrer Waren möglichst kosteneffizient zu skalieren.Das änderte sich in den 1980ern: Langsam aber sicher wurde ein Markt nach dem anderen immer enger. Globalisierung, Marktsättigung und das Internet haben zu stark konkurrierenden und dynamischen Märkten geführt. (Tatsächlich gab es noch mehr Triebkräfte für den Wandel im Markt, doch das würde den Rahmen dieses Blogposts sprengen.) Die Märkte wurden stark bedarfsgesteuert und die neue größte Herausforderung der Firmen war, sich an die veränderten Bedürfnisse der Kunden schnell genug anzupassen. Die entscheidende Triebkraft wechselte von „kosteneffiziente Skalierung“ zu „Reaktionsfähigkeit“.<h2>Veränderte Rolle der IT</h2>Nun könnten Sie sagen: „Gut, das weiß ich alles. Doch was hat das mit IT zu tun?“Die Sache ist die, dass Business und IT heutzutage eng miteinander verflochten sind. Man kann sie nicht mehr unabhängig voneinander betrachten, selbst wenn alles ganz anders begann:Wenn Sie an die Beziehung zwischen Business und IT in den 1950ern und 1960ern denken, unterstützte die IT winzige Bruchteile der Geschäftsfunktionen – einen kleinen Bericht hier, eine kleine Analyse da. Das geschah ziemlich selektiv, da die damalige Rechenleistung der Mainframes recht beschränkt war (jedes moderne Mobiltelefon hat um Größenordnungen mehr Rechenleistung als die Computer in den 1960ern).Dennoch war es für die Geschäftsabteilungen ziemlich angenehm, die Berichte und Analysen nicht mehr per Hand erstellen zu müssen. Und sie wollten mehr davon haben – was schließlich zur Softwarekrise führte: Der Bedarf an Software überstieg deutlich das Angebot.Die Reaktion auf die Softwarekrise war die Erfindung des Software-Engineering: eine Ingenieurs-Disziplin mit dem Ziel, die Produktion von Software kosteneffizient zu skalieren. Klingt vertraut, nicht wahr? Die Industrialisierung stand Anfang des 20ten Jahrhunderts vor einem sehr ähnlichen Problem und der damalige Lösungsansatz war Taylorismus in seinen verschiedenen Varianten. Es dürfte also nicht überraschen, dass das Software-Engineering viele tayloristische Konzepte und Praktiken aufgegriffen und auf die Softwareentwicklung übertragen hat.Und damals war das auch vollkommen in Ordnung. Doch mit der Zeit hat sich die Rolle der IT essentiell gewandelt. In den 1980ern begann der Siegeszug des PC und Netzwerke gewannen an Bedeutung. Das mooresche Gesetz wirkte weiter, Computer wurden immer leistungsfähiger. Letztlich unterstützte die IT nicht mehr nur ausgewählte Geschäftsfunktionen, sondern zunehmend die Geschäftsprozesse im Ganzen. Sie rutschte immer näher an das Business mit all seiner Komplexität.Diese Entwicklung ging weiter, das Internet begann seinen Siegeszug in den 1990ern und mittlerweile ist die IT das Nervensystem jeder nichttrivialen Firma: Das gesamte Businesswissen ist in IT codiert, IT-Ausfälle von nur wenigen Stunden gelten für viele Firmen als existenzbedrohend. Das bedeutet aber auch, dass Sie Ihr Business nicht mehr ändern können – weder neue Produkte noch neue Features oder Prozessänderungen –, ohne die IT anzufassen.<h2>The Need for Speed</h2>Wenn man die oben beschriebenen Beobachtungen zusammenfasst, zeigt sich, dass die IT zu einem entscheidenden Erfolgsfaktor für jede Firma geworden ist, um im Wirtschaftsdarwinismus bestehen zu können. Egal wie gut Sie die die Bedürfnisse und Forderungen Ihrer Kunden kennen, wenn Ihre IT nicht schnell genug liefern kann, werden Sie das Nachsehen haben.Dennoch klammern sich die meisten Firmen an die Ideen des herkömmlichen Software-Engineering, wo es das primäre Ziel ist, die Produktion von Software kosteneffizient zu skalieren. Das Problem ist, dass Skalierung der Softwareproduktion und IT-Kosteneffizienz nicht mehr die entscheidendsten Treiber sind (tatsächlich schreiben wir heutzutage viel zu viel Software, es dauert nur zu lange und sehr oft ergibt sich nur ein Bruchteil des erwarteten Mehrwerts).Der entscheidendste Treiber für die heutige IT sind Durchlaufzeiten – wie lange es dauert, um eine Idee zum Kunden zu bringen. Es geht also um die erforderliche Zeit, um die gesamte IT-Wertschöpfungskette zu durchlaufen, beginnend beim Aufnehmen der Anforderungen bis die Lösung live in der Produktion läuft.Je kürzer diese Durchlaufzeiten sind, desto besser kann man sich an den sich ständig verändernden Bedarf der hochdynamischen Märkte anpassen. Wir brauchen „Speed“!<h2>Verschärfte Bedingungen</h2>Wenn wir uns den zweiten Megatrend – die Digitalisierung – ansehen, wird es noch etwas schwieriger: Mit Digitalisierung wird die IT das Business nicht mehr nur unterstützen, sondern selbst zum Business. Wir erzeugen neue Businessprodukte, die teilweise oder gänzlich aus IT bestehen. Auf der einen Seite verlangt das nach Innovation, da wir gerade erst verschwommene Ideen entwickeln, welche zukünftigen Geschäftsmodelle Trends wie z.B. das Internet der Dinge (Internet of Things, IoT) ermöglichen werden. Andererseits bedeutet das, dass unsere IT noch robuster als zuvor sein muss, da auch unsere Kunden ständig damit in Berührung kommen.Der dritte Megatrend sind disruptive Technologien wie Cloud-Computing, Mobile Services, Big Data und IoT. Diese Technologien eröffnen ganz andere Möglichkeiten, um Geschäftsanforderungen umzusetzen, bis hin zu einer Ebene, wo sie vollständig neuartige Geschäftsmodelle ermöglichen. Da wir aber gerade erst begreifen, was wir mit diesen Technologien anstellen können, verschärfen sie die oben beschriebenen Bedingungen:Wir müssen verstehen und lernen, wir müssen Innovation treiben, wir müssen uns an die sich ständig ändernden Märkte anpassen und das Ganze muss schnell geschehen, wobei wir die neuen Möglichkeiten disruptiver Technologien berücksichtigen müssen. Und wir werden nicht erfolgreich sein, wenn wir uns dabei an Ideen klammern, die vor vielen Jahren in einer gänzlich anderen Geschäfts- und IT-Ära entwickelt wurden.Wir müssen IT neu denken!<h2>IT neu denken</h2>Dies war die Kurzversion der langen Geschichte, warum Durchlaufzeiten zum wichtigsten Treiber für die heutige IT geworden ist, warum wir IT neu denken müssen.Doch wenn das alte Wissen, auf der wir immer noch die meisten unserer IT-Prozesse und Arbeitsabläufe aufbauen, nicht geeignet ist, um IT neu zu denken, was ist es dann?<div><a href="https://media.graphassets.com/TL2olKkYQFiwr7Qk9paq"><img loading="lazy" src="https://media.graphassets.com/TL2olKkYQFiwr7Qk9paq" alt="DevOps, Continuous Delivery, Microservices und Cloud-basierte Infrastruktur als Kernbausteine einer neuen IT" width="250" height="188" /></a> Kernbausteine einer neuen IT, die auf die veränderten Treiber reagiert</div>Das ist eine durchaus berechtigte Frage. Ein guter Ausgangspunkt sind üblicherweise Organisation und Prozesse: Die Organisations- und die Systemtheorie haben gezeigt, dass sich dezentrale Organisationen mit vorwiegend autonomen Einheiten viel besser und deutlich schneller an die sich ständig ändernden Anforderungen anpassen können als hierarchische Organisationen, die auf tayloristischen Prinzipien beruhen. Außerdem sind dezentrale Organisationen typischerweise ein ganzes Stück robuster gegenüber unerwarteten Anforderungen.Wenn wir uns einen Moment lang umsehen, werden wir schnell erkennen, dass es bei DevOps genau um diesen Punkt geht: Wir schaffen vorwiegend autonome Teams, die ganzheitlich Verantwortung für dedizierte Geschäftsfähigkeiten übernehmen und wir lassen sie auf alle Änderungsforderungen in ihrem Kompetenzbereich reagieren. Tatsächlich gehört noch viel mehr zu DevOps, wie zum Beispiel ganzheitliche Optimierung von Durchlaufzeiten, Verstärkung von Feedback-Schleifen, um gegebenenfalls erforderliches Wissen bereitzustellen, und eine Kultur des beständigen Lernens. Dies sind ebenfalls sehr wichtige Eigenschaften von DevOps, die genau in die Richtung der Treiber zeigen, die wir oben gesehen haben.Doch DevOps allein genügt nicht. Wir müssen sicherstellen, dass Teamautonomie nicht durch Software und Systeme verletzt wird, an denen die Teams arbeiten. Wenn zum Beispiel viele Teams an einem großen Monolithen arbeiten (der leider die Tendenz hat, im Laufe der Zeit zu einem großen Brocken Spaghetticode zu verkommen), werden die Teams normalerweise jede einzelne Änderung koordinieren müssen und die Autonomie ist dahin. Wenn wir Software nur in großen Alles-oder-nichts-Releases freigeben können, wenn wir mit einem Laufzeit-Megamonolithen konfrontiert sind, müssen die Teams sämtliche Änderungen koordinieren und sich auf ein Release-Datum verständigen – und die Autonomie ist ebenfalls dahin.Wir brauchen also ein Architekturmuster, das Autonomie in Bezug auf Entwicklung und Bereitstellung von Software unterstützt. Microservices sind ein solches Architekturmuster. Deren Eigenständigkeit („Self-containment“) und problemlose Erfassbarkeit für den Einzelnen („Fits in one brain“) unterstützen Teamautonomie sehr gut. Zudem erlauben sie schnelle Änderungen und kurze Durchlaufzeiten. Faktisch sind Microservices nicht der einzige Stil, der den gegebenen Anforderungen entspricht, und zugegebenermaßen ist es recht einfach, sie zu verpfuschen und am Ende vor einem großen verteilten Kuddelmuddel zu stehen (auch bekannt als „verteilte Hölle“). Doch richtig gemacht unterstützen sie Autonomie und schnelle Anpassung sehr schön.Autonome DevOps-Teams, die auf die sich ständig ändernden Forderungen reagieren, müssen ihre Software auch freigeben („deployen“) können, wann immer sie wollen. Und wenn sie ihre Software mehrmals pro Tag freigeben müssen, darf das keine Probleme machen. Software unabhängig nach Bedarf freizugeben verlangt normalerweise nach Automatisierung. Manuelles Erstellen, Testen und Freigeben ist viel zu teuer und fehleranfällig, wenn dies häufig geschehen muss. Dies ist die Domäne von Continuous Delivery, das ja gerade das konsequente Automatisieren von Erstellen, Testen und Freigeben von Software zum Ziel hat.Der letzte Teil des Bilds ist die Infrastruktur, auf der die Software läuft, da sie ebenfalls sehr flexibel sein muss. Wenn es Tage, Wochen oder Monate dauert, um die erforderliche Infrastruktur für Entwicklung, Bauen, Testen oder Freigeben zu bekommen, ist jede Teamautonomie und Reaktionsfähigkeit dahin. Die Teams müssen in eigener Regie auf die erforderliche Infrastruktur zugreifen können („Self-service access“), wann immer sie sie brauchen, und sie müssen sie auch wieder abstoßen können, sobald sie sie nicht mehr brauchen. Genau diesen Anforderungen entspricht das Cloud-Bereitstellungsmodell. Darüber hinaus ermöglicht der API-basierte Ansatz elastisches Skalieren zur Laufzeit sowie bessere Automatisierung des Build-, Test- und Freigabeprozesses.<h2>Weitere Überlegungen</h2>Wir haben gesehen, dass DevOps, Microservices, Continuous Delivery und Cloud-Computing Kernbausteine einer neuen IT sind. Doch reicht das aus für unsere neue IT oder fehlen noch irgendwelche Teile?<div><a href="https://media.graphassets.com/ZI4DdEpRYyI7IpyegEHg"><img loading="lazy" src="https://media.graphassets.com/ZI4DdEpRYyI7IpyegEHg" alt="Beyond Budgeting, EAM neu gedacht und Craftsmanship als ergänzende Bausteine" width="250" height="188" /></a> Bausteine einer neuen IT, einschließlich unterstützender Elemente</div>Tatsächlich fehlen einige unterstützende Teile. Das erste ist das Unternehmensarchitektur-Management (Enterprise Architecture Management, EAM), doch nicht auf die Weise, wie man es kennt. Es hat keinen Mehrwert, Unmengen von Bildern im Voraus zu zeichnen und zentral zu versuchen, die gesamte IT-Landschaft im Detail unmittelbar vom Elfenbeinturm aus vorauszuplanen und zu beschreiben. Dies wird standardmäßig ein Flaschenhals sein und ist ziemlich genau das Gegenteil von dem, worum es bei DevOps geht.Dennoch gibt es einige wichtige Aufgaben in einer DevOps-Organisation, wo EAM eine Menge Mehrwert erzeugen kann: Selbst wenn die Teams möglichst unabhängig und autonom sein sollten, müssen sie trotzdem noch an einem gemeinsamen Ziel arbeiten. Hier bietet sich EAM an, um die gemeinsame Vision zu verbreiten und den Teams zu helfen, das große Ganze im Blick zu behalten.Zweitens ist totale Teamautonomie nicht möglich, da alle Teams auf ein gemeinsames Ziel hin arbeiten und die von ihnen produzierte Software zusammenspielen muss. Das heißt Koordination. Die Teams müssen sich wechselseitig abstimmen, wie ihre Software mit der jeweils anderen zusammenarbeitet. Das kann recht umständlich und ineffizient sein, wenn über jede einzelne Interaktion von Grund auf neu abgestimmt werden muss. Deshalb ist es sinnvoll, sich über bestimmte Interaktionsstandards über alle Teams hinweg zu verständigen. Diese Minimalmenge an Standards zu ermitteln und zu pflegen, ist ebenfalls eine gute Aufgabe für EAM.Eine andere Definition ist, dass sich EAM um das große Ganze und den Raum zwischen den Verantwortlichkeiten der Teams kümmert. Eine letzte Anmerkung zu EAM: Normalerweise ist dies kein Vollzeitjob und es sollte kein Elfenbeinturmteam damit betraut werden. Stattdessen sollte das EAM-Team aus Abgesandten der DevOps-Teams bestehen, die sich gelegentlich oder einfach nur bei konkretem Bedarf treffen.Der zweite große unterstützende Baustein ist das Führungsmodell („Governance“). Wir müssen immer noch sicherstellen, dass die Visionen des Top-Level-Managements und die Arbeit der Teams zueinander passen. Wichtig ist Transparenz – was geschieht in den Teams? Und ebenso wichtig ist, dass das Top-Level-Management den Teams Richtungsänderungen effizient vermitteln kann.Die herkömmlichen Führungsmodelle von hierarchischen Organisationen sind nicht geeignet für eine DevOps-Organisation, die Durchlaufzeiten und Marktreaktivität optimiert. Wir brauchen ein anderes Führungsmodell. Das gute daran ist, dass diese Führungsmodelle schon eine ganze Zeit bekannt sind und von diversen großen Firmen, die sie übernommen haben, erfolgreich in der Praxis erprobt wurden. Diese Modelle sind unter dem Namen „Beyond Budgeting“ oder „Beta-Kodex“ (eine Weiterentwicklung von „Beyond Budgeting“) bekannt.Als dritter großer unterstützender Baustein ist Craftsmanship zu nennen. Ja, es geht um Menschen (leider vergessen wir das allzu oft)! Wir müssen allen beteiligten Personen helfen, ein verändertes Verständnis bzgl. der Art und Weise zu entwickeln, wie sie arbeiten.Auf der einen Seite ist es wichtig, den Leuten dabei zu helfen, ständig die Art und Weise zu verbessern, wie sie ihre Arbeit erledigen und mit ihren Kollegen zusammenarbeiten. Man bezeichnet dies auch als „Meisterschaft“ („Mastery“). Eine Haltung der Art „alles wird sich finden“ ist nicht mehr ausreichend. Dies ist die Kernidee von Craftsmanship.Auf der anderen Seite brauchen die Menschen kein stabiles Arbeitsmodell mehr, sondern vielmehr ein robustes Veränderungsmodell. Menschen brauchen Orientierung – einige Regeln und Ankerpunkte, an denen sie sich orientieren können. In der Vergangenheit wurde den Leuten ein Modell vorgesetzt, wie sie ihre Arbeit zu erledigen haben, entweder mithilfe detaillierter Prozessbeschreibungen oder über weniger förmliche Richtlinien.Das Problem bei diesem Ansatz ist, dass sich die Arbeitsweise ständig ändert, da sich Firmen fortwährend an die sich ständig ändernden Bedürfnisse und Forderungen ihrer Kunden anpassen müssen. Demzufolge ist es nicht möglich, ein Arbeitsmodell bereitzustellen, das über einen längeren Zeitraum stabil ist. Deshalb ist es notwendig, den Leuten ein Modell an die Hand zu geben, mit dem sie leichter verstehen können, wann eine Veränderung notwendig ist und warum. Wir gehen also eine Stufe nach oben vom Bereitstellen eines stabilen Arbeitsmodells zum Bereitstellen eines robusten Veränderungsmodells. Selbst wenn dies kein zentraler Aspekt von Craftsmanship ist, gehört er zweifellos in diesen Bereich.<h2>Fazit</h2>Wir müssen IT neu denken – die Märkte, in denen die Firmen agieren, haben sich geändert, die IT selbst hat sich geändert. Die Rahmenbedingungen, unter denen unsere traditionellen IT-Modelle entwickelt wurden, existieren nicht mehr. Unser primärer IT-Treiber ist nicht mehr die kosteneffiziente Skalierung der Softwareproduktion, vielmehr geht es darum, die Durchlaufzeiten zu minimieren, um die Reaktionsgeschwindigkeit des Unternehmens zu maximieren.Die Kernbausteine für diese neue IT sind DevOps, Microservices, Continuous Delivery und Cloud-Computing, die durch einige zusätzliche Elemente wie EAM (ebenfalls neu gedacht!), Beyond Budgeting und Craftsmanship ergänzt werden müssen.Immerhin ist dies lediglich das „große Bild“, eine Draufsicht aus 10.000 Metern Höhe. Es gibt viele Schattierungen, die ich zugunsten der Kürze weggelassen habe – und dennoch ist es ziemlich lang geworden. Außerdem besteht jeder hier erwähnte Baustein aus vielen weiteren Details auf verschiedenen Ebenen. Und es sind jede Menge Details zu berücksichtigen, um nicht alles am Ende zu verpfuschen. Doch das sind andere Geschichten …

The Need for Speed – eine Geschichte über DevOps, Microservices, Continuous Delivery und Cloud-Computing

Wenn wir eine Definition für einen Begriff suchen oder Erklärungen zu einem Thema, wo schauen wir dann nach? Richtig, in <a href="http://de.wikipedia.org/wiki/Hauptseite " target="_blank">Wikipedia</a> ! Und wir wissen, dass die gesammelten Informationen nach dem Prinzip der offenen Community zusammengetragen worden sind, dass also jeder, der Ahnung von einem Thema hat, alle Experten dieser Welt ihr Wissen dort verewigen können und so dem nicht ganz so wissenden Rest der Welt zur Verfügung stellen können.Wir verlassen uns mittlerweile so sehr auf die Informationen in Wikipedia, dass wir uns häufig gar nicht mehr die Mühe machen, alternative Quellen zu prüfen. Und wenn irgendwo eine Definition aus Wikipedia zitiert wird, nehmen wir sie als richtig hin.Dazu das folgende Erlebnis, das ich dieses Jahr auf der <a href="http://www.irmuk.co.uk/eac2008/" target="_blank">Enterprise Architecture Conference</a> in London hatte:Auf besagter Konferenz hat John Zachman in einer Keynote die neue Version seines Frameworks vorgestellt. Dazu hat er an jeden Keynote-Teilnehmer ein Blatt ausgeteilt, das eine schön aufbereitete Darstellung seines Frameworks zeigte. Bevor er aber begann, die Neuerungen seines Frameworks zu erklären, hat er uns Teilnehmer auf zwei kurze Artikel aufmerksam gemacht, die auf der Rückseite des Blattes abgedruckt waren.Er erzählte dazu sinngemäß übersetzt: „Diese beiden Artikel erläutern in Kürze mein Framework. Der Grund, warum ich sie hier habe abdrucken lassen, ist Wikipedia. Ich hatte vor einiger Zeit aus Neugierde nachgelesen, was in Wikipedia über mein Framework geschrieben steht. Dabei ist mir aufgefallen, dass der Artikel in Wikipedia einige falsche Aussagen enthielt. Also habe ich die fehlerhaften Aussagen in dem Artikel korrigiert. Dank des offenen Konzepts von Wikipedia ist das ja kein Problem. Kurze Zeit später erhielt ich die Rückmeldung von Wikipedia, dass meine Änderungen gelöscht worden seien, da sie nicht korrekt wären. Ich schrieb sinngemäß zurück: ‚Hallo, ich bin John Zachman. Wenn ich nicht wissen soll, was im Kontext meines Frameworks richtig ist, wer dann?‘ Aber es hat nichts geholfen. Wikipedia hat darauf bestanden, dass meine Aussagen zu meinem Framework falsch seien. Aus diesem Grund sah ich mich gezwungen, diese beiden Artikel zu schreiben, in denen dargestellt ist, wie ich mir mein Framework vorstelle, wenn ich das schon nicht in Wikipedia machen kann.“Natürlich hatte John Zachman mit dieser Anekdote die Lacher auf seiner Seite und da er die gute Ausgangsstimmung in seiner Keynote aufrecht halten konnte, war es auch für alle Anwesenden eine tolle Keynote, bei der wir übrigens auch eine Menge über die neue Version seines Frameworks und die dahinterliegenden Ideen und Konzepte gelernt haben.Was sagt einem diese Geschichte aber in Bezug auf Wikipedia? Ich weiß nicht, was da im Detail passiert ist, wer genau die Änderungen von John Zachman in Wikipedia rückgängig gemacht hat und habe auch nicht weiter nachgefragt. Was einem die Anekdote von John Zachman aber gut vor Augen führt ist, dass auch Wikipedia nicht unfehlbar ist. Auch hinter Wikipedia stehen Menschen, und Menschen haben Schwächen und machen Fehler – Fehler, die sich letztlich auch in den Inhalten von Wikipedia wiederfinden.Für mich war es ganz hilfreich, mit dieser Geschichte mal wieder daran erinnert zu werden, dass auch Wikipedia nicht unfehlbar ist. Natürlich wissen wir das eigentlich auch alle, nur vergessen wir es zwischendurch immer mal wieder.Wikipedia ist eine hervorragende Informationsquelle und es ist aus meiner Sicht nach wie vor beeindruckend, wie über das offene Konzept von Wikipedia über so kurze Zeit so viel qualitativ hochwertiges Wissen zusammengetragen werden konnten. Dennoch sollten wir Wikipedia nicht mit der „Wahrheit an sich“ verwechseln, sondern es wie mit jeder anderen guten Informationsquelle auch halten: Wir können Wikipedia als erste Quelle für eine Informationsrecherche nutzen; dann sollten wir aber wie bei jeder guten Recherche mehrere weitere Quellen zur Gegenprüfung heranziehen, um das Fehlerrisiko zu minimieren und die Belastbarkeit unserer Informationen sicherzustellen.Denn: Wikipedia hat eben nur fast immer recht.

Wikipedia hat immer recht

Letzte Woche habe ich die SET 2009 in Zürich besucht. Die von <a href="http://www.sigs-datacom.de/">SIGS DATACOM</a> organisierte Konferenz ist nicht so groß wie ihre große Konferenz, die OOP. Die SET hatte etwa 160 Besucher, dauerte zwei Tage und hatte ein gutes Programm, das in drei parallelen Tracks organisiert war.Auf der Konferenz habe ich einen Vortrag über die Probleme der Wiederverwendungs-Diskussion und die Potentiale eines Design for Maintenance gehalten, aber darüber möchte ich hier nicht schreiben.In der restlichen Zeit habe ich die Gelegenheit genutzt, einige andere Sessions zu besuchen und mich mit anderen Konferenzteilnehmern zu unterhalten und ich möchte hier über zwei interessante Ideen schreiben, die ich in dem Kontext aufgeschnappt habe. Als erstes habe ich einen Erfahrungsbericht bzgl. eines virtuellen Entwicklungsteams besucht, den Stephan Wald gehalten hat. An einer Stelle  in seinem Vortrag hat er festgehalten, dass die Entwicklung in virtuellen Teams nur mit einem bestimmten Typus Entwickler funktioniert. Er sagte, dass diese Art der Zusammenarbeit Entwickler braucht, die bereit sind, sich regelmäßig auszutauschen, ihre Ergebnisse zu teilen, zu dokumentieren, was sie getan haben, und so weiter. Oder um es andersherum auszudrücken: „IT Superhelden“ oder „einsame Cowboys“ (gemäß ihrer Selbstwahrnehmung), die immer alles allein machen und nichts teilen, insbesondere nicht ihren Code, passen nicht zu dieser Art von Projekten, selbst wenn sie extrem schnell Ergebnisse produzieren. Der virtuelle Ansatz funktioniert schlicht nicht mit dieser Art von Entwicklern.Ich fand diese Beobachtung sehr interessant, weil ich schon immer ein wenig ambivalente Gefühle gegenüber diesen “Shared nothing”-Leuten gehegt habe. Auf der einen Seite waren diese Leute häufig exzellente Entwickler, die in der Lage waren, ein in Schieflage geratenes Projekt an einem Wochenende zu retten (weshalb sie bei Managern häufig sehr beliebt sind). Auf der anderen Seite erzeugten sie immer eine Art schwarzes Loch in ihrer Umgebung, mit dem sie sich unersetzlich machten – ebenfalls innerhalb eines Wochenendes.Als ich beim Mittagessen mit in paar anderen Leuten darüber gesprochen habe, sagte ein anderer Speaker, dass er denkt, dass „IT Superhelden“ immer ein Problem sind, in jeder Art von Projekt. Virtuelle, verteilte Teams würden es nur sehr schnell sichtbar machen. Die anderen Leute am Tisch stimmten dem zu und ich glaube auch, dass er recht hat. Für meinen Teil denke ich mir, dass die Ära der „IT Superhelden“, dieser „einsamen Cowboys“ zu Ende gehen sollte oder anderenfalls werden die Projekte, an denen sie beteiligt sind, zu Ende gehen – und zwar früher als erwartet.Die zweite interessante Sache, über die ich hier schreiben möchte, ist der Vortrag, den Peter Sommerlad gehalten hat, einer der Autoren des <a href="http://www.amazon.de/System-Patterns-Pattern-Oriented-Software-Architecture/dp/0471958697/">ersten POSA Buchs</a> und mittlerweile Professor am <a href="http://ifs.hsr.ch/">Institute for Software</a> in Rapperswil. Peter hat einen sehr interessanten Vortrag über „Decremental Development“ gehalten. Die Idee ist, alle unnötige Komplexität aus dem Code zu entfernen und den Code so auf einen Bruchteil seiner ursprünglichen Größe zu schrumpfen, wodurch er leichter zu verstehen und wartbarer wird.Diesen Vortrag fand ich sehr interessant, weil er ebenfalls die Wichtigkeit wartbarer Software betont hat, unabhängig davon, ob auf Architekturebene, worüber ich in meinem Vortrag gesprochen habe oder auf Design- und Codeebene, worüber Peter gesprochen hat. Für meinen Teil denke ich, dass die Leute zumindest auf den Konferenzen beginnen zu verstehen, dass wartungsfreundliches Design und wartungsfreundlicher Code die wirklich kritischen Punkte sind, die dringend angegangen werden müssen, um die Gesamtkosten (TCO) von Software unter Kontrolle zu halten.Es geht nicht darum, immer die billigste Implementierungsvariante zu wählen und damit punktuell einen gut aussehenden Business Case zu erzeugen, bei dem die Folgekosten, die diese billigste Lösung hervorruft, komplett ignoriert werden. Stattdessen geht es darum, die Gesamtkosten einer Anwendung unter Berücksichtigung ihres gesamten Lebenszyklus zu optimieren – und die Wartungsphase ist die mit Abstand größte Phase des Lebenszyklus einer IT Anwendung.Ich denke, wenn die Leute beginnen, sich dieser Tatsache auf Konferenzen bewusst zu werden, dann mag es immer noch eine Weile dauern, bis es in der Breite der IT-Schaffenden ankommt, aber es ist definitiv ein Schritt in die richtige Richtung.Das waren die zwei Ideen, über die ich schreiben wollte. Ein letzter Tipp: Sollten Sie einmal die SET besuchen, benutzen Sie die <a href="http://www.zvv.ch/zvv/de/home.html">öffentlichen Verkehrsmittel</a> . Wenn Sie – wie ich – die üblichen Verspätungen der Deutschen Bahn gewohnt sind, ist es einfach großartig, öffentliche Verkehrsmittel zu benutzen, die so pünktlich und zuverlässig sind, dass man seine Uhr danach stellen kann. Deshalb: Benutzen Sie die öffentlichen Verkehrsmittel, lehnen Sie sich einfach zurück und genießen Sie es … 😉

Eindrücke von der SET 2009 in Zürich

Das erste meet the experts – performance im Juni war für alle Beteiligten ein erlebnisreicher Tag. Auch das zweite meet the experts – agilität am 4. September war ein interessanter Tag mit vielen spannenden Vorträgen und Diskussionen. Daher freue ich mich, bereits jetzt den nächsten Termin in dieser Reihe ankündigen zu können.Das dritte meet the experts – architektur wird am 27. November 2009 stattfinden. Das Motto dieses Events ist „Architektur in Zeiten von Agilität“. Dabei geht es nicht nur um die Verbindung von Architektur und Agilität, sondern um die Anforderungen, die die aktuellen Entwicklungen in der IT an die Architektur stellt. In Zeiten knapper Budgets, immer kürzerer Entwicklungs- und immer längerer Betriebs- und Wartungszyklen reichen traditionelle Architekturansätze nicht mehr aus. In diesem Event soll beleuchtet werden, welche Herausforderungen sich aus dieser Situation für zeitgemäße Architekturen und Architekten ergeben und wie man sie meistern kann. Mittlerweile steht der Inhalt des Events fest und auch dieses Mal haben wir es wieder geschafft, namhafte Experten zu versammeln:<img title="Dr. Gernot Starke" src="https://media.graphassets.com/6sIL4Ti3QlqQ7O2kaD0l" alt="Dr. Gernot Starke" width="272" height="280" /><a href="http://www.gernotstarke.de/">Dr. Gernot Starke</a> arbeitet seit einigen Jahren als unabhängiger Berater für Software-Architekturen, methodisches Software-Engineering sowie iterative Entwicklungsprozesse. Er besitzt mehr als 20 Jahre Erfahrung in der Gestaltung von Architekturen und Prozessen von IT-Systemen unterschiedlicher Größe. Vor seiner Selbständigkeit wirkte er einige Jahre als technischer Direktor des „Object Reality Center“, einem Joint-Venture mit Sun Microsystems sowie als Entwickler, Berater und Projektleiter bei verschiedenen Unternehmensberatungen. Er ist Mitbegründer von arc42, dem freien Portal für Software-Architekten. Aus seiner Feder stammt der praktische Leitfaden „Effektive Software-Architekturen“ (3. Auflage, Hanser-Verlag 2008) sowie „Software-Architektur kompakt“ (Spektrum-Verlag, 2009) und weitere Bücher zu agiler Entwicklung, Design-Patterns und SOA. Gernot hat an der RWTH Aachen Informatik studiert und in Aachen und Linz über Software-Engineering promoviert.<img loading="lazy" title="Martin Lippert" src="https://media.graphassets.com/TP6ZbNU5RmSZGlzLW3nL" alt="Martin Lippert" width="272" height="280" /><a href="http://www.it-agile.de/">Martin Lippert</a> arbeitet als Senior-IT-Berater für die it-agile GmbH in Hamburg und hilft Teams und Organisationen, agile Methoden erfolgreich einzuführen und umzusetzen. Er verfügt über 10 Jahre Erfahrung aus agilen Softwareprojekten als Projektleiter, Coach und Entwickler und ist Experte für große objektorientierte Systeme, flexible und hochgradig modularisierte Architekturen und Refactoring-Techniken. Er ist regelmäßiger Sprecher auf nationalen und internationalen Konferenzen, Autor diverser Artikel und Co-Autor von Büchern zu Extreme Programming, Refactoring und Eclipse. Darüber hinaus arbeitet Martin an der Integration von Aspect-Weaving in die Equinox-OSGi-Runtime, um die Modularisierungstechnologien OSGi und AOP nahtlos miteinander zu verknüpfen.<img loading="lazy" title="Stefan Zörner" src="https://media.graphassets.com/9CtjhdDIR22AX7QiCO5C" alt="Stefan Zörner" width="272" height="280" /><a href="http://www.oose.de/">Stefan Zörner</a> ist Anwendungsarchitekt, Berater, Trainer und Coach bei oose in Hamburg und leitet dort den Bereich Software-Engineering. Zu seinem Erfahrungsschatz zählen etliche Entwicklungs- und Beratungsprojekte bei Unternehmen und Organisationen im In- und Ausland – zumeist im Zusammenhang mit Java. Sein Interesse an Verzeichnisdiensten und die Arbeit an seinem LDAP-Buch lenkten Stefans Interesse auf das Directory Project der Apache Software Foundation. Sein Einsatz dort führte 2005 zur Wahl in den Kreis der Committer dieses Projektes, in dem er noch immer sehr aktiv mitarbeitet. Stefan spricht regelmäßig auf Konferenzen und ist Autor zweier Bücher und zahlreicher Fachartikel (u.a. bei IBM developerWorks). Zuletzt zeichnete er im Java Magazin für die Kolumne zum Thema „Architekturen dokumentieren“ verantwortlich.<img loading="lazy" title="Uwe Friedrichsen" src="https://media.graphassets.com/mEP4u7U4R2ylLxtF5S0j" alt="Uwe Friedrichsen" width="272" height="280" /><a href="https://www.codecentric.de/">Uwe Friedrichsen</a> ist seit vielen Jahren in der IT tätig und leitet derzeit das Competence Center Architektur bei der codecentric GmbH. Er hat langjährige Erfahrungen als Architekt, Projektleiter, Berater und Entwickler. Seine Schwerpunkte sind Software Architekturen und Unternehmensarchitekturen im Kontext agiler Konzepte. Aktuell beschäftigt er sich intensiv mit den Herausforderungen flexibler und nachhaltiger Architekturen in der Praxis. Darüber hinaus verfasst er regelmäßig Artikel und hält Vorträge in den Bereichen Architektur, Agilität und Software-Engineering.Diese vier Experten beleuchten das gegebene Motto jeweils von ihrem Standpunkt aus und bieten Ihnen so ein breites Spektrum an Ansichten und Einsichten zu dem Thema an. Konkret sieht die Agenda für das meet the experts – architektur folgendermaßen aus:1. Uwe Friedrichsen: „Design for Maintenance“ in der PraxisDie IT-Budgets werden immer knapper, die Entwicklungszyklen immer kürzerer und die Betriebs- und Wartungsphase von Software immer länger. Agile Ansätze treiben diese Entwicklung auf die Spitze, da die Software praktisch mit Ende der ersten Iteration in die Betriebs- und Wartungsphase übergeht. Traditionelle Architekturansätze reichen häufig nicht mehr aus, um diesen Herausforderungen gerecht zu werden. „Design for Maintenance“ geht auf diese Herausforderungen ein, indem es zum Ziel hat, die Architektur einer Software so zu gestalten, dass sie möglichst gut auf die Anforderungen von Wartung, Weiterentwicklung und Betrieb vorbereitet ist und so die Einsparpotentiale dieser im Lebenszyklus einer Software dominanten Phasen zu erschließen. Die Frage ist nur: Wie geht das in der Praxis? Dieser Vortrag erläutert die Prinzipien und Potentiale von „Design for Maintenance“ und gibt dann eine Reihe allgemeiner und konkreter Empfehlungen zur Umsetzung in der Praxis, veranschaulicht mit Hilfe einer Reihe von praktischen Beispielen.2. Martin Lippert: Modulsysteme und ihr Einfluss auf ArchitekturenIm Java-Umfeld wird derzeit viel über ein zukünftiges Modulsystem für die Sprache diskutiert. OSGi wird dabei als ein möglicher Kandidat betrachtet, der sich in den letzten Jahren als ein tragfähiges dynamisches Modulsystem für Java-basierte Systeme etabliert hat. In Rahmen dieses Vortrags betrachten wir die elementaren Eigenschaften solcher Modulsysteme und diskutieren, welchen Einfluss sie auf die Gestaltung und Umsetzung von flexiblen Architekturen für große Business-Anwendungen haben. Wir widmen uns Fragen wie beispielsweise:<ul><li>Wie verändern sich Architektur-Vorstellungen, wenn eine starke Modularisierung und Komponentisierung des Systems eine wichtige Rolle spielt?</li><li>Wie helfen mir Modulsysteme, große Systeme über einen langen Zeitraum hinweg flexibel weiterzuentwickeln?</li><li>Wie kann eine flache Aufwandskurve auch über Jahre hinweg erhalten bleiben?</li></ul>Eine spannende und kontroverse Diskussion ist garantiert.3. Stefan Zörner: Steht alles im Wiki? Architekturen effektiv dokumentieren und kommunizierenDokumentieren zählt nicht zu den Lieblingsbeschäftigungen in Entwicklungsprojekten. Gerade Architektur und Entwurf einer Softwarelösung werden in vielen Fällen gar nicht oder zumindest nicht angemessen dokumentiert. Wenn dann später Umbaumaßnahmen am Softwaresystem anstehen oder Neue ins Team kommen, wird klar: Ziele, Entscheidungen und Strukturen sind nicht mehr nachvollziehbar, die Lösung ist (Zitat aller) „historisch gewachsen“. Dieser Vortrag stellt einige bewährte und praxiserprobte Arbeitsergebnisse vor, mit denen Sie Softwarearchitektur frei von unnötigem Ballast festhalten können. Sie unterstützen Sie dabei, Ihre Konzepte im Team zu kommunizieren, anstatt sie zu vergessen.4. Dr. Gernot Starke: Software-Architecture-by-ExampleWie entstehen eigentlich „gute“ Architekturen? Wie treffen Software-Architekten auf Basis unklarer und widersprüchlicher Anforderungen denn Entscheidungen, die Basis für flexible und robuste Systeme darstellen? Anhand realer Beispiele erfahren Sie, wie das in der Praxis funktioniert und wie Sie selbst solche Entscheidungen systematisch angehen. Außerdem erfahren Sie eine Menge über die Kommunikation zwischen Software-Architekten und den anderen Projektbeteiligten.Trotz teilweiser englischer Titel sind die Vorträge selbst natürlich alle auf Deutsch. Das <a href="http://www.meettheexperts.de/">meet the experts</a> wird in bewährter Weise durchgeführt, erstklassige Rahmenbedingungen, Vorträge und ein “Open Space”, um auch Themen platzieren zu können, die den Teilnehmern am Herzen liegen, sich aber nicht in den Vorträgen wiederfinden.Die Anmeldung zum Event ist freigeschaltet und ich würde mich freuen, Sie am 27. November beim meet the experts – architektur begrüßen zu dürfen.

meet the experts – architektur | 27. November 2009

Just a thought …A few days I read the following citation:<blockquote>“Perfection is reached not when there is no longer anything to add, but when there is no longer anything to take away.” (A. Saint-Exupéry)</blockquote>I thought about it for a while and from my perspective there is a lot of truth and wisdom in this short sentence. But then I started thinking about IT … One should think that confronted with more and more complexity we should strive for that kind of perfection by getting rid of anything that we do not absolutely need to accomplish our goal. At least that is what I would expect. But when looking around most of the time I see exactly the opposite. We pile up more and more complexity around us no matter if we need it or not. Just to name a few examples:<ul><li>To make things more comprehensive we invent new elaborated templates for everything and anything every day, starting with more than detailed requirements templates and ending in support processes that take several hundred or thousand pages of description … templates and rules that take weeks and months to understand and that make sure that the content is way much harder to understand than it was before … at least for the “normal” people.</li><li>To avoid ambiguity we create models that would take up whole walls to show them. No one will ever understand them altogether, but still we create them. And if is not enough we start creating meta models and meta-meta models to make sure that we lose the last people who had an idea of the model.</li><li>By trying to get things done easier we use products that have so many features that we will probably never use more than 3% of them … and we also integrate those products in our application landscapes.</li><li>To save a few keystrokes we plug so much stuff into our IDEs that no one knows anymore what is going on “backstage” and we are lost in all the “magic” that is going to happen.</li><li>Again in our never ending search to get things done easier we create so many frameworks and we are so keen about using as many as possible in one application that we are completely lost in understanding the technology and resolving all the resulting integration issues and do not have any time left to deal with the applications purpose – you know, that “business stuff”.</li><li>With all those tools we create applications of such a complexity that no one really understands anymore what is going on inside the application, neither the users nor the poor developers who try to implement a new feature within those code nightmares without breaking the whole system.</li><li>And just because we can and some business department guy or lady thinks this might possibly become useful some day we interconnect everything in our application landscape no matter if it provides real business value or not, this way creating a web of dependencies that no one really understands anymore.</li></ul>I could probably go on for hours, but I think you got the point, and I am sure that you could instantaneously add some more examples. We regularly succeed in turning something simple into something complicated by adding more and more stuff to it no matter if it serves the goal or not, until it develops complex behavior, i.e. that it becomes incomprehensible and unpredictable.By trying to deal with the limits of our brains or sometimes just because of our laziness or our fear of decisions we pick the worst alternative very often: We add complexity instead of removing it.When I look at this trend within the IT that everything becomes more and more complex I think it is urgently about time to change course. Instead of complaining about more and more complexity around us we should try to avoid it wherever we can. Again, just to provide a few examples:<ul><li>No one requires us to do things as formal as machines. We are humans and we should interact like humans. Yes, we make mistakes because we are human (it’s part of our nature) but altogether we do not make less mistakes if we try to behave and communicate like machines, i.e. more and more formal.</li><li>Nobody needs models that no one understands. A model serves communication in the first place, the sharing of knowledge; and if nobody understands it there is nothing to share. I would rather have a simple model that I can share with everybody than a complex model that cannot be shared, no matter how precise it is.</li><li>Nobody urges us to use every plug-in for our IDE and every framework for our application that is around. I had a colleague a lot of years ago when design patterns were “all the rage”. He proudly told us one day that he managed to implement each design pattern of the “gang of four” book within his code. Alerted by this statement the rest of the team took a look into his code. After doing this we decided to throw away all the code that colleague ever wrote for the project and to rewrite it from scratch because it was brittle, error prone and not maintainable at all. The same thing usually is true for your IDE and your source code if you use too many plug-ins or frameworks or whatever.</li><li>And do we really need to implement each and every requirement some business guy or lady postulates without questioning it? I mean it is the very own right of the business departments to ask for everything and anything without thinking about the consequences it might have on the technical side. It is not their job to think about the technical consequences and usually they do not have the required knowledge to do that. But it is our job to talk to them, to show them the consequences (in a non-technical language, please), to show them alternatives, to help them to make the best decision by showing them the whole picture. And quite often they will pick the best alternative then, one that is quite often less complex than the initial one.</li></ul>However, this is not a black or white story. There is not “the” solution to our dilemma and simplification beyond recognition does not help either. But I think it is about time for all of us to avoid complexity wherever we do not need it, that we try to push back to the amount of complexity our brains are capable to deal with. Or, to close this with another citation I like a lot:<blockquote>“Less is more!” (Mies v.d. Rohe)</blockquote>As I said at the beginning: Just a thought …

Perfection in the IT – or “less is more”

What is the common story that you usually hear about agility? Yes, most of the times it is something like this: Agility was invented by a bunch of frustrated developers who had enough of big, big processes that did not work out and dozens of artefacts that did not deliver to the final product at all. They fought all those evil V-models, RUPs and however those cumbersome process monsters were named by inventing some nice, lean and agile principles they called Scrum, XP and so on. And since then they kept on with their heroic fight to free the developers from their 800 pound process burden and to carry agility into those centres of backwardness, i.e. the management and the business departments to make the developers lives worth living again. That’s sort of the story you know, isn’t it? Now, here at codecentric we know a quite different story. Practicing agility for quite a while we had the opportunity to be part of the first agile projects that some of our customers implemented. Most of the times those customers had a tough deadline to meet or something similar that would not work with their standard processes and they had heard about the speed of agility. And, to make a long story short: At some point in time we were there to implement the project in an agile fashion. But throughout the implementation of those projects our observations were often quite different than you would expect it from the “common story”:The business departments simply *loved* agility! They were happy that they had fast feedback cycles and somebody who was going to have a real communication with them, not just urging them to write another formal document whenever they had a problem or a requirement. They loved to see their vision growing in short iterations and having the opportunity to fine-tune their own ideas. They even loved to figure out where they were wrong with their initial ideas because they had the opportunity to change it easily and to improve the final product a lot that way. They were simply happy and they never wanted to do a non-agile project again if they had the choice.The management also was quite fond of agility. The business management liked it because their departments loved it and the IT management liked it because the business management stopped complaining, about delivering too slow, putting too much workload on their folks, and so on. Okay, with the IT management it wasn’t always love on first sight. They often were quite suspicious about that agile stuff because they had no idea what it would mean for them if that would really become a big success. Sometimes those managers secret hope was that this agile project would fail. Then they would have shown to the business folks that all this agile stuff does not work out either and that they can stick to the way they did it before. On the other hand, when the agile project turned out to be successful they liked the part that the business people were quite happy.And then there were the developers, those guys from the customers IT department who should be lucky that finally they are allowed to work agile, after all those years, shouldn’t they? Surprisingly, most of them weren’t lucky at all! They liked their processes and artefacts very much and most of the time they were pushing towards “more formalism”. They felt save in the world that they built up throughout the last years. Whenever something went wrong in the former years they added another piece of formalism, another process step, another artefact. They had built their own comfortable world within the bounds of their processes. Everything had its place and its order. Everything was defined in their processes and things that were not described in their processes simply were not allowed. And the best part of it: No one had to take over real responsibility for any failure. As long as you comply with the processes you have done everything right and if something goes wrong it must be the fault of someone else. So, simply do whatever the process tells you and you are safe! Whew, what a relief!You can imagine that agility with its focus on the product instead of the process, with self empowered teams who take over responsibility for the result, with its enforcement to communicate with business people to clarify things instead of simply rejecting specifications, this whole strange agile thing wasn’t exactly the thing those developers were looking for. It actually scared the shit out of them! It made them feel really uncomfortable. They did not know how to deal with this and they always had that creepy feeling that they could be responsible if something would go wrong. No, they weren’t lucky at all!Yes, I exaggerated it a bit to make the point plain, but: That is not a problem of some particular customers of ours. That is something that you can find throughout the whole industry and we had a lot of talk and discussions with many other agile protagonists who approved that observation we made. And it is not that those developers don’t like agility because they are “evil” or “backward” or whatever. They are simply insecure. They built their well organised comfort zone for many years or they were forced into that comfort zone and they simply haven’t learned yet how to deal with this agile way.And what is the moral of the story? Yes, it takes a lot of change management efforts to introduce agility successfully into a company, but … *but* quite often it is not the business departments that we have to prepare for agility; it is the IT departments that we have to prepare for agility. Strange, isn’t it? … 😉A short “disclaimer”: I am not talking about *all* developers. I know many of you have an agile mindset and really love to work the agile way. But on the other hand there is still that huge mass of developers around who do not want to become agile or at least do not know how to change, and I think it is those people we have to focus our change efforts on, not on the business folks.

The fairy tale of the agile developer

Meanwhile, there is a debate for a long time whether architecture and design are the same thing or not. The advocates of the “both are the same” thesis say that architecture is basically the first stage of design, while the opponents of this thesis claim that architecture and design are completely different tasks that just share some more or less fuzzy line of contact. So, who the heck is right?I think it is really hard to find out who is right or wrong … actually I think it is sort of impossible. Even within our small company we are not able to get a common agreement about what exactly architecture is and what design is. And if it is not possible to get to an agreement within a few people (even if some of them are strong characters … 🙂 ), how should we come to an agreement within the whole IT community? It is probably impossible.Thus, I will not try to find a precise answer for that question. Instead I will try to approach the topic from a different angle. First, why is it so hard to answer the question? I think a big part of the problem is that there is no satisfying definition for both terms available, neither for architecture nor for design. So, whenever you talk with another person about architecture or design you can almost be sure that he or she will talk about something different than you do.I mean there are *lots* of definitions available but most of them are so specific that they do not capture the topic sufficiently or they are so vague that they do not help at all. Just for instance, Robert Martin (who said and wrote a lot of very smart things, btw) once stated “Architecture is about the important stuff. Whatever that is.”. Now, this means everything and nothing. Does it mean that design is about the unimpotant stuff? Probably not. And, if coffee is really important for the developers (which it usually is), does it mean, that architecture is about coffee? Probably not. As you can see this definition does not really help.I will not go into detail for other definitions because I think it will not lead anywhere. It won’t be possible to find a definition for architecture and design that everybody will agree upon *and* that will help us to figure out the difference between architecture and design. Especially I think it won’t be possible to find a clear separating line between architecture and design, where the one thing ends and the other thing starts. Everybody draws his line somewhere else and many people probably rather have some kind of fuzzy cloud in mind instead of a sharp line. “Somewhere within that cloud architecture stops and design starts” they will say.Okay, but there must be something that might help us. At least there should be something …Maybe it does help to step away from that question for a moment. From my experience I figured out that there are two basic tasks that make up that whole architecture and design thing (without trying to find the separating line). The whole thing is about transforming all the requirements that are around into a result. (Btw: If you would ask where the coding is in there, I think I would leave it up to you to find the separating line between design and coding; I think it is a similar question … 😉 )The first part of that transformation task is to understand all the requirements (not just the business and user requirements, but also the requirements of the mangement, the project management, the development team, operations, system planning, the security department, the testers, and so on), really understand them, to balance them (there are always conflicting and inconsistent requirements across the different domains and stakeholders to deal with) and to find an appropriate solution idea for all those balanced requirements. I usually call this part of the work “alignment”.The second part of the transformation into a working solution consists of turning the solution idea into an appropriate structure that supports maintainability and changeability, and refine the structure over and over again until you are down at the code level without losing the properties described before. I usually call this part of the work “structuring”.Now, is it important to distinguish those two tasks? I think, yes! The reason for this is that I figured out that those two tasks require very different skills. While alignment has much to do with communication and conflict management skills, structuring requires more formal strengths. Also alignment requires kind of a broad knowledge about all the different requirement domains while structuring requires more of a deep knowledge about the solution domain. As a consequence, you will find quite few persons who are capable (or willing) of doing both tasks with the same strength, and if you neglect one of the two tasks you will most likely get an unsatisfying result.Okay, getting back to the initial question. Will alignment and structuring help us to find a separating line. I think, sort of …From my perspective, alignment is definitely part of any good architecture while structuring is definitely part of any good design. You cannot be a good architect without doing a lot of alignment and you also cannot be a good designer without doing a lot of structuring. How much of structuring is required in architecture and how much of alignment is required in design, I think that is mostly a matter of taste and there won’t be a definite answer to this.So, I also cannot provide you with “the” answer to the initial question. But I know, if somebody talks about architecture without talking about alignment he does something wrong and if somebody talks about design without talking about structuring he also does something wrong. And that is the most important thing from my point of view …PS: My apologies to Robert Martin for picking on his definition of architecture. As I wrote before he said and wrote a lot of really smart things, even though I do not agree with all of them. So, if you have the opportunity to read some of his stuff or listen to a presentation of him, just do it! Now, that should be enough of indemnification … 😉

Is there a difference between architecture and design?

Yesterday I attended the Agile Day on the JAX 2009 in Mainz. I do not want to rate the talks in any way. Since was one of the speakers, it just wouldn’t make much sense … 😉 … but I want to share a few personal impressions I had.First I was surprised how many people attended the agile day. There were at least 300 persons, throughout the whole day. This showed me in a very impressive way that people are really interested in agility these days. In a short poll about half the people said they are using a few agile practices but they are not really agile. Most people of the other half said they are not doing any agility at all at the moment but they are interested in the topic. And just a few people stated they are doing real agile software development and most of them were speakers. For me that showed that there is still a long road to travel in the area of agility but many people started moving which is good.The second interesting impression was a Pecha Kucha session. Stefan Roock organized that session. There were 6 speakers doing a presentation, each with exactly 20 slides, which are shown exactly 20 seconds each, 6 minutes and 40 seconds altogether. These are the rules of a Pecha Kucha presentation. For me it was really interesting to attend such a session. I have read about it before but I haven’t attended a Pecha Kucha session up to yesterday. I liked the short duration of the presentations. It urges the presenters to focus on one or maximum two ideas and keeps them from lengthily talking about dozens of things. On the other hand the strict format was quite distracting for me. Most of the time the slides were shown a bit too long or too short for the things the speakers had to say about the slide. So quite often they had either to wait or to hurry up. And I always was distracted somehow waiting for the next slide to show up. In summary it was an interesting experience for me but I don’t think that this very strict format is very helpful in most cases. I think short sessions – i.e. 10 minutes or less – are a good format but they shouldn’t be that strict.The last interesting impression for me was the speaker panel at the end. It wasn’t the panel discussion in itself. Those I have seen many times. It was the fact that even the agile experts that stood there still had quite different viewpoints on the topic agility. I mean on the one hand that is quite normal for many topics but on the other hand it is always quite surprising to experience that live within a panel discussion. I think it shows that agility is still not a too well explored area that yet has a lot of evolution to go through.

This is a reflection of the meet the experts – architecture that took place at codecentric in Solingen at November-27-2009.Since the whole event including all talks was held completly in german an english version of this reflection would probably not be very expedient. Thus I decided not to translate this announcement.You can read the full version of the reflection if you switch the language to german (by clicking on the german flag in the upper left corner of this page).Beyond that we will – of course – carry on providing an english version of our blog entries.

meet the experts – architecture | November-27-2009 – a reflection

Many “conventional” project manager are quite offish about Scrum or they even reject it completely. One of the reasons for this behaviour is that they cannot identify with Scrum since there isn’t a role “project manager” in Scrum. Throughout our Meet the Experts – Agility had the opportunity to talk a bit about this topic with <a href="http://borisgloger.com/">Boris Gloger</a> .Before, within an open space session Boris had presented his point of view on the role Product Owner. Throughout this presentation I realised that this role has a lot more elements of the conventional project manager role than I thought before. I got the perception that the responsibilities of the conventional project manager became distributed across the roles Product Owner and Scrum Master in a certain way. Having this picture in mind I asked Boris about it and he confirmed my perception. To be exact, he even extended it a bit: From his point of view the conventional project manager role is overloaded and there is hardly a person who is capable to fulfil all responsibilities of this role in a reasonable way. On the other hand in Scrum the role is split up the following way:<ul><li>The Product Owner is responsible for direction (the vision), control with regard to content (Product Backlog) and the budget. He is the one who sets the direction and drives development with regards to content. He also tries to make the most of the available budget. No matter how the project looks in detail – since the features that promise the highest business value are relatively also the best funded features, the pursuit of making the most of the budget automatically leads to a priorisation of the features by their business value. Now, this might not sound “noble and pristine”, but in practise this works surprisingly well … 😉</li><li>The team is responsible for planning the implementation and sticking to its plan, i.e. the whole detail planning and controlling tasks. Using concepts as sprint planning, commitment on the negotiated sprint contents and team responsibility for the implementation, it is much better guaranteed that expectations and results fit together than in conventional projects.</li><li>Finally the Scrum Master is the “care taker”: He takes care of the pizza if it becomes late and he smoothes the impediments out … but he is also the guy who looks over the teams shoulder and reminds it of its commitments if necessary. He makes sure that everybody fulfils his individual role and he cares for the best working conditions possible.</li></ul>This way the responsibilities of a conventional project mangager are split across the three Scrum roles in a quite straightforward fashion. Thus, if a project manager wants (or sometimes is urged) to move into Scrum it is quite easy for him to select the appropriate role. He should figure out for himself honestly which part of the project manager role he likes the best:<ul><li>If he likes most to drive a project with regard to contents and has a way with budgets, he should take the Product Owner role.</li><li>If he is more of a “care taker” and loves to make sure that a project is running smoothly, he should take the Scrum Master role.</li><li>If he became project manager in the first place because he was simply too good in his former developer role and somehow slipped or grew into the responsibility this way, he should become part of the team best and enjoy to push the project along with his own effort.</li></ul>Alltogether Boris point of view makes a lot of sense to me. Especially I think that this way the critical responsibilites for project success of the conventional project manager role are split up well across the three Scrum roles. Also I think that these responsibilities are handled much better by three persons than by one person.Anyway, one point Boris left out in his presentation: There is a kind of conventional project managers that can be met quite often. I like to call them “pure project managers”. They manage projects in a pure formal fashion without having a deeper insight of the project contents. They limit themselves to manage plans (whoever created them) as well as escalations. They posess distinct controlling knowledge, sometimes also good political skills. Following the “management by spreadsheet” metaphor (management on the basis of key figures only neglecting the underlying business contents) they do a “project management by spreadsheet” and some of them are even proud of the fact that they don’t know anything about the contents they manage (“I can manage any project no matter what it is about.”).Now, for this kind of project managers Scrum actually has no usage. Following the lean principle “Eliminate waste!” Scrum avoids any kind of dead freight and focuses solely on those aspects of the project manager role that provide added value, i.e. add directly to project success. And since real success can be judged finally on the basis of the produced results only, a person that cannot contribute to the project contents, to the actual result is not needed in Scrum. The only question left is, if such a person is needed outside of Scrum …

The conventional project manager in Scrum

Inline comments within code are “evil” and everybody who still uses inline comments today is a really, really bad developer and should get his license revoked. That’s what seems to be consensus throughout the developer community … or at least throughout the “up to date” community.Okay, but I say that we need more inline comments. So, what’s wrong with me? Have I gone completely nuts?Now, while answering the last two questions might be a difficult task … 😉 … my idea about inline comments is quite straightforward:If you want to understand any kind of solution, i.e. whenever you need to implement some new feature within an existing, yet unknown code base, you need at least three essential questions to be answered:<ul><li>Why?</li><li>What?</li><li>How?</li></ul>So, how will you get these questions answered without having the original developer at hand?<ul><li>The “How” is simple. That is the code in itself. Thus, it definitely makes sense to write the code as understandable as possible that everybody else will understand the “How” as easy as possible.</li><li>The “What” is usually the domain of the class/method/function/… header. The comment header describes “What” the piece of code down below is meant to do. In Java that is the domain of the Javadoc, other programming languages have their own means or conventions for that.</li><li>But where is the “Why”? The code itself cannot answer the question for obvious reasons and the Javadoc, etc. is not meant for this. It has to focus on the “What”. You could put the “Why” part to a separate artifact, an extra document, i.e. a design document or whatever. But that is quite cumbersome. Also there is a high probability that any changes, refactorings, etc. in the code wouldn’t find their way into that document so that it becomes obsolete quite fast. Hence, it would be better to place the answers to the “Why” questions right at the place where you can see the effect of the corresponding decision, right next to the code that shows “How” the decision of the “Why” question was implemented.</li></ul>That’s where inline comments come in handy. They provide a perfect means to describe rationale for certain decisions that you find within the code. Whenever you think “Why the heck did he or she implement that piece of code this way?” it would be just perfect to find an inline comment right next to the piece of code that answers that question, wouldn’t it? But today most of the time you will look in vain for those answers. Instead you might have to ask the original developer if he or she is still around and remembers that decision or that knowledge is gone for good and you have to guess the rationale.Thus, for me the domain of inline comments is answering “Why” questions and from my experience from a maintainability and changeability perspective (that’s where the architect inside kicks in 😉 ) understanding the “Why” is often a lot more important than understanding the “What” … and the “How” is laid out in the source code anyway.That’s the reason why I say that we need more inline comments<ul><li>not for explaining the “What”, that’s the domain of the header comments</li><li>not for explaining the “How”, the code should answer that by itself</li><li>but for answering those “Why” questions, to provide the rationale for design and implementation decisions that are missing most of the time</li></ul>Therefore here’s my concluding tip for you:Kick that rule off your coding standard that says<blockquote>“You are not allowed to use inline comments”</blockquote>and replace it with<blockquote>“You should use inline comments only to explain (non-obvious) design and implementation decisions (“Why” questions) … and don’t forget to use them for this purpose!”</blockquote>

We need more inline comments!

I read statements like “the cloud isn’t actually new”, or a bit harder “it’s just old wine in new skins” over and over again.Yes, you can think about it that way but I have my difficulties with those statements. Why?Disruptive innovations (those innovations, that really change something) don’t need fundamentally new ideas. Actually the fewest innovations, that really changed something, entirely consisted of all new ideas.No matter, if the Ford T, the PC, the passionately loved and hated MS Windows or the smart phones … all of them weren’t new ideas but a recombination of known ideas at the right time, i.e. the market was ready for them, both form a market demand point of view and from a delivery capability point of view (the capability to deliver the “new” product in an appropriate quality). As a counter example the Apple Newton certainly was a great product, but the market wasn’t ready for it.Thus, the “revolutionary” thing about the cloud isn’t its parts, but their combination and the timing.So, for me the actual innovation about the cloud is that combination of elasticity, flexible pricing models (to the point of the often used pay per use model), customer self service and instant delivery. Yes, each of those ideas is around for quite a while, but this combination is new, a real innovation with disruptive potential.It’s a bit as with an extraordinary meal: The ingredients are well known, you can get them on the market or in your favorite store, but their combination and the preparation turn them into somthing extraordinary. I know, this comparison isn’t working too well since an extraordinary meal doesn’t depend on an appropriate timing. That would rather lead us to fast food, which was a disruptive innovation in its time … but if that still has to do with extraordinary meals? … 😉For those reason I have some difficulties with the statements I mentioned in the beginning. The innovation nature of an idea does not depend on the innovation nature of its parts, but on their combination … and of course on the timing.Given this, for me the cloud fulfils the prerequisites of an actual disruptive innovation. If it really will become one we will see, when the hype mist that covers the cloud at the moment is going to clear up …

Cloud: An innovation or just old wine in new skins?

It’s christmas holidays and as many other people I use that time to goof off a bit – no big visits of relatives, no big vacation trips, just hanging around at home and making sure not to do too much at all. But as many other people after the first few days I start doing odd things, namely cleaning up things here and there. So, this morning I spent some time sorting out things in my office at home I don’t need anymore.In doing so I found some notes I took 2008 at the <a href="http://www.irmuk.co.uk/eac2008/" target="_blank">Enterprise Architecture Conference in London</a> . Even though it was a great conference I decided that I don’t need most of the notes anymore and threw them away. But there was one sentence on one of the pages that made me pause for a while. It seems that it was a sentence from a keynote that David Robertson, a professor from the Switzerland held. The sentence seemed to be so important to me at that time that I noted it down (I’m not a big note-taker, so it must have been important to me).The sentence was: “Architecture is a compass, not a blueprint”. In brackets, I added a “Rethink that!” as a reminder for me to come back to that sentence. Okay, it seems that it took me more than 3 years to come back to that sentence and from todays perspective I think, it actually is an important sentence – one of those timeless sentences.From my todays perspective it perfectly describes what architecture should be and what it shouldn’t. Architecture should be a guidance towards the right solution in a terribly complex environment where even “right” is an extremely complex thing that isn’t obvious and hard to find. Therefore, we need to watch the environment once in a while from several distant (i.e. more abstract) points of view, just with the goal to come back then and to say “From what I saw over there I think it’s a good idea to follow that path for a while”.After that we take the next steps and then we observe again to decide about the next steps and so on: architecture as a compass. We usually cannot draw a complete map (i.e. a blueprint) from our territory upfront. It is just way too complex. And usually you don’t need that big, thorough map at all. Usually it is enough to take a few notes about the basic perceptions you had at the distant points of views (overview pictures and high-level concepts) and the rationale for the most important decisions – just in case you come back to that point and you want to comprehend why you did it then the way it is done.Architecture as a compass also has a second meaning: Architecture is dynamic, not static. Architecture is not a goal, it is part of a journey. It changes over time. It evolves. It changes if the terrain changes, it changes if you learn something from your former steps. While an outdated map doen’t help you anymore at all a compass will always stay useful – but only if you accept that it is not a solution in itself but just a valuable aid to find the right direction on your journey through uncharted complex territory.I think we also could get rid of many of these annoying discussion about architecture – especially in conjunction with agility – if we all would accept this one sentence: “Architecture is a compass, not a blueprint”. Architecture is not a map to the solution, it is a means to find the right way.There is for sure a lot more to write about this sentence but it’s christmas holidays and I don’t want to do too much at all … 😉

Architecture is a compass, not a blueprint

You might ask yourself how emergent architecture is related to scalability and fault tolerance. To be honest: Not at all. With this short blog post I just want to give you a pointer to a few recent presentations I finally managed to upload to Slideshare.First of all there is a new presentation about fault tolerance patterns in the context of scale-out solutions: <div> <a href="http://www.slideshare.net/ufried/no-crash-allowed-fault-tolerance-patterns" target="_blank">No crash allowed – Fault tolerance patterns</a> <div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>A few days ago I also uploaded a related presentation about high-scalability patterns:<div> <a href="http://www.slideshare.net/ufried/scalability-patterns" target="_blank">Scalability patterns</a> <div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>And finally I would like to mention a presentation about the opportunities and limitations of emergent architecture, I also uploaded a few days ago:<div> <a href="http://www.slideshare.net/ufried/emergent-architecture-12620741" target="_blank">Emergent architecture</a> <div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div><div> View more <a href="http://www.slideshare.net/" target="_blank">presentations</a> from <a href="http://www.slideshare.net/ufried" target="_blank">Uwe Friedrichsen</a> </div></div>As always, the “audio track” is missing but I tried to design the slides in such a way that they are not completely useless without the audio.And also as always, I am interested in your opinion and feedback. Thus, if you have any comment about the slides, just let me know …

Scalability, fault tolerance and emergent architecture

Let me start this post with a bit of ranting: I am so tired to hear or read the same nonsense over and over again usually emitted by people obviously hardly knowing what they are talking about.What am I ranting about? It is about this stupid argument that Agile does not need an architect because Scrum does not know about this role. Aaaaaaaarrrrgh, could scream about that nonsense!Do not get me wrong: I do not think that you always need an explicit architect — not at all. There might be reasons to have an architect on your project, there might be reasons not to have one. That is not the point.It is the mindless argumentation usually used that annoys me. It goes like this: “Scrum does not define a role Architect and therefore an architect is not needed in an agile IT project. Case closed. Period.”I hoped we left this mindless argumentation behind us several years ago but I still hear this crap over and over again — usually either by some blindfold agile disciples trying to justify their point of view this way or by some agile deniers trying to start a rant right after this claim.I just read it a few days ago again in a session abstract of a big, well-known German conference. And it was not meant as a joke. The author meant it absolutely serious. Aaaaaaaarrrrgh again!Okay, I guess most of you know already what is wrong about this argumentation. For those of you who are not completely sure, let us step back and think about Scrum a bit:First of all Scrum is not an equivalent for Agile but just a tiny process framework with lots of gaps and missing bits and pieces (at least if Scrum is all you have to run an IT project). There is a lot more to Agile than just Scrum. Thus, even if Scrum does not provide for an architect it does not mean at all that Agile does not need an architect. But that is not the most important point.The most important point is: Scrum is IT-agnostic!Scrum does not know anything about IT!Or as Jeff Sutherland once told us in my original Scrum Master training several years ago: “You can use Scrum to organize your weekend.” And even though you partner is not provided as an explicit Scrum role you should better not exclude her or him from our weekend organization if you care about your relation … 😉Actually, Scrum was not developed in the IT domain at all. Scrum’s <a href="http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG" target="_blank">origins</a> are the design and development of consumer goods. Much later it became generalized and rolled out to other domains, as the IT domain.And if you look really carefully, you will figure out that Scrum also does not define roles as Requirements Engineer or Tester. Scrum even does not define a role Developer!There is just a Team and all Scrum tells us about that team is that you better make sure all skills you need to get the job done should be available in the team.Utilizing the mindless argumentation from the beginning I am really curious how anyone will get an IT project done without developers. Maybe Chuck Norris can do, but not the rest of us … 😉Conclusion: The fact that Scrum does not mention an architect role does not give any evidence if this role is needed or not in an IT project. Scrum does not mention any IT-specific role because it is IT-agnostic.Thus, please let us stop using this stupid argumentation for good. And if you should ever see someone using this argumentation again please tell him or her that he or she is talking crap. Let us all get rid of that nonsense for good.Again, there might be good reasons why you need or do not need an architect in your project but that is a different story … a much more interesting story!

Agile, Scrum and the nonsense about architects

Currently we can observe three mega-drivers that force IT into a dramatic change:<ul><li>Economic darwinism</li><li>Digitization</li><li>Disruptive technology</li></ul>All of them are extremely important and the companies that ignore these drivers will sooner or later fall short of their competitors (at least as long as the companies live in an efficient market – non-efficient markets are a different story).<h2>Changing markets</h2>Let’s begin with the first driver and start with a quick explanation: “Darwinism” in short means “Survival of the fittest” – and the “fittest” is not the strongest but whoever can adapt quickly enough to the changing demands of the surrounding environment.<div><a href="https://media.graphassets.com/lIroTVhXTJSEzAyV3cNo"><img src="https://media.graphassets.com/lIroTVhXTJSEzAyV3cNo" alt="Economic darwinism, digitization and disruptive technologies create pressure on IT" width="300" height="225" /></a> Mega-drivers create pressure on IT, forcing it into fundamental change</div>This is also true for companies: Only the companies that adapt quickly enough to the changing needs and demands of their customers will survive in the long (or even short) run.You might say: “Hey, where are the news? This is true since the beginning of economy.” And you are right.The key part is that the markets most companies live in changed dramatically some years ago. For almost a century most markets were broad, almost unlimited and sluggish: There was always a larger demand than supply and the biggest challenge for companies in those markets was to scale the production of their goods in a cost-efficient way.This started to change back in the 80ies: Slowly but surely one market after the other became narrower. Globalization, market saturation and the internet led to highly competitive and dynamic markets (Actually there were more drivers for the market change but that is outside the scope of this post). The markets became highly demand-driven and the new biggest challenge of the companies was to adapt to the changing demands of the customers quickly enough. The key driver changed from “cost-efficient scaling” to “responsiveness”.<h2>Changing role of IT</h2>You might say: “Yeah, I know all this. But what has it got to do with IT?”The point is that business and IT are tightly interwoven these days. You cannot consider them independently anymore even if it started quite differently:If you think about the relation between business and IT, back in the 50ies and 60ies it started with IT supporting tiny fractions of business functions – a little report here, a small analysis there. It was very selective because the computing power of the mainframes back then was quite limited (every cell phone today has orders of magnitude more computing power than the computers back in the 60ies).Yet, it was so cool for the business departments that they did not have to create their reports and analyses manually anymore that they wanted more of that – which eventually led to the software crisis: Demand for software became a lot higher than supply.The reaction to the software crisis was the invention of software engineering: An engineering practice to scale the production of software in a cost-efficient manner. Sounds familiar, doesn’t it: Industrialization had a very similar problem in the beginning of the 20th century and the solution approach back then was Taylorism and its variants. Thus, it is not surprising that software engineering picked up many tayloristic concepts and practices and adopted them to software development.And that was perfectly fine back then. But over time the role of IT changed essentially. Sometime back in the 80ies the PC started its triumphant success and networking became widespread. Also Moore’s law did its job and computers became more powerful all the time. As a result IT did no longer only support selective business functions, it started to support whole business processes. It moved closer and closer to the business with all its complexity.This development continued, the internet started its success story in the 90ies and eventually IT became the nervous system of each non-trivial company: The whole business domain coded into IT, IT outages of just a few hours considered existence-threatening by many companies. And this also implies that you cannot change your business anymore – no new products, features or process changes – without touching IT.<h2>The need for speed</h2>Combining the two observations described before, we can conclude that IT has become a critical success factor for any company to hold its ground in the economic darwinism. No matter how good you understand the needs and demands of your customers, if your IT cannot deliver fast enough you will go away empty-handed.Yet, most companies still stick to the ideas of traditional software engineering where the primary goal is scaling the production of software in a cost-efficient manner. The problem is that scaling software production and IT cost-efficiency are not the most crucial drivers anymore (we actually write way too much software these days, it just takes too long and very often just delivers a fraction of the value expected).The most crucial driver for IT today are cycle times, the time needed to bring an idea to the customer. This means the time needed to traverse the whole IT value chain beginning in picking up the requirement until it is live in production.The shorter these cycle times are, the better we can adapt to the ever-changing demands of the highly dynamic markets. We need “speed”!<h2>Tightened conditions</h2>If we look at digitization, the second mega-driver, we get an additional twist: With digitization IT no longer just supports the business, it becomes the business. We create new business products which consist partly or completely of IT. On the one hand this means the need for innovation as we just start to develop vague ideas what future business models trends like Internet-of-Things (IoT) will enable. On the other hand this means that our IT needs to be even more robust than before as it becomes continuously exposed to our customers.The third mega-driver are disruptive technologies like cloud, mobile, big data and IoT. These technologies provide very different ways to implement business needs up to a level where they enable completely innovative business models. As we are still just at the beginning of understanding what we can do with those technologies, they tighten the conditions described before:We need to understand and learn, we need to innovate, we need to adapt to ever-changing markets and we need to do it fast incorporating the new possibilities provided by disruptive technologies. And we will not succeed if we try to accomplish all this clinging to ideas developed many years ago in a very different business and IT era.We need to re-think IT!<h2>Re-thinking IT</h2>This was the short version of the much longer story why cycle times became the most important driver for IT today, why we need to re-think IT.But, if the old wisdom we still base most of our IT processes and operation on is not appropriate for re-thinking IT, what is appropriate instead?<div><a href="https://media.graphassets.com/TL2olKkYQFiwr7Qk9paq"><img loading="lazy" src="https://media.graphassets.com/TL2olKkYQFiwr7Qk9paq" alt="DevOps, microservices, continuous delivery and cloud-based infrastructure as core building blocks of a new IT" width="300" height="225" /></a> Core building blocks of a new IT, responding to the change drivers</div>This is a very valid question. A good starting point usually are organization and processes: Organizational and system theory showed that decentralized organizations with mostly autonomous units can adapt much better and a lot quicker to ever-changing demands than hierarchical organizations based on tayloristic principles. Also the decentralized organizations tend to be a lot more robust against unexpected demands.If we look around for a moment we will quickly realize that DevOps is exactly about this issue: We create mostly autonomous teams that take over end-to-end responsibility for dedicated business capabilities and we let them respond to all change demands in their capability area. Actually there is a lot more to DevOps like holistic optimization of cycle times, amplifying feedback loops in order to provide knowledge where it is needed and a culture of continuous learning. These are also very important traits of DevOps which exactly point in the direction of the drivers we have seen before.But DevOps alone is not enough. We need to make sure that team autonomy will not be compromised by the software and systems the teams are working on. For example, if we have many teams all working on a big monolith (which unfortunately has the tendency to eventually degenerate into a big lump of spaghetti code), the teams will usually need to coordinate every single change and the autonomy is gone. If we can release software only in big all-or-nothing releases, if we are confronted with a runtime mega-monolith, the teams need to coordinate all their changes and agree on a release date and the autonomy is also gone.This means we need an architectural style which support autonomy in terms of development and deployment of software. Microservices are such an architectural style. Their self-containment and fits-in-one-brain properties support team autonomy very well. They also support quick changes and short cycle times. Actually microservices are not the only style that supports the given needs and admittedly it is quite easy to screw them up and end up with a distributed ball of mud (a.k.a. “distributed hell”) but if done right, they support autonomy and quick adaption very nicely.Autonomous DevOps teams that respond to ever-changing demands also need to release their software frequently, whenever it suits their needs. And if they need to release their software multiple times per day, it must not be a problem. Deploying software independently on demand that often requires automation. A manual build, test and deployment is way too expensive and error prone to execute it frequently. This is the domain of continuous delivery which is exactly about consequently automating build, test and deployment.The last part of the picture is the infrastructure the software runs on as it also needs to be very flexible. If it takes days, weeks or months to get the required infrastructure for development, build, test or deployment, any team autonomy and responsiveness is toast. The teams need self-service access to the required infrastructure whenever they need it and they also need to get rid of it as soon as they don’t need it anymore. The cloud provisioning model exactly meets those demands. Additionally the API-based approach enables elastic scaling at runtime as well as better automation of the build, test and deployment process.<h2>Some more re-thoughts</h2>We have seen that DevOps, microservices, continuous delivery and cloud computing are core building blocks of a new IT. But is that all we need for our new way of IT or are there missing pieces?<div><a href="https://media.graphassets.com/ZI4DdEpRYyI7IpyegEHg"><img loading="lazy" src="https://media.graphassets.com/ZI4DdEpRYyI7IpyegEHg" alt="Beyond budgeting, EAM re-thought and craftsmanship as supporting topics of a new IT" width="300" height="225" /></a> Building blocks of a new IT, including supporting topics</div>Actually some supporting pieces are missing. The first one is Enterprise Architecture Management (EAM), but not the way we know it. There is not any value in drawing lots of pictures ahead and centrally trying to pre-plan and prescribe the overall IT landscape in detail right from the ivory tower. This will be a bottleneck by default and is quite the opposite of what DevOps is about.Yet, there are some important tasks in a DevOps organization where EAM can create a lot of value: Even though the teams should be as independent and autonomous as possible they still need to work towards a common goal. EAM can help to spread the common goal and help the teams not to lose track of the big picture.Secondly, total team autonomy is not possible as all team work towards a common goal and the software they produce need to work together. This means coordination. The teams need to agree mutually upon how their software interacts with each other. This can become quite cumbersome and inefficient if every single interaction is agreed upon from scratch. Thus, it makes sense to agree upon some interaction standards across all teams. Finding and maintaining this minimal set of standards is also a good task for EAM.A different definition is that EAM takes care about the big picture and the space between the responsibilities of the teams. One last remark about EAM: Usually this is not a full-time job and there should not be an ivory tower EAM team in charge. Instead the EAM team should consist of agents from the DevOps teams that meet once in a while or whenever needed.The second big supporting topic is which governance model to use. We still need to make sure that the top level management’s vision and the work of the teams is in sync. It is important that we have transparence what is going on in the teams and it is also important that top level management can transport changes in direction in an efficient way to the teams.The traditional governance models of hierarchical organizations are not suitable for a DevOps organization which optimizes for cycle times and market responsiveness. This means we need a different governance model. The good news are that those governance models are known for quite a while and that they are successfully battle-tested by some big companies which adopted them. Those models are known under the name “Beyond Budgeting” or “Beta codex” (which is a further development of “Beyond Budgeting”).The third big supporting topic is Craftsmanship. Yes, it is about people (unfortunately we forget that way too often)! We need to help all the affected persons to develop a different understanding of the way they need to work.On the one hand it is important to help people becoming continuously better in the way they do their work and collaborate with their peers. This is also know as “mastery”. An “everything will be all right” attitude is just not sufficient anymore. This is the core idea of Craftsmanship.On the other hand people do not need a robust work model anymore, they need a robust change model. People need orientation – some rules and anchors they can use for orientation. In the past people were provided with a model how to do their work, either using detailed process descriptions or less formal guidelines.The problem with that approach is that the way work is done changes continuously as companies continuously need to adapt to the ever-changing needs and demands of their customers. Therefore it is not possible to provide a working model that is robust over a longer period of time. Therefore, it is necessary to provide people with a model that makes it easier for them to understand when change is needed and why. So, we go one level up from providing a robust work model to providing a robust change model. Even though this is not a core aspect of Craftsmanship it definitely belongs in that area.<h2>Wrap-Up</h2>We need to re-think IT – the markets the companies live in have changed, IT itself has changed. The conditions in which our traditional IT models were developed do not exist anymore. Our main IT driver is not cost-efficient scaling of software production anymore, it is minimizing cycle times in order to maximize the company’s responsiveness.The core building blocks for this new IT are DevOps, microservices, continuous delivery and cloud computing which need to be augmented by some additional topics like EAM (also re-thought!), Beyond Budgeting and Craftsmanship.After all, this is just the “big picture”, a 30.000ft point of view. There are many shades of grey I have left out for the sake of keeping it short – and yet it became quite lengthy. Also each building block I mentioned consists of many, many more details on different granularity levels. And there are quite a lot of details that need to be considered for not screwing up everything badly. But those are different stories …

The need for speed – A story about DevOps, microservices, continuous delivery and cloud computing

Re-use is the holy grail of IT: whenever a new architectural paradigm comes to IT town, “re-use” is one of the core arguments why to go for that paradigm. The business sales pitch typically goes like this: “Switching to <insert new paradigm here> will cost some money upfront but due to the re-use it enables it will soon pay back”.I do not know about your experiences but I have never really seen it working the promised way. No matter if you look at Object-orientation, CORBA, Component-based architectures, EJB, SOA, you name it: re-use was accomplished to a lot smaller degree than promised, which meant that the promised business case never got realized. Additionally, very often brittle and tightly coupled systems emerged after a while that were very hard to change and operate, i.e., the business case started to turn into its opposite. But fortunately, at this point in time usually the next holy-grail paradigm showed up and the cycle started over again.In short words: re-use based on any architectural paradigm never worked as promised, the promise was always broken.And today? Currently, microservices are the paradigm de jour, and – of course again – re-use is the business case promise that accompanies it regularly. Will it work this time? Have we finally found the long promised silver bullet?I do not know your opinion about it, but I am convinced that if we push for re-use in our microservice approaches, we will – once again – end up with a completely messed up architecture, including a very poor business case.This leads to the question: Why is the promise of re-use broken?There are several reasons why the re-use promise is broken. Here are my – probably incomplete – observations:First of all, good reusability is expensive. Fred Brooks many years ago coined the “Rule of 9” for a re-usable component (where “component” here solely means the basic building block of re-use, no additional semantics attached to it). Based on his observations it took about three times the effort to design a component that can be re-used properly compared to a component that was just designed for simple use. This has a lot to do with the fact that it is very hard to isolate the right responsibility in a component and then to design a good API to offer the functionality to others. It takes a lot of brain-power and trial and error to come up with such a component.Brooks also made the observation that it takes another factor of three to make the component ready for re-use, i.e., the required testing, hardening and documentation. Finally he stated that these two factors are independent, i.e., they do not sum up, they multiply. This 3 times 3 lead to the “Rule of 9”.You might say that Fred Brooks was way too pessimistic with his statements and that we cannot compare software development in the early 70ies (when he made his statements) to software development today. And you may be right. Things have changed and might have become better (even though I have not seen any evidence for that). So, maybe a factor of 9 is too high today, maybe it is just 5 times the effort to turn a simple project result into a re-usable component, i.e., the additional struggling for the right responsibility encapsulation, good APIs, additional testing, documentation and hardening.This means that you need a re-use of at least 5 times for a component that was made re-usable in order to amortize the investment, and you would need a lot higher re-use factor to justify the typical re-use business case, which claims that you do not only amortize your investment but save a lot of money over time.But if you look into the rarely published re-use numbers of SOA initiatives (Fun fact: If you search the web, you will find tons of pages that talk about, how important re-use is for SOA and how important it is to measure your re-use, but you will hardly find any page that shows real re-use numbers realized by SOA initiatives), you will realize that typical average usage factor for a service is one point something (1.x). In other words: Most services were used only one time, a few services (usually less than 20%) were used more than once. Let us recap: services, that are five times as expensive to create in order to be re-usable, in average used a bit more than one time. There goes the business case …Understanding that the business case is broken is one thing. But it is more important to realize that there is a lot less re-use than expected and thus re-use is a lot less important argument for any architectural paradigm than always claimed.After that statement you regularly find the black-and-white folks who cry out immediately “So, you are telling us that we should not do *any* re-use *at all* and *everybody* should start to write their own string library again!” – which would be nonsense of course. But polemically perverting a statement into its absolute extreme, which – as all extremes – does not make sense, is no proof that the statement itself does not make sense.The point about re-use is that mostly everything that would be re-used often enough that it makes sense to invest the effort to make it re-usable has been implemented already. These are the libraries which are usually part of a programming language ecosystem, be it that they are part of the language itself or are available as 3rd party libraries. Higher level re-usable components, especially company-specific business components are rarely worth the effort in terms of investment costs vs. re-use ratio.And even if you might have IT assets that are worth encapsulating in re-usable components, you do not need a new architectural paradigm for it: Every programming language, every communication protocol provides the means to define an interface. That’s all you need to implement encapsulation which is the basic building block for re-use. It’s all there, it’s been there all the time – nothing new needed.But we face a dilemma: we wanted to get our hands on that new, shiny silver-bullet architectural paradigm that is all the rage and thus made the re-use promise – and now we have to deliver. How is that typically implemented? First of all, we promised re-use as part of our business case. Therefore we design our whole application landscape with re-use in mind. Re-use becomes the driver of design and components must re-use each other, no matter if it makes sense or not. We promised re-use. Thus, there has to be re-use, no matter what it costs.Implementing this, we usually end up in a mess of tightly coupled components which (re-)use each other in strange ways. We especially did not take the time to understand how to design the components best, which boundaries and APIs emerge over time, which ideas work and which do not work. As we promised re-use will make things less expensive, components need to be cheap and re-usable right away without taking the efforts, Fred Brooks described, to make them really re-usable.Besides other bad effects, this leads to a very nasty kind of premature optimization: We try to guess in which way a component might be re-used and as we usually have no real idea about it at the time of the initial design, we just take our first guess and throw it at the world. And because we don’t know anything about our potential users, we just create a “generic” component which offers its internal concepts at its API. This way we end up with basically the exact opposite of a re-usable component.Why do we end up with the opposite of a re-usable component? There are at least two reasons for that: First, as we do not have the knowledge which variability points the component needs to offer in order to satisfy the actual needs of its clients, we usually implement way too many variability points and thus increase the accidental complexity of the component and its interface protocol a lot. In other words: The component becomes harder to use than required, it will be harder to understand and the overall system complexity will be higher than needed.Secondly, “generic”, provider-driven APIs tend to create tight couplings between the provider and its clients because – as you do not have any experience about usage patterns and client needs at design time – you just externalize everything that your component offers via the API. This way, the API is implementation-driven and not client-driven which adds two bad effects:First, the clients are tightly coupled to the implementation of the component (which is externalized via the API due to missing alternatives at design time), usually requiring a much more fine-grained protocol for component access than the client would have needed. Secondly, it becomes very hard to change the implementation of the component after a client started to use it because the implementation was externalized via the API.This, way we end up with a overly complex, tightly coupled, brittle and hard to change system landscape – the opposite of what we wanted to achieve. Even if we would eventually figure out better responsibility encapsulations and access protocols based on actual client needs, we would have a hard time to change the overly complex and highly dependent system we created in the first place. And all this just because we started with a re-use based business case to get a hand on the new shiny paradigm.This is not just theory. Basically, every single system I have seen over the years that was built with re-use in mind exactly looked the way I just described. Sometimes (especially in SOA initiatives), it was even worse because the designers went for a “layered architecture”.The layered architecture pattern is broken often enough within a component, but across components, which are meant to be loosely coupled by definition (and thus btw. need to be as self-dependent as possible), it is quite close to the worst design imaginable: extremely tight coupled components, overly long call-chains (often across process boundaries), very high structural complexity, fragile at runtime due to many components involved for every single request, extremely hard to change – in short words: From an architectural perspective and the goals we wanted to achieve close to a nightmare.After all this: What can we learn from this?<ul><li>First of all: Never base an architectural decision on re-use. It will never work and you usually end up at quite the opposite place of where you wanted to go.</li><li>You don’t need any special architectural paradigm for re-use. Everything that is needed for re-use is already in place – batteries included.</li><li>Re-use emerges. Don’t plan for it. It takes a lot of work, trial and error and actual experience with real clients to design a good re-usable component which encapsulates the right responsibility and provides it via a good client-driven and easy-to-understand API.</li><li>Re-use is expensive. It takes a lot of effort to make a component re-usable. As a rule of thumb, it costs about 5 times as much as it costs to make a component usable. Thus, make sure, it is worth the effort, i.e., the component is used often enough before you make it re-usable.</li><li>And last of all: Don’t go for cheap re-use by building trivial components or layered components. You will end up in a hell where you never, ever wanted to be.</li></ul>How can we make it better?As so often, I do not have a perfect plan to offer (and probably there is no perfect plan at all). My recommendation is to go for replaceability instead of re-use. Replaceability leads in the right direction: you think about how to separate responsibilities in order to make them replaceable, which gives you loose coupling. You think about separating clients from the implementation in order to keep it replaceable, which gives you client-driven APIs.And, if you might realize after a while, that a component tends to be used several times, you go the extra mile to make it really re-usable in terms of additional testing, documentation and hardening. Therefore I would like to add one more line to the learnings:<ul><li>Strive for replaceability, not re-use. It will lead you the right way.</li></ul>Any final words? Um, yes: do not get me wrong. Re-use is not bad per se. Re-use can be extremely useful. For example, I am absolutely grateful that I do not have to build my own String libraries from scratch in every new project as I had to do in the early 90ies with C and C++. It is also great that today it is virtually a no-brainer in most programming languages to create a HTTP client or server. This are just two of probably a million examples where re-use does a great job.Just do not justify your new architectural toy with re-use. It will not work. Never. Why? Re-use this post to figure out … 😉

The broken promise of re-use

If we look for a definition of a term or for an explanation of a special topic, where do we look first? Right, in <a href="http://en.wikipedia.org/wiki/Main_Page" target="_blank">Wikipedia</a> ! We know that the information in Wikipedia are collected by an open community that consists of thousands of experts all around the world, all of them publishing their knowledge so that the rest of the world can get a bit more clever with each click.Meanwhile, in many cases we count on the reliability of Wikipedia so much that we don’t bother looking up alternative sources. Also it is quite normal to believe someones thesis if it is backed by a Wikipedia excerpt.In this context I had a nice experience on the <a href="http://www.irmuk.co.uk/eac2008/" target="_blank">Enterprise Architecture Conference</a> in London this year:In a keynote John Zachman presented the new version of his framework. Therfore every attendee got a piece of paper that contained a nicely formatted presentation of the framework. Before he started to explain the new features of the framework though, he advised us of of two short articles on the back of the paper.Basically, what he stated was: “The two articles describe the framework in a very short manner and the reason for printing them on the back of the paper is Wikipedia. Out of curiousity I read the description of my framework in Wikipedia a while ago and found out that some of the statements were wrong. So, I corrected the wrong statements in the Wikipedia article. Due to the open concept of Wikipedia that works straightforward. After a while I got feedback by Wikipedia that the changes had been deleted because they were not correct. So, I wrote back something like ‘Hi, I am John Zachman, the inventor of the framework and if I don’t know the correct description of the framework, who on earth does?’ It didn’t help. Wikipedia insisted that my statements about my framework were wrong. Thus I had to write the two articles to describe my framework as I intended it to be – as in wikipedia I wasn’t able to do it.”Of cause John scored by making everybody laugh telling us this nice anecdote. Since he kept up the good atmosphere throughout his keynote, it was a great keynote for all attendees and we also learned a lot about the new version of his framework and the ideas and concepts behind it.But what does this story tell us about Wikipedia? I don’t know what happened in detail, who exactly removed the changes that John made in Wikipedia and I didn’t ask for more details. However, this anecdote shows quite plainly that Wikipedia is not infallible. Wikipedia is built and maintained by humans and humans are making mistakes – mistakes that eventually can be found in any of the entries in Wikipedia.This was quite helpful for me to be reminded by the story that I cannot take wikipedia by their words in any case. Of course we certainly use to know that but sometimes we also tend to forget about it.Wikipedia is a very powerful information source and for me it is still very impressing, how this immense amount high-quality knowledge was brought together in such a short peroid of time due to the open concept of Wikipedia. Yet we shouldn’t consider Wikikpedia to be “the truth in itself” but rather we should handle it like any other good source of information: We can use Wikipedia as our first research source, but then – as with any good research – we should try to find other resources for crosschecking the information, in so doing minimizing the risk of errors and making sure to get proven and sustainable information.Remember: Wikipedia is just almost always right.

Wikipedia is always right

This is a small post to inform you about some new slide decks that you can view online or download if you like.I’ve been presenting at some conferences in the last months. First I talked about the developer challenges if you leave the strict consistency model of ACID transactions at <a href="http://www.oop-konferenz.de/" target="_blank">OOP</a> . The <a href="http://de.slideshare.net/ufried/how-to-survive-in-a-base-world" target="_blank">slide deck</a>  first compares ACID and BASE transactions for a second. Then a simple example using ACID transactions is presented (Java/JPA/RDBMS). Afterwards this example is ported to the NoSQL world in a naive way (seen quite often in real-life projects). The reminder of the deck then shows the challenges that arise from this naive port one by one and ways to deal with them. As with every slide deck a lot of the information is on the voice track but I think the slides on their own already offer some helpful pointers. (This last sentence is also true for the slide decks I’m going to write about in the remainder of this post. Thus, I won’t repeat it for the other slide decks.)<div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div>This first presentation is complemented by the presentation I gave at <a href="http://www.javaland.eu/" target="_blank">JavaLand</a> . There I talked about the different consistency models in more detail and presented two approaches in depth that I only mentioned shortly in the first presentation: quorum based read & writes which can give you strong client-side consistency and CRDTs (Conflict-free Replicated Data Types) which help to keep your data eventually consistent even under extreme availability requirements. The <a href="http://de.slideshare.net/ufried/self-healing-data" target="_blank">slide deck</a>  is exactly organized the way I just described it before, so no need to write anything more about it.<div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div>There is another pair of correlated presentations I’d like to offer. Those presentations are located in the resilience area. The first of the two presentations I gave at <a href="http://qconlondon.com/" target="_blank">QCon London.</a>  The <a href="http://de.slideshare.net/ufried/implementing-fault-tolerance" target="_blank">slide deck</a>  first gives a quick motivation why resilience and fault-tolerant software design is an important topic for developers today. The reminder of the deck is organized the following way: First a case study is shown that explains the consequences of non-resilient applications. Then some patterns are shown that help to mitigate the problems shown in the case study – including code examples that show how to implement those patterns. The idea of this talk was not to give an introduction or overview to resilient software design, but to demonstrate that at least for some resilience patterns it is surprisingly easy to get them implemented in your application – which is a lot better than not having any of them in place.<div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div>The complementing presentation is the one I gave at the <a href="http://bed-con.org/2014/home" target="_blank">Berlin Expert Days</a> . There I gave an introduction to Hystrix, a resilience library developed by Netflix. Hystrix implements downstream isolation utilizing timeouts, circuit breakers and load shedder which are some of the patterns I presented in the other talk. The <a href="http://de.slideshare.net/ufried/resilience-with-hystrix" target="_blank">slide deck</a>  again starts with a quick motivation why resilience is important. Then Hystrix is introduced – first a quick overview, then some basics features. Afterwards some principles of Hystrix are explained in more detail, followed by some resilience patterns that can be implemented using Hystrix – including lots of code examples. A short glance at some advanced Hystrix features and extensions that were not mentioned before close the presentation.<div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div>Those were the slide decks related to distributed and scalable systems which is one of my current focus areas. My second focus area I usually describe with “IT organizations in a post-agile world”. If you want to know a bit more in detail what I mean with that flamboyant phrase you might want to have a quick look at my <a href="http://de.slideshare.net/ufried/dr-hectic-and-mr-hype-surviving-the-economic-darwinism" target="_blank">slide deck</a> about surviving the economic darwinism which explains the core ideas. Within the scope of this focus area I am going to talk about “DevOps for Developers” at <a href="http://rome2016.codemotionworld.com" target="_blank">Codemotion</a> . The core idea of this <a href="http://de.slideshare.net/ufried/devops-for-developers-28043923" target="_blank">slide deck</a> is that many developers are taken in by the false assumption that DevOps is a cool idea but does not affect them in their daily development work. Therefore, first the false assumptions is presented in the slide deck. Then the needs of an operations administrator are described as they nicely describe what properties are crucial for an application in production. Those needs are then taken and the challenges for a developer are derived from them. Afterwards for each of the challenges several principles are presented that explain what a developer needs to take care of in his daily development work in order to deliver software that is really production-ready.<div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div><div><div><div>Click on the button to load the content from www.slideshare.net.<a href="#">Load content</a> </div></div><div></div></div>Those were the slide decks I wanted to present in this post. Feel free to view them online or download them. I would be glad if they give you some helpful ideas. And feel free to contact me via Twitter, Email or some other channel if you have any questions or remarks about the slides.

New slide decks available: Resilience patterns, Hystrix, beyond ACID transactions, CRDTs and DevOps for developers

Last week I attended the SET 2009 in Zurich. The conference – organized by <a href="http://www.sigs-datacom.de/">SIGS DATACOM</a> – is not as big as their flagship conference OOP. About 160 people visited the conference, it took two days and had a nice programme organised in three parallel tracks.I was there because I gave a talk on the problems of reuse and the potentials of design for maintenance but that’s not what I want to talk about here.In the other time I took the opportunity to attend a view other sessions and talk to other people and I’d like to talk about two interesting ideas I picked up there. First I attended a talk about the experiences with a virtual development team given by Stephan Wald. At some point in his talk he claimed that development in virtual teams only works with a certain type of developer. He said that this way of working together requires developers that are willing to collaborate a lot, share their results, document what they have done, and so on. Or to say it the other way around: Those “IT superheroes” or “lonesome cowboys” (in their self-perception) who are doing everything on their own, not sharing anything and especially not their code, do not fit in those projects even if they produce results extremely fast. The virtual approach just does not work with this kind of developers.I found this observation very interesting because I always felt somehow ambivalent about this type of “shared nothing” people. On the one hand those guys often were excellent developers that were able to save a project that fell behind schedule within a weekend (which often made them kind of manager’s darling). On the other hand they always created sort of a black hole in their perimeter making themselves irreplaceable – also within a weekend.When I talked about this at lunch with some other people another speaker just stated that he thinks those “IT superheroes” are always a problem in any kind of project. The virtual, distributed team just makes it obvious very quickly. The other people on the table agreed and I also think this guy is right. So, for me I think with virtual, distributed teams the era of “IT superheroes”, those “lonesome cowboys” should come to an end or otherwise the projects they are involved with will come to an end – much earlier than expected.The second very interesting idea I’d like to share is the talk that Peter Sommerlad, one of the authors of the <a href="http://www.amazon.de/System-Patterns-Pattern-Oriented-Software-Architecture/dp/0471958697/">first POSA book</a> and meanwhile professor at the <a href="http://ifs.hsr.ch/">Institute for Software</a> in Rapperswil. Peter gave a very interesting talk about “Decremental Development”. The idea is to get rid of all unnecessary complexity in the code and to shrink it down to a fraction of its original size this way making it easier to understand and to maintain.I found this talk very interesting because it also stressed the importance of maintainable software, no matter if it is on the architecture level that I talked about in my presentation or on the design and code level that Peter talked about. For my part I think at least at the conferences people start to realise that design and code for maintenance is the real issue that needs to be addressed badly to keep the TCO (Total Cost of Ownership) of software in balance.It is not about always picking the cheapest implementation to create a nice punctual business case neglecting the follow-up costs caused by the cheapest solution. Instead it is about optimising the total costs of an application regarding the whole lifecycle of the application – and maintenance is the by far biggest part of an IT applications lifecycle.I think when people start to become aware about this at those conferences it might still take a while until it becomes common understanding but it is definitely a step in the right direction.Those were the two ideas I wanted to share. One last tip: If you should ever go to the SET use <a href="http://www.zvv.ch/zvv/en/home.html">public transport</a> . If you are – as I am – used to the common delays of the Deutsche Bahn it is simply great using public transport that is so punctual and reliable that use can set your clock to its schedule. Hence, use public transport, relax and enjoy it … 😉

Impressions from the SET 2009 in Zurich

Enterprise Architecture Management (EAM) is an important issue for most enterprises, not only the big ones. But its implementation still bears a lot of risks and the results are often way beyond the initial expectations.Dr. Ingo Schrewe from <a href="http://www.incowia.com/">incowia GmbH</a> and I wrote an article how agility can help to reduce risk and optimise the results when implementing an EAM. The article was published within the scope of an EAM online special by SIGS-DATACOM and can be downloaded here: http://www.sigs.de/publications/os/2010/EAM/friedrichsen_schrewe_OS_EAM_10.pdf (available in german language only)Ingo Schrewe and I plan to continue this article by writing some more articles that provide practical guidelines, hints and examples how to establish an agile EAM … whenever we will find the time to write those articles … 😉

Agility and EAM

All right, now I’m trying to write the probably shortest post ever published in the codecentric blog … 😉So, what’s it about?I just wanted to point out for those who do not know yet that <a href="http://www.bredemeyer.com/">Dana Bredemeyer</a> will conduct his well-known Software Architecture Workshop at codecentric from Sep-13-2010 to Sep-16-2010. Dana haven’t had an open enrollment for this workshop in Germany for almost 10 years and from all I’ve heard about it this will be a great course. So, if you are interested in that workshop and do not want to travel to the United States for that you might want to take a look at <a href="https://www.codecentric.de/wissen/schulungen/">http://www.meettheexperts.de/software-architecture</a> .Also, I wanted to mention our “Meet the Experts” on Sep-17-2010. “New challenges in architecture today” will be the topic. Five well-known speakers, including Dana Bredemeyer, Dr. Gernot Starke and Prof. Dr. Heinz Züllighoven will share their ideas in insights with you. And, as always there will be a lot of time for discussions, networking, open space for your questions, great catering, and so on. So, if that sounds interesting for you, just have a look at http://www.meettheexperts.de/meettheexperts-architektur.Okay, that’s all I wanted to talk about. I think those sessions will be great stuff, I will be there for sure. And if you will be there too, I’ll be glad to meet you … and if not, maybe we’ll meet some other time …

Software Architecture Workshop with Dana Bredemeyer and Meet the Experts

Meanwhile I know <a href="http://www.opengroup.org/togaf/" target="_blank">TOGAF</a> for several years but I never found the opportunity to use it in its whole breadth in a customer project. For any actual project situation TOGAF with all its phases and result artifacts always seemed to be just too much to use it straightforward. I always was sort of afraid to frighten off my customers if I would talk about more than a dozen phases and sub phases and lots of result artifacts to be produced. So I usually tended to use a more “lightweight” architecture lifecycle framework consisting of only a few phases and artifacts that fitted the requirements of my customers pretty well.Then a few weeks ago I had the opportunity to attend the Open Group Conference in Munich, one of the largest gatherings of TOGAF experts worldwide. So I was very curious to talk to these experts, what their experiences were. Did I just have the wrong projects for TOGAF in the past? Did I miss an important point? Or would they share the same experiences I had?So, when attending the case studies and talking to other people at the conference I always got the same answer: No one of them used TOGAF “pure”. All of them tailored TOGAF according to their specific customer requirements which usually meant simplification: Phases were pooled together, dropped or renamed. The result artifacts were also simplified, dropped or renamed. In one case they compressed the framework down to four phases and did not mention the term “TOGAF” at all, just to avoid discussions about the architectural framework complexity with the customer.On the other hand everybody agreed that TOGAF is a really good framework which is very well suited to get a grasp of what is important to architecture lifecycle management and to start any non-trivial architectural effort. In the context of an actual project though, the framework usually has to be customized or simplified to suit the projects constraints – even radically if required.This feedback was very interesting for me since it somehow confirmed my former approach: Do not customize the customer to suit the needs of the framework but select and customize the framework to suit the needs of the customer. And a framework of the size of TOGAF is usually just about a magnitude too large for most customers and projects. Hence most of the time you have to simplify the framework to suit the needs of the customer. Of course there are also projects that require the complete TOGAF in its whole and unlimited beauty. But due to the size of these projects they are quite rare.By the way this is an experience I had for most non-trivial methods and frameworks – also in different areas: Most of them give you a good idea of what areas you should look at when dealing with the topic they cover but you use them quite rarely in their pure form. Most of the time you have to customize, i.e. simplify and modify them to work with your specific customer and project.Remember: The goal is to create business value, not establishing methods and frameworks – those are just a means to an end.

TOGAF applied

Michael Nygard is a well-known software engineer and architect. He designed and delivered some large-scale systems in his career and distilled some of his insights in his book Release It! [1]. He is also a renowned expert in the area of microservices. This month, he is visiting Germany to give his workshop “Monolith to Microservices” in Solingen and Munich. We had the opportunity to interview him.Uwe Friedrichsen: Microservices are no longer a hype. They have become reality in many companies. Even more companies have just started picking them up. And some companies with special requirements like Segment already <a href="https://segment.com/blog/goodbye-microservices/" target="_blank">stopped using them</a> [2]. What is your opinion regarding microservices? Are they the long-searched-for panacea as some say? Or are they Pandora’s Box as others say? How do you experience microservices?Michael Nygard: As the saying goes, there’s no silver bullet. Microservices are a technological solution to an organizational problem. That problem is, “How do I scale my development team without paralyzing development flow?”I also think microservices are the result of failures in our operating systems, languages, and frameworks. Basically, the goal is fault isolation and independent deployment. We want each team to deploy on their own schedule without causing downtime to other teams. We also want to prevent bad code in one service from harming others. This is only partly achieved with microservices today. Third, we want to isolate the OS level namespaces—IP addresses, TCP ports, file names, directory contents, etc.—from each other. Finally, we want to enforce architectural boundaries between the services. Do these really require us to run thousands of containers, each with their own operating system image?Uwe: You already touched upon it in your previous answer, but just to get to the heart of it: when do you think, using microservices is a good idea?Michael: They’re a good idea when you need independent deployment across multiple teams.<blockquote>The reality is that adopting this architectural style means constant redesign and evolution.</blockquote>Uwe: While I feel I already know your answer, let me ask you nonetheless: when should you better refrain from using microservices?Michael: If you are a small team working cohesively, like in a single room, then you are better off avoiding the operational complexity of microservices.Uwe: If you look at your customers, what are – based on your experience – their biggest challenges when picking up microservices? What do they really struggle with?Michael: There are two big hurdles. First, many people pick up microservices but don’t do enough design of the APIs between the services. As a result, they build a distributed ball of mud, where every service can call every other service. That results in rigidity at a higher level, since nobody is free to change their APIs.Second, a lot of groups that pick up microservices think they’re just going to design things once, build a set of microservices, and then be done with it. The reality is that adopting this architectural style means constant redesign and evolution. You may delete a service that you just created last month, and you have to be willing to accept that. It can be uncomfortable, because we’re used to thinking of code as a long-lived asset.Uwe: Facing those challenges: what are your recommendations? What are the most important topics people and companies should be aware of if they decide to adopt microservices?Michael: First, they need to be aware of the nature of distributed systems development. Developers should be comfortable drawing Lamport diagrams and talking about idempotent messages versus “exactly once” delivery infrastructure. That’s already a prominent part of system design and it will only become more important. I extend this all the way to the front-end as well, by the way. Modern front-ends are applications in a distributed system with all the uncertainty and asynchrony that implies.Second, I think developers have gotten plenty of discussion about the virtues and perils of microservices, but most have little experience designing the services and evolving their APIs. What I mean by that is, you can find hundreds of tutorials about setting up Kubernetes or how to use Docker to deliver your code to production. But there isn’t as much about how to design a good service, let alone how to build a whole system out of such services. Developers must avoid falling into the trap of making their microservices act like distributed objects or entity services. That was a big part of the motivation behind my “Monolith to Microservices” workshop. In that class, developers build real services and we talk extensively about making usable, evolvable APIs.<blockquote>You can find hundreds of tutorials about setting up Kubernetes or how to use Docker to deliver your code to production. But there isn’t as much about how to design a good service.</blockquote>Uwe: Okay, that is quite a bit to ponder regarding the adoption of microservices. Let us finish with a look into the crystal ball: Do you think microservices will still be relevant in five years? Or will they be replaced by a new paradigm? Or will we be so absorbed with totally different challenges that we simply won’t care?Michael: I’m going to predict what I think should happen, in the hopes that I can simply wish it into being true. Our languages and platforms today don’t help developers express the design of a distributed system. We’ve got languages for writing code that runs inside a process on one machine. Then we try to assemble that code together with functions-as-a-service, a pile of infrastructure-as-a-service using some other languages and tools. Then we somehow expect that the assembly respects the wire protocols, preconditions, and invariants that we planned for our system. Yet there’s no way to assist the humans in making the whole assembly correct.By that I mean that we have things like unit tests, type checkers, linters, and so on that help us get the code right that runs inside a single process. But when it comes to coordinating processes across a network, we don’t have tools to assist the developer or designer. So what I’d like to see in five years is something like this: We have a true distributed operating system, in the same sense as a server operating system. It provides an abstraction over hardware, resource management, an API, visibility, operational tools, etc. We have a language that lets us describe the connections between processes in terms of their data formats and invariants, and we use the same language—or something very similar—to describe the code inside the processes. When we hand a system written in that way to the operating system, it will be the job of the OS to make everything run with the right network rules, security protections, isolation, and so on.I think we can see the beginnings of such a world right now. But each installation is a unique combination of off-the-shelf parts. So you might have Kubernetes, Helm, and Istio, running on AWS with Lambda, etc. I might be using Terraform, Consul, Vault, with applications in Clojure with Clojure.spec. It would be like if every server ran its own hand-crafted version of Unix.Uwe: Thanks a lot for the interview, Michael!A German translation of the interview was previously published on <a href="https://www.heise.de/developer/artikel/Microservices-sind-keine-Patentloesung-Ein-Interview-mit-Michael-Nygard-4142196.html" target="_blank">heise Developer</a> .<img width="250" height="347" src="https://media.graphassets.com/8y2WjDb1R6isdX3p02qF" alt="Michael Nygard on Microservices" />Michael Nygard has been a professional programmer and architect for more than 15 years. He has delivered running systems to the U.S. government and to the banking, finance, agriculture, and retail industries. Michael is a popular speaker at technical conferences, and has written and co-authored several books, including Release It! [1] and 97 Things Every Software Architect Should Know [3].<h2>References</h2>[1] Michael Nygard, Release It!, 2nd edition, Pragmatic Programmers, 2018[2] Segment Blog, Alexandra Noonan, Goodbye Microservices: From 100s of problem children to 1 superstar, see <a href="https://segment.com/blog/goodbye-microservices/" target="_blank">https://segment.com/blog/goodbye-microservices/</a> [3] Richard Monson-Haefel (Ed.), 97 Things Every Software Architect Should Know, O’Reilly, 2009

Microservices all the way down – An interview with Michael Nygard

Talk "From Here to Resilience – a Travel Guide"

Workshop "Domain Driven API Design"

Weitere Infos

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

Produktentwicklung

IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Software Architecture Alliance 2024

Weitere Infos

Talk "Datenarchitektur in der Realität"

Talk "From Here to Resilience – a Travel Guide"

Workshop "Domain Driven API Design"

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten