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

IT-Security

Produktentwicklung

Weitere Leistungen...

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

Alle Standorte

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?  

STANDORT-TEAM

codecentric Hamburg 

Unser codecentric Team am Standort Hamburg stellt sich vor.

codecentric Team Hamburg

Willkommen im Team Hamburg

Senior IT-Consultant

<h2>Code-Beispiele mit Testinfra: So testen Sie Docker-Images und vermeiden böse Überraschungen in Containern.</h2><p>Bei Anwendungen, die in Docker-Containern laufen, verlagert sich ein guter Teil des Infrastruktur- und auch des Applikationssetups in die Container. Dieser Part wird oft weder durch Infrastrukturtests noch durch die fachlichen Tests der Anwendung abgedeckt. Dies kann zu bösen Überraschungen führen, wenn ein Fehler im Docker-Image selbst begründet liegt. Die Fehlersuche gestaltet sich oft langwierig und schwierig.</p><p>Es ist jedoch durchaus möglich zu testen, ob Images und die aus ihnen erzeugten Container korrekt aufgebaut sind. Im Gegensatz zu Infrastrukturtests, welche den tatsächlichen Status laufender Infrastruktur testen, kann ein Entwickler auf diese Weise Tests bereits zur Entwicklungszeit ausführen. Ebenso können die Tests in den Build-Prozess eines Images integriert werden, und so Regressionen vermeiden.</p><p>Damit schließt sich die Lücke zwischen den fachlichen Tests einer containerisierten Anwendung und der Infrastruktur, auf der diese Anwendung läuft.</p><p>In diesem Artikel zeige ich anhand von konkreten Code-Beispielen, wie Sie solche Tests mit Hilfe von <a href="https://testinfra.readthedocs.io/en/latest/" target="_blank">Testinfra</a>  schreiben können. Sie werden lernen, wie Sie</p><ul><li>Tests gegen einen laufenden Container ausführen,</li><li>Images zur Test-Zeit bauen und Container programmatisch starten</li><li>sowie Images testgetrieben entwickeln.</li></ul><p>Als Beispiel dient ein Team aus Entwicklerinnen und Entwicklern, welches das <a href="https://hub.docker.com/_/jenkins/" target="_blank">offizielle Jenkins-Image</a>  testen und an eigene Bedürfnisse anpassen möchte.</p><h3>Einen laufenden Container testen</h3><p>Im offiziellen Jenkins-Container startet ein Java-Prozess unter dem Benutzer <code>jenkins</code>. Unser Beispiel-Team möchte sicherstellen, dass es dieses grundlegende Setup nicht durch eigene Anpassungen gefährdet. Das Team nutzt dazu <a href="https://testinfra.readthedocs.io/en/latest/" target="_blank">Testinfra</a> , ein Tool zum Testen von Infrastruktur. Es basiert auf der Programmiersprache Python und dem Test-Framework <a href="https://docs.pytest.org/en/latest/" target="_blank">pytest</a> .</p><p>Eine Entwicklerin des Teams schreibt die folgenden beiden Testinfra-Tests:</p><div>

```python
# ./tests/image_test.py
import pytest
 
def test_current_user_is_jenkins(host):
    assert host.user().name == "jenkins"
    assert host.user().group == "jenkins"
 
def test_jenkins_is_running(host):
    jenkins = host.process.get(comm="java")
    assert jenkins.args == "java -jar /usr/share/jenkins/jenkins.war"
    assert jenkins.user == "jenkins"
```

</div><p>Der erste Test stellt sicher, dass der Benutzer <code>jenkins</code> existiert und dass er als aktueller Benutzer gesetzt ist.<br /> Der zweite Test gewährleistet, dass der Jenkins-Prozess läuft und die korrekte Benutzerkennung hat. Die Tests stellen also sicher, dass das Jenkins-Image sich wie erwartet verhält, und dieses Verhalten durch spätere Anpassungen nicht beeinträchtigt wird.</p><p>Die Tests setzen voraus, dass ein Jenkins-Container läuft. Der folgende Befehl startet diesen:</p><div>

```bash
docker run --rm --name=jenkins_test_container jenkins
```

</div><p>Anschließend startet <code>testinfra</code> mit dem Connection-Backend <code>docker</code> die Tests. Mit dem <code>--hosts</code> Parameter kann dabei definiert werden, gegen welchen Container die Tests ausgeführt werden:</p><div>

```bash
testinfra --connection docker --hosts=jenkins_test_container
```

</div><p>Alternativ kann der zu testende Container über die Variable <code>testinfra_hosts</code> im Test-Modul angegeben werden:</p><div>

```python
import pytest
 
testinfra_hosts = ["docker://jenkins_test_container"]
```

</div><p>Dadurch ist es möglich, verschiedene Container in unterschiedlichen Modulen zu testen. Die Tests können dann einfach mit dem Kommando <code>testinfra</code> oder <code>pytest</code> gestartet werden.</p><h3>Container bauen und testen</h3><p>Praktischer ist es, wenn das Test-Modul den Container programmatisch startet. Dies geht mit Hilfe der Bibliothek <a href="https://docker-py.readthedocs.io/en/stable/" target="_blank">docker-py</a>  problemlos:</p><div>

```python
#./tests/image_test.py
import pytest
import docker
 
testinfra_hosts = ["docker://jenkins_test_container"]
 
@pytest.fixture(scope="module", autouse=True)
def container():
    client = docker.from_env()
    container = client.containers.run('jenkins', name="jenkins_test_container", detach=True)
    yield container
    container.remove(force=True)
```

</div><p>Diese Codezeilen definieren ein <a href="https://docs.pytest.org/en/latest/fixture.html" target="_blank">Test-Fixture</a> , das vor den Tests einen Container startet und diesen im Nachgang wieder entfernt. Der Parameter <code>scope="module"</code> sorgt dafür, dass nur ein Container für das gesamte Modul gestartet wird. Andernfalls würde jeder einzelne Test einen Container erzeugen und wieder entfernen. <code>autouse=True</code> bewirkt, dass das Fixture erzeugt wird, obwohl die Tests es nicht explizit referenzieren.</p><p>Das Team hat mit dieser Test-Suite nun ein gutes Fundament, um ein angepasstes Jenkins-Image zu testen. Einer der Entwickler scheibt folgendes Dockerfile, um ein neues Image auf Basis von <code>jenkins</code> zu definieren:</p><div>

```dockerfile
# ./src/Dockerfile
FROM jenkins
MAINTAINER John Doe <john.doe@example.com>
```

</div><p>Das Beispiel nimmt noch keine Anpassungen vor. Im ersten Schritt sollen die bestehenden Tests gegen dieses neue Image laufen. Die Bibliothek docker-py kann das Image zur Laufzeit der Tests bauen. Ein Session-scope Fixture in der Datei <code>conftest.py</code> baut das Image einmalig – vor allen Tests des Projekts:</p><div>

```python
#./tests/conftest.py
import docker
import pytest
 
@pytest.fixture(scope="session")
def client():
    return docker.from_env()
 
@pytest.fixture(scope="session")
def image(client):
    return client.images.build(path='./src')
```

</div><p>Das erste Fixture erzeugt zunächst einen Docker-Client, der im zweiten Fixture das Image baut. Die <code>build</code>-Funktion greift dazu auf das Dockerfile im <code>src</code>-Ordner zu.</p><p>Das <code>container</code>-Fixture aus dem Test-Modul muss nun natürlich das frisch gebaute Image verwenden:</p><div>

```python
# ./tests/image_test.py
@pytest.fixture(scope="module", autouse=True)
def container(client, image):
    container = client.containers.run(image.id, name="jenkins_test_container", detach=True)
    yield container
    container.remove(force=True)
```

</div><p>Die beiden Fixtures aus <code>conftest.py</code> werden per Namenskonvention in das <code>container</code>-Fixture hinein gereicht. Der Docker-Client startet dort nun einen Container auf Grundlage des zuvor gebauten Images.</p><h3>Testgetriebene Container-Entwicklung</h3><p>Die Entwicklerin beginnt nun damit, die Funktionen des Jenkins-Image zu erweitern.<br /> Ganz im Sinne testgetriebener Entwicklung, kann sie die Anforderungen in Form eines Tests abbilden:</p><div>

```python
# ./tests/image_test.py
def test_maven_is_installed(host):
    assert host.package("maven").is_installed
```

</div><p>Da das Team Maven-Projekte bauen möchte, muss Maven installiert sein. Der Test prüft mittels <code>host.package</code>, ob das <code>maven</code> Paket installiert ist. Intern wird dazu die Paketverwaltung des Images verwendet. In diesem Beipiel ist es dpkg. Weil das Jenkins-Image die Anforderung noch nicht erfüllt, schlagen die Tests fehl. Testinfra gibt die Fehlermeldung aus, die im Container aufgetreten ist:</p>

```sh language-sh
Failed: Unexpected exit code 1 for CommandResult(command="dpkg-query -f '${Status}' -W maven", exit_status=1, stdout=None, stderr='dpkg-query: no packages found matching maven\n')

```

<p>Um dies zu korrigieren, wechselt das Dockerfile per <code>USER</code>-Instruktion zum <code>root</code> Benutzer und installiert anschließend <code>maven</code>:</p><div>

```dockerfile
# ./src/Dockerfile
USER root
RUN apt update && apt install -y maven
```

</div><p>Der neue Test wird jetzt grün, jedoch schlagen die anderen beiden Tests fehl. Das Sicherheitsnetz hat funktioniert und warnt davor, dass nun der Benutzer <code>root</code> Jenkins ausführt!</p><div>

```bash
  def test_jenkins_is_running(host):
        jenkins = host.process.get(comm="java")
        assert jenkins.args == "java -jar /usr/share/jenkins/jenkins.war"
>       assert jenkins.user == "jenkins"
E       assert 'root' == 'jenkins'
E         - root
E         + jenkins
```

</div><p>Eine weitere <code>USER</code>-Instruktion nach der Installation korrigiert diesen Fauxpas:</p><div>

```dockerfile
# ./src/Dockerfile
USER root
RUN apt update && apt install -y maven
USER jenkins
```

</div><p>Nun laufen alle Tests erfolgreich durch!</p><div>

```bash
tests/image_test.py::test_current_user_is_jenkins[docker://jenkins_test_container] PASSED
tests/image_test.py::test_jenkins_is_running[docker://jenkins_test_container] PASSED
tests/image_test.py::test_maven_is_installed[docker://jenkins_test_container] PASSED
 
================================== 3 passed in 3.31 seconds ==================================
```

</div><h3>Ausblick</h3><p>Mit den gezeigten Beispielen hat das Team ein gutes Basis-Setup und kann nach Bedarf weitere Tests schreiben und das Image an die Anforderungen anpassen. Testinfra ist ein geeignetes Werkzeug, um die Änderungen mit Tests abuzusichern.</p><p>Es ist auch möglich eine Reihe von Container-Konfigurationen zu testen, indem verschiedene Test-Module unterschiedliche Container-Fixtures nutzen. Dazu kann docker-py zum Beispiel unterschiedliche Umgebungsvariablen setzen, welche den Aufbau des Containers beeinflussen.<br /> Dabei sollten Test-Autoren jedoch berherzigen, das Verhalten des Dockerfiles und nicht das der containerisierten Anwendung zu testen.</p><p>Auch komplexe Setups mit untereinander verlinkten Containern sind denkbar. Zum Beispiel könnte docker-py Mock-Container starten, um den zu testenden Container in eine kontrollierte Umgebung zu isolieren.</p><h3>Fazit</h3><p>Mit <a href="https://testinfra.readthedocs.io/en/latest/" target="_blank">Testinfra</a>  können Teams nicht nur Infrastruktur testen. Auch für Docker-Images ist es ein geeignetes Werkzeug. Tests können mit <a href="https://docker-py.readthedocs.io/en/stable/" target="_blank">docker-py</a>  Images zur Laufzeit bauen und Container starten. Testinfra bietet eine Reihe von Modulen, die den Aufbau dieser Container überprüfen können. Darüber hinaus stehen Entwicklerinnen und Entwicklern alle Möglichkeiten von <a href="https://docs.pytest.org/en/latest/" target="_blank">pytest</a>  offen.</p><p>Die Beispiele aus diesem Artikel sind auf <a href="https://github.com/angelo-v/testinfra-docker-example" target="_blank">Github</a>  verfügbar.</p><blockquote><p><strong>Exkurs: Testinfra im Container ausführen</strong><br /> Wenn man ohnehin mit Docker arbeitet liegt es nahe, die Tests ebenfalls im Container auszuführen. Das Image [<code>aveltens/docker-testinfra</code>] enthält alle dazu nötigen Abhängigkeiten. Der Source-Code des Projekts und der Docker-Socket des Hostsystems müssen lediglich über ein Volume in den Container einghängt werden:</p><div>

```bash
docker run --rm -t \
  -v $(pwd):/project \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  aveltens/docker-testinfra
```

</div></blockquote>

Hilfe, mein Container zickt!

<p>In den letzten beiden Artikeln habe ich gezeigt, wie Frontend und Backend von Webanwendungen mithilfe von JSON-LD entkoppelt werden können. Dank JSON-LD sind weder die genauen JSON-Bezeichner noch spezifische "API-Endpunkte" im Backend relevant. Bei JSON-LD kommt es nicht mehr auf die konkrete Struktur und Syntax der Daten an, sondern auf die diesen inhärente Semantik. Dies liegt daran, dass JSON-LD eben kein spezifisches Datenformat ist, sondern lediglich eine JSON-Serialisierung von <a href="https://www.w3.org/DesignIssues/LinkedData.html" target="_blank">Linked Data</a> . Um die Vorteile von JSON-LD zu verstehen, ist ein Blick auf die Eigenschaften von Linked Data hilfreich.</p><h2>Bisherige Artikel</h2><ol><li><a href="/wissens-hub/blog/datenaustausch-mit-json-ld">Schmerzloser Datenaustausch: Mit JSON-LD Backend und Frontend entkoppeln</a> </li><li><a href="/wissens-hub/blog/json-ld-verlinkte-daten-statt-hart-kodierter-endpunkte">Verlinkte Daten statt hart-kodierter Endpunkte</a> </li><li>Semantische Fakten statt fester Baumstruktur</li></ol><h2>Linked Data</h2><p>Nehmen wir den Datensatz aus dem <a href="/wissens-hub/blog/json-ld-verlinkte-daten-statt-hart-kodierter-endpunkte">letzten Artikel</a>  als Beispiel:</p><div>

```javascript
{
  "@context": {
    "@vocab": "https://schema.org/",
    "@base": "https://api.example/",
    "firstname": "givenName",
    "lastname": "familyName",
    "street": "streetAddress",
    "id": "@id"
  },
  "id": "persons/42",
  "firstname": "John",
  "lastname": "Doe",
  "address": {
    "id": "addresses/1337",
    "street": "Mainstreet 23"
  }
}
```

</div><p>Ungeachtet der konkreten JSON-Struktur handelt es sich bei diesem Datensatz um zwei <em>Ressourcen</em> und deren <em>Beziehungen</em>. Die Daten lassen sich genauso gut tabellarisch darstellen:</p><table><thead><tr><th>Subjekt</th><th>Prädikat</th><th>Objekt</th></tr></thead><tbody><tr><td>https://api.example/persons/42</td><td><a href="https://schema.org/givenName">https://schema.org/givenName</a> </td><td>John</td></tr><tr><td>https://api.example/persons/42</td><td><a href="https://schema.org/familyName">https://schema.org/familyName</a> </td><td>Doe</td></tr><tr><td>https://api.example/persons/42</td><td><a href="https://schema.org/address">https://schema.org/address</a> </td><td>https://api.example/addresses/1337</td></tr><tr><td>https://api.example/addresses/1337</td><td><a href="https://schema.org/streetAddress">https://schema.org/streetAddress</a> </td><td>Mainstreet 23</td></tr></tbody></table><p>Wir haben hier eine Sammlung von Fakten, die Aussagen über eine Ressource (Subjekt) treffen. Die Ressourcen sind eindeutig über <a href="https://de.wikipedia.org/wiki/Internationalized_Resource_Identifier" target="_blank">IRI</a> s identifiziert. Ebenso ist die Art der Aussage (Prädikat) durch Verwendung von IRIs semantisch eindeutig. Als Objekt einer Aussage können primitive Datentypen verwendet werden, wie z. B. die Zeichenkette "John" als <code>givenName</code>. Durch Verwendung von IRIs als Objekt können wir auf andere Ressourcen verweisen, so wie dies bei der Adresse der Fall ist. Da es sich bei einer IRI um eine global eindeutige ID handelt, können sogar Ressourcen über APIs hinweg miteinander verlinkt werden. Daher kommt die Bezeichnung "Linked Data". Bei HTML nutzen wir dieses Prinzip ganz selbstverständlich, in strukturierten Daten fehlen solche Links leider viel zu oft.</p><p>Über die sogenannten "Daten-Tripel" aus Subjekt, Prädikat und Objekt lassen sich beliebige Fakten formulieren. Bei diesem Datenmodell handelt es sich um das <a href="https://de.wikipedia.org/wiki/Resource_Description_Framework" target="_blank">"Resource Description Framework" (RDF)</a> . RDF ist unabhängig von einer bestimmten Serialisierung, JSON-LD ist nur eine davon. Darüber hinaus gibt es zum Beispiel RDF-XML, Notation3 oder Turtle. RDF ist im akademischen Umfeld beliebt, jedoch nie in der alltäglichen Praxis von Webentwickler*innen angekommen, da die meisten Serialisierungen ungleich komplizierter zu handhaben sind als JSON.</p><p>Dies ändert sich mit JSON-LD grundlegend, da wir die Vorteile von einfach verwendbarem JSON und der starken Semantik von RDF vereinen. Egal in welcher Struktur und mit welchen Bezeichnern ein Backend Daten ans Frontend sendet: Es handelt sich dem Wesen nach stets um "Daten-Tripel", die wir in ein uns genehmes Format serialisieren können. Dies reicht von der simplen Änderung von Bezeichnern bis hin zur Umstrukturierung ganzer JSON-Bäume.</p><p>JSON-LD ermöglicht es, die Semantik der Daten losgelöst von der Serialisierung des Backends zu betrachten und die Daten in einer neuen Form zu serialisieren. Das Frontend kann dazu die Form wählen, die es für am besten geeignet hält. Im Folgenden zeige ich einige Beispiele, wie die obigen Daten im Frontend serialisiert werden können.</p><h2>Eigene JSON-Bezeichner und vollständige IRIs</h2><p>Das Frontend-Team entscheidet sich, die Struktur des Backends beizubehalten, aber eigene JSON-Bezeichner zu wählen und über vollständige IRIs zu verlinken. Auf die Addresse kann dann leicht über <code>person.address</code> zugegriffen werden. Weitere Daten werden von <code>person.address.iri</code> geladen.</p><div>

```javascript
{
  "@context": {
    "@vocab": "https://schema.org/",
    "first": "givenName",
    "last": "familyName",
    "location": "streetAddress",
    "iri": "@id"
  },
  "iri": "https://api.example/persons/42",
  "address": {
    "iri": "https://api.example/addresses/1337",
    "location": "Mainstreet 23"
  },
  "last": "Doe",
  "first": "John"
}
```

</div><h2>Flache Liste von Ressourcen</h2><p>Das Frontend-Team entscheidet sich, alle Ressourcen in einer flachen Array-Liste vorzuhalten. Die Person enthält lediglich eine Referenz auf die IRI der Adresse. In dieser Form sind alle Ressourcen leicht über ihre ID zu ermitteln, ohne eine Hierarchie von Verschachtelungen durchgehen zu müssen. z.B.</p><div>

```javascript
data["@graph"].find((it) => it.id === "addresses/1337");
```

</div><div>

```javascript
{
  "@context": {
    "@vocab": "https://schema.org/",
    "@base": "https://api.example/",
    "id": "@id"
  },
  "@graph": [
    {
      "id": "addresses/1337",
      "streetAddress": "Mainstreet 23"
    },
    {
      "id": "persons/42",
      "address": {
        "id": "addresses/1337"
      },
      "familyName": "Doe",
      "givenName": "John"
    }
  ]
}
```

</div><h2>Umkehren der Verschachtelung</h2><p>Das Frontend-Team möchte eine andere Form der Verschachtelung. Hier kann das Frontend nun über <code>address.resident</code> auf die Person zugreifen, statt umgekehrt über <code>person.address</code> die Adresse einer Person zu ermitteln. Im Kontext wird dazu mit dem Schlüsselwort <code>@reverse</code> angegeben, dass es sich bei <code>resident</code> um die Beziehung <code>https://schema.org/address</code> handelt, jedoch Subjekt und Objekt vertauscht sind.</p><div>

```javascript
{
  "@context": {
    "@vocab": "https://schema.org/",
    "resident": {
      "@reverse": "address"
    },
    "uri": "@id"
  },
  "uri": "https://api.example/addresses/1337",
  "resident": {
    "uri": "https://api.example/persons/42",
    "givenName": "Doe",
    "familyName": "John"
  },
  "streetAddress": "Mainstreet 23"
}
```

</div><h2>Datenhaltung im Frontend</h2><p>Da das Frontend letzlich immer "Daten-Tripel" vom Backend lädt, kann es die Sammlung dieser Tripel im Speicher vorhalten und mit jeder Antwort vom Backend um weitere Fakten anreichern. Zunächst wird z. B. die Person geladen, dann deren Adresse, dann weitere verlinkte Daten wie z. B. Geoinformationen über den Wohnort. Die Faktensammlung auf Frontend-Seite wächst, wird in eine geeignete Form gebracht und dann von Frontend-Komponenten dargestellt.</p>
![datenhaltung_frontend.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/GnWj7UZgRIS7l5GbNSlg)
<h2>Fazit</h2><p>All dies ist möglich, weil es bei JSON-LD eben nicht auf die Syntax und Struktur eines JSON-Objekts ankommt, sondern die dahinterliegende Semantik entscheidend ist. Die wesentliche Frage lautet, welche <em>Daten-Tripel</em> ausgetauscht werden. In welcher Form diese serialisiert werden, bleibt den Teams selbst überlassen und kann unabhängig voneinander geändert werden.</p><h2>Ausblick</h2><p>In meinen Artikeln habe ich mich auf die Verarbeitung von Backend-Daten im Frontend fokussiert. Natürlich gilt das Gesagte aber auch für den umgekehrten Weg: Daten, die das Frontend zurück ans Backend sendet, sind mit JSON-LD ebenso unabhängig von einer konkreten Struktur. Das Backend kann darauf den eigenen Kontext anwenden und ist vor Änderungen auf Frontend-Seite gefeit. Das Gleiche gilt auch für den Datenaustausch zwischen Backend-Services. JSON-LD eignet sich zum Beispiel hervorragend, um den Datenaustausch zwischen Microservices zu realisieren oder Drittanbieter-APIs zu integrieren.</p><p>JSON-LD bietet mehr Funktionalität, als ich in meinen Artikeln unterbringen konnte. Abschließend daher noch einige Links für alle, die sich weiter mit dem Thema befassen wollen. Ich freue mich auch über Feedback in den Kommentaren.</p><p> </p><ul><li><a href="https://json-ld.org" target="_blank">JSON-LD Homepage</a> </li><li><a href="https://json-ld.org/spec/latest/json-ld/" target="_blank">JSON-LD Spezifikation</a> </li><li><a href="https://github.com/digitalbazaar/jsonld.js/" target="_blank">jsonld.js JavaScript Bibliothek</a> </li><li><a href="http://www.hydra-cg.com" target="_blank">Hypermedia-driven Web APIs mit JSON-LD</a> </li></ul>

Linked Data mit JSON-LD: Semantische Fakten statt fester Baumstruktur

<p>Viele Webanwendungen bestehen aus einem JavaScript-Frontend, das JSON-Daten aus einem Backend abruft. Der Datenaustausch basiert dabei in der Regel auf Namenskonventionen für JSON-Bezeichner und vorab festgelegten „API-Endpunkten“. Eine JSON-LD-basierte API ist eine interessante Alternative zu dieser Herangehensweise.</p><p>Der „klassische“ JSON-basierte Ansatz führt schnell zu Problemen: Eine neue Version des Backends liefert Daten unter neuen JSON-Bezeichnern aus, das Frontend wurde nicht angepasst – <em>peng</em> ? „‚undefined‘ is not an object“.</p><p>Die folgenden Handlungen sind meiner Erfahrung nach kritisch:</p><ol><li>JSON-Bezeichner werden geändert.</li><li>Die Struktur der Daten wird verändert.</li><li>Bestimmte Daten werden nicht mehr direkt ausgeliefert, sondern erfordern eine zusätzliche HTTP-Anfrage.</li><li>Backend-seitig ändern sich „Endpunkte“, welche die Daten bereitstellen.</li></ol><p>Im schlimmsten Fall kommt es zu Fehlern, weil das Frontend die Änderungen nicht berücksichtigt. Im besten Fall sind alle Beteiligten über die Änderungen informiert und machen sich an die Arbeit. Selbst dann ist es lästig, dass im Frontend überhaupt Arbeit anfällt. Zumal dies unnötig ist, wie ich zeigen möchte.</p><p>Weder sollten die genannten Änderungen zu Fehlern führen, noch sollte in langwierigen Meetings darüber diskutiert werden, wie einzelne JSON-Bezeichner lauten und wie die Daten verschachtelt werden. Die verantwortlichen Teams können dies vermeiden, indem sie den Datenaustausch von der konkreten JSON-Syntax unabhängig machen.</p><p>Du lernst,</p><ol><li>wie du unterschiedliche JSON-Bezeichner in Backend und Frontend verwenden kannst</li><li>wie du Daten lädst, ohne vorab im Frontend die „Endpunkte“ zu kennen</li><li>wie du das Frontend von den konkreten Datenstrukturen des Backends entkoppelst</li></ol><p>Als erstes werden wir die JSON-Bezeichner von Frontend und Backend entkoppeln. Nehmen wir an, ein Backend liefert Daten zu einer Person als JSON-Objekt mit bestimmten Eigenschaften:</p><div>

```javascript
{
    "id": "42",
    "firstname": "John",
    "lastname": "Doe",
    "birthday": "1978-05-17"
}
```

</div><p>Für gewöhnlich verlässt sich das Frontend auf die verwendeten Bezeichner. Darauf basierend wird eine Ansicht aufgebaut. Eine Funktion erzeugt bespielsweise eine Begrüßung anhand der Eigenschaften <code>firstname</code> und <code>lastname</code>:</p><div>

```ecmascript
function greet(person) {
  return `Hello, ${person.firstname} ${person.lastname}`;
}
```

</div><p>Das Backend-Team ändert nun die ausgelieferte Datenstruktur wie folgt ab:</p><div>

```javascript
{
    "id": "42",
    "firstName": "John",
    "lastName": "Doe",
    "birthday": "1978-05-17"
}
```

</div><p>Wir müssen das Frontend nun ebenfalls anpassen und die neuen Bezeichner <code>firstName</code> und <code>lastName</code> verwenden.</p><p>Um diese Abhängigkeit von den Bezeichnern aufzulösen, bietet sich die Verwendung von <a href="https://json-ld.org/" target="_blank">JSON-LD</a>  an. Bei JSON-LD handelt es sich um eine Erweiterung des JSON-Formats. Das Kürzel „LD“ steht für „Linked Data“ – was es damit auf sich hat, werden wir später noch sehen.</p><p>Um JSON-LD zu nutzen, müssen wir an den eigentlichen Backend-Daten nichts verändern. Sie müssen lediglich um einen „Kontext“ erweitert werden. Dieser Kontext beschreibt die <em>Semantik</em> der Daten. Ein JSON-LD Datensatz könnte in unserem Beispiel so aussehen:</p><div>

```javascript
{
  "@context": {
    "@vocab": "https://schema.org/",
    "firstname": "givenName",
    "lastname": "familyName",
    "birthday": "birthDate",
    "id": "@id"
  },
  "id": "42",
  "firstname": "John",
  "lastname": "Doe",
  "birthday": "1978-05-17"
}
```

</div><p>Die eigentlichen Daten und JSON-Bezeichner haben sich nicht verändert. Wir haben dem Objekt lediglich die Eigenschaft <code>@context</code> hinzugefügt. Dieser Kontext legt die Bedeutung der einzelnen JSON-Bezeichner fest. In Zeile 3 besagt <code>@vocab</code>, dass wir das Vokabular von <a href="https://schema.org/" target="_blank">schema.org</a>  als Grundlage verwenden wollen. Schema.org stellt eindeutige URIs zur Auszeichnung von Daten zur Verfügung, um z.B. Inhalte aus Webseiten für Suchmaschinen verständlich zu machen. So lässt sich zum Beispiel eine Zeichenkette, die als <code>https://schema.org/givenName</code> ausgezeichnet ist, eindeutig als Vorname einer Person erkennen. Das Vokabular von schema.org können wir mit JSON-LD nutzen, um auch die Daten für unser Frontend auszuzeichnen.</p><p>Die nächsten Zeilen innerhalb von <code>@context</code> bilden die im Backend verwendeten Bezeichner auf schema.org Eigenschaften ab. Hinter dem Bezeichner <code>firstname</code> steckt also die Eigenschaft <code>https://schema.org/givenName</code>. Ebenso werden <code>lastname</code> und <code>birthday</code> semantisch ausgezeichnet. Der letzte Eintrag im Kontext gibt an, dass der Bezeichner <code>id</code> das Objekt eindeutig identifiziert. Dies wird später noch wichtig, wenn wir Daten vom Backend laden wollen.</p><p>Der Vorteil von JSON-LD liegt unter anderem darin, dass das Frontend seinen eigenen Kontext festlegen kann, um selbstständig die Bezeichnungen auf Frontend-Seite fest zu legen:</p><div>

```javascript
var context = {
  "@vocab": "https://schema.org/",
  first_name: "givenName",
  last_name: "familyName",
  birth_date: "birthDate",
  person_id: "@id"
}
```

</div><p>Das Frontend legt mit diesem Kontext eigene Bezeichner für die schema.org-Eigenschaften fest. Indem dieser Kontext auf die Daten vom Server angewendet wird, erhält das Frontend einen Datensatz, der vor Backend-seitigen Änderungen gefeit ist:</p><div>

```ecmascript
import * as jsonld from "jsonld";
 
// Frontend-Kontext auf Backend-Daten anwenden
jsonld.compact(context, backendData, (err, person) => {
  greet(person);
});
 
function greet(person) {
  console.log(`Hello, ${person.first_name} ${person.last_name}`);
}
```

</div><p>Die Funktion <code>jsonld.compact</code> stammt aus der Bibliothek <a href="https://github.com/digitalbazaar/jsonld.js/" target="_blank">jsonld.js</a> . Sie übersetzt die Backend-Daten (<code>backendData</code>) in den Frontend-Kontext (<code>context</code>). Das Ergebnis steht der Callback-Funktion in der Variable <code>person</code> zur Verfügung. Diese enthält nun folgendes Objekt:</p><div>

```javascript
{
  "@context": {
    "@vocab": "https://schema.org/",
    "first_name": "givenName",
    "last_name": "familyName",
    "birth_date": "birthDate",
    "person_id": "@id"
  },
  "person_id": "42",
  "birth_date": "1978-05-17",
  "last_name": "Doe",
  "first_name": "John"
}
```

</div><p>Somit konnten wir die Backend-Daten im Frontend auf selbst gewählte Bezeichner abbilden. Ändern sich die Bezeichnungen im Backend hat dies keinen Einfluss mehr auf den Frontend-Code, solange die verwendete Semantik die gleiche bleibt. Teams können sich darauf konzentrieren, über die fachliche Bedeutung der Daten zu sprechen, die sie austauschen wollen. Sie müssen nicht mehr über einzelne Bezeichner oder bestimmte Notationen wie „Camel- vs. Snake-Case“ diskutieren. Änderungen auf dieser Ebene führen nicht mehr zu Problemen. Stattdessen können sich die Teams auf die fachlich wichtige Semantik des Datenaustauschs konzentrieren.</p><p>Um JSON-LD und das beschriebene Beispiel in Aktion sehen zu können, habe ich ein JSFiddle vorbereitet:</p><p><script async src="//jsfiddle.net/aveltens/d3tzfhjx/21/embed/"></script></p><p>Darüber hinaus bietet sich der <a href="https://json-ld.org/playground/#startTab=tab-compacted&json-ld=%7B%22%40context%22%3A%7B%22%40vocab%22%3A%22https%3A%2F%2Fschema.org%2F%22%2C%22firstname%22%3A%22givenName%22%2C%22lastname%22%3A%22familyName%22%2C%22birthDay%22%3A%22birthDate%22%2C%22id%22%3A%22%40id%22%7D%2C%22id%22%3A%2242%22%2C%22firstname%22%3A%22John%22%2C%22lastname%22%3A%22Doe%22%2C%22birthDay%22%3A%221978-05-17%22%7D&context=%7B%22%40vocab%22%3A%22https%3A%2F%2Fschema.org%2F%22%2C%22first_name%22%3A%22givenName%22%2C%22last_name%22%3A%22familyName%22%2C%22birth_date%22%3A%22birthDate%22%2C%22person_id%22%3A%22%40id%22%7D" target="_blank">JSON-LD-Playground</a>  für tiefergehende Experimente an.</p><p>Ich habe gezeigt, wie du mithilfe von JSON-LD die Bezeichner von Frontend und Backend entkoppeln kannst. JSON-LD bietet jedoch noch vieles mehr! Im nächsten Artikel werden wir weitere Daten vom Backend laden, ohne dass im Frontend „API-Endpunkte“ festgelegt sind.</p><p><a href="/json-ld-verlinkte-daten-statt-hart-kodierter-endpunkte">Weiter mit <strong>„JSON-LD: Verlinkte Daten statt hart-kodierter Endpunkte“</strong></a> </p>

Schmerzloser Datenaustausch: Mit JSON-LD Backend und Frontend entkoppeln

<p>APIs sind längst mehr als technische Schnittstellen zwischen Backend und Frontend. Für viele Unternehmen werden APIs zum Kern des Geschäftsmodells. Unter den Stichworten <a href="/wissens-hub/blog/api-as-a-product">„API as a Product“</a>  und „API-first“ rücken disruptive Unternehmen APIs in den Fokus ihres geschäftlichen Handelns und bedienen so völlig neue Märkte.</p><p>Um diesen Ansatz zum Erfolg zu führen, muss bereits beim Design einer API darauf geachtet werden, dass das fachliche Angebot im Vordergrund steht und nicht technische Implementierungsdetails. Ich zeige in diesem Artikel anhand eines Beispiels, wie dies mit Hilfe von <a href="https://schema.org" target="_blank">Schema.org</a>  gelingen kann.</p><h2>Fachlichkeit fokussieren – auch bei API-first</h2><p>Beim Design einer API sollte sich ein Unternehmen zunächst folgende Fragen stellen:</p><ul><li>Welche Dienste bieten wir an?</li><li>Welche Daten bieten einen Nutzen für unsere Kunden?</li><li>Was möchten Kunden mit unserer API erreichen?</li></ul><p>Die Überlegungen sind also sehr Konsumenten-orientiert und betrachten die API tatsächlich als Produkt welches angeboten wird. In Verbindung mit „API as a Product“ bietet sich ein „API-first“ Ansatz an, bei dem die API die erste Benutzungsschnittstelle einer Anwendung darstellt, noch bevor ein grafisches Interface entwickelt wird.</p><p>Für ein erfolgreiches API-Produkt reicht es nicht aus, das interne Datenmodell als JSON auszuliefern. Anbieter einer API müssen Domänen orientiert denken und nicht in technischen Details. Fragen nach JSON-Bezeichnern, Daten-Verschachtelung und URL-Strukturen sollten nicht im Fokus stehen, sondern erst nachrangig betrachtet werden. Wichtiger ist eine klar kommunizierte Fachlichkeit und sehr gute Zugänglichkeit für Entwickler:innen (Developer Experience).</p><p>Der Fokus auf die Fachlichkeit deckt sich mit dem Anspruch des Domain-driven Designs (DDD). Bei DDD werden Konzepte der Fachdomäne auf die Modellierung in Software übertragen. Produkt-Teams können Methoden aus DDD nutzen, um fachliche Konzepte aus der Geschäftsdomäne zu identifizieren, die über eine API bereitgestellt werden sollen. Bei der Modellierung dieser Konzepte als Web-Ressourcen kann Schema.org helfen, das ein breites, erprobtes Vokabular für unterschiedlichste Domänen bereitstellt.</p><h2>Beispiel: Kino-API</h2><p>Um dies zu verdeutlichen, möchte ich zunächst mit einem Negativbeispiel beginnen. Anschließend werden wir die Domänenkonzepte heraus arbeiten und diese mit Hilfe von Schema.org in einer besseren Variante der API abbilden. Als Beispiel dient eine API zum Buchen von Kinotickets.</p><p>Die API könnte derart gestaltet sein, dass über <code>/events/<id></code> Daten zum Ausstrahlungstermin eines Films abgerufen werden können:</p>

```
GET /events/4711

```

<div>

```javascript
{
  "id": "4711",
  "start": "2019-03-28 21:00",
  "movie_id": 14123,
  "movie_name": "Aquaman",
  "image": "static/images/aquaman.png",
  "price": 1600,
  "location_id": "123",
  "available": true,
  "tickets_left": 120,
  "rebate_tariff": "A-12",
  "hidden": false,
  "promote": true
}
```

</div><p>Dieser Datensatz birgt zahlreiche Probleme:</p><ul><li>Er vermischt mehrere Domänenkonzepte, wie Ausstrahlungstermin, Film, Preise, Verfügbarkeiten…</li><li>Er enthält eher technische Flags, ohne klare fachliche Bedeutung (<code>hidden</code>, <code>available</code>, <code>promote</code>)</li><li>Es ist unklar, ob und wie weitere Daten abgerufen werden können (z.B. Filmdetails)</li><li>Er exponiert interne Identifier (<code>id</code>, <code>rebate_tariff</code>, <code>location_id</code>)</li><li>Es fehlen Informationen (Zum Beispiel beim Preis: Ist <code>1600</code> eine ID oder ein Wert? Welche Einheit / Währung?)</li><li>Was stellt das verlinkte Bild (<code>image</code>) dar? Ist es für den Film generell gültig, oder nur für diesen Ausstrahlungstermin?</li></ul><p>Solche Strukturen gelten bei bestehenden APIs oft als „historisch gewachsen“. Felder kamen hinzu, weil „Das Frontend“™ oder irgendein (Micro)service die Daten „nun einmal braucht“. Der Knackpunkt hierbei ist jedoch nicht das Alter einer API, sondern der mangelnde Fokus auf die Fachlichkeit. Auch ein API-first Ansatz kann sich in die völlig falsche Richtung entwickeln, wenn die Geschäftsdomäne aus dem Blickfeld gerät.</p><p>Wie sieht ein besserer Ansatz aus? Zunächst einmal gilt es zu überlegen, welche fachlichen Entitäten über eine API bereitgestellt werden sollen. Werkzeuge aus DDD können helfen, diese zu identifizieren. Hier sind es zum Beispiel:</p><ul><li>Filme</li><li>Vorstellungstermine</li><li>Kinos</li><li>Preise / Angebote</li><li>Verfügbarkeiten</li><li>…</li></ul><p>Weiterhin gilt es zu überlegen, welche Services über die API bereitgestellt werden:</p><ul><li>Vorstellungstermine zu Filmen suchen</li><li>Angebote einsehen</li><li>Tickets buchen</li><li>Platzreservierung vornehmen</li><li>…</li></ul><p>Einer guten API gelingt es, diese fachlichen Konzepte und Dienste nach außen zu kommunizieren, sodass diese zumindest leicht verständlich für Client-Entwicker:innen sind – im Idealfall sogar maschinenverständlich. Um dies zu erreichen, kann ein Blick in das Vokabular von Schema.org helfen, das bereits eine Vielzahl von Konzepten im Web modelliert. Für Angebote von Kinos werden wir fündig:</p><table><thead><tr><th>Entität</th><th>Schema.org Typ</th></tr></thead><tbody><tr><td>Film</td><td><a href="http://schema.org/Movie">http://schema.org/Movie</a> </td></tr><tr><td>Vorstellungstermin</td><td><a href="http://schema.org/ScreeningEvent">http://schema.org/ScreeningEvent</a> </td></tr><tr><td>Angebot</td><td><a href="http://schema.org/Offer">http://schema.org/Offer</a> </td></tr><tr><td>Kino</td><td><a href="http://schema.org/MovieTheater">http://schema.org/MovieTheater</a> </td></tr><tr><td>Ticket</td><td><a href="http://schema.org/Ticket">http://schema.org/Ticket</a> </td></tr><tr><td>Sitzplatz</td><td><a href="http://schema.org/Seat">http://schema.org/Seat</a> </td></tr><tr><td>Reservierung</td><td><a href="http://schema.org/Reservation">http://schema.org/Reservation</a> </td></tr></tbody></table><p>In vielen Fällen muss man für die eigene API nicht das Rad neu erfinden, sondern kann auf bestehende und allgemein verständliche Konzepte zurückgreifen. Selbst in hoch-innovativen Geschäftsfeldern finden sich immer wieder allgemeine Konzepte, wie Preise, Personen, Orte, die sich über Schema.org abbilden lassen. Ein erfolgreiches API-Produkt überzeugt durch die angebotenen Daten und Services sowie leichte Integration. Es hält Clients nicht allein durch Kopplung an das eigene proprietäre Datenmodell bei sich (Vendor-lock-in).</p><p>Für die Nutzung von Schema.org in APIs bietet sich eine JSON-LD Repräsentation an. Mit Hilfe von JSON-LD können wir erreichen, dass unsere API diese fachlichen Konzepte in Form von klassischem JSON darstellen kann. Näheres habe ich <a href="/wissens-hub/blog/datenaustausch-mit-json-ld">an anderer Stelle</a>  bereits beschrieben.</p><p>Das Beispiel von oben können wir schrittweise als JSON-LD Datensatz wie folgt modellieren. Ein Ausstrahlungstermin lässt sich zunächst als <a href="http://schema.org/ScreeningEvent">http://schema.org/ScreeningEvent</a>  beschreiben:</p><div>

```javascript
{
   "@context": "https://schema.org/",
   "type": "ScreeningEvent",
   "startDate": "2019-03-21T20:00"
 }
```

</div><p>Weiterhin benötigen wir Informationen über den ausgestrahlten Film. Dieser lässt sich über <a href="http://schema.org/workPresented" target="_blank">http://schema.org/workPresented</a> , mit dem Ausstrahlungstermin verknüpfen. Ähnlich lässt sich der Ort über <a href="http://schema.org/location" target="_blank">http://schema.org/location</a>  angeben:</p><div>

```javascript
{
  "@context": "https://schema.org/",
  "type": "ScreeningEvent",
  "startDate": "2019-03-21T20:00",
  "workPresented": {
    "type": "Movie",
    "name": "Aquaman",
    "image": "/static/images/aquaman.png"
  },
  "location": {
    "type": "MovieTheater",
    "name": "Kino City-Central"
  }
}
```

</div><p>Hier werden nun der ausgestrahlte Film und das Kino klar als eigene fachliche Entitäten kommuniziert. Später können wir noch entscheiden, ob wir die Feldnamen von Schema.org 1:1 übernehmen, oder mittels JSON-LD-Kontext das Vokabular auf eigene Bezeichner abbilden. Ebenso können wir entscheiden, unter welchen URIs die Ressourcen ausgeliefert werden, ob wir die Daten des Films bzw. Kinos teilweise oder komplett einbetten, oder <a href="/wissens-hub/blog/json-ld-verlinkte-daten-statt-hart-kodierter-endpunkte">über deren IDs verlinken</a> . Dies sind jedoch Implementierungsdetails der API, welche nachrangig betrachtet werden können.</p><p>Spannender sind zunächst noch Preise, Angebote und Verfügbarkeiten. Bei Schema.org findet sich das Konzept einer <code>Offer</code> bzw. <code>AggregateOffer</code>, welche zum Beispiel so aussehen könnte:</p><div>

```javascript
{
  "@context": "https://schema.org/",
  "type": "AggregateOffer",
  "price": 16,
  "priceCurrency": "EUR",
  "availability": "OnlineOnly",
  "offerCount": 120
}
```

</div><p>Die Ressource kommuniziert klar den Preis und die Verfügbarkeit. Boolesche-Flags sind an keiner Stelle notwendig. Eine <code>Offer</code> ist entweder an einem <code>ScreeningEvent</code> vorhanden, oder nicht. Auch Sondertarife und Preisnachlässe lassen sich über dieses Konzept kommunizieren:</p><div>

```javascript
{
   "@context": "https://schema.org/",
   "type": "ScreeningEvent",
   // [...]
   "offers": [
      {
        "@type": "AggregateOffer",
        "price": 16,
        "priceCurrency": "EUR",
        "availability": "OnlineOnly",
        "offerCount": 120
      },
      {
        "type": "AggregateOffer",
        "name": "Rebate for students",
        "price": 12,
        "priceCurrency": "EUR"
      }
   ]
 }
```

</div><p>Was wir aus dem Negativbeispiel bisher noch nicht berücksichtigt haben ist das <code>promote</code>-Flag. Es ist unklar, was damit überhaupt gemeint ist. Dies lässt sich nur mit den Fachverantwortlichen klären. Nehmen wir hier an, es dient dazu, bestimmte Filmvorstellungen besonders in den Vordergrund zu stellen, z.B. in einem Frontend prominent auf der Startseite zu platzieren. Dies hat jedoch fachlich überhaupt nichts mit der Vorstellung an sich zu tun, ist also fehl am Platz. Für solche Fälle ist es besser, getrennte Resource-Collections für unterschiedliche Use-Cases in der API anzubieten, z.B.:</p><table><thead><tr><th>Collection-URI</th><th>Bedeutung</th></tr></thead><tbody><tr><td><code>/events</code></td><td>Liefert alle aktuellen Filmvorstellungen</td></tr><tr><td><code>/promotions</code></td><td>Liefert besonders beworbene Filmvorstellungen</td></tr></tbody></table><p>Auch wenn die eigene Domäne nicht zu 100% über Schema.org abgebildet werden kann, sollte man beim Design der API stets die Fachlichkeit im Blick behalten und die API so gestalten, dass fachliche Entitäten und Eigenschaften ausgeliefert werden. Auch sollte man genau prüfen, ob sich Konzepte <em>wirklich nicht</em> abbilden lassen, oder ob die Fachlichkeit in Wahrheit durch technische Details verdeckt wird. Implementierungsdetails einer Anwendung sollten keine Auswirkung auf deren API haben. Es kann auch sinnvoll sein, auf spezialisierte Vokabulare zurück zu greifen. Im eCommerce findet zum Beispiel <a href="http://purl.org/goodrelations/">GoodRelations</a>  breite Verwendung.</p><p>Entitäten die tatsächlich inhärent eigene Konzepte abbilden, können durch einen neuen Typen im unternehmenseigenen Vokabular aus der Ubiquitous Language bedient werden:</p><div>

```javascript
 {
   "@context": "https://enterprise.example/vocab/",
   "type": "Quuxbaz",
   "foobarization_level": 17
 }
```

</div><p>Mit solchen Schöpfungen sollte man jedoch möglichst sparsam umgehen, da sie die Interoperabilität und allgemeine Verständlichkeit der API einschränken. Mindestens sollte das entsprechende Vokabular gut dokumentiert sein, idealerweise über den Abruf der zugehörigen URLs:</p>

```
https://enterprise.example/vocab/Quuxbaz
https://enterprise.example/vocab/foobarization_level

```

<p>Ruft man diese URLs im Browser ab, sollte man direkt auf der entsprechenden Dokumentationsseite landen. Auch diesbezüglich geht Schema.org mit gutem Beispiel voran und man darf sich gerne daran orientieren, um eine großartige Developer Experience zu schaffen, die sich positiv auf eine breite Adaption der API auswirkt.</p><h2>Fazit</h2><p>In diesem Artikel habe ich dargelegt, dass erfolgreiche API-Produkte sich auf die Geschäftsdomäne konzentrieren sollten. Ein Negativbeispiel hat verdeutlicht, welche Probleme mangelnder Fokus auf die Fachlichkeit birgt. Mit Hilfe von Schema.org haben wir ein besseres Design entwickelt. Abschließend habe ich gezeigt, dass die Grenzen dieses Ansatzes nicht bei Schema.org liegen. Bei Bedarf können spezialisierte oder unternehmenseigene Vokabulare hinzugezogen werden.</p>

Domain-driven API-first Design mit Schema.org

<p>Mit <a href="https://json-ld.org/" target="_blank">JSON-LD</a>  können Abhängigkeiten zwischen Frontend und Backend reduziert werden. Im <a href="/wissens-hub/blog/datenaustausch-mit-json-ld/">letzten Artikel</a>  habe ich gezeigt, wie sich die JSON-Bezeichner entkoppeln lassen. Als nächstes lernst du, wie ein Frontend Daten laden kann, ohne abhängig von bestimmten Endpunkten im Backend zu sein. Das Laden von Daten wird zum einen deutlich vereinfacht, zum anderen bleibt das Frontend stabiler gegenüber Änderungen im Backend.</p><p>Als Beispiel dient wieder ein Datensatz über eine Person:</p><div>

```javascript
{
    "id": "42",
    "firstname": "John",
    "lastname": "Doe",
    "address_id": "1337" 
}
```

</div><p>Offenbar ist zu dieser Person auch eine Adresse unter der ID <code>1337</code> hinterlegt. Um diese Annahme zu bestätigen ist ein Blick in die API-Dokumentation nötig. Dort erfährt das Frontend-Team dann (hoffentlich) auch, wie genau die Adresse geladen werden kann. Ein URL-Template wie <code>https://api.example/addresses/<id></code> wird dann oft fest im Code verdrahtet.</p><p>Mit JSON-LD verfolgen wir einen anderen Ansatz. Wie im <a href="/wissens-hub/blog/datenaustausch-mit-json-ld/">letzten Artikel</a>  erwähnt, steht das „LD“ in JSON-LD für <a href="https://www.w3.org/DesignIssues/LinkedData.html" target="_blank">„Linked Data“</a> . Statt nur lokal gültiger IDs verwenden wir global eindeutige, dereferenzierbare URIs, um Ressourcen im Web zu identifizieren. Die ID eines JSON-LD-Datensatzes ist immer ein vollständiger, internationalisierter URI (im Folgenden <a href="https://de.wikipedia.org/wiki/Internationalized_Resource_Identifier" target="_blank">IRI</a> : Internationalized Resource Identifier). Um den obigen Datensatz als JSON-LD abzubilden, fügen wir wieder einen Kontext hinzu:</p><div>

```javascript
{
  "@context": {
    "@vocab": "https://schema.org/",
    "@base": "https://api.example/",
    "firstname": "givenName",
    "lastname": "familyName",
    "id": "@id",
    "address_id": {
      "@id": "address",
      "@type": "@id"
    }
  },
  "id": "persons/42",
  "firstname": "John",
  "lastname": "Doe",
  "address_id": "addresses/1337"
}
```

</div><p>Wie bereits im letzten Artikel bilden wir die vom Backend verwendeten JSON-Bezeichner auf das Vokabular von <a href="https://schema.org/" target="_blank">schema.org</a>  ab. Hinter <code>firstname</code> steckt also wieder ein <code>https://schema.org/givenName</code> und hinter <code>lastname</code> entsprechend ein <code>https://schema.org/familyName</code>. Bei <code>address_id</code> verwenden wir eine etwas komplexere Konfiguration. Zunächst legen wir mit <code>"@id": "address"</code> fest, dass es sich um eine <code>https://schema.org/address</code> handelt. Mit <code>"@type": "@id"</code> sagen wir zusätzlich, dass wir nur die ID der Adresse hinterlegt haben und kein komplettes Adress-Objekt.</p><p>An den Daten selbst hat sich diesmal eine Kleinigkeit geändert: Statt „42“ und „1337“ hinterlegen wir die relativen Pfade <code>persons/42</code> und <code>addresses/1337</code>. Zusammen mit dem im Kontext unter <code>@base</code> hinterlegten Basis-IRI ergibt sich für die Adresse der vollständige IRI <code>https://api.example/addresses/1337</code>.</p><p>Im Frontend verwenden wir wieder einen eigenen Kontext und legen so die lokalen Bezeichner für die schema.org Eigenschaften fest:</p><div>

```javascript
const context = {
  "@vocab": "https://schema.org/",
  "first_name": "givenName",
  "last_name": "familyName",
  "postal_address": "address",
  "iri": "@id"
}
```

</div><p>Indem wir den Frontend-Kontext anwenden, erhalten wir folgendes Objekt:</p><div>

```ecmascript
var person = {
  "@context": { /** ... */ },
  "iri": "https://api.example/persons/42",
  "postal_address": {
    "iri": "https://api.example/addresses/1337"
  },
  "last_name": "Doe",
  "first_name": "John"
}
```

</div><p>Hier sehen wir nun leicht, wie wir die Adresse nachladen können, nämlich einfach von <code>person.postal_address.iri</code>. Es ist nicht nötig, vorab im Frontend einen Endpunkt für Adressen zu kennen und die ID korrekt in ein URL-Template oder Ähnliches einzubauen. Stattdessen können wir eine generische Ladelogik implementieren:</p><div>

```ecmascript
jsonld.compact(personDataFromBackend, context, (err, person) => {
  loadData(person.postal_address);
});
 
function loadData(resource) {
    console.log(`Loading ${resource.iri}`);
    // do http request ...
}
```

</div><p>Gegenüber Änderungen des IRI ist das Frontend immun. Ändert dieser sich zum Beispiel zu <code>https://api.example/person/42/address</code> sind keine Anpassungen im Frontend nötig. Das Backend liefert dann <code>"address_id": "person/42/address"</code> und die Ladelogik funktioniert wie gehabt.</p><p>Selbst wenn sich das Backend-Team entscheidet, zusätzlich zur ID einige Adressdaten vorab mit zu senden, ändert sich im Frontend nichts. Lediglich das Backend ändert Daten und Kontext wie folgt:</p><div>

```javascript
{
  "@context": {
    "@vocab": "https://schema.org/",
    "@base": "https://api.example/",
    "firstname": "givenName",
    "lastname": "familyName",
    "street": "streetAddress",
    "id": "@id"
  },
  "id": "persons/42",
  "firstname": "John",
  "lastname": "Doe",
  "address": {
    "@id": "addresses/1337",
    "street": "Mainstreet 23"
  }
}
```

</div><p>An der Semantik der Daten hat sich nichts geändert hat, daher funktioniert das Frontend wie gehabt weiter. Das Backend liefert ja weiterhin die ID der Adresse aus. Die hinzu gekommene <code>https://schema.org/streetAddress</code> können, aber müssen wir im Frontend nicht nutzen. Es ist aber generell empfehlenswert, das Frontend so zu implementieren, dass mitgelieferte Daten bereits verwendet werden, bis der Ladevorgang von ggf. zusätzlichen Daten abgeschlossen ist.</p><p>Wie wir sehen, gibt es mit <a href="https://json-ld.org/" target="_blank">JSON-LD</a>  keinen Grund mehr, „Endpunkte“ im Frontend hart zu kodieren. IDs werden zu abrufbaren IRIs – JSON wird zu <a href="https://www.w3.org/DesignIssues/LinkedData.html">Linked Data</a> . In dieser Form werden Daten auch unabhängig von einer bestimmten JSON-Struktur und -Verschachtelung. Dies werde ich im nächsten Artikel näher beleuchten.</p><p>Ich habe auch wieder ein JSFiddle mit dem Beispiel aus diesem Artikel vorbereitet:</p><p><script async src="//jsfiddle.net/aveltens/yot1anvd/embed/"></script></p><p><a href="/wissens-hub/blog/json-linked-data">Weiter mit <strong>„Linked Data mit JSON-LD: Semantische Fakten statt fester Baumstruktur“</strong></a> </p>

JSON-LD: Verlinkte Daten statt hart-kodierter Endpunkte

<h2>Teil 3 – Die Gretchenfrage: Plattform oder Ökosystem?</h2><p><em>Digitale Plattformen sind ein erfolgreiches Geschäftsmodell in vielen Bereichen geworden. Sie bringen Marktakteure an einem zentralen Ort zusammen und schaffen einen lukrativen Handelsplatz. Eine Plattform in neuen Bereichen zu etablieren, ist daher das Ziel vieler Digitalisierungsprojekte. Das „Winner takes all“-Prinzip der Plattformwelt ist jedoch sehr risikobehaftet. Diese Artikelreihe zeigt eine alternative Option auf.</em></p><ul><li><a href="/wissens-hub/blog/dezentrale-plattform-oekonomie-im-web-teil-1">Teil 1 – Winner takes all: Die Grenzen zentraler Plattformen</a> </li><li><a href="/wissens-hub/blog/dezentrale-plattform-oekonomie-im-web-teil-2">Teil 2 – Permissionless Innovation: Web-basierte Ökosysteme</a> </li><li><strong>Teil 3 – Die Gretchenfrage: Plattform oder Ökosystem?</strong></li></ul><p>Im letzten Teil habe ich Web-basierte Ökosysteme als mögliche Alternative zu zentralen Plattformen vorgestellt. Doch wann ist es sinnvoll, ein solches Ökosystem zu etablieren, statt auf eine Plattform zu setzen?</p><p>Um diese Frage zu klären, musst du dein Marktumfeld betrachten und entscheiden, welche Ziele du erreichen möchtest. Im Folgenden möchte ich auf einige Gegebenheiten eingehen, die darauf hindeuten, dass ein Web-Ökosystem die richtige Wahl ist:</p><ol><li>Partnerschaftliche Zusammenarbeit auf Augenhöhe soll gewährleistet werden.</li><li>Die Abhängigkeiten von bestehenden Plattformen sollen reduziert werden.</li><li>Geschäftsmodelle sollen auf innovative Funktionen fokussieren.</li><li>Hohe Datensouveränität soll gewährleistet werden.</li><li>Die Verantwortung für Datensicherheit soll verteilt werden.</li><li>Innovationen sollen ohne zentralen Gatekeeper entstehen können.</li></ol><h3>Partnerschaftliche Zusammenarbeit auf Augenhöhe</h3><p>Befindest du dich in einem Markt mit mehreren Mitbewerbern, von denen prinzipiell jeder als Betreiber einer neuen, gemeinsamen Plattform in Frage käme? Dann könnte es schwierig werden, deine potentiellen oder tatsächlichen Konkurrenten als Partner zu gewinnen. Warum sollte die Konkurrenz gerade dir diese Vormachtstellung überlassen? Unter solchen Gegebenheiten kann ein Ökosystem die partnerschaftliche Zusammenarbeit auf Augenhöhe ermöglichen und Synergien schaffen, wo sonst durch Missgunst Chancen vertan werden.</p><p>Wenn du jedoch in der Lage bist, als neutrale Instanz deine Partner unter einer Plattform zu vereinen, kann dies die bessere Wahl sein.</p><h3>Abhängigkeiten von bestehenden Plattformen reduzieren</h3><p>Gibt es in deinem Markt bereits eine etablierte Plattform, auf die du angewiesen bist, die aber gleichzeitig deine Innovationsfähigkeit einschränkt? Eine neue Plattform zu etablieren, ist aufgrund des bestehenden Netzwerkeffekts extrem schwierig. Warum sollte man sich von einer Abhängigkeit in die andere begeben? Ein offenes Ökosystem kann echte Alternativen bieten und daher den Markt zu deinen Gunsten kräftig aufwirbeln.</p><p>Wenn es jedoch noch keine Plattform gibt und du auch keine ernstzunehmende Konkurrenz auf diesem Gebiet erwartest, könnte dein Unternehmen eine zentrale Plattform etablieren, bevor es jemand anderes tut.</p><h3>Auf innovative Funktionen fokussieren</h3><p>Dein Geschäftsmodell sieht neue, innovative Anwendungen vor, die durch hilfreiche Funktionen überzeugen? Der Ökosystem-Ansatz kann dir helfen, diesen Fokus langfristig zu behalten und sich weniger mit Themen Datenschutz (Stichwort DSGVO), IT Security, Datenqualität, Betrugsprävention, Stabilität und Skalierung befassen zu müssen. Fokussiere dein Geschäft stattdessen auf die stetige Verbesserung deiner Dienste und Funktionen.</p><p>Wenn dein Geschäftsmodell auf die Erreichung eines Datenmonopols und Lock-In-Effekte abzielt, ist eine Plattform der bessere Ansatz.</p><h3>Hohe Datensouveränität gewährleisten</h3><p>Wenn im Markt ein hohes Bedürfnis an der Hoheit über die eigenen Daten besteht, ist es schwierig eine Plattform mit zentraler Datenhaltung zu etablieren. Ein Web-Ökosystem kann dem Bedürfnis gerecht werden und dabei auch mit einer heterogenen Datenlandschaft umgehen.</p><p>Wenn die Vorteile der zentralen Zusammenführung und Homogenisierung von Daten überwiegen und die Partner vielleicht sogar froh sind, wenn es dafür eine einheitliche Plattform gibt, dann ist jene die bessere Wahl.</p><h3>Verantwortung für Datensicherheit verteilen</h3><p>Eine zentrale Plattform, die Opfer von Cyberkriminalität wird, kann alle Teilnehmenden wirtschaftlich schwer treffen. Das Riskio lässt sich in einem Ökosystem besser verteilen.</p><p>Eine Plattform kann andererseits essenzielle Sicherheitstandards durchsetzen, wo einzelne Teilnehmer im Ökosystem eventuell versagen.</p><h3>Innovationen ohne zentralen Gatekeeper</h3><p>Wenn Innovationen von verschiedenen Akteuren in den Markt getragen werden sollen, um das Gesamtsystem attraktiver zu machen, bietet ein Web-Ökosystem die dazu nötigen Freiheitsgrade. Es ermöglicht ein schnelles Wachstum, auch unter konkurrierenden Anforderungen.</p><p>Eine Plattform ist der richtige Weg, wenn ein hoher Grad von Einheitlichkeit erreicht werden soll und eine zentrale Instanz dazu Vorgaben macht.</p><h3>Fazit</h3><p>Die folgende Tabelle fast noch einmal die wichtigsten Entscheidungskriterien zusammen:</p><table><thead><tr><th>Ziel</th><th>Web-Ökosystem</th><th>Zentrale Plattform</th></tr></thead><tbody><tr><td>Partnerschaftliche Zusammenarbeit auf Augenhöhe, zwischen potentiellen Konkurrenten</td><td>X</td><td></td></tr><tr><td>Betrieb einer Plattform ist neutral möglich, keine Konkurrenz zu Partnern</td><td></td><td>X</td></tr><tr><td>Die Abhängigkeiten von bestehenden Plattformen sollen reduziert werden.</td><td>X</td><td></td></tr><tr><td>Es gibt noch keine Plattform und es wird keine ernstzunehmende Konkurrenz erwartet.</td><td></td><td>X</td></tr><tr><td>Geschäftsmodelle sollen auf innovative Funktionen fokussieren.</td><td>X</td><td></td></tr><tr><td>Daten- und Infrastruktur-basiertes Geschäftsmodell erwünscht</td><td></td><td>X</td></tr><tr><td>Hohes Bedürfnis an Datensouveränität und Verbindung von heterogenen Daten</td><td>X</td><td></td></tr><tr><td>Hohes Bedürfnis an zentrale, homogene Datenhaltung</td><td></td><td>X</td></tr><tr><td>Die Verantwortung für Datensicherheit soll verteilt werden.</td><td>X</td><td></td></tr><tr><td>Verantwortung für Datensicherheit an zentraler Stelle erwünscht</td><td></td><td>X</td></tr><tr><td>Innovationen sollen ohne zentralen Gatekeeper entstehen.</td><td>X</td><td></td></tr><tr><td>Hoher Grad an Einheitlichkeit erwünscht</td><td></td><td>X</td></tr></tbody></table><p>Plattform oder Ökosystem: Wo siehst du die Rolle deines Unternehmens? Wirst du die nächste große Plattform? Beschränkt eine Plattform deine Innovationsmöglichkeiten? Hast du eine tolle Anwendungsidee, aber keine Daten? Willst du deine Daten effektiver nutzen, ohne dich von einer Plattform abhängig zu machen? <strong>Schreib uns – wir entwickeln ein Konzept mit dir!</strong></p>

It Takes All The Winners – Dezentrale Plattformökonomie im Web (Teil 3)

<h2>Teil 2 – Permissionless Innovation: Web-basierte Ökosysteme</h2><p><em>Digitale Plattformen sind ein erfolgreiches Geschäftsmodell in vielen Bereichen geworden. Sie bringen Marktakteure an einem zentralen Ort zusammen und schaffen einen lukrativen Handelsplatz. Eine Plattform in neuen Bereichen zu etablieren, ist daher das Ziel vieler Digitalisierungsprojekte. Das „Winner takes all“-Prinzip der Plattformwelt ist jedoch sehr risikobehaftet. Diese Artikelreihe zeigt eine alternative Option auf.</em></p><ul><li><ul><li><a href="/wissens-hub/blog/dezentrale-plattform-oekonomie-im-web-teil-1">Teil 1 – Winner takes all: Die Grenzen zentraler Plattformen</a> </li><li><strong>Teil 2 – Permissionless Innovation: Web-basierte Ökosysteme</strong></li><li><a href="/wissens-hub/blog/dezentrale-plattform-oekonomie-im-web-teil-3">Teil 3 – Die Gretchenfrage: Plattform oder Ökosystem?</a> </li></ul></li></ul><p>Im ersten Teil haben wir zentrale Plattformen näher beleuchtet und auch deren Risiken und Nachteile aufgezeigt. Der Plattform-Ansatz wird oft gewählt, weil er alternativlos erscheint, nicht weil er zwangsläufig die beste Wahl wäre. Ein digitaler Marktplatz mit interoperablen Daten und Geschäftsprozessen kann jedoch auch ohne zentrale Plattformen erreicht werden.</p><p>Das World Wide Web setzt seit Anbeginn auf die globale Verteilung und Verlinkung von Informationen und funktioniert ohne zentralen Gatekeeper.</p><p>Jeder kann zum Beispiel einen Webshop eröffnen und diesen unter einer eigenen Domain online verfügbar machen. Ein kleiner, eigenständiger Webshop ist aber im Vergleich zu Händler*innen, die auf einer Plattform wie Amazon auftreten schwieriger auffindbar und stellt Kund*innen vor zusätzliche Hürden, wie zum Beispiel die Eingabe von Address- und Zahlungsdaten.</p><p>Es ist aber möglich die Vorteile von zentralen Plattformen in einem offenen Web-Ökosystem umzusetzen. Dabei geht es keineswegs um die altruistische Öffnung gegenüber anderen Marktteilnehmern, sondern um die Minimierung der Plattform-Risiken und das Erschließen neuer Geschäftsmodelle für das eigene Unternehmen.</p><p>Die Daten verbleiben im Ökosystem-Ansatz bei ihren Besitzern, werden jedoch im Web für ausgewählte Anwendungen verfügbar gemacht. Die Anwendungen können Daten aus verschiedenen Quellen aggregieren und eine einheitliche Benutzungserfahrung gegenüber den Endkund*innen gewährleisten. Man denke dabei zum Beispiel an Google Shopping, welches nützliche Such- und Filterfunktionen über zahlreiche verschiedene Webshops hinweg bereitstellt.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/v7EkEOOcQMLyDf522MM9"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/v7EkEOOcQMLyDf522MM9" alt="Web-Ökosystem als offene Plattform" width="878" height="335" /></a> <p>Web: Verteilte Datenhoheit und unabhängige Innovation</p></div><h3>Rollen im Web-Ökosystem</h3><p>In einem solchen Ökosystem ergeben sich neue Rollen:</p><ol><li>Data Owner</li><li>Hostinganbieter</li><li>Service Provider</li><li>Kund*innen</li></ol><p>Die <strong>Data Owner</strong> besitzen interessante Daten, die aufgefunden und genutzt werden sollen. Diese entsprechen den Partnern aus dem Plattform-Ansatz.</p><p>Sie können ihre Daten selbst im Web bereitstellen oder auf einen darauf spezialisierten IT-Dienstleister zurückgreifen (<strong>Hostinganbieter</strong>). Essenziell ist, dass das Data Hosting ähnlich funktioniert wie klassisches Webhosting. Data Owner können mit ihren Daten jederzeit zu einem anderen Host wechseln.</p><p><strong>Service Provider</strong> sind Unternehmen, welche Dienstleistungen auf Basis der Daten anbieten und Geschäftsprozesse abwickeln. Sie stellen nützliche Anwendungen bereit, ohne dabei ein Monopol auf die Daten- und Userbasis zu besitzen.</p><p>Die <strong>Kund*innen</strong> sind die gleichen wie beim Plattform-Ansatz. Im Web können sie jedoch die Anwendungen, mit denen sie auf die Daten zugreifen frei wählen und sind nicht auf die Angebote einer Plattform beschränkt. Ihren User-Account können sie bei einem Anbieter hosten lassen und im gesamten Ökosystem als Single-Sign-on benutzen.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wKs4Cs8OQk2atbqDNqhi"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wKs4Cs8OQk2atbqDNqhi" alt="Rollen im Web-Ökosystem" width="675" height="330" /></a> <p>Data Owner stellen selbst oder über einen Hoster Daten bereit. Service Provider bieten nützliche Anwendungen.</p></div><table><thead><tr><th>Hostinganbieter</th><th>Service Provider</th><th>Data Owner</th><th>Kund*innen</th></tr></thead><tbody><tr><td>Web-Hoster, IT-Anbieter</td><td>Buchungsprozess as a Service</td><td>Hotels</td><td>Reisende</td></tr><tr><td>Web-Hoster, IT-Anbieter</td><td>Produktsuche, Bewertungsportale, Kaufprozess</td><td>Händler*innen</td><td>Käufer*innen</td></tr><tr><td>Web-Hoster, IT-Anbieter</td><td>Zielgruppenanalyse</td><td>Personen, Organisationen</td><td>Werbetreibende</td></tr></tbody></table><p><em>Beispiele von Rollen im Web-Ökosystem</em></p><p>Einen Plattform-Betreiber gibt es naturgemäß nicht. Unternehmen die das Geschäftsmodell Plattform erwägen, könnten sich stattdessen in der Rolle eines Hostinganbieters oder Service Providers wiederfinden. Welche Rolle die passendere ist, hängt davon ab, welche Probleme der Plattformwelt vermieden bzw. beseitigt werden sollen. Auch Kombinationen sind möglich.</p><h3>Trennung von Daten und Anwendungen</h3><p>Der wesentliche Unterschied zum Plattform-Modell ist die Trennung zwischen Daten- und Service-Providern und die dadurch entstehende Nicht-Exklusivität dieser Dienstleister. Sowohl auf Daten-, als auch Anwendungsseite entstehen neue Märkte und ein Wettbewerb auf Basis besserer Funktionen und Service-Garantien.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/fdgGDQU3Q6W0jVB5ty4e"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/fdgGDQU3Q6W0jVB5ty4e" alt="Wettbewerb im Web-Ökosystem" width="541" height="400" /></a> <p>Die Trennung von Daten und Diensten ermöglicht einen Wettbewerb auf Basis besserer Funktionen und höherer Service-Qualität.</p></div><h3>Interoperabilität durch gemeinsame Semantik</h3><p>Die Herausforderung ist es, trotz dieser Zersplitterung eine plattformähnliche Integration von Daten und Prozessen zu erreichen. Die Interoperabilität, welche die Plattform durch ihre zentrale Rolle erzwingen kann, muss im Web anders erreicht werden.</p><p>Dazu stellen alle interessierten Parteien ihre Daten und Angebote in strukturierten Formaten auf Basis einer einheitlichen Semantik ins Web. Dies kann in eigenen Rechenzentren, bei Cloud Providern oder Data-Hosting-Anbietern geschehen.</p><p>Das Web ist in der Lage, Informationen global eindeutig über <a href="https://de.wikipedia.org/wiki/Uniform_Resource_Locator">Uniform Resource Locators (URL)</a>  zu identifizieren und zu lokalisieren. Dadurch ist eine weltweite Verlinkung von Daten möglich. Das offene Web kann als einheitliche Plattform für die Vernetzung von Marktteilnehmern dienen. Die Interoperabilität, welche bei Plattformen durch Zentralisierung erreicht wird, kann im Web durch eine gemeinsame Semantik umgesetzt werden.</p><p>Dies ermöglicht es den Data Ownern, ihre Daten flexibel zu verknüpfen und mit einer fachlichen Bedeutung zu versehen. Service Provider sind in der Lage nützliche Anwendungen auf Basis dieser Daten zu entwickeln und zu vermarkten.</p><p>Im Web werden Daten um explizite, einheitliche Konzepte angereichert, um ein gemeinsames Verständnis zu schaffen. Data Owner können ihre Daten denen von Partnerunternehmen und Kund*innen zu einem Knowledge Graph verlinken. Durch die strukturierte Beschreibung von Systemzuständen und -fähigkeiten wird eine plattformunabhängige Zusammenarbeit auf Augenhöhe möglich. Da Interoperabilität auf einem semantischen Level hergestellt wird, verliert die Strukturierung und Organisation von Daten auf der Syntaxebene an Bedeutung. Hierzu können flexible W3C Metaformate wie das <a href="https://de.wikipedia.org/wiki/Resource_Description_Framework">Resource Description Framework (RDF)</a>  und weitere offene Webstandards und -technologien verwendet werden.</p><p>Die einheitliche Handhabung und Verlinkung von Konzepten im Web erlaubt eine breit angelegte Digitalisierung und Automatisierung aller Bereiche, einschließlich physischer Dinge und Vorgänge. Diese stehen zusammen mit klassischen Dokumenten als einheitliche Konzepte im Web.</p><p>Jeder Data Owner kann dabei die volle Kontrolle über die eigenen Daten behalten, oder sich einem Data Host anvertrauen und diesen bei Bedarf auch wechseln. Die Data Owner legen über feingranulare Zugriffsrechte (Web Access Control) fest, welche Kund*innen und Services die Daten auf welche Weise verwenden dürfen.</p><h3>Innovationsfreiheit</h3><p>Offene, erweiterbare Standards geben sowohl den Hostinganbietern als auch den Service-Providern eine stabile Basis für innovative Geschäftsmodelle und neue Formen von Anwendungen.</p><p>Sich einem Standard anschließen und gleichzeitig innovativ sein erscheint zunächst widersprüchlich. Ein Ansatz auf Grundlage bewährter W3C Web Standards erlaubt es jedoch, an einem globalen Informationsnetzwerk teilzuhaben und gleichzeitig eigene Innovationen voranzutreiben. In etablierten Bereichen wird dazu auf bewährte Modelle zurückgegriffen. Neue Geschäftsmodelle können „on top“ darauf eingeführt werden. Dadurch wird Innovation sogar beschleunigt, da sich Projekte auf die wirklich neuen Aspekte einer Idee konzentrieren können.</p><p>Der Webansatz und die damit verbundene semantische Wissensrepräsentation können zudem eine hervorragende Ergänzung zu maschinellem Lernen darstellen und Erkenntnisse jenseits von reinen Wahrscheinlichkeitsverteilungen ermöglichen.</p><h3>Eigenschaften: Web-Ökosystem im Vergleich</h3><p>Die folgende Tabelle fasst die wesentlichen Eigenschaften eines Web-basierten Ökosystems zusammen. Die Eigenschaften der Plattform aus Teil 1 sind dem gegenübergestellt:</p><table><thead><tr><th>Eigenschaft</th><th>Web-Ökosystem</th><th>Zentrale Plattform</th></tr></thead><tbody><tr><td><em>Interoperabilität</em></td><td><strong>durch gemeinsame Semantik</strong></td><td>durch zentrale Vorgaben</td></tr><tr><td><em>Datenhoheit</em></td><td><strong>Data Owner behält Datenhoheit</strong></td><td>liegt beim Plattformbetreiber</td></tr><tr><td><em>Datensicherheit</em></td><td><strong>Verantwortung bei Hostinganbietern. Kein zentraler Angriffspunkt.</strong></td><td>Volle Verantwortung beim Betreiber. Single Point of Failure.</td></tr><tr><td><em>Innovation</em></td><td><strong>Unabhängig, durch alle Akteure</strong></td><td>Betreiber gibt den Rahmen vor und ist Bottleneck</td></tr><tr><td><em>Offenheit</em></td><td><strong>kein zentraler Gatekeeper</strong></td><td>Betreiber bestimmt, wer teilnehmen kann</td></tr><tr><td><em>Geschäftsrisiko</em></td><td><strong>Besetzung von Marktnischen möglich</strong></td><td>Winner takes all, kein „Platz 2“</td></tr><tr><td><em>Geschäftsmodelle</em></td><td><strong>Daten, innovative Anwendungen oder Infrastruktur</strong></td><td>Fokussiert auf Daten & Infrastruktur</td></tr></tbody></table><h3>Fazit & Ausblick</h3><p>Zentrale Plattformen drängen ihre Betreiber in ein datenzentriertes Geschäftsmodell und bergen ein hohes Risiko des Scheiterns. Ein Web-basiertes Ökosystem öffnet dementgegen ein weites Feld aus Geschäftsmodellen und zu besetzenden Nischen. Im dritten und letzten Teil betrachten wir, wann sich eine Plattform lohnt und in welchen Fällen ein Web-Ökosystem die bessere Alternative für Ihr Digitalisierungsprojekt ist.</p><p>Weiter zu <a href="/wissens-hub/blog/dezentrale-plattform-oekonomie-im-web-teil-3">Teil 3 – Die Gretchenfrage: Plattform oder Ökosystem?</a> </p>

It Takes All The Winners – Dezentrale Plattformökonomie im Web (Teil 2)

<h2>Teil 1 – Winner takes all: Die Grenzen zentraler Plattformen</h2><p><em>Digitale Plattformen sind ein erfolgreiches Geschäftsmodell in vielen Bereichen geworden. Sie bringen Marktakteure an einem zentralen Ort zusammen und schaffen einen lukrativen Handelsplatz. Eine Plattform in neuen Bereichen zu etablieren, ist daher das Ziel vieler Digitalisierungsprojekte. Das „Winner takes all“-Prinzip der Plattformwelt ist jedoch sehr risikobehaftet. Diese Artikelreihe zeigt eine alternative Option auf.</em></p><ul><li><strong>Teil 1 – Winner takes all: Die Grenzen zentraler Plattformen</strong></li><li><a href="/wissens-hub/blog/dezentrale-plattform-oekonomie-im-web-teil-2">Teil 2 – Permissionless Innovation: Web-basierte Ökosysteme</a> </li><li><a href="/wissens-hub/blog/dezentrale-plattform-oekonomie-im-web-teil-3">Teil 3 – Die Gretchenfrage: Plattform oder Ökosystem?</a> </li></ul><p>Eine zentrale Plattform kann die Digitalisierung von Märkten vorantreiben und hat großes Disruptionspotenzial. Die Zentralisierung birgt für alle Beteiligten aber auch Risiken und Nachteile. Sie werden oft spät erkannt und betreffen sowohl den Betreiber als auch andere Akteure. Im vorliegenden Artikel-Teil befasse ich mich mit diesen Eigenheiten von Plattformen.</p><p>Ein Ökosystem, welches auf den Prinzipien des offenen Webs basiert, kann eine interessante Alternative sein. In einem solchen Ökosystem stehen Unternehmen im Wettbewerb um die besseren Dienste und Anwendungen, statt um die Hoheit über ein Datenmonopol. Netzwerkeffekte werden genutzt, ohne dass ein zentraler Gatekeeper Innovationen beschränken kann.</p><p>Ein web-basierter Ansatz ist überall dort interessant, wo Informationen und Dinge digitalisiert und vernetzt werden sollen. In aufstrebenden Bereichen wie zum Beispiel der Industrie 4.0 kann er die Digitalisierung in Schwung bringen. In etablierten Plattformökonomien hilft er bestehende Strukturen aufzubrechen und neuen Boden für Innovationen zu gewinnen. Zahlreiche Branchen können davon profitieren:</p><ul><li>Industrie & Produktion</li><li>Energiesektor</li><li>Transport & Logistik</li><li>Tourismus</li><li>Gesundheitswesen</li><li>Smart Home</li><li>Smart City</li><li>Connected Cars</li><li>Bauwesen</li><li>…</li></ul><p>Ich werde diesen Ansatz in Teil 2 der Artikelreihe näher beschreiben. Teil 3 zieht ein Fazit und soll als Entscheidungshilfe dienen, wann eine zentrale Plattform und wann ein Web-Ökosystem für dein Digitalisierungsprojekt die bessere Wahl ist.</p><h3>Plattform: Interoperabilität durch Zentralisierung</h3><p>Das Problem der Digitalisierung und Vernetzung von heterogenen Daten lösen Plattformen durch Homogenisierung und Zentralisierung: alle Daten fließen zentral in die Plattform ein. Diese kann somit die Formate und Schnittstellen vorgeben und vereinheitlichen. Alle Informationen werden unter der Hoheit des Betreibers vorgehalten und können durch diesen für bestimmte Use-Cases aufbereitet und zugeschnitten werden. Dadurch kann der Betreiber sehr effizient innovative Dienste entwickeln und sie allen Beteiligten zugänglich machen. Durch Zentralisierung lösen Plattformen das Problem der Interoperabilität von Daten und Prozessen.</p><h3>Geschäftsmodell Datenmonopol</h3><p>Diese Zentralisierung führt zwangsläufig zu einem datenorientierten Geschäftsmodell. Plattformen müssen versuchen, ein Datenmonopol zu erreichen und dieses monetarisieren. Auf einer Plattform gibt es mindestens drei beteiligte Parteien:</p><ol><li>Plattform-Betreiber</li><li>Plattform-Partner</li><li>Endkund*innen</li></ol><p>Der Erfolg einer Plattform hängt maßgeblich davon ab, möglichst viele Daten von Partnern zu erhalten und so attraktiv für die Kund*innen zu werden und zu bleiben.</p><table><thead><tr><th>Betreiber</th><th>Partner</th><th>Kund*innen</th></tr></thead><tbody><tr><td>Amazon</td><td>Händler*innen</td><td>Käufer*innen</td></tr><tr><td>Booking.com</td><td>Hotels</td><td>Reisende</td></tr><tr><td>Facebook</td><td>Leute & Organisationen</td><td>Werbetreibende</td></tr><tr><td>Netflix</td><td>Filmstudios</td><td>Zuschauer*innen</td></tr></tbody></table><p><em>Einige bekannte Plattformen und deren Partner und Kund*innen</em></p><p>Eine Plattform vereint Daten und Anwendungen unter einem Dach. Die Partner stellen der Plattform Daten bereit. Die Plattform beherbergt diese Daten und stellt den Kund*innen nützliche Anwendungen auf Basis der Daten bereit.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mbsVO92ISCOtIp0zhfqU"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mbsVO92ISCOtIp0zhfqU" alt="Prinzip der zentralen Plattform" width="631" height="231" /></a> <p>Die Plattform gibt Kund*innen über festgelegte Anwendungen Zugriff auf Daten der Partner.</p></div><p>Die Plattform wird dabei entweder von Kund*innen für den Zugang zu Daten bezahlt (Ziel: „etwas finden“) oder von Partnern für die Bereitstellung von deren Daten (Ziel: „gefunden werden“). Welches Modell funktioniert, hängt davon ab, wessen Interessen stärker wiegen. Hotels zahlen zum Beispiel eine Kommission an Booking.com, wenn sie über diese gefunden und gebucht werden. Werbetreibende hingegen bezahlen Facebook, um passende Zielgruppen zu erreichen. In beiden Fällen ist der Unique Selling Point jedoch, dass die Plattform über eine umfangreiche, interessante Datenbasis und zahlreiche Benutzer*innen verfügt.</p><table><thead><tr><th>Betreiber</th><th>Daten</th><th>Anwendungen</th></tr></thead><tbody><tr><td>Amazon</td><td>Produkte, Bilder, Preise</td><td>Produktsuche, Warenkorb, Check-out</td></tr><tr><td>Booking.com</td><td>Unterkünfte, Preise, Verfügbarkeiten</td><td>Preisvergleiche, Buchungen</td></tr><tr><td>Facebook</td><td>Interessen, Social Graphs</td><td>Zielgruppen-Targeting</td></tr><tr><td>Netflix</td><td>Filme & Serien</td><td>Video-Streaming, Vorschläge</td></tr></tbody></table><p><em>Beispiele von Daten und Anwendungen gängiger Plattformen</em></p><h3>Vorteile der Plattform</h3><p>Die Plattform löst entscheidende Probleme für die Kund*innen, indem sie wesentliche Informationen zentral zusammenbringt und einheitlich auffindbar macht. Statt verstreut im Web nach Informationen suchen zu müssen, gibt es einen zentralen Anlaufpunkt für ein jeweiliges Anliegen. Bei Amazon können Verbraucher*innen fast alles kaufen und bei Booking.com finden Reisende eine riesige Auswahl an Hotels und Unterkünften.</p><p>Auch Plattform-Partner profitieren, da wesentliche Cross-Cutting-Concerns einheitlich über die Plattform geregelt werden. Die Partner können sich auf ihr Kerngeschäft fokussieren, die Plattform kümmert sich um die digitale Abwicklung. Gleichzeitig wird über die Plattform eine breite Kundschaft erreicht.</p><p>Dabei wird oft verkannt, dass der Plattformansatz auch Nachteile mit sich bringt, sowohl für die Betreiber als auch für die Partnerunternehmen und Benutzer*innen.</p><h3>Nachteile der Plattform</h3><p>Die Partner geben die Hoheit über ihre Daten an den Betreiber ab und verlieren damit die Kontrolle über die Verwendungsmöglichkeiten. Welche Anwendungen und Use-Cases bereitgestellt werden liegt in den Händen des Betreibers. Ebenso bestimmt der Betreiber den Umfang und die Form der zu liefernden Daten.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wXjEC5wQvikbXwUdcq5O"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wXjEC5wQvikbXwUdcq5O" alt="Risiken der zentralen Plattform" width="791" height="490" /></a> <p>Die Plattform setzt zentrale Standards und bringt somit Partner und Kund*innen zusammen. Dadurch entstehen aber Risiken.</p></div><p>Die Plattform ist im Wesentlichen ein Datenmarktplatz. Die Qualität der zur Verfügung gestellten Anwendungen ist nachgelagert, da selbst die beste Anwendung ohne verfügbare Daten keinen Mehrwert bietet.</p><p>Während anfangs neue, überzeugende Funktionen einer Plattform beim Wachstum helfen, überwiegen ab einer bestimmten Marktmacht die Netzwerkeffekte. Die Plattform wird allein durch ihre Größe attraktiv. Partner können nicht weg, weil all ihre Kund*innen dort sind. Diese wiederum können nicht weg, weil sie nur dort alles nötige vorfinden. Ab diesem Punkt kann eine Plattform sehr unbequem für die Beteiligten werden. Der Druck, benötigte Features umzusetzen sinkt. Gleichzeitig können Plattformen die Kosten für den Zugang zu Daten in die Höhe treiben und strenge Regeln für die Teilnahme auferlegen.</p><p>Jede Plattform, die ein Partner mit Daten bedient, erzeugt bei diesem zusätzlichen Aufwand. Daher werden Plattformen mit viel Marktmacht bevorzugt. Eine positive Rückkopplung tritt ein, die den Netzwerkeffekt verstärkt. Große Plattformen wachsen, schwache werden nach und nach bedeutungslos.</p><p>Daher ist der Plattform-Ansatz auch für Betreiber risikobehaftet. Das datenbasierte Geschäftsmodell funktioniert nur, wenn ein Betreiber möglichst viele Daten anhäuft und konkurrierende Plattformen obsolet macht. <a href="https://d1g1tal.de/wenige-iot-plattformen-dominieren-den-markt/">Der Plattform-Markt konsolidiert</a> , bis schlussendlich ein letzter, großer Betreiber relevant bleibt.</p><p>Unternehmen, die sich auf den Plattform-Markt begeben, setzen sich somit dem vollen Risiko aus: Alles oder Nichts. Entweder ich werde <em>die Plattform</em> in einem Bereich und gewinne den Markt vollständig oder ich scheitere und verliere nach und nach alle Partner und Benutzer*innen an die Gewinner-Plattform.</p><p>Ein nachträglicher Einstieg in den Plattform-Markt ist nahezu unmöglich. Ohne Daten und Benutzer*innen haben selbst Anbieter mit innovativen und sehr nützlichen Anwendungen kaum Changen sich zu etablieren.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UcLmqhccR3K48CbfVzJJ"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UcLmqhccR3K48CbfVzJJ" alt="Wettbewerb auf dem Plattform-Markt" width="640" height="346" /></a> <p>Ohne Daten und Benutzer*innen haben auch innovative Unternehmen kaum Marktchancen.</p></div><p>Für Plattform-Betreiber ist es somit überlebenswichtig, zügig möglichst viele Partner zu gewinnen und so die Daten- und Nutzerbasis kontinuierlich auszubauen und langfristig zu halten.</p><h3>Data as a Liability</h3><p>Dieser Kampf um das Datenmonopol kann die Plattform-Betreiber einengen. Mit der Anhäufung von Daten und der Nutzung von Netzwerkeffekten hat sich möglicherweise unfreiwillig das Geschäftsmodell verschoben. Statt sich mit innovativen Anwendungen zu befassen, rücken Themen wie Datenschutz (Stichwort DSGVO), IT Security, Datenqualität, Betrugsprävention, Stabilität und Skalierung in den Vordergrund des Plattformgeschäfts.</p><p>Auf den Big-Data-Hype folgte mancherorts Ernüchterung über die <a href="https://www.itproportal.com/features/is-data-liability/">damit verbundene Verantwortung und den Aufwand</a>  diese Daten tatsächlich sinnvoll zu nutzen. Auch wenn dahinter valide Geschäftsmodelle stehen können, sind es nicht zwangsläufig die Geschäftsmodelle die ein Unternehmen tatsächlich umsetzten möchte. Die Etablierung einer Plattform kann ein Unternehmen jedoch in diese Geschäftsmodelle hineinzwingen.</p><h3>Übersicht Plattformeigenschaften</h3><p>Die folgende Tabelle fasst die wesentlichen Eigenschaften von zentralen Plattformen zusammen:</p><table><thead><tr><th>Eigenschaft</th><th>Zentrale Plattform</th></tr></thead><tbody><tr><td><em>Interoperabilität</em></td><td>durch zentrale Vorgaben</td></tr><tr><td><em>Datenhoheit</em></td><td>liegt beim Plattformbetreiber</td></tr><tr><td><em>Datensicherheit</em></td><td>Volle Verantwortung beim Betreiber. Single Point of Failure.</td></tr><tr><td><em>Innovation</em></td><td>Betreiber gibt den Rahmen vor und ist Bottleneck</td></tr><tr><td><em>Offenheit</em></td><td>Betreiber bestimmt, wer teilnehmen kann</td></tr><tr><td><em>Geschäftsrisiko</em></td><td>Winner takes all, kein „Platz 2“</td></tr><tr><td><em>Geschäftsmodelle</em></td><td>Fokussiert auf Daten & Infrastruktur</td></tr></tbody></table><h3>Fazit & Ausblick</h3><p>Zentrale Plattformen sind ein lukratives Geschäftsmodell – wenn man den Markt gewinnt und sich auf ein Geschäft mit Daten und Plattform-Betrieb einlassen kann und will. In Teil 2 werde ich zeigen, wie Web-basierte Ökosysteme dem gegenüber stehen und welche alternativen Geschäftsmodelle dies mit sich bringt.</p><p>Weiter zu <a href="/wissens-hub/blog/dezentrale-plattform-oekonomie-im-web-teil-2">Teil 2 – Permissionless Innovation: Web-basierte Ökosysteme</a> </p>

It Takes All The Winners – Dezentrale Plattformökonomie im Web (Teil 1)

<p>Langwierige Architekturplanung am Whiteboard ist üblicherweise nicht das, was wir agilen Teams empfehlen. Bei jahrelang gewachsenen Legacy-Systemen kann es jedoch sinnvoll sein, eine High-Level-Zielarchitektur als gemeinsames Zielbild des zukünftigen Systems zu entwerfen. Genau das haben wir bei einem unserer Kunden getan und möchten in diesem Artikel unseren Ansatz beschreiben.</p><p>Im vorliegenden Fall gab es in den einzelnen Teams selten bis nie Architekturüberlegungen. Die organisatorischen Teamschnitte waren technisch begründet und verliefen z. B. zwischen Frontend und Backend. Die tatsächliche Systemarchitektur folgte <a href="https://en.wikipedia.org/wiki/Conway's_law">Conway’s Law</a>  und richtete sich dementsprechend nicht an den wirklichen Anforderungen aus.</p><p>Unser Ansatz dient dazu, in einem solchen Umfeld ein erstes gemeinsames Zielbild einer Architektur auf hoher Flughöhe zu schaffen.</p><p>Der Weg zu dieser High-Level-Zielarchitektur erfolgte in 5 Schritten:</p><ol><li>Systemkontext verstehen</li><li>Anforderungen sammeln</li><li>ISO-Qualitätsanforderungen priorisieren</li><li>Themengruppen bilden</li><li>Teilsysteme skizzieren</li></ol><p>Eine detaillierte Analyse der bestehenden Architektur des Legacy-Systems (Ist-Architektur) haben wir bewusst auf später verschoben. Unserer Erfahrung nach kann man die Anforderungen eines Systems objektiver bewerten, wenn man den aktuellen Stand zunächst außen vor lässt. Ansonsten wird man zu früh von historischen Kompromissen und Zugeständnissen beeinflusst, wodurch man von einer idealen Soll-Architektur abgelenkt wird. Das heißt nicht, dass man auf eine solche Analyse verzichten sollte! Allerdings kommt sie in einem späteren Schritt und dient dann dazu, die Zielarchitektur nachzujustieren und einen Transitionsplan vorzubereiten.</p><p>Um unsere Planung strukturiert anzugehen, haben wir bestehende Standards herangezogen:</p><ul><li><strong><a href="https://c4model.com/">C4 Modell</a> </strong> – dieses Modell bietet einen einheitlichen aber pragmatischen Satz von Abstraktionen, um Software-Architektur grafisch zu beschreiben. Es fokussiert sich nicht auf die genaue Darstellung der Diagramme, sondern definiert 4 Detailgrade. <strong>Level 1 (<em>Systemkontext</em>)</strong> und <strong>Level 2 (<em>Container</em>)</strong> waren ausreichend für unsere High-Level-Zielarchitektur, <strong>Level 3 (<em>Komponenten</em>)</strong> und <strong>Level 4 (<em>Code</em>)</strong> bieten sich für eine spätere, detailliertere Planung der Mikroarchitektur an.</li><li><strong><a href="https://iso25000.com/index.php/en/iso-25000-standards/iso-25010">ISO 25010</a> </strong> – der ISO-Standard definiert universelle Qualitätsanforderungen, wonach man die Qualitätsaspekte eines bestehenden oder zukünftigen Systems bewerten kann</li></ul><h2>Systemkontext verstehen</h2><p>Im ersten Schritt ging es uns darum, den Kontext des Systems zu verstehen. Welche Rollen haben Benutzer*innen des Systems? Welche anderen Anwendungen greifen auf das System zu? Das Verständnis des Systemumfelds hilft dabei, Anforderungen zu identifizieren, die bestimmte Rollen und Drittsysteme an das System haben.</p><p>Wir haben den Systemkontext nach Level 1 des C4-Modells visualisiert. Dazu haben wir einen Workshop mit verschiedenen Stakeholdern durchgeführt, die sowohl die Business-Sicht als auch die Blickwinkel von Kund*innen und Benutzer*innen vertreten konnten. Im Idealfall sind alle Stakeholder unmittelbar involviert.</p><p>Das Ergebnis einer solchen Visualisierung für ein fiktives Beispiel sieht so aus:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/iFpAcvZlRAO2qy9FNB0P"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/iFpAcvZlRAO2qy9FNB0P" alt="Zielarchitektur Level 1 - Kontext" width="700" height="346" /></a> </p><p>In der Mitte befindet sich das System als Blackbox, außen werden verschiedene Rollen und deren Use-Cases aufgetragen, ebenso wie Verbindungen zu und Interessen von Drittsystemen.</p><h2>Anforderungen sammeln</h2><p>Mit Hilfe des Systemkontexts haben wir begonnen, nähere Anforderungen an das System zu sammeln. Die involvierten Rollen und Drittsysteme werden dazu genauer betrachtet: Was erwarten sie vom System? Welche Annahmen stehen hinter den einzelnen Use-Cases?</p><p>Wir haben hier die Beobachtung gemacht, dass Anforderungen vorschnell aus der eigenen Sicht formuliert werden, und die tatsächlichen Use-Cases in den Hintergrund geraten. Dies ist insbesondere gefährlich wenn nicht alle Stakeholder persönlich vertreten sind. Der Systemkontext hilft dabei, die Fragestellungen auf die richtigen Akteur*innen zu lenken.</p><p>Die gesammelten Anforderungen müssen in dieser Hinsicht gefiltert und eingeordnet werden. Wenn rein technische Wünsche geäußert werden, gilt es genau zu hinterfragen, welches Problem damit eigentlich für welche Rolle gelöst werden soll. Unsere Erfahrung hat gezeigt, dass die Teilnehmer häufig schon von technischen Lösungen überzeugt sind, die sie als Anforderungen verkleiden, aber die von den eigentlichen Anforderungen ablenken. Solche Lösungen sollen erst in einem späteren Schritt erarbeitet werden.</p><p><strong>Beispiele für „Anforderungen“, die weiter hinterfragt werden müssen:</strong></p><ul><li><em>„Wir brauchen Microservices“</em> -> Warum? Welches zugrundeliegende Problem soll gelöst werden?</li><li><em>„Die Software muss schnell sein“</em> -> <em>Wer</em> erwartet <em>wo</em> eine <em>wie schnelle</em> Reaktion?</li><li><em>„Wir brauchen eine moderne API“</em> -> Wer ist wir? Welche anderen Systeme müssen angebunden werden? Was erwarten diese?</li></ul><p><strong>Beispiele für Anforderungen die in diesem Schritt erarbeitet werden:</strong></p><ul><li>Kund*innen wollen zeitnah über Terminänderungen informiert werden.</li><li>Der Außendienst muss auch ohne Netzverbindung Arbeitsprotokolle anfertigen können.</li><li>Die IT erwartet, dass die Software einfach installiert werden kann.</li><li>Die Software muss Daten an externe ERP-Systeme senden.</li><li>…</li></ul><p>Bei der Ermittlung des Systemkontextes und der Anforderungen können bewährte Methoden wie <a href="/wissens-hub/blog/was-ist-user-story-mapping-eine-mate-mit-hias-wrba-einematemit">User Story Mapping</a>  oder <a href="/wissens-hub/blog/event-storming-gemeinsam-die-domaene-entdecken">Event Storming</a>  helfen. In unserem konkreten Fall hatten wir nicht die nötige Zeit, diese zur Anwendung zu bringen.</p><h2>ISO-Qualitätsanforderungen priorisieren</h2><p>Die gesammelten Anforderungen haben wir mit den Qualitätsanforderungen aus der ISO 25010 abgeglichen. Welche Qualitätsanforderungen stechen besonders hervor? Auf diese gilt es sich dann zu konzentrieren. Eine Softwarearchitektur kann unmöglich alle Anforderungen gleichzeitig bzw. gleich gut erfüllen. Eine gute Architektur geht daher die Trade-Offs an den richtigen Stellen ein, um das beste Ergebnis im jeweiligen Kontext zu erzielen.</p><p>Die bislang gesammelten Anforderungen konnten uns einen guten Überblick geben, welche der über 30 ISO-Anforderungen besondere Beachtung verdienen. Wir konnten uns auf 12 ISO-Anforderungen festlegen, die wir in einem weiteren Workshop näher betrachtet haben.</p><p>Jede dieser Qualitätsanforderungen haben wir im Workshop kurz vorgestellt. Dabei haben wir auch erläutert, zu welchen anderen ISO-Anforderungen sie ggf. in Konkurrenz stehen kann.</p><p>Für jede Qualitätsanforderung haben wir 3 Punkte behandelt:</p><ol><li>Wo ist sie wichtig?</li><li>Wo ist sie weniger wichtig?</li><li>Aussagen formulieren</li></ol><p>Wo ist die Anforderung wichtig? Bei welchen Use-Cases ist z. B. das Zeitverhalten relevant? Welche Daten müssen interoperabel sein? Welches UI muss besonders bedienfreundlich sein?</p><p>Wo ist eine Anforderung weniger wichtig? Klar, alles soll „schnell“ sein, aber vielleicht gibt es ja einen Bereich, wo es weniger darauf ankommt?</p><p>Im 3. Schritt haben wir zu jeder ISO-Anforderung konkrete Aussagen erarbeitet in der Form:</p>

```
Im <Bereich> soll <Anforderung> erreicht werden, auch wenn <Trade-Off>

```

<p>Durch die konkreten Aussagen sollen die abstrakten ISO-Anforderungen greifbarer gemacht und mögliche Trade-Offs aufgezeigt werden. Das heißt nicht, dass in der Zielarchitektur all diese Trade-Offs zwangsläufig eingegangen werden. Es zeigt jedoch, wo bei den Architekturüberlegungen ein Spielraum besteht und wo nicht.</p><p>Hier ist ein fiktives Beispiel für die ISO-Anforderung <strong>Zeitverhalten</strong>:</p><table><thead><tr><th>Zeitverhalten</th><th>Wichtig bei</th><th>Weniger wichtig bei</th></tr></thead><tbody><tr><td></td><td>Produktanzeige</td><td>Bestätigungsmail</td></tr><tr><td></td><td>Ergebnisberechnung</td><td>Archiv</td></tr><tr><td></td><td>…</td><td>…</td></tr><tr><td></td><td>…</td><td>…</td></tr></tbody></table><table><thead><tr><th>Aussagen</th></tr></thead><tbody><tr><td><em>Die Produktanzeige soll innerhalb 1 Sekunde laden, auch wenn dann ggf. nicht alle Daten aktuell sind.</em></td></tr><tr><td><em>Archivdaten unterliegen strengen Zugriffsregeln, sie müssen nicht in Echtzeit abgerufen werden können</em></td></tr><tr><td><em>Es müssen schnelle Ergebnisse geliefert werden, auch wenn diese dann nicht zu 100 % exakt sind</em></td></tr></tbody></table><h2>Themengruppen bilden</h2><p>Aus den Antworten auf die Fragen „Wo ist es [weniger] wichtig?“ und den konkret formulierten Aussagen zeichneten sich bestimmte wiederkehrenden Themengebiete ab, z. B.:</p><ul><li>Kundenportal</li><li>Verwaltung</li><li>Produktkatalog</li><li>Archiv</li><li>API Schnittstellen</li><li>…</li></ul><p>Wir haben nun alle Aussagen und zugehörigen ISO-Anforderungen nach diesen Themen gruppiert. Dabei wurde deutlich, dass bestimmte ISO-Anforderungen nur bei bestimmten Themen relevant sind, während andere übergreifend Beachtung finden. Bei manchen Gruppen wiederum stachen bestimmte ISO-Anforderungen als möglicher Trade-Off hervor.</p><p>In den einzelnen Themengruppen begannen wir dann Lösungsideen zu formulieren, die die entsprechenden Anforderungen und Trade-Offs berücksichtigten. Wichtig ist, dass man die Tendenz „One architectural pattern fits all“ vermeidet, und dass die verschiedenen Themengruppen unabhängig voneinander betrachtet werden.</p><h2>Teilsysteme bilden</h2><p>Aus den Themengruppen und unseren Lösungsideen formten sich dann recht offensichtlich einzelne Teilsysteme, die in der Zielarchitektur eine Rolle spielen könnten. Bei dem Schnitt dieser Teilsysteme achteten wir darauf, dass die Qualitätsanforderungen erfüllt werden und machten bewusst dort Trade-Offs, wo es notwendig und gleichzeitig aber auch erlaubt war, diese einzugehen.</p><p>Das Zielsystem skizzierten wir wieder im C4-Modell, auf Level 2. Hier zeigen wir einen Ausschnitt einer Skizze für ein fiktives Beispiel:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/27H8M6xYQ0mMksPeVDKO"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/27H8M6xYQ0mMksPeVDKO" alt="Zielarchitektur Level 2 - Container" width="700" height="374" /></a> </p><p>In dieser Skizze sieht man, wie die relevanten Anforderungen als Grundlage für technische Entscheidungen genutzt werden können. Die grünen Haftnotizen stellen dabei erfüllte Qualitätsanforderungen dar, während die orangenen für bewusste Trade-Offs stehen. In dem Beispiel ist es für Lieferant*innen besonders wichtig, dass der Lieferungscontainer permanent verfügbar ist und schnell auf Anfragen reagiert, so dass sie Aufträge ohne Wartezeiten weiter abarbeiten können, auch wenn andere Teile des Systems ausfallen.</p><p>Wir nehmen dabei in Kauf, dass der Container eine eigene Datenhaltung erhält, so dass seine Kopie der Aufträge nicht unbedingt den aktuellsten Zustand vorhält und Lieferdaten erst verzögert in der Verwaltung ankommen (<em>eventual consistency</em>). Gleichzeitig sorgt die Trennung der Daten für den gewünschten höheren Zugriffsschutz auf Verwaltungsseite.</p><p>Es wurde also versucht, die Kompromisse möglichst da anzusetzen, wo sie zu verschmerzen sind und so die gewünschten Qualitätsanforderungen an den wichtigen Stellen zu erreichen.</p><h2>Und nun?</h2><p>Warum haben wir das Ganze gemacht? Was folgt daraus? Ausgehend von der vorgefundenen Ist-Architektur, ist die erarbeitete Zielarchitektur zum einen utopisch und zum anderen entspricht sie sicherlich nicht zu 100 % dem, was tatsächlich gebraucht wird. Eine gute Architektur muss sich aus unserer Sicht langfristig und iterativ entwickeln. Ein gutes Verständnis der Fachdomäne ist ebenfalls wichtig, damit die sich daraus ergebenden Architekturanforderungen hinreichend beachtet werden. Die High-Level-Zielarchitektur kann nur als Beginn eines Prozesses gesehen werden.</p><p>Weiterhin sollte nun begonnen werden, sich näher mit der Ist-Architektur auseinander zu setzen und genau zu prüfen, welche dort getroffenen Entscheidungen auch zukünftig wichtig sind, im Idealbild jedoch übersehen wurden.</p><h2>Fazit</h2><p>Softwareentwicklung ist zu komplex, um vorab eine fertige Blaupause eines Systems liefern zu können. Es können nicht alle Anforderungen vorhergesehen werden und Bedürfnisse ändern sich im Laufe der Zeit. Unser Ziel war, ein lebendes Dokument gemeinsam mit einer Bandbreite von Stakeholdern beim Kunden zu entwickeln, welches als Ausrichtung für weitere Diskussionen dient und die agile Weiterentwicklung des Produkts unterstützt.</p><p>Das hier beschriebene Vorgehen bietet einen unmittelbaren Wert, wenn, wie in unserem Fall, kein einheitliches Architekturverständnis in der Organisation vorliegt und schnell eine brauchbare Diskussionsgrundlage geschaffen werden soll.</p><p>Die gemeinsamen Workshops und das entstandene Zielbild haben ein besseres gemeinsames Verständnis für Architektur geschaffen. Man hat nun eine fundierte Grundlage, auf deren Basis man diskutieren und die Architektur evolutionär fortsetzen kann. Die Zielarchitektur hat zudem aufgezeigt, wo Refactorings oder ggf. Neuentwicklungen nötig sind, welche davon innerhalb der Organisation stattfinden müssen und wo auch an Outsourcing gedacht werden kann. Auf Basis der Architekturüberlegungen können auch neue, sinnvollere Teamschnitte angedacht werden.</p><p>Zu guter Letzt möchten wir noch Uwe Friedrichsen unseren Dank aussprechen, für das theoretische Fundament unseres Vorgehens, sowie Christian Langmann für die praktische Unterstützung bei der Planung und Durchführung der Workshops.</p>

Auf dem Weg zur High-Level-Zielarchitektur

<p>Führt man Qualitätsmaßnahmen wie TDD, Pair Programming und generell agile Praktiken in Entwicklungsteams ein, wird oft befürchtet, man werde langsamer. Zusätzlich zu der „eigentlichen Aufgabe“ müsse man nun noch Tests schreiben, Reviews durchführen und dann auch noch so viele Meetings …</p><p>Dies scheint intuitiv Sinn zu ergeben: Bessere Qualität muss eben teuer erkauft werden. Die Management-Zahlen scheinen diesen Verdacht dann auch noch zu bestätigen: „Wo wir vorher acht Tickets geschafft haben, schaffen wir nun nur noch fünf!“</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Mu7WAhgFTDO6Fgz4Yf3X"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Mu7WAhgFTDO6Fgz4Yf3X" alt="Menge getaner Arbeit" width="418" height="106" /></a> </p><p>Dabei werden meine Kolleg*innen und ich nicht müde zu betonen, dass die Steigerung der Qualität dazu führt, dass Teams *schneller* werden. Wie passt das mit den vermeintlichen Fakten zusammen?</p><p>Schaut man sich an, was ein Team <em>qualitativ</em> macht, stellt man fest, dass es sich eigentlich „rückwärts bewegt“:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/OfQnMmHHTIK6ijBlcdrc"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/OfQnMmHHTIK6ijBlcdrc" alt="Menge wertvoller Arbeit" width="337" height="84" /></a> </p><p>Mit jedem Feature erzeugen sie neue Bugs und Code Smells oder arbeiten an den eigentlichen Anforderungen der Kund*innen vorbei. Die Arbeit für die nächsten Wochen beschafft man sich so selbst. Man hat immer etwas zu tun, schafft vermeintlich viel, kommt aber eigentlich nicht voran.</p><p>Deshalb zielt z. B. Scrum darauf ab, dass Teams <em>effektiv</em> zusammenarbeiten und wertvolle Features ausliefern, statt möglichst <em>viel</em> abzuarbeiten. Es gilt, die „Menge nicht getaner Arbeit“ zu maximieren und gezielt das umzusetzen, was wirklich Wert schafft. Aus diesem Blickwinkel ist das Team nach Einführung der Maßnahmen deutlich besser aufgestellt:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/58h53l2CQYu5cyTpnuCw"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/58h53l2CQYu5cyTpnuCw" alt="Qualität: Menge wertvoller Arbeit - vorher & nachher" width="425" height="143" /></a> </p><p>Es gibt vielfältige praktische Ausprägungen dieser Rückwärtsbewegung:</p><ul><li>Bugs</li><li>unnötige Features</li><li>unnötige Prozessschritte</li><li>Missverständnisse</li><li>Operative Notfälle</li><li>…</li></ul><p>In der Regel fallen mehrere Faktoren zusammen. Ich möchte zur Verdeutlichung ein konkretes Beispiel bringen: Ein Team wendet 50 % seiner Zeit zum Bugfixing auf und schafft in einer Woche zehn Tickets, also fünf Bugfixes und fünf Features. Innerhalb der gleichen Zeit entstehen acht neue Bugs. Hier läuft also etwas grundsätzlich falsch, obwohl das Team oberflächlich betrachtet mit der Geschwindigkeit von zehn Tickets sogar zufrieden ist und 50 % „Bugzeit“ suggerieren, dass man in Qualität investiert.</p><p>Nur auf die Auslastung der einzelnen Teammitglieder und die Menge getaner Arbeit zu schauen, ist also keine sinnvolle Metrik. Wichtig ist, dass sich Teams gezielt in die richtige Richtung bewegen und dabei hochwertige, nützliche Software an den Start bringen.</p>

3 Schritte vor und 5 zurück? Wie Qualität uns schneller macht

<p>Wir werden oft zu Projekten hinzugezogen, in denen ein hohes Maß an Softwarequalität gefragt ist. Seien es große Legacy-Anwendungen mit Qualitätsproblemen, bei denen das Kind schon in den Brunnen gefallen ist, oder junge Pilotprojekte, die auf ein stabiles Fundament gebaut werden sollen. Als erfahrene technische Experten können wir in diesen Fällen grundsätzlich weiterhelfen. Kunden ist aber anfangs oft nicht klar, dass Qualität auf mehr beruht als nur guter Technik.</p><p>Selbst technisch exzellente Teams können in Qualitätsprobleme geraten, wenn die Rahmenbedingungen nicht stimmen oder das Ziel unklar ist. Warum das so ist, und wie man gegensteuern kann, erläutern wir im Folgenden.</p><h2>Qualitätsprobleme durch Bugs</h2><p>Qualitätsprobleme machen sich für das Management oft erst dann wirklich bemerkbar, wenn die Fehlerzahl inakzeptabel ansteigt. Doch was ist überhaupt ein Bug und was nur ein (fehlendes) Feature? Dies führt regelmäßig zu Diskussionen zwischen Produktverantwortlichen und Entwicklung und kann streng genommen ohne klar dokumentierte Spezifikation gar nicht beantwortet werden.</p><p>Wie kann während der Entwicklung entschieden werden, was „weg kann“ und was definitiv noch funktionieren muss? Schnell wird ein Bug gefixt und zehn neue entstehen, sobald in der neuen Version etwas nicht mehr so funktioniert „wie vorher“. Aus Angst, etwas kaputtzumachen, bleiben dann auch mal ohne Not Altlasten im Code und verringern die Wartbarkeit immer weiter.</p><p>Um aus diesem Dilemma herauszukommen, braucht es ein gemeinsames Verständnis davon, was die Software eigentlich ist, was sie kann und was nicht. Zu jeder User Story gehören klare Akzeptanzkriterien und ggf. auch eine Abgrenzung, was explizit nicht dazugehört. Das schließt auch ein klares Verständnis des „Warum?“ ein, also welchen konkreten Nutzen ein bestimmtes Feature bringt. Erfahrene Teams vermeiden durch diese Kommunikation Bugs schon vor dem eigentlichen Programmieren.</p><p>Die Entwicklung muss dann natürlich auch in der Lage sein, die Anforderungen technisch einwandfrei zu implementieren und durch Tests abzudecken. Hierbei helfen z. B. Pair Programming, Code Reviews und testgetriebene Entwicklung (TDD).</p><h2>Tests</h2><p>Wir finden oft Projekte mit unzureichender Testabdeckung vor. Unser Ansatz ist es, keinen neuen Code zu schreiben und keinen Bug zu fixen, ohne dafür automatisierte Tests vorweisen zu können. Dies setzt wieder voraus, dass klar ist, was die Software eigentlich tun soll. Die Akzeptanzkriterien können als Grundlage für automatisierte Tests dienen. Der Ansatz der aktzeptanztestgetriebenen Entwicklung geht sogar so weit, dass die Spezifikation selbst als ausführbarer Test implementiert wird. Ebenso muss bei Bugs deutlich beschrieben sein, welches Verhalten eigentlich vom Soll abweicht und wie sich der Fehler reproduzieren lässt. Mit diesen Informationen können dann entsprechende Testfälle nachgebildet und Regressionen vermieden werden.</p><p>Hier ist es wichtig, dass das Unternehmen hohe Testautomatisierung als wesentlichen Bestandteil hochwertiger Softwareentwicklung versteht, <a href="/wissens-hub/blog/wie-qualitaet-uns-schneller-macht">der die Entwicklung tatsächlich <em>schneller</em> macht</a> . Die Entwicklungszeit muss stets auf Basis <em>funktionierender</em> Features gemessen werden. Um diese Botschaft verständlich zu machen, reicht ein Einsatz technischer Expert*innen nicht aus, sondern es braucht eine kulturelle und organisatorische Veränderung, die je nach Unternehmen bis zur Geschäftsleitung reichen muss. Die Entwicklungsteams können solch eine Veränderung nicht von alleine bewerkstelligen.</p><p>Außerdem kann man eine effiziente Testautomatisierung nur erreichen, wenn Softwareentwickelnde und Testende cross-funktional zusammenarbeiten. Wenn das Testing nachgelagert wird (z. B. durch eine dedizierte QA-Abteilung), verliert man viele Vorteile der Testautomatisierung, wie zum Beispiel schnelle Feedbackzyklen. Daher gehen organisatorische Themen, wie z. B. Teamstrukturen und Abläufe, häufig Hand in Hand mit technischen Themen.</p><p>Es reicht aber umgekehrt nicht, gute Anforderungsdokumente zu liefern und auf eine neue Kultur zu pochen. Teams müssen in der Lage sein, die Anforderungen in einer effizienten Testpyramide abzubilden und sicherzustellen, dass die Funktionen auch in einigen Monaten noch funktionieren. Auch die praktische Zusammenarbeit in cross-funktionalen Teams muss gelernt werden.</p><p>Außerdem hängt die Testbarkeit sehr stark von der Codequalität ab. Technische Methoden wie Test-driven Development und Refactorings können helfen, die Testbarkeit zu erhöhen. Mit erfahrenen Entwickler*innen oder Coaches können diese Methoden leichter etabliert werden.</p><h2>Refactorings</h2><p>Legacy-Anwendungen leiden oft darunter, dass alter Code nur sehr schwer verständlich und wartbar ist. Neue Features werden dadurch extrem teuer und die Bugrate steigt.</p><p>Erfahrene Teams refaktorieren ihre Anwendung kontinuierlich und lassen es im Idealfall erst gar nicht so weit kommen. Sie sind in der Lage zu erkennen, wie man das Software-Design verbessern kann, um das aktuelle Feature einfacher umzusetzen, und wechseln regelmäßig die „zwei Hüte“ (neue Funktionalität und Refactoring), um ihre Ziele zu erreichen. Sie behalten im Blick, dass das technische Fundament für die kommenden Anforderungen optimal gewappnet ist. Dazu müssen sie sich kontinuierlich mit den Produktverantwortlichen austauschen und die fachlichen Ziele verstehen.</p><p>Doch was, wenn große Refactorings dennoch notwendig werden? Rein technisch fokussierte Teams würden gerne keinen Stein auf dem anderen lassen oder eine Anwendung sogar komplett neu schreiben. Das ist aber selten die effizienteste Anwendung knapper Kapazitäten.</p><p>Refactorings sollten immer darauf einzahlen, zukünftige Features schneller umsetzen zu können. Dazu muss man aber wissen, in welche Richtung sich die Anwendung zukünftig entwickeln soll. Eine klare Produktvision und strategische Ausrichtung auf bestimmte Ziele ist nötig, damit Refactorings da eingesetzt werden können, wo sie tatsächlichen Wert schaffen.</p><p>Ob man größere Refactorings angehen soll, ist eine Ermessensentscheidung, die man selten aus rein technischen Gründen treffen kann. Wenn man eine klare Produktstrategie hat, die wichtige Rahmenbedingungen setzt, hilft das enorm, den relativen Aufwand einzuschätzen. Damit können wichtige Fragen beantwortet werden, z. B.</p><ul><li>Inwiefern wird diese Komponente in nächster Zeit erweitert?</li><li>Erfüllt das aktuelle Software-Design die Anforderungen, die auf der Produkt-Roadmap stehen?</li><li>Müssen wir (im schlimmsten Fall) in nächster Zeit diese Komponente komplett wegwerfen oder neu bauen?</li></ul><p>Die beste Produktvision kann jedoch nicht umgesetzt werden, wenn Teams nicht in der Lage sind, „den Karren aus dem Dreck zu ziehen“. Wenn klar ist, wohin die Reise gehen soll, braucht es geschulte Leute, die eine Legacy-Anwendung gezielt in diese Richtung refaktorieren können.</p><h2>Architektur</h2><p>Software-Architektur ist kein Selbstzweck, sondern dient dazu, den geschäftlichen Anforderungen den optimalen technischen Unterbau zu bieten. Es gibt nicht „die beste“ Architektur, sondern es geht immer darum bestimmte Trade-offs einzugehen. Verschiedene Architekturziele können sich widersprechen und müssen gegeneinander abgewogen werden. Dabei müssen die funktionalen Anforderungen mit einbezogen werden. Für eine zweckmäßige Architektur ist also auch wieder das Produktziel entscheidend.</p><p>Dennoch stößt man immer wieder auf einen Konflikt zwischen aktuellen und zukünftigen Anforderungen. Einerseits soll die Architektur evolutionär sein und inkrementell verbessert werden. Schließlich kann man das Feedback der Nutzer*innen und die zukünftigen Prioritäten nicht vorhersagen. Andererseits müssen bestimmte Architekturentscheidungen früh getroffen werden und das richtige Fundament kann die zukünftige Entwicklung erleichtern. Nur ein gut funktionierendes Team, welches das relevante technische und fachliche Wissen zusammenbringt und die Verantwortung für die Architektur übernimmt, ist in der Lage, die richtigen Entscheidungen zu treffen und optimal auf Veränderungen zu reagieren.</p><p>Nur durch diese Zusammenarbeit ist es möglich, die richtigen fachlichen Schnitte der Anwendung zu identizifieren und die Business-Domäne und deren Objekte zu definieren. Wichtig ist auch eine einheitliche Sprache, damit solche Objekte und die Use-Cases der Software von allen klar verstanden sind.</p><p>Teams müssen im Tagesgeschäft über Architektur diskutieren und mit verschiedenen Lösungsmöglichkeiten experimentieren können. Dies funktioniert nicht in Organisationen, in denen Arbeitspakete „von oben“ zugewiesen werden und ein hoher Stresslevel durch fremdbestimmte Deadlines existiert. Agiles Arbeiten in selbstorganisierten Teams ist daher eine wichtige Voraussetzung für gute Architekturentscheidungen.</p><p>Es reicht aber auch nicht aus, Agilität einzuführen und darauf zu hoffen, dass die Teams ab sofort gute Architektur umsetzen. Dies wird nicht funktionieren, insbesondere, wenn vorher ein anderes Arbeitsklima vorherrschte und daher keine Übung in solcher Eigenverantwortung besteht. Hier braucht es die Unterstützung von erfahrenen Entwickler*innen.</p><h2>Codequalität & 4-Augen-Prinzip</h2><p>Um eine hohe Softwarequalität zu erreichen, helfen z. B. Clean Code, Pair Programming und Code-Reviews. Alles Themen, die wir als technische Coaches vermitteln können. Allerdings muss die Umsetzung auch im Tagesgeschäft möglich sein. Ebenso wie für Tests und Architektur müssen die Teams auch hierfür den Kopf frei haben und Verantwortung übernehmen können. Einige Teams, denen wir begegnet sind, waren sich durchaus bewusst, wie man guten Code schreibt, klagten aber über Zeitdruck, Pairing-Verbot oder lange Wartezeiten für Reviews. In diesen Unternehmen wurden Methoden wie Pair Programming außerhalb der Entwicklung als Zeitverschwendung empfunden, ohne deren Vorteile für die Softwarequalität zu verstehen.</p><p>Dies sind wieder klare Anzeichen, dass die organisatorischen Rahmenbedingungen nicht stimmen. Wie wichtig Softwarequalität für die langfristige Entwicklungsgeschwindigkeit ist, muss unternehmensweit verstanden und in der Kultur verankert werden. Ansonsten verpuffen technische Schulungen wirkungslos, da nach dem ersten Enthusiasmus schnell auf alte Muster zurückgegriffen wird.</p><h2>Agilität und Zusammenarbeit lernen</h2><p>Um agile Softwareentwicklung effektiv zu betreiben, reichen technische Skills und Methoden nicht aus. Egal welches agile Vorgehen man nimmt, alle Beteiligten müssen lernen, mit den zugehörigen Werkzeugen und Praktiken effektiv umzugehen und ihre Rolle einzunehmen<span>.</span></p><p><span>Bei Scrum, zum Beispiel, müssen nicht nur Scrum Master und Product Owner gecoacht werden, sondern auch Entwickler*innen müssen lernen, wie sie sich sinnvoll in Planning, Refinement und Retrospektive einbringen können. Alle Rollen müssen gut zusammenarbeiten und sich ergänzen. Die Teams sollten daher fachlich aufgeteilt und cross-funktional aufgestellt werden, sodass alle nötigen Expertisen vertreten sind, um Aufgaben Ende-zu-Ende abzuarbeiten. Nur so kann eine gemeinsame Verantwortung für Qualität entstehen. In rein technisch geschnittenen Teams kommt es hingegen oft zu Fehlern an den Schnittstellen und zu gegenseitigen Schuldzuweisungen, warum ein Feature in Integration am Ende doch nicht funktioni</span><span><span>ert.</span></span></p><p><span><span>Es kann dennoch teamübergreifende Software- und Architektur-Themen geben, die koordiniert werden müssen. Hier kann ein Entwicklungsteam nicht alleine agieren: Der Austausch zwischen Teams und mit teamübergreifenden Rollen muss von der Organisationsstruktur gefördert werden. Dafür muss die Organisation den Entwickler*innen die Freiheit und die Gelegenheit geben, um solche Themen voranzutreiben. Hier kann zum Beispiel die Etablierung von Communities of Practice helfen</span></span>.</p><h3><span>Entwicklungsleitung und Management-Bu</span>y-in</h3><p>Wir erleben auch oft, dass die initiale Schieflage der Entwicklung, wenn wir gerufen werden, durch eine schwache oder nicht vorhandene Entwicklungsleitung zugelassen wurde. Kontinuierlicher Austausch, Verbesserung und der Rückfluss notwendiger Maßnahmen in Sprints und Roadmap können im Idealfall von Vertreter*innen der Teams selbst gemanagt werden. Hierfür müssen die Teams allerdings enabled sein. In den meisten Organisationen, die viele der oben beschriebenen Qualitätsprobleme haben, ist das Management aber nicht so aufgestellt, dass dies der Fall ist.</p><p>Deshalb haben wir gute Erfahrung damit gemacht, dass unsere Coaches sich kontinuierlich mit dem Management austauschen, um auch dort die Bereitschaft zu verankern, sich agil weiterzuentwickeln. Wird dies versäumt, behindert der Widerspruch zwischen klassischer Führung und agiler Entwicklung oft den Fortschritt und limitiert das Unternehmen stark. Dann bleibt es in Lagern: die da oben und die da unten – mit allen negativen Konsequenzen.</p><p>Für echte Veränderung braucht es auch ein Management-Buy-in und einen „Sponsor“ im Unternehmen, der die notwendigen Veränderungen und Maßnahmen (oft durch die Coaches initiiert) versteht und im Kreis des Managements vertritt. Er oder sie kann die nötigen Veränderungen in die Sprache des Managements übersetzen und helfen, die Organisation zu verändern und dabei alle Betroffenen mitzunehmen.</p><h2>Schlussfolgerung</h2><p>Hohe Qualität ist keine reine Technikfrage, sondern hängt von einem Zusammenspiel im gesamten Team ab:</p><ol><li>Produktvision und -ziele müssen klar herausgearbeitet werden.</li><li>Die organisatorischen Rahmenbedingungen müssen stimmen.</li><li>Das Team muss das nötige technische Know-how vorweisen.</li></ol><p>Wir haben daher festgestellt, dass die beste Variante, unsere Kunden bei Qualitätsproblemen zu unterstützen, ein Team aus verschiedenen Coaches ist:</p><ol><li>Product Coaches unterstützen das Business bei der Ausrichtung des Produkts und der Prioritätensetzung.</li><li>Agile Coaches unterstützen den Aufbau agiler Rahmenbedingungen und selbstorganisierter Teams.</li><li>Technical Coaches helfen den Teams bei der praktischen Umsetzung agiler Softwareentwicklung.</li></ol><p>In dieser Aufstellung können wir Unternehmen helfen, Qualitätsprobleme an der Wurzel anzupacken und die Qualität <em>nachhaltig</em> zu steigern.</p><p>Sie wollen wissen, wie auch Sie mehr Qualität in Ihrem Projekt erreichen können? <a href="https://www.codecentric.de/kontakt">Melden Sie sich gerne unverbindlich bei uns</a> .</p><p> </p><p><a href="https://www.codecentric.de/karriere/jobs/agile-fullstack-developer?utm_campaign=PeSo%20Blog%20to%20Job&utm_source=cc_blog&utm_medium=display&utm_content=fullstack_developer_und_consultant" target="_blank"><img loading="lazy" width="660" height="220" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/dxZ8BjusQP2SDKaLDh4D" alt="Mitglieder für unsere Gilde gesucht! Jetzt der Gilde als Fullstack Developer und Consultant (w/d/m) beitreten" /></a> </p><p> </p><p> </p>

Qualität ist Teamwork

<p>We are usually involved in projects demanding a high level of software quality, whether they be large legacy applications, where the customer is already beset with problems and is trying to shut the stable door after the horse has bolted, or newer pilot projects, which need to be built on stable foundations. As experienced technical experts we can of course help to get things on the right track. Having said that, we frequently find that our customers initially do not understand how quality is about a lot more than just good technology.</p><p>Even technically excellent teams can slip into quality problems if the working conditions or the project goal are unclear. In this article we explain why this is the case and what we can do about it.</p><h2>Is it a bug or a feature?</h2><p>Poor software quality often only comes to management’s attention when the number of errors reaches an unacceptable level. Yet what is actually a bug and what is just a (missing) feature? This question often leads to discussions between the product and development teams and cannot, strictly speaking, be answered without a clear written specification of the software’s requirements.</p><p>How do we decide during development what can be removed and what needs to remain? Most developers have experienced the situation where a bug fix leads to a string of new ones, due to something “not working like it used to” in the new version. For fear of breaking something, we often see developers steer clear of improving bad software design, which in turn leads to a continuing deterioration of the software’s maintainability.</p><p>To escape from this dilemma we need a shared understanding of what the software actually is: that is to say, what can it do and what not? Each user story should include clear acceptance criteria and, where applicable, define what is out of scope. For effective software development the team also needs to understand the broader context, i.e. not just <em>what</em> it is developing, but also <em>why</em> it is required and what concrete use cases are envisaged. Experienced teams avoid bugs through this type of communication, before they even begin with the implementation in code.</p><p>The development team still of course needs the right technical skills and experience in order to ensure that the software functions properly and is adequately protected through automated tests. Best practices such as pair programming, code reviews and test driven development (TDD) can help achieve this.</p><h2>Tests</h2><p>We frequently encounter projects with inadequate test coverage. Our approach is not to write new code or fix a bug without corresponding automated tests to verify the expected behaviour. This, however, presupposes that it is clear what the software is supposed to do.</p><p>Acceptance criteria in a user story serve as a basis for understanding this. Acceptance test driven development (ATDD) even goes so far as to translate the written specification into executable tests. Similarly, in the case of bugs, the way in which the functionality deviates from expected behaviour and how the error can be reproduced need to be clearly defined. This information can then be mapped into appropriate automated test cases so as to ensure functional correctness and avoid regression.</p><p>It is critical for the business to understand high test automation as an integral part of high-quality software <a href="/wissens-hub/blog/wie-qualitaet-uns-schneller-macht">which actually makes development faster</a> : development speed should always be measured based on <em>working</em> features. Unfortunately, the deployment of technical experts is in many cases not enough to communicate this message, rather, the business often requires significant cultural and organisational upheaval, which reaches as far as management level, to achieve this. Development teams cannot bring about such a change on their own.</p><p>Additionally, efficient test automation can only be achieved when developers and testers work together cross-functionally. If testing is only carried out after the development stage (for example by a dedicated QA department) many of the advantages of test automation, such as fast feedback loops, are lost. Consequently organisational aspects such as team structure and process often go hand in hand with technical matters.</p><p>It is, on the other hand, not enough just to deliver good requirement documents and to expect a new culture to appear. Teams need to be capable of mapping these requirements onto an efficient test pyramid and ensuring the software still works in ensuing months and years. Even good teamwork is a skill that cross-functional teams need to learn through practice.</p><p>Furthermore, code testability is very much dependent on good software design. Technical methods, for example test driven development and refactorings, can help to improve this, and such methods can be more readily established when experienced developers or coaches are on hand.</p><h2>Refactorings</h2><p>Legacy applications often suffer from old code being difficult to understand and maintain. This leads to new features being very expensive and to an ever-increasing bug rate.</p><p>Experienced teams refactor their application code continuously and ideally avoid these pitfalls. They are capable of recognising how the software design can be improved as they go along in order to implement the current feature and regularly switch between the “two hats” (new functionality and refactoring) to achieve the goal in hand. They also keep an eye on upcoming requirements to ensure the technical foundations are optimised to deal with them. In order to achieve this they keep open a continuous dialogue with product team representatives and understand the current business goals.</p><p>But what happens when larger refactorings are required? Teams with only a technical focus might prefer to leave no stone unturned in order to achieve their interpretation of technical perfection and might even push for a complete rewrite of the application. This is, however, rarely the most efficient use of limited resources.</p><p>Refactorings should always be geared towards making the job in hand and future requirements easier and quicker to implement. Yet in order to achieve this, it is important to understand where the application is heading. A clear product vision and strategic focus on defined goals is critical so that refactorings with the most value (i.e. which improve future development speed) can be prioritised.</p><p>Whether larger refactorings should be undertaken is always a judgement call, which cannot be made solely based on technical reasons. A clear product strategy, which defines the key parameters for anticipated functional requirements, is incredibly helpful to estimate the relative effort of the refactorings and to answer important questions such as:</p><ul><li>How and to what extent will this component be extended in the coming development cycles?</li><li>Does the current software design satisfy the requirements on the product roadmap?</li><li>Do we (in the worst-case scenario) need to throw this component away and start from scratch?</li></ul><p>Nonetheless, even the best product vision cannot be fulfilled if teams do not have the technical skills to dig themselves out of the hole they find themselves in. Once it is clear where the journey is heading, developers still need the right technical skills and training to understand how to refactor a legacy application and keep the project on the right track.</p><h2>Architecture</h2><p>Software architecture is not an end in itself, but should seek to provide an optimal technical foundation for the product’s business requirements. There is no such thing as “the best architecture”, rather, it is always a question of making trade-offs. A software product will always have multiple architecture goals which conflict with and need to be weighed up against each other. Again, the product’s goal and its functional requirements will also play an important role here in making the appropriate architectural decisions.</p><p>During development, even the best teams will keep coming up against conflicts between current and future requirements. On the one hand, software architecture should be evolutionary and be improved incrementally, as it is impossible to predict users’ feedback and the exact nature of future priorities. Yet, on the other hand, certain architectural decisions do need to be made early enough in the development process so that the right foundation is in place to facilitate productive development. Only a well-functioning team, which not only brings together the relevant technical and business knowledge but also assumes responsibility for the software’s architecture, will be in a position to make the right decisions and react to changes in requirements in the best possible way.</p><p>Only through such teamwork is it possible to identify the right context boundaries in the application and to define the business domains and their objects. It is also critical to establish a universal language for these domains, so that business objects and the software’s use cases are clearly understood by the entire team.</p><p>Successful teams discuss the software’s architecture as part of their daily business and are able to experiment with various possible solutions. This is not possible in organisations where small predefined tasks are imposed on development teams from above or where teams are constantly under pressure from external deadlines. Agile practices in self-organised teams are therefore an important precondition for good architecture decisions.</p><p>It is, on the other hand, not enough simply to introduce agile frameworks and hope that this leads to teams being immediately capable of good software architecture. This will usually not be the case without support and coaching from experienced developers, especially if the previous working conditions were very different and the developers do not have prior experience of working in self-organised teams.</p><h2>Code quality and the “four eyes principle”</h2><p>Methods such as clean code, pair programming and code reviews help to achieve a high level of software quality. As technical coaches we can help out in these areas, but this will only be possible if development teams are given the freedom to try out and practise such methods as part of their day-to-day work. Similarly, teams need freedom to make their own decisions and take responsibility for matters such as architecture and testing strategies. Some of the teams we come across have solid technical skills but complain about time pressure, not being allowed to pair together, or long waiting times for code reviews. In these organisations methods such as pair programming are often seen as time-wasting, without understanding their positive benefits.</p><p>This is a clear signal that the organisational framework is not suitable. The importance of software quality needs to be understood throughout the entire organisation and embedded in its culture. Otherwise the benefits of any technical training will simply wither away, as, despite initial enthusiasm, teams will usually drift back into old ways of working due to external pressures.</p><h2>Agility and teamwork</h2><p>Technical skills and methods alone are not enough to succeed in agile software development. No matter which agile framework is used, all participants need to learn how to use the relevant tools and practices effectively and play their role in the team.</p><p>In Scrum, for example, it is not just the scrum master and product owner who need to be coached, rather, the developers also need to learn how to contribute to plannings, refinements and retrospectives in a constructive way. All roles need to work together and complement each other. Teams need to be cross-functional, so that they have all the necessary expertise to implement end-to-end features. Only this way can a collective responsibility for quality be established. Where teams are divided up on a purely technical basis, features often suffer from misunderstandings and errors at the interfaces between components, and teams blame each other when explaining why their integration does not work as planned.</p><p>There are, of course, also overarching software and architecture issues which need to coordinated at a cross-team level. A development team cannot manage this on its own: communication between teams and with others involved in such matters needs to be encouraged by the organisational structure. Developers should be enabled to take responsibility for such issues. The establishment of communities of practice can, for example, help to achieve this.</p><h2>Management buy-in</h2><p>Continuous reflection and improvements of the development process and roadmap are ideally managed by the teams themselves – but, in most organisations that suffer from the above-mentioned quality problems, the necessary management setup is not in place to enable this.</p><p>Consequently we see the best possible results when our coaches also have direct and regular contact with management, to gain acceptance and adoption of agile methods at that level too. If this does not happen, the contradictions between “classic management” and agile development hamper progress, and we remain stuck with hierarchical layers – those above and those below – with all the negative consequences that entails.</p><p>For genuine changes in an organisation to occur, management buy-in is required, as well as a “sponsor”, who understands the necessary changes and measures (often initiated by the coaches) and promotes them in management circles. Such a sponsor is capable of translating the necessary changes into management speak and helping all relevant stakeholders to participate in the transformation.</p><h2>Summary</h2><p>Good software quality is not just a technical question, but depends on good teamwork:</p><ol><li>The product vision and goals need to be clearly defined.</li><li>The organisational structure needs to encourage good development practices.</li><li>The team needs to exhibit the necessary technical know-how.</li></ol><p>We often find that the best way of helping our customers to handle quality problems is with a team of coaches with different skillsets:</p><ol><li>Product coaches help the business with product direction and prioritising the requirements.</li><li>Agile coaches help to establish agile working conditions and self-organised teams.</li><li>Technical coaches help the teams with the establishment of agile software development practices.</li></ol><p>With such a team we can help businesses to attack quality problems from the root upwards and to improve quality in a <em>sustainable</em> way.</p><p>Do you want to learn more about building quality software for your project? Then feel free to <a href="https://www.codecentric.de/kontakt">get in touch with us</a> .</p>

Quality means teamwork

Software Developer & Consultant

Consultant

<p>Wir wollen in diesem Blogpost unsere Erfahrungen mit Metriken zur Bewertung einer agilen Transition teilen. Speziell geht es uns um die Motivation, Stabilität und Aussagekraft solcher Metriken in einer Transition. Deshalb betrachten wir Metriken wie z. B. Velocity oder Durchlaufzeit nur exemplarisch und erläutern, wo die Fallstricke beim Einsatz dieser Metriken liegen.</p><p>Mit Transition meinen wir größere Veränderungsprozesse, die Auswirkungen auf den Entwicklungsprozess und dessen Organisation haben, wie z. B. Änderungen der Architektur und Erhöhung technischer Exzellenz als auch Änderungen im Anforderungsmanagement, Vorgehensmodell oder Teamschnitt.</p><p>Die Ausgangssituation der Transition beschreiben wir nur grob, da sie je Kunde spezifisch ist und es für unser Thema nur auf eine grundsätzliche Betrachtung ankommt.</p><p>Wir betrachten Metriken, die den Entwicklungsprozess detailliert von innen betrachten. Diese sind gut geeignet, um Teams ihr Verbesserungspotenzial aufzuzeigen. Die Basis dieser Metriken unterliegt aber in der Regel genau den Veränderungen, die zur gewünschten Verbesserung des Entwicklungsprozesses führen.</p><h2>Situation</h2><p>Wir helfen oft Kunden, die eine Kombination von Problemen haben – Unklarheiten in der Anforderungsaufnahme, mangelnde Qualität, Probleme mit der Planbarkeit bzw. mit der Liefertreue, unberechenbare und sehr langsame Liefergeschwindigkeit. Gemeinsam mit dem Kunden erarbeiten wir eine Zielrichtung. Wir machen uns ein übergreifendes Bild vom Ist-Zustand des betroffenen Bereichs. Partizipativ identifizieren wir in einem kontinuierlichen Verbesserungsprozess mögliche Lösungsansätze und helfen dem Kunden, diese Schritt für Schritt umzusetzen.</p><p>Gegen Ende unseres Engagements kommt nicht selten das Management auf uns zu und verlangt nach Metriken. Es braucht die Zahlen, um den Erfolg der Maßnahme gegenüber Dritten zu belegen bzw. zu rechtfertigen. Um einen Ausgangspunkt für einen Vergleich am Ende zu erhalten, müssen Metriken von Anfang an erhoben werden. Die Festlegung auf Metriken schon am Anfang einer Veränderung ist jedoch eine große Herausforderung.</p><h2>Orientierungsnotwendigkeit</h2><p>Zu Beginn weiß der Kunde oft nicht, was genau verbessert werden soll, die Ziele sind ihm noch unklar. Und auch wir müssen uns erst ein Bild über den Bereich des Unternehmens machen, um den es in unserem Auftrag geht. Der Kunde berichtet uns zwar von Problemen, die er aus seiner Sicht wahrnimmt – für ein klares Bild müssen wir die Situation aber aus unterschiedlichen Blickwinkeln beleuchten. Anhand des Bildes müssen wir verstehen, was genau geändert werden muss und warum. Erst wenn wir mit dem Kunden ein Ziel definieren, können wir Metriken für die Veränderung ableiten.</p><h2>Leidensdruck</h2><p>Der Kunde hat zu Beginn einen starken Leidensdruck und drängt aufgrund seiner Situation massiv zu Lösungen. Die Verbesserung ist wichtiger als ihre Dokumentation. Das Aufstellen und Erheben von Metriken tritt dadurch in den Hintergrund. Wenn wir die Ausgangssituation aber nicht durch Metriken belegen, können wir später, wenn der Leidensdruck dem Druck, Erfolg zu melden, weicht, keinen Vergleich mehr ziehen. Eine objektive Bewertung der Veränderung ist dann nicht mehr möglich.</p><p>Wenn das Ziel feststeht und wir sinnvolle Metriken aufstellen wollen, stoßen wir in der Praxis gerade in der Anfangsphase von Veränderungen auf einige Herausforderungen.</p><h2>Herausforderungen beim Finden und Gestalten von Metriken</h2><h3>Die Basis einer Messung muss stabil bleiben</h3><p>Damit man später nicht Äpfel mit Birnen vergleicht, muss die Basis einer Messung über die Zeit stabil bleiben.</p><p>Nehmen wir zum Beispiel an, dass wir mit unseren Veränderungen den gesamten Entwicklungsprozess verbessern wollen. Hierzu schauen wir uns exemplarisch die Durchlaufzeit (Lead Time) von Anforderungen an.</p><p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BFXMWtewQttlasOIX5V2" alt="Lead Time als Metrik für Time to Market" /></p><p>Die Anforderungen, die wir vorfinden, sind meistens auf technische Komponenten zugeschnitten. In dieser Form zeigen sie den direkten Kundennutzen nicht mehr auf. Die Summe dieser technischen Anforderungen ergibt eine viel zu umfangreiche Kundenanforderung. Sie entspricht oft schon einem kleinen Kundenprojekt. Auf dieser Ebene zu messen bringt in der Regel nichts für den zeitlichen Rahmen, in dem das Management einen Erfolg melden muss.</p><p>Im Gegensatz zur technischen Anforderung beschreibt eine fachliche Anforderung eine einzelne Funktionalität und damit direkt einen Kundennutzen. Die Durchlaufzeit dieser Anforderung zeigt also Wert pro Zeit auf. Der Wechsel von technischer zu fachlicher Erfassung von Anforderungen verändert die Basis unserer Metrik. Die Vergleichbarkeit der beiden Messungen geht hierbei verloren.</p><p>Die Fähigkeit, fachliche Anforderungen möglichst klein zu schneiden, entwickelt sich erst im Laufe des Verbesserungsprozesses. Auch ist die Menge der Anforderungen relevant, die aufgrund der Umstellung zu fachlichen Formulierungen umgeschrieben bzw. neu erfasst werden müssen. Hier sehen wir also eine Verbesserung der Durchlaufzeit über die Zeit. Der Zeitpunkt, wann dieser Effekt sichtbar wird, kann für die Erfolgsmeldung zu spät sein.</p><p>Wenn POs technische Anforderungen fachlich neu formulieren und schneiden, dann muss der Kunde auch seine Organisation entsprechend anpassen. Das Unternehmen muss die Organisation also auf Feature-Teams statt auf Komponenten-Teams aufbauen. Bleibt die Umsetzung in Komponenten-Teams, werden Synchronisations- und Übergabezeiträume schnell zum bestimmenden Faktor der Entwicklungsgeschwindigkeit. Leider ändert der Umbau der Organisation auch die Basis der Metrik und die Messungen sind nicht mehr vergleichbar.</p><h3>Metriken müssen möglichst objektiv sein</h3><p>Für eine gute Aussagekraft müssen wir die Metrik so wählen, dass das Unternehmen möglichst objektiv und nicht manipulierbar messen kann.</p><p>Wenn wir zum Beispiel die Entwicklungsgeschwindigkeit messen wollen, dann wird hierzu gerne die Team Velocity verwendet. Diese Metrik ist nur gut genug, wenn sie teamintern verwendet wird, und zwar im Zusammenhang mit anderen Metriken. Diese müssen z. B. sicherstellen, dass die Geschwindigkeit nicht auf Kosten der Softwarequalität oder durch viele Überstunden entsteht. Währenddessen muss mit jeder Anforderung Wert an den Kunden geliefert werden.</p><p>Wenn die Velocity über geschätzte Story-Punkte des Teams entsteht, dann ist für die Interpretation der Metrik die Lernkurve des Teams zu beachten. Alternativ zum Schätzen mithilfe von Story-Punkten können auch Anforderungen gezählt werden bzw. die Durchlaufzeit im Team pro Anforderung (Cycle Time) gemessen werden.</p><p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/WGz9yjWjRfW4BNUrcvdt" alt="Cycle Time als Metrik für die Entwicklungsgeschwindigkeit" /></p><p>Die Stabilität des Teams beeinflusst ebenfalls die Geschwindigkeit und ist ein Faktor, auf den das Team meistens keinen direkten Einfluss hat. Bei Veränderungen eines Teams braucht es z. B. Zeit, um die volle Leistungsfähigkeit zu erreichen. Das Team muss sich erst finden und durchläuft daher <a href="/wissens-hub/blog/tuckmans-4-phasenmodell" target="_blank">Tuckmans Phasenmodell</a> : Forming, Storming, Norming, Performing.</p><p>Von außen gesehen ist die Velocity in Story-Punkten nur sehr bedingt aussagekräftig. Bei einem stetig hohen Verbesserungsdruck kann das Team auch hier die höhere Geschwindigkeit ohne Verbesserung des Prozesses erreichen. Die Mitarbeiter können z. B. Überstunden machen, ihr Schätzverhalten ändern oder auf Kosten der Qualität schneller liefern, um der Erwartung gerecht zu werden. Alternativ könnte der Geschäftswert der Anforderungen außerhalb des Teams bestimmt werden. Dies würde eher zu einer objektiven Metrik führen, auch wenn natürlich auch dieser Wert manipuliert werden kann.</p><h3>Metriken müssen leicht erfassbar sein</h3><p>Für eine stabile Messung über die Zeit müssen Metriken leicht genug erfassbar sein, damit die Messung auch unter viel Druck lückenlos und sicher gelingen kann. Unserer Erfahrung nach können selbst scheinbar einfache Metriken in der Implementierung alles andere als trivial sein.</p><p>Wir können z. B. beschließen, die Wiederherstellungszeit für einen Dienst (<a href="https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling" target="_blank">time to restore service</a> ) zu messen, um die Stabilität der Software zu beurteilen. Hier geht es um die Zeit, die benötigt wird, um eine Störung beim Kunden zu beheben (von Meldung der Störung bis zur Behebung)﻿. Die Schwierigkeit liegt hier in der Erfassung der Messungen. Oft ist es bei unseren Kunden so, dass Mitarbeiter Störungen auf sehr unterschiedlichen Wegen an das Team kommunizieren – auch gerne mal am Backlog vorbei. Somit müssen sich alle Beteiligten so disziplinieren, dass eine gemeinsame Erfassung gelingt. Und auch die Frage nach der Behebung der Störung kann herausfordernd sein, wenn z. B. die eigentliche Installation und Aktivierung von Änderungen ausschließlich durch den Endkunden erfolgt.<br /> Generell kann man sagen, dass die Messung umso sicherer zum Scheitern verurteilt ist, je umständlicher die Erfassung von Messdaten ist.</p><p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BH7Fr3VETLiYsqNjy8X9" alt="Wiederherstellungszeit für einen Dienst als Metrik für die Stabilität der Software und für Servicequalität" /></p><h3>Metriken müssen motivierend und neutral sein</h3><p>Metriken müssen für die betroffenen Personengruppen motivierend sein. Es ist schwierig, wenn anhand der Metrik jemand konkret bewertet und indirekt angegriffen wird. Es darf kein rückwärts gerichteter Rechtfertigungsdruck entstehen, sondern es braucht den Blick nach vorne als Motivation zur Verbesserung. Um motivierend zu sein und zu bleiben, müssen Metriken neutral und aussagekräftig sein. Gerade auch Niederlagen unterstützen bei richtig geformten Metriken den Erkenntnisgewinn, da Teams in der Softwareentwicklung im Bereich des Komplexen unterwegs sind. Hier müssen sie empirisch und experimentell vorgehen, um sinnvoll zu navigieren. Eine Metrik muss unterstützen und nicht nur bewerten.</p><p>Zur Teamentwicklung müssen die Metriken in erster Linie Verhaltensweisen und nicht Ergebnisse belohnen. Gesteckte Ziele sollen herausfordern, aber trotzdem erreichbar sein. Und bei dem, was das Unternehmen misst, müssen die Nutzer der Metrik den Zusammenhang zwischen ihrer Handlung und dem Effekt möglichst direkt erkennen. In einem solchen Kontext steigt das intrinsische Interesse daran, die Messungen als Indikatoren zur Verbesserung der eigenen Arbeit heranzuziehen. Wenn ein Team aus besseren Zahlen einen direkten Zusammenhang zu seiner konkreten Situation erkennen kann, indem es diese Verbesserungen in seiner Arbeit spürt, dann steigen Motivation und Engagement.</p><p>Bezogen auf den Motivationsaspekt können wir auch hier gut auf das Beispiel der Team Velocity zurückgreifen. Wenn das Management seine Teams unter hohem Druck alleine auf Basis ihrer Velocity bewertet und miteinander vergleicht, dann ist für Betroffene die Versuchung groß, Zahlen einfach dahin zu bringen, wo alle sie haben wollen. Ein Fortschritt im Team wird dann nicht erreicht. Hier ist die Frustration aller Betroffenen garantiert.</p><h2>Erfolgsdruck einer Veränderung</h2><p>Bei Metriken zum Messen des Erfolgs einer Veränderung ist die Motivation des Managements ein wichtiger Aspekt. Wenn ein Manager den Erfolg melden MUSS, dann werden Metriken zu Druckmitteln. Die betroffenen Mitarbeiter können die Zahlen entweder manipulieren oder sich frustriert zurückziehen. Der Sinn, eine Metrik als motivierenden Indikator zu verstehen, geht so verloren.</p><p>Unter diesen Umständen geht es dem Management hauptsächlich um die nackten Zahlen, die allerdings im Auge des Betrachters zu einer starken Vereinfachung der realen komplexen Situation führen. Ohne eine adäquate Interpretation sind diese Zahlen nichts mehr wert und können sogar eine gesunde Entwicklung des Unternehmens behindern.</p><p>Wenn hinzukommt, dass Veränderungserfolg in einem im Voraus bestimmten und vom Sachverhalt losgelösten Zeitintervall gemeldet werden muss, dann wächst der Rechtfertigungsdruck extrem. Im hierarchischen Gefälle CEO – CTO – (Scrum Master –) Team wächst der Druck nach unten. (Der Scrum Master ist zwar offiziell nicht Teil der Hierarchie, wird aber gerne als Teamleiter missbraucht, um gewünschte Metriken durchzusetzen und anschließend zu rechtfertigen.) Der extreme Druck nach unten ist kontraproduktiv und wirkt dem von uns angestrebten Servant Leadership entgegen.</p><p>Kennzahlen und erreichte Ziele können ein großer Motivationsverstärker sein. Richtig eingesetzt sorgen kleine Wettbewerbe, Siege und Niederlagen für persönliches und unternehmerisches Wachstum. Für ein hohes Engagement aller Teilnehmer, sich während der Veränderung von Metriken leiten zu lassen, müssen die betroffenen Mitarbeiter beim Ausarbeiten und Aufstellen der Metriken direkt mitgestalten. Da Metriken die reale Situation stark vereinfacht abbilden, müssen die Beteiligten verstehen, was hinter ihren Metriken steckt und dass es in erster Linie um die angestrebte Verbesserung geht und nicht um eine Kontrolle von außen. Die Mitarbeiter können so an viele Aspekte der Messung gleichzeitig denken, weil jeder diese aus seinem eigenen Blickwinkel beurteilt und formt.</p><h2>Fazit</h2><p>Aus dem Kontext einer Veränderung heraus sind Metriken wichtige Wegweiser für alle Betroffenen. Das Aufstellen und Messen von geeigneten und aussagekräftigen Metriken ist in vielen Fällen sehr herausfordernd. In jeder Phase der Veränderung können sie sinnvolle Hinweise geben. Als Erfolgsmeldung sind sie allerdings mit Vorsicht zu betrachten, da die Basis, auf der wir die Metriken erheben können, nicht grundsätzlich über die Zeit stabil bleibt. Der Vergleich und damit die Bewertung der Transition ist also nicht leicht darzustellen.<br /> Wir haben hier bewusst Metriken betrachtet, die zur Verbesserung des Prozesses verwendet werden können, da sie konkrete Rückschlüsse auf operative Handlungsfelder zulassen.</p><p>Für die Bewertung und strategische Steuerung auf Unternehmensebene eignen sich eher Metriken, die das Ergebnis der Produktion oder die Kundensicht betrachten. Sie nehmen also eher eine Außensicht ein und versprechen eine deutlich bessere Stabilität. Der direkte Bezug zur Operative und damit zur konkreten Steuerung der Verbesserungen ist allerdings schwierig. Und signifikante Auswirkungen der Veränderungen auf diese Metriken werden erst mit einer großen Zeitverzögerung sichtbar.</p><p>Sehr wichtig und am Ende auch ausschlaggebend ist vor allem die Motivation, die hinter diesen Metriken steckt, da vor allem ihre Interpretation zählt. Die entkoppelte Bewertung von dritten und besonders von hierarchisch höher gestellten Personen ist kontraproduktiv. Metriken entfalten dann eine gute Wirkung, wenn Betroffene sie selbst zur Verbesserung aufstellen und benutzen.</p><h2>Ein Team von Coaches unterstützt bei der Umstellung</h2><p>Eine agile Tranisition ist für jedes Unternehmen eine große Herausforderung. Um diesen Wandel bestmöglich zu unterstützen, arbeiten wir am besten mit einem Team von Coaches mit unterschiedlichen Schwerpunkten. Beim Aufbau agiler Rahmenbedingungen und selbstorganisierter Teams helfen Agile Coaches. Sie können ihr Wirken mit Product Coaches und Technical Coaches abstimmen und dadurch eine ganzheitliche Wirkung über die Bereiche hinweg erzielen.</p><ul><li>Agile Coaches begleiten den Aufbau agiler Rahmenbedingungen und selbstorganisierter Teams.</li><li>Product Coaches unterstützen bei der Ausrichtung des Produkts und dem Umgang mit Anforderungen.</li><li>Technical Coaches helfen den Teams bei der praktischen Umsetzung agiler Softwareentwicklung und Architekturfragen.</li></ul><p>Zusammen behält das Coach-Team den Überblick und unterstützt das Management, ihre Strategie im Veränderungsprozess zu verfolgen. Mit dieser breitgefächerten Unterstützung und Beratung helfen wir unseren Kunden bei der Skalierung in allen Bereichen ihres Unternehmens.</p>

Der Weg ist das Ziel: Metriken als Wegweiser statt als Erfolgsmeldung einer agilen Transition

<div><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/07wh7gqbRY2Qmbs7jfyt" alt="Teamwork" width="1280" height="853" /><p>Photo by Ron Lach from Pexels</p></div><h2>Einführung: Coaching in der Transition</h2><p>Veränderungsprozesse sind nicht trivial. Manchmal passiert es, dass man im Unternehmen in der Situation ankommt, wo man aus eigener Kraft und eigenem Know-how nur noch schwer vorwärts kommt. Wenn man diesen Punkt in einem Veränderungsprozess – wir nennen es im folgenden Transition – erreicht, kommt der Einsatz von externen Coaches in Frage.<br /> Für uns ist es dann ein Einstiegspunkt, an dem wir die bestehende Situation deines Unternehmens aus unserer Sicht und Erfahrung bewerten und eine grobe Richtung der Verbesserung identifizieren. Unsere Bewertung ist leichtgewichtig und basiert auf direkten Beobachtungen und einzelnen Analysen. Hypothesenbasiert erarbeiten wir dann gemeinsam mit dir einen iterativen Lösungsweg, den die Mitarbeiter*innen mit unserer Begleitung in die Tat umsetzen. Probleme und deren Lösungen liegen dann meist in mehreren Bereichen des Unternehmens. Um eine deutliche und langfristige Verbesserung der Situation zu erreichen, werden alle Herausforderungen in einem Zusammenhang betrachtet und ein für alle gemeinsames Ziel festgelegt.</p><p><span>Aus unserer Erfahrung hat sich der Einsatz eines eingespielten Teams von Agile Coaches, Technical Coaches und Product Coaches zur Begleitung eines solchen Prozesses bewährt. Die Spieler*innen bringen so die notwendige Expertise in ihren Bereichen mit und können durch ihr gemeinsames Verständnis und Vorgehen effektiv und effizient agieren. Dein Unternehmen kann so eine deutlich größere Veränderung in viel kürzerer Zeit erreichen, als bei alternativen Herangehensweisen.</span></p><h2>Unser Vorgehen beim Transition Coaching</h2><h3>Sponsorship identifizieren und Auftrag klären</h3><p><span>Zu Beginn unseres Einsatzes geht es uns in erster Linie um eine gründliche Auftragsklärung und damit auch um eine Person seitens des Unternehmens, die das Sponsorship übernimmt. Diese Unterstützung und Förderung ist ein wichtiger Erfolgsfaktor. Diese Person muss den gesamten Veränderungsprozess im Unternehmen promoten und verantworten. Sie schafft die notwendige Motivation bei allen Beteiligten, um der Veränderung eine Richtung zu geben und Kurs zu halten. Sie muss nach unserer Erfahrung möglichst weit oben in der Hierarchie verortet sein. Die Befugnisse müssen weit genug reichen, um wichtige Entscheidungen in Bezug auf Prozessänderungen und Personal zu treffen. Wir beobachten oft eine Teilung der Rolle in Sponsor*in und Treiber*in. Wenn die Person sehr weit oben in der Hierarchie ist, dann ist das zeitliche Engagement begrenzt, da er/sie viele andere Dinge neben dem Sponsorship im Blick behalten muss. In dieser Situation benötigen wir dann jemanden, der die Veränderung unternehmensintern treibt, das Vertrauen des/der Sponsors*in genießt und Entscheidungen vorbereitet. Wenn eine entsprechende Entscheidung getroffen wurde, wird er/sie diese Entscheidung in das Unternehmen treiben. Diese Person bindet sowohl uns als Berater*innen als auch die Betroffenen in diese Entscheidungsprozesse partizipativ ein und sorgt für die Umsetzung. So entsteht ein gemeinsames Verständnis und die notwendige Motivation aller Betroffenen für die Veränderung.</span></p><p><span>Hier bietet das Coach-Team dem Unternehmen, Sponsor*in sowie Management mehrere Vorteile. Einerseits gegenüber einer Gruppe einzelner Coaches, da die Kommunikation gebündelt geführt werden kann. Andererseits weil Grundsatzdiskussionen zwischen den Coaches in einem abgestimmten Team nicht nötig sind. Zusätzlich hilft die richtige Mischung an Erfahrung und Expertise des Teams, bessere Entscheidungen zu treffen, und Mitarbeiter*innen besser zu unterstützen.</span></p><h3>Ist-Situation und Zielbild</h3><p><span>Inhaltlich beginnen wir typischerweise mit einer Bestandsaufnahme der Ist-Situation und mit der Priorisierung der wichtigsten Pain Points des Unternehmens. Unsere unterschiedlichen Perspektiven ermöglichen einen Rundumblick der bestehenden Situation in diversen Bereichen eines Unternehmens. Nur so erhalten wir ein gutes Verständnis der Ausgangslage und Wirkzusammenhänge, um Handlungsoptionen zu identifizieren und schrittweise ein Zielbild und eine Strategie für die Transition zu entwickeln. Eine Transition zeichnet sich dadurch aus, dass sie mehrere Bereiche gleichzeitig betrifft. Die Ausgangssituation einer solchen Veränderung gefährdet meistens die Zukunftsfähigkeit eines Unternehmens.</span></p><p><span>Typische Pain Points, denen wir immer wieder begegnen, sind unter anderem:</span></p><ul><li><span>mangelnde Qualität (fehlende Automatisierung, schlechte Testabdeckung, zu viele Bugs, schwer änderbare Architektur, zu hohe Komplexität der Software)</span></li><li><span>nicht eingehaltene Liefertermine und langsame Entwicklungsgeschwindigkeit (durch Störungen im Prozess, zu viele Bugs, fehlenden Gesamtüberblick, fehlende Planung, technisch geschnittene Anforderungen, ungenügendes Anforderungsmanagement)</span></li><li><span>fehlende Ausrichtung am zu schaffenden Wert für das Produkt (viel Output statt echtem Outcome)</span></li><li><span>ungenügendes Management von Abhängigkeiten (zwischen Anforderungen, Teams, Komponenten)</span></li><li><span>schlechte Skalierbarkeit von Software und Organisation (in Architektur, Teamschnitt, Vorgehensmodell)</span></li></ul><p><span>Unser breit gefächertes Know How ermöglicht uns, </span><span>die Ursachen der Pain Points und ihre Wirkzusammenhänge zu verstehen. So kann jede*r seine/ihre Erfahrung und Stärken optimal in die Bewertung der Ist-Situation und mögliche Handlungsoptionen einbringen. Für Bewertung und Handlungsoptionen gibt es allerdings keine Blaupause. Hier ist es wichtig, dass die Erfahrungen und Kenntnisse der Mitarbeiter*innen des Unternehmens in diesen Prozess einfließen.</span></p><h3>Strategie entsteht nicht nur in einem Kopf</h3><p><span>Eine Veränderung dieser Größenordnung bedarf einer Strategie statt Symptombekämpfung und Einzellösungen. Sie ist komplex und wird nicht im stillen Kämmerlein alleine erdacht. Hierzu kombinieren wir im Transition Coaching die Kompetenzen von Agile Coaches, Product Coaches und Technical Coaches. Die Strategie wird auch nicht im Elfenbeinturm erbaut und darf nicht von den realen Problemen der Betroffenen abgehoben sein. In einem direkten Austausch erarbeiten wir mit ihnen erste Ergebnisse und steigen in einen kontinuierlichen und ganzheitlichen Verbesserungsprozess ein.</span></p><p><span>Wir als Coaches ergänzen diesen Prozess. Wir behalten sowohl das Zielbild als auch Prioritäten im Blick, als auch das Verständnis für die operative Umsetzung. Wir können sowohl das Management beraten als auch Hands-On mit den Betroffenen zusammenarbeiten. Strategie und operative Umsetzung sind für uns nicht entkoppelt. Durch ein iteratives und partizipatives Vorgehen kann die Strategie bei veränderten Bedingungen und Prioritäten zeitnah angepasst werden. So wird der Fortschritt transparent und es entstehen keine Brüche in den Feedbackschleifen.  </span></p><h3>Prozesse alleine reichen nicht aus</h3><p><span>Um die nötigen Verbesserungen zu erreichen, genügt es auch nicht, nur Prozesse aufzustellen. Bei schwerwiegenden Problemen und fehlender Expertise der Betroffenen, führen wir meist grundlegende Konzepte in mehreren Bereichen ein, um eine Basis für den anschließenden Verbesserungsprozess zu schaffen. Diese müssen vermittelt und gelebt werden. Hierfür benötigen die Betroffenen Zeit und Begleitung, um nicht bei jeder Störung in ihr altes Verhalten zurückzufallen.</span></p><p><span>Ist dies erfolgreich gelungen, können wir wieder stärker partizipativ arbeiten. Wichtig ist Transparenz zu schaffen, um ein Vorgehen nach Inspect & Adapt zu ermöglichen.</span></p><p><span>Während einer Transition kommt es auch nicht selten zu neuen Rollen, in die sich die Mitarbeiter*innen einleben müssen. Beispiele sind Product Owner, Scrum Master oder Tester*innen als integriertes Teammitglied. Diese Veränderung fällt den betroffenen Personen nicht leicht, da sie in dieser Form noch nie gearbeitet haben und sie diese Umstellung meistens im laufenden Tagesgeschäft zu bewältigen haben. Umso dringender suchen sie dann Unterstützung von erfahrenen Personen, die bei Bedarf direkt vorführen können, wie die neue Arbeitsweise funktioniert. Auch die Definition und das Schärfen der Rollen und Verantwortlichkeiten erfordert eine tiefe Erfahrung im Spezialgebiet der jeweiligen Coaches.</span></p><h3>Zusammenspiel der Coaches</h3><p><span>Ein konkretes Beispiel, das den Einsatz und das Zusammenspiel der verschiedenen Coaches verdeutlicht, ist z.B. das Vorbereiten und Durchführen des ersten Sprints.</span></p><p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/iDusKcgTR6iUfYSqoYch" alt="1. Sprint im Transition Coaching" /></p><p><span>Für einen erfolgreichen Sprint wird der erste Satz an Anforderungen im Backlog überarbeitet, um fachliche Schnitte zu formen und sinnvolle Prioritäten festzulegen. Damit die Product Owner das leisten können, schult und begleitet sie unser Product Coach.</span></p><p><span>Vorher und auch parallel dazu werden strukturelle Veränderungen vorbereitet und durchgeführt. Diese betreffen die Zusammensetzung crossfunktionaler Teams, das Identifizieren und Vorbereiten von Product Ownern oder gar eines Product-Teams, das Identifizieren und Vorbereiten der Scrum Master. Hierzu findet eine kontinuierliche und partizipative Zusammenarbeit unserer Agile Coaches mit Stakeholdern wie dem Management, den Scrum Mastern, Tester*innen und Entwickler*innen usw. statt. Evtl. werden auch alte Rollen aufgelöst und alternative Einsatzmöglichkeiten erarbeitet. </span></p><p><span>Parallel zu den Vorbereitungen der Strukturen und Anforderungen finden auch technische Vorbereitungen statt. Es ist wichtig, dass die Teams die Architektur ihrer Software verstehen und einen Weg zum kontinuierlichen Testen, Integrieren und Ausliefern ihrer Arbeitsergebnisse ausarbeiten. Anhand von funktionalen und nicht funktionalen Anforderungen verstehen sie, wie eine mögliche Zielarchitektur ihrer Software aussehen kann. So können sie später sicherstellen, dass am Ende eines Sprints wertvolle und qualitativ hochwertige Ergebnisse direkt an den Kunden ausgeliefert werden können. Damit die Teams das leisten können, begleiten sie unsere Technical Coaches in kontinuierlicher und iterativer Zusammenarbeit mit anderen Stakeholdern, wie dem Management und den Product Ownern. Bei fehlender Erfahrung im Unternehmen, können unsere Coaches in jedem dieser Themen eine Starthilfe geben.</span></p><h2><span>Eingespieltes Coach-Team</span></h2><p><span>Einzelne Coaches, die alleine oder mit anderen ihnen unbekannten Coaches eine Transition begleiten, haben es eher schwer, ihre Aufmerksamkeit über viele Abteilungen und Betroffene zu koordinieren. Ein eingespieltes Team hat einen ganzheitlichen Blick und stellt sicher, dass alle Aktionen aufeinander abgestimmt sind und zusammen Sinn ergeben. Durch den hohen Abstimmungsgrad und stark reduzierten Koordinationsaufwand ist eine ganzheitliche Transition mit hoher Umsetzungsgeschwindigkeit möglich.</span></p><h3>Gute Entscheidungen und Stabilität durch gegenseitige Impulse</h3><p><span>Da wir in der realen Welt unterwegs sind, kommt es bei der Umsetzung immer wieder zu komplett neuen Situationen und Herausforderungen, mit denen man nicht gerechnet hat. Ein*e auf sich allein gestellte*r Coach kann hier ins Straucheln geraten. In diesen Fällen kommt die breit gestreute Expertise in unserem Team allen Beteiligten zugute. So geben wir uns immer wieder gegenseitig wertvolle Impulse für Lösungen. Zudem hat jede*r von uns während des Engagements jemanden zum Sparring oder Austausch. Und der Input der Kolleg*innen ermöglicht das Erweitern des eigenen Horizonts. Bei Rückschlägen im Projekt motivieren wir uns wieder gegenseitig zu neuem Schwung, wovon am Ende auch unsere Kund*innen profitieren. Dem/Der einzelnen Coach fällt diese Motivation sehr viel schwerer. Der Energieaufwand, den jede*r von uns erbringen muss, wird hierdurch deutlich reduziert.</span></p><h3>Motivation trotz Widerstände</h3><p><span>Bei Transitionen und den daraus resultierenden umfassenden Veränderungen spielt der Faktor Mensch eine wichtige Rolle. Eine Veränderung kann ein*e Coach nicht erzwingen, dazu ist die Motivation der Betroffenen nötig, welche im Laufe der Begleitung unbedingt gefördert werden sollte. Stößt ein*e Coach auf Widerstände von Betroffenen, kann die Überwindung dieser Widerstände sehr nervenaufreibend und manchmal sogar unmöglich sein. Unsere Diversität erhöht die Chancen, dass immer eine*r zu den Betroffenen durchdringen und sie weiter motivieren und bewegen kann. </span></p><h3>Distanz bewahren</h3><p><span>Einem/einer einzelnen Coach fällt es schwer, strategische und operative Aspekte gleichermaßen im Blick zu behalten. Es droht die Gefahr, sich zu sehr mit den Betroffenen und deren Problemen zu identifizieren. Gibt er/sie dem Wunsch nach Zugehörigkeit nach, führt dies häufig zu operativer Beteiligung. Bei uns gehört es zur täglichen Routine, uns gegenseitig diese Gefahren zu spiegeln, um die nötige Distanz nicht zu verlieren.</span></p><p><span>Unterschätzen Coaches diese Gefahren, gefährden sie ihre Wirksamkeit und verlassen die Neutralität zu allen Beteiligten. Lösungen mit allen Betroffenen werden schwer. Der/Die Coach wird parteiisch.</span></p><h2>Fazit</h2><p><span>Die Situation, die dein Unternehmen zu einer Transition zwingt, ist teuer und gefährdet die Zukunftsfähigkeit des Unternehmens teilweise oder ganz. Die Kosten die entstehen, wenn diese Situation nicht nachhaltig überwunden werden kann, sind meistens höher als die Kosten für ein Engagement unseres Teams. Es ist wichtig, dass die Transition nicht stecken bleibt. Je schneller wir gemeinsam die Transition vorantreiben, desto früher bist du wieder in der Lage, wertschöpfende Dinge zu tun, statt in einem Labyrinth von Pain Points festzustecken. Deshalb ist es wichtig, kontinuierlich und zielgerichtet in kleinen parallelen Schritten voran zu kommen.</span></p><p><span>Als Coach-Team sind wir eingespielt, haben ein gemeinsames Vorgehen, können schnell ein gemeinsames Verständnis der Situation herstellen und müssen die Teamuhr (siehe auch </span><a href="/wissens-hub/blog/tuckmans-4-phasenmodell" target="_blank"><span>Tuckmans Phasenmodell </span></a> <span>) nicht mehr durchlaufen. Durch einen schnellen und leichtgewichtigen Austausch und gegenseitige Ergänzung arbeiten wir sehr effektiv und halten den Veränderungsprozess ohne große Umwege auf Kurs.</span></p><p><span>Unsere Stärke und Wirksamkeit liegt in unseren unterschiedlichen Schwerpunkten und Expertisen. Besonders der Austausch zwischen uns Coaches, die gegenseitige Ergänzung des Know Hows und die abgestimmte Veränderung unterschiedlicher Bereiche, ermöglichen eine optimale und vor allem ganzheitliche Begleitung aller Beteiligter.</span></p><p><span>Wir freuen uns darauf, mit dir über deine Situation zu sprechen. Kontaktiere uns gerne:<br /> <a href="mailto:anja.frank@codecentric.de">anja.frank@codecentric.de</a> <br /> <a href="mailto:irina.froese@codecentric.de">irina.froese@codecentric.de</a> <br /> <a href="mailto:thomas.schnoege@codecentric.de">thomas.schnoege@codecentric.de</a> </span></p><p> </p><h2>Ergänzende Blogeinträge</h2><ul><li><a href="/wissens-hub/blog/qualitaetsprobleme-qualitaet-teamwork" target="_blank"><span>Qualität ist Teamwork</span></a> <span><br /> </span></li><li><a href="/wissens-hub/blog/metriken-wegweiser-statt-erfolgsmeldung-transition" target="_blank"><span>Der Weg ist das Ziel: Metriken als Wegweiser statt als Erfolgsmeldung einer agilen Transition</span></a> <span><br /> </span></li><li><a href="/wissens-hub/blog/backlog-ueberfuellt-ein-produkt-ist-mehr-als-die-summe-seiner-funktionalitaeten" target="_blank"><span>Backlog überfüllt? Ein Produkt ist mehr als die Summe seiner Funktionalitäten</span></a> <span><br /> </span></li></ul>

Transition Coaching – Warum sich der Einsatz eines eingespielten Coach-Teams lohnen kann

Agile Coach

<p>(feature image by <a href="https://unsplash.com/@0asa?utm_medium=referral&utm_campaign=photographer-credit&utm_content=creditBadge" target="_blank"><span>unsplash-logo</span><span>Vincent Botta</span></a> )</p><h2>Motivation</h2><p>Sometimes you just need a simple database and also the ability to have a really simple way to edit the data in a quick and straightforward way, without compromising on integrity or accountability. This is where Google Sheets offers a totally valid solution!</p><p>Google Sheets provides us with an already familiar interface to create, edit, and view all our data in columns. We can search, order, and even do bulk operations. Also, Google provides an API to use these sheets in a programmatic way, which we are going to use for this article.</p><h3>Create the database</h3><p>First, you need to create a new spreadsheet. I trust you know how to do that. Then create your first table (aka worksheet) and a couple of columns. In my example, I created a recipes table with columns for a unique identifier (id), the name, a description (desc), and two date fields (createdAt, updatedAt).</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1QZshJwuSSGCsBNapH53" target="_blank"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1QZshJwuSSGCsBNapH53" alt="Google sheet example" width="250" height="100" /></a> <p>Sheet setup</p></div><p>The two date fields should be auto-filled by our “database”. So how are we going to do that? Simple: We attach a script to our spreadsheet. Goto <code>Tools -> Script Editor</code> and this will open a new window with an empty script.</p><div>

```javascript
function onEdit(e) {
  const columns = e.source
    .getActiveSheet()
    .getRange('1:1')
    .getValues()[0];
 
  const createdIdx = columns.indexOf('createdAt');
  const updatedIdx = columns.indexOf('updatedAt');
 
  const isNewRow = !e.source
    .getActiveSheet()
    .getRange(e.range.getRow(), createdIdx + 1)
    .getValue();
 
  if (createdIdx >= 0 && isNewRow) {
    e.source
      .getActiveSheet()
      .getRange(e.range.getRow(), createdIdx + 1)
      .setValue(new Date().toISOString());
  }
 
  if (updatedIdx >= 0) {
    e.source
      .getActiveSheet()
      .getRange(e.range.getRow(), updatedIdx + 1)
      .setValue(new Date().toISOString());
  }
}
```

</div><p><code>onEdit</code> is a callback that is invoked every time a cell was edited by a user. You can read about <a href="https://developers.google.com/apps-script/guides/triggers/#onedit" target="_blank">onEdit</a>  and <a href="https://developers.google.com/apps-script/guides/triggers/events" target="_blank">the event argument</a>  in Googles API documentation.</p><p>In the script above, we first check if the respective date column exists, then for <code>createdAt</code> we have to check if it is filled already. If not populate the field with the current date. <code>updatedAt</code> will be filled with the current timestamp after every edit made to the row by a user.</p><p>Now we have our very basic database table set up and ready to be accessed by an application.</p><h2>Creating the API</h2><p>We are going to implement the database API in Node.js. Google provides a library to communicate with its APIs called <code>googleapis</code> which is available as a npm module. Go and create a new project and install this library. Also, we are going to use typescript because we are not cavemen, and LokiJS as an in-memory database so we don’t have to constantly call the spreadsheet API.</p><div>

```bash
$> mkdir sheet-api
$> cd sheet-api
$> yarn init
question name (sheet-api):
...
$> yarn add googleapis google-auth-library \
    typescript lokijs \
    @types/node @types/lokijs
[1/4] ?  Resolving packages...
...
✨  Done in 13.37s.
```

</div><h3>Service account</h3><p>Now to connect to our database we need to authenticate with the Google API. To do this we will create a service account. Navigate to the <a href="https://console.cloud.google.com/iam-admin/serviceaccounts" target="_blank">Google Cloud Platform Console</a>  <code>IAM & admin -> Service accounts</code>. You should have a GCP project based on the sheet scripts we created earlier. If not create a new project. Create a new service account (I named mine <code>sheet-bot</code>), you don’t need to assign any roles, but do need to create a key. Choose JSON as the option for this key, and it should download you a credentials file containing all information needed to authenticate as this service account in our next steps. Save this file to your project folder as <code>sheet-api/credentials.json</code>. Also save the email address of the service account, because we are going to need it later.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jnmfHlQoS5WTpD0YKhBj" target="_blank"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jnmfHlQoS5WTpD0YKhBj" alt="google cloud platform service account overview" width="250" height="125" /></a> <p>GCP service account</p></div><h3>Authentification</h3><p>To make use of our newly created service account, we are going to use <code>google-auth-library</code>s utils to create a JWT and authorize our script. We will encapsulate this as a function in <code>api/auth.ts</code>:</p><div>

```javascript
import { readFile } from 'fs';
import { resolve } from 'path';
import { promisify } from 'util';
import { JWT } from 'google-auth-library';
 
const promisedFile = promisify(readFile);
 
export async function auth() {
  const credentials = JSON.parse(
    await promisedFile(resolve(__dirname, '../credentials.json'), 'utf-8'),
  );
  const client = new JWT({
    email: credentials.client_email,
    key: credentials.private_key,
    scopes: ['https://www.googleapis.com/auth/spreadsheets'],
  });
  await client.authorize();
  return client;
}
```

</div><h3>Accessing the sheet</h3><p>We will wrap the <code>googleapis</code> methods to operate on sheets with a helper function. First, because we don’t need all the functionality the sheet-API provides, and second we can slap some typings onto this and provide some level of confidence when we later deal with the data coming from and into the sheets.</p><div>

```javascript
import { google } from 'googleapis';
import { auth } from './auth';
 
const sheetsApi = google.sheets({ version: 'v4' });
 
export async function readSheet(
  spreadsheetId: string,
  range: string,
  firstRowAsKeys?: true,
): Promise<T[]>;
export async function readSheet(
  spreadsheetId: string,
  range: string,
  firstRowAsKeys: boolean = true,
): Promise<T[] | string[][]>; {
  const {
    data: {
      values: [keys, ...values],
    },
  } = await sheetsApi.spreadsheets.values.get({
    auth: await auth(),
    spreadsheetId,
    range,
    valueRenderOption: 'UNFORMATTED_VALUE',
  });
  return firstRowAsKeys
    ? values.map(columns =>
        keys.reduce(
          (acc, key, idx) => ({
            ...acc,
            [key]: columns[idx],
          }),
          {} as T,
        ),
      )
    : [keys, ...values];
}
```

</div><p>The code itself is pretty straightforward: we await the data with the use of our auth-helper detailed above. Then we parse the sheet data, which comes in a two-dimensional array. If we want to treat the first row as keys we are going to create an array of objects, where the properties are the mapped columns of each row. Take note at the <code>valueRenderOption: 'UNFORMATTED_VALUE'</code>, this ensures that data, that is formatted in a special way (e.g. currencies) arrives as a raw value in our application (e.g. without the currency sign).</p><p>One last thing to do is to add the service account to our database sheet as a collaborator so it can access the sheet. Goto the sheet and click the button <code>Share</code> in the top-right corner. Here you just have to paste the email you saved earlier and add it with read/write access.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Nm4InIxzTcKr430OdoIa" target="_blank"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Nm4InIxzTcKr430OdoIa" alt="Google sheets share settings" width="250" height="276" /></a> <p>Google sheet share settings</p></div><h2>Creating a consumer</h2><p>Now that we have our basic API wrapper finished, we can start creating our business model.</p><div>

```javascript
export type Recipe = {
  id: string;
  name: string;
  desc: string;
  createdAt: string;
  updatedAt: string;
};
```

</div><p>This is just our DTO with all columns/properties we created in our sheet.</p><div>

```javascript
import * as Loki from 'lokijs';
import { readSheet } from '../api/sheets';
import { Recipe } from './Recipe';
 
const sheetId = '1o0VAQ4f2QafBjLUd53yCWEtdwKonu5wPM33CttxBTXI';
const sheetRange = 'Recipes!A:E';
 
const db = new Loki('recipes.json');
const collection = db.addCollection('recipes', { indices: ['id'] });
 
export async function setup() {
  const data = await readSheet(sheetId, sheetRange);
  collection.insert(data);
}
 
export async function refresh() {
  const data = await readSheet(sheetId, sheetRange);
  const ids = data.map(d => d.id);
  collection.findAndUpdate(
    obj =>
      ids.includes(obj.id) &&
      new Date(data.find(d => d.id === obj.id).updatedAt).getTime() >
        new Date(obj.updatedAt).getTime(),
    obj => Object.assign(obj, data.find(d => d.id === obj.id)),
  );
  collection.findAndRemove({ id: { $not: { $in: ids } } });
  collection.insert(data.filter(d => !collection.findOne({ id: d.id })));
}
 
export { collection };
```

</div><p>As mentioned above, we are going to utilize LokiJS as an in-memory database to provide some basic things that come in handy (query, sorting, indices etc), so we don’t have to make that many API calls to query our sheet.</p><p>We are going to load all data in our sheet into memory on setup. This should be fine for every use case where Google Sheets is a viable option (hint: if you have more data than memory can reasonably hold, use a real database), you could even modify the setup to load the database in a build step and never query Google API for data in production setups. This is what I did at a company I worked for btw.</p><p>Next, we have a <code>refresh</code> function that will update our in-memory database to the current state of the sheet (insert, update, and remove entities).</p><p>And lastly we export the collection to further use in our application:</p><div>

```javascript
import { createServer } from 'http';
import { collection, setup, refresh } from './store/recipes';
 
const port = +process.env.PORT || 8000;
 
setup().then(() => {
  createServer(async (req, res) => {
    try {
      const data = collection.find();
      res.statusCode = 200;
      res.end(JSON.stringify(data), 'utf8');
    } catch (err) {
      res.statusCode = 500;
      res.end(JSON.stringify(err));
    }
  }).listen(port, () => {
    console.log(`?  Server listening on port ${port}!`);
 
    setInterval(refresh, 30000);
  });
});
```

</div><p>This code starts a basic HTTP server that will serve all our recipes as a JSON array, and update with new data every 30 seconds.</p><h2>Conclusion</h2><p>Google Sheets provides an easy-to-set-up and -manage way to fill some very basic database needs. You can automate scripts in the sheet to emulate calculated fields or validity checks when edits are made. Combined with an in-memory database, we can achieve reasonable performance, especially if we look into the costs (basically zero).</p><p>Like I mentioned above, I did implement this database in a company I worked for. We had a catalog of cities, airports, and countries, plus some relations (an airport belongs to a city etc.), which I validated on change with scripts and fancy drop-down menus. The benefit was that even non-technical personnel could easily access this data and make modifications (tag airports or cities, check boxes for cities that should / should not appear in certain features etc.) without coding a complex UI or buying third party software. We then bundled all data in a build step and ran some basic verification. All in all, it worked seamlessly.</p><h3>Source</h3><p>The complete project can be found on GitHub: <a href="https://github.com/codecentric/example-google-sheet-as-database" target="_blank">https://github.com/codecentric/example-google-sheet-as-database</a> </p>

Using Google Sheets as database

Senior Software Engineer

IT Consultant

Head of Berlin, Erfurt, Hamburg, Leipzig, Münster

IT Delivery Manager

<p>Von Continuous Integration kommen wir über Continuous Delivery zu Continuous Deployment. Codeänderungen und neue Features werden quasi sofort und automatisch in Produktion gebracht. Release Management und Continuous Deployment scheint sich auf den ersten Blick zu widersprechen.</p><p>Anders gefragt: Was hat Release Management mit Continuous Deployment zu tun? Kommt das eine aus der alten Welt, das andere aus der Neuen? Ist Release Management etwas für Manager und Continuous Deployment für Techniker? Wachsen beide Begriff im Zuge von DevOps zusammen? Oder wird Release Management mit Continuous Deployment überflüssig?<br /> <span><br /> Die Einführung von Continuous Integration (CI) dient vor allem dazu, den Entwicklern schnelleres Feedback zu ihren Änderungen zu liefern. CI ist die Voraussetzung für <a href="https://en.wikipedia.org/wiki/Continuous_delivery" target="_blank">Continuous Delivery</a> , bei dem jede Änderung zu einer auslieferungsfähigen Software führt. Wird jeder Build automatisch bis zur Produktion ausgeliefert sprechen wir von <a href="https://en.wikipedia.org/wiki/Continuous_delivery#Relationship_to_Continuous_Deployment" target="_blank">Continuous Deployment</a> .</span></p><h2>Was ist Release Management?</h2><p>Fangen wir mit einer Definition von Release Management an.</p><blockquote><p><a href="https://en.wikipedia.org/wiki/Release_management" target="_blank">Release management</a>  is the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases.</p></blockquote><p>Im klassischen Sinn besteht Release Management aus allem, was für den Lebenszyklus eines Release notwendig ist. Es fängt also an bei der Definition und Planung, geht über die Entwicklung und Qualitätssicherung und endet nach dem Deployment bei der Wartung. Deployment und Release treten in etwa gleich häufig auf, und das ist kein Zufall. Denn „Release“ bedeutet Freigabe, Freigabe in Produktion. Und wenn nicht ohnehin gleich auf Produktion gefixt wird, unterliegen in der klassischen Welt die Releases (auch von Bugfixes) einer z.T. aufwendigen Freigabeprozedur, inklusive der Sammlung von Unterschriften von Abnahmeberechtigten.</p><p>Womit wir beim Ziel vom Release Management wären: Im Weitesten Sinne sollen die Schritte für die Erstellung eines Release formalisiert werden, so dass ein Release planbar und kontrollierbar wird und auf der Zielumgebung ein klar definierter Stand vorhanden ist. ITIL sagt dazu:</p><blockquote><p><a href="http://wiki.de.it-processmaps.com/index.php/Release_und_Deployment_Management" target="_blank">ITIL Release & Deployment Management</a>  ist verantwortlich dafür, zu planen, festzulegen und zu kontrollieren, wie ein Release getestet und in die Live-Umgebung ausgerollt wird. Das primäre Ziel von Release Management und Deployment Management besteht darin, sicherzustellen, dass die Integrität der Live-Umgebung geschützt wird und dass nur zuvor geprüfte Komponenten ausgerollt werden.</p></blockquote><p>Das Erzeugen eines Release ist mit einem gewissen Aufwand verbunden und kostet Zeit. Je agiler man wird, desto häufiger versucht man, neue Versionen freizugeben. Die Frequenz für neue Features wird erhöht. Während früher neue Versionen oder Features beispielsweise quartalsweise released wurden, dauern Sprints nun nur noch ein bis zwei Wochen. Daher benötigt man in agilen Projekten eine andere Planung von Releases, die weniger zeitaufwendig ist.</p><blockquote><p><a href="http://www.scrum-institute.org/Release_Planning.php" target="_blank">Scrum Release Planing:</a>  A very high-level plan for multiple Sprints (e.g. three to twelve iteration) is created during the Release planning. It is a guideline that reflects expectations about which features will be implemented and when they are completed. It also serves as a base to monitor progress within the project. Releases can be intermediate deliveries done during the project or the final delivery at the end.</p></blockquote><p>Während z.B. in Scrum jeder Sprint eine lauffähige Software abliefert, markieren Releases jetzt eher eine logische (oder eine aus Sicht des Marketing oder Projektmanagements sinnvolle) Aggregation von Features.</p><h2>Einfluss von Continuous Delivery und Continuous Deployment</h2><p>Über den Zwischenschritt Continuous Integration, bei dem über schnelle Build- und Testzyklen den Entwicklern schnelles Feedback geliefert werden soll, kommen wir über Continuous Delivery zu Continuous Deployment. Durch das schnellere Ausliefern wird nicht nur die Liegezeit der eigentlich fertig entwickelten Features reduziert und damit der eigentliche Geschäftswert der Features genutzt. Auch ermöglicht Continuous Delivery und Continuous Deployment einen effizienteren <a href="http://www.it-agile.de/wissen/methoden/lean-startup/" target="_blank">Build-Measure-Learn-Zyklus</a> , weil viel schneller und zielgerichteter der Wert einzelner Änderungen getestet und bewertet werden kann.</p><p>Redet man über Continuous Deployment können im Extremfall die Begriffe „Release“ und „Deployment“ verschwimmen, weil bis zu mehrfach täglich auf die Produktionsumgebung deployed wird (z.B. <a href="http://engineering.skybettingandgaming.com/2016/02/02/how-we-release-so-frequently/" target="_blank">how-we-release-so-frequently</a> ). Differenziert man ein Deployment von einem Release, macht es beispielsweise Sinn ein Deployment als einen technischen Vorgang zu betrachten, der regelmäßig auftritt (ein „non-event“); ein Release hingegen ist ein logisches Konstrukt, nämlich eine Sammlung an Features, und sollte geplant sein. Zum Release gehört u.U. ein Wechsel einer Versionsnummer und eine Definition der enthaltenen Funktionalitäten. Um trotz der vielen Codeänderungen auch unvollständige Features deployen zu können oder gleichzeitig verschiedene Features unabhängig voneinander A/B-Testen zu können, bieten sich <a href="http://www.heise.de/developer/artikel/Continuous-Delivery-mit-dem-FeatureToggle-Pattern-1825477.html" target="_blank">Feature Toggles</a>  an – aber das ist ein anderes Thema.</p><p>Wie ändert sich demnach Release Management beim Übergang zu Agilität und Continuous Deployment?</p><p>In klassischen Release-Zyklen mit eher seltenen Releases können in den verschiedenen Phasen folgende Aufgaben anfallen (natürlich dient die Tabelle nur als vereinfachtes Beispiel, insbesondere verdient ein ausführlicher Rollout-Plan eine intensivere Betrachtung):</p><table><tbody><tr><td><strong>Planung</strong></td></tr><tr><td>Definiere Features</td></tr><tr><td>Definiere Rollout Timeline</td></tr><tr><td>Definiere zu messende Ergebnisse</td></tr><tr><td>Plane Wochenende für Rollout</td></tr><tr><td><strong>Implementierung</strong></td></tr><tr><td>Support guidelines</td></tr><tr><td>Operating Anweisungen</td></tr><tr><td>Migrationsprogramme</td></tr><tr><td>Rollout-Planung</td></tr><tr><td><strong>QA</strong></td></tr><tr><td>Test-Rollout</td></tr><tr><td>Training Operations & Support</td></tr><tr><td><strong>Rollout</strong></td></tr><tr><td>Ausführung Rollout plan</td></tr><tr><td>Absprache Go-Live oder Rollback</td></tr><tr><td><strong>Live</strong></td></tr><tr><td>Stabilisierung</td></tr><tr><td>Messen und Auswertung der Erfolgskriterien</td></tr></tbody></table><p>Tatsächlich besteht ein großer Teil der Arbeit darin, die Unterschiede zwischen der alten und neuen Version festzustellen, die Migration vorzubereiten, das Rollout durchzuführen und den späteren Betrieb sicher zu stellen. Je nach Unternehmen, Produkt und Aufwand kann alleine die Planung und Durchführung für den Releasewechsel Wochen voller Arbeit und seitenweise Planungsdokumente ergeben. Während des Releasewechsels (häufig auch Rollout-Wochenende genannt) sind alle Beteiligten auf Bereitschaft, um auf Benachrichtigung ihre Schritte des Rollouts durchzuführen. Schließlich sind unterschiedliche Teams für z.B. Datenbank, Applicationserver, Konfiguration oder Infrastruktur verantwortlich. Die anschließenden Tage oder Wochen sind vorgesehen, um das neue Release zu stabilisieren, häufig mit einem enormen Aufwand an Überstunden (The Manager’s Guide to Continuous Delivery, Andrew Philips et al, 2014 Xebia B.V.).</p><p>Beim Wechsel zu agilen Methoden und Continuous Deployment werden die Inkremente kleiner, so dass dieser Aufwand für jedes Release nicht mehr betrieben werden kann und soll. Vermieden wird das zum einen durch Automation im Deploymentprozess, wodurch auch das Risiko für Fehlschläge minimiert wird, als auch durch die laufenden Anpassungen an Operating (Stichwort DevOps) und Support. Die folgende Tabelle zeigt, in welcher Form bzw. welchen Phasen der agilen Softwareentwicklung dieselben Aufgaben ausgeführt werden:</p><table><tbody><tr><td><strong>Planung</strong></td><td></td></tr><tr><td>Definiere Features</td><td>Sprint-Planung/Release-Planung</td></tr><tr><td>Definiere Rollout Timeline</td><td>Sprint-Planung/Release-Planung</td></tr><tr><td>Definiere zu messende Ergebnisse</td><td>Sprint-Planung/Release-Planung</td></tr><tr><td>Plane Wochenende für Rollout</td><td>Entfällt</td></tr><tr><td><strong>Implementierung</strong></td><td></td></tr><tr><td>Support guidelines</td><td>Laufend</td></tr><tr><td>Operating Anweisungen</td><td>Laufend</td></tr><tr><td>Migrationsprogramme</td><td>Laufend</td></tr><tr><td>Rollout-Planung</td><td>Laufend</td></tr><tr><td><strong>QA</strong></td><td></td></tr><tr><td>Test-Rollout</td><td>Laufend auf alle Umgebungen</td></tr><tr><td>Training Operations & Support</td><td>Laufend</td></tr><tr><td><strong>Rollout</strong></td><td></td></tr><tr><td>Ausführung Rollout plan</td><td>Automatisiert auf alle Umgebungen</td></tr><tr><td>Absprache Go-Live oder Rollback</td><td>Entfällt</td></tr><tr><td><strong>Live</strong></td><td></td></tr><tr><td>Stabilisierung</td><td>Entfällt</td></tr><tr><td>Messen und Auswertung der Erfolgskriterien</td><td>Sprint-/Release-Review</td></tr></tbody></table><p>Aus dieser Darstellung der anfallenden Aufgaben lassen sich positive Ergebnisse herauslesen: Da viele formale Schritte komplett entfallen, können sich die Beteiligten auf ihre eigentlichen, Mehrwert-schaffenden Aufgaben konzentrieren. Management bzw. Product Owner plant und überprüft die zu entwickelnden Features, die Entwicklungsteams und Operating sorgen für die Implementierung, Bereitstellung und Funktionsfähigkeit.</p><p>Während die zu entwickelnden Features in der Sprint-Planung durch den Product Owner (Scrum) vorgegeben werden und dieser ebenso verantwortlich ist, die zu messenden geschäftsrelevanten Erfolgskriterien festzulegen und im Nachhinein zu überprüfen, liegen alle anderen Schritte in der Verantwortung der Entwickler: Zur Entwicklung eines Features und der „Definition of Done“ gehört eben nicht nur der getestete Code, sondern auch die Ressourcen, um das Feature automatisch deployen zu können. Dazu können Datenbankscripte, Shellscripte, Dockerimages oder Einstellungen im Build- oder Deploymenttool gehören (wie z.B. in <a href="http://jenkins-ci.org/" target="_blank">Jenkins</a>  oder <a href="https://xebialabs.com/products/xl-deploy/" target="_blank">XL Deploy</a> ).</p><h2>Zusammenfassung</h2><p>Das Einführen von agilen Methoden mit kürzen Release-Zyklen ist nicht nur vorteilhaft ist, um die Qualität der Software zu erhöhen indem Entwickler schnelleres Feedback bekommen. Durch häufigere Releases wird zwangsläufig die Automation und dadurch die Qualität erhöht, Aufwand und Risiko dafür gesenkt. Dadurch wird Release Management nicht unnötig, sondern konzentriert sich auf die Mehrwert-liefernden Aufgaben: Die benötigten Features zu planen und über den Build-Measure-Learn-Zyklus auszuwerten. Zudem kann man sehen, dass Continuous Deployment nicht nur auf technischer Ebene stattfindet, sondern den gesamten Software-Lifecycle und die Unternehmenskultur beeinflusst, in dem es die verschiedenen Rollen enger zusammenarbeiten lässt.</p>

Continuous Deployment und Release Management – ein Widerspruch?

<p>Mule bietet mit MUnit ein Framework, mit dem sehr ähnlich zu den normalen Flows Tests geschrieben werden können. Ob es sich dabei um Unit- oder Integrationstests handelt, hängt von der Implementierung und der Benennung ab. Denn mithilfe von Maven lassen sich Tests abhängig vom Namen filtern.</p><p>Das Vorgehen in Munit-Tests ist grundsätzlich vergleichbar mit „konventioneller“ Softwareentwicklung und die Prinzipien sind dieselben. Tests sind so strukturiert, dass es</p><ol><li>ein Setup gibt (pro Suite oder pro Test),</li><li>die Message für den Testaufruf vorbereitet wird,</li><li>der Testflow aufgerufen wird (flow under Test)</li><li>und anschließend das Ergebnis verglichen wird (assert).</li></ol><p>Viele Flows in Mule benötigen externe Services (z.B. Datenbanken, Messaging-Systeme), um Daten abzurufen oder zu aktualisieren. In diesem Artikel beschränken wir uns zunächst auf Datenbanken, konkret auf die relationalen. Insbesondere stelle ich verschiedene Möglichkeiten vor, Datenbanken in Mule zu mocken.</p><p>Der vollständige Code für die gesamte Artikelserie liegt in <a href="https://gitlab.codecentric.de/christian.langmann/munit-db-testcontainer" target="_blank">gitlab</a> .</p><h2>Scenario-Beschreibung</h2><p>Die Anwendung, die als Beispiel dienen soll, ist ziemlich einfach. Sie bietet einen REST-Service an, bei dem User abgefragt werden können. Der entsprechende Ausschnitt der Raml-Definition erlaubt das Abfragen einer Liste von allen oder eines einzelnen Users:</p><div>

```yaml
/users/{id}:
  get:
    responses:
      200:
        body:
          application/json:
            example: |
            {
               "id": "1234",
               "name": "Doe",
               "firstname": "John",
               "user": "jdoe"
            }
      404:
```

</div><p>Ich nehme an, dass in der Produktion eine Postgres-DB eingesetzt wird, sagen wir in der Version 10.6, aber zunächst spielt das eine untergeordnete Rolle. In der Datenbank gibt es ein einfaches Schema „mule“ mit einer Tabelle „users“:</p><div>

```postgresql
CREATE TABLE public.users(
    username character varying NOT NULL,
    lastname character varying NOT NULL,
    firstname character varying,
    id bigint NOT NULL DEFAULT nextval('users_id_seq'::regclass)
);
```

</div><p>Die eigentliche Implementierung (ich überspringe den Teil, in dem mit dem APIKit der Rumpf der Anwendung gebaut wird) ist ebenfalls sehr einfach: Um einen bestimmten User zu finden, wird eine entsprechende SQL-Query verwendet – mit der id des Users als Parameter. Anschließend wird mit Validate geprüft, ob auch ein User gefunden wurde und wenn ja, der User nach JSON konvertiert. Falls der User nicht gefunden wird (der „Is not empty“ Validator schlägt an) wird eine <code>org.mule.module.apikit.exception.NotFoundException</code> geworfen, die vom APIKit-Rumpf gefangen und in einen HTTP 404-Status umgewandelt wird:</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/x6XrpvDlQc2fZQs9PYdL"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/x6XrpvDlQc2fZQs9PYdL" alt="Flow get_users_id" width="374" height="126" /></a> <p>Flow für GET /users/{id}</p></div><p>Soweit, so gut. Diese Anwendung soll nun getestet werden. Der Einfachheit halber werden wir hier nur diesen Flow testen, nicht die drumherum aufrufenden APIKit-Flows (ich beschränke mich also auf die Teile, die ich üblicherweise mit Unit-Tests abdecke).</p><p>Die Hauptfrage, die in diesem Artikel gestellt wird, ist: Wie gehe ich mit dem Datenbank-Zugriff um? Es gibt mehrere Ansätze dafür:</p><ol><li>Mocken der Datenbank,</li><li>Benutzen einer Mock-Datenbank (häufig eine In-Memory-H2-Datenbank)</li><li>Tests laufen gegen eine echte Datenbank, die mit den Tests gestartet wird (Container)</li><li>Testen gegen die Produktions-Datenbank (ok, Scherz)<br /> Testen gegen eine produktionsähnliche Datenbank, die in einer dedizierten Testinfrastruktur bereitgestellt wird.</li></ol><p>Im Prinzip entsprechen diese Optionen den üblichen Arten von Tests:</p><ol><li>Unit-Tests</li><li>Unit-/Modultests</li><li>Integrationstests</li><li>End-2-End und Acceptancetests</li></ol><p>Natürlich ist der beschriebene Anwendungsfall trivial. Das erlaubt mir aber, diese Optionen auch anhand eines übersichtlichen Flows zu demonstrieren, so dass ich keine Unterscheidung zwischen der Testarten mache. In realen Umgebungen, wenn die Flows komplexere Logik enthalten oder die Aufrufhierarchie komplexer wird, werden die Testtypen dann auch wegen unterschiedlichen Intentionen und Laufzeiten unterschieden und implementiert.</p><h2>Unit-Tests mit gemockten Datenbanken</h2><p>Überlegen wir zunächst, welche Funktionen eigentich getestet werden müssen:</p><ul><li>Es gibt den „Happy-Path“, der den User findet und als JSON in der Payload zurück liefert.</li><li>Dann gibt es einen Ablauf, in dem kein User gefunden wird (wir erwarten eine entsprechende Exception).</li><li>Und dann kann es passieren, dass aus der Datenbank eine Exception geworfen wird, weil die Verbindung abbricht, keine Berechtigung vorhanden oder das SQL-Statement fehlerhaft ist.</li></ul><p>Den technischen Fehlerfall ignorieren wir an dieser Stelle – er ist, vergleichbar zum zweiten Fall, mit einer erwarteten Exception zu implementieren.</p><p>Die Unit-Tests in Mule werden mit MUnit implementiert. Dazu haben Kollegen bereits einige gute Artikel geschrieben (z.B. die Artikelserie <a href="/wissens-hub/blog/mule-munit-anypoint-studio" target="_blank">Mule-Anwendungen mit MUnit testen</a> ).</p><p>In der Übersicht sehen die Testfälle wie in den folgenden Bildern aus. Grundsätzlich ist die Struktur ähnlich wie bei Unit-Tests in herkömmlichen Sprachen: Ein Setup (ggf. ein Before-Suite/Before-Test) dient der Definition der Mocks (und Spies), dann werden die Eingangsdaten definiert, der Flow-under-Test aufgerufen und anschliessend das Ergebnis geprüft:</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6TpfiCmRJSxyAiMfU2Ag"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6TpfiCmRJSxyAiMfU2Ag" alt="test-flows" width="345" height="540" /></a> <p>Test-Flowsfür user-found und user-not-found</p></div><p>In einem ersten Schritt betrachten wir das Mocking der Datenbank, d.h. wir kappen die Verbindung zum Konnektor und tun nur so, als ob eine Datenbank vorhanden wäre:</p><div>

```xml
<mock:when ... messageProcessor=".*:.*">
    <mock:with-attributes>
        <mock:with-attribute name="doc:name" whereValue="#['Lookup user by id']"/>
    </mock:with-attributes>
    <mock:then-return ...>
</mock:when>
```

</div><p>Dies ist die Struktur der Mocking-Definition, die im Setup des Tests verwendet wird. Die Kombination aus mock:when mit dem Ausdruck im messageProcessor und den Attributen in with-attribute bestimmt den Prozess-Schritt, der gemockt werden soll. In diesem Beispiel wird lediglich der Name des Schritts zur Identifikation verwendet. In den allermeisten Fällen ist das ausreichend, da die Schritte (gerade bei kurzen Flows) eindeutig sein sollten. Ist das nicht der Fall, können weitere Bedingungen oder eine genauere Bestimmung des Message-Prozessors verwendet werden (für DB-Selects z.B. „db:select“). Das wäre auch hier eine Alternative zur Selektion mit dem Attribut, da es nur einen DB-Select in diesem Flow gibt. Ein Vorteil wäre sogar, dass der Test auch ohne Anpassung funktioniert, wenn der Schritt „Lookup user by id“ im Flow-under-Test umbenannt würde.</p><h3>Der Happy-Path</h3><p>Grundsätzlich werden beim Mocking die Endpoints abgeklemmt und definiert, wie diese beim Aufruf zu reagieren haben. Im Happy-Path soll die Datenbank in diesem Beispiel einen gültigen Record zurück geben. Das geschieht unter Verwendung von mock:then-return:</p><div>

```xml
<mock:when doc:name="DB returns 1 record" messageProcessor=".*:.*">
    <mock:with-attributes>
        <mock:with-attribute name="doc:name" whereValue="#['Lookup user by id']"/>
    </mock:with-attributes>
    <mock:then-return payload="#[['id': 1234, 'firstname': 'John', 'lastname': 'Doe', 'username': 'jdoe']]]"
        mimeType="application/java"/>
</mock:when>
```

</div><p>Zum Prüfen der Ergebnisse gibt es unterschiedliche Alternativen: Man könnte einzelne Felder extrahieren und mit assert prüfen (viel Arbeit), die Ergebnisse 1:1 vergleichen (dann führen aber eigentlich irrelavante Unterschiede wie Formatierungen in XML oder JSON zu Fehlern), die Konvertierung in ein einfach vergleichbares Format (z.B. dedizierte Java-Klassen) oder die Verwendung einer Vergleichsfunktion. Ich nutze gerne das Modul <a href="https://github.com/rbutenuth/assert-object-equals-connector">assert-Object-equals</a> , mit dem sehr einfach auch JSON oder XML-Ojekte verglichen werden können:</p><div>

```xml
<assert-object-equals:compare-objects
    expected-ref="#[getResource('user-expected.json').asStream()]"
    doc:name="user is returned" />
```

</div><p>Das File „user-expected.json“ hat das erwartete User-Objekt im Json-Format zum Inhalt und liegt zusammen mit anderen Testdaten im Verzeichnis src/test/resources, welches Bestandteil des classpath ist:</p><div>

```json
{
    "id": 1234,
    "user": "jdoe",
    "name": "Doe",
    "firstname": "John"
}
```

</div><h3>User not found</h3><p>Natürlich muss man den Fall prüfen, dass der User nicht gefunden wird. In diesem Fall liefert der Database-Connector eine leere Liste:</p><div>

```xml
<mock:when doc:name="DB returns empty list" messageProcessor=".*:.*">
    <mock:with-attributes>
        <mock:with-attribute name="doc:name" whereValue="#['Lookup user by id']"/>
    </mock:with-attributes>
    <mock:then-return payload="#[[]]" mimeType="application/java"/>
</mock:when>
```

</div><p>Im Test erwarten wir jetzt aber kein Ergebnis, das wir vergleichen können, sondern eine Exception. Dieses Verhalten prüfen wir mit der passenden Deklaration des Tests:</p><div>

```xml
<munit:test name="get_users_idTest-user-not-found"
    description="When user is not found a NotFoundException is expected"
    expectException="org.mule.module.apikit.exception.NotFoundException">
```

</div><p>Damit stellen wir sicher, dass der Flow-under-Test mit der angegebenen Exception abbricht – alles andere läßt den Test fehlschlagen.</p><h2>Zusammenfassung</h2><p>In diesem ersten Artikel dieser Serie habe ich das Mocking von Datenbanken in MUnit-Tests eingeführt. Dabei habe ich anhand eines sehr einfachen Beispiels die Struktur von MUnit-Tests beschrieben und Tests für verschiedene Ergebnisse von Datenbankaufrufen geschrieben.</p><p>In nächsten Artikel werde ich beschreiben, wie Tests geschrieben werden können, die auch das aufrufende API-Kit mit testen und wie anstelle des Abklemmens der Datenbank eine immer noch schnelle, für viele Tests geeignete In-Memory-Datenbank verwendet werden kann.</p>

Testen in Mule mit Datenbanken – Teil 1: Mocking von Datenbanken

<p>In den ersten zwei Teilen der Artikelserie haben wir einen einfachen REST-Service in Mule implementiert, der seine Informationen aus einer Datenbank bezieht. Zum Testen haben wir zunächst die Datenbank gemockt und in einem zweiten Schritt eine In-Memory-Datenbank verwendet.</p><p>Beide Maßnahmen sind gute Lösungen, um schnelle Unit-Tests (mit MUnit) zu schreiben, die zunächst die eigentliche Logik in den Flows und dann auch die Konfiguration des Endpoints testen. Die Maßnahmen greifen aber zu kurz, wenn Features der Datenbank genutzt werden sollen, die nicht kompatibel mit der durch Mulesoft verwendeten In-Memory-Datenbank H2 sind.</p><p>Ein Ausweg ist natürlich, die Tests gegen eine produktionsähnliche Datenbank in einer speziellen Testumgebung zu fahren. Häufig wird dazu eine Integrations- oder Akzeptanztestumgebung bereitgestellt. Dieser Weg hat allerdings den Nachteil, dass sich mehrere Entwickler bzw. im Endeffekt die Tests eine Umgebung teilen müssen und sich dadurch in die Quere kommen können, weil parallele Zugriffe und gemeinsame Testdaten zu Konflikten führen. Für automatisierte Tests ist das eine eher problematische Lösung.</p><p>Docker-Container erlauben es, Server in kurzer Zeit und mit relativ wenigen Ressourcen für einzelne Tests oder Test-Suiten zu starten, initialisieren und anschliessend wieder wegzuwerfen. Die Struktur ist dabei grundsätzlich ähnlich zur Verwendung von In-Memory-Datenbank, wie ich im letzten Artikel beschrieben habe.</p><p>Der vollständige Code für die gesamte Artikelserie liegt in <a href="https://gitlab.codecentric.de/christian.langmann/munit-db-testcontainer" target="_blank">gitlab</a> .</p><h2>Docker-Datenbanken mit testcontainers.org</h2><p>Um Docker-Container in Java-Unittests zu verwenden gibt es eine Library <a href="https://www.testcontainers.org" target="_blank">testcontainers.org</a> . Neben generischen Modulen gibt es spezielle für verschiedene relationale und nicht-relationale Datenbanken.</p><p>Eine Anforderung aus Sicht einer Mule-Anwendung ist, dass die Parameter für den Endpoint statisch vorgegeben werden müssen. Das ist eine wesentliche Einschränkung bei der Verwendung der testcontainers-Bibliothek, weil diese beispielsweise das Paradigma vertritt, dass Ports für Testinstanzen dynamisch vergeben werden und von der Anwendung abgefragt und dann verwendet werden (ein Pattern, das grundsätzlich Sinn macht und im Java-Umfeld auch leicht umzusetzen ist). Leider müssen die Endpoints in Mule in der Regel fest definiert werden, so dass diese Art der Verwendung von testcontainers-Modulen nicht möglich ist.</p><p>Die per JDBC-benutzbaren Datenbanken erlauben allerdings die Vorgabe aller relevanten Parameter per URL. Es gibt eine spezielle Klasse (<code>org.testcontainers.jdbc.ContainerDatabaseDriver</code>), die automatisch anhand der URL das passende Image lädt und startet und dann die Verbindung aufbaut. Die URL muss lediglich im Vergleich zur Original-URL um den Einschub <code>:tc</code> zwischen <code>jdbc</code> und dem Datenbank-Typen ergänzt werden. Zusätzlich gibt es testcontainers-spezifische Query-Parameter, mit denen die URL erweitert werden kann um die Container zu steuern (z.B. um Initialisierungsskripte mitzugeben).</p><p>Technisch gesehen verwendet die Klasse ContainerDatabaseDriver die URL, um das passende Image zu erkennen und mit Docker zu starten. Bei der ersten Verwendung einer URL wird dann das gestartete Image in einen Cache gesteckt, so dass bei mehrfachem Zugriff nicht jedes Mal ein neuer Container gestartet wird.</p><p>Leider setzt das die Verwendung der URL als Zugriffsmethode auf die Datenbank voraus. Aus Mule-Sicht bedeutet das, dass die URL-Connection in den Connector-Konfigurationen verwendet werden muss, nicht die einzeln spezifizierten Bestandteile wie Host, Port, Database oder die Spring-Bean.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6saIpWZRBuvcPBCF2eQw"><img width="1240" height="670" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6saIpWZRBuvcPBCF2eQw" alt /></a> </p><h2>Verwendung von db-testcontainer</h2><p>Die Steuerung der testcontainer wird durch die Verwendung eines Mule-Konnektors vereinfacht: <a href="https://github.com/manikmagar/munit-db-testcontainers-connector" target="_blank">munit-db-testcontainers-connector</a> . Dieser Konnektor bietet ähnlich wie die dbserver-Komponente von MUnit die Möglichkeit, einen DB-Server zu konfigurieren, zu starten und zu stoppen.</p><p>Für die Verwendung müssen zwei Abhängigkeiten definiert werden (in der pom.xml in mavenized-Projekten bzw. durch Hinzufügen der Libraries in das Projekt). In der pom sind das die Abhängigkeit zum Konnektor und des benutzten Datenbank-Module aus testcontainers, in unserem Fall des Postgres-Testcontainers (zu beachten sind natürlich die passenden bzw. aktuellen Versionen):</p><div>

```xml
<dependency>
    <groupId>com.unittesters</groupId>
    <artifactId>munit-db-testcontainers-connector</artifactId>
    <version>0.0.6-SNAPSHOT</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>postgresql</artifactId>
    <version>1.10.5</version>
    <scope>test</scope>
</dependency>
```

</div><h2>Die Tests</h2><p>Die Verwendung der testcontainer-Konnektoren entspricht von der Struktur her den Tests unter Verwendung der dbserver-Komponente aus dem letzten Artikel. Zunächst wird die Konfiguration erstellt (die Properties werden aus einer für diesen Test angelegten .properties-Datei geladen):</p><div>

```xml
<context:property-placeholder location="api.testcontainer-connector.properties" />
 
<db-testcontainers:config name="DB_TestContainers_Configuration" 
    url="${db.url}" 
    username="${db.user}" password="${db.password}" 
    doc:name="DB TestContainers: Configuration" dbInitScript="USERS.sql"/>
```

</div><p>Die wesentlichen Properties aus der Datei sind die folgenden: Die wesentliche Einstellung ist die <code>db.url</code> und dabei der <code>tc</code> Bestandteil. Diese Properties werden auch von der Datenbank-Konfiguration genutzt, die im eigentlichen Flow verwendet wird. So ist sichergestellt, dass auch dort auf die Docker-Datenbank referenziert wird.</p><div>

```properties
db.database=mule
db.user=test
db.password=test
db.port=5432
db.host=localhost
db.version=9.6.8
db.url=jdbc:tc:postgresql:${db.version}://${db.host}:${db.port}/${db.database}
```

</div><p>In dem <code>before-suite</code>-Abschnitt der Test-Suite wird der Konnektor benutzt, um den Container zu starten und in <code>after-suite</code> wird er gestoppt. Das in der Konfiguration angegebene Init-Script wird einmalig beim Starten ausgeführt. In diesem Test wird es verwendet, um das Schema zu erstellen.</p><div>

```xml
<munit:before-suite name="testcontainerBefore_Suite" description="MUnit Test">
    <db-testcontainers:start-db-container config-ref="DB_TestContainers_Configuration" doc:name="DB TestContainers" runInitScript="true"/>
</munit:before-suite>
 
<munit:after-suite name="testcontainerAfter_Suite" description="Ater suite actions">
    <db-testcontainers:stop-db-container config-ref="DB_TestContainers_Configuration" doc:name="DB TestContainers"/>
</munit:after-suite>
```

</div><p>Ab jetzt kann der normale Datenbank-Prozessor von Mule verwendet werden, um die Datenbank in einen passenden Zustand zu bringen. Für unseren Test muss ein User geladen werden. Dies geschieht in der Before-Test-Phase:</p><div>

```xml
<munit:before-test name="testcontainerBefore_Test" description="Before tests actions">
    <db:update config-ref="Generic_Database_Configuration" doc:name="Trunc users">
        <db:dynamic-query><![CDATA[TRUNCATE TABLE users;]]></db:dynamic-query>
    </db:update>
    <db:insert config-ref="Generic_Database_Configuration" doc:name="Insert user">
        <db:parameterized-query><![CDATA[INSERT INTO users (id, username, lastname, firstname) VALUES(1234, 'jdoe', 'Doe', 'John');]]>
        </db:parameterized-query>
    </db:insert>
</munit:before-test>
```

</div><p>Die Tests selber sehen jetzt genauso aus wie in den letzten Artikeln:</p><div>

```xml
<munit:test name="get_users_idTest-happy-path" description="Test">
    <set-variable variableName="id" value="#[1234]" doc:name="set id"/>
    <flow-ref name="get_users_id" doc:name="get_users_id"/>
    <assert-object-equals:compare-objects expected-ref="#[getResource('user-expected.json').asStream()]" doc:name="user is returned "  />
</munit:test>
 
<munit:test name="get_users_idTest-user-not-found" description="Expects a NotFoundException" 
    expectException="org.mule.module.apikit.exception.NotFoundException">
    <set-variable variableName="id" value="#[2]" doc:name="set id"/>
    <flow-ref name="get_users_id" doc:name="get_users_id"/>
</munit:test>
```

</div><h2>Zusammenfassung</h2><p>Es ist in der Regel nicht ausreichend, die Datenbanken in Tests zu mocken. Zu viel wird dabei dann nicht getestet. Häufig reicht es aber auch nicht, eine In-Memory-(H2)-Datenbank zu nutzen. Es bestehen zuviele mögliche Inkompatibilitäten, die man gerne frühzeitig finden möchte. Andererseits ist die Verwendung von dedizierten Testumgebungen teuer, führt zu Abhängigkeiten und benötigt extra Abstimmungsprozeduren. Mit Docker-Containern steht eine Alternative für viele Einsatzgebiete zur Verfügung, die auch in MUnit-Tests für Mule ohne großen Aufwand verwendet werden kann.</p><p>Nutzt man die vorhandenen Frameworks und ein paar einheitliche Verfahren, unterscheiden sich die Tests selber dann nicht mehr großartig von den gemockten oder In-Memory-DB-Tests. Integrationstests lassen sich auf diese Art relativ einfach und gut verstehbar implementieren und immer noch mit guter Performanz ausführen.</p><p>Im nächsten Artikel dieser Serie wird die gesamte Thematik nochmals mit der neuer Mule Version 4 umgesetzt.</p>

Testen in Mule mit Datenbanken – Teil 3: Datenbanken mit Docker

<p>Nachdem ich im ersten Teil der Artikelserie das Mocken einer Datenbank im Rahmen von Munit-Tests beschrieben habe, werde ich im Folgenden zeigen, wie eine In-Memory-Datenbank zum Testen benutzt werden kann.</p><p>Warum sollten überhaupt In-Memory-Datenbanken zum Testen von Mule-Flows verwendet werden? Die eigentliche Logik der Flows wird in Unit-Tests üblicherweise mit gemockten Datenbanken überprüft. Allerdings werden dabei einige Aspekte der Flows einfach ausgeklammert, die in späteren Testphasen eventuell teurer zu finden und beheben sind.</p><p>Als erstes sind die Konfigurationsprameter des Connectors zu prüfen: Auch wenn die konkreten Werte für die verschiedenen Umgebungen natürlich nicht zu testen sind, kann zumindest die korrekte Syntax geprüft werden. Desweiteren wird beim Mocking der Datenbank-Aufruf selbst nicht geprüft: Also stimmt die SQL-Syntax und werden alle Parameter wie erwartet übergeben? Und zuguterletzt wird beim Mocking die Rückgabe des Ergebnisses in einem Format fest vorgegeben, das möglicherweise von dem Format abweicht, das die Datenbank tatsächlich liefert.</p><p>All das könnte man mit einer „echten“ Datenbank natürlich auch testen. Allerdings ist es deutlich aufwendiger, so eine Datenbank zu starten. Im Sinne von schnellen Testzyklen kann es also sinnvoll sein, bestimmte Tests mit einer In-Memory-Datenbank durchzuführen, die sich idealerweise ähnlich verhält wie die Produktionsdatenbank.</p><p>In weiteren Module- oder Integrationstest sollen aber auch die Konnektoren mit getestet werden, weswegen die entsprechenden Services mitlaufen müssen. Für einige dieser Services bietet das Anypoint-Studio mit Munit bestimmte Server-Komponenten an (Database, FTP).</p><p>Mule 3.9 liefert eine solche Datenbank als Bestandteil von Munit mit. Tatsächlich steckt dahinter eine <a href="http://www.h2database.com/html/main.html" target="_blank">H2-Datenbank</a> , die häufig verwendet wird, um schnelle Unit- oder Modultests mit einer quasi-echten-Datenbank auszuführen.</p><p>Der vollständige Code für die gesamte Artikelserie liegt in <a href="https://gitlab.codecentric.de/christian.langmann/munit-db-testcontainer" target="_blank">gitlab</a> .</p><h2>Modul-Tests mit In-Memory Datenbank</h2><h3>Installation des Datenbank-Moduls</h3><p>Die MUnit-Tools liefern ein Modul (namespace dbserver), mit dem eine InMemory-Datenbank einfach in Tests integriert werden kann. Vom AnypointStudio aus kann dieses Modul über die Munit Update Site installiert werden:</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/WPqSHlO6QuKJV2x9ZRFa"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/WPqSHlO6QuKJV2x9ZRFa" alt="Select DBServer in Munit-Update Site " width="1736" height="594" /></a> <p>Select DBServer in Munit-Update Site</p></div><h2>Vorbereiten der Datenbank</h2><p>Die eigentliche Anwendung verwendet einen generischen Datenbank-Konnektor, um die Datenbank anzusprechen (ich habe in der Anwendung eine Postgres-DB angenommen):</p><div>

```xml
<db:generic-config name="Generic_Database_Configuration"
    url="${db.url}"
    driverClassName="org.postgresql.Driver"
    doc:name="Generic Database Configuration"/>
```

</div><p>Ausgehend von dem Szenario aus dem ersten Artikel müssen die Tests ein wenig angepasst werden. Zunächst wird das Mocking der Konnektoren abgeschaltet. Das geschieht auf Ebene der Test-Suite:</p><div>

```xml
<munit:config name="munit" doc:name="MUnit configuration" mock-connectors="false" mock-inbounds="false"/>
```

</div><p>Als nächstes müssen Test-Properties geladen werden, die für die Ausführung der Tests die Datenbank-Konfiguration definieren:</p><div>

```xml
<context:property-placeholder location="api.dbserver.properties" />
```

</div><p>Diese Datei enthält die Einstellungen, um die In-Memory-Datenbank anzusprechen, sobald sie gestartet wurde. Es werden die Properties definiert, die in der DB-Konfiguration der Anwendung verwendet werden: <code>db.url=jdbc:h2:mem:postgres</code></p><p>Als nächstes konfigurieren wir den Datenbankserver. Man kann den H2-Datenbankserver in verschiedenen Emulationsmodi laufen lassen. In diesem Fall benutzen wir den PostgreSQL-Modus. Zusätzlich wird ein SQL-File angegeben, das beim Starten ausgeführt wird. Ich verwende das in der Regel, um das Schema vorzubereiten und ggf. Daten zu laden, die für alle Tests gelten sollen.</p><div>

```xml
<dbserver:config name="DB_Server" database="postgres"
    connectionStringParameters="MODE=PostgreSQL" doc:name="DB Server"
    sqlFile="USERS.sql"/>
```

</div><p>Für unsere Tests enthält USERS.sql folgenden Code:</p><div>

```sql
CREATE TABLE users (
    id int8 NOT NULL,
    username VARCHAR NOT NULL,
    lastname VARCHAR NOT NULL,
    firstname VARCHAR NULL
);
```

</div><p>Aus Performance-Gründen ist es sinnvoll, die Datenbank möglichst selten hochzufahren, zu starten und zu stoppen. Daher wird das in den Before- bzw. After-Phasen der Test-Suite erledigt:</p><div>

```xml
munit:before-suite name="get_users_id-test-suite-dbserverBefore_Suite"
    description="Before suite actions">
    <dbserver:start-db-server config-ref="DB_Server" doc:name="Start DB Server"/>
</munit:before-suite>
 
<munit:after-suite name="get_users_id-test-suite-dbserverAfter_Suite" description="After suite actions">
    <dbserver:stop-db-server config-ref="DB_Server" doc:name="Stop DB Server"/>
</munit:after-suite>
```

</div><p>Wenn mehrere Tests in einer Suite enthalten sind und auf dieselbe Datenbank zugreifen, nutze ich die Before-/After-Test-Abschnitte, um per SQL mit TRUNK oder DELETE die Datenbank auf einen definierten einheitlichen Zustand zu bringen:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/WhY5g2QTkWN14sNOINPH"><img loading="lazy" width="250" height="504" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/WhY5g2QTkWN14sNOINPH" alt="start and stop database-server für test-suite" /></a> </p><div>

```xml
<munit:before-suite name="dbserverBefore_Suite" description="Start DB on Testsuite-startup">
    <dbserver:start-db-server config-ref="DB_Server" doc:name="Start DB Server"/>
</munit:before-suite>
 
<munit:after-suite name="dbserverAfter_Suite" description="Ater suite actions">
    <dbserver:stop-db-server config-ref="DB_Server" doc:name="Stop DB Server"/>
</munit:after-suite>
 
<munit:before-test name="dbserverBefore_Test" description="Before tests actions">
    <dbserver:execute config-ref="DB_Server" sql="TRUNCATE TABLE users" doc:name="Trunc users"/>
    <dbserver:execute config-ref="DB_Server" 
        sql="INSERT INTO users (id, username, lastname, firstname) VALUES(1234, 'jdoe', 'Doe', 'John')"
        doc:name="Insert user"/>
</munit:before-test>
```

</div><h3>Implementierung der Unit-Tests</h3><p>Mit einer „schnellen“ Datenbank im Hintergrund möchte ich zunächst zeigen wie, vergleichbar zur vollständig gemockten Datenbank, Unit-Tests aussehen können.</p><p>Für die Test des Happy-Path und user-not-found für den Flow-Under-Test get_users_id gilt: Das war es fast. Im Vergleich zur Version des Tests für die gemockte Datenbank muss lediglich das Mocking entfernt werden. Die Tests sehen jetzt also so aus:</p><div>

```xml
<munit:test name="get_users_idTest-happy-path" description="Happy-Path Test">
    <set-variable variableName="id" value="#[1234]" doc:name="set id=1234"/>
    <flow-ref name="get_users_id" doc:name="get_users_id"/>
    <assert-object-equals:compare-objects expected-ref="#[getResource('user-expected.json').asStream()]"
        doc:name="user is returned"/>
</munit:test>
 
<munit:test name="get_users_idTest-user-not-found" description="Expects a NotFoundException"
    expectException="org.mule.module.apikit.exception.NotFoundException">
    <set-variable variableName="id" value="#[2]" doc:name="set id=2"/>
    <flow-ref name="get_users_id" doc:name="get_users_id"/>
</munit:test>
```

</div><p>Ändern Tests Werte in der Datenbank und sollen diese Werte mit einem Assert geprüft werden, kann die dbserver-Operation validate-that verwendet werden. Es wird eine Query und das erwartete Ergebnis (als csv) angegeben. Da dabei allerdings lediglich die Ergebnisse als String verglichen werden, lohnt es sich, alle möglicherweise zufälligen aber relevanten Bedingungen (verwendete Spalten, Spaltenreihenfolge, Groß-/Kleinschreibung, etc.) explizit im Query-Statement zu spezifizieren. Für Details hierzu soll ein Verweis auf die <a href="https://docs.mulesoft.com/munit/1.3/munit-database-server" target="_blank">Dokumentation</a>  reichen.</p><h3>Implementierung der Integrationstests</h3><p>Mit Tests zu prüfen, ob die Subflows funktionieren ist gut und schön. Allerdings ist damit nicht gewährleistet, dass die APIs auch so funktionieren wie erwartet. Deswegen sollten Integrationstests den End-2-End-Aufruf prüfen. Um ein komplettes Set an Tests für per RAML spezifizierte APIs zu erzeugen sei auf einen anderen <a href="https://www.avioconsulting.com/blog/testing-mulesoft-apikit-munit" target="_blank">Artikel</a>  verwiesen. Im Rahmen dieses Artikels unterscheiden sie sich nicht sehr stark von den Unit-Tests. Die Datenbank wird auf exakt dieselbe Art und Weise angesteuert, lediglich der Aufruf des Flow-Under-Test und das Prüfen des Ergebnis unterscheiden sich leicht:</p><div>

```xml
<http:request-config name="HTTP-APIKit" host="localhost" port="${http.port}" basePath="/api/" doc:name="HTTP Request Configuration">
    <http:raml-api-configuration location="api.raml"/>
</http:request-config>
 
<munit:test name="users-id-get:/users/{id}:apiConfigTest" description="Test apikit-flow happy-path">
    <http:request config-ref="HTTP-APIKit" path="/users/{id}" method="GET" doc:name="HTTP">
        <http:request-builder>
            <http:uri-param paramName="id" value="1234"/>
        </http:request-builder>
    </http:request>
    <munit:assert-on-equals expectedValue="#[200]" actualValue="#[message.inboundProperties['http.status']]"
        doc:name="Assert http.status is 200"/>
    <assert-object-equals:compare-objects expected-ref="#[getResource('user-expected.json').asStream()]"
        doc:name="user is returned "/>
</munit:test>
 
<munit:test name="users-id-get:/users/{id}:apiConfigTest-nouser" description="Test apikit-flow with missing user">
    <http:request config-ref="HTTP-APIKit" path="/users/{id}" method="GET" doc:name="HTTP">
        <http:request-builder>
            <http:uri-param paramName="id" value="2"/>
        </http:request-builder>
        <http:success-status-t-validator values="404"/>
    </http:request>
    <munit:assert-on-equals expectedValue="#[404]" actualValue="#[message.inboundProperties['http.status']]"
        doc:name="Assert http.status is 404"/>
</munit:test>
```

</div><h2>Zusammenfassung</h2><p>(M)Unit-Tests, die Datenbankzugriffe komplett mocken, ignorieren wesentliche Teile der zu testenden Mule-Anwendungen. Das ist einerseits vorteilhaft, weil so wirklich nur die gewünschte Logik getestet wird und Tests möglichst schnell ausgeführt werden sollen. Andererseits können so Fehler in der Konfiguration von Datenbank-Endpoints nicht gefunden werden.</p><p>In diesem zweiten Teil der Artikelserie haben wir gesehen, wie als Kompromiss eine (In-Memory)-Datenbank für eine Reihe von MUnit-Tests gestartet werden kann, so dass aus Mule-Sicht die echten Endpoints ausgeführt und mit getestet werden.</p><p>Ein Nachteil ist allerdings immer noch, dass die von Mule bereitgestellte In-Memory-Datenbank die spätere externe Datenbank lediglich simuliert und sich diese daher anders verhalten kann als die Datenbank in Produktion. Im Endeffekt müssen daher auch Tests gegen eine produktionsähnliche Datenbank ausgeführt werden. Dieser Aufgabe widmet sich der nächste Teil dieser Artikelserie.</p>

Testen in Mule mit Datenbanken – Teil 2: In-Memory-Datenbanken

Alles String, oder was? Datenformate in Mule. Teil 1: XML

<p>In den letzten Monaten kamen immer häufiger Anfragen nach Architektur-Reviews bei mir an. Grund genug, meine Erfahrungen aufzuschreiben und zur Diskussion zu stellen. Dabei beschreibe ich die drei Ws:</p><ol><li>Wofür wird ein Architekturreview gemacht?</li><li>Was ist eine Architektur?</li><li>Wie wird ein Architekturreview durchgeführt?</li></ol><p>Natürlich ist das Thema zu umfangreich, um in einem Blogpost wie diesem vollständig behandelt zu werden. Daher kann ich zunächst viele Themen nur anteasern. Für weitere Informationen verweise ich auf die Literatur und freue mich über eine rege Diskussion.</p><p>Ein weiterer Anreiz das Folgende zu lesen: Vieles gilt bei einer Analyse einer existierenden Architektur genau wie bei einer Neuentwicklung. Der Artikel ist quasi wiederverwendbar. Während es bei der Entwicklung aber auf das richtige Maß ankommt (<a href="https://www.georgefairbanks.com/book/" target="_blank">Just enough Software Architecture)</a> ), ist das Kind bei der Review bereits in den Brunnen gefallen.</p><h2>Welche Ziele kann eine Architektur-Review haben?</h2><p>Es gibt verschiedene Gründe, warum unsere Kunden nach Architektur-Reviews fragen. Der naheliegenste (und naivste) ist, von einer dritten Person einen beruhigenden Stempel zu bekommen: „Die Architektur ist gut.“</p><p>So einfach ist es in der Regel natürlich nicht. Es fängt schon damit an, dass die Anfragen zu ganz unterschiedlichen Zeiten des Anwendungs-Lifecycle kommen. Hier eine Liste an Beispielen:</p><ul><li>Am Anfang der Entwicklung: Das Team oder ein interner oder externer Architekt hat sich etwas ausgedacht. Ist das in Ordnung?</li><li>Die Anwendung ist im Betrieb: Wir haben Probleme in unserer Anwendung. Liegt das an der Architektur? Was müssen wir ändern?</li><li>Die Anwendung ist relativ alt, die Frage nach Weiterentwicklung oder Neuentwicklung stellt sich.</li><li>Die Architektur ist gar nicht bekannt, die Review ist eigentlich eine nachträgliche Dokumentation</li></ul><p>Entsprechend ergeben sich verschiedene mögliche Ziele, die eine Architektur-Review haben kann:</p><ul><li>Beruhigung des Auftraggebers hinsichtlich Qualität, Umfang und Nutzen</li><li>Sicherstellen der richtigen Architekturentscheidungen bezüglich aktueller oder neuer Anforderungen</li><li>Entscheidungshilfen für die Weiterentwicklung/Umbau/Neuentwicklung einer Anwendung</li></ul><p>Wenn eine Architektur bewertet wird, kann man sich von zwei Seiten nähern: Entweder man prüft, ob die Architektur „gut genug“ ist, also die Anforderungen an sie erfüllt. Oder man beschreibt die Eigenschaften, die die Architektur hat und stellt dann Vor- und Nachteile gegenüber. <strong>(Bemerkung: Könnte man von Top-Down/Bottom-Up sprechen?)</strong></p><h2>Begriffsklärung: Was bedeutet Architektur?</h2><p>Der Nachteil an dem Begriff „Architektur“ ist, dass jeder davon redet, aber etwas Unterschiedliches meint. Wenn eine Anfrage nach einer AR kommt, muss daher zunächst eine Begriffsklärung erfolgen. Selbst wenn es halbwegs einheitliche Definitionen gibt (siehe z. B. <a href="https://de.wikipedia.org/wiki/Softwarearchitektur#Definition" target="_blank">Wikipedia</a> ), helfen diese beim gegenseitigen Verständnis wenig, weil die in den Definitionen benutzen Abstraktionen zu allgemein sind.</p><p>Wenn ich mir über Architektur Gedanken mache oder darüber rede, befindet sich immer ein Elefant im Raum, den man einmal für alle klar machen sollte: der Rahmen, in dem wir über Architektur denken und reden. Ignoriert man dies, führt das nahezu zwangsläufig zu Missverständnissen und enttäuschten Erwartungshaltungen.</p><p>Hier sind einige Konzepte, deren Bedeutung für den Auftrag festgelegt werden sollten:</p><h3>Systemarchitektur vs Softwarearchitektur</h3><p>Als erstes möchte ich die Flughöhe bzw. den Umfang von Architektur festlegen. Bei einer Systemarchitektur betrachte ich (wie der Name sagt) das Zusammenspiel verschiedener Systeme. Und schon muss ein weiterer Begriff definiert werden: Ein System ist, kurz gesagt, ein klar abgegrenztes Softwarepaket mit definierten Schnittstellen. Das kann also genauso ein ERP-System sein wie ein Microservice. Damit kann schon ein System einen sehr unterschiedlich großen Umfang haben. Eine Systemarchitektur wird manchmal auch als Makroarchitektur bezeichnet.</p><p>Bei einer Softwarearchitektur betrachte ich die Code-Komponenten, die i. d. R. innerhalb eines Prozesses laufen, und analysiere oder beschreibe das Zusammenspiel. Auch hier gibt es definierte Schnittstellen, und der Übergang zwischen System- und Softwarearchitektur ist nicht immer klar. In einer typischen 3-Tier-Anwendung laufen die UI- und die Backend-Komponenten zwar in getrennten Prozessen (und häufig auch Sprachen), bilden aber aus höherem Abstraktionslevel gesehen zusammen mit der Datenbank ein System. Im „Handbuch moderner Softwarearchitektur“ wird auch das Zusammenspiel von (in getrennten process-)Komponenten als Softwarearchitektur bezeichnet.</p><p>Auf unterster (Code-)Ebene kann man ebenfalls in Komponenten oder Schichten trennen und die Zusammenhänge beschreiben. Hier werden Metriken erstellt, mit denen die Wartbarkeit gemessen werden soll. Dafür gibt es <a href="https://de.wikipedia.org/wiki/Bewertung_von_Softwarearchitekturen#Werkzeuge" target="_blank">Tools</a> , die in die CI/CD-Pipeline eingebunden werden können und eine langfristige Verschlechterung verhindern sollen. Die Architektur, die sich hier befindet, wird manchmal auch als <a href="https://en.wikipedia.org/wiki/Microarchitecture" target="_blank">Mikroarchitektur</a>  bezeichnet.</p><h3>Architektur-Patterns</h3><p>Egal auf welcher Ebene man sich befindet: Das Wesentliche einer Architektur-Review ist das Analysieren und Erkennen von Patterns und zu verstehen, wie diese Patterns die Anforderungen an die Software erfüllen.</p><p>Auf Codeebene dürften jedem die <a href="https://de.wikipedia.org/wiki/Entwurfsmuster" target="_blank">Entwurfsmuster</a>  der Gang-of-Four bekannt sein. Diese Patterns stellen, „[…] eine wiederverwendbare Vorlage zur Problemlösung dar, die in einem bestimmten Zusammenhang einsetzbar ist“. Für verschiedene Programmiersprachen gibt es wiederum eigene Patterns oder Beschreibungen, wie allgemeine Patterns am besten in der jeweiligen Sprache umgesetzt werden können (Idiome). Es geht also darum, Code so zu strukturieren, dass Erfahrung wiederverwendet wird.</p><p>Anwendungen werden aus verschiedenen Komponenten zusammengebaut. Daher stellt sich in Softwaresystemen die Frage, wie die Komponenten zusammen funktionieren. Dabei ist aber nicht nur die Interaktionsweise und damit Abhängigkeit zwischen den Komponenten relevant, sondern auch Problemstellungen wie Deploybarkeit, Skalierbarkeit oder Versionierbarkeit. Beispiele für Patterns – oder Architekturstile – die diese Fragen beantworten sind z. B. Monolithen, Microservices oder SOA. Die Interaktionsweisen können zum Beispiel mit Client-/Server- oder Eventsourcing-Patterns implementiert werden.</p><p>Für bestimmte Arten von Softwaresysteme gibt es weitere Sammlungen von Patterns, zum Beispiel für <a href="https://www.enterpriseintegrationpatterns.com" target="_blank">Enterprise-Integration-Patterns</a>  (EiP) für die Integration von Softwarekomponenten oder -systemen. Wie der Name schon sagt, geht es dabei eher um die Integration von (Enterprise-)Systemen. Tatsächlich ist ein Großteil der Patterns aber so abstrakt, dass sie auch innerhalb eines Systems zur Anwendung kommen (z. B. gibt es Message Endpoints in jeder Anwendung, die APIs anbietet).</p><h3>Level bzw. Views</h3><p>Wie schon gesagt, gibt es bei der Betrachtung von Architekturen verschiedene Gesichtspunkte zu berücksichtigen. Bei Patterns sind dies die Probleme oder Aspekte, die auf unterschiedliche Arten gelöst werden können. Je nachdem, welche Probleme man analysieren oder lösen möchte und je nach Detailierungsgrad, ergeben sich verschiedene Sichtweisen, Modellierungs- oder Dokumentationssprachen:</p><ul><li>Komponenten: Interaktion, Verteilung, Deployment</li><li>Fachlichkeit: Bounded-Context, Interaktionsdiagramme, Klassendiagramme</li><li>Code: Design Patterns, Packages, Layer, Metriken</li></ul><p>Eine andere Darstellung ist z. B. das <a href="https://de.wikipedia.org/wiki/4%2B1_Sichtenmodell" target="_blank">4+1-Sichtenmodel</a> .</p><h2>Vorgehensweise</h2><p>Nachdem zunächst beschrieben wurde, was eine Architektur sein kann, die reviewed werden soll, kommen wir jetzt zum Vorgehen, also dem Wie. Im Prinzip bietet sich ein klarer Ablaufplan an. Wie aber später (siehe Dokumentation) beschrieben wird, ist eine häufige Interaktion mit dem Auftraggeber sinnvoll. Dadurch ergeben sich kurze Feedbackzycklen, so dass auch Änderungen oder neue Einsichten eingearbeitet werden können. Das passiert bei einer Entwicklung einer Architektur eher als bei einer reinen Review, aber da letzteres i. d. R. mit einem Zweck verbunden ist, gibt es auch hier externe veränderliche Einflüsse.</p><ol><li>Auftragsklärung: Ziel und der Umfang der Review</li><li>Erfassen der Anforderungen an die Architektur inkl. Priorisierung</li><li>Analyse und Verstehen der Architektur</li><li>Sichtung der Architekturentscheidungen und ggf. der Alternativen</li><li>Bewertung der Architektur hinsichtlich der Anforderungen</li><li>Zusammenstellen der Ergebnisse und ggf. Empfehlungen zum Umgang</li><li>Stempel drauf</li></ol><h3>Input</h3><p>Um eine Review durchführen zu können, werden verschiedene Daten und Informationen benötigt. Die genauen Details hängen von Level der Architektur ab, der zu untersuchen ist. Allgemein benötigt man vom Auftraggeber aber folgende Informationen:</p><ul><li>Existierende Dokumentation: Beschreibungen zur Architektur, evtl. ADRs (Architecture Decision Records)</li><li>Code: Je nach Betrachtungslevel muss der Code zur Verfügung stehen, um Codeanalysen durchführen zu können oder fehlende Dokumentation zu ersetzen.</li><li>Anforderungen: Diese werden benötigt, um die Ziele der Architektur abzugleichen.</li><li>Ansprechpartner: Je nach Komplexität kann es sinnvoll sein, mit verschiedenen Stakeholdern der Architektur zu sprechen (inkl. den Entwicklern, die sie entwickelt haben oder verwenden müssen).</li></ul><p>Eventuell lohnt es sich, Teamstrukturen und einige Prozesse wie Build und Deployment oder Release-Strategien genauer anzusehen. Häufig stehen diese in Wechselwirkung mit der Architektur (siehe <a href="http://www.melconway.com/Home/Conways_Law.html" target="_blank">Conways-Law</a> ).</p><p>Auf eine Architektur wirken immer bestimmte Anforderungen, ob diese nun erfüllt werden oder nicht. Um die Qualität beurteilen zu können, müssen also die Ziele der Architektur beschrieben werden. Ein gute Beschreibung davon haben Kollegen in <a href="/wissens-hub/blog/auf-dem-weg-zur-high-level-zielarchitektur" target="_blank">Auf dem Weg zur High-level-Zielarchitektur</a>  beschrieben. Ein wesentlicher Punkt ist auch der Detailierungsgrad: Häufig reicht es beispielsweise nicht aus, eine bestimmte Reaktionszeit zu fordern oder Erweiterbarkeit. Je nach Komponente muss man häufig genauer unterscheiden, welcher Teil schnell eine Antwort liefern muss, wo Skalierbarkeit wichtig ist, oder wo externe Entwickler Plugins bereitstellen können sollen. Einige Anforderungen beeinflussen oder widersprechen sich, so dass gegebenenfalls ein Abwägen stattfinden muss. In einer Review ist das insofern von Bedeutung, als dass die Vor- und Nachteile der gewählten Architektur im richtigen Level gegenüber gestellt werden müssen.</p><h3>Dokumentation</h3><p>In der Regel möchten die Auftraggeber eine Dokumentation der Ergebnisse der Architektur-Review. Wie sich aus den vorigen Ausführungen ergibt, kann es nicht „das“ Template für solche Analysen geben. Stattdessen kann die Dokumentation iterativ erstellt werden, um den Auftraggeber frühzeitig einzubeziehen und Mithilfe seines Feedbacks die Erwartungshaltung von vornherein abzustimmen.</p><p>Zunächst ist die Struktur festzulegen: Diese beinhaltet die vorläufigen Überschriften und eine kurze Beschreibung, was in den Kapiteln beschrieben wird. Während der Analyse einer Architektur können sich die Erwartungen des Auftraggebers ändern, eine andere Herangehensweise anbieten. Zudem können sich die Schwerpunkte verlagern. Deswegen kann oder muss die Struktur natürlich bei Bedarf angepasst werden, was durch ein interaktives Vorgehen mit kurzen Zyklen unterstützt wird.</p><p>Auch die Art der Diagramme sollte mit dem Auftraggeber abgestimmt werden. Eine gute Auswahl der Graphiken ist sehr schwer und abhängig davon, was gezeigt werden soll. Die Herausforderung besteht häufig darin, mehrere Aspekte der Architektur in einem Bild auszudrücken. Häufig werden dafür Graphiken mit mehreren Layern vorgeschlagen, die ein- oder ausgeblendet werden können. Eine andere interaktive Darstellungsweise ist in Details hinein zoomen zu können. Beide sind natürlich nur insoweit verwendbar, als zum Beispiel dynamische Visiodiagramme als Bestandteil der Dokumentation akzeptabel sind. Ist eine statische Dokumentation nötig, müssen die relevanten Ausschnitte ausgewählt und dupliziert werden.</p><p>Eine von mir gerne verwendete Art von Diagrammen ist die von <a href="https://c4model.com" target="_blank">C4</a> . Einerseits gibt diese eine vernünftige Struktur vor, andererseits ist diese so allgemein, dass sie an die meisten Anforderungen und Architekturfragen angepasst werden kann. Wie die Cs (Context, Container, Component, Class) beschreiben, werden dabei alle Abstraktionsebenen abgedeckt.</p><h2>Zusammenfassung</h2><p>Keine Architektur-Review ist wie die andere: Sie kann unterschiedliche Ziele verfolgen und sich auf verschiedene Bestandteile und Detailgrade eines Softwaresystems beziehen. Je nachdem können unterschiedliche Tools, Analyse- und Dokumentationswerkzeuge verwendet werden. Das grundsätzliche Vorgehen ist allerdings ähnlich. Es empfiehlt sich eine häufige Interaktion mit den Stakeholdern.</p><h2>Weiterführende Links</h2><p>https://www.heise.de/developer/artikel/Was-ist-Systemarchitektur-4931898.html<br /> https://github.com/clarkware/jdepend<br /> https://www.langlebige-softwarearchitekturen.de<br /> https://www.ionos.de/digitalguide/websites/web-entwicklung/was-sind-design-patterns/</p>

Was und wofür ist eine Architektur-Review?

Solution Architect

<p>Wir begegnen häufig Unternehmen im Wachstumsstadium, bei denen wir Probleme mit der steigenden Anzahl an Kundenwünschen und -anforderungen feststellen. Sie haben den Moment, an dem sie einen anderen Umgang mit ihren Anforderungen und Kunden benötigen, aufgrund ihres Erfolgs versäumt. Die Folgen: Das Backlog nimmt überhand und ist nicht mehr zu überblicken. Versprochene Liefertermine werden nicht eingehalten, es häufen sich Beschwerden der Kunden, dass nicht umgesetzt wurde, was gewünscht war. Ihre Entwickler kommen nicht hinterher und ihnen ist unklar, wie sie ihre Anforderungen priorisieren sollen. So erwarten sie, mit standardisierten Anforderungsdokumenten und einer klar definierten Anforderungsaufnahme, die Masse bewältigen zu können.</p><h2>Wenn Kundenwünsche überhandnehmen</h2><p>Die Anforderungen in diesen Unternehmen entstehen durch Fachabteilungen, Kunden oder Vertrieb. Sie werden selten durch ein Produktmanagement (aus-)sortiert. Die ToDo-Liste der Entwicklung wächst mit zugesagten Anforderungen der Kunden zu einer kaum mehr handhabbaren Menge. Meist ist die Lösung vorgegeben und vertraglich festgelegt, teilweise bevor ein technischer Experte zugezogen wurde. Die Vertriebsstrategie basiert auf spezifischen Anpassungen und Erweiterungen für den Kunden. Sie möchten so viele Kunden, Branchen und Märkte besetzen wie möglich und verlieren dabei leicht ihr Kerngeschäft aus den Augen.</p><p>Aufgrund des Mangels an einem zentralen Anforderungsmanagement entstehen so schon vor der Entwicklung Unklarheiten. Die Folge sind Unklarheiten in allem, was danach folgt. Dass die Entwicklung nicht mehr nachkommt und auf Qualität verzichtet, um fristgerecht fertig zu werden, ist eine von vielen negativen Folgen. Releases schlagen fehl und es entstehen immer mehr Bugs. Der Liefertermin verzögert sich immer weiter und mit ihm die folgenden Liefertermine aller anderen Kunden. Eine belastbare Planung findet nicht mehr statt. Somit befindet man sich in einer verzwickten Lage, aus der man schwer wieder ausbrechen kann.</p><h2>Durch Anforderungsmanagement zurück zum Kern</h2><p>Um die Lage in den Griff zu bekommen, braucht es eine grundlegend neue Art und Weise mit Anforderungen umzugehen. Ein zentrales Anforderungsmanagement vereinigt ähnliche Wünsche und Lösungen für unterschiedliche Kunden. So sorgt sie für eine Umsetzung, die allen Kunden gerecht wird. Wenn man dabei explizite Lösungen nicht vertraglich festlegt, erhält man eine Flexibilität in der Findung der besten Lösung. So gerät man auch nicht in ein Ping-Pong-Spiel mit dem Kunden, weil nicht genau das umgesetzt wurde, was gefordert wurde.</p><p>Durch die Vermeidung von speziellen Konfigurationen für einzelne Kunden wird es einfacher, ein einheitliches und stimmiges Gesamtprodukt zu schaffen. Die Wartung dieser Systeme wird wieder leichter und Anpassungen am Kern der Software sind nicht mehr mit hohem Aufwand verbunden. Ohne diesen Umschwung ist es nur eine Frage der Zeit, wann das System in sich zusammenfällt. Es besteht die Gefahr, dass sich Kunden aufgrund der schlechten Qualität abwenden. Die Zufriedenheit der Mitarbeiter schwindet, weil sie sich ein stressfreies Arbeiten wünschen. Und die Software an sich ist irgendwann nicht mehr zu warten.</p><p>Das Produkt muss mehr sein als die Summe der Funktionalitäten. Diese Unternehmen brauchen einen Plan, ein Ziel, eine Strategie. Sie müssen zu ihrem Kerngeschäft zurückfinden und eine Strategie und Vision für ihr Produkt erarbeiten. Daraus entstehen Forderungen an die Softwarearchitektur und eine Roadmap, die dem ganzen Unternehmen Struktur und Richtung gibt. Eine Sensibilisierung für Make-or-Buy-Entscheidungen hilft zudem, den Fokus auf das zu lenken, was das Produkt eigentlich ausmacht, und die Software nicht zu verbauen.</p><p>Wenn diese Unternehmen eine vom Kunden vorgegebene Lösung umsetzen, können sie nicht sicherstellen, dass es wirklich das ist, was der Kunde auch <em>braucht</em>. Die Frage an den Kunden nach dem Grund der Anforderung, welches Problem es für ihn löst, die Wirkung, die er sich wünscht, klärt den Kontext der Anforderung. Sie ermöglicht es, Umsetzungen zu finden, die diese Probleme viel besser lösen, als die formulierte Umsetzung des Kunden. Daraus resultiert ein besseres Verständnis der Nutzung des eigenen Produkts. Wenn der Produzent weiß, wie und wozu der Kunde das Produkt benutzt, ist er auch wieder Experte für sein eigenes Produkt. Er weiß besser, was noch am Produkt fehlt und nutzt den Input des Kunden als Feedback und Aufforderung, eine gute Lösung zu erarbeiten.</p><p>Umso wichtiger ist eine ständige Kommunikation mit dem Kunden, um zu verstehen, wie er das Produkt nutzt und welche Funktionalitäten wichtiger als andere sind. Oder wo hat er sich möglicherweise an einen Workaround gewöhnt? Wo schlummern Chancen, den Kunden glücklich zu machen?</p><h2>Umsetzen, was der Kunde wirklich braucht</h2><p>Um dem Kunden den größtmöglichen Mehrwert zu bieten, empfehlen wir als Coaches ein iteratives und agiles Vorgehen. Anforderungen werden in einzeln umsetzbare Funktionen geteilt, End-to-End formuliert und inkrementell umgesetzt. Dabei werden die Funktionen mit dem größten Nutzen priorisiert. User Stories und Akzeptanzkriterien ersetzen standardisierte und starre Anforderungsdokumente. Sie ermöglichen es, ein gemeinsames Verständnis zu schaffen, was wirklich gebraucht wird. Entwicklerteams und Produktmanager lernen, gemeinsam an der Lösungsfindung der Anforderungen zu arbeiten. Änderungen und Erweiterungen werden häufiger, dafür in kleinerer Form ausgeliefert. So kann der Kunde direktes Feedback geben und das Produktmanagement damit immer besser verstehen, was den Kunden glücklich macht.</p><p>Je fortgeschrittener das Produkt, desto wichtiger wird ein funktionierendes Produktmanagement, das den Fokus auf das große Ganze halten, und die Anforderungen überblicken und vor allem verstehen kann. Das gesamte Unternehmen kommt nicht umhin, sich auf den neuen Umgang mit Anforderungen und somit mit seinen Kunden einzustellen und auf den damit entstehenden Wandel für das System. Es kommen Überlegungen zur Architektur der Software auf sie zu, womöglich werden größere Umstellungen eingeplant und die Entwicklerteams müssen auf die neue Art der Anforderungsaufnahme eingestellt sein. Außerdem muss das Management die Vertriebsstrategie hinterfragen, wenn man nicht mehr alle Kundenwünsche zusagt.</p><h2>Ein Team von Coaches unterstützt bei der Umstellung</h2><p>Eine solch umfangreiche Umstellung ist für ein Unternehmen eine große Herausforderung. Um diesen Wandel bestmöglich zu unterstützen, arbeiten wir am besten mit einem Team von Coaches mit unterschiedlichen Schwerpunkten. Bei Themen im Bereich Anforderungen und Strategie, helfen Product Coaches. Sie können ihr Wirken mit Agile Coaches und Technical Coaches abstimmen und dadurch eine ganzheitliche Wirkung über die Bereiche hinweg erzielen.</p><ul><li>Product Coaches unterstützen bei der Ausrichtung des Produkts und dem Umgang mit Anforderungen.</li><li>Agile Coaches begleiten den Aufbau agiler Rahmenbedingungen und selbstorganisierter Teams.</li><li>Technical Coaches helfen den Teams bei der praktischen Umsetzung agiler Softwareentwicklung und Architekturfragen.</li></ul><p>Zusammen behält das Coach-Team den Überblick und unterstützt das Management, ihre Strategie im Veränderungsprozess zu verfolgen. Mit dieser breitgefächerten Unterstützung und Beratung, helfen wir unseren Kunden bei der Skalierung in allen Bereichen ihres Unternehmens.</p><p> </p>

Backlog überfüllt? Ein Produkt ist mehr als die Summe seiner Funktionalitäten

<p>We often find businesses in a stage of growth where they are experiencing problems caused by an increasing number of customer requests and requirements. They missed the moment when their success created the need for a different approach to their requirements and customers. The consequences? The backlog is out of control and no one can keep track of it. Promised delivery dates are not kept, and there are increasing complaints from customers that their requested features have not been implemented. Their developers can’t keep up and it’s unclear how to prioritize the requirements. They expect to be able to cope with the massive workload by using standardized documents and clearly defined processes.</p><h2>When customer requests get out of hand</h2><p>The requirements in these companies emerge from the departments, customers or sales and are seldom overseen by product management. The developers’ to-do list grows with the promised customer requirements to an almost unmanageable level. Most of the time, the solution is predetermined and contractually agreed, sometimes even before a technical expert is called in. The sales strategy is based on specific configurations and extensions for the customer. They want as many customers as possible irrespective of industry or market and therefore easily lose sight of their core business.</p><p>Due to the lack of a central management of requirements, ambiguities arise even before they reach development. The result is uncertainty in everything that follows. One of the many negative consequences is that the development team can no longer keep up and compromises on quality in order to finish on time. Releases fail and more and more bugs are produced. The delivery is delayed and with it the subsequent deliveries for all other customers. Stable planning is no longer possible. It’s a vicious circle that’s hard to escape.</p><h2>Back to the core through requirements management</h2><p>In order to get the situation under control, a fundamentally new way of dealing with requirements is needed. A central product management team aligns related requests for different customers and ensures an implementation that satisfies everyone. By not explicitly specifying solutions in a contract, they gain flexibility in finding the best solution and don’t run into a ping pong game with the customer due to not delivering exactly what was requested and written in the contract.</p><p>Furthermore, the maintenance of these systems becomes easier again and adjustments to the core of the software require less effort. Without this change, it is only a matter of time before the system collapses. Customers might turn away due to the poor quality. Employee satisfaction drops because they want their work to be stress-free. And, at some point, the software itself can no longer be maintained.</p><p>The product has to be more than the sum of its features. These companies need a plan, a goal, a strategy. They have to find the way back to their core business and develop a strategy and vision for their product. This results in software architecture requirements and a roadmap that gives the entire company structure and direction. Awareness of make-or-buy decisions also helps to focus on what actually defines the product and not to clutter the software.</p><p>When these companies implement a solution specified by the customer, they cannot ensure that it is really what the customer needs. Interviewing the customer about the reason for the requirement, which problem it solves for him, and the impact he wants, clarifies the context of the requirement. It makes it possible to find implementations that solve these problems much better than the formulated implementation of the customer. This results in a better understanding of the use of one’s own product. When the producer knows how and for what purpose the customer is using the product, he is again an expert on his own product. He has a better understanding of what is still missing in the product and uses the customer’s input as feedback and a request to find a suitable solution.</p><p>Constant communication with the customer is all the more important in order to understand how they use the product and which functionalities are more important than others. Have they found a workaround to solve their problem? Are there any quick-wins to make the customer happy?</p><h2>Implementing what customers really need</h2><p>In order to offer the customer the greatest possible added value, we as coaches recommend an iterative and agile approach. Requirements are divided into standalone, end-to-end features and implemented incrementally. The features with the greatest benefit are prioritized. User stories and acceptance criteria replace standardized and rigid requirement documents. This fosters the creation of a common understanding of what is really needed. Development teams and product managers learn to work together to find a solution to the requirements. Changes and features are delivered more frequently, but in a smaller form. In this way, the customer can give direct feedback and product management can better understand what makes the customer happy.</p><p>The more advanced the product, the more important it is to have a functioning product management that can maintain the focus on the big picture and has an overview and, above all, an understanding of, the requirements. In this way, the company as a whole cannot avoid adapting to this new way of dealing with requirements and its customers and the resulting change in the system. The software architecture needs to be reviewed and may require major changes, and the development teams have to be prepared for the new approach. In addition, the management has to revisit the sales strategy if it will no longer accept all customer requests.</p><h2>A team of coaches supports the change</h2><p>Such an extensive change is a great challenge for a company. In order to support this change in the best possible way, it is best to work with a team of coaches with different focuses. Product coaches help with topics in the area of ​​requirements and strategy. They can coordinate their work with agile coaches and technical coaches and thus achieve a holistic effect across the areas.</p><p>Product coaches support with alignment of the product and the handling of requirements.<br /> Agile coaches support the establishment of conditions for an agile framework and self-organized teams.<br /> Technical coaches help the teams with the practical implementation of agile software development and architecture.</p><p>Together, the coach team maintains an overview and supports the management in pursuing their strategy in the change process. With this wide range of support and advice, we help our customers to scale in all areas of their company.</p>

Crowded backlog? A product is more than the sum of its features

Product Coach

God save the team!?

Beyond the backlog: Scrum managen – Längerfristige Planung mit Jira Roadmaps

People Development

IT-Consultant

IT Consultant & Developer

Fullstack IT Consultant

Hamburg | Team

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.

Willkommen im Team Hamburg

Jetzt für unseren Newsletter anmelden