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

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

Data Effectiveness

Digitale Produkte & Lösungen

Digitale Souveränität

IT-Security

Künstliche Intelligenz

Software-Modernisierung

Leistungen von A bis Z ...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Jobs

Unsere Kultur

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 Frankfurt am Main

Unser codecentric Team am Standort Frankfurt am Main stellt sich vor.

codecentric Team Frankfurt am Main

Willkommen im Team Frankfurt

Entwicklung strukturierter Maßnahmen zu effizienter Remote-Work: Ein „Arbeitsblatt“

Principal Agile & Product Coach

Writing Platform Documentation That Developers Actually Want To Use

Many developer platforms already exist long before anyone calls them that.

Over time, teams standardize deployment workflows, define infrastructure patterns, and accumulate operational knowledge about how systems are built and run. These pieces gradually form the foundations of an internal developer platform, even if they are not recognized as such.

Discussions about platform engineering often focus on paradigm shifts or technology stacks. Both topics are important, but an equally important element often receives less attention: platform documentation.

For many organizations, platform engineering initially appears daunting. The term suggests large architectural transformations and complex tooling ecosystems. In practice, progress is often made in incremental steps.

Like software development, platform development benefits from iteration. Incremental improvements are easier to implement and usually deliver value quicker. Improving platform documentation is one of the simplest ways to improve the developer experience. Compared to infrastructure changes, it carries little risk while immediately reducing friction for developers working with the platform.

## Platform documentation is product documentation

Platform documentation works best when treated as product documentation rather than an internal archive of technical knowledge.

The shift is small but meaningful. The platform is a product, developers are its customers, and documentation exists to help those customers complete tasks.

From this perspective, documentation is not primarily a place to explain architecture or record historical decisions. Its purpose is to help engineers achieve concrete outcomes. 

Effective documentation prioritizes usefulness over completeness and focuses on practical questions.
### Do
- Treat the platform as a product and developers as customers
- Prioritize usefulness over completeness
### Don't
- Treat documentation as a historical archive
## Define your audience
Platform documentation serves different audiences. Keeping a few key personas in mind while writing helps to ensure the documentation meets the needs of its target audiences.

Junior developers often use documentation to understand unfamiliar systems. They benefit from context, explanations, and references to prerequisite knowledge.

Senior developers usually arrive with a specific task and prefer concise instructions, examples, and pages that allow them to locate relevant information quickly.

Documentation may also be consulted by security or compliance auditors who want to understand how systems enforce guardrails, provide auditability, and implement security-by-default.

These audiences do not require separate documentation. Clear structure allows readers to navigate to the details that are relevant to them.
### Do
- Define your target audiences through clear personas and keep them in mind when writing
- Assume readers may lack context and explain internal terminology when needed
### Don't
- Assume readers are familiar with internal conventions or acronyms
## Focus on use cases
Platform documentation should start with use cases rather than explanations. Engineers typically arrive with a task they want to complete, so documentation benefits from being organized around workflows instead of platform components.

Descriptive page titles make navigation significantly easier. Examples include:
- How to deploy a new microservice
- How to provision a managed database
- How to expose service metrics to the observability platform
- How to configure autoscaling for a Kubernetes workload

Pages structured around these workflows effectively define the platform’s “golden paths”, the recommended way of performing common tasks.

Incident documentation deserves particular attention. These pages are often consulted under time pressure and should clearly describe troubleshooting tools, mitigation steps, escalation paths, and how to reach the appropriate support teams.
### Do
- Organize documentation around concrete workflows
- Use clear, task-oriented page titles
### Don't
- Use vague or generic page titles
- Organize documentation primarily around platform components
## Make documentation easy to skim
Documentation pages should serve both readers who study the material carefully and those who are looking to find specific information quickly. Keeping the aforementioned personas in mind while adhering to a clear structure helps meeting the needs of different audiences.

A clear page layout begins with a short introduction stating the page’s purpose and what readers can achieve by following it. List any prerequisite knowledge at the top, and when possible, link to learning resources so less experienced developers can fill gaps before continuing.

Contextual explanations should be separated into clearly marked sections or headings, allowing those who need additional background to read them, while more experienced engineers can skip them. Step-by-step walkthroughs should remain explicit and complete, with explanations included in dedicated sections unless critical to understanding a specific step.

This approach ensures that pages are navigable, accessible, and useful for readers with different levels of experience, making it easy to find the information needed without unnecessary reading.
### Do
- Structure pages so engineers can quickly scan for relevant sections
- Start pages with a short description of their purpose
- Link to prerequisite knowledge when tasks require prior understanding
- Separate contextual explanations from instructions
- Provide explicit step-by-step guidance for common tasks
### Don't
- Hide instructions inside long explanatory sections
## Centralize documentation
Documentation is most effective when it has a clear home. In many organizations it gradually spreads across repository READMEs, wiki pages, and internal knowledge bases. This fragmentation makes information harder to find and reduces confidence in its accuracy.

Ideally, platform documentation lives in a single location such as a documentation site generated from Markdown files or a well-structured company wiki. When consolidation is not immediately possible, establish a primary entry point to provide a consistent starting location. From there, link to secondary sources as needed to guide readers to additional information.
### Do
- Maintain a central entry point for documentation
- Include troubleshooting steps and escalation paths
### Don't
- Scatter documentation across multiple locations
## Encourage contributions
Platform documentation improves when it is treated as a shared asset rather than the responsibility of a single team.

Readers should have clear ways to provide feedback, suggest improvements, and contact the platform team. Contribution workflows strongly influence participation. Many engineers hesitate to directly edit wiki pages where changes become visible immediately.

Version-controlled documentation often lowers this barrier. When documentation lives in a Git repository, contributors can propose changes through pull requests, a workflow familiar to most engineers. Review processes help maintain consistency and distribute the work across contributors and reviewers.
### Do
- Enable contributions through version-controlled workflows
### Don't
 - Require developers to contact the platform team to understand basic workflows

## Using AI as a documentation assistant
AI tools can assist with drafting and maintaining documentation when provided with clear guidelines.

One useful approach is defining an instruction file such as `AGENTS.md` that describes the expected structure and conventions of documentation pages. It can include the preferred page structure, formatting rules, and typical documentation patterns.

With these guidelines in place, AI tools can help transform rough notes into structured documentation and identify gaps or unclear sections. Clear rules and examples significantly improve the usefulness of generated content.
### Do
- Provide clear writing guidelines and documentation structure for AI tools
- Use AI to turn rough notes into structured documentation
- Use AI to review drafts for clarity, structure, and potential gaps

## Where to go from here
Once documentation clearly describes the platform’s workflows, it often becomes easier to identify opportunities for improvement. Documented processes reveal repeated manual steps, unnecessary configuration choices, or workflows that could be simplified.

These observations lead to platform improvements such as automation, higher-level abstractions, or sensible defaults that reduce cognitive load for engineers. As the platform becomes more intuitive and workflows more guided, documentation can shrink. In a mature platform, some documentation may even become unnecessary altogether, because the developer experience itself is clear and largely self-explanatory.
### Do
- Use documented workflows to identify opportunities for automation and simplification
## Conclusion
Platform engineering discussions often focus on infrastructure, tooling, and architecture. Documentation rarely receives the same attention, yet it strongly influences how a platform is experienced by its users.

Clear documentation makes workflows visible, establishes common patterns, and reduces the need for informal support channels. In many organizations, this is where platform engineering quietly begins. Once workflows are documented, they become easier to standardize, automate, and improve. Over time, documentation does not just describe the platform, it helps shape it.

For that reason, improving platform documentation is rarely only a documentation exercise. It is often one of the first practical steps toward a more deliberate and mature developer platform.

Platform Engineer, Cloud Solution Architect

In diesem Artikel beschreiben wir gesammelte Best Practices für das Integration Testing von Microservices. Zu diesem Zweck haben wir ein Projekt namens <a href="https://github.com/codecentric/toti-example-service"  target="_blank">toti-example-service</a> erstellt und auf GitHub veröffentlicht. Wir werden uns in diesem Beitrag immer wieder auf dieses Projekt und auf den Quelltext beziehen.

## Kurzer Überblick über das Demo-Projekt
Das Projekt haben wir mit Kotlin und dem Spring-Boot-Framework erstellt. Es enthält beispielhaft zwei REST-Endpunkte, um die Interaktion mit einer Datenbank sowie einem anderen Microservice zu demonstrieren. Wie üblich bei Spring haben wir im Projekt verschiedene Schichten implementiert, wie Controller, Services, Repositories und Web-Clients.

Im Folgenden sind die Funktionalitäten der Beispielanwendung zu sehen:

![image.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4MuzMwhQwSdyZAdlMtRy)

Wie auf der Abbildung zu erkennen ist, wurde eine Funktionalität für Blogposts implementiert. Diese kann man in einer DynamoDB-Tabelle verwalten, und es steht eine einfache CRUD-API zur Verfügung.

Die zweite Funktionalität demonstriert die Kommunikation mit einem anderen Microservice. Hierbei ist es möglich, einen oder mehrere Fakten über Katzen (CatFacts) abzurufen. Diese werden im Hintergrund über einen WebClient von einer öffentlichen API abgefragt.

## Warum Integration Testing?
Wir stellen immer wieder fest, dass Integrationstests in Projekten zu wenig Beachtung finden und dementsprechend selten genutzt werden. Dabei hat sich gezeigt, dass sie einen großen Beitrag zur Sicherheit und Stabilität der Schnittstellen leisten können, da sie den Service als Black Box betrachten. Diese Sichtweise führt dazu, dass der Service aus der Sicht eines externen Systems getestet wird, was zur Verbesserung der Schnittstellen-Stabilität beiträgt.

Durch die Gewährleistung der Stabilität der Schnittstelle bieten Integrationstests bei Refactorings eine große Sicherheit, da der API-Vertrag garantiert unverändert bleibt. Dies erleichtert es, sowohl die interne Datenstruktur als auch die Implementierung eines Microservices zu ändern.

Im Projektalltag hat es sich mittlerweile etabliert, Fehler zunächst mit einem Integrationstest zu reproduzieren, bevor man sie behebt. Dadurch wird sichergestellt, dass der Fehler nicht erneut auftritt, und Sonderfälle sowie Ausnahmen sind im Quellcode dokumentiert – gegebenenfalls inklusive der Ticketnummer. Integrationstests helfen somit nicht nur bei der Stabilität der Software, sondern auch bei der Dokumentation von Ausnahmefällen.


## Was wir unter einem Integrationstest verstehen

Es kommt häufig vor, dass es Missverständnisse darüber gibt, was ein Integrationstest umfasst und was ihn ausmacht. Wir verstehen darunter einen Test, bei dem der Microservice unter möglichst realistischen Bedingungen getestet wird. Das bedeutet, dass der gesamte Quellcode, der auch in Produktion ausgeführt wird, getestet werden sollte – und auch ausschließlich dieser. Konkret bedeutet dies:

- Keine Beans überschreiben
- Keine Extra-Konfiguration, keine *TestConfiguration*
- keine Mocks des Quelltexts
- **echte Http-Aufrufe**
- **echte Persistenz in einer Datenbank** (z. B. PostgreSQL ausgeführt in Docker, …)


## Abgrenzung zu anderen Testarten
**Abgrenzung zu Unit-Tests:**
- Unit-Tests konzentrieren sich auf individuelle Komponenten, während Integrationstests die Zusammenarbeit zwischen Komponenten prüfen.
- Unit-Tests sind in der Regel schneller, da sie in Isolation ausgeführt werden, während Integrationstests mehr Zeit in Anspruch nehmen können, da sie die Interaktion zwischen Komponenten testen.

**Abgrenzung zu End-to-End-(E2E-)Tests:**
- E2E-Tests testen das gesamte System aus der Perspektive des Benutzers, während sich Integrationstests auf die Interaktionen zwischen Komponenten konzentrieren.
- E2E-Tests sind in der Regel langsamer als Integrationstests, da sie das gesamte System testen und oft komplexere Testumgebungen und -szenarien erfordern.


**Abgrenzung zu Performance-Tests:**
- Performance-Tests messen Leistungskennzahlen wie Antwortzeiten, Durchsatz und Ressourcenverbrauch, während Integrationstests die Funktionalität und Zusammenarbeit zwischen Komponenten testen.
- Performance-Tests haben den Fokus auf die Leistung und nicht auf die Funktionalität, während sich Integrationstests darauf konzentrieren, ob die Komponenten korrekt zusammenarbeiten.
## Wie sieht das in unserem Beispiel aus?

Um die zuvor genannten Anforderungen zu erfüllen, nutzen wir verschiedene Frameworks wie zum Beispiel <a href="https://wiremock.org/"  target="_blank">Wiremock</a>, <a href="https://greenmail-mail-test.github.io/greenmail/"  target="_blank">Greenmail SMTP Server</a>, <a href="https://www.testcontainers.org/modules/databases/postgres/"  target="_blank">Datenbanken in Docker</a> oder <a href="https://www.testcontainers.org/modules/localstack/"  target="_blank">AWS Localstack</a>. Auf diese Weise stellen wir sicher, dass die produktive Umgebung im Test möglichst genau nachgebildet wird. Konkret bedeutet dies:

![image.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/d8R1xzzTiBJKLIpZAwYg)

In der Grafik wird deutlich, dass unser Microservice als Black Box betrachtet wird (grüne Box). Die Testumgebung wird möglichst realitätsnah nachgebildet, wie an den Boxen *Wiremock* und *Docker*(DynamoDb) zu erkennen ist. Der Test nutzt den HTTP-Server Wiremock und startet den Docker-Container, bevor die Testfälle ausgeführt werden. Anschließend ruft der Test unseren Microservice über die Rest-API auf, um beispielsweise Entitäten zu erstellen und abzurufen. Dies ist ein Beispiel für ein Integrationstest-Setup.

Hier eine Liste möglicher Frameworks zum Mocken des Microservice-Umfelds:
- Testcontainer: Postgres Dockerfile
- Testcontainer: Oracle Dockerfile
- Testcontainer: InfluxDb Dockerfile
- Testcontainer: Local DynamoDB Dockerfile
- Testcontainer: AWS Localstack (z. B. für SQS, SNS)
- Wiremock (leichtgewichtiger HTTP-Server, um andere Microservices zu mocken)
- GreenMail - SMTP Server Mock
- UnboundID LDAP Server Mock
- Eigene Extensions, um bspw. eine UDP Verbindung zu mocken


## Testcontainer am Beispiel DynamoDB als JUnit 5 Extension

Um das Testcontainer-Framework vor dem Start aller Tests zu initialisieren und hochzufahren, müssen die Daten für die Verbindung zum Container (Host, Port) in der Spring-Umgebung bekannt gemacht werden. Wir haben dabei gute Erfahrungen mit der Kapselung dieser Schritte in einer JUnit 5 Extension gemacht:

```kotlin

class DynamoDbLocalExtension : BeforeAllCallback {

    companion object {
        @JvmStatic
        var container = DynamoDbLocalContainer()

        @JvmStatic
        var initialized = false
    }

    override fun beforeAll(context: ExtensionContext) {
            if (!initialized) {
                container.withExposedPorts(8000)
                    .start()
                System.setProperty(
                    "dynamo.endpoint",
                     "http://${container.containerIpAddress}:${container.getMappedPort(port)}"
            )

                )

                createTables(context)
            }
    }

    private fun createTables(context: ExtensionContext) {
        val blogPostRepository = SpringExtension.getApplicationContext(context).getBean(BlogPostRepository::class.java)
        blogPostRepository.blogPostTable().createTable()
    }

    class DynamoDbLocalContainer : GenericContainer<DynamoDbLocalContainer>("amazon/dynamodb-local:latest")
}

```

Die JUnit 5 Extension erweitert den *BeforeAllCallback*, um sicherzustellen, dass die Initialisierung vor dem Hochfahren des Spring-Contexts stattfindet. Dabei werden die Konfigurationsparameter gesetzt und beim Hochfahren des Spring-Contexts dynamisch geladen.

Es ist jedoch zu beachten, dass die Methode *beforeAll* vor jeder Testklasse aufgerufen wird. Um sicherzustellen, dass der Container nur einmal initialisiert wird, verwenden wir die statische *initialized*-Property. Daher verzichten wir auch auf die automatisierte Verwaltung des Frameworks, die über die Annotation *@Container* gesteuert wird. Diese würde dazu führen, dass der Container nach jedem Test heruntergefahren wird.

## Performance-Überlegungen
In verschiedenen Projekten wurde argumentiert, dass das Starten mehrerer Docker-Container viele Ressourcen des Host-Systems verbraucht und daher nicht praktikabel ist. Heutzutage ist dies jedoch kein Problem mehr, da in der Regel alle Computer, insbesondere die von Entwicklern, mit ausreichenden Ressourcen ausgestattet sind. Im praktischen Betrieb ergeben sich in der Regel keine Probleme.

Sollte es dennoch zu Engpässen kommen, besteht die Möglichkeit,  <a href="https://www.testcontainers.cloud/"  target="_blank">Testcontainers in der Cloud von atomicjar</a>  zu verwenden.

Durch die Möglichkeit, alle Umgebungssysteme eines Services durch Container abzubilden, entsteht im Integrationstest eine zusätzliche Umgebung. So ist es unserer Meinung nach möglich, mit nur zwei Umgebungen (zum Beispiel Staging und Production) zu arbeiten und die Tests als Development-Umgebung zu betrachten.

## Beispiel für einen Integrationstest
Abschließend möchten wir ein kurzes Beispiel vorstellen, wie man einen Test konkret implementieren kann. Wir wollen hier die Schnittstelle zum Anlegen eines Blogposts ansprechen und testen, ob diese den Post korrekt anlegt und zurückgibt:

```kotlin

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@ExtendWith(DynamoDbLocalExtension::class)
class BlogPostIntegrationTest {
    companion object {
        @JvmStatic
        @RegisterExtension
        val rest = WebTestClientExtention()
    }

    @Test
    internal fun `should create blog post and return it`() {
        val id = IdGenerator.nextAsLong()
        rest.webTestClient.put()
            .uri { uriBuilder ->
                uriBuilder.path("/blogposts/{id}")
                    .build(id)
            }.bodyValue(
                """
                {
                   "id": $id,
                   "title": "some title 2",
                   "content": "the content 2"
                }
            """.trimIndent()
            )
            .headers { headers -> headers.contentType = MediaType.APPLICATION_JSON }
            .exchange()
            .expectStatus().is2xxSuccessful
            .expectBody().json("""
                {
                   "id": $id,
                   "title": "some title 2",
                   "content": "the content 2"
                }
            """.trimIndent())
    }

}

```
In dem obigen Test Case wird deutlich, dass die zuvor angesprochene JUnit Extension mithilfe der *@ExtendWith*-Annotation verwendet wird, um sicherzustellen, dass die lokale DynamoDB vor dem Test hochgefahren und initialisiert wird. Anschließend rufen wir den Service über den *WebTestClient* von Spring Boot wie in einem externen System auf. In diesem Beispiel wird die Antwort nur auf das JSON-Dokument und den HTTP-Status geprüft, aber es könnten auch umfangreichere Validierungen durchgeführt werden. Ein bewährtes Framework für Validierungen ist beispielsweise <a href="https://assertj.github.io/doc/"  target="_blank">assertJ</a>, das sich hier gut einfügt.

**Takeaways:**
- Integrationstests sind wichtig für stabile und sichere Schnittstellen in Microservices.
- Der Test sollte den Service als Black Box betrachten und unter realistischen Bedingungen durchführen.
- Frameworks wie Wiremock, SMTP Server, Datenbanken in Docker oder AWS Localstack können ein praktikables Integrationstest-Setup bereitstellen.
- Die Abbildung aller Umgebungssysteme eines Services durch Container schafft im Integrationstest eine zusätzliche Umgebung.
- Parallelisierung von Integrationstests kann Testdauer verkürzen und Testabdeckung verbessern.
- Integrationstests sollten automatisiert in den Entwicklungsprozess durch Continuous Integration/Continuous Delivery integriert werden.
- Integrationstests geben ein gutes Gefühl, da die Schnittstellen nach außen garantiert funktionieren.


Wir bedanken uns für das Lesen dieses Beitrags und hoffen, einige Denkanstöße zum Thema Integration Testing gegeben zu haben. Wir werden diese Gedanken in weiteren Beiträgen vertiefen; der nächste wird sich mit dem Thema der Parallelisierung dieser Tests befassen.



Microservice Integration Testing done right 

Senior IT Consultant

VueJS performance tips. Part I

VueJS performance tips. Part II

I'm an interviewer: how to prepare if I am a techie, not a hiring manager

Frontend Developer

<p><em>Die Luft ist zum Schneiden, der Beamer rauscht auf höchster Stufe und die Hemden vieler Teilnehmer sehen alles andere als frisch aus. Erleichterte Blicke, als der PO dem Team dankt und das Planungsmeeting beenden will – „Aber“, fällt ihm da eine Entwicklerin aus der hinteren Ecke des Raumes ins Wort, „für meine Komponente gibt es in diesem Sprint noch überhaupt nichts zu tun.“ Also, alle wieder hinsetzen, alles zurück auf null und noch mal von vorne beginnen mit dem Zuweisen der Stories in den Sprint.</em></p><p>In vielen Scrum-Projekten, in denen ich über die letzten Jahre gearbeitet habe, gab es ein ähnliches Problem: Die benötigten Technologien sind sehr heterogen und die Entwickler daher zu spezialisiert, als dass sie in allen Bereichen des Projektes eingesetzt werden könnten. Im Folgenden erläutere ich daraus resultierende Probleme und zeige verschiede Lösungsansätze.</p><p><span></span></p><p>Besonders Projekte, die neue Technologien in einem größeren Legacy-IT-Umfeld einführen, neigen durch den Mix an Alt und Neu dazu, eine große Menge an Sprachen, Frameworks und Tools zu beinhalten. Als Beispiel ein Technologie-Stack aus einem aktuellen Projekt: <em>PhoneGap, AngularJS, Node.js, Java-Middleware, XML-basierte Messaging-Sprache, Oracle Database</em>. Dazu kommen all die kleinen Tools und Frameworks, die in agiler Software-Entwicklung vorausgesetzt werden. Wer agiles Vorgehen schon mit der Entwickler-Muttermilch aufgesogen hat, neigt dazu, den zusätzlichen Lernaufwand zu unterschätzen, den es braucht, um TDD zu verinnerlichen, Mockito zu verwenden, Maven-Skripte auf dem CI-Server und eine Test Coverage-Analyse in seiner IDE ausführen zu lassen. Die Menge an neuem Wissen und Vorgehen, die Menschen lernen können, ist begrenzt. Es gilt also, die richtigen Prioritäten zu setzen. Doch dazu später mehr.</p><h2>Das Feature-Team</h2><p>Die optimale Größe eines Development-Teams liegt laut Scrum-Guide bei drei bis neun Entwicklern. Möchte man Feature-Teams bilden, so sollten diese Entwickler in der Lage sein, ohne externe Hilfe einen Wert für den Kunden zu schaffen. Also Anforderungen komplett von der UI bis zur Persistenz zu entwickeln.</p><blockquote><p>“Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Having more than nine members requires too much coordination.” <a href="http://www.scrumguides.org/scrum-guide.html" target="_blank">(1)</a> </p></blockquote><p> </p><blockquote><p>“‘A feature team is a long-lived, cross-functional, cross-component team that completes end-to-end customer features—one by one.’ Feature teams are an essential element to scaling up agile development.” <a href="http://www.featureteamprimer.org/" target="_blank">(2)</a> </p></blockquote><p>Der Scrum-Guide spricht explizit nur von Entwicklern, egal welche Rolle sie im Development-Team einnehmen. Trotzdem erkennen die Autoren an, dass es in einem Team Spezialisierungen geben kann, wobei die Verantwortung für die Entwicklung aller Teile immer beim gesamten Team verbleibt:</p><blockquote><p>“Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”  <a href="http://www.scrumguides.org/scrum-guide.html" target="_blank">(1)</a> </p></blockquote><h2>Das Komponenten-Feature-Team</h2><p>Schauen wir einem imaginären Project Manager über die Schulter, wie er ein Entwickler-Team für den oben genannten Technologie-Stack zusammengestellt hat:</p><ul><li>2 Tester, da das Team wenig Erfahrung in Testautomatisierung hat.</li><li>1 UX / UI-Experte, verantwortlich für Design und Implementierung der Oberfläche.</li><li>1 PhoneGap-Entwickler.</li><li>1 JS-Entwickler, für AngularJS und Node.js.</li><li>2 Java-Entwickler, verantwortlich für die Middleware-Komponenten.</li><li>1 Entwickler für die XML-basierte Messaging-Sprache.</li><li>1 Oracle Datenbank-Spezialist.</li></ul><p>Das Ergebnis ist ernüchternd. Um ein Feature-Team zu bilden, das alle Bereiche der Entwicklung abdecken kann, haben wir für die meisten Bereiche nur einen Entwickler.</p><p>Die negativen Folgen liegen auf der Hand: Es bilden sich Wissenssilos, Code-Reviews und Pair-Programming sind deutlich erschwert. Der Abgang eines Entwicklers kann das gesamte Projekt in Schieflage bringen. Die andere Seite ist, dass es einen deutlichen Overhead in der Planung gibt. <strong>Der eindimensionale Velocity-Wert ist zur Planung nicht mehr ausreichend.</strong> Das Commitment des Teams wird es nur geben, wenn es in keinem der Technologie-Bereiche einen Engpass gibt. Damit bleiben Product Owner und Entwickler während der Planung zwangsweise im alten Komponentendenken hängen. Es kann passieren, dass der Product Owner die User Stories wieder mehr als Komponenten-Stories schreibt, da diese scheinbar einfacher zu planen sind. Durch die Fokussierung auf Komponenten wird aber gegen zwei wichtige <a href="https://en.wikipedia.org/wiki/INVEST_(mnemonic)" target="_blank">INVEST</a> -Faktoren verstoßen – die Stories sind nicht mehr unabhängig voneinander und sie liefern alleine keinerlei Wert für den Kunden. Aus agiler Sicht ist diese Lösung daher eine der schlechtesten.</p><h2>Lösungsansätze</h2><h3><h3>1) Mehr Flexibilität der Entwickler</h3><p>Die häufigste Antwort auf das geschilderte Problem ist, dass sich die Entwickler weiterbilden sollen und werden. Der Java-Entwickler lernt JavaScript und der Datenbank-Entwickler wird zum Teilzeit-Java-Entwickler. Der <em>Feature Team Primer</em> spricht davon, dass die Teams zum Lernen gezwungen werden.</p><blockquote><p>A feature team organization exploits speed benefits from specialization, as long as requirements map to the skills of the teams. But when requirements do not map to the skills of the teams, learning is ‘forced,’ breaking the overspecialization constraint. Feature teams balance specialization and flexibility. <a href="http://www.featureteamprimer.org/" target="_blank">(2)</a> </p></blockquote><p>Aus meiner Erfahrung funktioniert dies in vielen Fällen nicht. Wie weiter oben bereits erwähnt, sind der Wille und die Fähigkeit zum Lernen begrenzt. Die Einführung von agilen Feature-Teams beinhaltet schon viel Neues. Auch für Entwickler, die schon länger mit agilen Methoden arbeiten, gibt es – ganz im Sinne von Continuous Improvement – immer noch vieles zu lernen und zu verbessern. Wenn Sie wählen müssten, ob ein Kollege agiles Vorgehen wie Test-Driven-Development verbessert, oder ob er ein mittelmäßiger Teilzeit-Frontend-Entwickler wird. Nun ja…</p><p>Eine gewisse Spezialisierung ist hilfreich, damit sich Expertentum bilden kann. Nur Experten werden in ihrem Bereich sehr gute Lösungen finden und implementieren können. Nur Experten werden Verantwortung für zukunftsfähige Lösungen in ihrem Bereich übernehmen.</p><p>Fazit: Die Flexibilitätssteigerung ist erstrebenswert, aber sie kann nur für solche Teams eine Lösung sein, die schon länger agil entwickeln und in denen es eine sehr hohe Lernbereitschaft gibt.</p><h3>2) Komponenten-Teams</h3><p>Eine Möglichkeit, die Komplexität und Anzahl der Technologien zu reduzieren ist Komponenten-Teams einzuführen. Anstatt eines gibt es zwei Entwicklungsteams, die zum Beispiel Frontend und Backend-Technologie untereinander aufgeteilt haben. Es gibt Vorteile: Die Scrum-Meetings sind fokussierter. Die Zusammenarbeit im Team wird erleichtert, die Verantwortung für die entwickelten Komponenten wächst. Die Teamaufteilung ist in vielen Unternehmen näher an der klassischen (gewohnten) Organisation.</p><p>Die Nachteile aber sind vielfältig:</p><ul><li>Dadurch, dass keine User Stories, sondern Komponenten-Stories bearbeitet werden, steigt der Planungsoverhead. Es müssten Integrationsphasen und daraus entstehende Rückläufer eingeplant werden.</li><li>Das Risiko von <a href="https://de.wikipedia.org/wiki/Muda" target="_blank">unnötigem Aufwand</a>  steigt: Komponenten werden „auf Halde“ erweitert, ohne zu wissen, ob darauf aufbauende Features von anderen Teams jemals umgesetzt werden.</li><li>Durch falsch verstandene Schnittstellen können leicht Bugs entstehen.</li><li>Komponententeams können weniger Feedback zu Produktdesign und Implementierungsmöglichkeiten geben. Das <em>Warum</em> geht verloren, wenn Teams detaillierte technische Komponentenstories als Input erhalten.</li><li>Nicht-funktionale Anforderungen sind schwieriger einzuhalten, da die Verantwortlichkeit dafür diffundiert.</li><li>Es ist schwieriger Tester schon während der Entwicklung einzubeziehen.</li></ul><p>Fazit: „It depends“ – Komponenten-Teams können in bestimmten Umgebungen Vorteile bieten, doch haben sie gegenüber Feature-Teams in der agilen Entwicklung insgesamt eine erhebliche Anzahl an Nachteilen. Lassen sich Komponententeams nicht vermeiden, so können einige der Nachteile durch überlappende Plannungsmeetings und automatisiertes Contract-Testing abmildern.</p><h3>3) Größere Teams</h3><p>Ein naheliegender Ansatz ist es, das Team zu vergrößern. Der Vorteil dieser Lösung ist die sehr einfache Umsetzung. Bereiche mit dem<a href="https://de.wikipedia.org/wiki/Truck_Number" target="_blank"> Bus-Faktor </a> von 1 können sehr schnell personell verstärkt werden. Ich habe schon Scrum-Teams mit 16 Entwicklern gesehen.</p><p>Es gibt allerdings auch hier einige Nachteile. Erstens wird die Aufteilung in gefühlte Komponententeams innerhalb des Scrum-Teams noch zunehmen. Der zweite Nachteil nennt bereits der oben zitierte Scrum-Guide: Der Aufwand für Kommunikation und Koordination im Team nimmt stark zu. Möchte man, dass alle Teammitglieder täglich ein paar Worte direkt miteinander wechseln, sind in einem 8-köpfigen Team 28 Gespräche nötig. Bei 16 Personen müssten täglich schon 120 Gespräche geführt werden. Durch die Größe des Teams steigt auch die Velocity stark an. Klingt erst mal gut. Doch bei zu vielen User Stories in einem Sprint wird es schwierig den Fokus zu behalten. Die täglichen Standup-Meetings, wie auch Planung und Demo, dauern zu lang. Schnell passiert es dann, dass Entwickler nicht mehr aktiv teilnehmen, da der Nutzen im Vergleich zum Aufwand infrage gestellt wird.</p><p>Fazit: Die Vergrößerung des Teams scheint eine schnelle Lösung sein, um ein Wissenssilo oder einen Engpass abzubauen. Komponentengrenzen können so aber nicht aufgelöst werden. Langfristig überwiegen auch hier die negativen Folgen.</p><h3>4) Reduktion der Technologien</h3><p>Ein weiterer möglicher Lösungsansatz ist es die Anzahl der verwendeten Technologien zu reduzieren. Man würde sich wünschen, dass für jede neue Technologie mindestens eine alte aus dem Projekt entfernt wird. Wie in einem guten Bücherregal, aus dem man für jedes neue Buch auch eines herausnehmen muss – und so für eine stetige Qualitätssicherung und Perfektionierung sorgt. In der Praxis geschieht diese Technologie-Reduktion leider aus unterschiedlichsten Gründen oft nicht. Dabei sollten die hier zuvor genannten Probleme und Herausforderungen deutlich machen, dass es nicht unbedingt sinnvoll ist, neue Technologien einzuführen, wenn man alte dafür nicht ablösen kann.</p><p>Ist es nicht möglich, die Anzahl der Technologien im Projekt zu reduzieren, kann eine andere Strategie helfen. Im DDD gibt es das Konzept der Anti-Corruption-Layer (ACL), die verhindern, dass das eigene Domänenmodell durch unsaubere externe Schnittstellen verschmutzt wird. Durch ein technologisches ACL kann man eine Legacy-Technologie vor einem Entwicklungs-Team verbergen. Ob es die moderne REST-Fassade vor einem alten Hostsystem ist, oder die moderne Messaging-Technologie als Adapter zu einem alten selbstentwickelten System. Auf diese Weise können Komplexitäten verringert werden.</p><p>Fazit: Die Reduktion der verwendeten Technologien ist die nachhaltigste, aber auch die am schwierigsten umzusetzende Lösung. Beim Starten agiler Projekte sollte darauf geachtet werden, nicht leichtfertig neue Technologien einzuführen, wenn dafür nicht auch alte entfernt werden können. Frameworks wie Vaadin könnten dabei helfen, Barrieren zwischen Frontend- und Backend-Entwicklern zu verringern. Andere <a href="https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/" target="_blank">Firmen</a>  haben sich für Node.js im Frontend- und Backend entschieden, um einen homogeneren Technology-Stack zu haben. In einer heterogenen Umgebung können Legacy-Technologien durch technologische ACL verborgen werden.</p><p>Zusammengefasst: Ein heterogener Technologiestack stellt jedes Entwicklungsteam vor eine Herausforderung. Eine Flexibilitätssteigerung des Entwicklungsteams ist erstrebenswert. Notwendig ist, dass sich für jede Technologie neben dem/der Experten/in weitere Entwickler Basiswissen erarbeiten. Langfristig wird es sich auszahlen, die Anzahl der Technologien zu reduzieren.</p><p> </p><p><em>Keine der oben genannten Lösungsansätze ist einfach oder kommt ohne Nachteile aus. Gerne stelle ich daher die Frage nach weiteren Strategien und Lösungen an die Leser: Kennt ihr die beschriebene Problematik und habt ihr weitere Ideen zur Verbesserung? Ich freue mich über eure Kommentare.</em></p></h3>

Spezialisierung in Agilen Feature-Teams

<p>Der Herr, der eben beim Auspacken seines Laptops beinahe meinen Kaffeebecher umgestoßen hat, schaut kurz auf meinen Bildschirm und sieht den geöffneten Hystrix-Vortrag. Ja, von Hystrix hat er schon einmal gehört, hat sein Team ihm vorgeschlagen, soll gut funktionieren. Doch dann holt er Luft für sein großes Aber: “Warum sollte ich meinen Entwicklern Zeit dafür geben ein Framework einzuführen, das ihnen hilft auf Ausfälle und Fehler zu reagieren? Ich möchte, dass sie in der Zeit stattdessen verhindern, dass diese Fehler überhaupt auftreten”.</p><p><span></span></p><p><span>Ich vermute, dass ich wohl erst nach Göttingen an dem Vortrag weiter arbeiten kann, klappe den Rechner zu und beginne zu erzählen: In komplexen verteilten Systemen sind Ausfälle und Fehler immanent; Systeme, die nicht fehlertolerant sind, werden keine zufriedenstellende User-Experience bieten können. Der Einsatz von Hystrix sensibilisiert Entwickler beim Einbinden von externen Diensten über den möglichen Einfluss auf das eigene System nachzudenken.</span></p><p><span>In verteilten Systemen addieren sich die Ausfallzeiten: Angenommen das Team meines Sitznachbarn schafft es, dass jeder Service zu 99,99% erreichbar ist, also deutlich unter 5 Minuten Downtime pro Monat hat. Wenn man dann weiter annimmt, dass ihre Microservice-Architektur aus 30 unabhängigen Services besteht, dann werden nur noch zu 99,7% der Zeit alle Services verfügbar sein – oder anders gesagt: Fast zweieinviertel Stunden pro Monat, ist nicht das komplette System verfügbar. Sind die Services nicht verfügbar oder fehlerhaft, sind die Kunden unzufrieden und man verdient kein Geld mit ihnen – kurzum: die Software ist wertlos.</span></p><p><span>Die oben skizzierte Erkenntnis führt zu dem Mantra der Resilience-Bewegung: </span><i><span>“Do not try to avoid failures. Embrace them”. </span></i><span>Wer mehr Details über die Grundlagen von Resilience und Resilient Software Design erfahren möchte, sei auf die gute<a href="https://jaxenter.de/unkaputtbar-einfuehrung-resilient-software-design-15119"> Resilience-Einführung</a>  oder den Talk über <a href="https://www.youtube.com/watch?v=T9MPDmw6MNI">Resilience-Patterns </a> von Uwe Friedrichsen verwiesen.</span></p><p><span>Wir wollen also mit den Fehlern umgehen, anstatt zu versuchen, sie zu vermeiden. Eine Technologie um diese sogenannte Resiliance zu erreichen ist Hystrix, ein Java-Framework aus dem Netflix Open Source Stack. Die Entkopplung einzelner Services in verteilten Systemen ist die Kernaufgabe von Hystrix; und damit der Aufbau eines robusten und fehlertoleranten Systems.</span></p><h2>Die wichtigsten Eigenschaften von Hystrix</h2><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/tU7LoSipQMCut1NKMWOL"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/tU7LoSipQMCut1NKMWOL" alt="hystrix-features" width="700" height="334" /></a> </p><p> </p><ul><li><span>Alle Aufrufe von externen Systemen werden in HystrixCommands verpackt, welche typischerweise in einem separaten Thread ausgeführt werden.</span></li><li><span>Aufrufe werden abgebrochen, wenn sie mehr Zeit brauchen als vorab als Obergrenze festgelegt wurde. Es muss also z.B. nicht mehr auf Netzwerk- oder Datenbank-Timeouts gewartet werden, bis eine Programmausführung fortgesetzt werden kann.</span></li><li><span>Für jede externe Abhängigkeit wird ein eigener kleiner Thread-Pool verwaltet. Damit wird verhindert, dass eine einzelne fehlerhafte Abhängigkeit ein ganzes System non-responsive machen kann.</span></li><li>Die Ausführungszeiten, Erfolge und Fehler eines jeden HystrixCommands werden gemessen, erfasst und in einem Dashboard zur Verfügung gestellt.</li><li><span>Ein circuit-breaker stoppt alle Aufrufe einer externen Abhängigkeit, die derzeit nicht erreichbar oder fehlerhaft ist. </span></li><li><span>Es können Fallback-Logiken implementiert werden, für den Fall, dass externe Abhängigkeiten keine oder fehlerhafte Antworten liefern.</span></li></ul><h2>Hello World mit Hystrix</h2><p>Nach der Einführung in die grundlegenden Konzepte von Hystrix wird es Zeit für ein Beispiel:</p><div>

```java
public class CommandHelloWorld extends HystrixCommand {
 
   private final String name;
 
   public CommandHelloWorld(String name) {
     super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
     this.name = name;
    }
 
   @Override
   protected String run() {
     //network call
     return getLocalizedGreeting(name);
    }
 
   @Override
   protected String getFallback() {
     //graceful degradation - use english as fallback
     return "Hello " + name + "!";
    }
 
    [...]
 }
```

</div><p>Der obige Code zeigt ein einfaches HystrixCommand, das versucht eine entferne Ressource aufzurufen um eine Begrüßung in der Sprache des Nutzers abzurufen. Sollte der Aufruf fehlschlagen, so wird als Fallback eine englische Begrüßung ausgegeben. Ein HystrixCommand kann synchron, asynchron oder mit dem Observer-Pattern ausgeführt werden:</p><p>1) Synchrone Ausführung</p><div>

```java
 String s = new CommandHelloWorld("World").execute();
```

</div><p>2) Asynchrone Ausführung</p><div>

```java
 Future fs = new CommandHelloWorld("World").queue();
 String s = fs.get();
```

</div><p>3) Observer-Pattern</p><div>

```java
 Observable fWorld = new CommandHelloWorld("World").observe();
 fWorld.subscribe((v) -> {
   System.out.println("onNext: " + v);
 })
```

</div><p>Die Wiki-Dokumentation des Hystrix-Projektes ist umfangreich und gut verständlich. Daher verzichte an dieser Stelle auf weitere Einstiegsbeispiele und verweise stattdessen auf <a href="https://github.com/Netflix/Hystrix/wiki/How-To-Use">das originale Tutorial bei GitHub.</a> </p><h2>Konfiguration und Metriken</h2><p><span>Hystrix ist schnell eingebaut, aber es gibt doch eine gewisse Lernkurve, die man einplanen sollte. Zum Beispiel für die Konfiguration: Die Möglichkeiten der Konfiguration sind umfangreich. Der Ansatz von Netflix ist es, die Kommandos in der Standardkonfiguration zu starten und dann im Betrieb zu messen, beobachten und feinzujustieren. Dafür braucht man zwingend dynamische Konfiguration und jemanden, der das Hystrix-Dashboard im Auge behält.</span></p><p><span>Auch langfristig sollte man die Metriken von Hystrix überwachen und die sehr umfangreichen Informationen nicht ungenutzt lassen. So kann man zum Beispiel die Hystrix Streams, bzw. deren aggregierte Informationen, in Elasticsearch speichern und langfristig aus den Metriken lernen</span></p><h2>Neues und Ausblick auf Hystrix 2.0</h2><p><span>Das aktuelle Hystrix-Release 1.5 beinhaltet Erweiterungen im Bereich der Metriken. Die Metric-Streams werden nun auch unaggregiert angeboten und können dadurch deutlich flexibler konsumiert und ausgewertet werden. Die HystrixCommands unterstützen seit Version 1.5.3 nun außerdem die Cancellation, so dass dem ausführenden Thread ein interrupt-Signal gesendet wird, wenn auf dem Future ein cancel() aufgerufen wird oder ein unsubscribe() auf der Subscription.</span></p><p><span>Für Hystrix 2.0 ist das Update auf Java 8 geplant – das wird die Verwendung von Hystrix deutlich kompakter machen.</span></p><h2>Fazit</h2><p>Es wurde erläutert warum in verteilten Systemen immer mit dem Ausfall von Resourcen gerechnet werden muss und wie die Funktionen von Hystrix dabei helfen ein Resilient-Software-Design zu erreichen.  Dieser Artikel ist ein kurzer Einstieg in das Thema und ist der Auftakt einer mehrteiligen Blogartikel-Serie zum Thema Hystrix in der verschiedene codecentric-Kollegen ihr Praxiswissen zum Thema teilen werden. Im nächsten Teil wird unter anderem das Thema dynamische Konfiguration von Hystrix beleuchtet werden.</p>

Hystrix: Fehlertoleranz statt Hochverfügbarkeit – Eine Einführung in Resilience mit Hystrix

<p>„Software-Entwicklung muss nicht wehtun“, sagt Nils Wloka in der ersten Folge von #EineMateMit, dem neuen IT-Talk-Format der codecentric. Wo es zuweilen schmerzte, und wie er dies abstellen möchte, erläutert der Kopf des codecentric Digitization Labs nach einem kurzen Schluck aus der Mate-Flasche. „Ich denke, dass es inzwischen sehr viele Schichten gibt, zwischen den Menschen, die Probleme mit Software lösen lassen wollen und den Menschen, die Probleme mit Software lösen können.“ Die meisten dieser Schichten und viele der deswegen notwendigen Rituale könne man entfernen, und so wieder „zu einer angenehmeren und effektiveren Art und Weise der Software-Entwicklung kommen“.</p><p><span></span></p><p> </p>
<a href="https://www.youtube.com/watch?v=heLtAebYugQ" target="_blank"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YwhNYeKIS6S4DIfGRUqZ" alt="YouTube" />
zum Video "Digitalisierung und Rapid-Prototyping | Eine Mate mit Nils Wloka #EineMateMit"</a>
<div></div>
<br>



<p><em>Eine Mate Mit </em>ist ein Format, in dem verschiedenste Menschen aus der IT-Branche aus ihren Projekten, und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei der codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Die Gemeinsamkeit der Interviews: <strong>Kurz, knackig, auf den Punkt</strong>.</p><h3>5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p><em>Eine Mate Mit</em> möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links, direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p> </p><p>Wir freuen uns auf eure Kommentare hier im Blog auf Twitter unter #EineMateMit oder auf youtube. Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen. Jeweils hier auf dem codecentric Blog und auf youtube.</p><p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2LLzp22LTSGB5bZYUUVw"> </p><p> </p><p>Weiterführende Links für die heutige Folge mit Nils Wloka:</p><p><a href="https://www.codecentric.de/leistungen/digitale-produktentwicklung">Die codecentric Digitization Labs</a>  bieten die Möglichkeit, digitale Produktideen<br /> unmittelbar mittels Software zu validieren.</p><p><a href="https://www.codecentric.de/wissens-hub/softwerker#softwerker-magazine">Der Digitalisierungs-Softwerker</a>  bietet einen guten Einblick in die Herausforderungen der Digitalisierung; auch und gerade für nicht-Entwickler.</p><p><a href="https://youtu.be/heLtAebYugQ">Und hier noch mal der Link auf das heutige #EineMateMit-Video mit Nils Wloka</a> </p><p> </p><p> </p>

Rapid-Prototyping und Digitization Labs. Eine Mate mit… Nils Wloka.

<p>„Die Software läuft halt einfach“, sagt Dieter Dirkes sichtlich zufrieden, als er über sein letztes großes Keycloak-Projekt erzählt. Dieses Projekt ist seit einem Jahr im Einsatz und bietet verteilt über 26 Länder Single-Sign-On (SSO), Idendentiy- und Access-Management. „Innerhalb von 2 Tagen hatten wir den ersten technischen Durchstich fertig“, sagt Dirkes, der Leiter des Münsteraner Standorts der codecentric AG. Eine technische Einordnung von SSO mit Keycloak, die Highlights und auch die Probleme, die in den Projekten entstanden sind, erzählt Dieter Dirkes in dieser Ausgabe von Eine Mate Mit.  #EineMateMit.</p><p><span></span></p><h2>Über Keycloak</h2><p>Komfortables Single Sign-On in einer professionellen Identity- und Accessmanagement (IAM) Umgebung – und das auch noch Open Source? Keycloak als OpenID Connect Provider macht’s möglich. Keycloak wird von Red Hat entwickelt und gefördert. Das Produkt ist komplett in Java geschrieben und bedient sich sehr ausgiebig an Red Hats Java Stack. So wird standardmässig WildFly als Applicationserver eingesetzt, und auch die Clustering- und HA-Funktionen von WildFly werden genutzt.</p><p> </p>


<a href="https://www.youtube.com/watch?v=YRoEtEjya5U" target="_blank"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/GfCV9ZySSi2CyPdMe4TM" alt="YouTube" />
zum Video "Was ist Keycloak? | Eine Mate mit Dieter Dirkes #EineMateMit"</a>
<div></div>
<br>

<p> </p><p><em>Eine Mate Mit </em>ist ein Format, in dem verschiedenste Menschen aus der IT-Branche aus ihren Projekten und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei der codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Die Gemeinsamkeit der Interviews: <strong>Kurz, knackig, auf den Punkt</strong>.</p><h3>#EineMateMit – 5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p><em>Eine Mate Mit</em> möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p>Wir freuen uns auf eure Kommentare hier im Blog, auf Twitter unter #EineMateMit oder auf youtube. Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen. Jeweils hier auf dem codecentric Blog und auf youtube.</p><p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2LLzp22LTSGB5bZYUUVw"> </p><p>Weiterführende Links für die heutige Folge mit Dieter Dirkes:</p><p>Die Projektseiten befinden sich unter <a href="http://keycloak.jboss.org/" target="_blank">http://keycloak.jboss.org</a> , die Sourcen sind in GitHub unter <a href="https://github.com/keycloak/keycloak" target="_blank">https://github.com/keycloak/keycloak</a>  zu finden. Lead-Entwickler sind im wesentlichen Stian Thorgersen, Bill Burke und Marek Posolda.</p>

Was ist Keycloak? Eine Mate mit… Dieter Dirkes zum Thema SSO #EineMateMit

<p>„Das Schöne ist, dass es eine klar definierte Schnittstelle zwischen Operations und Entwicklern gibt“, sagt Roland Huß, als er im Vorfeld des <a href="https://www.meetup.com/de-DE/DevOps-Frankfurt/events/241112360/" target="_blank">DevOps Meetups „Java-Entwicklung im Zeitalter von Kubernetes und OpenShift“</a>  über die Vorteile von Container-Lösungen für DevOps-Projekte spricht.</p><p>„Ich versuche heute zu zeigen, warum es auch für Java-Entwickler sinnvoll ist und auch Spaß machen kann, Applikationen mit Kubernetes zu deployen“, erzählt Roland Huß über seinen Vortrag.</p><p>Viele sprächen von einem neuem IT-Zeitalter bei dem Anwendungen in Container verpackt und von Orchestrierungsplattformen wie Kubernetes oder OpenShift skalierbar betrieben werden. „Tatsächlich spricht vieles dafür, dass wir unsere Java-Anwendungen künftig nicht mehr als JAR, WAR oder EAR Artefakte ausliefern werden sondern als Docker Container Images.“, so Huß. „Mein Vortrag zeigt wie dieser Übergang schmerzfrei vollzogen werden kann. Tools wie <em>minikube</em> oder <em>minishift</em> zeigen wie einfach es ist, komplexe Plattformen wie Kubernetes oder OpenShift mit einem einzigen Kommando zu installieren. Um ein bestehendes Projekt auf diese Umgebungen umzustellen helfen Werkzeuge wie das fabric8-maven-plugin.“</p><p><span></span></p><h2>Über Kubernetes und DevOps</h2><p>Kubernetes ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen. Es unterstützt Docker und andere Container-Tools. Kubernetes eignet sich hervorragend um Microservice-Anwendungen verteilt über mehrere Server auszuführen, und die Server-Ressourcen dabei optimal auszunutzen.</p><p>OpenShift bezeichnet sich als „enterprise-ready“ Container Application Platform, da es zu Docker und Kubernetes noch verschiedene DevOps-Tools und Support-Möglichkeiten hinzufügt.</p><p>Es gibt viele DevOps-Definitionen… Im Kern geht es darum, die Prozesse so zu verbessern, dass Betrieb und Entwicklung besser zusammenarbeiten können.</p>
<a href="https://www.youtube.com/watch?v=IO130Zb_vDA&t=13s" target="_blank"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/EruwaGUET3qhwnEVlQC1" alt="YouTube" />
zum Video "DevOps und Container | Eine Mate mit Roland Huß #EineMateMit"</a>
<div></div>
<br>
<p> </p><p><em>Eine Mate Mit </em>ist ein Format, in dem Menschen aus der IT-Branche aus ihren Projekten und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Was alle Interviews verbindet: <strong>Kurz, knackig, auf den Punkt</strong>.</p><h3>#EineMateMit – 5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p><em>Eine Mate Mit</em> möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p>Wir freuen uns auf eure Kommentare hier im Blog, auf YouTube oder auf Twitter unter #EineMateMit. Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen. Jeweils hier auf dem codecentric Blog und auf YouTube.</p>
<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2LLzp22LTSGB5bZYUUVw">
<p> </p><p>Weiterführende Links für die heutige Folge mit Roland Huß:</p><p>Kubernetes: <a href="https://kubernetes.io/" target="_blank">https://kubernetes.io/</a> </p><p>Open Shift: <a href="https://www.openshift.com/" target="_blank">https://www.openshift.com/</a> </p><p>Seite des DevOps-meetups: <a href="https://www.meetup.com/de-DE/DevOps-Frankfurt/events/241112360/" target="_blank">https://www.meetup.com/de-DE/DevOps-Frankfurt/events/241112360/</a> </p><p>fabric8: <a href="https://fabric8.io/" target="_blank">https://fabric8.io/</a> </p><p>Geschichte der Containerisierung (für Frachtgüter): <a href="https://de.wikipedia.org/wiki/Containertransport#Geschichte" target="_blank">https://de.wikipedia.org/wiki/Containertransport#Geschichte</a> </p><p> </p>

DevOps und Container: Eine Mate mit… Roland Huss. #EineMateMit

<p>„Da hab‘ ich gewusst, ich will User Story Mapping ab jetzt in jedem Projekt nutzen“, sagt Hias Wrba, als er davon erzählt, wie er das erste Mal die Methode „User Story Mapping“ nach Jeff Patton angewendet hat.</p><p>Mathias „Hias” Wrba arbeitet seit nunmehr fast 15 Jahren als quereingestiegener User-Experience-Stratege und -Designer im Bereich digitale Medien. Seine Schwerpunkte sind Research-getriebene Strategie- und Produktentwicklung in agilen Kontexten. Er leitet seit 2018 gemeinsam mit Bernd Feldmayer den Münchner Standort der <a href="https://uxi.de/">UX&I</a>  GmbH.</p><p>Für Hias ist User Story Mapping ein Tool, um das Gesamtsystem eines Software-Projektes auf eine verständliche Art zu beschreiben, wie auch um leichter sinnvolle Priorisierungen vornehmen zu können. <strong>„Das eigentliche Product Backlog in Scrum ist so wenig Produkt und eigentlich nur eine Sammlung von Stories“</strong>, so Wrba. „Und mit User Story Mapping bekommt man dann plötzlich den Kontext und den Überblick.“</p><h2>User Story Mapping und Quick Personas</h2><p>Hias, der als Gastdozent am artop–Institut das Vorgehensmodell UX Thinking schult, erzählt in dieser Folge von „Eine Mate mit“ außerdem von Quick Personas und auch ganz offen von den Fehlern, die ihm bei der Umsetzung von Projekten unterlaufen sind.</p>

<a href="https://www.youtube.com/watch?v=-LlUw_2GWbI" target="_blank"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/zaOg3OzDRd25JEmICoZC" alt="YouTube" />
zum Video "Was ist User Story Mapping? | Eine Mate mit Hias Wrba #EineMateMit"</a>
<div></div>
<br>


<p> </p><p>Eine Mate mit ist ein Format, in dem verschiedenste Menschen aus der IT-Branche aus ihren Projekten und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Die Gemeinsamkeit der Interviews: kurz, knackig, auf den Punkt.</p><h3>#EineMateMit – 5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p>Eine Mate mit möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p>Wir freuen uns auf eure Kommentare im Blog, auf <a href="https://twitter.com/codecentric">Twitter</a>  unter #EineMateMit oder auf auf <a href="https://www.youtube.com/user/codecentricAG">YouTube</a> . Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen.</p><div><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2LLzp22LTSGB5bZYUUVw">
 <p>Eine Mate Mit – User Story Mapping</p></div><p>Weiterführende Links zur heutigen Folge zum Thema User Story Mapping mit Hias Wrba:</p><p><a href="https://jpattonassociates.com/user-story-mapping/">User Story Mapping</a> </p><p><a href="https://www.uxpin.com/studio/blog/ux-designers-5-minute-guide-lean-personas/">Lean / Quick Personas</a> </p><p> </p>

Was ist User Story Mapping? Eine Mate mit Hias Wrba #EineMateMit

<p>„Es geht nicht darum, sich als Entwickler-Rockstar zu fühlen, der noch das letzte Prozent Perfektion herausholt, sondern gemeinsam, für alle Entwickler, die Software-Entwicklung zu verbessern“, sagt Benedikt Ritter im Gespräch über Software Crafting bzw. Software Craftsmanship. Benedikt arbeitet seit September 2013 als Software Craftsman bei der codecentric, er ist Member der Apache Software Foundation und Committer beim Apache Commons Projekt. „Software Crafting hat zwei Aspekte“, sagt Benedikt, „auf der einen Seite geht es um die Verbesserung der Software-Entwicklung. Also ‚Wie‘ Software entwickelt wird; auf der anderen Seite geht es um die Professionalisierung des Umgangs miteinander.“</p><p><span></span></p><h2>Software Crafting oder Software Craftmanship?</h2><p>Derzeit sieht man beide Begriffe Software Crafting und Software Craftsmanship. Im Interview, welches wir dieses Mal in der Lobby des neuen codecentric-Gebäudes in Solingen geführt haben, erklärt Benedikt, wie es dazu kommt und welcher Begriff in Zukunft wahrscheinlich mehr zu sehen sein wird. Außerdem geht es um den Sinn einer Software-Crafter- oder Software-Craftsmanship-Zertifizierung und welches die ersten Schritte sein könnten, wenn man sich auch Software Crafter nennen möchte. Und dann zählt Benedikt auch noch ganz handfest die Vorgehensweisen auf, die aus seiner Sicht, am meisten dazu beitragen, besser Software zu entwickeln.</p><p> </p>

<a href="https://www.youtube.com/watch?v=IgsCeabDn5g" target="_blank"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/i7LOQleOR02pAv15td73" alt="YouTube" />
zum Video "Was ist Software-Craftsmanship/-Crafting? | Eine Mate mit Benedikt Ritter #EineMateMit"</a>
<div></div>
<br>

<p> </p><p><em>Eine Mate Mit </em>ist ein Format, in dem verschiedenste Menschen aus der IT-Branche aus ihren Projekten und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei der codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Die Gemeinsamkeit der Interviews: <strong>Kurz, knackig, auf den Punkt</strong>.</p><h3>#EineMateMit – 5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p><em>Eine Mate Mit</em> möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p>Wir freuen uns auf eure Kommentare hier im Blog, auf Twitter unter #EineMateMit oder auf youtube. Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen. Jeweils hier auf dem codecentric Blog und auf youtube.</p><p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2LLzp22LTSGB5bZYUUVw">
 </p><p>Weiterführende Links für die heutige Folge mit Benedikt Ritter:</p>
<p><a href="https://www.softwerkskammer.org/">https://www.softwerkskammer.org/</a></p>
<p><a href="http://softwarecrafters.org/">http://softwarecrafters.org/</a> </p>
<p><a href="https://www.socrates-conference.de/">https://www.socrates-conference.de/</a> </p>
<p><a href="https://www.amazon.de/Software-Craftsman-Professionalism-Pragmatism-Robert/dp/0134052501">https://www.amazon.de/Software-Craftsman-Professionalism-Pragmatism-Robert/dp/0134052501</a>
<p><a href="http://autoweird.fm">http://autoweird.fm</a> </p><p><a href="https://twitter.com/BenediktRitter">https://twitter.com/BenediktRitter</a> </p>

Was ist Software Crafting/Software Craftsmanship? Eine Mate mit Benedikt Ritter #EineMateMit.

Delivery Manager

Digital Product Coach

<p>TOD (Team-oriented development/Teamorientierte Entwicklung) ist ein Begriff, den wir geprägt haben, um einen flexiblen Entwicklungsalltag zu beschreiben. Nachdem wir in unserem letzten Team mit den verschiedensten Programmier-Modi experimentiert hatten, fanden wir es unnötig, Ansätze wie „Pair Programming“, „Ensemble Programming (früher Mob Programming)“, „Parallel Programming“ und „Einzelkämpfer-Modi“ voneinander abzutrennen. Im Laufe des Tages sprangen wir zwischen diesen Techniken hin und her, wobei ständig neue Variationen entstanden, je nachdem, wie es die Situation erforderte. TOD beschreibt diesen flexiblen Ansatz des ständigen Experimentierens, bei dem wir nicht an künstliche Leitplanken gebunden waren, sondern uns als Gruppe weiterentwickeln konnten, mit dem Vorteil, einen Shared-Everything-Ansatz im Team zu etablieren. Die Konzentration auf Programmiertechniken, an denen zwei oder mehr Personen beteiligt sind, hat uns also geholfen, unser Wissen auf intelligente Weise an das gesamte Team weiterzugeben. Und das Ganze machte obendrein noch jede Menge Spaß.</p><p>TOD ist für uns eines der besten Werkzeuge, um Wissen im Team zu teilen, die Entwickler-Skills zu verbessern und den Zusammenhalt und Spaß im Team zu erhöhen. In diesem Artikel geben wir euch einen Überblick über die Techniken innerhalb von TOD und teilen unsere Erfahrungen, die wir in realen Projekten mit TOD gemacht haben.</p><h2>Pair Programming – ein guter Einstieg</h2><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6WkAuzFHQRiKq47LrMhK"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6WkAuzFHQRiKq47LrMhK" alt="pair programming" width="1024" height="607" /></a> </p><p>Die Konzentration auf Programmiertechniken, an denen zwei oder mehr Personen beteiligt sind, hat uns geholfen, unser Wissen auf intelligente Weise an das gesamte Team weiterzugeben. Eine Methode, die auch Spaß macht.</p><p>Pair Programming ist eine gute Möglichkeit, mit dem Wissensaustausch zu beginnen. Zwei Programmierer lösen gemeinsam ein Problem, sprechen darüber, tauschen Ideen aus usw. Es ist auch gut, um jemanden nach Urlaub oder Krankheit auf den neuesten Stand zu bringen, ohne den Rest des Teams auszubremsen.</p><p>Verschiedene Studien (z. B. [1] und [2]) berichten über eine bessere Code-Qualität während der Software-Entwicklung mit dem Resultat, dass am Ende weniger Bugs entstehen. Sobald man anfängt, die Einzelkämpfer-Rolle aufzugeben, wird man definitiv bessere Ergebnisse erzielen. Ein positiver Nebeneffekt ist, dass man beginnt, den Bus Factor und das Wir-Gefühl innerhalb des Teams zu erhöhen.</p><p>Ein Nachteil beim Pair Programming verbirgt sich im Wort „Pair“: Bei dieser Methode sind nur zwei Programmierer beteiligt. Sie kann dazu führen, dass einzelne Teammitglieder kleine Teile des gesamten Wissens verlieren, was nicht gut für die Verbreitung von Wissen im Team wäre. Das war ein Grund, warum wir versucht haben den Einsatz von Pair Programming auf das nötige Minimum herunterzufahren.</p><h2>Ensemble Programming – erhöhe den Bus Factor des Teams</h2><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1SKF1LxS7e1Z5c9hetIJ"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1SKF1LxS7e1Z5c9hetIJ" alt="mob-soft-mode" width="1024" height="511" /></a> </p><p>Ensemble Programming (früher Mob Programming) macht Spaß und ist eine gute Möglichkeit, Wissen im ganzen Team zu verbreiten. Ensemble Programming bedeutet, dass ein Team von Entwicklern (4-6 Personen sind perfekt) einen Computer benutzt, um an einer Aufgabe zu arbeiten. Einer der Gruppe ist das „intelligente Eingabegerät“, während die anderen dafür verantwortlich sind die Person an der Tastatur zu navigieren.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/tUYH0W7WTW6WFYyAAxwU"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/tUYH0W7WTW6WFYyAAxwU" alt="mob programming-in-a-nutshell" width="1024" height="867" /></a> </p><p>Die Rolle des Drivers wechselt häufig, zum Beispiel alle 7 Minuten. Hier solltet ihr mit eurem Team experimentieren, um den für euch besten Timer zu finden. Ihr solltet auch verschiedene Driver-Navigator-Patterns ausprobieren. Dies alles wird euch helfen, das Wissen im gesamten Team zu verbreiten. Außerdem wird es sich positiv auf den Bus Factor eures Teams auswirken. Der Bus Factor definiert den Gesundheitszustand eures Teams. Wenn sich der Bus Factor eurer Teamgröße nähert, bedeutet das, dass das Team gesund bleibt, auch wenn einige Teammitglieder ausfallen. Kurz gesagt, der Bus Factor bedeutet, dass, wenn eine Person des Teams von einem Bus überrollt wird, das Team in Schwierigkeiten geraten würde, wenn diese Person über ein spezielles Wissen verfügt und die einzige Person wäre, die dieses Wissen besitzt.</p><p>Ein effektives Ensemble Programming erfordert Fähigkeiten, die im Laufe der Zeit aufgebaut werden. Am ersten oder gar am zehnten Tag wird es nicht perfekt funktionieren. In einem früheren Blog-Beitrag haben wir die Einzelheiten von „Ensemble Programming und Share Everything“ bereits <a href="/wissens-hub/blog/mob-programming-shared-everything">beschrieben</a> . Dort werdet ihr auch ausführlichere Informationen über die verschiedenen Muster und Experimente erhalten, mit Fokus auf Remote Ensemble Programming.</p><h2>Parallel Programming – Alle für einen</h2><p>Streng genommen erlauben Ensemble Programming und Pair Programming nur einen Bildschirm und eine Person, die gleichzeitig tippen kann. Jeder, der mit den Techniken gearbeitet hat, wird zustimmen, dass es Situationen gibt, in denen dies frustrierend und einschränkend sein kann. Es ist eine Kunst, lange genug dabei zu bleiben und sich von dieser Frustration zum Lernen zwingen zu lassen, und dennoch zu wissen, wann es wirklich an der Zeit ist, sich zu trennen und parallel zu arbeiten.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/R2sNThTQyVw9SI6gXXJw"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/R2sNThTQyVw9SI6gXXJw" alt="parallel programming" width="1024" height="696" /></a> </p><p>Als wir an den Punkt kamen, an dem es schwierig war, eine gute Lösung für ein Problem zu finden, und fast jeder in der Gruppe eine Idee hatte, um es zu lösen, haben wir Ensemble Programming gestoppt und, wie wir es nannten, „<strong>Parallel Programming</strong>“ gestartet. Jeder versuchte, das Problem auf seinem eigenen Rechner zu lösen, während man in der Videokonferenz online blieb oder man zusammensaß. Jeder durfte reden und konnte sich gegenseitig fragen oder über Erkenntnisse sprechen.</p><p>Das traditionelle Ensemble Programming ist in dieser Situation frustrierend, weil eine Person die Dokumentation lesen will, eine andere versucht Code zu ändern oder einen Befehl auszuführen, und eine andere Person nach Antworten im Internet suchen möchte. Und das Lesen von Text auf dem Bildschirm eines anderen ist eine Herausforderung an sich, wenn z.B. unerwartetet gescrollt wird, usw.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/WbA8HcIVSna2787xmZ9S"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/WbA8HcIVSna2787xmZ9S" alt="single piece flow" width="1024" height="672" /></a> </p><p>Einer der Vorteile von Ensemble Programming ist der Single-Piece-Flow – die Idee, dass immer nur an einem Punkt gearbeitet wird. Eine schlanke Produktion wertet das Konzept zusätzlich auf. Das Gute bei Parallel Programming ist, dass es den Single-Piece-Flow behält. Alle Entwickler arbeiten immer noch an der gleichen Aufgabe. Aber das parallele Arbeiten gibt ihnen die Freiheit, die Richtung einzuschlagen, in die sie gehen wollen. Ein Beispiel dafür ist die Fehlerbehebung. Wenn der Fehler schließlich gefunden wird, erklärt die Person, die ihn gefunden hat, den anderen das Problem. Die anderen verstehen die Erklärung sofort, weil sie sich gerade mit derselben Sache innerhalb desselben Kontextes beschäftigt haben.</p><p>Nützlich hierbei war für uns die Festlegung von Time-Boxen (etwa 20 Minuten). Nachdem die Zeit abgelaufen war, kamen wir wieder zusammen, um unsere individuellen Recherchen auszutauschen und zu entscheiden, ob wir mehr Zeit benötigen (eine weitere Zeitbox einzurichten) oder ob wir wieder mit Ensemble Programming weiter machen und eine der gefundenen Lösungen ausprobieren wollten. Während des Ensemble Programmings und des Experimentierens mit verschiedenen Modi fanden wir es auch vorteilhaft, Time-Boxen einzurichten, wodurch eine gewisse Disziplin entsteht.</p><h2>Anwendung der Techniken in der Praxis</h2><p>Bei einem unserer letzten Projekte haben wir mit Ensemble Programming begonnen. Nach einer Weile ließen wir uns von den Herausforderungen entmutigen und wechselten zu Pair Programming und Einzelkämpfer-Modi. Aber wir probierten den Ensemble-Ansatz immer mal wieder aus. Irgendwann hatten wir eine gewisse Sicherheit bei Ensemble Programming erreicht und, was wichtiger war, dessen Vorteile erkannt. Wir kamen zu der Einsicht, dass wir so viel wie möglich als Team zusammenarbeiten wollten und dass wir Ensemble Programming als unsere Haupttechnik zur Softwareentwicklung einsetzen wollten. Wir beschlossen Einzelkämpferaufgaben in unserem Tagesgeschäft so weit wie möglich zu reduzieren, was meist abhängig von der Arbeit bzw. Aufgabe war. Wenn es zur aktuellen Aufgabe passt, ist Einzelkämpferarbeit durchaus sinnvoll. Wir wollten sie einfach auf ein vernünftiges Minimum reduzieren.</p><p>Ein Nachteil von striktem Pair oder Ensemble Programming ist, dass die Arbeitszeiten synchronisiert werden müssen. Dies ist mit gewissen sozialen Kosten verbunden. Wir hielten es für ein besseres Modell, alle arbeiten zu lassen, wann sie wollten, mit grober Orientierung an den üblichen Bürozeiten. Daran sind die meisten Programmierer bereits gewöhnt. Wenn jemand von Natur aus 30 Minuten früher als andere im Büro eintrifft, sollte er sich eine andere Aufgabe suchen, die sich am besten als Einzelkämpfer bewältigen lässt. Teams können solch relevante Aufgaben auf eine To-do-Liste (oder Single-Task-Backlog) setzen, um auf solche Momente vorbereitet zu sein. Wenn später weitere Entwickler zur Arbeit kommen, können sich daraus Pair- oder Ensemble-Programming oder mehrere Pair-Programming-Sessions, usw.,  entwickeln.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/CJX3LjayTfKE2tUMnCYd"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/CJX3LjayTfKE2tUMnCYd" alt="distribution methods" width="1024" height="683" /></a> </p><p>Wie im Diagramm grob dargestellt, haben wir als primäre Technik Ensemble Programming verwendet. Seit wir die großen Vorteile von Parallel Programming entdeckt haben, haben wir sie häufiger als Pair Programming zusammen mit Ensemble Programming eingesetzt. Aber wir entdeckten diese Technik erst in einem späteren Stadium des Projekts, was den kleineren Balken im Diagramm erklärt.</p><h2>Finde den Weg für dein Team</h2><p>Der oben beschriebene Team-Lernprozess nahm Zeit in Anspruch. Das Team muss erst seinen optimalen Weg finden – was eine gewisse Zeit beansprucht.</p><p>Vielleicht wird euer Team feststellen, dass es am bequemsten und effizientesten ist, wenn es hauptsächlich mit Pair Programming arbeitet. Solange das Team zufrieden ist und seine Ziele erreicht, ist das in Ordnung. Darum geht es bei TOD wirklich: ein Team, das frei experimentiert und gemeinsam den besten Ansatz für sich entdeckt. Und doch bedeutet die Denkweise eine kontinuierliche Verbesserung, während das Team seinen idealen Ansatz sucht. Wir fordern uns selbst immer wieder heraus, sammeln Ideen und versuchen neue Experimente, um uns stetig weiter zu verbessern.</p><p>TOD ist teamspezifisch. Euer Team könnte einen idealen Weg finden, aber wenn ihr als Einzelperson einem neuen Team beitretet, müsst ihr bereit sein, euch anzupassen, den Prozess neu zu beginnen und die in diesem Szenario gewonnenen Erkenntnisse und Ergebnisse akzeptieren.</p><h2>TOD stärkt dein Team</h2><p>Wir stellten bei der Einführung der teamorientierten Entwicklung fest, dass das Wir-Gefühl und die Wohlfühl-Atmosphäre von Tag zu Tag zunahmen. Wir wuchsen zu einem starken Team zusammen, in dem jedes einzelne Teammitglied hoch motiviert war und seine ganze Energie einsetzte. Wir erkannten auch, dass so etwas wie ein Wissens-Safe-Space entstand. Jeder hatte sein eigenes Fachwissen und konnte bei verschiedenen Dingen helfen. Und jeder war bereit zu lernen. Somit hatte niemand im Team Angst zu fragen: „Das habe ich nicht verstanden. Kann es mir nochmal jemand erklären?“.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/d1arg0X5TWGL6pN8gGnF"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/d1arg0X5TWGL6pN8gGnF" alt="we are the team" width="1024" height="697" /></a> </p><p>Klingt das alles gut für euch? Warum versucht ihr dann nicht heute euer erstes kleines Experiment? Macht die Teamarbeit wieder großartig und wertvoll!</p><h2>Quellen</h2><p>[1] Herez Moise Kattan, Flavio Soares, Alfredo Goldman, Eduardo Deboni, and Eduardo Guerra. 2018. Swarm or pair? strengths and weaknesses of pair programming and mob programming. In Proceedings of the 19th International Conference on Agile Software Development: Companion (XP ’18). Association for Computing Machinery, New York, NY, USA, Article 43, 1–4. DOI:<a href="https://doi.org/10.1145/3234152.3234169" target="_blank">https://doi.org/10.1145/3234152.3234169</a> </p><p>[2] Jim Buchan and Mark Pearl. 2018. Leveraging the Mob Mentality: An Experience Report on Mob Programming. In Proceedings of the 22nd International Conference on Evaluation and Assessment in Software Engineering 2018 (EASE’18). Association for Computing Machinery, New York, NY, USA, 199–204. DOI:<a href="https://doi.org/10.1145/3210459.3210482" target="_blank">https://doi.org/10.1145/3210459.3210482</a> </p>

Team-oriented development

<p>Mob Programming ist eine Methode, die wir exzessiv eingesetzt haben, um den Wissensaustausch im Team zu fördern, Entwickler-Skills zu schärfen und den Teamzusammenhalt zu erhöhen. Das mögen nicht unbedingt die Primärziele eures Unternehmens sein, aber sie tragen enorm dazu bei, eure eigentlichen Ziele erfolgreich zu erreichen. In diesem Artikel teilen wir mit euch die Ansätze, die wir nutzten, um Mob Programming machbar, effektiv und unterhaltsam zu machen.</p><h2>„Shared Everything“</h2><p>In einem unserer letzten Projekte haben wir Mob Programming eingeführt, um das Hauptziel „Wissensaustausch im Team“ zu erreichen. Wir wollten damit alle Entwickler auf das gleiche Niveau bringen, statt uns mit Titeln, Kategorisierungen und Spezialisierungen aufzuhalten. Das Ergebnis unserer kontinuierlichen Arbeit an einem „Shared Everything“-Mindset war, dass unser „Bus Factor“ sich an unsere Teamgröße annäherte.</p><h2>Bus Factor?</h2><p>In jedem Team findet man einzelne Personen, die ein Silo an spezifischem Wissen darstellen. Wissen, das essentiell für die Ergebnisse und die Performance des Teams entscheidend ist. Wenn eine solche Person nun das Team plötzlich verlässt, wird das gesamte Team darunter leiden.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/IStAzEB4R1mKwRHkdBqX"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/IStAzEB4R1mKwRHkdBqX" alt="bus factor" width="1024" height="1024" /></a> <p>Bild von Lai Man Nung, unsplash</p></div><p><em><strong>Der Bus Factor eines Teams ist die Anzahl der Teammitglieder, die „von einem Bus überfahren werden müssen“, damit ein Team in ernste Schwierigkeiten kommt.</strong></em></p><p>Somit ist der Bus Factor ein Indikator dafür, wie „gesund“ dein Team in Bezug auf Wissenstransfer und Skill-Sharing ist. Ein hoher Bus Factor deutet auf einen guten Wissenstransfer innerhalb des Teams hin.</p><p>Wie haben wir Mob Programming und Shared Everything etabliert?</p><h2>Mob Programming – Ein Abenteuer</h2><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ai9qU79SShqHkJODAYIB"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ai9qU79SShqHkJODAYIB" alt="remote mob session" width="1024" height="640" /></a> <p>Remote Session – Bild von den Autoren</p></div><p>Während des besagten Projektes waren wir in der glücklichen Lage, DDD (Domain-driven Development), TDD (Test-driven Development), und, was wesentlicher war, Mob-Programming-Techniken zu verwenden.</p><p>Wir hatten einen holprigen Start. Mob Programming fühlte sich für uns total fremd an gegenüber der Art der Softwareentwicklung, die wir gewohnt waren. In täglichen Retrospektiven wurde das Gefühl von Verlangsamung beanstandet und man war relativ schnell frustriert, dass man nicht mehr wie gewohnt die Macht über das Keyboard und die damit verbundene Kontrolle hatte. Wir versuchten es, gaben es auf, starteten neu und hörten wieder auf.</p><p>Was wir damit sagen wollen, ist, dass wir am Anfang viel experimentierten. Während dieser Phase wurden wir durch den <a href="http://www.mobprogrammingguidebook.com/images/mobprogrammingguidebook.pdf" target="_blank">Guide von Maaret Pyhäjärvi</a>  inspiriert.</p><p>Wir begannen zu erkennen, dass Wissen im Team viel besser zu den einzelnen Teammitgliedern transferiert wurde und sich auch unsere Codequalität erhöhte.</p><p>Dennoch blieben die Herausforderungen bestehen. Wir waren auch zu Beginn an einem Punkt angekommen, an dem wir diese eigentlich gute Idee aufgeben wollten. Aber wir hatten dann einen sehr guten Workshop mit <a href="https://woodyzuill.com/" target="_blank">Woody Zuill</a> . Dieser Workshop-Tag half uns enorm dabei, festzustellen, dass die Mob-Programming-Technik uns unterstützt, uns selbst als Menschen, aber auch als Team weiterzuentwickeln. Wir waren wieder enthusiastisch! Neben den vielen Tipps und Tricks, die Woody uns mitgab, war eines für uns entscheidend: die Daily Retrospektive. Eine tägliche Retro? Ja. Jeden Tag um ca. 16 h kamen wir für fünf Minuten zusammen. In dieser Retro geht es darum, dass jeder etwas sagt, was an diesem Tag gut gelaufen ist. Wir empfehlen euch, dafür einen Alarm einzurichten, um damit vertraut zu werden.</p><p>Eine weitere Herausforderung bei uns war, dass wir den Fokus auf Remote Mob Programming setzen mussten, da ein Teil unseres Teams über verschiedene Standorte verteilt war. Hierbei holten wir uns Inspiration aus dem <a href="https://www.remotemobprogramming.org/" target="_blank">Guide von Simon Harrer, Jochen Christ, und Martin Huber</a> . Wir mussten einige Regeln etablieren, um Remote-Arbeit für uns erfolgreich zu machen.</p><h3>Einige „Shared Everything“-Regeln</h3><ul><li><strong>Kamera immer an</strong><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nBsdt2CKTaugEPav2jx7"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nBsdt2CKTaugEPav2jx7" alt="webcam" width="1024" height="387" /></a> <p>Bild von Aksa2011, pixabay</p></div><p>Da das Team über verschiedene Standorte verteilt war, war es für uns besonders wichtig, die „Kamera immer an“-Regel zu forcieren. Das hilft allen Teammitgliedern, sich wie „Bürger erster Klasse“ zu fühlen. Es gibt, vor allem für die Remote-Mitglieder, ein besseres „Wir“-Gefühl. Zusätzlich hat es den Vorteil, dass bei Diskussionen und Meetings ein besseres Verständnis erzielt wird, weil man neben der Sprache so auch die Gestik der sprechenden Person mitbekommt. Das bringt uns zur nächsten Regel …</p></li><li><strong>30-Sekunden-Regel</strong><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/e0m2vVsRpm7JwKHyBrSw"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/e0m2vVsRpm7JwKHyBrSw" alt="timer" width="1024" height="358" /></a> <p>Bild von Aron Visuals, unsplash</p></div><p><strong>Wenn jemand mehr als 30 Sekunden spricht und sich dabei außerhalb der Kamera befindet, kann jeder das Meeting unterbrechen, damit die Situation bereinigt werden kann.</strong></p><p>Da bei uns im primären Projektbüro jeder sein eigenes Notebook verwendete, war es sowieso Standard, dass jeder die ganze Zeit vor der Kamera war.</p><p>In den Business-Meetings mit unseren Stakeholdern war jeder angehalten teilzunehmen, damit wir unsere „Shared-Everything“-Philosophie forcieren konnten. Es war entscheidend, unsere Einrichtung so anzupassen, dass alle Gäste im Raum von den Remote-Mitgliedern/-Teilnehmern deutlich gesehen werden konnten – ob es darum ging, die Körpersprache wahrzunehmen oder einfach nur zu wissen, wer genau spricht. Daher machte diese Regel auch einen Unterschied wie Tag und Nacht. Die zusätzlichen Personen wurden also vor Beginn des Meetings auf die vorhandenen Kameras (Notebooks) verteilt. Die Beteiligten haben in unserem Fall sehr gut mitgespielt.</p></li><li><strong>10-Minuten-Regel</strong><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DmyvaY7MSeUbmWwdKoK3"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DmyvaY7MSeUbmWwdKoK3" alt="speaking" width="1024" height="355" /></a> <p>Bild von Clem Onojeghuo, unsplash</p></div><p>Bei der 10-Minuten-Regel geht es im Wesentlichen darum, dass jeder Teilnehmer ausreichend abgeholt ist. Falls einer der Beteiligten für mehr als zehn Minuten nichts sagte, wurde das Meeting kurz unterbrochen und derjenige sollte kurz den Stand zusammenfassen. Das klingt nach einer harten Regel, ja, aber für uns war es extrem wichtig, dass jeder alles mitbekam. Nur so konnten wir einen guten Wissenstransfer sicherstellen. Üblicherweise ist es ein Indikator, falls jemand eine Weile nichts zu sagen hat, dass derjenige den Faden der Konversation verloren hat.</p></li><li>Brauchst du eine Pause? Nimm dir eine.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DuweXxQduW8qtM8Yukzw"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/CG2UQ6nQnyZQkH1pFB4w" alt="break" width="1024" height="368" /></a> <p>Bild von Alex, unsplash</p></div><p>Mob Programming braucht eine extrem hohe Fokussierung und Aufmerksamkeit von jedem. Hinzu kommt, dass Lernen schnell müde macht. Somit war es jedem in unserem Team erlaubt, eine Pause zu machen, wann immer eine benötigt wurde. Das Positive bei Mob Programming ist, dass man sehr schnell wieder auf dem Laufenden ist, wenn man aus einer Pause zurückkehrt. Wir haben verschiedene Pausenmodelle ausprobiert und sind am Ende bei der individuellen Pause geblieben. Das Einzige, was wir versucht haben zu synchronisieren, war die Mittagspause. Ansonsten konnte sich jeder eine individuelle Pause nehmen, sofern es nötig war. Die Person wurde dann einfach immer an das Ende der Mob-Programming-Liste gefügt und konnte sich somit eine Runde lang aufgleisen.</p></li></ul><p>Bei Business-Meetings haben wir allerdings eine andere Pausenregelung angewandt. Wir haben hier die 45-Minuten-Regel verwendet. Also alle 45 Minuten eine kurze Pause. Das war besonders für unsere Remote-Teilnehmer sinnvoll, weil diese Meetings anstrengend sein können, wenn man nicht unbedingt in seiner Muttersprache folgen muss.</p><p>Die Regeln oben halfen uns während der Mob-Programming-Sessions sehr. Und Mob Programming half uns, das gesamte Wissen an jedes einzelne Teammitglied weiterzugeben. Jeder in unserem Team kannte also jede kleine Ecke unserer Anwendung und konnte an jedem Teil davon arbeiten.</p><h2>Unsere Experimente</h2><p>Wie wir bereits erwähnten, haben wir viel experimentiert. Experimente machen Spaß. So haben wir zum Beispiel verschiedene Ansätze für Mob Programming, die wir in „Dojos“ bei Woody Zuills Workshop gelernt haben, ausprobiert. Wir haben sie strict, soft und freestyle genannt:</p><ul><li><strong>Strict<br /> </strong><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DuweXxQduW8qtM8Yukzw"><img loading="lazy" width="250" height="117" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DuweXxQduW8qtM8Yukzw" alt="mob-strict-mode" /></a> <br /> Die strikte Art und Weise, Mob Programming durchzuführen, bedeutet, dass ausschließlich der Navigator reden darf. Der Rest darf nur zuschauen. Man darf nicht antworten, auch nicht auf direkt gestellte Fragen. Man kann sich vorstellen, dass das ziemlich schnell frustrierend sein kann. Vor allem, wenn man mit ansehen muss, wie der Navigator anfängt zu straucheln und einem nicht erlaubt ist, zu antworten oder Hinweise zu geben. Allerdings kann das überraschenderweise große Benefits mit sich bringen. Der Navigator zum Beispiel lernt laut zu denken, was wiederum der nächste Navigator aufgreifen kann. Dem Mob Fragen zu stellen ist eine effektive Methode der Kommunikation (auch wenn diese unbeantwortet bleiben)Auf der anderen Seite lernt der Mob, sich in Geduld zu üben und, was wir als wichtiger empfinden, dem Navigator Raum zu lassen, Dinge einfach auszuprobieren. Wenn man gelernt hat, mit diesen Frustrationen umzugehen, wird man merken, dass diese Art und Weise eine sehr friedvolle Technik ist. Keine Diskussionen, keine Argumente. Einfach programmieren und dabei versuchen, den anderen und dessen Gedankengang zu verstehen.</li><li><strong>Soft<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/uydRh5SZR3yPGmd2bK4M"><img loading="lazy" width="250" height="125" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/uydRh5SZR3yPGmd2bK4M" alt="mob-soft-mode" /></a> <br /> </strong>Diese Art ist ähnlich zur strikten Methode, mit dem Unterschied, dass der Mob reden darf, falls eine Frage vom Navigator gestellt wird. Man kann auf Fragen reagieren oder die Hand heben und warten, bis man an der Reihe ist, wenn man einen Hinweis oder eine Idee teilen möchte. Das erlaubt es, einem strauchelnden Teammitglied aktiv helfen zu können. Nichtsdestotrotz kann diese Technik in lange Diskussionen und den Freestyle-Modus abschweifen. Daher ist hier Vorsicht geboten.</li><li><strong>Freestyle<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/fKtb40bTIOMGAHY3x1Vj"><img loading="lazy" width="250" height="116" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/fKtb40bTIOMGAHY3x1Vj" alt="mob-freestyle-mode" /></a> </strong><br /> Im Freestyle-Modus gibt es nur den Driver und alle anderen sind Navigatoren. Jeder darf frei Hinweise, Kommandos, Ideen äußern oder eine Diskussion starten. Wir haben gemerkt, dass es bei dieser Methode wichtig ist, Techniken anzuwenden, die Diskussionen reduzieren. Eine Möglichkeit ist es, die Idee eines Teammitglieds aufzugreifen und durchzuführen, egal ob sie gut oder schlecht endet, statt diese totzudiskutieren. Das Ergebnis kann überraschend sein!</li></ul><p>Wir waren die meiste Zeit im Soft-Modus unterwegs, ein guter Kompromiss zwischen den anderen beiden Modi. Auch haben wir während des Tages immer mal wieder den Freestyle-Modus angewandt. Zudem haben wir uns einen Timeslot pro Tag (maximal eine Stunde) für den strikten Modus genommen, weil wir das Training für Geduld und Lösungsfindung sehr gut fanden.</p><p>Zudem haben wir viel mit der Mob-Programming-Rundenzeit experimentiert. Wir haben sehr kurze (2-3 min), mittlere (5-12 min) und lange (15-25 min) Rundenzeiten ausprobiert. Wir haben eine Zeit ausgewählt und 1-2 Runden Mob Programming durchgeführt. Wir haben festgestellt, dass bei den langen Zeiten sehr schnell der Fokus verloren wurde. Auch bei den zu kurzen Zeiten waren wir uns schnell einig, dass es nicht funktioniert, weil einfach zu wenig Zeit war, wenn man kurz nachdenken wollte oder man eine kleine Diskussion startete. Am Ende haben wir uns bei Zeiten zwischen 6-8 min eingependelt. Das war für uns genug Zeit, um etwas zu erreichen, aber auch, um mal eine kleine Diskussion zu führen.</p><p>Als hundertprozentiges Remote-Team mussten wir uns auch nebenbei noch eine Lösung suchen, um die Driver-Navigator-Wechselzeiten zu verbessern (Push des Codes zu einem dedizierten Git-Branch, Wechsel des Screensharings, etc.). Wir haben sie mittels Bash-Skripten und Disziplin auf ca. 30 Sekunden reduziert. Bei Timern unter 6 min ist das auch ein signifikanter Aspekt.</p><p>Auch haben wir verschiedene Driver-Navigator-Methoden ausprobiert. Viele Teams bleiben beim Navigator-Driver-Pattern. Wir haben nebenbei noch folgende Muster versucht:</p><ul><li><strong>Navigator-Driver-Mob</strong><br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mYat3uvTS7lsyLYq9INA"><img loading="lazy" width="250" height="101" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mYat3uvTS7lsyLYq9INA" alt="navigator-driver" /></a> <br /> Der Navigator wird zum Driver, der Driver tritt dem Mob bei, und der Nächste aus dem Mob wird zum Navigator.</li><li><strong>Driver-Navigator-Mob</strong><br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6GDWeccZRiq1Cc0vMH4N"><img loading="lazy" width="250" height="100" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6GDWeccZRiq1Cc0vMH4N" alt="driver-navigator" /></a> <br /> Der Driver wird zum Navigator, der Navigator tritt dem Mob bei, und der Nächste aus dem Mob wird zum Driver.</li><li><strong>Driver-Mob-Navigator-Mob</strong><br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RAGYBbtkSCiCaeFqzPsp"><img loading="lazy" width="250" height="115" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RAGYBbtkSCiCaeFqzPsp" alt /></a> <br /> Der Driver und der Navigator treten dem Mob bei und die zwei Nächsten des Mobs werden zum Driver und zum Navigator.</li></ul><p><strong>Driver-Navigator-Mob</strong> wurde unser Standard, denn:</p><ul><li>Wenn jemand den Faden verlor, war hierbei die Chance groß, dass derjenige durch die Driver-Rolle wieder aufgegleist wird, bevor er zum Navigator wird.</li><li>Während des Wechsels ist es von Vorteil, wenn der Driver aus dem Mob kommt, da er bereits die nötigen Dateien etc. öffnen kann, bevor es zum Wechsel kommt.</li></ul><p>Aber wir fanden auch die anderen Muster interessant und zum Teil auch hilfreich. Haben wir schon erwähnt, dass wir es sehr mochten zu experimentieren?</p><h2>Psychologische Sicherheit im Mob Programming</h2><p>Die Forschung hat gezeigt, dass psychologische Sicherheit ein starker Prädiktor für die Teamleistung ist. Es ist ein angenehmes Gefühl, sagen zu können, was man denkt, und zu sein, wer man ist, ohne sich zu schämen oder Auswirkungen befürchten zu müssen. Die enge Zusammenarbeit hat uns geholfen, uns als Menschen zu verbinden. Selten gab es in unserem Team etwas wie den „Code eines anderen“, und jeder wusste und fühlte sich mit den Fähigkeiten und persönlichen Umständen des anderen wohl.</p><p>Es ist uns gelungen, uns mehrmals persönlich zu treffen und zusammenzuarbeiten – was sehr vorteilhaft ist. Sich live treffen, abends gemeinsam ein Bier trinken, die Familie des Kollegen kennen lernen – das sind Dinge, die ein Team stärken und vereinigen.</p><h2>Die Ironie des Shared Everything und des Bus Factors</h2><p>Die Verwendung des Mob-Programming-Ansatzes als Teil einer „Shared Everything“-Mentalität kann sehr vorteilhaft sein. Im Laufe des Projekts stellten wir fest, dass sich unser Bus Factor unserer Teamgröße angenähert hatte. Mit anderen Worten: Man hätte im Grunde das gesamte Team auflösen müssen, damit das Wissen und die Fähigkeiten aus dem Projekt verloren gehen. Das ist phänomenal.</p><p>Wir stellten auch eine hohe Zufriedenheit fest, die sich im Team verbreitete. Alle waren leidenschaftlich an den Experimenten und der Zusammenarbeit interessiert. Niemand fürchtete sich zu sagen: „Ich habe das nicht verstanden“, „Können wir das ändern?“ oder: „Wir sollten das mal so versuchen“.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LxVateSEOpHjgdvdHkow"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LxVateSEOpHjgdvdHkow" alt="leaving" width="1024" height="372" /></a> <p>Bild von Ryan Tang, unsplash</p></div><p>Ein hoher Busfaktor schützt das Team, falls die Leute es verlassen. Die Ironie dabei ist jedoch, dass, wenn ein „Shared-Everything“-Team gebildet wird, niemand das Team verlassen will. Wir hatten während dieses Projekts keine Fluktuation in unserem Team.</p><p>Trotz der wirklich interessanten Technologien und des kooperativen Kunden, der an dem Projekt beteiligt war, fasste ein Teammitglied am Ende des Projekts das Gefühl des Teams mit den Worten zusammen: „<em><strong>Ich bin wirklich traurig, dass dieses Projekt zu Ende geht. Nicht wirklich wegen der Projektarbeit, sondern weil ich das Team verliere.</strong></em>“</p>

Mob Programming und Shared Everything

Das Developer's-Dilemma: Den Übergang zum AI Engineering meistern

5 Gründe, warum wir Entwickler Agentic Software Engineering falsch einschätzen

<h4>The coronavirus is thrusting society towards digitalisation. Expect many changes to remain long after the crisis has gone.</h4><p>Mike Chang, Product Owner at Altoread (names changed) briefed his technical staff last week in regards to COVID-19: “We need to prepare for traffic at up to 4x normal levels…”</p><p>Altoread offers readers computer and smartphone-based alternatives to traditional paper books. As libraries shut their physical buildings over the past weeks, they pointed their readers towards such digital services.</p><p>But the second half of Mike’s statement was the most interesting part: “We are expecting this to be a permanent change. After the crisis, traffic will not fall again.”</p><p>COVID-19 has already had a dramatic effect on the world. But much more is to come. As governments prepare to spend “unlimited” amounts of money to prop up their economies, people around the world in various stages of lockdown are being forced to find new ways to get on with work and daily life. They are charting new waters, waters which in many cases, no amount of persuasion up to this point had caused them to venture into. And be it video conference, grocery delivery or online shopping, those waters are almost exclusively digital services.</p><p>Many of the old, non-digital habits will return after COVID-19 is gone, but some won’t. In 2014, a strike on the London Underground closed some tube lines, forcing commuters to create new itineraries using the remaining lines to get to work and back. <a href="https://www.cam.ac.uk/research/news/london-tube-strike-produced-net-economic-benefit" target="_blank">A study</a>  by Oxford and Cambridge universities revealed that after the strike had ended, 5% of passengers continued using their new itinerary, apparently preferring it to their previous route. Could something similar happen in the online space after coronavirus?</p><h2>Digitalisation by force</h2><p>The world was already on a trajectory of going digital. This inevitable change nevertheless takes time. People stick to their old habits, and it’s quite difficult for firms to persuade them to try something new. Grocery shopping is a case in point. In the US, Target famously used customer loyalty-card data to predict, with impressive accuracy, which of its shoppers were in their second trimester of pregnancy. They then bombarded these ladies with promotional material intended to influence them to switch to Target as their main household shopping source. The second trimester of pregnancy, science has revealed, is one of the few times in life that people are especially open to breaking old habits and forming new ones.</p><p>The novel coronavirus has put us into a similar situation, though rather by necessity and force than by hormones or nature. In Spain and some other European countries, police and the armed forces are patrolling the streets and enforcing the lockdown. There is no longer an option to resist digitalisation and avoid “new-fangled stuff”. You no longer have a choice to support your local bricks-and-mortar book seller. You are literally being forced to conduct business online by people carrying guns. That beats even the second trimester.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/AKimbKMiTDSNSzrjDRpe"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/AKimbKMiTDSNSzrjDRpe" alt="Man sweats at computer while armed and masked men say &quot;Just order online&quot;" width="700" height="323" /></a> <p>This gives a new meaning to “One-Click Ordering”. Comic by Florian Schneider.</p></div><h2>Ordering a New World</h2><p>The effect is being felt in digital demand. Amazon is employing 100,000 new warehouse and logistic workers to deal with the increase in orders. Microsoft Teams remote collaboration software has stuttered under sudden demand, whilst the share price of Zoom, a video communications service, has rocketed against the backdrop of a wider market freefall. And as for grocery shopping, Woolworths, an Australian supermarket, has suspended online shopping and delivery in some regions, unable to cope.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/v9l8y657R6YxUNn2Ba3e"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/v9l8y657R6YxUNn2Ba3e" alt="Empty pasta shelves at a supermarket during COVID-19 crisis" width="640" height="480" /></a> <p>Perhaps shoppers who only know how to cook pasta are preparing for Italy to disappear</p></div><p>The changes are everywhere. Teachers are sharing their contact details with students in order to be able to instruct them remotely, previously a taboo idea for many in their attempt to strictly separate work and private life. Churches are holding services entirely online. “Ghost” music concerts (be it <a href="https://twitter.com/JamesBlunt/status/1238500843030302721" target="_blank">pop</a>  or classical) are being played in empty theatres and broadcast for free. Tomorrow <a href="https://live.theleaddev.com/" target="_blank">Lead Dev Live</a>  will kick off, one of many free online events created to replace a cancelled in-presence conference; over 10,000 people have signed up. Localised small interest groups have switched to online.</p><p>Before Corona, aficionados would probably have told you that these events can only be conducted in-person. Isn’t the entire purpose of church, or a software conference, physically coming together to socialise, interact and exchange ideas? Live-recorded music concerts were always just a flavour of recorded music. Homeschooling is/was either banned or vaguely tolerated in most countries. But when it’s virtual or nothing, virtual suddenly has virtue.</p><h2>Borders close. Online communities open.</h2><p>These approaches are already opening new horizons. This month, codecentricer Chris Dutz will present live from his home in Frankfurt, Germany at the Melbourne, Australia IoT meetup. The Lead Dev London could never have handled so many attendees at the physical conference – this newfound reach might be something the organisers would like to continue. Will virtual meetups continue after the crisis, defined by time and language rather than by region? In the education space homeschooling is unlikely to take off, but expect to see a few new methods filter through into normal practise after the crisis.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/KYi4gEHmQN2WTxjKc6aV"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/KYi4gEHmQN2WTxjKc6aV" alt="A video conference" width="600" height="263" /></a> <p>As long as each participant in a video conference remains 1m from his monitor, the mandated 2m is maintained between any two participants at all times.</p></div><p>Earlier in the crisis, when social distancing was only beginning to be encouraged, there were reports on Twitter of managers continuing to insist that employees come to the office, because permitting employees to work from home “might create a precedent”. In other words, after COVID-19 crisis has passed, people might ask their bosses why they shouldn’t continue to <a href="/en/knowledge-hub/blog?q=remote">work from home</a> : “I avoided a long commute, I was able to work without distractions, and as you can see, I got more done than ever.”</p><p>Assuming the reports are true, these managers are spot on. Employees will request this and more, and citizens will make other changes. The net effect on society is going to be a sudden jump forward in digitalisation, where heretofore unreachable people, having broken down the mental or cultural barrier, jump on the train of online shopping, banking and other services.</p><h2>Reopening unemployment</h2><p>Sadly, many of the businesses which are hardest hit right now will also carry the cost of this change forever. Bricks and mortar stores might struggle to reopen, only to find that 10% of their customers have permanently disappeared. Employee layoffs could create structural unemployment – a situation in which existing skills have become irrelevant and previously talented people become unemployable. It’s not an easy problem to solve, and governments will be further restricted in their ability to help by the debt which they have racked up during their “save the economy” spending sprees.</p><p>The future is bright for digitalisation enablers like codecentric. Management consults tell me of their attempts to convince heads of business that they are not, for example, a bank which has some supporting IT, they are an IT company which offers banking services. This message is getting easier to understand. The need for digital enablement support in every type of company will only increase.</p><p>Hopefully, companies like codecentric can also help with the structural unemployment. We can’t work miracles with totally unqualified people, but we do try hard to make our hiring as inclusive as possible – the qualifications to work with us are soft rather than hard. Demonstrating initiative and a deep desire to learn can be worth more to us than a university degree. Besides listing open positions, we also accept applications for any unlisted job – maybe <a href="/en/careers" target="_blank">we need you</a>  and we just don’t know it yet.</p><p>As for those digital reading services, Altoread is perfectly positioned to handle the surge in demand from the bunkered-down bookworms. codecentric helps them to run their digital services as a cloud-native company. This enables them to automatically scale their IT infrastructure up to cope with surges in customer traffic. As the traffic drops again, the systems scale back down. That is, if the traffic ever drops down again.</p>

Death, downturn and dramatic digitalisation – COVID-19’s legacy-to-be

<p><span>Mob programming is a technique we use extensively for sharing knowledge in the team, improving developer skills and increasing team cohesion. These might not be the primary goals of your business, but they probably contribute much more than you realise to achieving your goals. In this article, we share the techniques we have developed to make Mob programming feasible, fun and effective.</span></p><h2><span>“Shared everything”</span></h2><p><span>In a recent project, we introduced mob programming as part of our goal to share everything inside our team. We wanted to have all developers on the same level, rather than having titles, categorisations and specialisations. As a result of consistently applying a “shared everything” mindset, our team’s “bus factor” approached the team size.</span></p><h2><span>Bus factor?</span></h2><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/IStAzEB4R1mKwRHkdBqX"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/IStAzEB4R1mKwRHkdBqX" alt="bus factor" width="1024" height="1024" /></a> <p>– Image by Lai Man Nung - unsplash</p></div><p><i><span>In any team, there are individuals who are the sole possessors of specific knowledge, knowledge which is essential to the team’s performance and the outcomes. If these people were to suddenly leave the team, the team would suffer.</span></i></p><p><b><i>The bus factor of a team is the number of team members that would need to be “hit by a bus” before the team would end up in serious trouble.</i></b></p><p><i><span>So the bus factor indicates how healthy your team is regarding knowledge transfer and skill sharing. A high bus factor indicates healthy knowledge sharing and a healthy team.</span></i></p><p><span>How did we apply mob programming and “shared everything”?</span></p><h2><span>Mob programming – An adventure</span></h2><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ai9qU79SShqHkJODAYIB"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ai9qU79SShqHkJODAYIB" alt="remote mob session" width="1024" height="640" /></a> <p>– Remote mob programming session – Screenshot by the authors</p></div><p><span>During the project in question, we were lucky enough to use DDD (Domain Driven Design), TDD (Test Driven Development), and more importantly mob programming techniques.</span></p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nBsdt2CKTaugEPav2jx7"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nBsdt2CKTaugEPav2jx7" alt="mob-in-a-nutshell" width="1024" height="867" /></a> </p><p><em>Mob programming in a nutshell: You have one computer and three or more developers. One is typing (driver), one or the rest of the developers lead the driver and give commands (navigator-s). The whole team is working on the same issue at the same time. See the different mob programming modes in the experiment section.</em></p><p><span>Initially we had a bumpy start. Mob programming felt completely different to the software development we were used to. A feeling that we might not be moving fast enough was repeatedly mentioned in retrospectives, and there was the frustration of not being able to take the keyboard and control. We tried it, abandoned it, restarted, and stopped again.</span></p><p><span>In the beginning, we experimented a lot and were inspired by the <a href="http://www.mobprogrammingguidebook.com/images/mobprogrammingguidebook.pdf">Guide from Maaret Pyhäjärvi</a> .</span></p><p><span>We started to see how knowledge was being transferred to every team member and code quality seemed to be increasing.</span></p><p><span>Nevertheless, the challenges continued. Just when we were about to give up the idea for good, we had a great mob programming workshop with <a href="https://woodyzuill.com/">Woody Zuill</a> </span><span>. This helped us to see how the technique allowed us to develop as people and as a team, and we were enthusiastic again! Among the many ideas we picked up from Woody was the practice of a daily retrospective. Generally we did this at about 4pm and tried to keep it to 5 minutes. In the daily retro everyone said something which went positive during the day. To get used to it, we needed to set up an alarm.</span></p><p><span>We needed to focus on </span><i><span>remote</span></i><span> mob programming, because the team members were spread over different locations. Here we got inspired by a <a href="https://www.remotemobprogramming.org/">remote mob programming guide</a>  from Simon Harrer, Jochen Christ, and Martin Huber</span><span>. We needed to establish a few rules …</span></p><h3><strong>Some “shared everything” rules</strong></h3><ul><li><b><b>Camera always on<br /> </b></b><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/e0m2vVsRpm7JwKHyBrSw"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/e0m2vVsRpm7JwKHyBrSw" alt="webcam" width="1024" height="387" /></a> <p>– Image by Aksa2011, pixabay</p></div><p><span>Since the team was spread over several locations, it was important for us to define the “</span><b>Camera always on</b><span><span>” rule. That helped that all team members felt like first-class citizens. It gives you a better ‘we’ feeling, especially for the remote members. Additionally, it promotes a better understanding in discussions and meetings, because you will get the gestures of the speaking person. Which brings us to the next rule…</span></span></p></li></ul><p> </p><ul><li><b><b>30-second rule<br /> </b></b><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DmyvaY7MSeUbmWwdKoK3"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DmyvaY7MSeUbmWwdKoK3" alt="timer" width="1024" height="358" /></a> <p>– Image by Aron Visuals, unsplash</p></div><p><b>If a person speaks for more than 30 seconds off-camera, the meeting must be interrupted in order to force corrections.<br /> </b>Since every one of us in our primary project office had their own notebook with a camera, most of the time everyone was on camera by default. However, typically stakeholders would visit us for meetings. In order to enforce our “shared everything” philosophy, everyone needed to participate in these meetings on equal footing. It was critical to adjust our setup so that all the guests in the room could clearly be seen by the remote members/participants. Whether for catching body language or simply for being aware of who exactly was speaking, this rule makes a difference like night and day. So, the extra persons were distributed to the existing notebooks (cameras), before the meeting started. The stakeholders were extremely co-operative.</p></li></ul><p> </p><ul><li><b><b><b><b>10-minute rule<br /> </b></b></b></b><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/CG2UQ6nQnyZQkH1pFB4w"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/CG2UQ6nQnyZQkH1pFB4w" alt="speaking" width="1024" height="355" /></a> <p>– Image by Clem Onojeghuo, unsplash</p></div><p><b><b><b><span>If a remote participant doesn’t say anything for 10 minutes, stop the meeting and ask them to say something or summarise the last minutes. Sure, that is a hard rule, but for us it was important that everyone understood the matter of the meetings and kept the knowledge spread. If someone doesn’t talk for a while, it’s usually an indicator that they have lost track of what is going on.</span></b></b></b></p></li></ul><p> </p><ul><li><b><b>Do you need a break? Take one.<br /> </b></b><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DuweXxQduW8qtM8Yukzw"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DuweXxQduW8qtM8Yukzw" alt="break" width="1024" height="368" /></a> <p>– Image by Alex, unsplash</p></div><p><b><span>Mob programming needs high attention and focus, and learning is tiring. Everyone in the team should be allowed to take a break whenever it is needed. The positive thing while doing mob programming is that this person will get back into the flow quickly.<br /> </span></b><span>We tried various break techniques, and generally settled on the “individual breaks” technique. We generally synchronised lunch, but otherwise there were no agreed breaks. Any person could take a short break whenever they felt it was necessary. When they came back we simply put them on the end of the list. This avoided discussion and organisation. And the person could get in again easily.</span></p></li></ul><p><span>For business meetings of course, you need to take breaks together. Here we established another rule – the “45-minute rule”, which basically meant a forced break every 45 minutes. Meetings are quite stressful for remote participants who are not speaking their native language. This helps them to stay tuned in.</span></p><p><span>The rules above helped us a lot while doing mob programming. And mob programming helped us a lot to spread all the knowledge to every single team member. So, everyone on this team knows every small corner of our application and was able to work on every part of it.</span></p><h2><span>Experiments for the win</span></h2><p><span>As we mentioned earlier, we did a lot of experiments. Experiments are fun. So, for example, we tried to do mob programming in three different ways which we learned as “Dojos” from Woody Zuill during his workshop. We called them strict, soft, and freestyle.</span></p><p> </p><ul><li><b>Strict<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/uydRh5SZR3yPGmd2bK4M"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/uydRh5SZR3yPGmd2bK4M" alt="mob-strict-mode" width="250" height="117" /></a> <br /> </b><span><span>The strictest implementation of the driver-navigator pattern. Only the navigator is allowed to speak, others simply watch. Literally, they may not speak, even to answer questions.</span></span>This very quickly becomes frustrating for the mob as they see the navigator struggling but are not allowed to give them any answers. Surprisingly, this can create great benefits. The navigator learns to think out loud so that the next navigator can easily take over. Asking the mob questions (which go unanswered) is a surprisingly effective method of communication.The mob learns patience, and the vital art of letting someone else have a go; trying someone else’s ideas out. Once you learn to handle the frustration, you find that this is the most peaceful technique of all. No discussion, no arguments. Just coding and trying to understand each other.</li></ul><p> </p><ul><li><b>Soft</b><span><br /> </span><i><span><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/fKtb40bTIOMGAHY3x1Vj"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/fKtb40bTIOMGAHY3x1Vj" alt="mob-soft-mode" width="250" height="125" /></a> <br /> </span></i><span><span>This is similar to the strict technique, but the mob is allowed to speak when requested by the navigator. They can answer questions and also raise their hands and wait until they are asked to speak. This removes some of the seeming stupidity of the strict technique when you watch a teammate flounder. However, if you are not careful, this technique can degrade into long discussions and “freestyle”.</span></span></li></ul><p> </p><ul><li><b><b>Freestyle<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mYat3uvTS7lsyLYq9INA"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mYat3uvTS7lsyLYq9INA" alt="mob-freestyle-mode" width="250" height="116" /></a> <br /> </b></b>In freestyle mode there is one driver and the rest of the team members are navigators. Everyone is free to give a command, mention an idea, or start a discussion. We found that in this mode it was important to apply techniques to reduce discussion. One such technique is just accepting the idea of a colleague and trying it out to prove it good or bad, instead of discussing it to death. Often the result is surprising!</li></ul><p><span>We think we ended up in the soft mode most often – a good compromise between other techniques. Freestyle felt like a natural thing to do a bit every day too. But, we found that we had to reserve a time slot (maximum of 1 hour) for doing the strict mode because we valued this training in solution finding and patience, but one doesn’t just accidentally fall into doing something that feels so unnatural.</span></p><p><span>We also experimented with the mob programming time. So, we tried to set the timer to a very low (2-3 minutes), medium (5-12 minutes), and high (15-25 minutes) time. And then we started to mob for 1 to 2 rounds. We figured out that a timer set too high will cause followers to lose their focus. Also, too low times are bad because you start, think about something, start a small discussion and boom …. the time is over. At least, we stick to 6-8 minutes for a driving round. It was enough time for us to get something done, but also to discuss a little about an idea.</span></p><p><span>As a remote team, we also had to factor in the overhead of switching (pushing to a dedicated Git branch, switching screen sharing). We managed to reduce this to 30 seconds when we were disciplined, but no further. So with a timer of less than about 6 minutes, this became a significant aspect.</span></p><h3>What about the mob programming patterns</h3><p><span>Another thing we tried are different ways of driver-navigator patterns. Many teams are stuck on the navigator-driver-mob pattern. We tried every possible variation:</span></p><p> </p><ul><li><b>Navigator-driver-mob<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6GDWeccZRiq1Cc0vMH4N"><img loading="lazy" width="250" height="101" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6GDWeccZRiq1Cc0vMH4N" alt="navigator-driver" /></a> <br /> </b>The navigator becomes the driver, the driver joins the mob, and the next out of the mob becomes the navigator.</li></ul><p> </p><ul><li><b>Driver-navigator-mob<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RAGYBbtkSCiCaeFqzPsp"><img loading="lazy" width="250" height="100" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RAGYBbtkSCiCaeFqzPsp" alt="driver-navigator" /></a> <br /> </b>The driver becomes the navigator, the navigator joins the mob, and the next out of the mob becomes the driver.</li></ul><p> </p><ul><li><b>Driver-mob-navigator-mob<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LxVateSEOpHjgdvdHkow"><img loading="lazy" width="250" height="115" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LxVateSEOpHjgdvdHkow" alt /></a> <br /> </b>The driver and the navigator join the mob and the next two of the mob become the driver and the navigator.</li></ul><p><i><span>Driver-navigator-mob</span></i><span> became our default order, because:</span></p><ul><li><span>If someone lost touch with what was going on, they had a better chance to mentally get back into it as a driver before becoming navigator. </span></li><li><span>The changeover friction is reduced when the driver comes from the mob. They can ensure they have the right programs and classes open 30 seconds before changeover, which isn’t practical when they’re trying to navigate.</span></li></ul><p><span>However, at various times we found the other patterns to be interesting and helpful. Did we mention it before? We loved to experiment.</span></p><h2><span>Psychological safety</span></h2><p><span>Research has shown that psychological safety is a strong predictor of team performance. This is basically feeling comfortable to say what you think and be who you are without embarrassment or fear of repercussions. Collaborating together so closely helped us bond as people. There was rarely such a thing as “someone else’s code”, and everyone knew and was comfortable with everyone else’s capabilities and personal circumstances.</span></p><p><span>We managed to meet and work together in person a number of times – something which is very beneficial. Meet live, have a beer together in the evening, meet the family of your colleague – these are things which strengthen a team into a unit.</span></p><h2><span>The irony of shared everything and bus factor</span></h2><p><span>Using the mob programming approach as part of a “shared everything” mindset can be very beneficial. As the project went on, we noticed that our bus factor had approached our team size. In other words, you would basically need to remove the entire team for the knowledge and skills to be lost from the project. This is quite a phenomenal result.</span></p><p><span>We also discovered a high satisfaction spread through the team. Everyone was passionate about doing the experiments and working with each other. No-one feared to say “I didn’t get this”, “could we change this?” Or, “we should try this”.</span></p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/czdEdbSNSSeqOmZFiPz7"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/czdEdbSNSSeqOmZFiPz7" alt="leaving" width="1024" height="372" /></a> <p>– Image by Ryan Tang, unsplash</p></div><p><span>High bus factor protects the team in the case that people leave it. Yet the irony of this is, when a “shared everything” team is established, no-one wants to leave. We had no fluctuation in our team during that project.</span></p><p><span>Despite the really interesting technologies and co-operative customer involved in the project, at the end of the project one team member summed up the team feeling by saying “I’m really sad that this project is ending. Not really because of the project work, but because of losing the team”.</span></p>

Mob programming and shared everything

The developer's dilemma - mastering the transition to AI engineering

5 reasons we developers misjudge agentic software engineering

Staff Engineer

Einführung in Hadoop – Die wichtigsten Komponenten von Hadoop (Teil 3 von 3)

<h2>MongoDB</h2><p><strong>MongoDB</strong> (abgeleitet vom engl. <em>hu<strong>mongo</strong>us</em>, „gigantisch“) ist eine hochperformante, schema-freie, dokumentenorientierte Open-Source-Datenbank, die in der Programmiersprache C++ geschrieben ist.<span> </span>Da die Datenbank dokumentenorientiert ist, kann sie Sammlungen von JSON-ähnlichen Dokumenten verwalten. So können viele Anwendungen Daten auf natürlichere Weise modellieren, da die Daten zwar in komplexen Hierarchien verschachtelt werden können, dabei aber immer abfragbar und indizierbar bleiben. Eine kurze Einleitung, die die ersten Schritte mit MongoDB erklärt, gibt <a href="/wissens-hub/blog/spring-data-mongodb-2" target="_blank">dieser Artikel</a> .</p><p><span></span></p><p>Bei MongoDB handelt es sich um eine NoSQL-Datenbank, wobei NoSQL ein Sammelbegriff für eine Vielzahl von unterschiedlichen Datenbanklösungen ist, welche sich besser als „Nicht-relationale Datenbanken“ beschreiben lassen. Ihren Ursprung hatten diese Lösungen in der Erkenntnis, dass gerade für Big Data Probleme „traditionelle“ relationale Datenbanken (RDBMS) mit ihren meist starren Schemas und normalisiert in Tabellen gepressten Daten nicht die ideale Lösung sind. Zudem ist man in Sachen der Skalierbarkeit von RDBMS immer häufiger an Performance- und Kostengrenzen gestoßen. Entsprechend hat man nach anderen Lösungen für diese Probleme gesucht. Ein großer Treiber hinter der NoSQL-Bewegung ist sicherlich das Internet und die Bedürfnisse von Webapplikationen, da gerade dort die Datenmengen immer größer werden, gleichzeitig werden diese Daten aber auch immer vernetzter und gerade durch die zunehmende Benutzerinteraktion des Web 2.0 werden die Daten auch immer individueller und nicht mehr klar strukturiert. Bekannteste Beispiele für auf diesen Überlegungen basierende NoSQL-Lösungen sind dabei sicherlich Google mit ihrem 2004 entstandenen <a href="http://de.wikipedia.org/wiki/BigTable" target="_blank">BigTable-Ansatz</a>  zur Speicherung ihres Suchmaschinen-Indexes sowie Amazon mit seinem 2007 publizierten <a href="http://de.wikipedia.org/wiki/Amazon_Dynamo" target="_blank">Dynamo-Ansatz</a> , welcher die Basis für die Amazon Web Services bildet. Ebenso ist auch die Erfolgsgeschichte von sozialen Netzwerken auf der technischen Seite eng mit der NoSQL-Bewegung verbunden.</p><p>Ich persönlich finde die NoSQL-Bewegung sehr spannend, da sie meiner Meinung nach stark dazu beigetragen hat, das jahrelang vorherrschende und selten hinterfragte Mantra „Datenhaltung = RDBMS“ aufzubrechen und man sich nun noch intensiver mit der eigentlichen Struktur der Daten und den Anforderungen an eine Datenhaltungslösung beschäftigt. Und die NoSQL-Bewegung gibt einem dazu eine Vielzahl von unterschiedlichen Lösungen und Ansätzen an die Hand, welche zum großen Teil auch noch als Open-Source verfügbar sind. Der Markt für NoSQL-Datenbanken ist dabei über die Jahre auch immer mehr gereift und erreicht meines Erachtens nach langsam die Spitze seines <a href="http://en.wikipedia.org/wiki/Hype_cycle" target="_blank">Hype Cycles</a> . Gleichzeitig ist der Markt für NoSQL-Lösungen aber trotzdem immer noch recht dynamisch, neue NoSQL-Lösungen entstehen und manche vielversprechende Projekte wurden auch schon wieder eingestellt. Bei dieser Entwicklung hat sich MongoDB als die gemessen an der Anzahl der Downloads <a href="http://gigaom.com/cloud/theres-a-lotta-mongodb-out-there-hadoop-too-infographic/" target="_blank">populärste NoSQL-Lösung</a>  herauskristallisiert und wird aufgrund seiner Einfachheit in der Handhabung und der breiten Funktionalität auch gerne als „Einstiegsdroge“ in die NoSQL-Welt bezeichnet. Doch auch bei allem gegenwärtigen Hype um NoSQL, darf man nicht vergessen, dass auch NoSQL-Datenbanken keine eierlegenden Wollmilchsäue sind und allein deren Einsatz automatisch alle Probleme löst. Auch sind deswegen „traditionelle“ RDBMS und SQL  noch lange nicht tot, sondern haben in vielen Anwendungsgebieten nach wie vor unschlagbare Vorteile. Sicher ist aber, wenn es heutzutage um die Architektur von Datenhaltungslösungen geht, dass man nicht mehr einäugig sein darf und sich mit den Vor- und Nachteilen von NoSQL auseinander setzen sollte, um so die passende Lösung für sein spezifisches Problem zu finden.</p><h2>MongoDB User-Gruppe Frankfurt</h2><h2><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/gCubYypDSkuNNJ4bunki"><img loading="lazy" title="Title Image MongoDB User-Gruppe Frankfurt" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/gCubYypDSkuNNJ4bunki" alt width="734" height="55" /></a> </h2><p>codecentric ist seit April dieses Jahres stolzer Consulting & Service Partner von 10gen, der Firma hinter MongoDB. Weiterhin wurden im Mai dieses Jahres bereits die ersten Schulungen zum Thema Entwicklung und Administration von MongoDB erfolgreich in Zusammenarbeit mit Trainern von 10gen durchgeführt. Diese sind auf reges Interesse gestoßen und es werden sicherlich nicht die letzten Schulungen dieses Jahr bleiben.</p><p>Aufgrund des Interesses habe ich daher vor kurzem in Zusammenarbeit mit 10gen die regionale User-Gruppe zum Thema MongoDB in Frankfurt gegründet. Diese folgt der bereits von meinem Kollegen Tobias Trelle initiierten MongoDB User-Gruppe in Düsseldorf , welche bereits ihr ersten Treffen mit einem hochinteressanten Beitrag zu „Spring Data MongoDB“  von <a href="https://twitter.com/#!/olivergierke" target="_blank">Oliver Gierke</a>  (SpringSource) hatte.</p><p>Ziel der User-Gruppe ist der regelmäßige Informationsaustausch und die Vernetzung zwischen MongoDB-Usern aus dem Großraum Frankfurt (und auch gerne darüber hinaus). Dazu bieten sich zum einen die Foren in XING zum virtuellen Austausch an, zum anderen schlägt aber natürlich nichts den persönlichen Austausch. Daher wird es monatliche Treffen der User-Gruppe im Raum Frankfurt geben, auf welchen wir Vorträge rund um das Thema MongoDB anbieten wollen und hoffentlich auch in rege Diskussionen kommen. Ich bin aktuell noch an der Planung des ersten Treffens, die Ankündigung findet zeitnah auf XING statt.</p><p>Ich freue mich auf neue interessierte Mitglieder und den gemeinsamen Erfahrungsaustausch. Let’s MongoDB!</p>

MongoDB User-Gruppe Frankfurt

<p>So lässt sich die Fragestellung dieses zweiten Teils gut zusammenfassen und wird noch ergänzt durch die Frage „Und wie viel davon?“. Tatsächlich gibt es so etwas wie ein allgemein anerkanntes „Standard“-Hadoop nicht und am nächsten dran sind hier noch die Open Source Projekte der Apache Foundation. Aber zu Apache Hadoop gehören eine Vielzahl von Projekten und welche sind nun sinnvoll und welche braucht man? Weiterhin gibt es darauf aufbauend die Hadoop-Distributionen, die einen Teil dieser Open Source Projekte bündeln und teilweise noch um eigene Komponenten erweitern. Aber natürlich unterscheiden sich die Distributionen in Umfang, Unterstützung des Betriebs und Services für den Geschäftseinsatz – und natürlich auch im Preis. Letztendlich gibt es auch noch den Bereich der Big Data Suiten, die nochmal weitere Funktionalität wie etwa die Visualisierung der Daten und erweiterte Möglichkeiten für den Import & Export der Daten hinzufügen.<span></span></p><p>Die folgende Grafik stellt dieses Spektrum dar und im Folgenden wollen wir uns diesen drei Kategorien widmen und sie näher darstellen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/5zrjxoOkQUChltezgS9S"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/5zrjxoOkQUChltezgS9S" alt="übersicht_hadoop_pakete" width="672" height="504" /></a> </p><p> </p><h2>Apache Hadoop</h2><p>Die Komponenten von Hadoop sind bei der Apache Foundation angesiedelt und stehen unter der <a href="http://www.apache.org/licenses/LICENSE-2.0" target="_blank">Apache License 2.0</a> . Bei Hadoop handelt es sich nicht nur um ein einzelnes Projekt, sondern um eine Vielzahl von zusammenhängenden und aufeinander aufbauenden Projekten. In diesem Zusammenhang spricht man gerne von den Kernkomponenten von Hadoop, welche die Grundlage für Hadoop und alle anderen Projekte bilden, die man als das Hadoop Ökosystem bezeichnet. Die Kernprojekte sind die folgenden:</p><ul><li><b>Hadoop Distributed File System (HDFS): </b><span>Ein verteiltes Dateisystem für die Speicherung und Verwaltung großer Datenmengen</span></li><li><b>Hadoop MapReduce: </b>Ein Framework zur verteilten und parallelen Verarbeitung von in HDFS gespeicherten Datenmengen</li></ul><p>Während sich Apache Hadoop recht einfach auch in einem lokalen Modus auf einem einzelnen Rechner für die Entwicklung installieren lässt, ist die Installation und der Betrieb in Clustern deutlich komplexer. Zum einen gibt es keine eingebaute Unterstützung bei der Installation von Hadoop in einem Cluster und ebenso gibt es auch keine Unterstützung zur Überwachung des Clusters im laufenden Betrieb. Zum zweiten beschränkt sich Apache Hadoop tatsächlich auf den Kern dessen, was Hadoop ausmacht. Das gesamte darum entstandene Ökosystem ist nicht enthalten und möchte man weiteren Komponenten nutzen, so müssen diese alle von Hand installiert werden. Und hier steht man schon vor dem ersten Problem, dass man sich die jeweils miteinander kompatiblen Versionen selbst aussuchen muss. Schließlich gibt es keinerlei kommerziellen Support und Firmen müssen alle ihre Hadoop-Probleme selbst lösen, wozu vor allem der meist langwierige Aufbau von entsprechendem Know-how gehört.</p><p>Daraus ist ersichtlich, dass sich Apache Hadoop insbesondere für Experimente oder für interessierte Entwickler eignet. Während ein Einsatz im Clusterbetrieb für mittelgroße Firmen durchaus möglich ist, empfiehlt es sich je nach Geschäftsmodell aber durchaus zumindest auf eine Hadoop-Distribution zu setzen – und sei es alleine schon wegen der kürzeren Einarbeitung und dem professionellen Support.</p><p> </p><h2>Hadoop Distributionen</h2><p>Hadoop-Distributionen sind ganz klar auf den Einsatz im Enterprise-Umfeld ausgelegt. Der Markt ist zwischen einer Handvoll etablierter Anbieter aufgeteilt, wobei natürlich immer wieder neue Anbieter versuchen diese Phalanx zu durchstoßen. Der Umfang der Distribution unterscheidet sich natürlich von Anbieter zu Anbieter leicht, aber die wichtigsten Komponenten aus dem Hadoop-Ökosystem wie Pig, Hive und HBase sind bei allen dabei und werden teilweise noch um spezifische Entwicklungen der Anbieter ergänzt. Die Releasezyklen zwischen verschiedenen Versionen der Distributionen liegen typischerweise bei 3 bis 6 Monate und die Distributionen enthalten nicht immer die aktuellsten Versionen aller Komponenten. Dafür wird aber Sorge dafür getragen, dass auch alle Komponenten und Systeme miteinander kompatibel sind und entsprechend wird viel Wert auf den Test und die Sicherstellung des Zusammenspiels gelegt. Alle etablierten Distributionen bieten zudem Werkzeuge zur Clusterinstallation und -administration und zudem bieten die Anbieter optionalen kommerziellen Support an.</p><p>Die wichtigsten Anbieter von Hadoop-Distributionen sind die folgenden:</p><p><b><a href="http://www.cloudera.com/" target="_blank">Cloudera</a> </b><br /> Die am weitesten verbreitete Distribution mit den meisten Referenzinstallationen. Es gibt leistungsfähige, aber proprietäre Werkzeuge zur Clusteradministration. Mit Impala treibt Cloudera zudem ein quelloffenes Projekt zur Echtzeitabfrage von großen Datenmengen voran. Es gibt zwar eine kostenfreie Version der Distribution, für den kommerziellen Einsatz fallen allerdings Lizenzgebühren in Abhängigkeit der Größe des Clusters an, die dann aber auch professionellen Support beinhalten.</p><p> </p><p><b><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/qvGspYbR22SXfRibj26w"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/qvGspYbR22SXfRibj26w" alt="Hadoop Distribution Hortonworks" width="100" height="100" /></a> </b></p><p><a href="http://hortonworks.com/" target="_blank"><b>Hortonworks</b></a> <br /> Die einzige Distribution am Markt, die 100% quelloffen ist und keine Lizenzgebühren verlangt. Alle Weiterentwicklungen, die Hortonworks vornimmt, fließen direkt in die Open Source Projekte von Apache Hadoop ein und Hortonworks ist eine treibende Kraft hinter der Entwicklung von Hadoop 2.0. Zudem bietet Hortonworks in Kooperation mit Microsoft als einziger Anbieter Hadoop für Windows und Azure an. Während für die Distribution selbst keine Lizenzgebühren anfallen, bietet Hortonworks aber auch Business-Support an und die Höhe der Supportgebühren richtet sich auch hier nach der Clustergröße.</p><p> </p><p><b><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UXIvHyncRnOQz8aLxFMZ"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/UXIvHyncRnOQz8aLxFMZ" alt="Hadoop Distribution MapR" width="100" height="100" /></a> <a href="http://www.mapr.com/" target="_blank">MapR</a> </b><br /> Die Besonderheit dieser Distribution besteht darin, dass MapR direkt auf das Unix-Dateisystem aufsetzt und damit proprietär eine Alternative zu HDFS anbietet. Auch hier gibt es eine kostenfreie Version der Distribution, für den kommerziellen Einsatz fallen allerdings Lizenzgebühren in Abhängigkeit der Größe des Clusters an, die dann aber auch professionellen Support beinhalten.</p><p> </p><p><b><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9D7VGt87Tb6DDwOEYa5g"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9D7VGt87Tb6DDwOEYa5g" alt="Hadoop Distribution Amazon" width="100" height="100" /></a> </b> <a href="http://aws.amazon.com/de/elasticmapreduce/" target="_blank"><b>Amazon Elastic Map Reduce</b></a> <br /> Amazon bietet seine eigene Hadoop-Distribution auf der Basis der Cloudlösungen EC2 und S3 an, wobei die Distribution speziell darauf ausgerichtet ist, S3 anstelle von HDFS als Speicher zu verwenden. Kunden haben den Vorteil, dass Amazon das komplette Clustermanagement übernimmt, bezahlen dies aber auch mit dem Nachteil, dass S3 als Speicher nur bedingt geeignet und daher wesentlich langsamer als HDFS ist. Die Bezahlung richtet sich wie bei Amazon üblich nach den tatsächlich genutzten Ressourcen wie CPU und Speicherplatz.</p><p> </p><p>Es gibt noch weitere Distributionen, z.B. von <a href="http://gopivotal.com/pivotal-products/pivotal-data-fabric/pivotal-hd" target="_blank">Pivotal</a>  oder Intel, die aber jeweils relativ speziell sind und bisher noch eine geringe Verbreitung haben. Die Auswahl der Distribution hängt nur zum Teil davon ab, welche Features man benötigt, denn in dieser Hinsicht ähneln sich die Distributionen doch sehr. Die wichtigsten Fragen, die man sich während der Evaluierung der Hadoop-Distributionen stellen sollte, sind die folgenden:</p><ul><li>Möchte man sich an einen Anbieter binden (Vendor-Lock-In)?</li><li>Wie hoch sind die Lizenzgebühren für den eigenen Anwendungsfall?</li><li>Möchte bzw. kann man den Hadoop-Cluster selbst betreiben?</li><li>Welcher Grad an professionellem Support wird benötigt?</li></ul><p> </p><h2>Big Data Suiten</h2><p>Die Verwendung einer Big Data Suite zielt darauf ab, den Analysten und Endanwendern im Unternehmen die Arbeit mit Hadoop wesentlich zu erleichtern und ihnen zu erlauben, Werkzeuge zu verwenden, die sie gewohnt sind. Folgende zusätzliche Leistungen bieten Big Data Suiten:</p><p><b>Integrierte Umgebung</b></p><p>Es gibt eine integrierte grafische Benutzerumgebung, meist basierend auf dem bekannten Eclipse mit eigenentwickelten Plugins, aus der heraus viele Funktionen aufgerufen werden können und welche somit die Entwicklung vereinfacht.</p><p><b>Visualisierung</b></p><p>Mit den Bordmitteln von Apache Hadoop ist man bei der Anzeige der Daten meist auf Kommandozeilentools beschränkt. An dieser Stelle erweitern Big Data Suiten den Funktionsumfang und bringen eigene Tools zur Visualisierung und Aufbereitung der in HDFS gespeicherten Daten mit.</p><p><b>Echtzeitanalyse</b></p><p>Gerade zur Exploration von Daten wollen Analysten Antworten auf Anfragen idealerweise in Echtzeit bekommen und nicht erst immer auf langlaufenden MapReduce-Jobs warten, nur um dann festzustellen, dass irgendwo noch ein kleiner Fehler war. Daher benutzen Big Data Suiten verschiedene Techniken wie Vorkompilation und Datenauszüge, um erst mal ein Rapid Prototyping auf einer kleinen, möglichst repräsentativen Datenmenge zu ermöglichen, bevor die MapReduce-Jobs auf der gesamten Datenmenge ausgeführt werden.</p><p><b>Modellierung & Codegenerierung</b></p><p>Analysten wollen (und können meist) keine MapReduce-Anwendungen schreiben, welche aber die Basis jeglicher Datenverarbeitung in der aktuellen Version von Hadoop sind. Und auch wenn Apache Hadoop und die Hadoop Distributionen mit dem skriptähnlichen Pig und dem SQL-ähnlichen Hive bereits abstrakte Abfragesprachen bieten, gehen viele Big Data Suiten noch einen Schritt weiter und bieten graphische Oberflächen zum Erstellen von MapReduce-Anwendungen, welche den zugehörigen Code dann automatisch generieren.</p><p><b>Scheduling</b></p><p>Auf großen Clustern spielt die Verwaltung von MapReduce- Jobs und die Modellierung ihrer Abhängigkeiten eine große Rolle. Zwar gibt es in Apache Hadoop mit dem Fair und Capacity Scheduler bereits zwei unterschiedliche Strategien mit rudimentären Weboberflächen und auch das Hadoop Ökosystem hält mit Apache Oozie eine Workflow-Lösung parat, allerdings erweitern die Big Data Suiten auch diese Funktionalitäten teilweise um komfortablere Werkzeuge.</p><p><b>ETL & Konnektoren</b></p><p>Daten stammen aus verschiedensten Quellen, aus SQL- und NoSQL-Datenbanken, aus Logdateien, aus B2B-Systemen wie Salesforce und SAP oder von sozialen Medien wie Facebook und Twitter. Big Data Suiten bieten dazu Konnektoren an, damit Datenquellen einfach an Hadoop angeschlossen und Daten ausgetauscht werden können. Das Schreiben von Schnittstellencode wird so vermieden.</p><p>Angeboten werden Big Data Suiten einerseits von spezialisierten Anbietern wie etwa <a href="http://de.talend.com/" target="_blank">Talend</a> , Teradata<b>, </b>Pentaho, <a href="http://www.datameer.com/" target="_blank">Datameer</a> , etc.<b> </b>und auf der anderen Seite erweitern mittlerweile auch Softwareanbietern wie <a href="https://www.microsoft.com/de-de/sql-server/sql-business-intelligence" target="_blank">Microsoft</a> , <a href="http://www-01.ibm.com/software/data/infosphere/hadoop/" target="_blank">IBM</a> , <a href="http://www.oracle.com/de/technologies/big-data/index.html" target="_blank">Oracle</a>  ihre Produktpalette um entsprechende Angebote.</p><p>Und so breit wie hier das Angebot an Lösungen ist, so unterschiedlich sind auch viele dieser Big Data Suiten und reichen von spezialisierten Produkten bis hin zu viele Bereiche abdeckende Produkten. Die Entscheidung für eine Suite hängt daher von einer Reihe von Faktoren ab und man sollte sich zuerst diese grundlegenden Fragen stellen:</p><ul><li>Erfüllt die Big Data Suite die jeweiligen Anforderungen?</li><li>Ist sie für technisch nicht so versierte Endbenutzer intuitiv benutzbar?</li><li>Welche Softwareanbieter sind im Unternehmen schon vorhanden?</li><li>Wie integriert sich die Big Data Suite mit der bestehenden Unternehmenssoftware?</li><li>Wie steht man zum Open-Source-Ansatz?</li><li>Welche Lizenzkosten sind zu erwarten?</li></ul><p>Diese Übersicht über das Universum an Hadoop-Plattformen zeigt, wie groß die Auswahl ist. Dadurch wird aber auch deutlich, dass man seine jeweiligen Anforderungen möglichst genau kennen sollte, um dann zu entscheiden, ob Apache Hadoop, eine Hadoop-Distribution oder eine Big Data Suite am besten passt. Die Auswahl des passenden Anbieters folgt erst danach. Dabei werden neben der Eignung für das jeweilige Projekt sicherlich auch weitere individuelle, unternehmensübergreifende Kriterien eine Rolle spielen.</p><p>Weiter geht es in <a href="/wissens-hub/blog/einfuhrung-in-hadoop-die-wichtigsten-komponenten-von-hadoop-teil-3-von-5">Teil 3 mit den wichtigsten Komponenten von Hadoop, hier lang…</a> </p>

Einführung in Hadoop – Welches Hadoop hätten’s denn gern? (Teil 2 von 3)

<h2>Was ist Big Data?</h2><blockquote><p><strong>„Big Data ist, wenn die Daten selbst Teil des Problems werden“</strong></p></blockquote><p>Diese kurze Definition in Anlehnung an ein Zitat des Verantwortlichen für Marktforschung bei O’Reilly Media, Roger Magoulas, ist in meinen Augen die beste Charakterisierung von Big Data, gerade weil sie so kurz und prägnant ist und trotzdem den Kern des Problems – und der Herausforderungen – so zeitlos umfasst. Hier wird gar nicht erst probiert, das aktuelle Hype-Thema Big Data anhand reiner Zahlen wie „Big Data ist alles über 1, 5, 10, 50, … GB, TB, PB, …“ festzuzurren. Big Data in Zahlen zu fassen scheint aber anscheinend trotzdem ein menschliches Grundbedürfnis zu sein, ich weiß nicht wie viel Zeit ich auf User Groups , Open Spaces, Konferenzen, etc. allein mit der Diskussion der „Größe“ von Big Data verbracht habe. Und diese Diskussion ist eigentlich nie zielführend gewesen, viel wichtiger ist es in meinen Augen, die Prinzipien hinter den Technologien zu verstehen und welche Möglichkeiten sich dadurch ergeben. Und genau das möchte ich in dieser Blog-Serie versuchen zu beleuchten, wohl wissend, dass Big Data nicht nur Hadoop ist, auch wenn die aktuelle Berichterstattung dies häufig zu suggerieren scheint. Aber Hadoop ist zumindest ein nicht unbedeutender Teil von Big Data, daher fangen wir einfach mal damit an und andere Themen werden sicherlich folgen.</p><h2>Das 3V-Prinzip<span></span></h2><p>Zurück zum Thema: Das ursprüngliche Zitat von Roger Magoulas bezog sich lediglich auf die Größe der Daten und ich denke wie so viele, dass diese Hervorhebung zu einseitig ist und zu kurz greift. Natürlich ist die Größe der Daten einer der offensichtlichsten Faktoren bei Big Data – der Name kommt schließlich nicht von ungefähr. Trotzdem wäre das zu eindimensional und verkennt die weiteren Dimensionen des Phänomens Big Data. Dies sehen auch die Analysten von Gartner so, wie sie nicht müde werden zu betonen, und ihr 3V-Prinzip ist sicherlich die populärste Definition von Big Data und ich denke, dass Sie diese auf jeden Fall  zumindest kennen sollten. Die Definition ist mittlerweile von diversen Autoren und Marketingabteilungen noch um einige V’s erweitert worden, ich will mich aber auf die ursprüngliche Definition beschränken:</p><blockquote><p><b>Volume (= Größe der Daten)</b></p><p><b><span>Mit den exponentiell steigenden Datenvolumen, die von Unternehmen angesammelt werden, geht es in der Regel darum, große Datenmengen zu speichern und zu analysieren. Wir reden dabei heutzutage typischerweise über Daten im Terabyte- bis Petabyte-Bereich, die traditionelle Systeme an ihre Grenzen bringen bei dem Versuch diese Datenflut effizient zu verarbeiten.</span></b></p><p><b>Velocity (= Geschwindigkeit der Daten)</b></p><p><b>Die Geschwindigkeit der Datenerzeugung nimmt ständig zu. Bei neu entstehenden Datenquellen wie mobilen Geräten, sozialen Netzwerken, Sensordaten, RFID, etc. werden die Daten kontinuierlich in Echtzeit generiert. Aber auch die Speicherung über mehrere Kanäle hinweg und die nachfolgende Datenanalyse soll möglichst in Echtzeit stattfinden, um schnelle Entscheidungen zu treffen und so Wettbewerbsvorteile zu sichern.</b></p><p><b>Variety (= Vielfalt der Daten)</b></p><p><b>Die Dimension „Vielfalt“ bezieht sich nicht nur auf unterschiedliche Datenformate, die von verschiedenen Datenquellen erzeugt werden. Mit dem Einsatz von RFID-Sensoren, Roboter und der explosionsartigen Verbreitung von  sozialen Netzwerken werden Daten in zahllosen Formaten wie Text, Video, Audio, Sensordaten, Tweets, Logausgaben usw. generiert. Auch die Notwendigkeit mit unterschiedlichen Datentypen wie strukturierte, semistrukturierte und unstrukturierte Daten arbeiten zu müssen, trägt zur Komplexität der Lösung bei.</b></p></blockquote><h2>Und was ist mit NoSQL?</h2><p>Im Zusammenhang mit Big Data stößt man häufig ebenfalls auf den Begriff <b>NoSQL</b> – auch Sie sind sicherlich in diesem Zusammenhang schon mal über die dokumentenbasierte Datenbank <a href="http://www.mongodb.org/" target="_blank">MongoDB</a> , den verteilten Key-Value-Store <a href="http://basho.com/riak/" target="_blank">Riak</a> , die Graph-Datenbank <a href="http://www.neo4j.org/" target="_blank">Neo4</a> j und weitere Lösungen gestolpert. Und auch wenn diese technische Lösungen meist auf den Grundprinzipien der vertikalen Skalierbarkeit und der Verwendung von Commodity Hardware aufbauen und sich somit ebenfalls für die Speicherung und Verarbeitung von großen Datenmengen eignen, so ist der Begriff Big Data heutzutage doch fast synonym mit <a href="http://hadoop.apache.org/" target="_blank">Apache Hadoop</a>  verknüpft.</p><p>Ich will diese Verknüpfung auch gar nicht erst bewerten, denn auf Basis von NoSQL-Datenbanken sind ebenfalls eine Vielzahl von innovativen Lösungen entstanden und sie haben Ihre ganz eigenen Einsatzzwecke und sind somit Teil des Big Data Lösungsraums. Der Grundsatz ist dabei wie immer „Wähle das richtige Tool für deine Aufgabe“ und Hadoop ist eben für viele Aufgaben im Bereich von Big Data das richtige Tool. Das können Sie nach der Lektüre dieser Serie aber hoffentlich selbst bewerten und ich vertraue auf Ihr Interesse als Leser, sich tiefer in das Thema hineinzuarbeiten, z.B. mit der Lektüre des sehr empfehlenswerten Buchs (mit dem sperrigen Titel) <a href="http://www.amazon.de/Big-Data-f%C3%BCr-IT-Entscheider-gewinnbringend/dp/3446433392/" target="_blank">„Big Data für IT-Entscheider: Riesige Datenmengen und moderne Technologien gewinnbringend nutzen“</a>  meines Kollegen und Big Data Experten <a href="http://www.amazon.de/Pavlo-Baron/e/B0045B2NBY/" target="_blank">Pavlo Baron</a> .</p><h2>Nun aber zu Hadoop…</h2><p>Fokussieren wir uns nun also auf Hadoop: Das von der Apache Software Foundation geleitete Open Source Projekt Hadoop ist ein Framework zum verteilten Speichern und parallelen Verarbeiten von großen Datenmengen in horizontal verteilten Umgebungen. Die <strong>horizontale Skalierung</strong> („Scale out“) ist dabei eines der Grundprinzipien von Hadoop, welche es ermöglicht große Datenmengen sicher und fehlertolerant auf bis zu mehreren Tausend Servern  innerhalb eines Clusters zu verteilen. Dabei kommen nicht mehr teure und spezielle Server („Scale up“) zum Einsatz, sondern es wird auf kostengünstige Commodity Hardware gesetzt.</p><p>Neben dem Speichern von großen Datenmengen ist das verteilte und parallele Verarbeiten dieser Daten eine weitere Kernaufgabe von Hadoop. Dafür hat Hadoop viele intelligente und effiziente Mechanismen entwickelt, wobei das <strong>Prinzip der Datenlokalität</strong> das Wichtigste ist. Dabei werden nicht wie in klassischen Systemen die Daten zu den Servern transportiert, die dann den Programmcode ausführen, sondern der Programmcode wird auf die Server im Cluster mit den zugehörigen Daten verteilt, dann dort verteilt ausgeführt und die (Teil-)Ergebnisse wieder zusammengeführt. Auf diese Weise werden zeitintensive Datentransfers über das Netzwerk minimiert, der Cluster skaliert sehr gut und insgesamt wird dadurch die Geschwindigkeit der Datenverarbeitung erhöht bzw. in vielen Fällen überhaupt erst ermöglicht! Dieser Ansatz der Verarbeitung bewirkt aber auch, dass <strong>Hadoop im Grundsatz ein Batch-System ist</strong> und somit z.B. weniger für Aufgaben im Realtime-Bereich oder für iterative Algorithmen geeignet ist, sondern eher den Fokus auf die – meist nachträgliche – parallele Verarbeitung und Aggregation von Daten legt. Ein Umstand den man trotz allen aktuellen Bemühungen und auch Erfolgen, Hadoop immer mehr in Richtung (Near-)Realtime zu entwickeln, niemals vergessen sollte.</p><p>Nach der kurzen Einführung in Big Data und Hadoop geht es im nächsten Teil weiter mit einer Übersicht über die <a href="/wissens-hub/blog/einfuhrung-in-hadoop-welches-hadoop-hattens-denn-gern-teil-2-von-5">Hadoop-Plattformen, folgen Sie mir einfach…</a> </p>

Einführung in Hadoop – Was ist Big Data & Hadoop? (Teil 1 von 3)

Delivery Manager / Standortleiter Frankfurt

Cloud Security Architect

<p>In der Praxis treten innerhalb von Projekten häufig Schwierigkeiten auf, die auf unklare oder unscharfe Abgrenzung von Fachlogik zurückzuführen sind. Ursache häufig: die Problemdomäne ist für den Kunden nicht immer klar, oder von vornherein wurde die Domäne viel zu groß oder am eigentlichen Problem vorbei abgesteckt. Mitunter entstehen dadurch Probleme beim Laufzeitverhalten – häufige, gegenseitige Aufrufe von Microservices, Nebenläufigkeitsprobleme, hohe Latenzzeiten etc. – die erhebliche Nachbesserungen und Behebungskosten nach sich ziehen.<br /> Im Extremfall ist das ganze Unternehmen als „kanonisches Datenmodell“ umgesetzt – ein absolutes <a href="https://jaxenter.de/microservices-patterns-antipatterns-73293" target="_blank">Anti Pattern</a>  für moderne Microservice-Architekturen. Und natürlich kann es zu fundamentalen Missverständnissen zwischen Fachabteilung und Entwicklern kommen, welche dazu führen, dass ein Projekt komplett am eigentlichen Ziel vorbei entwickelt wird.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hxCLYYb5RqiCoH2Yeq5N"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hxCLYYb5RqiCoH2Yeq5N" alt="Event Storming Such-Trend" width="700" height="207" /></a> </p><p>Durch die Methoden des Domain Driven Designs sollen solche Probleme vermieden werden. Es gilt, zunächst ein gemeinsames Bild von der Fachlichkeit zu finden und ein von technischen Details möglichst befreites Modell zu entwickeln, auf das in der Folge die gesamte Systemarchitektur ausgerichtet wird. Ein sinnvoller erster Schritt auf dem Weg dorthin ist Event Storming (auch: EventStorming). Von Alberto Brandolini entwickelt, erfreut sich dieses Workshop-Format großer Beliebtheit, und das Interesse an Event Storming steigt in den letzten Jahren deutlich (siehe Bild 1).</p><h2>Das Ziel von Event Storming</h2><p>Ziel von Event Storming ist es, ein gemeinsames Verständnis für die Domäne(n) zu erlangen, sowie eine gemeinsame Sprache aller an der Entwicklung beteiligten Fachleute und Softwarespezialisten zu definieren, die „Ubiquitous Language“. Über die einzelnen Abteilungs-Silos hinweg werden Business Cases modelliert und für alle Beteiligten sichtbar und verständlich gemacht. Probleme und Bottlenecks können identifiziert und die wichtigsten Bestandteile eines Business-Prozesses herausgefunden werden – z.B. für die Entwicklung eines MVPs.</p><p>Das sichtbare Ergebnis des Workshops (siehe Bild 2) ist ein großflächiges Bild der Prozesse und ihrer umgebenden Kontexte, jedoch stellt dies eher einen Anfangs- als einen Endpunkt dar: Man muss klarstellen, dass kein finales Modell der Domäne zu erwarten ist, sondern immer nur ein „Snapshot“ der mit den Teilnehmern und dem aktuellen Wissensstand entwickelten Sicht auf das fachliche Problem. Das eigentliche Domänen-Modell entsteht später innerhalb des Codes der Anwendung.</p><p>Noch wichtiger ist aber, dass losgelöst vom Artefakt ein einheitliches Wording für die verschiedenen Konzepte innerhalb der identifizierten Domänen entsteht. Durch den initialen Fokus auf Events wird die Komplexität maximal reduziert, und es kann sich leicht auf die ablaufenden Prozesse konzentriert werden. Entwicklungsteams können so schnell in eine Domäne eingearbeitet werden, und durch den Austausch mit den Domänenexperten frühzeitig Unklarheiten klären oder vermeiden.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/l0h1gDC1Qta9FyOw8ZbT"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/l0h1gDC1Qta9FyOw8ZbT" alt width="700" height="197" /></a> </p><h2>Der Workshop in Kürze</h2><p><span>Innerhalb eines codecentric-internen Trainings unter Anleitung von Tobias Goeschel konnten wir erste Erfahrungen mit Event Storming sammeln. Dabei wurde ein (fiktives) Szenario als Rollenspiel modelliert und durch die 4 grundlegenden Schritte von Event Storming vertieft: </span></p><ul><li><span>Big Picture</span></li><li><span>The Picture That Explains Everything</span></li><li><span>Process Modelling</span></li><li><span>Software Design</span></li></ul><p>Im Folgenden beschreibe ich kurz meine dabei gesammelten Eindrücke und Erkenntnisse.</p><h3>Das Setup</h3><p>Eine Stärke des Event Stormings ist, dass fachliche Experten (Stakeholder, POs, evtl. Nutzer) und Entwickler im selben Raum sind. Dabei ist auf eine gleichmäßige Verteilung zu achten: Es sollten annähernd die gleiche Anzahl Fachexperten und Implementierer anwesend sein. Idealerweise umfasst die Gruppe nicht mehr als 15 Personen, der “Sweet Spot” liegt bei etwa der Hälfte, also 8-10 Personen.</p><p>Der Moderator stellt am Anfang des Workshops eine “unendlich” große Fläche zur Verfügung (z.B. auf einer Papierrolle), um später darauf die Klebezettel platzieren zu können. Ein Raum mit viel glatter Wandfläche ist hierfür am besten geeignet. Dazu wird eine ebenfalls “unendliche” Anzahl an Klebezetteln in unterschiedlichen Farben und Ausprägungen, sowie passende Stifte, für die Teilnehmer bereitgestellt.</p><p>Die Wandfläche repräsentiert – in der Regel von links nach rechts – den zeitlichen Horizont für die zu entdeckenden Prozesse. Klebezettel sind als Modellelemente ideal, denn man kann sie frei sortieren, verschieben und wegschmeißen. Nichts ist “in Stein gemeißelt” – im Gegenteil werden im Laufe des Workshops immer wieder Teile des Modells verworfen, verschoben oder erweitert. Der Moderator greift in die Diskussionen nur minimal lenkend ein, um den Workshop erfolgreich ins Ziel zu führen, lässt aber ansonsten den Teilnehmern möglichst viel Freiraum. Eine Legende mit den verschiedenen „Building Blocks“ des Workshops entsteht während der Arbeit und steht jederzeit zur Verfügung.</p><h3>Das Vorgehen</h3><p>Das Vorgehen zu Beginn des Event Storming Workshops ist explorativ und bewusst nicht darauf ausgelegt, dass von Anfang an alles „perfekt“ wird. Das Wording muss noch nicht immer stimmen, die Events – zunächst der einzige verfügbare Baustein – nicht immer „korrekt“ formuliert sein. Wichtig ist, dass der Einstieg leicht fällt, und dadurch die Gruppe schnell in einen Flow kommt und kreativ aktiviert wird. Die Domäne wird anschließend iterativ erkundet und das Modell Schritt für Schritt immer weiter ausgearbeitet. Im weiteren Verlauf des Workshops stellt der Moderator nach und nach weitere Tools und Bausteine zur Verfügung, um die Teilnehmer nicht mit Informationen zu überladen. Dies hat den Nebeneffekt, dass durch veränderte Bedingungen auch unterschiedliche Aspekte der Fachlichkeit beleuchtet werden, was Schärfung und Detailreichtum des Modells fördert.</p><h4><em>„The Big Picture“</em></h4><p>Der Workshop startet damit, dass die Aufgaben der Teilnehmer klargestellt werden: Die Domänenexperten dürfen Ereignisse auf Klebezettel schreiben, die Entwickler müssen sie auf der Modellfläche platzieren und in eine sinnvolle Reihenfolge bringen. Werden diese „falsch“ angebracht, sollen die Fachexperten einschreiten und verbessern. Sind Zusammenhänge unklar, werden durch die Entwickler Fragen gestellt und von den Experten beantwortet. Alle sollen dabei ausgiebig miteinander über die Events diskutieren, diese in Frage stellen und Verbesserungsvorschläge machen.</p><p>Zuerst werden – wie bereits angedeutet – nur <i>Domain Events</i> auf der Fläche verteilt: Fachliche Ereignisse, die im zu erkundenden Problemraum zu beobachten sind. Den Anfang zu machen, ist dabei vielleicht das Schwerste – der Moderator kann etwas nachhelfen. Danach kommt man schnell in eine regelrechte Flut von neuen Events, welche zeitlich vor, parallel zu, oder nach dem ersten Event stattfinden.</p><p>Natürlich können „falsche“ (also vermeintlich schlecht benannte) oder doppelte Events angebracht werden. Der Moderator kann darauf hinweisen, dass diese Events nicht unbedingt der Konvention entsprechen, aber sollte nicht unbedingt dadurch den Fluss an neuen Events verlangsamen. Wichtig ist, ein ganzheitliches Bild des Prozesses zu erlangen. Später können Events nachgeschärft oder verbessert werden.</p><p>Teile des Prozesses werden größere Diskussionen auslösen: über Probleme, Risiken oder Entscheidungen. Man kann diese mit<i>Hot-Spot</i>-Zetteln (in lila) markieren, welche später genauer betrachtet oder nochmal geklärt werden müssen. Auf diese Weise werden allzu lange Pausen vermieden und der Arbeitsfluss bleibt konstant schnell.</p><p>Je größer das Bild wird, um so mehr bilden sich auch zusammenhängende Ketten und „Cluster“ heraus, die mittels Klebezetteln deklariert und benannt werden können.</p><p>Am Ende des „Big Picture“ ist ein Überblick über das „große Ganze“ entstanden – die Gruppe hat eine Vorstellung der Dimensionen und Zusammenhänge entwickelt und bereits jetzt viele Abstimmungen und Einigungen erzielt.</p><h4><b><i>„The Picture That Explains Everything“</i></b></h4><p>Sobald sich ein klareres Bild ergibt, der Fluss an neuen Events langsamer wird und auch die Diskussionen weniger werden, stellt sich die Frage nach dem Ursprung der Ereignisse: Akteure  (Strichmännchen) werden identifiziert und benannt, sowie „Commands“, also Befehle, eingeführt. Dabei gilt der Befehl nicht etwa anderen Akteuren, sondern ergeht an das System. Ein Befehl verändert den Systemzustand – und die Veränderung wird als Ereignis sichtbar.</p><p>Durch die Einführung der neuen Elemente entstehen neue Diskussionen, es wird ein verfeinertes Bild der Abläufe erzeugt. Ein Command kann durch verschiedene (auch mehrere) Akteure ausgelöst werden, welche aus ganz unterschiedlichen Gründen eine Entscheidung treffen. Es stellt sich ggf. heraus, dass einige Events unnötig sind, oder andere wiederum unter falschen Annahmen erstellt wurden. Es beginnt ein stetiges Herausfordern der vorherigen Annahmen über die Prozesse.</p><p>Zum Treffen von Entscheidungen werden Daten benötigt – Read Models werden eingeführt.</p><p>Nun können die benötigten Informationen spezifiziert und diskutiert werden. Interessant ist hier, dass der Fokus vollständig auf der <i>Verwendung</i> der Daten liegt, nicht auf deren Erfassung oder Speicherung – Stammdaten, Tabellen und Verknüpfungen sind Implementationsdetails und werden „ausgeblendet“. Es ergeben sich verblüffende Erkenntnisse über die Struktur und Relevanz der Daten, die signifikante Auswirkungen auf die Lösungsarchitektur haben können:</p><p>Aus diesen neuen Informationen lässt sich bspw. leicht eine Event-Driven Architecture ableiten. Man kommt einem ganzheitlichen Bild des späteren Modells für die einzelnen Prozesse immer näher.</p><p>Automatisierbare oder eindeutig regelbasierte Entscheidungen werden als „Policies“ markiert und benannt. Hier entfällt der Akteur, da das System eigenständig agieren kann. Die genauen Geschäftsregeln werden aber zunächst noch nicht eingepflegt, da dies sowohl die Übersichtlichkeit gefährden, als auch den Arbeitsfluss unterbrechen würde. Am Ende des Workshop-Abschnitts sollte jedem Event entweder ein Command oder eine Policy zugeordnet, alle benötigten Daten identifiziert und die Akteure benannt sein – damit ist „everything explained“, also der Gesamtzusammenhang erschlossen.</p><p>Es sollte zu diesem Zeitpunkt auch deutlich werden, welche Teilprozesse untereinander kommunizieren oder in zeitlichen Abhängigkeiten stehen. Außerdem können über gezeichnete Begrenzungen die einzelnen Prozesse isoliert werden, der <a href="https://martinfowler.com/bliki/BoundedContext.html" target="_blank"><i>Bounded Context</i></a>  wird sichtbar und bildet das Ergebnis dieses Schrittes.</p><h4><b><i>Process Modelling</i></b></h4><p>Als nächster Schritt werden die einzelnen Prozesse, bestehend aus Commands, Events, Policies usw. näher betrachtet und verfeinert. Es werden Namen für die Prozesse vergeben und Teilprozesse identifiziert. Die für die Benennung der einzelnen Bausteine verwendete Sprache wird noch einmal besonders kritisch geprüft, d.h. es wird z.B. auf eine bessere Namensgebung geachtet und Konsistenz hergestellt. Das kann erneut dazu führen, dass umgruppiert und ausgetauscht wird. Kernprozesse des Geschäftsmodells (Core Domain) werden von Hilfsdomänen (Supporting Domain, z.B. Notifications, Buchhaltung, Dokumentendruck) separiert und so der Blick auf das eigene Unternehmensprofil geschärft. Nicht zuletzt werden noch „externe Systeme“, wie bspw. Email oder Payment Provider, eingefügt und in die Prozesse mit einbezogen.</p><h4><b><i>Software Modelling</i></b></h4><p>Im letzten Schritt werden die Prozesse innerhalb eines Bounded Contexts aufgelöst und die darin enthaltenen Events und Commands nach ihrer Benennung gruppiert. Zusammengehörige Elemente („Vertrag aufgesetzt“, „Vertrag zugeschickt“, „Vertrag abgeschlossen“) weisen auf die grundlegenden Bausteine des Domänenmodells hin: Sogenannte „Aggregates“, d.h. in der Regel aus mehreren einfacheren Objekten zusammengesetzte Strukturen, die die wesentlichen Bestandteile der Geschäftslogik ausmachen (in diesem Fall: „Vertrag“). Diese Objekte kapseln Zustände und Transaktionen und bilden später in der Implementation die Grundstruktur des modularen Systems. Nun zahlt sich aus, wie akribisch der bisherige Workshop durchgeführt wurde: Je präziser die Benennung, umso leichter ist es, auf die richtigen Strukturen zu stoßen.</p><p>Objekte, die Aufgaben erledigen („Dokument drucken“, Vertrag drucken, “F„ormular drucken“), jedoch keinen eigenen Zustand enthalten, stellen die letzten noch fehlende Bausteine dar: Domain Services sind hier interne Dienste („DruckService“), die innerhalb des Domänenkerns verortet sind – im Gegensatz zu klassischen Services, die bekanntlich fertig implementierte Komponenten darstellen. Ihre Identifikation läuft analog und zeitgleich mit dem Entdecken der Aggregates, lediglich durch den Inhalt der Ereignisse und Commands wird die Unterscheidung deutlich.</p><h2>Ausblick</h2><p>Abschließend kann mit dem Gesamtergebnis aus identifizierten (Sub-)Domänen, Prozessen und Softwarebausteinen ein Plan für die Umsetzung erstellt werden: Es gilt, wichtige und unwichtige Prozessschritte zu finden, und diese voneinander zu isolieren. Einzelne Teilprozesse können dabei als Namensgeber für User Stories dienen, die in einem anschließenden Story Mapping Workshop den Start einer Produktumsetzung entscheidend erleichtern. Vor allzu großem Enthusiasmus über die Fülle der Ergebnisse sei jedoch an dieser Stelle noch einmal gewarnt: Während es in jedem Fall deutlich zu bevorzugen ist, eine Projektplanung auf den Ergebnissen aus dem Event Storming aufzubauen, als über ein im klassischen Requirements Engineering erarbeiteten Backlog (oder gar Pflichtenheft), so ist und bleibt das Modell eine – wenn auch detailreiche – Momentaufnahme. Während der Entwicklung ist es durchaus nicht ungewöhnlich, dass stellenweise nachkorrigiert oder auch mal größere Systemteile verändert werden müssen, wenn neue Erkenntnisse entstehen. Das lässt sich in komplexen Zusammenhängen weder vermeiden, noch wäre eine Vermeidungsstrategie wünschenswert. Vielmehr sollte in  regelmäßigen Abständen das Event Storming wiederholt und damit geprüft werden, ob das gemeinsame Bild immer noch mit dem letzten modellierten Stand kongruent ist, oder ob sich inzwischen Änderungen ergeben haben, die Berücksichtigung verlangen. Aber selbstverständlich kann dies auch durch viele andere Mechanismen erreicht werden. Es bietet sich mithin an, die Methoden zu variieren, da sich sonst möglicherweise Automatismen einschleichen, die die Ergebnisse verwässern.</p><h2>Fazit</h2><p>Durch das gemeinsame Brainstorming und das Reduzieren auf rein fachliche Events kann der Workshop manche Schwierigkeiten klassischer Softwareprojekte lösen: Die Einstiegshürde ist denkbar niedrig (jede*r kann am Workshop teilnehmen und auch ohne methodische Vorkenntnisse sofort produktiv einsteigen), der Wissenstransfer ist unmittelbar und umfassend. Doch es ist keineswegs nur ein Transfer in eine Richtung: Aus dem Zusammenspiel von Domänenexperten, Entscheidern, Entwicklern und Moderator können komplexe Zusammenhänge für alle Beteiligten erarbeitet und verfeinert werden. Nicht selten werden dabei Fehleinschätzungen und Missverständnisse aufgedeckt, die unerkannt über Jahre für Probleme sorgten.</p><p>Der Moderator führt während des Workshops Stück für Stück neue Konzepte ein, um die Diskussionen am Leben zu erhalten und gleichzeitig die Teilnehmer nicht mit Informationen zu überladen. Das sorgt für ein konstant hohes Energielevel und verblüffend detailreiche Ergebnisse.</p><p>Am Ende des Workshops herrscht ein gemeinsames Verständnis über die besprochene Domäne, und es kann nun ein erstes Modell erstellt und verifiziert werden. Dieses sollte im Verlauf des Projektes an neue Erkenntnisse und Learnings iterativ angepasst und immer wieder verfeinert werden.</p><p>Der Blogbeitrag vermag natürlich nur einen kurzen Überblick über Event Storming und dessen Durchführung zu geben. Den besten Einblick erhält der Leser beim Ausprobieren und Selbst-Erleben der Methode. Voraussetzung für das bestmögliche Ergebnis ist allerdings unbedingt eine professionelle Unterstützung bei der Moderation – die Dynamik des Formats und die vielen kleinen Hinweise und Anregungen, die sonst verloren gehen, machen die Investition auf jeden Fall wett.</p><p>Als Grundlage für das Entwerfen komplexer Geschäftsanwendungen hat sich dieses Vorgehen hundertfach entscheidend bewährt und ist nach meiner Einschätzung uneingeschränkt zu empfehlen.</p><p>Mein Dank gilt Tobias Goeschel für das Training, für die tollen Diskussionen über Event Storming und seine Unterstützung beim Schreiben dieses Blog Posts.</p><p><a href="/wissens-hub/webinare"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/q1XcUx2RaepsS1ftTGRY" alt="EventStorming Masterclass mit Alberto Brandolini" width="700" height="394" /></a>  Vom EventStorming-Erfinder persönlich lernen? – <a href="/wissens-hub/webinare">Jetzt Ticket sichern!</a> </p>

Event Storming – Gemeinsam die Domäne entdecken

<p>In diesem Blogpost zeigen wir an verschiedenen Situationen (welche heutzutage leider noch viel zu häufig in der Realität vorkommen), warum Projekte scheitern oder eine agile Transformation fehlschlägt.<br /> Wir merken immer häufiger, dass für eine „korrekte” (worüber sich vortrefflich streiten lässt) Umsetzung von agiler Entwicklung oder DevOps die <a href="/wissens-hub/blog/kulturkampf-digitalisierung-eine-un-success-story">Kultur des Managements und der Mitarbeiter entscheidend</a>  ist. Gerade in großen Unternehmen fällt das Mitnehmen und Motivieren der Mitarbeitenden eher zu knapp aus und so gibt es zwar immer wieder Initiativen zur Transformation des Unternehmens, aber diese verpuffen an der Einstellung der Belegschaft oder des Managements.<br /> <strong></strong></p><blockquote><p>„Wir sind doch agil!”</p></blockquote><p><br /> Agil ist ein <a href="/wissens-hub/blog/unternehmen-im-wandel-der-mensch-im-fokus">überstrapazierter Begriff</a>  geworden. In diesem Beitrag betrachten wir Agilität aus der Perspektive der Unternehmenskultur, welche durch die Mitarbeitenden gelebt werden muss. Diese Kultur muss von Vorgesetzten gelebt werden und die Transformation dahin ist mühevoll, denn es müssen alte Strukturen und Verhaltensweisen aufgebrochen werden.<br /> Meist wird Agilität mit Scrum gleichgesetzt. Es wird angenommen, wenn Scrum praktiziert wird, ist agile Entwicklung automatisch vorprogrammiert. Nach Scrum zu arbeiten klingt dabei nach einer einfachen Aufgabe und dennoch passieren viele Fehler bei der Durchführung von Scrum in Bezug auf einge gute agile Praxis. Außerdem: Scrum muss dabei mitunter gar nicht so wichtig sein. Wichtiger ist es, Agilität in der Projektkultur zu leben.<br /> Eine agile Kultur beinhaltet einen Fokus auf Transparenz über alle getroffenen Entscheidungen und eine Stärkung des Informationsflusses sowohl innerhalb des Teams als auch nach außen. So kann jedes Teammitglied maximal zum Erfolg des Projektes beitragen kann, indem es bei Planung, Design und Verbesserung des Projektes einbezogen wird. Agile Methoden sind Frameworks, um dies kontinuierlich und iterativ zu ermöglichen. Im Folgenden gehen wir auf häufige agile Anti-Patterns in Zusammenhang mit Scrum ein.</p><p><strong>Das „Agile-Wasserfall“-Projekt:</strong> Häufig zu beobachten ist, dass agile Projekte ähnlich wie ein Wasserfall-Projekt am Anfang durchgeplant werden: ein Zeit- und Projektplan wird festgelegt und das Budget muss bestimmt werden. Für die einzelnen Features werden Deadlines bestimmt. Dann werden Requirements in User Stories verpackt und diese in einem großen Batch auf das Projekt losgelassen. Die User Stories sind im schlimmsten Fall von schlechter Qualität, z. B. weil sie viel zu groß geschnitten oder spezifiziert sind.<br /> Features werden entwickelt, aber eine Validierung und ein Feedback durch die eigentlichen Endnutzer:innen findet, wenn überhaupt, viel zu spät statt. Das Projekt fällt immer weiter hinter den eigentlichen Plan zurück und scheitert letztlich an den gleichen Gründen wie frühere Wasserfall-Projekte: Der anvisierte Launch wird mehrmals verschoben und wenn dann endlich das Release da ist, fehlt die Nutzerakzeptanz. Ein Big Bang, wie er im Buche steht und ganz und gar nicht einer agilen Kultur entsprechend.</p><p><strong>„Chef-Programmierer“ gibt die Richtung vor:</strong> Scrum wird als Vorwand genutzt, um Agilität vorzutäuschen. Das Pattern: Bspw. ein PO (z. B. ein früherer Projektleiter, nun umgeschult) gibt jedem einzelnen Teammitglied genau vor, welche Aufgaben es zu welchem Zeitpunkt zu erledigen hat. Scrum Tools und Meetings werden nur zum Micromanagement des Teams genutzt. Ein eigenständiges Arbeiten ist für das Team unmöglich. Prioritäten werden oft während des Sprints gewechselt, z. B. weil Features nicht nach maximalem Nutzen für das Produkt priorisiert werden, sondern nach politischen Aspekten (z. B. weil ein Feature für das nächste Release dem Kunden versprochen wurde). Als Konsequenz kommt es zu immer größeren Beeinflussungen des Teams durch den “Chef-Programmierer” bei eigentlich teaminternen Entscheidungen.<br /> Scrum wurde nicht entwickelt, um Teams besser kontrollieren zu können. Es sollte klar sein, dass nicht jede:r alles wissen kann und daher eine Lösung im Team erarbeitet werden muss. Wenn alle im Team zusammenarbeiten und jeder einen guten Überblick über das Projekt und die zukünftige Entwicklung hat, kann vielleicht eine bessere Lösung gefunden werden.</p><p><strong>Fehlender dedizierter Scrum Master:</strong> Gute Scrum Master sind teuer, aber wichtig. Es ist oft zu hören: „Dabei produzieren die doch nicht einmal Code!“ Als Schluss folgt: Dann kann doch auch einfach ein Teammitglied das Ganze übernehmen.<br /> Es kommt dadurch häufig zu Frustration und Blockaden innerhalb des Teams, da z. B. Retrospektiven nicht oder schlecht durchgeführt werden oder kein dedizierter Mensch sich um die Beseitigung von Blockaden kümmert. Es folgt darauf eine sinkende Entwicklungsgeschwindigkeit und die vorher eingesparten Kosten sind dahin.<br /> Hierfür gibt es nur eine Lösung: Setzt dedizierte Scrum Master ein. Sie sorgen für einen Schutz des Teams vor externer Beeinflussung, organisieren die Meetings und lösen interne Probleme. Das Team muss ungestört arbeiten können!</p><p><strong>Zu große Teams:</strong> Teams sollten nicht zu groß sein, da sonst einige negative Effekte zu bemerken sind. Meetings ziehen sich aufgrund der Teilnehmerzahl in die Länge, Entscheidungsfindung wird aufgrund vieler zu berücksichtigender Parteien träger und es wird komplizierter, psychologische Sicherheit im Team aufrecht zu erhalten.<br /> Der Wissenstransfer zwischen den einzelnen Teammitgliedern wird immer schwieriger. Außerdem verbringt das Team 30-50 % der Zeit des Sprints in Meetings, die Zeit für das Entwickeln wird immer knapper.<br /> Bei großen Projekten wird für so ziemlich jede Entscheidung oder Blocker erstmal ein Meeting einberufen und am besten müssen immer alle mit dabei sein, es könnte ja jeden betreffen. Im schlimmsten Fall wird sich dadurch minutenlang angeschwiegen.<br /> Teams sollten möglichst unabhängig miteinander agieren können und nicht zu groß sein. Es sollten ihre gemeinsamen Abhängigkeiten und Schnittstellen herausgefunden werden und sie sollten dem jeweiligen anderen Team ein „Produkt“ zur Verfügung stellen. Dies führt zu einer Entkopplung der einzelnen Teams und die Teams können wieder selbstbestimmt arbeiten. Größere Meetings zwischen den Teams sollten nur noch mit einzelnen „Abgesandten“ der jeweiligen Teams stattfinden. Hier hat sich auch das Pattern der Communities of Practice bewährt.<br /> <strong></strong></p><blockquote><p>„Wir sind agil, wir machen doch DevOps!“</p></blockquote><p><br /> DevOps ist als Buzzword im Management angekommen. Dennoch werden fundamentale Konzepte von DevOps nicht oder nur teilweise umgesetzt. Wenn DevOps-Praktiken nicht funktionieren, ist dies auch häufig auf eine fehlende Anpassung der Gewohnheiten, Prozesse und Methoden durch Management und Mitarbeiter zurückzuführen.<br /> Unter anderem werden Teams nicht dazu ermutigt, eine DevOps-Kultur zu leben. Stattdessen existieren weiterhin silo-artige, abgekapselte Abteilungen oder Teams mit unterschiedlichen Zuständigkeiten, Budgets und somit auch ganz eigenen politischen Zielen.<br /> So wird z. B. fälschlicherweise DevOps nicht als Praxis, sondern als eine Abteilung innerhalb des Unternehmens etabliert. Ein DevOps-Team als Enabler innerhalb der Organisation wäre dabei keine schlechte Sache, doch stellt diese Abteilung in der Realität nicht Unterstützung für Teams, sondern ist verborgen hinter Beantragungen und langwierigen Prozessen. Das Team kommt nicht von den Zwängen der alten Plan-Build-Run-Kultur los. Um z. B. die dringend benötigte Build Pipeline zu bekommen, ist nicht etwa ein Klick innerhalb eines Tools nötig, sondern es müssen langwierige Anträge ausgefüllt und von mehreren übergeordneten Stellen abgesegnet werden, damit die Pipeline dann vom sogenannten DevOps-Team erstellt wird.<br /> Diese Prozesse sind in Unternehmen über lange Zeit gewachsen, vielleicht aus guten Gründen. Dennoch hindern sie die Entwickler an einer effektiven Arbeit am Projekt. Das Credo muss sein: Alles und jeder im Unternehmen muss darauf hinarbeiten, dass die Entwickler effektiv und störungsfrei arbeiten können. Nur dann können sich Entwickler darauf konzentrieren, Werte für das Unternehmen zu schaffen, also z. B. das Produkt der Firma voran zu bringen. Für unser Beispiel könnte das also bedeuten, dass ein DevOps-Team eine funktionierende Self-Service-Plattform für CI/CD zur Verfügung stellt, mit der Projekte ohne großen Aufwand neue Build und Deployment Pipelines erstellen können. Sie fungieren selbst als Enabler-Team und schulen sowie supporten andere Teams, um ihre Plattform schnell in ihre Arbeit integrieren zu können.<br /> Ein agile Kultur und eine funktionierende DevOps Praxis bilden eine starke Symbiose. So unterstützt DevOps das Entwickeln nach agilen Methoden enorm. Nur wenn Teams eigenständig und selbstbestimmt mit Ressourcen umgehen können, können sie auch schnell Features in Produktion bringen.<br /> <strong></strong></p><blockquote><p>„Digitalisierungsprojekt XY hat höchste Prio!“</p></blockquote><p><br /> Fokus ist wichtig. Sehr oft erleben wir, dass Teams durch andere Aufgaben von ihrem eigentlichen Projekt abgehalten werden. Wie soll das wichtige Digitalisierungs-Projekt erfolgreich abgeschlossen werden, wenn Teammitglieder noch 50 % ihrer Zeit mit Firefighting für Altsysteme zubringen oder in sinnlose Meetings gezogen werden?<br /> Ein gutes Management hält diesen Teammitgliedern den Rücken frei und propagiert die Projektziele, um alle Mitarbeitenden auf ein gemeinsames Ziel einzuschwören. Jedem Teammitglied sind die Ziele klar und Entscheidungen des Managements sind transparent. Nur dann werden die Teammitglieder effektiv und mit großer intrinsischer Motivation arbeiten.<br /> <strong></strong></p><blockquote><p>„Ihr habt vor zwei Monaten gesagt, das braucht x Tage, nun macht mal!“</p></blockquote><p><br /> Zusätzlich geraten Teams in eine weitere Falle: Sie werden auf Zeiten und Budgets festgenagelt, die vor Monaten arbiträr festgelegt wurden, aber mit dem nun aktuellen Wissensstand absolut unhaltbar sind. Am Anfang des Projektes wurden viele technologische und architektonische Entscheidungen getroffen, die auf nun veralteten Annahmen basieren, wenn das Projekt ein oder zwei Monate läuft. Das Team versucht nun, diese Deadlines unbedingt zu halten, obwohl klar ist, dass diese nicht mehr zu halten sind: Die Motivation sinkt und der Glaube an den Erfolg geht verloren. Es sammeln sich Unmengen an Überstunden an und die technischen Schulden werden immer größer. Die Abwärtsspirale beginnt.<br /> Wichtiger wäre es, Teams nicht an Deadlines und Budgets zu messen, die in den meisten Fällen nicht eingehalten werden können, sondern auf Basis von gelieferten Features. Einschneidende Entscheidungen sollten so spät wie möglich getroffen werden, um den Lösungsraum offen zu halten und dadurch so schnell wie möglich zu Ergebnissen zu kommen, die dann evaluiert und getestet werden können. Kleine, portionierte Entscheidungen sollten dagegen schnell getroffen werden, um schnell mittels Feedback validiert zu werden.<br /> <strong></strong></p><blockquote><p>„Das ist doch alles Jugend forscht hier.“</p></blockquote><p><br /> Diese Aussage ist extrem und haben wir so schon öfter gehört. Sie ruft starke Verwunderung bei uns hervor. Für uns ist ein exploratives Vorgehen selbstverständlich und ein kontinuierliches Entwickeln von Hypothesen und deren Validierung durch Tests unabdingbar.<br /> In der Realität sieht es oft so aus: Die genauen Anforderungen an das Produkt erscheinen klar. Also wird (nur ohne Lasten/Pflichtenheft) losgelegt und User Stories werden erstellt und ein Zeitplan ausgearbeitet. Beispielsweise werden dann Features aus den zu ersetzenden Altsystemen übernommen, die augenscheinlich unbedingt benötigt werden. Außerdem ist man sich einig, dass das Altsystem zwar gut war, aber nun mal durch etwas Besseres ersetzt werden muss. Man möchte von vornherein alles „richtig“ machen. Doch der Weg dahin ist oft unklar und wir stellen fest, dass die Kunden selbst nicht so genau wissen, welche Features wirklich den größten Business Value produzieren. Anstatt also bei Null anzufangen, wird meist ein kanonisches Datenmodell entwickelt (oder übernommen), die Architektur wird festgelegt und statt herauszufinden, womit in der Neuentwicklung der größte Wert geschaffen werden kann, wird ein großer Feature-Katalog abgearbeitet.<br /> Das Gegenteil ist aber meistens der Fall und die Anforderungen sind alles andere als klar. Die Ziele werden dann meistens nicht erreicht, es entsteht ein immer größerer Verzug zu den Deadlines und die Endnutzer:innen werden nicht um Feedback gefragt. Die Motivation der Entwickler:innen bricht weg und niemand glaubt noch an den Erfolg des Projektes. Man befindet sich wieder in einer Abwärtsspirale und das Projekt wird früher oder später scheitern.<br /> Ein exploratives Vorgehen kann dies verhindern, kommt aber nicht ohne vermeintliche Schmerzen. Denn es sieht am Anfang danach aus, als ob keine Erfolge zu verbuchen wären. Annahmen werden getroffen, es werden Features entwickelt und später wird viel wieder verworfen. Je früher jedoch Annahmen validiert oder invalidiert werden können, desto besser.<br /> Es ist wichtig, von vornherein offen für Veränderung zu sein! Dies ist Teil einer agilen Kultur. Veränderung muss sich in der Architektur und der Implementierung der Software widerspiegeln. Es wird passieren, dass das Datenmodell sich nach jeder Iteration erneut ändert und der Code jedes mal stark refactored werden muss. Dennoch kann man durch solch ein Vorgehen die eigentlich wichtigen Features implementieren und erhält früh das nötige Feedback der Nutzer:innen. Es ist wichtig, den Erfolg des Teams nicht anhand von geschafften Deadlines zu messen, sondern anhand der getesteten und validierten Entscheidungen.<br /> <strong></strong></p><blockquote><p>„Ja, wir wollen so schnell wie möglich produktiv gehen.“</p></blockquote><p><br /> Diese Aussage hören wir leider viel zu oft in Projekten, die meistens schon verzögert sind, z. B. aufgrund der oben bereits genannten Situationen. Das bedeutet manchmal, dass ein Projekt schon Monate oder Jahre hinter dem eigentlichen Zeitplan zurückliegt. Dennoch wurde während der Entwicklung noch nicht einmal erfolgreich auf Produktion ausgerollt.<br /> Es muss eines deutlich gesagt werden: Wenn das Feature/Produkt nicht produktiv gegangen ist, wurde noch kein Wert geschaffen. Dennoch erleben wir es immer wieder, dass Teams weiter mit Feature Requests bombardiert werden: Der Fokus liegt nicht darauf, bestehende Features auf Produktion zu bringen und an Endnutzer:innen zu testen und Feedback einzuholen. Also wird weiter und weiter entwickelt, Geld verbrannt, und am Ende werden die Kunden vor vollendete Tatsachen gestellt. Wenn es überhaupt jemals zu einem Kontakt der Endnutzer:innen mit dem fertigen Produkt kommt.<br /> Wenn es dann soweit ist, und es kann auf Produktion deployed werden, fehlt im Team das Wissen, welche firmenspezifische Compliance-Regeln und Prozesse eingehalten werden müssen, um überhaupt das neue „Cloud-native Digitalisierungsprojekt“ auf Produktion zu deployen. Beispielsweise werden Cloud-Teams als Enabler im Unternehmen eingesetzt (ähnlich wie zuvor beschrieben bei DevOps), um die jeweiligen großen Cloud-Anbieter innerhalb des Unternehmens einzuführen, aber später sind diese Teams entweder nicht dafür ausgelegt, andere Teams bei ihrem Weg zur Produktion zu unterstützen oder sind mit ihren Aufgaben völlig ausgelastet.<br /> Wie schon bei dem schlecht durchgeführten DevOps mangelt es bei der fehlenden Produktionsreife wieder am Service-Gedanken gegenüber den Projekten. Weiterhin sollte es selbstverständlich für DevOps-praktizierende Teams sein, auch mehrmals täglich auf Produktion zu deployen. Nur so ist es möglich, einen kontinuierlichen Flow und Feedback zu erhalten.</p><h2>TL;DR</h2><p>Dieser Blogpost beleuchtete verschiedene Situationen und Szenarien, die in agilen Projekten vorkommen können und diese dann zum Scheitern verurteilen.<br /> Fassen wir kurz zusammen:</p><ul><li>„Agilität“ ist oft eine leere Worthülse und zieht sich nicht durch die ganze Unternehmenskultur. Scrum wird eingeführt und mit agil gleichgesetzt. Ein kultureller Wandel findet nicht statt.</li><li>DevOps-Praktiken sind wichtig, um agile Projekte zu ermöglichen, werden nicht richtig umgesetzt und versinken z. B. in einem Dschungel aus Anträgen und Berechtigungen.</li><li>Teams können nicht selbstständig, unabhängig und fokussiert arbeiten.</li><li>Kontinuierliches Lernen, Feedback und Verbessern findet nicht oder nur wenig statt.</li><li>Es wird nur selten oder gar nicht auf Produktion deployed, Erfahrungen können nicht gesammelt werden und es kann nicht daraus gelernt werden. Es wurde dadurch auch kein Wert geschaffen.</li></ul>

Scheitern auf Ansage – Szenen aus der agilen Transformation

<p>In diesem Artikel beschreiben wir die Entwicklung, zusammen mit den Herausforderungen, des Logstash-Java-Input-Plug-ins für Apache PLC4X, das im Rahmen des Open-Source-Projekts <em>Apache PLC4X</em> in Absprache mit Elastic entwickelt wurde.</p><h2>Architektonische Übersicht über das Logstash-Java-Input-Plug-in</h2><p>Zunächst werfen wir einen Blick auf die grundlegende Architektur und Systemlandschaft und werden im Anschluss die Umsetzung des Plug-ins betrachten. In der nachfolgenden Abbildung ist eine Übersicht über das Einsatzgebiet des Plug-ins zu sehen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/QGkcjYiTRFGOO3orSoBA"><img width="700" height="174" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/QGkcjYiTRFGOO3orSoBA" alt="Overall architecture Logstash Java Input Plug-in PLC4X" /></a> </p><p>Wir verwenden im Plug-in das Framework Apache PLC4X, um Daten von IIoT-Geräten (Industrial Internet of Things) mittels Pull-Prinzip abzufragen. Diese Daten werden an Logstash übergeben, welches diese anschließend über ein Output-Plug-in der Pipeline mittels Push-Prinzip weiterleitet. Hier haben wir beispielsweise <em>ElasticSearch</em> gewählt.<br /> Neben der Abfrage von mehreren IIoT-Geräten in einer Pipeline ist es ebenfalls möglich, mehrere Pipelines zu definieren, um die Abfragen auf mehrere Pipelines zu verteilen. Dies ist z. B. bei verschiedenen Gerätetypen oder Standorten sinnvoll.</p><h2>Die Entwicklung des Plug-ins und der zugehörige Build-Prozess (als Teil von Apache PLC4X)</h2><p>Für die Entwicklung eines Logstash-Java-Input-Plug-ins gibt es von Elastic eine Anleitung, die <a href="https://www.elastic.co/guide/en/logstash/current/java-input-plugin.html" target="_blank">hier</a>  gefunden werden kann.<br /> Dort wird erklärt, dass als erstes der Quelltext von <em>logstash</em> heruntergeladen und gebaut werden muss. Anschließend wird im Projekt des Java-Logstash-Input-Plug-ins der Pfad zu <em>logstash</em> in der Datei <em>gradle.properties</em> eingetragen. Dieser Schritt ist notwendig, solange die entsprechende JAR-Datei von <em>logstash</em> noch nicht auf dem <em>Maven Central Repository</em> verfügbar ist. Aktuell ist noch unklar, wann dies der Fall ist – es existiert aber bereits ein <a href="https://github.com/elastic/logstash/issues/11002" target="_blank">Issue</a>  im entsprechenden GitHub-Projekt von Elastic.</p><p>Wird das Logstash-Java-Input-Plug-in anschließend gebaut, verwendet das Skript <em>gradle.build</em> die Datei <em>rubyUtils.gradle</em> von <em>logstash</em>. In diesen Utils wird JRuby heruntergeladen und anschließend verwendet. Für das Herunterladen und Entpacken von JRuby wird der Befehl <b><em>commandLine ‚./mvnw‘, ‚clean‘, ‚install‘, ‚-Pdist‘, ‚-Pcomplete‘</em></b> verwendet. Gradle führt Maven an dieser Stelle über einen Maven-Wrapper aus. Dies ist im Rahmen des Apache-PLC4X-Projekts ungünstig. Denn PLC4X verwendet Maven selbst als Build-Tool. Daher ergäbe sich bei einfacher Einbindung von Gradle aus der Elastic-Anleitung folgender Build-Prozess:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/8xsMyWkSdyjWwCkvqIde"><img loading="lazy" width="700" height="462" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/8xsMyWkSdyjWwCkvqIde" alt="Build process with maven and gradle (plc4x project)" /></a> </p><p>Hier ist eine unnötige Verkettung von Build-Tools zu sehen, da Maven Gradle ausführt und dieses im Anschluss wiederum Maven aufruft. Daher haben wir beschlossen, den Gradle-Teil des Build-Prozesses ebenfalls in Maven umzusetzen, sodass sich folgender Ablauf ergibt:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ukUKvCE5RkaoqQcprPJO"><img loading="lazy" width="700" height="334" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ukUKvCE5RkaoqQcprPJO" alt="build process with maven (plc4x project)" /></a> </p><p>Abschließend stellen wir noch die Umsetzung des Build-Prozesses mit Maven und den zugehörigen Plug-ins vor.</p><table><tbody><tr><td></td><td><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wkgbOmfRGmmUWu1M38OA"><img loading="lazy" width="250" height="635" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wkgbOmfRGmmUWu1M38OA" alt="build process" /></a> </td></tr><tr><td><strong>groovy-maven-plugin:</strong> In diesem Schritt wird die Version ohne <em>SNAPSHOT</em> berechnet und als künstliche Eigenschaft in Maven (<em>current-full-version</em>) gesetzt. JRuby benötigt die Version in diesem Format, da es ansonsten mit einer Fehlermeldung abbricht.</td></tr><tr><td><strong>download-maven-plugin:</strong> Dieses Plug-in lädt und entpackt JRuby, das zum Erstellen des Artefakts benötigt wird.</td></tr><tr><td><strong>maven-resources-plugin:</strong> Dieses Plug-in bearbeitet alle Ressourcen (z. B. ersetze <em>${current-full-version}</em> durch die Version).</td></tr><tr><td><strong>maven-shade-plugin:</strong> Erstellt eine Fat JAR aus den Klassen und Dateien des Plug-ins sowie allen Abhängigkeiten.</td></tr><tr><td><strong>exec-maven-plugin:</strong> Mit diesem Plug-in werden JRuby und Gem aufgerufen, die anschließend das Artefakt <em>logstash-input-plc4x-X.X.X.gem</em> erstellen.</td></tr><tr><td><strong>build-helper-maven-plugin:</strong> Mit diesem Plug-in wird das Artefakt in Maven hinzugefügt, sodass es ebenfalls in der <em>install</em>-Phase von Maven berücksichtigt wird.</td></tr></tbody></table><h2>Beispielkonfiguration des Plug-ins</h2><p>Voraussetzung für die Verwendung des Plug-ins ist die Installation in Logstash. Anschließend kann das Plug-in wie folgt initialisiert und konfiguriert werden.<br /></p><div>

```autoconf
## logstash pipeline config - input
input {
	## use plc4x plugin (logstash-input-plc4x)
	plc4x {
		## define sources
		sources => {
			source1 => "opcua:tcp://opcua-server:4840/"
			source2 => "opcua:tcp://opcua-server1:4840/"
			source3 => "..."
		}
		## define jobs
		jobs => {
			job1 => {
				# pull rate in milliseconds 
				rate => 2
				# sources queried by job1
				sources => ["source1", ...]
				# defined queries [logstash_internal_fieldname => "IIoT query"]
				queries =>  {
					PreStage => "ns=2;i=3"
					MidStage => "ns=2;i=4"
					PostStage => "ns=2;i=5"
					Motor => "ns=2;i=6"
					ConvoyerBeltTimestamp => "ns=2;i=7"
					RobotArmTimestamp => "ns=2;i=8"
				}
			}
			job2 => { .... }
		}
	}
}
 
## logstash pipeline config - filter
filter {
	...
}
 
## logstash pipeline config - output
output {
	...
}
```

</div><p>Im Abschnitt <em>input</em> wird das Plug-in durch <em>plc4x</em> initialisiert. Innerhalb des <em>plc4x</em>-Abschnitts können <em>sources</em> und <em>jobs</em> definiert werden. <em>Sources</em> sind die Connection-Strings für die jeweiligen PLCs (hier beispielsweise OPC UA Server).<br /> Im <em>jobs</em>-Abschnitt können einzelne <em>jobs</em> definiert werden. Diese enthalten <em>queries</em> (Abfragen) für bestimmte <em>sources</em>. Die Abfragen sind in der Form <em>X => „Y“</em> angegeben. X ist der interne Feldname für Logstash. Y ist die Abfrage, die zum PLC gesendet wird.<br /> Für jeden Job wird eine Rate angegeben, die die Zeitspanne zwischen den einzelnen Abfragen definiert. Im Beispiel werden die fünf definierten Felder alle <em>300</em> Millisekunden von <em>source1</em> abgefragt.</p><h2>Quelltext des Java-Logstash-Plug-ins für PLC4X</h2><p>Das Plug-in besteht aus einer Klasse, die wir für diesen Blogbeitrag in drei Abschnitte aufgeteilt haben.</p><p>Im ersten Teil des Plug-ins werden die <em>sources</em> eingelesen und anschließend dem Builder des Scrapers von PLC4X hinzugefügt. Der Scraper ist ein Teil von PLC4X, um Daten regelmäßig von beliebigen PLCs abzufragen.</p><div>

```java
// parse sources
for (String sourceName : sources.keySet()) {
	Object o = sources.get(sourceName);
	if(o instanceof String) {
		String source = (String)o;
		builder.addSource(sourceName, source);
	} else {
		logger.severe("URL of source " + sourceName + "has the wrong typ!");
	}
}
```

</div><p>Der zweite Abschnitt des Quellcodes ist für das Einlesen und Erstellen der <em>jobs</em> zuständig.<br /> In der äußeren <em>for-</em>Schleife wird über alle definierten <em>jobs</em> iteriert. Für jeden einzelnen Job werden anschließend die Rate, die <em>sources</em> als auch die Abfragen eingelesen und dem <em>jobBuilder</em> (ebenfalls Teil des Scrapers) von PLC4X zugewiesen.</p><div>

```java
// parse jobs
for (String jobName : jobs.keySet()) {
	Object o = jobs.get(jobName);
	if (o instanceof  Map) {
		Map job = (Map<String, Object>) o;
		JobConfigurationTriggeredImplBuilder jobBuilder = builder.job(
			jobName, String.format("(SCHEDULED,%s)", job.get("rate")));
		for (String source : ((List<String>) job.get("sources"))) {
			jobBuilder.source(source);
		}
		Map<String, Object> queries = (Map<String, Object>) job.get("queries");
		for (String queryName : queries.keySet()) {
 
			String fieldAlias = queryName;
			String fieldAddress = (String) queries.get(queryName);
			jobBuilder.field(fieldAlias, fieldAddress);
		}
		jobBuilder.build();
	} else {
		logger.severe("Jobs of wrong Type!");
	}
}
```

</div><p>Nachdem nun alle <em>sources</em> und <em>jobs</em> eingelesen sind, können wir den Scraper ausführen. Bei der Initialisierung des Scrapers übergeben wir eine Lambda-Funktion, die nach erfolgreicher Abfrage der Felder aufgerufen wird. In dieser Funktion werden die erhaltenen Werte geloggt und die Ergebnisse anschließend vom <em>consumer</em> akzeptiert (der <em>consumer</em> ist Teil des Logstash-API und nimmt die Daten entgegen).</p><div>

```java
// start scraper
ScraperConfigurationTriggeredImpl scraperConfig = builder.build();
try {
	plcDriverManager = new PooledPlcDriverManager();
	triggerCollector = new TriggerCollectorImpl(plcDriverManager);
	scraper = new TriggeredScraperImpl(scraperConfig, (jobName, sourceName, results) -> {
		HashMap<String, Object> resultMap = new HashMap<String, Object>();
		resultMap.put("jobName", jobName);
		resultMap.put("sourceName", sourceName);
		resultMap.put("values", results);
 
		//TODO: add guard for debug mode, so only in debug mode its run
		for (Map.Entry<String, Object> result : results.entrySet()) {
			// Get field-name and -value from the results.
			String fieldName = result.getKey();
			Object fieldValue = result.getValue();
			logger.finest("fieldName: " + fieldName);
			logger.finest("fieldValue: " + fieldValue);
		}
		consumer.accept(resultMap);
	}, triggerCollector);
	scraper.start();
	triggerCollector.start();
} catch (ScraperException e) {
	logger.severe("Error starting the scraper: "+ e);
}
```

</div><h2>Fazit und Lessons Learned</h2><ul><li><b>Benennung von Dateien und Klassen</b><br /> Die Logstash-Java-Input-Plug-ins sind bei der Benennung der Dateien und Konfigurationen sehr sensitiv. Die Namen der Gemspec-, JAR- sowie Gem-Dateien müssen alle derselben Benennung folgen (z. B. <em>logstash-input-plc4x</em>). Ebenfalls müssen der Klassenname und einige Konfigurationen (beispielsweise Inhalte der Ruby-Konfiguration, also der <em>.rb</em>-Dateien) bezüglich der Benennung übereinstimmen. Zu Beginn der Entwicklung hatten wir uns überlegt, die <em>aritfact-id</em> des Projekts zu verwenden. Dabei hatten wir das Problem, dass wir diese nicht überall durch das <em>maven-resource-plugin</em> ersetzen lassen konnten. Dadurch stimmten die Benennungen teilweise nicht überein und es kam zu Problemen bei Installation und Ausführung des Plug-ins. Nachdem wir uns für eine statische Benennung des Plug-ins entschieden und alle relevanten Stellen identifiziert hatten, ließ sich das Plug-in in Logstash installieren und ausführen. Diese Lösung hat auch den Vorteil, dass die artifact-id <em>plc4j-logstash-plugin</em> mit dem Namensschema von PLC4X und der Plug-in Name <em>logstash-input-plc4x</em> mit dem Namensschema für Plug-ins in Logstash übereinstimmt.</li><li><b>Installationsdauer des Plug-ins</b><br /> Die Installation des Plug-ins in Logstash benötigt meist ~2 Minuten. Dies ist im Fehlerfall (wie z. B. bei der Problematik mit der Benennung) sehr unglücklich, da so zwischen Änderung und Test dieser einige Minuten vergehen.</li><li><b>Build-Tools: Maven, Gradle, JRuby, …</b><br /> Ein weiteres Learning dieses Projekts besteht darin, dass wir in zukünftigen Projekten die Verwendung mehrerer Build-Tools, genau wie hier, hinterfragen werden. Ansonsten entstehen gegebenenfalls ungünstige Verkettungen von Build-Tools wie oben beschrieben (Maven und Gradle). An dieser Stelle möchten wir uns auch bei <em>Christofer Dutz</em> bedanken, der uns bei dieser Problematik unterstützt hat.</li></ul><p>Der Quellcode des gesamten Plug-ins ist hier im PLC4X-Projekt zu finden.</p>

Logstash-Java-Input-Plug-in für Apache PLC4X

![titleimage.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmnej2fdtb3v907ulk00mrbwh)

Durch die Nutzung von großen Sprachmodellen (LLMs) ist es immer einfacher möglich, explorativ Daten zu analysieren. Dabei werden LLM-Agenten genutzt, um Informationen über die vorhandene Datenbasis zu erhalten. In den letzten Jahren hat sich RAG (Retrieval-Augmented Generation) etabliert, um Texte einem LLM zugänglich zu machen. Unter dem Trend "Ask-Your-Data" werden LLM-basierte Agentensysteme genutzt, um Datenanalyse weiter zu vereinfachen. Durch die direkte Anbindung von LLMs an Unternehmensdaten können diese natürlichsprachige Anfragen in Datenbank-Abfragen umwandeln, so die Daten abrufen und automatisch auswerten. Databricks kombiniert dabei RAG, ihr Ökosystem und verschiedene Agents, um bessere Ergebnisse zu liefern.  

In diesem Blogpost möchte ich zeigen, wie dies im Databricks Ökosystem gelöst wird. Ich gebe einen kurzen Überblick über die bestehende Komponenten für agentenbasierte Datenanalyse auf Databricks.

> Als praktischen Beispieldatensatz habe ich für diesen Post die frei zugänglichen [Plenarsaalsitzungsprotokolle des Deutschen Bundestags](https://dip.bundestag.de/) verwendet. Sie sind in unterschiedlichen Formaten zugänglich: als PDF Download, als XML File oder direkt per API. Im Folgenden dienen diese Dokumente als Evaluationsbasis für die verschiedenen Agentic AI Mechanismen auf der Databricks Plattform.

## Warum auf Databricks?

Databricks ist eine [Datenplattform](https://www.codecentric.de/wissens-hub/blog/erstes-data-engineering-projekt-mit-databricks-asset-bundles-und-gitlab-ci-cd), welche das komplette Tooling für Data Engineering auf Basis einer Data Lakehouse Architektur bereitstellt.  
Anstatt also die mühsam kuratierten Daten an externe LLM-Anbieter zu senden, verfolgt Databricks den Ansatz: Die KI wird direkt zu den Daten ins Lakehouse gebracht. Die Basis ist dabei der Unity Catalog. Er liefert als Governance- und Semantik-Layer genau den Kontext, den das LLM benötigt. Dabei vollzieht Databricks den Wechsel von singulären Modellen hin zu “[Compound AI Systems](https://www.databricks.com/blog/what-are-compound-ai-systems)”: Anstatt sich auf einen einzelnen Prompt zu verlassen, werden Aufgaben durch mehrere interagierende Komponenten gelöst. Dafür bietet Databricks zahlreiche neue Funktionen unter dem Oberbegriff “Agent Bricks”. Einige der Funktionen sind aktuell nur auf US gehosteten Workspaces verfügbar, vieles kann aber auch schon in EU gehosteten Workspaces genutzt werden.

## Die Bausteine: Agent Bricks

Der Weg zum eigenen KI-Agenten ist traditionell mit monatelangem Prompt-Engineering, Coding und Finetuning gepflastert. Ein anderer [Ansatz](https://www.codecentric.de/en/knowledge-hub/blog/how-to-generate-insights-with-motherduck-mcp-server-and-opencode) ist z.B. mit einem Coding Agent wie Open Code per Model Context Protocol (MCP) direkt auf die Datenbank zuzugreifen. Mit "Agent Bricks" bietet Databricks nun ein Framework, das den Ansatz verfolgt, komplett im Ökosystem von Databricks zu bleiben. Du wählst für deinen Usecase das passende Template für einen Agenten aus, zeigst auf deine Daten im Unity Catalog, und das Framework übernimmt im Hintergrund die Generierung von Benchmarks, das Finetuning und die Optimierung hinsichtlich Kosten und Qualität. 

### AI-generierte Dokumentation im Unity Catalog

Gute Metadaten sind für LLMs unerlässlich, aber das manuelle Pflegen von Tabellenbeschreibungen ist lästig. Databricks hilft dir dabei über die "AI generate"-Funktion im Catalog Explorer. Das System analysiert selbstständig Spaltennamen sowie Datentypen und schlägt automatisch präzise semantische Beschreibungen für Kataloge, Schemata, Tabellen und einzelne Spalten vor. Wir müssen diese Vorschläge nur noch prüfen und per Klick akzeptieren, wodurch der semantische Kontext für alle nachgelagerten KI-Modelle sofort nutzbar wird.

### Document Parsing

Ein massiver Teil von Daten schlummert in PDFs, Word Dokumenten, Präsentationen und Bildern. Bisher warst du dafür auf externe OCR-Dienste angewiesen. Databricks löst dies durch die native SQL-Funktion *ai\_parse\_document*. Diese ruft Foundation Models auf, um strukturierte Inhalte direkt aus unstrukturierten Blob-Daten zu extrahieren – und das strikt innerhalb der Databricks Plattform. Die Rückgabe ist ein strukturierter VariantType (JSON-ähnlich), der selbstständig Layout-Marker, Tabellen und Texte erkennt. Dieser Ansatz ist ein grundlegender Baustein für RAG innerhalb von Databricks.

### Unity Catalog Functions

Eine Möglichkeit, vor der Nutzung der Daten durch die Agenten die Korrektheit der Abfragen für gewisse SQL Abfragen zu erhöhen, ist diese vorab als Unity Catalog Function (UCF) zu definieren. Wenn die zugrunde liegende SQL-Abfrage vorab bekannt ist und der Agent nur Parameter übergeben soll, ist dies der empfohlene Weg für eine bessere Qualität der Antworten der Agenten. 

> Bundestags-Use-Case: Wir hinterlegen eine Unity Catalog Function in SQL “calculate\_distinct\_parties” welche die Anzahl der Parteien aus der Tabelle liest. Wann immer ein Agent (z.B. AI/BI Genie) nun eine Anfrage bekommt, die Anzahl von Parteien in der Tabelle zu finden, greift er auf diese gespeicherte Funktion zurück, anstatt ein neues SQL Statement zu entwickeln. Gerade bei komplexeren, im Voraus bekannten Abfragen kann so die Zuverlässigkeit des Agenten gesteigert werden, da vermieden wird, dass der Agent evtl. falsche Statements produziert.

### Model Context Protocol

Als alternative Lösungsmöglichkeit hat Databricks zudem das Model Context Protocol (MCP) nativ integriert. MCP ist ein offener Standard und erlaubt es, den Agenten von externen Tools zu entkoppeln. Anstatt für ein Drittsystem Konnektoren selber zu implementieren, greifen Agenten über standardisierte MCP-Server (Managed, Custom oder via Marketplace angebunden) flexibel auf externe Tools zu. MCP ist also besonders nützlich, wenn du dein System dynamisch um neue externe Fähigkeiten erweitern möchtest.

### Information Extraction Agent (Beta)

Aktuell nur in US-Workspaces verfügbar. Dieser Agent transformiert große Mengen unstrukturierter, ungelabelter Texte in strukturierte Tabellen. Die Daten können dabei aus verschiedenen Quellen (PDFs, Bildern, Präsentationen) kommen. Er nutzt unter der Haube das o.g. Document Parsing und führt den Workflow weiter, indem er auch die Analyse der Daten erlaubt (sentiment, summarization, classification) und einen Agenten zur Verfügung stellt.

> Bundestags-Use-Case: Die Datenbank enthält alte Drucksachen (z.B. aus den 50er Jahren) oft nur als eingescannte PDFs. Mit der zugrundeliegenden ai\_parse\_document-Funktion ist es möglich, diese historischen Scans direkt zu parsen. Das System erkennt selbstständig Layout-Marker und macht sie als Text für deinen Vektor-Index zugänglich.

### Knowledge Assistant Agent

Auch aktuell nur in US-Workspaces verfügbar. Erstellt einen Chatbot auf Basis der hinterlegten, unstrukturierten Daten im Unity Catalog oder in einem Vektor-Index. Idealer Agent für RAG Systeme und dokumentbasierten Q\&A dank präziser Quellenangaben.

> Bundestags-Use-Case: Wir bekommen einen Chatbot für inhaltliche Recherchen auf dem unstrukturierten Text. Du fragst: „Was waren die Kernargumente der Opposition zum Thema Open Source in der Verwaltung?“. Der Agent durchsucht den Vektor-Index der Reden und belegt seine Antwort mit exakten Quellenangaben direkt aus der Tabelle mit den Plenarprotokollen. 

### Supervisor Agent

Erstellt ein Multi-Agent System aus vorher erstellen “Agent Bricks” Agenten, Unity Catalogue Functions und externen MCP Servern. Wenn ein einzelner Agent nicht reicht, bündelt der Supervisor andere Agenten und Tools zu einem einzigen Endpunkt. So können Agenten für RAG bzw. unstrukturierte Daten mit Agenten für strukturierte Daten kombiniert werden.

> Bundestags-Use-Case: Du baust einen allumfassenden „Bundestags-Analysten“. Fragt der Nutzer nach inhaltlichen Argumenten, delegiert der Supervisor an den Knowledge Assistant. Geht es um harte Fakten aus Metadaten („Wie viele namentliche Abstimmungen gab es?“), leitet er die Frage nahtlos an einen AI/BI Genie Space. Eingebaute Access Controls sichern dabei ab, dass Nutzer nur Antworten aus Daten erhalten, für die sie im Unity Catalog ohnehin berechtigt sind.

### Custom LLM Agent (Beta)

Erlaubt es ein bestehendes LLM mit Daten anzureichern, um spezifische textbasierte Aufgaben auch innerhalb einer Pipeline oder während SQL-Abfragen auszuführen. Ist dabei spezialisiert auf maßgeschneiderte Textgenerierungsaufgaben (wie Zusammenfassungen, Klassifizierungen) und aktuell nur in US-Workspaces freigeschaltet.

> Bundestags-Use-Case: Bevor die Reden in den Vektor-Index wandern, reichern wir sie an. Wir nutzen native Databricks AI-Funktionen wie ai\_analyze\_sentiment oder ai\_classify, um die emotionale Stimmung jeder Rede (z.B. positiv, negativ) zu bewerten oder sie vollautomatisch thematischen Clustern (Wirtschaft, Soziales) zuzuordnen.

### Code Your Own Agent

Integriert einen Agent in Databricks Apps, erlaubt es, über Quellcode und mit OSS Librarys mit der Databricks Plattform zu arbeiten. Richtet sich hauptsächlich an Entwickler, die volle Kontrolle benötigen und mit Open-Source-Bibliotheken (wie LangChain) direkt auf der Agenten-Infrastruktur arbeiten wollen.  

> Bundestags-Use-Case: Die vorgefertigten Agent Bricks (wie der Knowledge Assistant) stoßen an ihre Grenzen, sobald wir nicht nur einfache Fragen beantworten wollen, sondern komplexe, mehrstufige Analyse-Pipelines mit Schleifen (Loops) und einem "Gedächtnis" (State) benötigen. Beispielsweise könnte sich so ein Knowledge Graph auf Basis des Vektor Indexes und daraus extrahierten Entitäten erstellen lassen.

### AI/BI Genie

Der Agent für “Ask-Your-Data” auf Basis von Tabellen. Ähnlich wie der Knowledge Assistant Agent, aber für strukturierte Daten. Erstellt aus natürlicher Sprache SQL-Abfragen und generiert dynamische Visualisierungen.   
Genie nutzt im Hintergrund einen sogenannten "Knowledge Store". Der Hintergedanke dabei ist, dass ein LLM Kontext braucht, um den Nutzenden besser zu verstehen. Dazu reicherst du diesen Knowledge Store vorab mit Prompts, kuratierten SQL-Expressions und Metadaten an.

> Bundestags-Use-Case: Hier kommen nun die strukturierten Metadaten der API (welcher Abgeordnete gehört zu welcher Fraktion, Dauer der Rede, Datum) ins Spiel, die in einer Tabelle liegen. Analysten oder Journalisten können Genie einfach fragen: „Zeige mir ein Balkendiagramm: Welche Fraktion hat 2025 die meisten Reden zum Thema Umwelt gehalten?“. Genie baut das komplexe SQL im Hintergrund, aggregiert die Daten und liefert das fertige Dashboard zurück.

##  Vertrauen und Kosten

KI-Agenten neigen zum Halluzinieren. Um Enterprise-KI nachvollziehbar zu machen, speichert Databricks die Ausführungspfade (Traces) deiner Agenten im OpenTelemetry-Format direkt in Unity Catalog Tabellen.   
Die Kosten (abgerechnet in Databricks Units / DBUs) sind durch die Nutzung der Databricks Plattform transparent:

- Inference (Agent Bricks): Diese laufen auf Serverless Endpunkten. Die Kosten skalieren stark mit der für das Modell gewählten Hardware (CPU vs. GPU Serving).  
- AI/BI Genie: Hierfür gibt es keine separaten "Per-Seat"-Lizenzen. Du zahlst lediglich für die Serverless SQL Compute DBUs, die bei der Ausführung der generierten Queries anfallen.

## Mein Fazit

Databricks löst die infrastrukturellen Kernprobleme von Ask-Your-Data, indem es Semantik, Orchestrierung und Qualitätskontrolle auf einer einheitlichen Plattform vereint. Die Technologie ist bereit für die Produktion und macht Datenanalyse intuitiv und teilweise sogar spaßig. Am Ende bleibt jedoch das Gefühl, alles nochmal überprüfen zu wollen und nicht nur blind auf die generierten SQLs zu vertrauen.

 Information Retrieval mit Databricks Agents

<p><span>Industrial IoT (IIoT) as a buzzword gained traction within recent years. However, implementing common use cases like real-time monitoring of PLCs may involve a huge amount of money and effort. For example, current approaches implementing such a monitoring solution require complex architectures. Examples and </span><a href="https://www.elastic.co/use-cases/mm-karton" target="_blank"><span>show-cases</span></a> <span> for real-time monitoring often use OPC-UA as an interface to connect to the PLCs. However, this leaves out a huge number of older PLCs in factories all over the world with no support for OPC-UA.</span></p><p><span>We are presenting an approach involving less effort and way less money needed to implement near-real-time IIoT monitoring. This is realized by utilizing </span><a href="https://plc4x.apache.org/" target="_blank"><span>Apache PLC4X</span></a> <span> and the </span><a href="https://www.elastic.co/what-is/elk-stack" target="_blank"><span>ELK Stack</span></a> <span>. Apache PLC4X is integrated into Logstash as a Logstash plugin. This is used to connect to the PLCs and transfer the incoming data into ElasticSearch. Kibana serves as the data analysis and monitoring user interface.</span></p><h2><span>Showcase overview</span></h2><p><span>The showcase implements a rather simple scenario with two conveyor belts within a factory containing temperature sensors for each conveyor belt. A conveyor belt consists of three workstations (or stages). </span><span>The conveyor belt processes items through the workstations. The temperature of the processed items is monitored by the sensors at every stage. </span><span>During each workstation, errors may occur due to high temperatures (it’s a rather theoretical </span><span>example). These errors may produce faulty material, so we are eager to monitor the temperature on each workstation and get insights if anomalies happen.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/eif5qSLhS3WpRJXjYOqW"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/eif5qSLhS3WpRJXjYOqW" alt="Sensors on Conveyor Belt" width="415" height="146" /></a> </span></p><p><span>The showcase consists of three main components. First, there is a simulated (virtual) factory with two servers as data sources for our scenario. </span><span>The servers are polled by Logstash (with integrated Apache PLC4X) as the second component. Logstash pushes the data to ElasticSearch, with Kibana as the frontend for data analysis and display.</span></p><p> </p><p><span><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/pWvANtEStmLxX00zgkXQ"><img loading="lazy" width="250" height="287" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/pWvANtEStmLxX00zgkXQ" alt="Components overview" /></a> </span></p><h3><span>What is Apache PLC4X?</span></h3><p><span><a href="/en/knowledge-hub/blog/apache-plc4x-industrial-innovation">Apache PLC4X</a>  serves as a universal protocol adapter for different types of PLCs. The project’s goal is to easily access many types of PLCs by having a standardized interface for the PLCs’ protocol, e.g. Siemens S7 or Beckhoff ADS.</span></p><h3><span>Logstash integration</span></h3><p><span>The simplicity of the presented approach is achieved by the integration of Apache PLC4X into Logstash as a plugin. We implemented an easy and convenient way to leverage the power of PLC4X with a well-known ETL tool like Logstash. <a href="/wissens-hub/blog/plc4x-logstash-java-input-plugin">This blog post</a>  (German only) presents our challenges in building the Logstash integration.</span></p><h2><span>The showcase</span></h2><p><span>The showcases example implementation is available within a </span><a href="https://github.com/stefah/plc4x-elasticsearch-demo" target="_blank"><span>GitHub repository</span></a> <span>. You can run and try out the example with all components in a few seconds by executing <em>docker-compose</em>.</span></p><p><span>This will spin up several Docker containers for ElasticSearch, Kibana, Logstash, and 2 simulated OPC-UA servers. Everything is preconfigured to show the demo.</span></p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/izPJpY4GQrquJrJjce2k"><img loading="lazy" width="250" height="260" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/izPJpY4GQrquJrJjce2k" alt="Implementation Overview" /></a> </p><h3><span>The simulated OPC-UA server</span></h3><p><span>For the first iteration of our showcase, we quickly needed a simulated PLC to demonstrate the capabilities of Apache PLC4X with Logstash. As PLC4X’s greatest advantage over OPC-UA is that it seamlessly supports different kinds of legacy PLCs (i.e. PLCs without support for OPC-UA), we wanted to use a simulated PLC. However, we didn’t have such a simulated PLC at hand. Therefore, we used a </span><a href="https://github.com/FreeOpcUa/opcua-asyncio" target="_blank"><span>free implementation of an OPC-UA server</span></a> <span> and because of the OPC-UA protocol support of Apache PLC4X, we can demonstrate our use case.</span></p><p><span>The server consists of three temperature sensors, continuously emitting temperature data with little variations in the temperature value (Gaussian distributed) and introduces randomized temperature variations into the data.</span></p><h3><span>Demo Implementation</span></h3><p><span>The implementation of our showcase is done by configuring the Logstash PLC4X plugin within a pipeline:</span></p>

```
input {
	plc4x {
		jobs => {
			job1 => {
				rate => 200
				sources => ["sensors1", "sensors2"]
				queries =>  {
					PreStage => "ns=2;i=3"
					MidStage => "ns=2;i=4"
					PostStage => "ns=2;i=5"
					ConveyorBeltTimestamp => "ns=2;i=7"
				}
			}
		}
		sources => {
			sensors1 => "opcua:tcp://opcua-server-1:4840/freeopcua/server/"
			sensors2 => "opcua:tcp://opcua-server-2:4841/freeopcua/server/"
		}
	}
}
```

<p><span>Afterward, we configured three Timelion visualizations to display the three different temperature sensors for each conveyor belt. You can configure many more useful visualizations if needed. The picture below shows the configuration of a time series diagram for one stage.</span></p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/HYoYSNemTZIlNlB41gbJ"><img loading="lazy" width="250" height="129" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/HYoYSNemTZIlNlB41gbJ" alt="Timelion Visualization" /></a> </p><p><span>The 3 Timelion visualizations are combined within a dashboard and already present a nice overview of the temperature data.</span></p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LdWmaRRu2sdOsWMd2egK"><img loading="lazy" width="250" height="129" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LdWmaRRu2sdOsWMd2egK" alt="Dashboard" /></a> </p><p><span>You may already see some of the detected anomalies at first sight. However, smaller anomalies, with narrower outliers, are harder to manually discover within such a view. </span><span>This is where Kibana’s machine learning features (part of the platinum license) come in place. We are able to automatically detect anomalies within our factory, simply by configuring a new machine learning job.</span></p><p><span>You can configure the machine learning job by navigating to the machine learning tab and clicking on the “<em>create new job</em>” button. Then you have to select the <em>plant</em> index and choose the wizard for multi-metric anomaly detection. Next, choose the time range for your job data. In our case, we had the example running for about four hours, which produced around 140.000 data points.</span></p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jctzeKZBS521SFybZVGo"><img loading="lazy" width="250" height="137" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jctzeKZBS521SFybZVGo" alt="ML Job Creation" /></a> </p><p><span>In the job settings area, select the fields on which the job runs: <em>values.PreStage</em>, <em>values.MidStage </em>and <em>values.PostStage</em> with the max aggregation operation. As the split data field, select the sensor name by choosing the <em>sourceName </em>field.</span></p><p><span>The bucket span describes the size of the generated buckets for the max aggregation and should be set to one second for a finer resolution. Last but not least, configure a job name and description. By clicking on the  “<em>create job</em>” button, the machine learning job gets started. </span></p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/gJMTKvITbWyrpiQQzT2G"><img loading="lazy" width="250" height="208" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/gJMTKvITbWyrpiQQzT2G" alt="ML job results" /></a> </p><p><span>After the job finished, you can view the results. As you can see in the screenshot, the model detected several anomalies and even scores them with a severity measure.</span></p><p><span>It’s also possible to configure a watcher (alerting) for a continuously running job. This allows for e-mail notifications when anomalies occur.</span></p><h3><span>Key takeaways</span></h3><p><span>In this blog post, we built a near-real-time monitoring and anomaly detection for a simulated factory showcase.</span></p><p><span>The benefits of this solution are its low cost and effort compared to similar solutions on the market. Although we used a simulated PLC, the demo is easily applicable to a real PLC. Monitoring, alerting, and machine learning is usually just a matter of configuring the available components and therefore quickly implemented. </span></p><p><span>For the demo setting with only three sensors on two servers, machine learning seems a bit overpowered. However, with thousands of PLCs within multiple factories, manually configuring alerting and thresholds can be a tedious task. Scaling up our example is easily manageable, all it takes is an ElasticSearch cluster and Logstash with the PLC4X plugin on small machines close to the PLCs.</span></p><p><span>So what’s next? We want to improve our showcase by using real or simulated PLCs without OPC-UA to demonstrate the real power of Apache PLC4X. We will further improve the PLC4X Logstash plugin and get it ready for production. It is on our roadmap to extend the showcase scenario to a more production-like setting with an ElasticSearch cluster and a scalable, variable amount of PLCs. </span></p>

Using Apache PLC4X and ElasticSearch for IIoT monitoring and anomaly detection

<p>In this blog post, we want to show why agile transformations fail, illustrating various situations that unfortunately still occur far too often in reality today.<br /> More and more often, we notice that the company culture lived by the management and the employees is crucial for a successful implementation of an agile transformation or agile development. Particularly in large companies, onboarding employees and motivating them tends to be neglected. For example, there are initiatives to transform the company, but they falter and fail due to the attitude of the workforce and/or management, i.e. the company’s culture.<br /> When a healthy agile culture can’t be established in an organization, the following situations may appear:</p><blockquote><p>“But, we are agile! We are doing Scrum!”</p></blockquote><p>Agile has become an overused term. In this article, we look at agile from the perspective of corporate culture. A healthy agile culture has to be lived by employees and their superiors (who act as role models). The transformation to it is laborious, because old structures and behaviors need to be broken up.<br /> Often, <em>Agile</em> is equated with Scrum. It is assumed that if Scrum is practiced, agile software development follows. Working according to Scrum sounds like an easy task, and yet many mistakes happen in the implementation of Scrum in terms of a good agile practice. We have noticed that Scrum does not have to be that important at all. It is more important to live agile in the project culture.<br /> An agile culture includes a focus on transparency, e.g. about all project decisions made, and strengthening the flow of information both within the team and externally. This allows each team member to contribute fully to the success of the project by being involved in the planning, design and improvement of the project. Agile methods (e.g. Scrum) are frameworks to enable this to happen continuously and iteratively.<br /> In the following, we will address common agile anti-patterns related to Scrum.</p><p><strong>The “agile waterfall” project:</strong> It is often observed that agile projects are planned similarly to a waterfall project at the beginning: a time and project plan is defined and the budget must be determined. Deadlines are determined for the individual features. Requirements are packaged into user stories and these are unleashed in the project in one big batch. In the worst case, the user stories are of poor quality, e.g. because they are sliced into too large chunks or are soon outdated.<br /> What follows is that features are implemented, but validation or feedback from the actual end users takes place far too late, if at all. The project falls further and further behind the planned schedule and ultimately fails for the same reasons as usually waterfall projects fail: the planned launch is postponed several times, and when the release finally arrives, it lacks user acceptance. The textbook example of a Big Bang – not at all in line with an agile culture.</p><p><strong>“Chief programmer” sets the direction:</strong> Scrum is used as an excuse to pretend to be Agile. Example Pattern: a product owner (e.g. a former project manager, now retrained) tells each individual team member exactly what tasks to do and when to do them. Scrum tools and meetings are only used to micromanage the team. It is impossible for the team to work independently. Priorities are often changed during the sprint, e.g. because features are not prioritized according to maximum benefit for the product, but according to political aspects (e.g. because a certain feature was promised to a manager for the next release). As a consequence, the team’s decisions are influenced by the “chief programmer” on actual team-internal decisions, therefore it gets impossible for the team to commit to a (sprint) goal.<br /> One thing needs to be made clear: Scrum was not developed to control teams better. It should be clear that not everyone can know everything and therefore a solution must be worked out with the team. If everyone in the team works together and everyone has a good overview of the project’s goals and the future product development, perhaps a better solution can be found.</p><p><strong>Lack of dedicated scrum master:</strong> Good scrum masters are expensive, but they are important. We often hear: “But they don’t even produce code! Well, then a team member can just take over the whole thing.”<br /> This often leads to frustration and impediments within the team, because, for example, retrospectives are poorly conducted or omitted. There is no dedicated person who takes care of removing impediments. This is followed by a decreasing development speed and the previously saved costs are gone.<br /> There is only one solution for this: employ dedicated scrum masters! They take care of protecting the team from external influence and pressure, organize the scrum meetings and solve internal problems. The team must be able to work undisturbed!</p><p><strong>Overly large teams:</strong> Teams should not be too large, otherwise some negative effects can be noticed: meetings drag on due to the number of participants, decision-making becomes increasingly difficult due to many parties to consider, and it becomes more complicated to maintain psychological safety in the team.<br /> Also, knowledge transfer between team members is more challenging. In addition, the team spends 30-50% of the sprint time in meetings, and the time for development becomes increasingly scarce.<br /> In large projects, a meeting is called for pretty much every decision or blocker, and preferably everyone has to be there, because it could affect everyone. In the worst case, this leads to minutes of silence and a lot of wasted time.<br /> Teams should be able to act as independently as possible and they should not be too large. Shared dependencies and interfaces should be discovered and teams should provide a “product” to the respective other team. This leads to a decoupling of the individual teams and the teams can work in a self-determined manner again. Larger meetings between the teams should only take place with individual “emissaries” of the respective teams. The “community of practice” pattern has also proven itself here.</p><blockquote><p>“Well, we are agile! We are doing DevOps!”</p></blockquote><p>DevOps (as a buzzword) has arrived in management. Nevertheless, fundamental concepts of a healthy DevOps practice are not or only partially implemented. When DevOps practices do not work, this is also often due to a lack of alignment of habits, processes and methods by management and employees.<br /> Among other things, teams are not encouraged to live a DevOps culture. Instead, siloed departments or teams continue to exist, with different responsibilities, budgets, and therefore their very own political goals.<br /> For example, DevOps is mistakenly established as a department within the company rather than a practice. A DevOps team as an enabler within the organization would not be a bad thing in this regard, but in reality this department does not provide support for teams, but is hidden behind ticketing systems and lengthy processes. The teams cannot get away from the constraints of the old plan-build-run culture. For example, getting the much-needed CI pipeline doesn’t require one click within a tool, but rather lengthy application forms must be filled out and signed off on by multiple higher-ups so that the pipeline can then be created by the so-called DevOps team.</p><p>These processes have grown in companies over a long time, perhaps for good reasons. Yet they prevent developers from working effectively on the project. The credo must be: <em>Everything and everyone in the company must work toward enabling developers to work effectively and without disruption.</em> Only then can developers focus on creating value for the company and advance the company’s product.<br /> So for our example, this could mean that a DevOps team provides a working self-service platform for CI/CD, which allows projects to create new build and deployment pipelines without much effort. They act as an enabler team and train and support other teams to quickly integrate their platform into their work.<br /> An agile culture and a functioning DevOps practice form a strong symbiosis. DevOps supports development according to agile methods enormously. Only when teams can handle resources independently and in a self-determined manner are they able to also quickly bring features into production.</p><blockquote><p>“Digitization project XY has the highest priority!”</p></blockquote><p>Focus is important. Very often, we see that teams are distracted from their current project by other tasks. How can the important digitization project be successfully completed if team members still spend 50% of their time firefighting for legacy systems or are dragged into pointless meetings?<br /> Good management keeps these team members on task and propagates the project goals to keep all employees focused on a common goal. Goals need to be clear to each team member and management decisions need to be transparent. Only then will team members work effectively and with great intrinsic motivation.</p><blockquote><p>“You said two months ago that it would take X days, now get on with it!”</p></blockquote><p>In addition, teams fall into another trap: they are nailed down to schedules and budgets that were arbitrarily set months ago, but are absolutely untenable with the current knowledge of the product or domain. At the beginning of the project, many technological and architectural decisions were made based on now outdated assumptions when the project had been running for a month or two. The team now tries to meet these deadlines at all costs, even though it is clear that they can no longer be met: motivation drops and the belief in success is lost. Huge amounts of overtime accumulate and the technical debts become bigger and bigger. A downward spiral begins.<br /> It would be more important to measure teams not on deadlines and budgets, which in most cases cannot be met, but on the basis of delivered features. Big decisions should be made as late as possible in order to keep the solution space open and thereby achieve results as quickly as possible, which can then be evaluated and tested. On the other hand, small portioned decisions should be made quickly in order to be validated quickly and to receive feedback fast.</p><blockquote><p>“Are we at a science fair?”</p></blockquote><p>This statement is extreme but we have heard it more often than we would have liked to. It really astonishes us. For us, an explorative approach is a matter of principle and a continuous development of solutions out of hypotheses and their validation through user tests is indispensable.<br /> In reality, it often looks like this: the exact requirements for the product seem to be clear. So we get started (but without requirements specifications, because we are agile!) and user stories are created and a schedule is worked out. For example, features are then taken from (to-be-replaced) legacy systems which are obviously absolutely needed. In addition, it is agreed that the old system was great, but must now be replaced by something better, but the new system must do exactly the same things as the old one.<br /> One wants to do everything right from the start. The way to get there is often unclear and we observed that the customers themselves are not so sure which features really produce the greatest business value for the new product. But instead of starting from scratch, a canonical data model is usually developed (or adopted), the architecture is defined, and instead of figuring out what will create the most value in the new product, a large feature catalog is worked through.</p><p>Again, a downward spiral starts, because the opposite is usually the case: the requirements are anything but clear. What usually happens: the project’s goals are not achieved, there is an ever-increasing delay to the deadlines and the end users are not asked for feedback. The developers’ motivation declines and nobody believes in the success of the project. The project will fail sooner or later.<br /> An explorative approach can prevent this, but it does not come without pain. After all, at the beginning it looks like there are no successes made and that there is a slow development speed. Assumptions are made, features are developed and later much is discarded. However, the earlier assumptions can be validated or invalidated, the better and the higher the development speed will be later on.</p><p>It is important to be open to change from the start! This is part of an agile culture. Change must be reflected in the architecture and implementation of the software. It will happen that the data model will change again after each iteration and the code will have to be heavily refactored each time. Nevertheless, such an approach allows for implementing the actually important features and for getting the necessary feedback from the users early on. It is important to measure the success of the team not on the basis of deadlines met, but on the basis of tested and validated decisions.</p><blockquote><p>“Yes, we want to be in production as soon as possible!”</p></blockquote><p>Unfortunately, we hear this statement far too often in projects that are usually already delayed, e.g. due to the situations already mentioned above. This sometimes means that a product is already months or years behind the actual schedule. Yet, during development, it has not even been successfully rolled out to production.<br /> One thing must be clearly stated: if the feature/product has not deployed to production, no value has been created. Yet, we see it time and time again that teams continue to be bombarded with feature requests: the focus is not on getting existing features into production and testing on end-users and getting feedback. Development goes on and on, money is burned, and in the end customers are presented with a fait accompli.<br /> When the time comes, and the product can be deployed to production, the team lacks the knowledge of which company-specific compliance rules and processes must be adhered to in order to even deploy the new “cloud-native digitization project” to production. For example, cloud teams are deployed as enablers within the company (similar to DevOps teams described earlier) to introduce the respective major cloud providers within the company, but later on these teams are either not designed to support other teams on their way to production and/or are completely busy with other political tasks.<br /> As with a poorly executed DevOps practice, the lack of production readiness again shows a poor “as a service” mindset towards a project. Furthermore, it should be natural for DevOps-practicing teams to also deploy to production several times a day. Only in this way is it possible to obtain a continuous development flow with constant feedback.</p><h3>TL;DR</h3><p>This blog post highlighted various situations and scenarios that can occur in agile projects and then doom them to failure.<br /> Let’s summarize briefly:</p><ul><li>“Agile” is often an empty word and it does not permeate the entire corporate culture. Scrum is introduced and equated with agile. A cultural change does not take place.</li><li>DevOps practices are important to enable agile projects, but are not implemented properly and may drown in a jungle of application forms and politics.</li><li>Teams cannot work autonomously, independently and with focus.</li><li>Continuous learning, feedback, and improvement do not take place, or take place only infrequently.</li><li>It is rarely or not at all deployed to production, experiences cannot be gathered and no lessons can be learned from them. No value has been created as a result either.</li></ul>

Failure on demand – Scenes from an agile transformation

Service Lead - Digital Solutions

Software Developer and Consultant

Software Developer & Consultant

IT Consultant

IT-Security Consultant


> Keycloak ist ein Open-Source-Identitätsanbieter. Du kannst mit minimalem Aufwand Authentifizierung zu Anwendungen und sicheren Diensten hinzufügen. Dabei musst du dich nicht mit der Speicherung oder der Authentifizierung von Benutzern befassen. Keycloak bietet eine Benutzer-Föderation, starke Authentifizierung, Benutzerverwaltung, feingranulare Autorisierung und mehr.
> <a href="https://www.keycloak.org/" target="_blank" rel="noopener noreferrer">~ Keycloak</a>

In diesem Blogpost werde ich meinen Lernweg zu Keycloak und die Ressourcen, die mir auf diesem Weg geholfen haben, mit dir teilen.
Vielleicht hilft dir auch das von mir verwendete Material, Identity and Access Management (IAM) und Keycloak zu verstehen.

Es hat mich einige Zeit gekostet, Keycloak zu erlernen und in Gang zu bringen.
Ich bin wenig vertraut mit dem Java-Ökosystem, da seit meinem letzten Java-Projekt einige Zeit vergangen ist.
Daher fiel mir das Lernen vielleicht etwas schwerer. Wenn du aber ein routinierter Java-Entwickler bist, hast du Glück, denn Keycloak ist in Java geschrieben.
Ich möchte darauf hinweisen, dass ich noch nicht alles erlernt habe, aber ich fühle mich sicher bei der Bereitstellung, Erweiterung und Integration von Keycloak.

## Einstieg in Keycloak
Meine Keycloak-Reise begann in einem Kundenprojekt, in dem wir ein Log-in Theme für Keycloak gebaut und in unsere Frontend-Anwendungen integriert haben.
Sicherlich ist es nur eine kleine Teilmenge dessen, was Keycloak zu bieten hat, aber die anfänglichen Ressourcen sind ein guter Ausgangspunkt für jeden.
Nach einem ersten Besuch der Website, um einige grundlegende Informationen zu finden, zeigen folgende zusätzliche Videos kompakt die Leistungsfähigkeit von Keycloak:

- <a href="https://www.youtube.com/watch?v=mdZauKsMDiI" target="_blank" rel="noopener noreferrer">Securing apps and services with Keycloak authentication | DevNation Tech Talk </a> von Stian Thorgersen (Keycloak Project Lead)
- <a href="https://www.youtube.com/watch?v=KrOd5wIkqls" target="_blank" rel="noopener noreferrer">How to secure your Spring apps with Keycloak von Thomas Darimont @ Spring I/O 2019</a> von Thomas Darimont (Keycloak Maintainer)

## Ressourcen jenseits der Keycloak-Doku: Was ist IAM?
Ich habe eine interessante Beobachtung bei mir selbst gemacht:
Als ich mit Keycloak anfing, war die offizielle Dokumentation überhaupt nicht hilfreich.
Zum Glück hat sich das geändert, und jetzt finde ich die Dokumentation ganz anständig.
Kollegen, die ebenfalls mit Keycloak in Kontakt kamen, hatten das gleiche Problem.
Ich lernte, meine seltsame Beziehung zur Keycloak-Dokumentation entstand aufgrund einer Lücke zwischen meinem Wissen und den Informationen die die Dokumentation bereitstellt.
Die Dokumentation erklärt nicht, was IAM oder OpenID Connect ist und wie es intern funktioniert. Das wird vorausgesetzt.

Ich habe gelernt: Es gibt den IAM-Sektor und Keycloak als Produktlösung.
Die Keycloak-Dokumentation konzentriert sich auf die wichtigsten Teile der Bereitstellung, Verwaltung und Anpassung von Keycloak.
Es wird erwartet, dass einem die IAM-Grundlagen und die Funktionsweise der entsprechenden Protokolle geläufig sind.
Für viele (mich eingeschlossen), die in Keycloak einsteigen, ist das wahrscheinlich nicht der Fall.
Bevor die Keycloak-Dokumentation also eine Hilfe für uns ist, müssen wir zunächst Grundwissen über IAM aufbauen.

Wenn du vor demselben Problem stehst, ist es vielleicht eine gute Idee, einen Schritt zurückzugehen und sich auf die Grundlagen von IAM zu konzentrieren, bevor wir tiefer in Keycloak einsteigen.
Es ist sinnvoll, sich über den IAM-Sektor im Allgemeinen zu informieren, aber sich auch mit den Protokollen vertraut zu machen, die wir verwenden möchten.
In meinem Fall sind das hauptsächlich OAuth2 und OpenID Connect (OIDC).

Das wirft die Frage auf, worum es bei IAM eigentlich geht.
RedHat (der Sponsor von Keycloak) hat einen guten Artikel, der den IAM-Kontext beschreibt:
> Identitäts- und Zugriffsmanagement (IAM) ist eine zentralisierte und konsistente Methode zur Verwaltung von Benutzeridentitäten (d. h. Personen, Dienste und Server) zur Automatisierung von Zugriffskontrollen und zur Erfüllung von Compliance-Anforderungen in herkömmlichen und containerisierten Umgebungen.
> <a href="https://www.redhat.com/en/what-identity-and-access-management-iam" target="_blank" rel="noopener noreferrer">~What is identity and access management (IAM)?</a>

Es gibt eine großartige Ressource, die die Lücke zwischen dem Erlernen der Grundlagen und dem Erlernen von Keycloak überbrückt.
Stian, der Ersteller von Keycloak, hat letztes Jahr ein <a href="https://www.keycloak.org/2021/06/book.adoc" target="_blank" rel="noopener noreferrer">Buch über Keycloak</a> geschrieben.
Ich finde, dieses ist der perfekte Startpunkt.
Er erklärt die Grundlagen des OpenID-Connect-Protokolls und zeigt, wie es mit Keycloak benutzt wird.
Darüber hinaus erklärt er eine Menge Funktionen von Keycloak in kurzen Abschnitten.
Es verschafft uns einen guten Überblick, welche Funktionalitäten Keycloak alles bietet.
Von dort aus können wir die Funktionen auswählen, die den Anforderungen unserer Projekte entsprechen.
Nun können wir zur Keycloak-Dokumentation springen, um einen tieferen Einblick in die Verwendung der einzelnen Funktionen zu erhalten.

> Eine Anmerkung beim Lesen des Buches:
> OAuth2 – die Grundlage von OpenID Connect – ist nicht der Schwerpunkt des Buches.
> Es deckt die Grundlagen ab, aber in meinem Fall war es nicht ganz ausreichend.
> Ich empfehle dir daher, dich während dem Lesen des Buches nach Blogartikeln umzusehen, die sich eingehender mit OAuth2 befassen.

## Lernen von alten Keycloak-Hasen
Glücklicherweise haben wir bei codecentric einige sehr talentierte Leute, die Experten für IAM und Keycloak sind (<a href="/en/knowledge-hub/blog/keycloak-keycloak-x" target="_blank" rel="noopener noreferrer">Sebastian Rose und Thomas Darimont</a>, euch meine ich!).
Sie um sich zu haben und die Möglichkeit, sie alles fragen zu können und von ihrer Erfahrung zu lernen, die sie in vielen Kundenprojekten gesammelt haben, hat meinen Lernprozess sehr gefördert!

Ich hatte die Möglichkeit, an einem *Keycloak Fundamentals*-Workshop von Arne Strathmann teilzunehmen.
Hier haben wir die Grundlagen von Keycloak besprochen und mit dem (inzwischen veralteten) JBoss CLI zur Konfiguration von Keycloak gearbeitet.
Danach haben wir es in andere Anwendungen integriert.

Einige Zeit später nahm ich an einem Meetup teil, bei dem Thomas erklärte, wie man Keycloak erweitern kann.
Neben einer großartigen Präsentation mit guten einfachen Beispielen und vielen Learnings aus seiner Erfahrung gab es für mich noch mehr mitzunehmen:
Kürzlich hat Thomas ein <a href="https://github.com/thomasdarimont/keycloak-project-example" target="_blank" rel="noopener noreferrer"> Keycloak Starter Repository</a> erstellt.
Dies ist ein großartiger Ausgangspunkt oder sogar ein Standard-Repository, um ein neues Keycloak-Projekt zu starten.
Als er es vorstellte, war das Repository noch recht neu und hatte eine kleine Basis.
Ich benutzte diese Vorlage für mein eigenes Keycloak-Setup.
Im Laufe der Jahre hat dieses Repo eine Menge weiterer Konfigurationsoptionen erhalten.
Es ist toll, dass man dort so viele funktionierende Kombinationen finden kann.
Wenn man mit Keycloak anfängt, kann es sinnvoll sein, einige der ersten Commits im Repo zu verwenden.
Dort gibt es nur ein Setup in einer einfacheren Form.
Wenn du dann bereit bist, Keycloak in größerem Umfang einzusetzen, könnten die letzten Updates für dich interessant sein.

Eine andere Sache, die ich gefunden habe, ist das <a href="https://github.com/thomasdarimont/keycloak-extension-playground" target="_blank" rel="noopener noreferrer">Keycloak-Repository</a> mit Erweiterungen von Thomas.
Er hat eine ganze Reihe von Keycloak-Erweiterungen entwickelt.
Vielleicht ist die Erweiterung, die du entwickeln willst, bereits vorhanden!
Ich habe eine Menge hilfreicher Extensions gefunden, und es war eine großartige Inspirationsquelle für meine eigenen Erweiterungen.

Ich würde dir auch empfehlen, den Keycloak-Blog im Auge zu behalten.
Es gibt nicht viele Blog-Einträge, aber neue Artikel liefern immer sehr hilfreiche Informationen!
Zum Beispiel wurde im Dezember letzten Jahres eine <a href=" https://www.keycloak.org/2021/12/cve.html" target="_blank" rel="noopener noreferrer">Sicherheitslücke</a>  in einem Blogeintrag bekanntgegeben.

## Erste Gehversuche
Ausgestattet mit all dem Gelernten begann ich, eigene Erfahrungen mit der Erstellung eines eigenen Keycloak-Docker-Images zu sammeln.
Mit einer Basisinfrastruktur, die ich auf AWS erstellt habe (mit VPC, ELB, ECS Fargate, RDS und SES), konnte ich mein Image bereitstellen und ausführen.
Inzwischen gibt es auch einige Open-Source-Ressourcen für Keycloak in der AWS-Infrastruktur: <a href="https://github.com/aws-samples/cdk-keycloak" target="_blank" rel="noopener noreferrer">cdk-keycloak</a>.
Nachdem die Bereitstellung abgeschlossen war, begann ich mit der Konfiguration von Keycloak.
Diese Konfiguration reicht von der Erstellung des Realms und dem Hinzufügen von Clients über die Konfiguration von Log-Einstellungen, Plugins und Realm-Einstellungen bis hin zur Bereitstellung des Login-Flows und Token-Inhalts.
Diese Konfiguration muss auf einer laufenden Keycloak-Instanz durchgeführt werden.
Wir können sie entweder über die mitgelieferte Admin UI oder die CLI vornehmen.
Da beide Optionen etwas umständlich sind, habe ich die <a href="https://github.com/adorsys/keycloak-config-cli" target="_blank" rel="noopener noreferrer">keycloak-config-cli</a> verwendet.
Sie bietet *Konfiguration als Code* über YAML- oder JSON-Konfigurationsdateien für Keycloak und funktioniert hervorragend.

Und das ist auch schon alles.

> Wenn du Terraform verwendest, um die Infrastruktur für Keycloak zu erstellen, gibt es die Option, Keycloak mit Terraform zu konfigurieren:
> <a href="/wissens-hub/blog/keycloak-konfiguration-mit-terraform" target="_blank" rel="noopener noreferrer">Keycloak-Konfiguration mit Terraform</a>

## Fazit

Zunächst schien Keycloak kompliziert und starr zu sein.
Aber als ich mich näher mit Keycloak beschäftigte, stellte ich fest, dass es viel zu bieten hat.
Es gibt extrem viele Konfigurationsmöglichkeiten, und es ist leicht erweiterbar.

Aber ich habe auch gelernt, dass die Integration von Keycloak in eine Anwendungslandschaft mit versteckten Kosten verbunden ist.
Die Wartung eines Keycloak-Clusters in Produktion erfordert einiges an Aufwand.
Die korrekten Einstellungen und die Durchführung von Updates mit minimalen Auswirkungen auf die Benutzer sind nicht trivial.
Bevor du dich also auf Keycloak stürzt, nur weil es *kostenlos* erscheint, würde ich diese Entscheidung noch einmal hinterfragen.

In letzter Zeit ist viel Wettbewerb im IAM-Sektor entstanden.
Einige Player bieten neben einem Open-Source-Kern auch SaaS-Angebote an.
Andere Anbieter stellen wiederrum eine gehostete Keycloak-Lösung zur Verfügung.
_Managed Services_ haben den Vorteil, dass wir uns auf die Entwicklung und Auslieferung unseres Produkts konzentrieren können.

Das Team hinter Keycloak hat verstanden, dass sich die IAM-Landschaft weiterentwickelt.
Stian hat im <a href="https://www.keycloak.org/2021/10/keycloak-x-update.html" target="_blank" rel="noopener noreferrer">Keycloak.X-Update</a> – siehe auch den <a href="/en/knowledge-hub/blog/keycloak-keycloak-x" target="_blank" rel="noopener noreferrer">Blogpost</a> von Thomas und Sebastian zu Keycloak.X –  einige Einblicke in die Roadmap gegeben.
Man hat das Gefühl, dass sie einige der scharfen Kanten von Keycloak angehen und verbessern.
Das sind gute Neuigkeiten, und ich bin zuversichtlich, dass die Arbeit mit Keycloak in Zukunft einfacher sein wird.
Es ist jedoch wichtig zu wissen, dass dies einige Zeit in Anspruch nehmen wird und zu einigen Umstellungen für derzeit laufende Keycloak-Cluster führen wird.

Ich bin gespannt, welches Tool das Rennen machen und den Markt in Zukunft dominieren wird.
Insgesamt ist Keycloak immer noch ein sehr stabiler Identitätsanbieter, der von einer Menge großer Unternehmen genutzt wird.

Ich hoffe, ich konnte dir einige hilfreiche Ideen und Ressourcen für das Erlernen von Keycloak an die Hand geben.

Bis dann! ✌️


Meine Keycloak-Lernreise

Infrastructure as Code in AWS: Keine Silver Bullet


> Keycloak is an open-source identity provider. You can add authentication to applications and secure services with minimum effort. No need to deal with storing users or authenticating users. Keycloak provides user federation, strong authentication, user management, fine-grained authorization, and more.
> <a href="https://www.keycloak.org/" target="_blank" rel="noopener noreferrer">~ Keycloak</a>

I will share my path to learning Keycloak and the resources that helped me along the way.
Maybe some material that I used will help you understand Identity and Access Management (IAM) and Keycloak, too.

It took me some time to learn and get going with Keycloak.
I’m not that familiar with the Java ecosystem because some time has passed since my last Java project.
So I might have had a harder time learning.
But if you use Java on a daily basis, you’re in luck, since Keycloak is written in Java.
I also want to emphasize that I’m still not done learning yet, but I feel confident deploying, extending, and integrating Keycloak.

## Getting started with Keycloak
My Keycloak journey started in a customer project where we built a login theme for Keycloak and integrated it into our frontend applications.
Sure this is only a tiny subset of what Keycloak has to offer but the initial resources are a good starting point for anyone.
After visiting the website to find some basic information, some additional videos briefly show the power of Keycloak:

- <a href="https://www.youtube.com/watch?v=mdZauKsMDiI" target="_blank" rel="noopener noreferrer">Securing apps and services with Keycloak authentication | DevNation Tech Talk </a> by Stian Thorgersen (Keycloak Project Lead)
- <a href="https://www.youtube.com/watch?v=KrOd5wIkqls" target="_blank" rel="noopener noreferrer">How to secure your Spring apps with Keycloak by Thomas Darimont @ Spring I/O 2019</a> by Thomas Darimont (Keycloak Maintainer)

## Resources beyond the Keycloak docs: What is IAM?
I made an interesting observation about myself.
When I started with Keycloak, the docs weren’t helpful at all.
Luckily that changed, and now I think the docs are quite decent.
Conversations with colleagues, who also came in contact with Keycloak, had the same issue.
I learned that I had this strange relationship with the Keycloak docs because there was a gap between the information that the docs provide and my knowledge.
The docs don't explain what IAM is or what OpenID Connect is and how its internals work.
They expect you to know it.

I learned: There is the IAM sector and Keycloak as an identity provider application offering.
The Keycloak docs focus on the important parts of deploying, managing, and adapting Keycloak.
They expect you to know IAM fundamentals and the inner workings of related protocols.

For many people (including me) who jump into Keycloak, this might not be the case.
So before the Keycloak docs are of any help to us, we have to build up some basic knowledge around IAM.

If you find yourself facing the same problem, it might be a good idea to take a step back and focus on the foundations of IAM before diving deeper into Keycloak.
It makes sense to read about the IAM sector in general but also dive into the protocols you want to use.
In my case, it is mostly OAuth2 & OpenID Connect (OIDC).

This raises the question of what IAM is all about.
RedHat (who sponsors Keycloak) has a good article describing the IAM context:
> Identity and access management (IAM) is a centralized and consistent way to manage user identities (i.e. people, services, and servers), automate access controls, and meet compliance requirements across traditional and containerized environments.
> <a href="https://www.redhat.com/en/what-identity-and-access-management-iam" target="_blank" rel="noopener noreferrer">~ What is identity and access management (IAM)?</a>

There is an awesome resource that bridges the gap between learning the basics and learning Keycloak.
Stian, the creator of Keycloak, wrote a <a href="https://www.keycloak.org/2021/06/book.adoc" target="_blank" rel="noopener noreferrer">book</a> last year about Keycloak.
I think it is the perfect starting point.
It explains the basics of the OpenID Connect protocol and shows how to use it with Keycloak.
Furthermore, it touches on a ton of Keycloak features in short sections to show you what's possible.
From there you can select the features that fit your requirements for your projects.
After that, you can jump to the Keycloak documentation to get a deeper insight into how to use each feature.

> One note while reading the book:
> OAuth2 – the foundation of OpenID Connect – is not the focus of the book.
> It covers the basics but in my case, it was not quite enough.
> So I recommend you have a look around for some blog articles that cover OAuth2 more deeply while reading the book.

## Learning from Keycloak experts
Luckily at codecentric, we have some very talented people that are experts in IAM and Keycloak (looking at you, <a href="/en/knowledge-hub/blog/keycloak-keycloak-x" target="_blank" rel="noopener noreferrer">Sebastian Rose and Thomas Darimont</a>).
Having them around and the ability to ask them anything and learn from the experience they gathered in many customer projects boosted my knowledge.

I was able to attend a *Keycloak Fundamentals* workshop by Arne Strathmann.
There we went over the Keycloak basics, and we worked with the (now old) JBoss CLI for configuring Keycloak.
After that, we integrated it into other applications.

Some time later I participated in a meetup where Thomas explained how to extend Keycloak.
Besides a great presentation with good simple examples and many learnings from his experience, there were more takeaways for me:
Lately Thomas created a <a href="https://github.com/thomasdarimont/keycloak-project-example" target="_blank" rel="noopener noreferrer"> Keycloak Starter Repository</a>.
This is a great starting point or even boilerplate repo for starting a new Keycloak project.
When he presented it, the repo was quite new and had a small baseline.
I used this boilerplate for my own Keycloak setup.
Over the years this repo got a ton of more config options.
It is great that you can find so many working combinations there.
Although when you start with Keycloak it might make sense to head to some of the first commits in the repo.
There is only one setup in a simpler form.
When you are ready to deploy Keycloak on scale, the latest updates might be for you.

Another thing I found is the <a href="https://github.com/thomasdarimont/keycloak-extension-playground" target="_blank" rel="noopener noreferrer">Keycloak Extension Repository</a> from Thomas.
He developed quite a few Keycloak extensions.
Maybe the extension you want to build is already in there!
I found a lot of helpful ones, and it was a great inspiration source for my extensions.

I would also recommend you keep an eye on the Keycloak blog.
There are not that many blog posts but new ones always provide some really helpful information.
For example, in December last year, one blog post disclosed a <a href=" https://www.keycloak.org/2021/12/cve.html" target="_blank" rel="noopener noreferrer">security vulnerabilitiy</a>.

## First in the field experience
Equipped with all the learnings, I started to gain some experience building my Keycloak Docker image.
With some baseline infrastructure I created on AWS (using VPC, ELB, ECS Fargate, RDS & SES), I was able to deploy and run my image.
By now, there are also some open-source resources for Keycloak in AWS infrastructure: <a href="https://github.com/aws-samples/cdk-keycloak" target="_blank" rel="noopener noreferrer">cdk-keycloak</a>.
After the deployment was complete, I started configuring Keycloak.
This configuration includes creating your realm, adding clients to it, configuring log settings, plugins, realm settings, and providing your login flow and token contents.
This config setup has to be done on a running Keycloak instance.
You can apply your configuration either through the provided admin UI or the CLI.
Since both options are a bit cumbersome, I used the <a href="https://github.com/adorsys/keycloak-config-cli" target="_blank" rel="noopener noreferrer">keycloak-config-cli</a>.
It offers *Configuration as Code* via YAML or JSON configuration files for Keycloak and works great.

And that's pretty much it.

> When you're using Terraform to create the infrastructure for Keycloak, there is the option to configure Keycloak with Terraform:
> <a href="/wissens-hub/blog/keycloak-konfiguration-mit-terraform" target="_blank" rel="noopener noreferrer">Keycloak-Konfiguration mit Terraform</a>

## Conclusion

At first, Keycloak seemed complicated and rigid.
But digging deeper into Keycloak I realized it has a lot to offer.
There are tons of configuration options, and it is easily extendable.

But I also learned that there is a hidden cost attached to integrating Keycloak into your application landscape.
Maintaining a Keycloak cluster in production takes quite some effort.
Setting it up correctly and running updates with minimal user impact is not trivial.
So before jumping into Keycloak just because it seems *free*, I would question that decision again.

A lot of competition in the IAM sector has arisen lately.
Some provide SaaS offerings besides an open-source core.
Others offer a managed Keycloak solution.
Managed services have the benefit that we are able to focus on building and shipping our product.

The team behind Keycloak has understood that the IAM landscape evolves.
Stian showed some insights into the roadmap in his <a href="https://www.keycloak.org/2021/10/keycloak-x-update.html" target="_blank" rel="noopener noreferrer">Keycloak.X-Update</a> blog post, as did the <a href="/en/knowledge-hub/blog/keycloak-keycloak-x" target="_blank" rel="noopener noreferrer">Keycloak.X blog post</a> by Thomas und Sebastian.
It feels like they are finally tackling some rough edges of Keycloak.
This is great to hear, and I'm confident that it'll be easier working with Keycloak in the future, although it is important to note that this will take some time and lead to some breaking changes for currently running Keycloak clusters.

I'm curious about what tool will win the race and dominate the market in the future.
Overall, Keycloak is still a very stable identity provider used by a ton of big companies.

I hope I was able to provide you with some helpful ideas and resources for learning Keycloak.

See ya ✌️

My Keycloak learning journey

# Building desktop apps with web technologies

In this article I share insights into Electron and what to consider when shipping an desktop app with Electron.
After that I introduce you to a new alternative called Tauri.
It the end I provide an estimation when which tool makes more sense.

Building cross-platform desktop apps with JavaScript, HTML, and CSS became possible with <a href="https://electronjs.org/" target="_blank" rel="noopener noreferrer">Electron</a>.
It combines Node.js, Chromium (both leveraging the V8 JavaScript engine) and some wrappers for native system interfaces.

It all started with the <a href="https://github.com/atom/atom" target="_blank" rel="noopener noreferrer">Atom</a> editor developed by GitHub, where web technologies were used. They packaged it with an Atom shell as a desktop application.
The shell was eventually detached and renamed to Electron.
Over the years it became part of the OpenJS Foundation and received wide adoption from other companies and open-source apps.
Applications such as VSCode, Slack, Skype, Figma, Obsidian, <a href="https://blog.1password.com/1password-8-the-story-so-far/" target="_blank" rel="noopener noreferrer">1Password8</a> and many others use Electron to ship their applications.

![electron-apps-built-with-electron.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/KIIOO9JaRISYGfPSUyx9)

> In my daily work routine I often stumble across JWT tokens, timestamps and other encoded data (base64, URI, ...).
> For debugging purposes I often need more insights or I want to transform it.
> Pasting application data into random websites is a no-go, so I needed some other tooling.
> I solved my problem by building a developer scratchpad.
> It combines tools & transform operations for everyday tasks called <a href="https://github.com/florianwiech/codewaffle" target="_blank" rel="noopener noreferrer">CodeWaffle</a>.
> You can inspect, download and use it open-sourced and free on GitHub. The downloads are in the <a href="https://github.com/florianwiech/codewaffle/releases" target="_blank" rel="noopener noreferrer">GitHub releases</a>.
> This application was built with Electron.
> The learnings from this article are applied in this codebase.

## The Electron architecture overview
### Multi-process model

![electron-process-model.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/weylgvdQQ6Kc5hfpzREC)

Electron consists of a main process and one-to-many renderer processes.

The **main process** runs in a Node runtime.
All the provided Node APIs are accessible including access to the file system.
Electron provides an additional API to create native UI elements. It includes native popover dialogues, notifications or an application menu bar setup among others.
The main process exists only once per app.
When this process terminates, the app will exit.
Watch out, because <a href="https://twitter.com/NumaanAshraf/status/968496732278374400" target="_blank" rel="noopener noreferrer">blocking the main process with heavy computation will freeze the entire app</a>!
So use async code as much as possible and offload heavy computations to <a href="https://www.electronjs.org/docs/latest/tutorial/multithreading" target="_blank" rel="noopener noreferrer">another thread</a>.

Via the main process we start **one or more renderer processes**.
The renderer process is a Chromium window that runs a web app.
It uses the same browser environment as normal web pages do.
The entry point is a HTML file which loads included CSS assets and JavaScript code.

The **preload script** runs at the renderer window context creation.
This script allows for bridging custom-developed handlers from the main process to the renderer process. It uses the same sandbox as Chromium plugins.

The Electron architecture has analogies to Chrome's own browser and renderer processes.
As you might know, Chromium and V8 are quite memory-intensive, which is a drawback you'll often hear when the conversation is about Electron apps.

### Workflow & communication

![electron-inter-process-communication.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/HC6FOjzzTwyC9H3yTHR9)

The startup of Electron works from a high-level perspective in the following steps:
1. In the Electron init phase the main process sets up handlers for Electron events.
2. When Electron is ready, the main process starts renderer processes and provides a preload script.
3. While setting up the window object for the renderer process, the preload script runs and injects additional APIs.
4. When the renderer process is ready, it loads and renders the web page.

When everything runs, the main and renderer processes communicate via the API created in the preload script.
Those communication options are called *<a href="https://www.electronjs.org/docs/latest/tutorial/ipc" target="_blank" rel="noopener noreferrer">Inter-Process Communication (IPC)</a>*.
With these IPC helpers it is possible to communicate back and forth between the main and renderer processes.
The communication between two renderer windows with the IPC API is only possible through the main process.

Due to this limitation, the *<a href="https://www.electronjs.org/docs/latest/tutorial/message-ports" target="_blank" rel="noopener noreferrer">MessagePorts</a>* API was introduced.
It enables the possibility to create communication channels and then pass messages directly between processes.

## Creating an Electron project setup
### Project setup

The project setup consists of two main parts: the dev environment and the bundling and shipping process.
The **dev setup** consists of things like hot-module-reloading for faster feedback loops.
The **bundling setup** packages the app ready for release.
For better code quality you can bring all the web utilities you know and use (eslint, prettier, testing-library, ...) but I won't cover them in this article (you can look them up in my linked setup though).

Based on your decision which tools you want to use, the setup complexity is different.
Using all the Browser, Node and Electron standards (only using supported ES versions, CommonJS, etc.), your setup is straightforward.
If you want to use the latest JavaScript features, use TypeScript and ESM, you'll need a transpiler and bundler, so your setup will be more complex.

For bundling your Electron apps, you'll eventually come across two libraries: `electron-forge` and `electron-builder`.
`electron-forge` is a great starting point. It's like the `create-react-app` that generates you a ready-to-use boilerplate. It takes care of the dev environment, bundling and releasing part. You can directly start coding.
When you need some more customisations or bring some of your own tools, `electron-builder` is a nice library that just helps you package the electron app. You can bring all your own tools for everything else.
Thankfully the community already provides helpful resources to get you started.
The <a href="https://github.com/cawa-93/vite-electron-builder/" target="_blank" rel="noopener noreferrer">vite-electron-builder</a> is a good boilerplate for Electron apps.

One difference I noticed is the updating process for the Electron app:
`electron-forge` works with the updater built within Electron. It works on Windows and Mac. Linux is required to update their apps with their native package managers.
`electron-builder` provides its own updater, which ships the auto-updating feature for alle three platforms.
You gain more freedom and flexibility but it also means doing the project setup yourself.

### Module support

In JavaScript we like to split our codebase across modules.
The most famous module systems are CommonJS (CJS) and <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules" target="_blank" rel="noopener noreferrer">JavaScript Modules (ESM)</a>.
Node did rely on CJS for a long time, but now ESM is fully supported.
With ESM support in current browsers and Node, <a href="https://github.com/sindresorhus/meta/discussions/15" target="_blank" rel="noopener noreferrer">many developers switch to ESM</a>.
Among other things, ESM provides tree-shaking options and a better readable syntax.
But there is also a fundamental <a href="https://exploringjs.com/es6/ch_modules.html#sec_modules-vs-scripts" target="_blank" rel="noopener noreferrer">difference</a> between those module systems: CJS works synchronous, ESM is asynchronous.

Due to the <a href="https://github.com/electron/electron/issues/21457#issuecomment-1099904505" target="_blank" rel="noopener noreferrer">current setup of Electron</a>, which requires some synchronous tasks, ESM is supported in version 28, but has some limitations you should be aware of. 
The switch to <a href="https://github.com/electron/electron/issues/21457#issuecomment-1159633831" target="_blank" rel="noopener noreferrer">ESM was complicated</a> and <a href="https://github.com/electron/electron/issues/21457#issuecomment-1460917316" target="_blank" rel="noopener noreferrer">took some time</a>.
This only affects the main and preload scripts.
The renderer process (Chromium window) is not affected by this limitation.
Here you can embrace ESM thanks to the browser support.

But do I have to build both main and preload code purely with CJS now?
When you are okay bringing in a transpiler/bundler, it is possible write the complete codebase in ESM and compile the main and preload scripts to CJS.

> In my app I was able to work with ESM as a default.
> I transform the main and preload scripts to CJS in the build step.
> You can configure using ESM as default for the entire codebase by setting the `"type": "module"` entry in your `package.json`.
> You can read about my decision to use ESM <a href="https://github.com/florianwiech/codewaffle/blob/v0.6.0/docs/0002-module-system-setup.md" target="_blank" rel="noopener noreferrer">here</a>.

### Testing

While developing an app, we verify everything works correct. At best we automate it.

Test the **renderer process**–a classical web app–with unit and integration tests.
You can bring and use the tool you already know and work with. With clear code patterns you make your life easier testing specific functions.
For the **main process** it makes sense to start with unit tests. You can verify that specific functions work as expected. On these layers we do not want to test external library–Electron–behaviour.

So in the first step these two processes are tested separately.
The preload script might not include and therefore require that much testing. You can still build some unit tests though. Using TypeScript, you even gain type-safety for the communication.

But the questions remains: How do I verify that my feature works from a user perspective? How do I automate it with E2E tests?

There are some toolkits that support testing Electron apps. The ones I found:
- <a href="https://playwright.dev/docs/api/class-electronapplication" target="_blank" rel="noopener noreferrer">Playwright</a> *still experimental*
- <a href="https://webdriver.io/docs/desktop-testing/electron" target="_blank" rel="noopener noreferrer">WebdriverIO</a>

I tried Playwright with my setup. Yes, it is experimental, but it worked fine.
You can start the entire Electron app and automate the usage from a user perspective.
It's a great way to make sure that features work throughout the entire app.

## Road to production of Electron apps

So with the setup in place, how do I ship the app?

> For CodeWaffle I only have a macOS deployment. Windows is a bit different in terms of the code signing process (you'll read about it shortly).

### Security in Electron

Due to numerous security vulnerabilities in the way Electron apps have been developed in the past, there are some aspects to look out for when shipping an app.
It was commonsensical to use the Node native system APIs in the renderer process. 
One process to load and execute remote resources has full native system access. Bad idea. So we got the preload script.

Among other things they introduced the <a href="https://www.electronjs.org/docs/latest/tutorial/sandbox" target="_blank" rel="noopener noreferrer">Process Sandboxing</a> and <a href="https://www.electronjs.org/docs/latest/tutorial/context-isolation" target="_blank" rel="noopener noreferrer">Context Isolation</a>.
Those are closer to the Chromium security architecture and introduce a context bridge to prevent sharing global objects across processes.

Besides those internal structures, it is recommended to load only secure content from external sources.
Even better, bundle assets and code directly with the app.
Bundled data is part of the app signing and therefore spared from various attacks that can happen to a remote server.
But it means the continuous deployment looks very different than the pipeline for a web app. App updates require some user interaction.

This is just an short outline and some highlights.
To really make sure your app aligns with the latest security standards, Electron provides a big <a href="https://www.electronjs.org/docs/latest/tutorial/security" target="_blank" rel="noopener noreferrer">security checklist</a> to go through.
Thankfully there are more helpful resources for learning and validating your setup:
With the launch of 1Password 8 they shared their <a href="https://www.youtube.com/watch?v=_P6qI4ahBVk&t=5156s" target="_blank" rel="noopener noreferrer">learnings building secure Electron apps</a> and provide a helpful <a href="https://github.com/1Password/electron-secure-defaults" target="_blank" rel="noopener noreferrer">secure-defaults example setup</a>.
The tool <a href="https://github.com/doyensec/electronegativity" target="_blank" rel="noopener noreferrer">electronegravity</a> can help you identify misconfigurations and security anti-patterns in Electron applications.
It leverages AST and DOM parsing to look for security-relevant configurations.
But there are limitations of the AST/DOM parsing which means you may encounter false positive results.
It is a really nice helper, but you have to do the verification yourself!

### User experience

Coming from an web app development background, you have to consider more things when building a desktop app that feels native to each operating system.
Here are some highlights you want to consider:
- Multiple windows: Most platforms show the app preferences in a separate window. Doing this in you Electron app as well brings a native app feeling.
- The window position and size is restored when reopening a window. You need to take care of the positioning yourself.
- Each app has a Menu with items like "File", "Edit", "View", "Window", "Help", etc. in der top left corner.
- Dropdowns – context menus – on an operating system layer have their native theme and design. You should integrate those instead of using your own (as you might solve it in your web app).

There are some great blog articles and talks to help you with you setup:
- <a href="https://www.youtube.com/watch?v=p4PyzDzppiY" target="_blank" rel="noopener noreferrer">Make Your Electron App Feel at Home Everywhere | Kilian Valkhof | Conf42 JavaScript 2021</a>
- <a href="https://dev.to/vadimdemedes/making-electron-apps-feel-native-on-mac-52e8" target="_blank" rel="noopener noreferrer">Making Electron apps feel native on Mac</a>

Surely there are some things you already know. Page speed and performance optimisations are some of them.
Primarily the first window load is about getting the window rendered as fast as possible. A great talk covers how it is handled inside VSCode: <a href="https://www.youtube.com/watch?v=r0OeHRUCCb4" target="_blank" rel="noopener noreferrer">CovalenceConf 2019: Visual Studio Code – The First Second</a>

### Shipping includes bundling, code signing and releasing

With the bundle process and package step, the app is ready to use.
Unfortunately others are not able to install it directly.
Desktop apps on Windows and macOS require an app sign and notarize process before others are able to install the app.
To do that, we need a <a href="https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution" target="_blank" rel="noopener noreferrer">code signing certificate</a>.
You get macOS certificates via an Apple Developer account (includes a yearly fee).
Windows certificates can be purchased by various vendors.
For each platform you have to purchase an appropriate certificate.

This extra step is required, but you can automate it and include it in your release pipeline.
Since others already figured that part out, here are the articles that helped me:
- <a href="https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/" target="_blank" rel="noopener noreferrer">Notarizing your Electron application</a>
- <a href="https://dev.to/rwwagner90/signing-electron-apps-with-github-actions-4cof" target="_blank" rel="noopener noreferrer">Signing Electron Apps with GitHub Actions - DEV Community</a>
- <a href="https://felixrieseberg.com/codesigning-electron-apps-in-ci/" target="_blank" rel="noopener noreferrer">Code-signing Electron Apps in CI</a>
- <a href="https://til.simonwillison.net/electron/sign-notarize-electron-macos" target="_blank" rel="noopener noreferrer">Signing and notarizing an Electron app for distribution using GitHub Actions | Simon Willison’s TILs</a>
- <a href="https://funtoimagine.com/blog/electron-mac-sign-and-notarize/" target="_blank" rel="noopener noreferrer">How I sign and notarize my Electron app on MacOS | Fun to Imagine</a>
- <a href="https://blog.borodutch.com/how-to-deploy-an-electron-app-with-auto-updates-enabled-for-free-in-2021/" target="_blank" rel="noopener noreferrer">How to deploy an Electron app with auto-updates enabled for free in 2021 with just one command</a>

## The new kid on the block: Tauri

With the popularity of Electron and its drawbacks – heavy memory consumption, more effort to nail security and licensing issues – new tools emerged.
One tool I want to highlight is <a href="https://tauri.app/" target="_blank" rel="noopener noreferrer">Tauri</a>.
They saw the popularity of Electron and built a new foundation based on learnings from past mistakes.
Instead of Node and Chromium, they use Rust for the core process and WebView for the renderer processes.
Security is not an afterthought, but directly baked into the core architecture.

### So what should I go with?

As always, it depends.
Electron is the save bet. You can be pretty sure that it will work or there is already a ticket with an open discussion.
Tauri, on the other hand is bleeding edge. *Meaning you will be bleeding.* But it has some advantages that might be worth it.

Here's my evaluation:
- You want to be safe that everything you need is supported (and you have some special needs)? *Go with Electron. Over the years they shipped many native systems APIs you can rely on. Tauri is catching up fast, but there might still be some differences.*
- You are really worried about security (who wouldn't be)? *Both win. Electron has way more cycles gone through. Tauri's overall architecture is better and learned from the mistakes happened in Electron.*
- You are worried about the application performance? *Go with Tauri. You have less dependencies, no Node, no Chromium, no V8. With Rust you have a foundation for a fast runtime.*

FYI: 1Password8 has shown that they shipped their Rust codebase with Electron – the more mature platform. That way you can use both worlds together until Tauri is fully ready. Their solution leverages <a href="https://neon-bindings.com/" target="_blank" rel="noopener noreferrer">`neon-bindings`</a>.

Cheers.

Building desktop apps with web technologies

**tl;dr**
A summary of KubeCon Europe 2026:
It is the year AI agents move from prototypes to production.
This article covers what that means: giving agents verifiable identities, routing inference traffic with the new Gateway API Inference Extension, governing traffic through AI gateways, and building and managing agents with frameworks.

![IMG_1281-boxed.jpeg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmnd3kei8j4uz08t8dzh0112w)

From 23. March 2026 till 26. March 2026 [KubeCon and CloudNativeCon Europe 2026](https://www.cncf.io/blog/2025/08/05/kubecon-cloudnativecon-europe-2026-returning-to-amsterdam-23-26-march/) happened in Amsterdam, Netherlands.
In this article, I share my learnings from this year's conference.
It was my first time at KubeCon. Therefore, I can’t compare it to previous years.

It’s a huge event, tons of companies, thousands of people and hundreds of talks.
As with every conference, you run into the trouble that interesting talks run in parallel. 
You have to decide which one to attend.
Luckily, the talks got recorded. You can look them up afterwards.

The great thing is that maintainers, companies, engineers, and more are in one place.
It's great to meet people from the community you’ve met or worked with before.
The benefit of this conference is that it brings everyone together in one place.
Getting to know maintainers of the tools you use and run.

AI evolves so rapidly that by the time speakers submit their proposals and the conference takes place, the technology has already advanced.
This created a challenge to deliver up-to-date talks.

## Takeaway: Getting agents to production

The general theme regarding AI was:
In 2025, many AI projects, initiatives, and experiments were kicked off.
Now, 2026 is becoming the year of ROI.
Investors are expecting tangible results.
This means prototypes must move into production.
They suddenly face much stricter requirements for security, compliance, and observability.

## Use k8s to run AI agents

I used to assume that companies would run AI agents in tightly sandboxed environments like micro-VMs.
LLMs are powerful, unpredictable, and easy to trick.
That felt like a clear security risk.
What I’ve learned instead is that many teams simply run these agents as containers in their existing Kubernetes clusters.
Most of these agents serve internal use cases.
This lets teams reuse the infrastructure and tooling they already know.
But it also moves the security challenges into the k8s environment itself.

## Agent identities in k8s with SPIFFE/SPIRE

Running agents on personal machines, it seems natural that they impersonate the user.
But when an agent runs within the cluster, how do we identify the agent?
It often serves multiple users and exhibits human-like interaction capabilities.

This is what some talks covered.
One of them was [When an Agent Acts on Your Behalf, Who Holds the Keys? - Mariusz Sabath & Maia Iyer, IBM Research](https://sched.co/2CVxt)
In this talk, the speakers presented [kagenti](https://github.com/kagenti/kagenti).
It cryptographically binds an AI agent’s identity to the user's delegated identity.

All the talks relied on the agent identity on SPIFFE/SPIRE (SPIFFE as the standard, SPIRE the implementation).
They showed how SPIRE’s workload attestation can be extended to create a verifiable agent identity.
Then they used Keycloak, acting as an OAuth 2.0 server, to manage delegated user identity while preserving context across long, nested transactions.

## New traffic patterns demand new infrastructure

AI chats and agent workloads have introduced a very different traffic pattern compared to traditional web services.
In classic APIs, each endpoint typically receives requests of similar size.
With chatbots and agents, however, every new message is sent along with the _entire_ conversation history as context.
As chats grow longer (the request body grows too), request sizes become highly variable and increasingly large, hitting the same endpoint.
This shift puts new pressure on ingress, routing, and load balancing for inference workloads.

A whole wave of new projects emerged to address these challenges.
They operate at different layers of the stack.

### Inference routing: Gateway API Inference Extension

To address inference-specific routing challenges in Kubernetes, a new *Inference Gateway API* emerged.
The [Gateway API Inference Extension](https://gateway-api-inference-extension.sigs.k8s.io/) is an official Kubernetes SIG project that optimises routing and load-balancing for self-hosted generative AI models on Kubernetes.
It is not a gateway itself, but a **spec that gateway implementations adopt**.
Envoy AI Gateway, Agentgateway, and Istio all implement it.

[llm-d](https://github.com/llm-d/llm-d/) builds on top of this standard. It uses the Inference Extension as its control plane API for intelligent scheduling.
The talk [Cloud Native Theater | Istio Day: Running State of the Art Inference with Istio and LLM-D - Jackie Maertens, Microsoft and Nili Guy, IBM](https://sched.co/2EG0w) covered inference routing with istio and llm-d in detail.
It aims to improve throughput and latency for real-world LLM traffic.

### AI Gateways: proxying LLM, MCP, and agent traffic

One layer up from inference routing sit the AI gateways. These proxy and govern the traffic between applications/agents and LLMs, between agents and tools (MCP), and between agents themselves (A2A). They handle concerns like authentication, rate limiting, observability, and policy enforcement.

Several projects occupy this space, with overlapping but distinct scopes:

**[Envoy AI Gateway](https://aigateway.envoyproxy.io/)** extends Envoy Gateway to manage traffic to generative AI services. It supports routing to LLM providers through a unified interface. It provides token-aware rate limiting, provider failover, and an MCP gateway with stateless session management. It implements the Gateway API Inference Extension for self-hosted model routing. It is Kubernetes-native, built on Envoy Proxy, and maintained by the Envoy/CNCF community.

**[Agentgateway](https://github.com/agentgateway/agentgateway)** is a Rust-based AI-native proxy that covers the broadest scope. It handles LLM traffic, MCP (tool federation with stdio/HTTP/SSE transports), and A2A (agent-to-agent) protocol. This makes it the only gateway of the three that supports all three traffic types. It also provides built-in guardrails (regex filtering, moderation APIs), a Cedar/CEL policy engine, and tool poisoning protection. It is a Linux Foundation project (originated at Solo.io) and runs both standalone and on Kubernetes.

**[Kuadrant](https://kuadrant.io/)** is a CNCF Sandbox project that takes a different approach: it is a **policy layer on top of existing gateways**, not a standalone gateway. It attaches auth, rate limiting, DNS, and TLS policies to Gateway API resources. Its [mcp-gateway](https://github.com/Kuadrant/mcp-gateway) sub-project specifically handles MCP server aggregation and tool-level authorisation (e.g., via Keycloak groups).

These talks explored the gateway and policy space:

- [Envoy in the Era of Agentic Workloads - Yan Avlasov, Google & Erica Hughberg, Tetrate](https://sched.co/2EF7C): This talk explores how agentic workloads stress both data and control planes, and shows how Envoy and Envoy AI Gateway provide building blocks for service-centric networking for inference, MCP, and agent-to-agent (A2A) requests.
- [Least-Privilege for AI: Authorizing Agents and MCP Tools with Agentgateway and Kyverno - Luc Chmielowski, Nirmata & Nina Polshakova, Solo.io](https://sched.co/2CVxe): This session shows how Agentgateway integrates with Kyverno policies to evaluate MCP traffic, preventing uncontrolled tool access and privilege escalation while ensuring namespace and tenant isolation.
- [Keeping Your Agents in Check: Layered Security for Agentic Platforms in Production - Evaline Ju, IBM Research & Kelly Abuelsaad, IBM](https://sched.co/2DY7P): This talk explores a layered approach to securing agentic platforms, from identity and authorisation to guardrails at the Envoy gateway layer, demonstrating how risks like prompt injection and unauthorised tool access can be mitigated. The speakers also presented Kuadrant as an MCP Gateway that enforces policy and audit controls at a single, trusted point between agents and their tools.

## Building and managing agents on Kubernetes

Beyond the networking and gateway layer, another set of tools focuses on the agent lifecycle itself: building agents, deploying them, discovering tools, and orchestrating workflows.

### Agent frameworks

**[kagent](https://github.com/kagent-dev/kagent)** is a CNCF Sandbox project (created at Solo.io) that provides a Kubernetes-native framework for building AI agents. Agents, tools, and model configurations are all defined as Kubernetes CRDs. It ships with pre-built MCP tool servers for cloud-native operations (Kubernetes, Istio, Helm, Argo, Prometheus, Grafana, Cilium). Its engine is built on Google ADK. Note: this is a different project from kagenti (IBM), which focuses on securing and operating agents rather than building them.

**[Dapr Agents](https://github.com/dapr/dapr-agents)** takes a different approach, focusing on **resilient agent workflows**. Built on the CNCF Dapr runtime, it uses a virtual actor model where each agent is a lightweight, stateful actor with scale-to-zero support. Its key differentiator is durable execution: agent workflows are guaranteed to complete through automatic retries and state recovery after crashes. Dapr provides built-in pub/sub, state management, and service invocation out of the box.

Both frameworks were featured in talks that showed them in action:

- [Day-2 Ready: Bringing agentic pilots to production - Idit Levine & Keith Babo, Solo.io](https://sched.co/2DYGs): Solo.io presented their vision for taking agents from prototype to production. They introduced kagent as the framework for defining and running agents on Kubernetes, and agentregistry (covered below) as the missing discovery layer. The central argument was that production-readiness for agents requires the same declarative, GitOps-friendly patterns that platform teams already use for the rest of their infrastructure.
- [Orchestrating Document Data Extraction with Dapr Agents - Fabian Steinbach, Software Architect, ZEISS](https://sched.co/2HgFV): ZEISS Vision Care shared how they built a document data extraction pipeline using Dapr Agents. Their challenge was processing highly variable, multi-lingual documents with different layouts and handwriting. By composing deterministic workflows that blend specialized OCR, LLM calls, and standard code, they went from concept to production in two months. The talk demonstrated a key advantage of Dapr Agents: because workflows are durable and vendor-neutral, the team could swap AI providers without rearchitecting the system.

### Agent registries

**[agentregistry](https://github.com/agentregistry-dev/agentregistry)** addresses a practical problem: MCP servers and AI tools are scattered across npm, PyPI, Docker Hub, GitHub repos, and random URLs. Nobody knows which ones are trustworthy, which versions work, or how to get them running.
agentregistry is an open-source platform that gives you one place to find, manage, and run MCP servers, AI agents, and skills.
You import or publish artifacts once, and then anyone on your team can discover them, deploy them with one command, and have their IDE automatically configured to use them.

## The broader AI landscape

Beyond agents and gateways, a few other AI-related talks stood out:

- [MCP in 2026: Context is All You Need - David Soria Parra, Anthropic](https://sched.co/2E7Db): David Soria Parra, one of the creators of MCP at Anthropic, gave an update on where the Model Context Protocol is heading. The key takeaway was that MCP is moving beyond simple tool calling toward richer context exchange between agents and their environment, making the protocol a foundational building block for agentic systems rather than just a tool integration spec.
- [The New AI Coding Fabric - Patrick Debois, Tessl](https://sched.co/2DY5H): Patrick Debois drew a parallel between the DevOps movement and today's autonomous coding agents. Just as DevOps introduced patterns for continuous integration and delivery, he argues we need a similar "fabric" of practices, pipelines, and feedback loops for AI-driven software development. The talk outlined how teams can apply lessons from DevOps to govern, test, and trust code produced by coding agents at scale.
- [Is AIOps the Future of Operations? Real Use Cases From the Trenches - Iveri Prangishvili & Danilo Banjac, Adobe](https://sched.co/2DY8K): Adobe shared real-world examples of using agentic workflows to automate on-call tasks, diagnose incidents, and drive continuous improvement. The practical takeaway was that AIOps is not about replacing operators but about reducing manual toil: agents handle the repetitive triage and data gathering so that humans can focus on the decisions that matter.

## Surprise highlight talk: Virtual Power Plant

One of the standout sessions for me was
[Virtual Power Plants (VPP): How They Work and What They Are - LeRenzo Malcom & Mario Flores, Enpal](https://sched.co/2CVyB)

They started by explaining the power grid as a single giant machine that must remain at a stable 50 Hz frequency, with supply and demand matched every second.
The European grid, the largest in the world, has essentially never been shut down.
Yet, events like the coldest winter in Texas showed how close we can come to a total blackout, which operators avoided by only a few minutes.

From there, they showed how renewables disrupt this fragile balance.
Solar power can flood the grid with energy during the day and then vanish in the evening.
During the day, it pushes prices so low that providers effectively pay people to use electricity.
This creates the famous duck curve: low net demand at midday and a steep ramp-up later.

Virtual power plants are their answer to this problem.
A VPP connects many small assets like rooftop solar, home batteries, and electric cars.
It controls them via software, so they act as one flexible power plant.
It can shift when homes and cars use or store energy, soaking up excess solar when it is cheap and feeding power back when demand is high.
That makes the grid more stable, helps integrate more renewables, and gives households a way to save money or even earn by offering their flexibility.

If you want to dive deeper, their [website](https://whatisavpp.com/) and the talk recording are well worth a look.

## SWAG

As always with events, there is SWAG (**s**tuff **w**e **a**ll **g**et).

![kubecon-swag.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmnd84w2o3k3s07tchq50gqso)

These are the highlights I found:
- JetBrains bag featuring a map of Amsterdam. Uniquely designed for this conference, paired with the Dutch tulip tradition.
- Solo.io van Gogh shirt featuring the k8s mascots. Special image blending van Gogh art, known from Amsterdam, with the k8s brand.
- ASML Wafer Waffles. ASML merged stroopwafels (thin caramel-filled waffle cookies that are a classic local treat) with their wafer lithography systems.

Besides the highlights, as always, you could get shirts, socks, bags, stickers, coffee, muffins and more at each booth.
Other marketing themes this year included raffles for LEGO sets, vacations, and gaming consoles.

![IMG_1438.jpeg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmnd3m6ahindu06uqoci3ivvm)

That's it. If you went to KubeCon, I hope you had fun.

Thank you for reading.

KubeCon Europe 2026: AI agents go to production

<p>Ca. zwei Monate nach meinem Einstieg bei codecentric hatte ich ein wirklich interessantes Gespräch mit einem Kollegen. Ich glaube, es verlief folgendermaßen:</p><p>Kollege: Hey, hast Du schon mal von YAGNI gehört?<br /> Ich: Gesundheit.<br /> Kollege: Was?<br /> Ich: Du hast doch gerade geniest?<br /> …</p><p>Ich bin mir ziemlich sicher, dass das Gespräch so verlief. Aber im Ernst, er sagte mir, dass es für die effektive Entwicklung von Software entscheidend ist, YAGNI (You aren’t gonna need it) zu verstehen und anzuwenden. Ich sollte es ausprobieren und es in meinen aktuellen und nächsten Projekten verbreiten. Aber was in aller Welt ist YAGNI und warum sollte es mir bei der Software-Entwicklung helfen? Ich möchte euch in diesem Artikel einen kurzen Überblick geben und einige Erfahrungen mit euch teilen.</p><h2>You aren’t gonna need it!</h2><p>Er gab mir einen Website-Link [<a href="http://c2.com/xp/YouArentGonnaNeedIt.html" target="_blank">http://c2.com/xp/YouArentGonnaNeedIt.html</a> ], um mehr über YAGNI zu lesen. YAGNI ist also eine Extreme-Programming-Technik. Und eines der ersten Zitate auf der Website sagt eigentlich alles aus, was man wissen muss:</p><blockquote><p>Implementiere die Dinge immer dann, wenn du sie tatsächlich brauchst, niemals, wenn du nur voraussieht, dass du sie brauchen könntest.</p></blockquote><p>Moment, was? Das ist einfach und genial zugleich. Als ich diesen Satz las, hatte ich direkt ein euphorisches Gefühl und war sofort vom YAGNI-Virus infiziert.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/P854jxRGNxPAjjz4GWgP"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/P854jxRGNxPAjjz4GWgP" alt="softwarepiece" width="1024" height="683" /></a> </p><p>Wie oft habe ich in der Vergangenheit, bevor ich diesen Ansatz kannte, so etwas gedacht: „Was könnte mit meiner Software in der Zukunft passieren? Oh ja, vielleicht dies und das. Lass uns einfach all diese Dinge implementieren, da wir sowieso gerade daran arbeiten. Dann ist es zukunftssicher.“ Und was geschah dann? Richtig, die implementierten Funktionen, die auf Annahmen basierten, funktionierten nicht wie vom Kunden oder Benutzer erwartet. Also mussten wir am Ende einige Teile der Software neu implementieren, um das zu beheben. Und manchmal kommt es vor, dass ein Teil der Software aus bestimmten Gründen zukünftig nicht mehr benötigt oder verwendet wird.</p><p>Hier kann YAGNI helfen: indem ihr Dinge erst dann implementiert, wenn sie gebraucht werden. Damit könnt ihr euch Zeit und unnötige Arbeit bei der Implementierung sparen und unnötige Wartung des Codes vermeiden.</p><p>Das gleiche Prinzip gilt sowohl auf der geschäftlichen Ebene, wie z. B. bei den Produktfunktionen, als auch auf der Implementierungsebene, wie z. B. bei den Software-Abstraktionen. Schreibt ihr nur eine Klasse oder erstellt ihr bereits eine abstrakte Klasse mit einer Child-Klasse, weil ihr vermutet, dass in Zukunft noch mehr Child-Klassen kommen werden?</p><h2>Würde YAGNI in den Projektalltag passen?</h2><p>Kurze Antwort: Auf jeden Fall. Bei einem kürzlich durchgeführten Projekt waren der oben genannte Kollege und ich in der glücklichen Lage, demselben Team beizutreten. Und er hat auch dort das YAGNI-Prinzip gleich zu Beginn dem Rest des Teams vorgestellt. Es war interessant zu beobachten, wie diese Technik zu einer Art Herausforderung wurde. Sehr oft hörten wir jemanden sagen: „Warte, brauchen wir das wirklich jetzt?“. Das war sehr cool. Sie waren alle mit diesem YAGNI-Virus infiziert. Eines unserer neuen Teammitglieder schuf sogar einen Post-It-Schrein an der Wand des Büros.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9op4M3EeThe3O8ib5anS"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9op4M3EeThe3O8ib5anS" alt="yagni do-we-really-need-it" width="1024" height="265" /></a> </p><p>Ein großer Vorteil von YAGNI ist es, unnötige Entwicklungen zu vermeiden. Wenn man darüber nachdenkt, entwickelt man sicherlich oft Software auf der Grundlage von Annahmen. Wenn man über zukünftige Funktionen nachdenkt, kann es auch manchmal Unklarheiten geben. Ich habe die Erfahrung gemacht, dass auch der Kunde sagte: „Ja, wir brauchen jetzt die Funktion X“, und wenn man nach den Anforderungen an diese Funktion fragte, hörte man als Antwort manchmal so etwas wie „Oh, das ist im Moment nicht hundertprozentig klar“. Das sollte eine Warnung sein. Diese Dinge sind genau das, wofür YAGNI steht. Verschiebt diese Anforderung auf einen späteren Zeitpunkt des Projekts. Dann könnten die Anforderungen klarer sein und ein Feature könnte genauer bzw. gezielter entwickelt werden.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nB3onXLgQRGYRXOmVn7h"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nB3onXLgQRGYRXOmVn7h" alt="yagni-mindset" width="1024" height="383" /></a> </p><p>Aber … es gibt immer ein „aber“ … es ist manchmal nicht so einfach. Es ist harte Arbeit, eine YAGNI-Mentalität in einem Team und bei einem Kunden zu verbreiten. Ihr solltet immer wieder versuchen, euer Gegenüber herauszufordern. Fragt euch selbst, euer Team und den Kunden: „Brauchen wir das wirklich (jetzt)?“. Wenn euer Gegenüber Schwierigkeiten hat oder nicht klar ist, warum etwas benötigt wird, dann ist dies ein Indikator, dass YAGNI helfen kann. Und dann solltet ihr auch darüber nachdenken, es zu verschieben oder auf Eis zu legen, bis es wieder wichtig wird. Das bedeutet nicht, dass die Dinge nicht wichtig sind, aber sie sind vielleicht zu einem frühen Zeitpunkt noch unklar. Wenn sie zu einem späteren Zeitpunkt wichtiger werden, dann könnte auch die Reife dieses Themas ausgeprägter sein. Es könnte für den Kunden relevanter werden, und es könnten genug Details für eine Umsetzung geben.</p><p>Was YAGNI nicht bedeutet, ist, dass ein Feature niemals implementiert wird, nur weil es jetzt nicht notwendig ist. Es soll euch nur dabei helfen, Prioritäten zu setzen und zu vermeiden, dass ihr jetzt auf der Grundlage von Annahmen arbeitet, mit der Gefahr, es später zweimal zu tun, weil es im Moment falsche oder zu wenige Informationen gibt.</p><p>Wenn ihr YAGNI verwendet, könntet ihr auch das Gefühl bekommen, dass es euch davon abhalten könnte, Experimente durchzuführen. Das wäre richtig, wenn ihr die YAGNI-Methodik bei der Erstellung von Prototypen ignoriert. Der bessere Weg ist, wenn ihr die Technik zum Fokussieren verwendet. Quasi während ihr einen Prototyp erstellt. Und hier wäre es völlig in Ordnung, wenn man dieselbe Arbeit zweimal machen würde. Dann könnt ihr aus dem Feedback lernen, und vielleicht ist der Prototyp auch manchmal nicht das, was der Benutzer oder Kunde erwartet. Das führt sehr schnell dazu, dass die Idee verworfen wird und man es noch einmal implementiert. Aber das ist völlig in Ordnung, und während der Durchführung von Versuchen solltet ihr auch YAGNI einsetzen, um euer Ergebnis nicht zu überfrachten. Wie auch immer, beim Prototyping geht es darum, etwas auszuprobieren und sich bewusst zu sein, dass es am Ende weggeworfen wird.</p><h2>Fazit</h2><p>Für mich ist YAGNI eine ausgezeichnete Möglichkeit, den Software-Entwicklungszyklus zu verbessern. Es hilft sehr, sich auf die notwendigen Funktionen und Software-Artefakte zu konzentrieren. Ihr solltet es für Experimente (Prototyping) verwenden und euch dabei bewusst sein, dass Software-Artefakte möglicherweise mehrfach implementiert werden müssen. Ich finde, dass YAGNI und Prototyping perfekt zusammenpassen. Und nun sucht euch etwas, was vereinfacht werden muss!</p>

YAGNI – Eine kurze Einführung und ein Erfahrungsbericht

<p>About two months after I joined codecentric, I had a really interesting conversation with a colleague. I think it went like this:</p><p><em>Colleague: Hey, have you ever heard of YAGNI?</em><br /> <em>Me: Bless you!</em><br /> <em>Colleague: What?</em><br /> <em>Me: Did you just sneeze?</em><br /> <em>…</em></p><p>I am pretty sure that the conversation was like that. But seriously, he told me that in order to develop software effectively, it’s critical to understand and apply YAGNI, which is short for: “You Aren’t Gonna Need It”. I should try it and use it inside my current and upcoming projects, he said. But what on earth is YAGNI and why should it help me in software development? In this article, I would like to give you a quick overview and share some experiences.</p><h2>You aren’t gonna need it!</h2><p>My colleague gave me a website link [<a href="http://c2.com/xp/YouArentGonnaNeedIt.html" target="_blank">http://c2.com/xp/YouArentGonnaNeedIt.html</a> ] to read more about YAGNI. So, YAGNI is an extreme programming technique. And one of the first quotes on the website tells you everything you need to know:</p><p><em>“Always implement things when you actually need them, never when you just foresee that you need them.”</em></p><p>Wait, what? That is simple and genius at the same time. When I read that sentence it gave me a mind-blowing feeling and I was instantly infected with the YAGNI virus.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/P854jxRGNxPAjjz4GWgP"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/P854jxRGNxPAjjz4GWgP" alt="softwarepiece" width="1024" height="683" /></a> </p><p>Often, in the past, before I knew that approach, I thought something like: “What could happen with my software in the future? Oh yeah, maybe this and that. Let’s implement all these things since we are working on this part anyway. That way it’s future-proof” And what happened afterwards? Right, the implemented features, based on assumptions, didn’t work as expected by the customer or user. So in the end we had to reimplement some parts of the software to fix that. And sometimes it happens that a piece of the software is not needed or used in the future, because of reasons.</p><p>This is where YAGNI can help. By not implementing things until you need them, you can save time and prevent useless work implementing and maintaining this code.</p><p>This same principal applies on both a business level, such as product features, and on an implementation level, like software abstractions. Do you just write a class, or do you already create an abstract class with one child class because you suspect more children will come in the future?</p><h2>Would YAGNI fit into your daily project life?</h2><p>Short answer: absolutely. In a recent project, the above mentioned colleague and I were in the lucky situation to join the same team. And he also introduced the YAGNI principle to the rest of the team at the very beginning. It was interesting to observe how this technique was a kind of a challenge. Very often we heard someone say: “Wait, do we really need that now?”. That was amazing. They were all infected with that virus, too. One of our new team members also created a Post-It shrine at the office wall.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9op4M3EeThe3O8ib5anS"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9op4M3EeThe3O8ib5anS" alt="yagni do-we-really-need-it" width="1024" height="265" /></a> </p><p>A big advantage of YAGNI is that you avoid unnecessary development. If you think about it, you certainly often develop software on the basis of assumptions. Also, sometimes when you think about future features, there could be obscurities. I have heard customers say “Yeah, we need feature X now”, and when you ask what the requirements for this feature are, you sometimes get an answer like “Oh, that is not 100% clear at the moment”. This should alert you. Those things are exactly what YAGNI stands for. Postpone them to a later state of the project when requirements are more clear and a feature can be developed more accurately.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nB3onXLgQRGYRXOmVn7h"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nB3onXLgQRGYRXOmVn7h" alt="yagni-mindset" width="1024" height="383" /></a> </p><p>But … there is always a “but” … sometimes it is not that easy. It is hard work to spread a YAGNI mindset in a team and propagate it to a customer. Over and over, you should try to challenge your opposite. Ask yourself, your team, and your client: “Do we really need this (now)?”. Whenever your counterpart struggles or doesn’t have a clear standing why something is needed, it’s clearly time for YAGNI. Then you should also think about discarding it or put it on hold until it becomes relevant again. This doesn’t mean that things aren’t important, but they are maybe still unclear at an early point in time. When they become more important at a later point, the maturity of this issue might also have grown. It might become more relevant for the client and there could be enough details for an implementation.</p><p>What YAGNI does not mean is that a feature will never be implemented only because it is not necessary at present. It should just help you to prioritise your work and prevent you from doing work that is based on assumptions. You’ll only risk having to re-do it later because the information you had earlier was wrong or not sufficient.</p><p>When using YAGNI, you might get the impression that it will prevent you from doing experiments. This would be right if you ignored the YAGNI methodology while doing prototyping. It’s best to use the technique for focusing while you create a prototype. In that case it is totally OK to do the work twice. You can then learn from the feedback. After all, your prototype might not always be what the user or client expects, so you will need to discard your idea and re-do it. This is totally fine, and while implementing trials, you also should adopt YAGNI in order not to overload your outcome. Anyway, prototyping is about trying something while being aware that it may be dismissed in the end.</p><h2>Conclusion</h2><p>For me, YAGNI is an excellent way to improve your software development cycle. It helps you a lot to focus on necessary features and software pieces. You should use it for experiments (prototyping) and be aware that software pieces might have to be implemented multiple times. YAGNI and prototyping fit together perfectly. Now, go find something and simplify it down to essentials right now!</p>

YAGNI – A quick introduction and field report

Team oriented developer

<p>Scala erlaubt die Nutzung des Keywords <code>lazy</code> in Verbindung mit <code>val</code>, um die Initialisierung bei Bedarf auszuführen. Bedarfsauswertung für <code>val</code> hört sich gut an, allerdings hat die konkrete Implementierung in <code>scalac</code> dem Scala Compiler ein paar sehr subtile Probleme, auf die man nicht immer gefasst ist. Dieser Artikel wirft einen Blick hinter die Kulissen und zeigt einige der Stolperfallen auf: neben einem Blick auf die Implementierung in <code>scalac</code> werden wir Szenarien vorstellen, in denen bei Bedarf ausgewertete <code>val</code> das komplette Programm abstürzen lassen, parallele Auswertung verhindern oder anderes Unerwartetes Verhalten zeigen.</p><div><div><h2>Einführung</h2><div><p>Dieser Beitrag wurde ursprünglich inspiriert von dem Talk <a href="https://www.youtube.com/watch?v=aftdOFuVU1o">Hands-on Dotty</a>  (<a href="https://d-d.me/scalaworld2015/#/">slides</a> ) von Dmitry Petrashko, vorgetragen während der Scala World 2015. Dmitry hielt dort einen wunderbaren Talk über Dotty und erklärt einige der Fallstricke die durch Bedarfsauswertung entstehen, sowie die geänderte Implementierung in Dotty. Wir werden im Folgenden die Bedarfsauswertung von <code>val</code> diskutieren, uns einige der Beispiele von Dmitry genauer ansehen und zusätzliche Szenarien betrachten.</p></div></div><div><h2>Wie <code>lazy</code> funktioniert</h2><div><p>Das prägende Merkmal von <code>lazy</code> ist, dass das <code>val</code> nicht sofort initialisiert wird sondern <b>einmalig</b><sup><a href="#fn.1">1</a> </sup>, bei Bedarf. Wenn der erste Zugriff erfolgt wird der Ausdruck ausgewertet und das Ergebnis dem Namen des <code>val</code> zugewiesen. Nachfolgende Zugriffe führen nicht zu wiederholter Auswertung: es wird stattdessen sofort das gespeicherte Ergebnis zurückgegeben.</p><p>Mit der oben stehenden Beschreibung, scheint es, als ob „Auswertung bei Bedarf“ harmlos ist und keine negativen Effekte hat, also warum fügt man <code>lazy</code> nicht immer hinzu, sozusagen als eine spekulative Optimierung? In Kürze werden wir sehen warum eben das meist keine gute Idee ist, aber bevor wir dieses Thema vertiefen, sollten wir erst einen genaueren Blick auf die Semantik von <code>lazy val</code> werfen.</p><p>Wenn wir wie folgt einen Ausdruck einem <code>lazy val</code> zuweisen:</p><div>

```src src-scala
lazy val two: Int = 1 + 1

```

</div><p>erwarten wir, dass der Ausdruck <code>1 + 1</code> an den Namen <code>two</code> gebunden wird, jedoch noch keine Auswertung stattfindet. Beim ersten, und nur beim ersten Zugriff auf <code>two</code> wird der gespeicherte Ausdruck <code>1 + 1</code> ausgewertet und das Ergebnis zurückgegeben. Nachfolgende Zugriffe auf <code>two</code> führen <b>nicht</b> zu weiteren Auswertungen: stattdessen wurde das Ergebnis der Auswertung gespeichert und wird nun jedes Mal zurückgegeben.</p><p>Die Eigenschaft, das Auswertung nur <b>einmal</b> stattfindet ist dabei sehr wichtig. Insbesondere wird dies deutlich, wenn man an Szenarios denkt, bei denen nebenläufige Ausführung stattfindet. Wie, zum Beispiel, soll das Verhalten aussehen, wenn zwei oder mehr Threads gleichzeitig auf ein <code>lazy val</code> zugreifen wollen? Die oben erwähnte Eigenschaft, dass Auswertung nur einmal stattfindet, bedingt eine Form der Synchronisierung um mehrfache Auswertungen zu vermeiden. In der Praxis wird also ein Thread die Auswertung durchführen, während alle anderen Threads warten müssen. Erst wenn die Auswertung des zugewiesenen Ausdrucks abgeschlossen ist, können die wartenden Threads das Ergebnis lesen.</p><p>Und wie ist das in <code>scalac</code>, dem aktuellen Standard Scala Compiler implementiert? Dazu können wir ein Blick auf <a href="http://docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html">SIP-20</a>  werfen. Im Beispiel wird dort eine Klasse <code>LazyCell</code> mit einem <code>lazy val</code> „value“ definiert:</p><div>

```src src-scala
final class LazyCell {
  lazy val value: Int = 42
}

```

</div><p>Eine handgeschriebene Version des Codes, den der Compiler für <code>LazyCell</code> generiert sieht in etwa so aus:</p><div>

```src src-scala
final class LazyCell {
  @volatile var bitmap_0: Boolean = false                   // (1)
  var value_0: Int = _                                      // (2)
  private def value_lzycompute(): Int = {
    this.synchronized {                                     // (3)
      if (!bitmap_0) {                                      // (4)
        value_0 = 42                                        // (5)
        bitmap_0 = true
      }
    }
    value_0
  }
  def value = if (bitmap_0) value_0 else value_lzycompute() // (6)
}

```

</div><p>In <code>(3)</code> sehen wir die Verwendung eines Monitors via <code>this.synchronized {...}</code> um zu garantieren, dass die Auswertung auch bei der Verwendung durch mehrere Threads nur einmal stattfindet. Der Compiler verwendetet eine Booleschen Variable (<code>(1)</code>) um den Initialisierungsstatus (<code>(4)</code> & <code>(6)</code>) der Variablen <code>value_0</code> (<code>(2)</code>) zu verwalten. Diese speichert das finale Ergebnis der Auswertung und wird nach der initialen Auswertung gesetzt (<code>(5)</code>).</p><p>In der obigen Implementierung wird außerdem deutlich, dass ein <code>lazy val</code> – anders als ein normales <code>val</code> – bei <b>jedem</b> Zugriff zuerst den Status des Booleschen Flags überprüft (<code>(6)</code>). Das sollte man auf jeden Fall im Hinterkopf behalten, bevor man (versucht) <code>lazy val</code> als kostenlose Optimierung zu verwenden.</p><p>Nun da wir ein besseres Verständnis der zugrunde liegenden Mechanismen des <code>lazy</code> Keywords haben, können wir einen Blick auf eine Handvoll Szenarios werfen, bei denen es interessant wird.</p></div></div><div><h2>Szenario 1: Nebenläufige Initialisierung von mehreren unabhängigen vals geschieht sequenziell</h2><div><p>Um dieses Szenario zu verstehen ist es wichtig die oben erwähnte Verwendung von <code>this.synchronized { }</code> im Hinterkopf zu haben. Durch diese Zeile bedingen wir, dass wir ein exklusives Lock der momentane Instanz haben. Werden mehrere <code>lazy val</code> in der gleichen Instanz (z.B. in einem <code>object</code>) definiert, so führt der Zugriff auf <b>eine</b> der <code>lazy val</code> innerhalb der Instanz dazu, dass <b>alle</b> Threads warten müssen. Das ist auch der Fall, wenn diese auf unterschiedliche <code>lazy val</code> zugreifen.</p><p>Das folgende Codebeispiel demonstriert genau das: es werden zwei <code>lazy val</code> (<code>(1)</code> & <code>(2)</code>) innerhalb des <code>ValStore</code> <code>object</code>. Im <code>object</code> <code>Scenario1</code> greifen wir nun auf beide <code>val</code> innerhalb eines <code>Future</code> (also separater Thread) zu. Zur Laufzeit wird der Zugriff auf die beiden <code>lazy val</code> aber sequenziell stattfinden. Im konkreten Fall, in dem die Berechnung der <code>lazy val</code> einige Zeit dauert, ist das besonders unerfreulich.</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

def fib(n: Int): Int = n match {
  case x if x < 0 =>
    throw new IllegalArgumentException(
      "Only positive numbers allowed")
  case 0 | 1 => 1
  case _ => fib(n-2) + fib(n-1)
}

object ValStore {
  lazy val fortyFive = fib(45)                   // (1)
  lazy val fortySix  = fib(46)                   // (2)
}

object Scenario1 {
  def run = {
    val result = Future.sequence(Seq(            // (3)
      Future {
        ValStore.fortyFive
        println("done (45)")
      },
      Future {
        ValStore.fortySix
        println("done (46)")
      }
    ))
    Await.result(result, 1.minute)
  }
}

```

</div><p>Das Szenario kann sehr einfach in der Scala REPL getestet werden. Dazu den obigen Code kopieren und per <code>:paste</code> in der REPL wieder einfügen und per Aufruf von <code>Scenario1.run</code> starten. Wenn alles funktioniert wird zuerst die Auswertung von <code>ValStore.fortyFive</code> stattfinden, dann der Text „done (45)“ und erst danach die Auswertung von <code>ValStore.fortySix</code>, natürlich ist auch die umgekehrte Reihenfolge möglich.</p></div></div><div><h2>Szenario 2: Gefahr des Deadlocks bei Zugriff auf lazy vals</h2><div><p>Im vorigen Szenario litten wir „nur“ unter unerwarteten Performance Problemen, falls mehrere <code>lazy val</code> innerhalb einer Instanz definiert sind und durch mehrere Threads Zugriff erfolgt. Im folgenden Szenario sind die Konsequenzen etwas problematischer:</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

object A {
  lazy val base = 42
  lazy val start = B.step
}

object B {
  lazy val step = A.base
}

object Scenario2 {
  def run = {
    val result = Future.sequence(Seq(
      Future { A.start },                        // (1)
      Future { B.step }                          // (2)
    ))
    Await.result(result, 1.minute)
  }
}

```

</div><p>Wir definieren drei <code>lazy val</code> in zwei verschieden <code>object</code> <code>A</code> und <code>B</code>. Die Abhängigkeiten unter den <code>lazy val</code> sind hier noch mal visualisiert:</p><div><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RBOO6bxgTpKTmAq6Hv8b"><img width="417" height="204" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RBOO6bxgTpKTmAq6Hv8b" alt="dep" /></a> </p></div><p>Der Wert von <code>A.start</code> ist abhängig von <code>B.step</code>, welcher von <code>A.base</code> abhängt. Wichtig: hier ist keine <b>zyklische</b> Beziehung vorhanden ist, trotzdem führt die Ausführung des obigen Szenarios via Scala REPL zu einem Deadlock (sollte es zufällig beim ersten Mal funktionieren, einfach noch einmal probieren):</p>

```example
scala> :paste
...
scala> Scenario2.run
java.util.concurrent.TimeoutException: Futures timed out after [1 minute]
  at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
  at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)
  at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)
  at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
  at scala.concurrent.Await$.result(package.scala:190)
  ... 35 elided

```

<p>Was passiert hier? Wir haben einen Deadlock, weil die beiden <code>Future</code> in <code>(1)</code> und <code>(2)</code> beim Zugriff auf <code>A</code> bzw. <code>B</code> wieder den exklusiven Zugriff haben durch Verwendung des Monitors. Damit die Ausführung fortgesetzt werden kann, braucht der Thread der exklusiven Zugriff auf <code>A</code> hat, auch Zugriff auf <code>B</code> wegen <code>B.step</code>. Der andere Thread dagegen hat exklusiven Zugriff auf <code>B</code>, braucht aber <code>A.base</code>. Wir haben also einen Deadlock. Im obigen Szenario ist die Situation recht leicht erkennbar, aber bei komplexeren Szenarien ist es ungleich schwerer auf die Ursache zu kommen. Die gleiche Situation kann auch bei Verwendung von <code>class</code> entstehen, obwohl es schwerer ist eine Situation wie die obige zu konstruieren. Im Allgemeinen sollte man aber auch erwähnen, dass die Deadlock Situation recht unwahrscheinlich ist, da es recht exaktes Timing beim gleichzeitigen Zugriff voraussetzt. Umso schwieriger ist es aber auch dieses Szenario zu reproduzieren, falls man es (gelegentlich) im Betrieb feststellt.</p></div></div><div><h2>Szenario 3: Deadlock in Kombination mit Synchronisierung</h2><div><p>Durch die Verwendung eines Monitors bei der Initialisierung von <code>lazy val</code> gibt es aber neben dem Problem aus Szenario 2 noch mehr Fälle, in denen es zu Problemen kommen kann. Zum Beispiel im folgenden Code:</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

trait Compute {
  def compute: Future[Int] =
    Future(this.synchronized { 21 + 21 })        // (1)
}

object Scenario3 extends Compute {
  def run: Unit = {
    lazy val someVal: Int =
      Await.result(compute, 1.minute)            // (2)
    println(someVal)
  }
}

```

</div><p>Ausführung in der Scala REPL führt zu folgendem Ergebnis:</p>

```example
scala> :paste
...
scala> Scenario3.run
java.util.concurrent.TimeoutException: Futures timed out after [1 minute]
  at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
  at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)
  at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)
  at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
  at scala.concurrent.Await$.result(package.scala:190)
  at Scenario3$.someVal$lzycompute$1(<console>:62)
  at Scenario3$.someVal$1(<console>:62)
  at Scenario3$.run(<console>:63)
  ... 33 elided

```

<p>Der <code>Compute</code> trait allein betrachtet ist zunächst harmlos, allerdings verwendet er einen Monitor via <code>synchronized</code> in <code>(1)</code>. Kombiniert man <code>Compute</code> mit <code>lazy val</code> befindet man sich in einer Deadlock Situation. Der Zugriff auf <code>someVal</code> (<code>(2)</code>) im <code>println(someVal)</code> erzwingt die Auswertung des <code>lazy val</code>, was dazu führt, dass der momentane Thread exklusiven Zugriff auf das <code>Scenario3</code> <code>object</code> bekommt. Beim Auswerten des Ausdrucks für <code>someVal</code> versucht die Methode <code>compute</code> ebenfalls exklusiven Zugriff zu bekommen – erneut befinden wir uns in einer Deadlock Situation.</p></div></div><div><h2>Zusammenfassug</h2><div><p>In den verschieden Szenarien wurden <code>Future</code> und <code>synchronized</code> als Beispiel benutzt. Wichtig ist aber, dass die Probleme unabhängig sind von den zwei konkret genutzten Arten Threads zu starten (<code>Future</code>) und Zugriffe zu synchronisieren (<code>synchronized</code>).</p><p>In diesem Artikel haben wir einen Blick hinter die Kulissen der <code>scalac</code> Implementierung von Scala’s <code>lazy val</code> geworfen und einige überraschende Szenarien genauer betrachtet:</p><ul><li>sequenzielle Initialisierung aufgrund der internen Verwendung<br /> eines Monitors</li><li>Deadlock während des nebenläufigen Zugriffs auf <code>lazy vals</code></li><li>Deadlock in Kombination mit anderen Synchronisierungsmitteln</li></ul><p>Wie man sehen kann, ist <code>lazy</code> <b>keine</b> kostenlose Optimierung, welche man ohne weiteres Betrachten des konkreten Falles einfach anwenden kann. Im Gegenteil, vermutlich würde es bei vielen der <code>lazy val</code> mehr Sinn machen sie durch normale <code>val</code> oder <code>def</code> zu ersetzen. Die gute Nachricht ist, dass die <a href="https://github.com/lampepfl/dotty/wiki/Getting-Started">Dotty</a>  Plattform bereits eine alternative Implementierung für die Initialisierung von <code>lazy val</code> verwendet (von Dmitry Petrashko), welche <b>nicht</b> die oben erwähnten Probleme hat. Für mehr Informationen über Dotty sind in den Referenzen Links zu Dmitry’s Talk und die GitHub von Dotty zu finden.</p><p><i>Alle Beispiele wurden mit Scala 2.11.7 getestet.</i></p></div><div><h3>Referenzen</h3><div><ul><li><a href="https://www.youtube.com/watch?v=aftdOFuVU1o">Hands-on Dotty</a>  (<a href="https://d-d.me/scalaworld2015/#/">slides</a> ) by Dmitry Petrashko</li><li><a href="http://docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html">SIP-20</a>  – Improved Lazy Vals Initialization</li><li><a href="https://github.com/lampepfl/dotty">Dotty</a>  – The Dotty research platform</li></ul></div></div></div><div><h2>Fußnoten</h2></div><div><div><div><sup><a href="#fnr.1">1</a> </sup>Das ist nicht ganz richtig. Falls bei der ersten Initialisierung eine Exception geworfen, werden darauf folgende Zugriffe erneut versuchen die Initialisierung vorzunehmen.<div></div></div></div></div></div>

Lazy Vals in Scala: Ein Blick hinter die Kulissen

<p>Scala allows the special keyword <code>lazy</code> in front of <code>val</code> in order to change the <code>val</code> to one that is lazily initialized. While lazy initialization seems tempting at first, the concrete implementation of lazy vals in <code>scalac</code> has some subtle issues. This article takes a look under the hood and explains some of the pitfalls: we see how lazy initialization is implemented as well as scenarios, where a lazy val can crash your program, inhibit parallelism or have other unexpected behavior.</p><p><span></span></p><div><div><h2>Introduction</h2><div><p>This post was originally inspired by the talk <a href="https://www.youtube.com/watch?v=aftdOFuVU1o" target="_blank">Hands-on Dotty</a>  (<a href="https://d-d.me/scalaworld2015/#/" target="_blank">slides</a> ) by Dmitry Petrashko, given at Scala World 2015. Dmitry gives a wonderful talk about Dotty and explains some of the lazy val pitfalls as currently present in Scala and how their implementation in Dotty differs. This post is a discussion of lazy vals in general followed by some of the examples shown in Dmitry Petrashko’s talk, as well as some further notes and insights.</p></div></div><div><h2>How <code>lazy</code> works</h2><div><p>The main characteristic of a <code>lazy val</code> is that the bound expression is not evaluated immediately, but <b>once</b> on the first access<sup><a href="#fn.1">1</a> </sup>. When the initial access happens, the expression is evaluated and the result bound to the identifier of the <code>lazy val</code>. On subsequent access, no further evaluation occurs: instead the stored result is returned immediately.</p><p>Given the characteristic above, using the <code>lazy</code> modifier seems like an innocent thing to do, when we are defining a <code>val</code>, why not also add a <code>lazy</code> modifier as a speculative “optimization”? In a moment we will see why this is typically not a good idea, but before we dive into this, let’s recall the semantics of a <code>lazy val</code> first.</p><p>When we assign an expression to a <code>lazy val</code> like this:</p><div>

```src src-scala
lazy val two: Int = 1 + 1

```

</div><p>we expect that the expression <code>1 + 1</code> is bound to <code>two</code>, but the expression is not yet evaluated. On the first (and only on the first) access of <code>two</code> from somewhere else, the stored expression <code>1 + 1</code> is evaluated and the result (<code>2</code> in this case) is returned. On subsequent access of <code>two</code>, <b>no evaluation happens</b>: the stored result of the evaluation was cached and will be returned instead.</p><p>This property of “evaluate <b>once</b>” is a very strong one. Especially if we consider a multithreaded scenario: what should happen if two threads access our <code>lazy val</code> at the same time? Given the property that evaluation occurs only once, we have to introduce some kind of synchronization in order to avoid multiple evaluations of our bound expression. In practice, this means the bound expression will be evaluated by one thread, while the other(s) will have to wait until the evaluation has completed, after which the waiting thread(s) will see the evaluated result.</p><p>How is this mechanism implemented in Scala? Luckily, we can have a look at <a href="http://docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html" target="_blank">SIP-20</a> . The example class <code>LazyCell</code> with a <code>lazy val value</code> is defined as follows:</p><div>

```src src-scala
final class LazyCell {
  lazy val value: Int = 42
}

```

</div><p>A handwritten snippet equivalent to the code the compiler generates for our <code>LazyCell</code> looks like this:</p><div>

```src src-scala
final class LazyCell {
  @volatile var bitmap_0: Boolean = false                   // (1)
  var value_0: Int = _                                      // (2)
  private def value_lzycompute(): Int = {
    this.synchronized {                                     // (3)
      if (!bitmap_0) {                                      // (4)
        value_0 = 42                                        // (5)
        bitmap_0 = true
      }
    }
    value_0
  }
  def value = if (bitmap_0) value_0 else value_lzycompute() // (6)
}

```

</div><p>At <code>(3)</code> we can see the use of a monitor <code>this.synchronized {...}</code> in order to guarantee that initialization happens only once, even in a multithreaded scenario. The compiler uses a simple flag (<code>(1)</code>) to track the initialization status (<code>(4)</code> & <code>(6)</code>) of the var <code>value_0</code> (<code>(2)</code>) which holds the actual value and is mutated on first initialization (<code>(5)</code>).</p><p>What we can also see in the above implementation is that a <code>lazy val</code>, other than a regular <code>val</code> has to pay the cost of checking the initialization state on <b>each</b> access (<code>(6)</code>). Keep this in mind when you are tempted to (try to) use <code>lazy val</code> as an “optimization”.</p><p>Now that we have a better understanding of the underlying mechanisms for the <code>lazy</code> modifier, let’s look at some scenarios where things get interesting.</p></div></div><div><h2>Scenario 1: Concurrent initialization of multiple independent vals is sequential</h2><div><p>Remember the use of <code>this.synchronized { }</code> above? This means we lock the whole instance during initialization. Furthermore, multiple <code>lazy vals</code> defined inside e.g., an <code>object</code>, but accessed concurrently from multiple threads will still all get initialized <b>sequentially</b>. The code snippet below demonstrates this, defining two <code>lazy val</code> (<code>(1)</code> & <code>(2)</code>) inside the <code>ValStore</code> object. In the object <code>Scenario1</code> we request both of them inside a <code>Future</code> (<code>(3)</code>), but at runtime each of the <code>lazy val</code> is calculated separately. This means we have to wait for the initialization of <code>ValStore.fortyFive</code> until we can continue with <code>ValStore.fortySix</code>.</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

def fib(n: Int): Int = n match {
  case x if x < 0 =>
    throw new IllegalArgumentException(
      "Only positive numbers allowed")
  case 0 | 1 => 1
  case _ => fib(n-2) + fib(n-1)
}

object ValStore {
  lazy val fortyFive = fib(45)                   // (1)
  lazy val fortySix  = fib(46)                   // (2)
}

object Scenario1 {
  def run = {
    val result = Future.sequence(Seq(            // (3)
      Future {
        ValStore.fortyFive
        println("done (45)")
      },
      Future {
        ValStore.fortySix
        println("done (46)")
      }
    ))
    Await.result(result, 1.minute)
  }
}

```

</div><p>You can test this by copying the above snippet and <code>:paste</code>-ing it into a Scala REPL and starting it with <code>Scenario1.run</code>. You will then be able to see how it firsts evaluates <code>ValStore.fortyFive</code>, then prints the text and afterwards does the same for the second <code>lazy val</code>. Instead of an <code>object</code> you can also imagine this case for a normal <code>class</code>, having multiple <code>lazy vals</code> defined.</p></div></div><div><h2>Scenario 2: Potential dead lock when accessing lazy vals</h2><div><p>In the previous scenario, we only had to suffer from decreased performance, when multiple <code>lazy vals</code> inside an instance are accessed from multiple threads at the same time. This may be surprising, but it is not a deal breaker. The following scenario is more severe:</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

object A {
  lazy val base = 42
  lazy val start = B.step
}

object B {
  lazy val step = A.base
}

object Scenario2 {
  def run = {
    val result = Future.sequence(Seq(
      Future { A.start },                        // (1)
      Future { B.step }                          // (2)
    ))
    Await.result(result, 1.minute)
  }
}

```

</div><p>Here we define three <code>lazy val</code> in two objects <code>A</code> and <code>B</code>. Here is a picture of the resulting dependencies:</p><div><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RBOO6bxgTpKTmAq6Hv8b"><img width="417" height="204" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RBOO6bxgTpKTmAq6Hv8b" alt="Dependencies" /></a> </p></div><p>The <code>A.start</code> val depends on <code>B.step</code> which in turn depends again on <code>A.base</code>. Although there is no cyclic relation here, running this code can lead to a <b>deadlock</b>:</p>

```example
scala> :paste
...
scala> Scenario2.run
java.util.concurrent.TimeoutException: Futures timed out after [1 minute]
  at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
  at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)
  at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)
  at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
  at scala.concurrent.Await$.result(package.scala:190)
  ... 35 elided

```

<p>(if it succeeds by chance on your first try, give it another chance). So what is happening here? The deadlock occurs, because the two <code>Future</code> in <code>(1)</code> and <code>(2)</code>, when trying to access the <code>lazy val</code> will both lock the respective object <code>A</code> / <code>B</code>, thereby denying any other thread access. In order to achieve progress however, the thread accessing <code>A</code> also needs <code>B.step</code> and the thread accessing <code>B</code> needs to access <code>A.base</code>. This is a deadlock situation. While this is a fairly simple scenario, imagine a more complex one, where more objects/classes are involved and you can see why overusing <code>lazy val</code> can get you in trouble. As in the previous scenario the same can occur inside <code>class</code>, although it is a little harder to construct the situation. In general this situation is unlikely to happen, because of the exact timing required to trigger the deadlock, but it is equally hard to reproduce in case you encounter it.</p></div></div><div><h2>Scenario 3: Deadlock in combination with synchronization</h2><div><p>Playing with the fact that <code>lazy val</code> initialization uses a monitor (<code>synchronized</code>), there is another scenario, where we can get in serious trouble.</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

trait Compute {
  def compute: Future[Int] =
    Future(this.synchronized { 21 + 21 })        // (1)
}

object Scenario3 extends Compute {
  def run: Unit = {
    lazy val someVal: Int =
      Await.result(compute, 1.minute)            // (2)
    println(someVal)
  }
}

```

</div><p>Again, you can test this for yourself by copying it and doing a <code>:paste</code> inside a Scala REPL:</p>

```example
scala> :paste
...
scala> Scenario3.run
java.util.concurrent.TimeoutException: Futures timed out after [1 minute]
  at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
  at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)
  at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)
  at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
  at scala.concurrent.Await$.result(package.scala:190)
  at Scenario3$.someVal$lzycompute$1(<console>:62)
  at Scenario3$.someVal$1(<console>:62)
  at Scenario3$.run(<console>:63)
  ... 33 elided

```

<p>The <code>Compute</code> trait on it’s own is harmless, but note that it uses <code>synchronized</code> in <code>(1)</code>. In combination with the <code>synchronized</code> initialization of the <code>lazy val</code> inside <code>Scenario3</code> however, we have a deadlock situation. When we try to access the <code>someVal</code> (<code>(2)</code>) for the <code>println</code> call, the triggered evaluation of the <code>lazy val</code> will grab the lock on <code>Scenario3</code>, therefore preventing the <code>compute</code> to also get access: a deadlock situation.</p></div></div><div><h2>Conclusion</h2><div><p>Before we sum this post up, please note that in the examples above we use <code>Future</code> and <code>synchronized</code>, but we can easily get into the same situation by using other concurrency and synchronization primitives as well.</p><p>In summary, we had a look under the hood of Scala’s implementation of lazy vals and discussed some surprising cases:</p><ul><li>sequential initialization due to monitor on instance</li><li>deadlock on concurrent access of <code>lazy vals</code> without cycle</li><li>deadlock in combination with other synchronization constructs</li></ul><p>As you can see, <code>lazy vals</code> should not be used as a speculative optimization without further thought about the implications. Furthermore you might want to replace some of your <code>lazy val</code> with a regular <code>val</code> or <code>def</code> depending on your initialization needs after becoming aware of the issues above.<br /> Luckily, the <a href="https://github.com/lampepfl/dotty/wiki/Getting-Started" target="_blank">Dotty</a>  platform has an alternative implementation for <code>lazy val</code> initialization (by Dmitry Petrashko) which does <b>not</b> suffer from the unexpected pitfalls discussed in this post. For more information on Dotty you can watch Dmitry’s talk linked in the “references” section and head over to their <a href="https://github.com/lampepfl/dotty" target="_blank">github page</a> .</p><p><em>All examples have been tested with Scala 2.11.7.</em></p></div><div><h3>References</h3><div><ul><li><a href="https://www.youtube.com/watch?v=aftdOFuVU1o" target="_blank">Hands-on Dotty</a>  (<a href="https://d-d.me/scalaworld2015/#/" target="_blank">slides</a> ) by Dmitry Petrashko</li><li><a href="http://docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html" target="_blank">SIP-20</a>  – Improved Lazy Vals Initialization</li><li><a href="https://github.com/lampepfl/dotty" target="_blank">Dotty</a>  – The Dotty research platform</li></ul></div></div></div><div><h2>Footnotes:</h2><div><div><sup><a href="#fnr.1">1</a> </sup>This is not completely true, initialization will be tried again in case of exceptions during the first access until the first successful initialization.</div><div></div></div></div><p> </p></div>

Lazy Vals in Scala: A Look Under the Hood

<div><div><div><p>Tired of writing hundreds of unit tests manually? Write <i>properties</i> and let the test cases be generated automatically! We introduce the ScalaCheck library and demonstrate the benefits of property-based testing, an approach that is very different from the traditional unit testing, because we focus on writing general properties instead of specific test cases.</p></div></div></div><p><span></span></p><div><div><div><p>If you want to look at the full code for the post while reading, you can find it at <a href="https://github.com/markus1189/intro-to-scalacheck">github</a> .</p></div></div><div><h2>Property-based Testing</h2><div><p>Writing good tests is an important building block for high software quality. On the developer side however, it is also well-known that writing <i>good</i> tests is extremely hard. As an example, even a basic unit test has to consider the intended use, possible edge cases of the test input, as well as the expected behavior if something goes wrong. This in turn leads to a huge number of individual tests, which make it hard to identify the original property.</p><p>Wouldn’t it be nice to have test cases <i>automatically</i> generated and the results checked if they match the specification? <a href="http://www.scalacheck.org/">ScalaCheck</a>  does exactly this, given a property describing the expected behavior, it will generate random input data, covering many edge cases, and check the result. This form of testing is called <i>property-based testing</i>, originally invented in Haskell in the form of the <a href="https://hackage.haskell.org/package/QuickCheck">QuickCheck</a>  library, which was later ported to Scala and many other languages.</p><p>In this post, we provide an introduction to ScalaCheck and use it to write and test a simple program that checks whether a given input is a palindrome. The purpose of this post is to get a quick overview of the how and why of ScalaCheck, not (yet) a complete overview of available features.</p></div></div><div><h2>Checking Palindromes</h2><div><p>Before we can use ScalaCheck to test our implementation, we obviously first need an implementation. As our toy example, we use a simple problem: checking whether a string is a palindrome.</p><p>For simplicity, we consider only single words (instead of whole sentences or other units) and define a palindrome as:</p>

```example
A given word is a palindrome, iff it reads the same forwards and backwards.

```

<p>Given this definition, we can translate it into Scala code easily:</p><div>

```src src-scala
def checkReverse(s: String): Boolean = s == s.reverse

```

</div><p>This naive implementation is not the most efficient, but it has the advantage of obvious correctness by simplicity. This is a common situation: we have a very simple and naive solution, but we might want to replace it with a better implementation later on, using less memory and/or a faster algorithm. Before we start to develop alternative implementations to check palindromes, let’s have a first look at ScalaCheck.</p></div></div><div><h2>Using ScalaCheck</h2><div><p>Testing with ScalaCheck and using property-based testing in general, consists of two important activities:</p><ol><li>formulating properties that hold for our implementation</li><li>writing generators, creating random test data for which the property has to hold</li></ol><p>ScalaCheck then generates a (configurable) number of test input sets and checks, whether the property holds for all of them. Finding <i>good</i> properties is the point where developer creativity plays a big role, as thinking of tests in form of properties is different from the unit testing mindset. However, in this post we focus on a special case where ScalaCheck can be used without requiring us to find a good set of properties for our implementation: replacing algorithms with alternatives that are better (with regard to an aspect like memory allocation, runtime, etc.).</p><p>Writing a generator for your data is made easy, because ScalaCheck ships with a large number of predefined generators for a lot of standard types, as well as a rich library of combinators. Generators are represented as <code>Gen[+T]</code> which is a generator for values of type <code>T</code>. In order to test our implementation of <code>checkReverse</code> we need to generate palindromes, so let’s start with that.</p><div>

```src src-scala
val palindromeGen: Gen[String] = for {
  base <- arbitrary[String]
  middle <- Gen.option(arbitrary[Char])
} yield base + middle.getOrElse("") + base.reverse

```

</div><p>We have a palindrome generator, where palindromes are normal <code>Strings</code> . <code>Gen</code> implements <code>map</code>, <code>flatMap</code> and friends, which allows us to use Scala’s for comprehensions as syntactic sugar. A palindrome is built from two other generators: <code>base</code> which is the part that is repeated in reversed form at the end (the very definition of a palindrome) and an optional <code>middle</code> of type <code>Char</code> to allow palindromes with an odd number of characters:</p><div><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1k9fs1rQGYUvGrcmfzYA"><img width="550" height="154" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1k9fs1rQGYUvGrcmfzYA" alt="kayak" /></a> </p></div><p><code>Gen.option</code> takes as an argument a generator and returns another generator that may or may not generate a value. In order to provide default generators for types, ScalaCheck uses the <code>Arbitrary</code> type class, which defines the <code>arbitrary</code> method. Using <code>arbitrary</code>, we can make use of an implicitly defined generator for the given type. If we want to have this for our own types, we can do this by writing instances of the <code>Arbitrary</code> class.</p><p>To get an idea of the palindromes generated, we can sample our <code>palindromeGen</code> like this:</p>

```example
scala> palindromeGen.sample
res1: Option[String] = Some(㳺ᢨȕ❓❓ȕᢨ㳺)
scala> palindromeGen.sample
res2: Option[String] =
  Some(⻧᲎ჹ쩄颧㱵댤扛峌甔ᩡ잉ᇐ醢徉⧭༐跍멅跍༐⧭徉醢ᇐ잉ᩡ甔峌扛댤㱵颧쩄ჹ᲎⻧)

```

<p>Not the palindromes you would have come up with in unit tests, right? This is where property-based testing really shines, because when writing unit tests, we have to make dedicated effort in order to come up with test cases that exercise corner cases and abnormal behavior, while here we can lean back and let ScalaCheck come up with them instead. Of course, we could have written our palindrome generator <code>palindromeGen</code> in a way, such that it does not use unicode chars, for example by using <code>Gen.alphaStr</code> or other predefined generators in the companion object for <code>Gen</code>.</p></div></div><div><h2>Testing Our Implementation and Generator</h2><div><p>As a first test, let’s check that our naive palindrome checker from above coincides with our palindrome generator. We do this by writing our very first property:</p><div>

```src src-scala
property("checkReverse coincides with generator") =
  forAll(palindromeGen) { palindrome =>
    checkReverse(palindrome)
  }

```

</div><p>Our new property takes as an argument a description and consists of a check that <code>forAll</code> palindromes generated from our palindrome generator <code>palindromeGen</code>, <code>checkReverse</code> returns true. If we run the tests in sbt, we get:</p>

```example
> test
[info] + Palindrome.checkReverse: OK, passed 100 tests.

```

<p>This means that our property held for all of the randomly generated test inputs. Not unexpected, but good to know in any case.</p></div></div><div><h2>A Better Palindrome Checker</h2><div><p>Our <code>checkReverse</code> method does the job and the nice thing is that the implementation is very simple. As hinted earlier, at some point, though, we might want to exchange the implementation for a better version. One problem of the naive reverse approach is that for every string we check, we need <i>twice</i> the memory to perform the actual equality check. With growing adoption of our palindrome-checking-service however, users want to have larger and larger strings checked for palindromicity, reaching millions of chars in length! When we want to check such a large string, it is unthinkable to just allocate twice the memory, certainly we can do better than that!</p><p>After a quick round on the white board, we come up with an alternative way to check for palindromicity: we keep track of two indices, starting from the very left and the very right of the palindrome. The idea is to then work our way towards the middle, comparing the characters as we go:</p><div><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Yghvb2ljT4mTnTwpegPz"><img loading="lazy" width="700" height="196" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Yghvb2ljT4mTnTwpegPz" alt="racecar" /></a> </p></div><p>We start with an implementation and on the first try, we come up with this:</p><div>

```src src-scala
def checkIndices(s: String): Boolean = {
  @tailrec
  def loop(i: Int, j: Int): Boolean = (i,j) match {
    case (i,j) if i == j => true
    case (i,j) if s(i) != s(j) => false
    case (i,j) if s(i) == s(j) => loop(i+1,j-1)
  }

  loop(0,s.length-1)
}

```

</div><p>To test this, we need a property. As we are pretty sure that <code>checkReverse</code> is a correct implementation, why not use that as reference:</p><div>

```src src-scala
property("checkIndices") = forAll(maybePalindrome) { s =>
  checkReverse(s) == checkIndices(s)
}

```

</div><p>We say that for all strings generated by <code>maybePalindrome</code>, our <code>checkIndices</code> method should return the same result as <code>checkReverse</code>. We define <code>maybePalindrome</code> as:</p><div>

```src src-scala
val maybePalindrome: Gen[String] = Gen.oneOf(palindromeGen,arbitrary[String])

```

</div><p>Note the use the <code>oneOf</code> method from <code>Gen</code> to create a generator that will sometimes produce palindromes and sometimes arbitrary strings. Now let’s test our new palindrome checker:</p>

```example
> test
[info] ! Palindrome.checkIndices: Exception raised on property evaluation.
[info] > ARG_0: ""
[info] > Exception: java.lang.StringIndexOutOfBoundsException:
  String index out of range: 0

```

<p>We forgot about the empty string! Okay that’s easy, let’s fix that and just run the tests again:</p>

```example
> test
[info] ! Palindrome.checkIndices2: Exception raised on property evaluation.
[info] > ARG_0: "꫖꫖"
[info] > Exception: java.lang.StringIndexOutOfBoundsException:
  String index out of range: 2

```

<p>Another error, this time when handling palindromes with an even number of chars. Investigating this, we come to the conclusion, that we forgot to consider what happens when the two indices never meet because they pass each other, due to an even number of chars:</p><div><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/V9hRmrCxS3q07XPwnCtQ"><img loading="lazy" width="450" height="224" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/V9hRmrCxS3q07XPwnCtQ" alt="noon" /></a> </p></div><p>Here in the next step, our current algorithm would continue with <code>i</code> and <code>j</code> in swapped position and then continue both indexes until we run out of chars, leading to the <code>StringIndexOutOfBoundsException</code> from above. To fix this, we add another case to our implementation:</p><div>

```src src-scala
def checkIndices(s: String): Boolean = {
  @tailrec
  def loop(i: Int, j: Int): Boolean = (i,j) match {

    // additional case: check for adjacent indices
    case (i,j) if i+1 == j => s(i) == s(j)

    case (i,j) if i == j => true
    case (i,j) if s(i) != s(j) => false
    case (i,j) if s(i) == s(j) => loop(i+1,j-1)
  }

  // additional check: "" is a palindrome
  s.isEmpty || loop(0,s.length-1)
}

```

</div><p>Feeling lucky, we run our tests again:</p>

```example
> test
[info] + Palindrome.checkReverse: OK, passed 100 tests.
[info] + Palindrome.checkIndices: OK, passed 100 tests.
[info] Passed: Total 2, Failed 0, Errors 0, Passed 2

```

<p>Success! For 100 randomly generated strings, our implementation of <code>checkIndices</code> returned the same result as our reference implementation <code>checkReverse</code>.</p></div></div><div><h2>Conclusion</h2><div><p>Properties do not have to be used exclusively, instead they can be combined with regular unit tests. Sometimes explicit examples in the form of unit tests are still desirable, for documentation purposes. In Scala, most testing frameworks have support for ScalaCheck properties, e.g. <a href="http://www.scalatest.org/">ScalaTest</a>  and <a href="https://etorreborre.github.io/specs2/">specs2</a> , making it easy to combine unit tests and properties.</p><p>This little demo of ScalaCheck only scratches the surface, but gives a brief glimpse of the strength of property-based testing. We wrote only one single property, to check a more complex implementation against a reference. By randomly generating test input we are able to cover a wide range of corner cases, which are easy to miss or cumbersome to enumerate with unit tests. The pattern of using a simple but slow implementation as reference for a better version is only one powerful scenario where property-based testing makes your life as a developer easier.</p><p><i>Exercise for interested readers:</i> Download the code from <a href="https://github.com/markus1189/intro-to-scalacheck">github</a> . Write another version that checks whether a given string is a palindrome. You can use any algorithm you want, alternatively, try to write a recursive version that proceeds by dropping chars from both ends until the check is done. Write a property that compares your implementation with our reference implementation <code>checkReverse</code> and see if you got it right by running the tests.</p><p>You can find more about ScalaCheck on the official <a href="http://www.scalacheck.org/">website</a> , including a <a href="https://github.com/rickynils/scalacheck/wiki/User-Guide">user guide</a>  and the API documentation.</p><p>The code in this post (<a href="https://github.com/markus1189/intro-to-scalacheck">github</a> ) was tested with Scala <code>2.11.7</code> and ScalaCheck <code>1.12.5</code>.</p></div></div></div><p></p><p></p><p> </p>

Introduction to Property-based Testing using ScalaCheck

IT Consultant & Developer

Angular Signals

Ich habe mich gefragt, wie Workload und Infrastruktur-Deployment als eine Einheit betrachtet werden können. Gute Software ist schließlich erst dann wertvoll, wenn sie stabil mit der dazugehörigen Infrastruktur betrieben werden kann. Dabei sollen interne Developer-Plattformen helfen. Bei meiner Suche nach einer Lösung für dieses Problem im Aufbau von Developer-Plattformen bin ich auf den Platform Orchestrator gestoßen.

**Was ist ein Platform Orchestrator?**  
Man kann sich den Platform Orchestrator als einen Rule-Engine vorstellen, die versteht, was die Entwickler\*innen benötigen und es basierend auf den Konfigurationen und Templates, die vom Platform-Team bereitgestellt werden, anbietet. [Humanitecs Platform Orchestrator](https://humanitec.com/products/platform-orchestrator) ist eine solche Regel-Engine. Neben dem SaaS Produkt von Humanitec gibt es noch andere explizite Platform Orchestrator wie z.B. [Kratix](https://www.kratix.io/) oder [KusionStack](https://www.kusionstack.io/zh/). Thoughtworks hat Platform Orchestrator als Tool-Kategorie 2023 in ihr bekanntes [Technologie-Radar](https://www.thoughtworks.com/en-de/radar/techniques/platform-orchestration) aufgenommen. Wie einen Platform Orchestration Layer ebenfalls implementieren kann, erklärt mein Kollege Jonas Hecht in seinem Artikel [Going full GitOps with Crossplane & ArgoCD](/en/knowledge-hub/blog/full-gitops-with-crossplane-and-argocd).

Wir sehen immer wieder, dass sich fast jedes Plattform-Design im Wesentlichen darauf konzentriert, vorgefertigte Git-Repository Templates mit unterschiedlichsten Konfigurationsdateien über ein vermeintliches Developer-Portal bereitzustellen. Danach bleibt es den Entwickler\*innen überlassen, das “Skriptchaos” zu warten. Wenn sie damit überlastet sind, übertragen sie dieses Chaos an die IT-Operations-Teams. Das Ergebnis ist, dass die Entwickler\*innen langsamer werden, auf andere warten müssen und die IT-Operations-Mitarbeitenden sich durch unzählige Tickets kämpfen müssen. Dabei leidet die Time-to-Market, das Lebenselixier jedes Softwareentwicklungsprozesses.

![Developer Platform - Frontend Backend.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/WzcOGA2jSEG9Z8oOKXGt)

Platform Architekturen sollten in Front- und Backend unterteilt werden. Platform Orchestrator bilden den Kern eines solchen Backends. Die Idee ist es, die gesamte Anwendung inklusive ihrer Infrastruktur-Ressourcen \- Datenbanken, Objekt-Storage oder DNS etc. \- bei jedem einzelnen Deployment neu zu konfigurieren. Ein Platform Orchestrator liest im Wesentlichen ein Rezept von Entwickler\*innen und erstellt dynamisch Anwendungs- und Infrastruktur-Konfigurationen bei jedem Deployment. Auf diese Weise gibt es im Deployment keinen Unterschied zwischen dem ersten und dem x-ten Mal. Dieser Ansatz ermöglicht ein hohes Maß an Standardisierung und ermöglicht es den Plattform Engineers, hoch skalierbare sogenannte Golden-Paths zu erstellen, die standardmäßig alle Ressourcen, Konfigurationen und Richtlinien enthalten. Außerdem führt dies zur deutlichen Reduzierung der Anzahl an Konfigurationsdateien.

**Der Platform Orchestrator schafft klare geteilte Verantwortung**  
Der Orchestrator integriert sich in die Pipeline, ist an die Image-Registry und das Secret-Management angebunden und möglicherweise auch an ein Developer-Portal und Service-Katalog \- Post-CI also. Was genau der Orchestrator dort macht, basiert auf den Eingaben von zwei in der Regel unterschiedlichen Benutzergruppen. Die erste Gruppe sind die Entwickler\*innen. Sie wissen am besten, welche Infrastruktur-Ressourcen ihre Workload benötigt, wie diese Ressourcen angebunden werden müssen und möglicherweise auch, wie sie mit anderen Workloads kommunizieren soll. Um dies zu beschreiben, gibt es für jede Workload ein kleines Rezept, die sogenannte Workload-Specification. In diesem Fall ist das [score](https://score.dev/). Wenn die Workload beispielsweise von einer PostgreSQL-Datenbank abhängt, dann wird genau das und nur das in die Workload-Specification eingetragen. Diese Rezepte sind umgebungsagnostisch und um es möglichst einfach zu machen, basieren sie auf der YAML-Syntax und liegen im gleichen Repository wie der Applikations Code selbst.

Wir wissen jetzt, dass die Workload von einer PostgreSQL-Datenbank abhängt. Wir wissen nicht, ob wir diese Workload an eine vorhandene Datenbank anschließen oder eine neue erstellen sollen. Wir wissen auch nicht, wie wir die Konfiguration für das Anwendungs-Deployment erstellen sollen. Wie viel Rechenleistung benötigen wir? Brauchen wir Sidecars, Labels und Annotationen? Welche Security- und Compliance Anforderungen gibt es an diese Infrastruktur Ressourcen? Diese fehlenden Informationen werden vom Platform Team, unserer zweiten Benutzergruppe, bereitgestellt. Das Platform Team hinterlegt im Orchestrator vorher sogenannte [Resource Definitions](https://humanitec.com/marketplace#resource-definitions). Das ist sozusagen der Capability-Katalog, den die Plattform zur Verfügung stellt und an dem sich Entwickler\*innen bedienen können. Über gängige Infrastructure as Code Tools wie Terraform oder Crossplane wird beschrieben, wie in unserem Beispiel Postgres Datenbanken auszusehen haben.

Um den Ablauf jetzt einmal greifbar zu machen, gehen wir ihn Schritt für Schritt einmal durch.  
Im ersten Schritt pushen wir unseren Applikations Code und unser kleines Rezept, die Workload Spezifikation, in unsere CI-Pipeline. Die CI-Pipeline pusht das Image in die Image-Registry und das Rezept an den Platform Orchestrator. Der Orchestrator erhält die Information, dass ein neues Image erstellt wurde, sowie den Pfad zu diesem Image und das Rezept selbst. Daraufhin startet nun das sogenannte RMCD-Execution Pattern. RMCD steht für Read, Match, Create and Deploy. Im Read-Schritt liest der Orchestrator das Rezept und erkennt in unserem Beispiel, dass die Workload von einer Postgres-Datenbank abhängt. Im Match-Schritt versteht er den Kontext, z.B. dass die Bereitstellung für eine Entwicklungsumgebung oder die Produktivumgebung erfolgt. Er findet dann heraus, welche Resource Definitions und Regeln, Ressource Criterias, das Platform Team in dieser Situation anwenden möchte. In der Create-Phase erstellt der Orchestrator die Anwendungskonfigurationen. Dann findet er heraus, ob die Workload an eine vorhandene Ressource angeschlossen werden soll oder ob eine neue erstellt werden muss. Wenn eine neue erstellt werden muss, kann er dies mithilfe der hinterlegten Resource Definition tun. 

Anschließend ruft er die Anmeldeinformationen für die Ressource ab und indiziert sie zur Laufzeit über Secrets in den Container. In der Deploy-Phase wird die Workload bereitgestellt und wir sind fertig. Diesen Prozess wiederholt der Orchestrator bei jeder Bereitstellung. Das hat einen erheblich positiven Einfluss auf die Standardisierung, Benutzerfreundlichkeit und Wartbarkeit der Applikations- und Infrastruktur Ressourcen über ihre gesamte Lebenszeit. 

![humanitec Platform Orchestrator - RMCD Pattern.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/yQ1kYybNRYWFyoszwkQ4)

**Fazit**  
Bei Internal Developer Platforms geht es nicht darum, die initiale Bereitstellung von Services und ihre Infrastruktur Abhängigkeiten durch ein paar Templates oder ein schickes Developer-Portal zu optimieren. Tag fünfhundert, tausend oder zweitausend im Lebenszyklus dieser Komponenten sind die, wo am häufigsten zeitraubende Probleme entstehen. Deswegen liegt da auch der Hebel, um wirklich langfristig mehr Effektivität im Softwareentwicklungsprozess zu schaffen. Durch weniger und einfachere Konfigurationsdateien, klare, geteilte Verantwortlichkeiten zwischen Entwickler\*innen und dem Platform Team, kann die kognitive Last in den Teams reduziert, die Hürden für die Nutzung der Plattform niedrig gehalten und folglich die Adaption der Plattform gefördert werden. Der Humanitec Platform Orchestrator kann für diese Herausforderung eine unterstützende Komponente sein. 

Wenn du dich für den Aufbau interner Entwickler Plattformen oder speziell für den Platform Orchestrator von Humanitec interessierst, schau doch mal [hier](https://www.codecentric.de/leistungen/platform-engineering) vorbei. Dort erklären wir unseren Ansatz für erfolgreiche Plattform Initiativen. 


Der Platform Orchestrator von Humanitec

Plattformen sind heutzutage sehr beliebt. Der Term “Platform” taucht überall auf. Developer Plattformen in [Platform Engineering](https://platformengineering.org/blog/what-is-platform-engineering), [GitLab, die DevSecOps Platform](https://www.codecentric.de/en/services/gitlab-solutions/managed-gitlab), E-Commerce Platform, Cloud Platform, Social Media Platform und so weiter. Aber was macht die Plattform eigentlich zur Plattform und warum wird ihnen so viel Bedeutung zugesprochen? In diesem Artikel geht es darum, was eine Plattform ausmacht und warum Plattformen für die Softwareentwicklung ein strategisch relevantes Thema sind.

Die Idee von Plattformen ist nicht neu. Es gibt viele großartige Beispiele dafür, wie Plattform-Architekturen ganze Branchen transformiert haben. Eine dieser Branchen ist die Automobilindustrie. Autos besitzen eine Menge komplexer Ingenieurarbeit wie Motor, Getriebe, Komponenten zur Einhaltung von Emissionsvorschriften und ABS-Bremsen - all diese Dinge, die Autos effizient und sicher machen, die der Kunde jedoch nicht sieht. Der Kunde sieht die Farbe, das Interieur, wie schön die Türen schließen und wie bequem die Sitze sind. Die Automobilindustrie hat vor vielen Jahrzehnten erkannt, dass sie diese komplexe Ingenieurarbeit einmalig erledigen und dann unterschiedliche Varianten auf dieser Basis Plattform entwickeln kann, um sie an verschiedene Kunden und Zielgruppen zu verkaufen. Dieses Konzept war enorm erfolgreich, weil es die Fertigungstiefe drastisch verringerte. So baut die Volkswagen-Gruppe beispielsweise Modelle vom Audi A3 über Seat Leon oder Škoda Octavia auf derselben MQB Plattform. Das Gleiche wollen wir mit Platform Engineering in der Softwareentwicklung auch erreichen. Wenn wir uns jedoch auf diese Reise begeben, müssen wir verstehen, welche Mechanismen dahinterstecken, die dies ermöglichen.

Die Schlüssel von Plattformen besteht darin, dass sie Standardisierung ermöglichen. Normalerweise assoziieren wir Standards jedoch damit, dass sie Freiheit und Flexibilität einschränken. Der Standard sagt, wie genau etwas zu tun ist, sonst geht es nicht. Ist es gegen den Standard, ist es nicht erlaubt. Aber es gibt einen anderen Typ von Standard, der tatsächlich Innovationen vorantreibt. Einer der wirkungsvollsten Standards, denen wir jeden Tag begegnen, ist HTTP. Damit kann jeder Browser eine Verbindung zu jedem Webserver herstellen und wir sehen eine Webseite. Dieser Standard hat tatsächlich Innovationen stark vorangetrieben. Wir können uns die Welt ohne diesen Standard nicht mehr vorstellen. Ein anderes Beispiel wäre der DIN-A4 Standard. Niemand kann sagen, dass er nicht kreativ sein kann, weil ihm die A4-Papiergröße vorgegeben wird. Das A4-Format ist standardisiert: 297 mal 210 Millimeter. Trotzdem hemmt das nicht die Kreativität - ganz im Gegenteil. Niemand muss darüber streiten, wie groß ein Leitz Ordner oder der Umschlag für das Papier sein sollen. Das Festlegen bestimmter Standards und das Einigen auf bestimmte Rahmenbedingungen kann tatsächlich Innovation und Kreativität fördern. Genau das ist das Ziel hinter Plattformen.

> Plattformen sind eine Möglichkeit, Expertise zu zentralisieren. Aber Innovationen zentralisiert du nicht - das überlässt du den Teams, die am nächsten am Kunden sind. Sie werden auf der Plattform aufbauen. - Peter Buhrmann von Thoughtworks

Standardisierung ist also ein bewährtes Mittel, um die Fertigungstiefe zu reduzieren – und damit die Effizienz in der Entwicklung digitaler Produkte zu steigern. Doch bleibt dabei oft eine zentrale Frage unbeachtet: Was ist mit der Effektivität?

Wir können zwar sehr effizient arbeiten – aber wenn wir die falschen Dinge effizient umsetzen, bleiben sie weiterhin falsch. Mehr Effizienz allein verkürzt weder die Time-to-Market noch führt sie automatisch zu einem positiven Return on Investment (ROI). Gerade bei Entwickler Plattformen ist der ROI kein kurzfristiges Ziel. Ihr Aufbau ist eine langfristige und strategische Investition. Umso wichtiger ist es, die echten [Potenziale im Softwareentwicklungsprozess](https://www.codecentric.de/leistungen/platform-engineering) zu erkennen: team- und abteilungsübergreifend ein gemeinsames Problembewusstsein zu schaffen, klar zu priorisieren – und erst dann in die Lösungsfindung einzusteigen. Andernfalls entstehen Standards, die nicht fördern, sondern blockieren: Sie hemmen Kreativität, erhöhen die kognitive Belastung in den Teams – und führen letztlich eben nicht zu dem Effekt, den Plattformen eigentlich erzeugen sollen.


Vorgaben oder Freiheit? Spannungsfeld Platform Engineering

Service Lead Platform Engineering

Stream Processing mit Kafka Streams und Spring Boot

<p>Hyperledger Fabric ist eine hervorragende DLT-Plattform und bietet großartige Anpassungsmöglichkeiten. Eine Möglichkeit davon ist es, verschiedene Datenbanken zur Speicherung von <a href="/leistungen">Blockchain</a> -Daten zu nutzen. Die empfohlene und am besten unterstützte Option ist die Verwendung einer CouchDB. Sie erlaubt es komplexe Abfragen auf Blockchain-Daten durch Hyperledger Fabric Chaincode mittels verschiedener Programmiersprachen, wie etwa go, JavaScript oder Java, durchzuführen. Um mehr über Hyperledger in Kombination mit CouchDB zu erfahren, werfe einen Blick in die <a href="https://hyperledger-fabric.readthedocs.io/en/release-1.4/couchdb_tutorial.html">offizielle Dokumentation</a> .</p><p><span>Im Bild unten findet man eine CouchDB-Übersicht anhand eines Hyperledger-Fabric-Knotens mit dem Channel „compactionchannel“ und dem Chaincode „cdbc“. Dies ist nur ein Beispiel, um die CouchDB-Struktur zu demonstrieren und enthält noch nicht viele Daten.</span><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/U9K64D7cRDCHs2s9yICr"><img title src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/U9K64D7cRDCHs2s9yICr" alt="CouchDb Übersicht mit Hyperledger" width="700" height="162" /></a> </p><p><span>Blockchains wie Hyperledger speichern Daten auf unbestimmte Zeit und somit wächst die Gesamtmenge der Daten kontinuierlich an. Um die genannten komplexen Abfragen zu ermöglichen, wird der aktuelle „world state“ in CouchDB abgelegt. Wenn sich Daten ändern, ändert sich auch der entsprechende „world state“. CouchDB fügt den neuen Wert nur an seine interne Repräsentation an und entfernt den alten Wert zunächst nicht. Normalerweise würde die automatische Compaction unbenutzte Daten kontinuierlich entfernen und die Größe der Datenbank klein halten.</span></p><p><span>Unter Umständen startet die automatische Compaction nicht, solch eine Situation haben wir bei einem unserer Kunden festgestellt. Dies führte zu einem kontinuierlichen Wachstum der Datenbank und zu Unmengen unnötiger GBs an Speicherplatz. In diesem Fall hast du nun zwei Möglichkeiten: Du kannst die Compaction neu konfigurieren oder manuell starten.</span></p><h2>Status der Hyperledger CouchDB Compaction</h2><p><span>Mit dem folgenden Befehl kannst du den Compaction Status abfragen:</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" http://<CouchDB>:5984/_node/nonode@nohost/_config

{
  ...
  "compactions": {
    "_default": "[{db_fragmentation, \"30%\"}, {view_fragmentation, \"30%\"}]"
  },
  "compaction_daemon": {
    "check_interval": "300",
    "min_file_size": "256000"
  }
}

```

<h3>Manuelle Compaction</h3><p><span>Du kannst die manuelle Compaction folgendermaßen anstoßen:</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" -X POST http://<CouchDB>:5984/<channel-name>_<chaincode>/_compact

{"ok":true}

```

<p><span>Um den Status des Prozesses zu überprüfen:</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic_Auth>" http://<CouchDB>:5984/<channel-name>_<chaincode>

{
  ...
  "compaction_running": true,
  ...
}

```

<p><span>Darüber hinaus können nicht nur die Datenbank, sondern auch CouchDB Views komprimiert werden. Dazu kann folgender REST-Aufruf verwendet werden:</span></p>

```
curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" -X POST http://<CouchDB>:5984/<channel-name>_<chaincode>/_compact/<view-name>

{"ok":true}

```

<p><span>Abhängig von der Größe der Hyperledger-Fabric-Datenbank oder der Views kann die Compaction einige Zeit in Anspruch nehmen.</span></p><p><span>Weitere Informationen über Compaction sind in der </span><a href="https://docs.couchdb.org/en/stable/maintenance/compaction.html"><span>offiziellen Dokumentation</span></a>  von CouchDB <span>zu finden.</span><br /> <strong>Tipp: Auf unsere Website haben wir umfassende Informationen zusammengestellt, wie wir dir dabei helfen können, das Thema Blockchain und Ledger-Technoligie im eigenen Kontext einzusetzen. <a href="https://hubs.ly/H0mxqSd0" target="_blank">Alle Angebote zu Blockchain</a> .</strong></p>

Hyperledger Fabric CouchDB lässt meine Cloud-Rechnung explodieren

> Vorab: Dieser Artikel richtet sich gezielt an Teams, die an der Modernisierung und Weiterentwicklung von bestehenden Systemen arbeiten und nicht an Projekte auf der sprichwörtlichen grünen Wiese, wo völlig andere Gesetze gelten.

Jeder spricht über den massiven Produktivitäts-Boost durch Künstliche Intelligenz in der Softwareentwicklung. Tools wie GitHub Copilot und andere AI-Assistenten versprechen, dass wir Features in einem Bruchteil der bisherigen Zeit implementieren können. Und tatsächlich ist die Generierung von Code rasant geworden.

Doch werfen wir einen Blick in die Realität bestehender Softwareprojekte und eingespielter Teams, zeigt sich oft ein anderes Bild. Die Entwickler sind zwar schneller, aber der Business Value kommt beim Endkunden nicht zügiger an. Woran liegt das? Wir erliegen einer AI-Speed-Illusion. Wir haben vergessen, dass Code schreiben nur ein Teil der Gleichung ist.

Natürlich hat die Softwareentwicklung unzählige Variablen. Für die Liefergeschwindigkeit sind jedoch im Kern vier Sektoren entscheidend: Anforderungen, Development, Qualitätssicherung (QA) und Auslieferung. Ein isolierter Speed-Boost in nur einem dieser Bereiche macht das Gesamtsystem nicht schneller. 

Oft staut es sich bereits ganz vorne, wenn geklärte Vorgaben nur als kleines Rinnsal in die Entwicklung tröpfeln. Doch selbst wenn die Anforderungen fließen und die AI daraus in Rekordzeit einen Code-Tsunami erzeugt, wartet vor der Auslieferung das nächste Nadelöhr. Auf genau diesen Teil der Gleichung wollen wir uns hier fokussieren: die QA.

### Das Jahrzehnt des Gleichgewichts

Um das Problem zu verstehen, müssen wir uns ansehen, wie bestehende Teams abseits der grünen Wiese arbeiten. Viele dieser Projekte funktionieren seit Jahren oder gar Jahrzehnten gut. Über die Zeit hat sich in diesen Teams ein natürliches Gleichgewicht etabliert: eine eingependelte Geschwindigkeit über alle vier Sektoren hinweg – von der Anforderung bis zur Auslieferung.

Entwickler schrieben Code in einem bestimmten Tempo. Die Test-Infrastruktur sowie die oft manuellen Instanzen der QA waren exakt darauf ausgerichtet, diesen Output zeitnah zu validieren. Es war ein Rhythmus, der funktionierte. Development-Speed und die Abnahme durch die QA befanden sich in einer perfekten Balance.

### Der Tsunami und die Staumauer

Und dann kam die AI.

Innerhalb kürzester Zeit hat sich die Geschwindigkeit, mit der Code produziert wird, vervielfacht. (Wie extrem diese Geschwindigkeit auf der grünen Wiese aussehen kann, zeigt unser Experiment: [Ein kompletter PoC in 5 Minuten mit AI-Assisted Coding](https://www.codecentric.de/wissens-hub/blog/poc-in-5-min-mit-ai-assisted-coding-und-spec-driven-development)). 
Das historische Gleichgewicht wurde förmlich weggespült. Die Entwicklung erzeugt nun einen regelrechten Code-Tsunami.

Das Problem bei bestehenden Teams ist, dass die Prozesse, die Test-Infrastruktur und die Menschen in der Abnahme geblieben sind, wie sie waren. Der Tsunami trifft ungebremst auf die bestehende QA-Staumauer. Wenn Test-Runs für ein Feature Stunden dauern oder es weiterhin manuelle Instanzen in Form von QA-Testern gibt, staut sich der Code. Die Features sind zwar Code Complete, aber nicht in Produktion. Der tatsächliche Mehrwert für das Business steigt nicht. Er verharrt im Flaschenhals der Abnahme.

Wichtig zu verstehen: Das ist kein Versagen der QA! Es ist schlichtweg ein System, das für eine völlig andere Geschwindigkeit und für Projektsituationen der Vergangenheit optimiert wurde.

### Der Bumerang-Effekt: Warum AI-Code ohne schnelles Feedback zu Instant Legacy Code wird

Dieser Stau vor der QA hat nicht nur Folgen für die Time-to-Market, er schlägt auch unweigerlich auf das Entwicklerteam zurück. Denn irgendwann wird der Code getestet. Wenn dann Fehler gefunden werden, wandert das Ticket zurück zum Entwickler. Das Problem dabei ist, dass dieses Feedback durch den Flaschenhals oft erst Stunden oder Tage später kommt.

Nun könnte man sagen: „Kontextwechsel und Warten auf die QA waren schon immer anstrengend und teuer.“ Das stimmt. Aber wenn ein Bug in von AI generiertem Code gefixed werden muss, kommt eine neue, gefährliche Dimension hinzu: die fehlende mentale Verankerung.

Wenn ein Entwickler ein komplexes Feature komplett selbst tippt, baut er Zeile für Zeile ein tiefes mentales Modell der Logik auf. Fällt dieser Code drei Tage später in der manuellen QA auf, erinnert er sich an seine Gedankengänge. Wenn wir Code jedoch mit Hilfe der AI bauen, wechseln wir oft in die Rolle des Reviewers. Wir akzeptieren Blöcke von Code. Das mentale Modell, das wir dabei aufbauen, ist wesentlich flacher.

Dauert ein Testlauf nun Stunden oder das Feedback der QA Tage und wir müssen einen subtilen Bug fixen, beginnt ein mühsames Reverse-Engineering von Code, den wir streng genommen nie wirklich selbst geschrieben haben. Die kognitive Last ist enorm. Ohne sofortiges Feedback erschaffen wir gewissermaßen Instant Legacy Code – Code, der gerade erst generiert wurde, den aber schon jetzt niemand im Team mehr im Detail versteht. Wir erleben hier Software-Entropie auf Steroiden: Das schleichende Verrotten der Code-Basis und der Aufbau von Komplexität, was früher Monate dauerte, passiert durch AI-generierten Code plötzlich in wenigen Wochen. Schnelles und automatisiertes Feedback in Minuten ist daher der einzige Weg, Fehler zu fangen, solange dieser flache AI-Kontext im Kopf des Entwicklers noch frisch ist.

### Die Testpyramide ist wichtiger denn je: Wann ist eine Test-Suite bereit für AI?

Um wirklich AI Powered Development in Bestandsprojekten betreiben zu können, gibt es nur einen Ausweg. Wir müssen die Testpyramide nicht neu erfinden, aber wir müssen sie ernster nehmen als je zuvor. Die klassische Testpyramide war nie weg, aber im Zeitalter der AI rückt sie vom wichtigen Architekturkonzept zur absoluten Überlebensstrategie auf.

Nur wer ohne Bottleneck arbeiten kann, wird die PS der AI auch auf die Straße bringen. Aber was bedeutet das konkret? Eine Test-Suite ist erst dann wirklich tauglich für AI, wenn sie folgende Kriterien erfüllt:

* **Rasante Basis:** Unit- und Komponententests laufen in unter 5 Minuten durch. Sie sind der erste und wichtigste Filter für von AI generierten Code.
* **Schneller Feature-Zyklus:** Das Feedback auf Ebene der Features kommt spätestens innerhalb eines Entwicklerfensters von unter 30 Minuten.
* **Trustful Test-Suite:** Es reicht nicht, dass der Code kompiliert. Entwickler müssen blind vertrauen können. Ein grüner Testlauf bedeutet, das gesamte Feature und die Applikation funktionieren fehlerfrei. Ohne dieses Vertrauen fordert man als Sicherheitsnetz bei jedem Schritt wieder manuelle Re-tests an.
* **Lesbare Fehlermeldungen:** Fehlermeldungen und Log Messages müssen so eindeutig wie möglich sein und konkrete Hinweise auf den Fehler geben. Ein generisches „End-to-End-Test rot, viel Glück“ hilft weder dem Entwickler noch der AI. Nur wenn die Logs präzise sind, kann die AI beim automatisierten Debuggen echten Mehrwert liefern.

### AI schreibt unsere Tests? Ein Realitätscheck und das TDD-Comeback

Nun könnte man argumentieren: "Dann lassen wir die AI eben auch die Tests schreiben!"

Die Testgenerierung ist zweifellos viel besser geworden. Doch die Praxis in gewachsenen Systemen zeigt, dass die AI umso mehr an ihre Grenzen stößt, je integrativer und komplexer die Abhängigkeiten werden. (Wer genauer wissen will, wo die aktuellen Grenzen der AI-Assistenten im echten Entwickleralltag liegen, dem empfehle ich unseren Artikel [Bugs, Refactoring, Tests: Wo Chatbots beim Coden glänzen und wo sie scheitern](https://www.codecentric.de/wissens-hub/blog/bugs-refactoring-tests-wo-chatbots-beim-coden-glaenzen-und-wo-sie-scheitern)).

Hier offenbart sich ein überraschendes Phänomen: Die Rückkehr zu Test-Driven Development (TDD), allerdings im neuen Gewand der AI. Es ist wesentlich effektiver, vorab gut durchdachte und scharfe Tests zu definieren. Diese Tests geben der AI exakt die Leitplanken, den Business-Kontext und die Edge-Cases vor. Die AI erzeugt aus vorab geschriebenen, starken Tests einen wesentlich besseren Produktivcode, als wenn man sie bittet, für ihren eigenen Produktivcode nachträglich Tests zu erfinden. Die Tests werden zum mächtigsten Prompt, den ein Entwickler haben kann.

Wie gut dieses Prinzip in der Praxis funktioniert und wie man die AI dazu zwingt, sauberen Code gegen harte Testvorgaben zu schreiben, zeigt der hervorragende codecentric Blogbeitrag [Kein Schummeln erlaubt: Isolierte Specification Tests mit Claude Code](https://www.codecentric.de/wissens-hub/blog/kein-schummeln-erlaubt-isolierte-specification-tests-mit-claude-code).

### Tests als lebendiges Gedächtnis und unverzichtbares Fangnetz

Ein weiterer entscheidender und oft übersehener Punkt ist, dass Tests nicht nur reine Qualitätssicherung sind. Sie fungieren als externer Speicher für Kontext, den die AI sonst verschluckt oder schlicht nicht kennt.

Hier zeigt sich auch, warum Regressionstests in der AI-Ära so extrem wichtig sind. Wenn die AI in Zukunft bestehenden Code refactort oder neue Features in ein gewachsenes System integriert, sind umfassende Regressionstests das einzige Fangnetz, das sicherstellt, dass historische, mühsam erarbeitete Funktionen nicht unbemerkt kaputtgehen. Wenn Absprachen oder komplexe Edge-Cases in Acceptance- oder Unit-Tests manifestiert sind, hat die AI auch in Zukunft viel einfacheren Zugriff darauf als auf textuelle Beschreibungen von Edge-Cases, die in irgendeinem Confluence-Wiki verstauben.

Eine große Basis an Test-Code ist also absolut kein Ballast. Sie ist das Langzeitgedächtnis des Systems, eine lebendige und maschinenlesbare Dokumentation sowie ein massiver Kickdown für zukünftiges AI-Development.

### Fazit: Kein Erfolg mit AI ohne Test-Exzellenz

> *"KI in alte Prozesse zu stecken erzeugt nur schneller Stau — das erleben wir bei Kunden jeden Tag. Der eigentliche Hebel liegt nicht in der Code-Generierung, sondern in der Frage, ob die gesamte Delivery-Pipeline mithalten kann. Wer seine Testpyramide und CI/CD nicht auf AI-Geschwindigkeit bringt, verlagert das Problem nur vom Entwickler in die QA. Die Investition in Test-Exzellenz ist keine Kür mehr, sie ist die Eintrittskarte für AI-native Entwicklung."*
> **– Kai Lichtenberg, Geschäftsbereichsleiter bei codecentric**

Wir befinden uns in einer Zeit des Umbruchs. Wer in der Software-Modernisierung von AI profitieren will, darf nicht nur auf die Generierung von Code schauen.

Die Investition in Tools für AI-Development zahlt sich am Ende des Tages nur dann wirklich aus, wenn parallel dazu auch in die Test-Infrastruktur, die CI/CD-Pipelines und die Laufzeiten der Test-Suites investiert wird. Wer seine Testpyramide vernachlässigt, wird nicht schneller. Man verlagert das Problem lediglich und produziert einen Stau vor der Öffnung der QA Staumauer.  
![qa dam.jpeg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmn8rm3un93ex06upm6vde29c)

Es war noch nie so wichtig wie heute, eine exzellente und schnelle Test-Suite zu haben. Sie ist das Fundament, auf dem die Geschwindigkeit der AI überhaupt erst stattfinden kann.

***

**Leseempfehlung zum Weiterdenken:** Wenn die AI uns das Schreiben des Codes abnimmt und wir uns stärker auf Architektur, Tests und Qualitätssicherung fokussieren müssen – was bedeutet das für unsere Jobs? Mehr dazu in unserem Beitrag: [Ersetzt KI die Softwareentwickler?](https://www.codecentric.de/wissens-hub/blog/ersetzt-ki-die-softwareentwickler)


AI Code-Tsunami trifft auf QA-Staumauer: Das Ende der eingependelten Geschwindigkeit

<p><span>Hyperledger Fabric is a nice DLT platform and offers great customization options. One of which is the ability to choose different databases to store blockchain data. The recommended and best supported option is to use a CouchDB. It offers the ability to use complex queries on the blockchain data via Hyperledger Fabric Chaincode via different programming languages like go, JavaScript or Java. To find out more about Hyperledger with CouchDB take a look at the <a href="https://hyperledger-fabric.readthedocs.io/en/release-1.4/couchdb_tutorial.html">offical documentation</a> .</span></p><p><span>In the picture below you can see the CouchDB overview of an example Hyperledger Fabric node with one channel “compactionchannel” and the chaincode “cdbc”. This is just an example to demonstrate the CouchDB structure and doesn’t contain much data.</span><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/U9K64D7cRDCHs2s9yICr"><img title src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/U9K64D7cRDCHs2s9yICr" alt="CouchDb overview for Hyperledger" width="700" height="162" /></a> </p><p><span>Blockchains like Hyperledger store data indefinitely and so the overall amount only increases. To enable the mentioned complex queries the current “world state” is represented in CouchDB. When data changes the corresponding “world state” also changes – CouchDB only appends the new value to its internal representation. Normally the automatic compaction would remove unused data continuously and keep the size of the database small. </span></p><p><span>In some circumstances the automatic compaction will not start. We encountered this situation at one of our customers. This lead to continuous growth of the database and tons of unnecessary GBs of storage. In this case you have two options, reconfigure the automation trigger or start the compaction manually.</span></p><h2>Status of your Hyperledger CouchDB compaction</h2><p><span>You can query your compaction configuration with the following command:</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" http://<CouchDB>:5984/_node/nonode@nohost/_config

{
  ...
  "compactions": {
    "_default": "[{db_fragmentation, \"30%\"}, {view_fragmentation, \"30%\"}]"
  },
  "compaction_daemon": {
    "check_interval": "300",
    "min_file_size": "256000"
  }
}

```

<h3>Manual compaction</h3><p><span>You can start the compaction manually via the following REST command.</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" -X POST http://<CouchDB>:5984/<channel-name>_<chaincode>/_compact

{"ok":true}

```

<p><span>To check the process of compaction:</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic_Auth>" http://<CouchDB>:5984/<channel-name>_<chaincode>

{
  ...
  "compaction_running": true,
  ...
}

```

<p><span>Furthermore not only the database but also views can be compacted. To do so another REST call can be used.</span></p>

```
curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" -X POST http://<CouchDB>:5984/<channel-name>_<chaincode>/_compact/<view-name>

{"ok":true}

```

<p><span>Depending on the size of the Hyperledger Fabric database or view the compaction can take quite some time.</span></p><p>Detailed information about CouchDB compaction can be found in the <a href="https://docs.couchdb.org/en/stable/maintenance/compaction.html">compaction page</a>  of the official documentation. The German version of this post can be found <a href="/wissens-hub/blog/hyperledger-fabric-couchdb-laesst-meine-cloud-rechnung-explodieren">here</a> .</p>

Hyperledger Fabric CouchDB is killing my cloud storage bills

> Note upfront: This article is specifically aimed at teams working on the modernization and further development of existing systems, not at greenfield projects where completely different rules apply.

Everyone is talking about the massive productivity boost from Artificial Intelligence in software development. Tools like GitHub Copilot and other AI assistants promise that we can implement features in a fraction of the time it used to take. And indeed, code generation has become incredibly fast.

But if we look at the reality of existing software projects and established teams, a different picture often emerges. Developers are faster, but the business value doesn't reach the end customer any quicker. Why is that? We are falling prey to an "AI Speed Illusion". We have forgotten that writing code is only one part of the equation.

Of course, software development has countless variables. When looking at delivery speed, however, four sectors are essential: Requirements, Development, Quality Assurance (QA), and Delivery. An isolated speed boost in just one of these areas does not make the overall system faster. 

Often, the bottleneck is right at the beginning, when clarified requirements merely trickle into development like a small stream. But even if the requirements flow and the AI turns this stream into a code tsunami in record time, the next bottleneck awaits right before delivery. In this article, we want to focus on exactly this part of the equation: QA.

### The Decade of Equilibrium

To understand the problem, we need to look at how existing teams work away from the greenfield. Many of these projects have been running smoothly for years or even decades. Over time, a natural equilibrium has established itself within these teams: a balanced velocity across all four sectors – from requirements to delivery.

Developers wrote code at a certain pace. The test infrastructure and the often manual QA instances were perfectly aligned to validate this output in a timely manner. It was a rhythm that worked. Dev speed and QA approval were in a perfect balance.

### The Tsunami and the Dam

And then came AI.

Within a very short time, the speed at which code is produced has multiplied. (Just how extreme this speed can be in a greenfield scenario is shown in our experiment: [A complete PoC in 5 minutes with AI-Assisted Coding](https://www.codecentric.de/wissens-hub/blog/poc-in-5-min-mit-ai-assisted-coding-und-spec-driven-development)). 
The historical equilibrium was literally washed away. Development is now generating a veritable code tsunami.

The problem for existing teams is that the processes, the test infrastructure, and the people in QA have remained exactly the same. The tsunami crashes unhindered against the existing QA dam. If test runs for a feature take hours or if manual testing instances by QA testers still exist, the code piles up. The features might be "Code Complete", but they are not in production. The actual added value for the business does not increase. It remains stuck in the QA bottleneck.

Important to understand: This is not a failure of QA! It is simply a system that was optimized for a completely different speed and for project situations of the past.

### The Boomerang Effect: Why AI Code Without Fast Feedback Becomes Instant Legacy Code

This traffic jam in front of QA doesn't just impact time-to-market; it inevitably hits back at the development team. Because eventually, the code gets tested. And when bugs are found, the ticket wanders back to the developer. The problem here is that, due to the bottleneck, this feedback often arrives hours or days later.

Now, one might say: "Context switching and waiting for QA have always been exhausting and expensive." That's true. But when we have to fix a bug in AI-generated code, a new, dangerous dimension is added: the lack of mental anchoring.

When a developer types out a complex feature entirely on their own, they build a deep mental model of the logic, line by line. If this code fails in manual QA three days later, they remember their train of thought. However, when we build code with the help of AI, we often switch to the role of a reviewer. We accept blocks of code. The mental model we build in the process is significantly shallower.

If a test run now takes hours or QA feedback takes days, and we have to fix a subtle bug, a tedious reverse-engineering process begins for code that, strictly speaking, we never really wrote ourselves. The cognitive load is enormous. Without immediate feedback, we are essentially creating Instant Legacy Code – code that has just been generated, but which no one on the team understands in detail anymore. We are experiencing software entropy on steroids: the creeping decay of the codebase and the build-up of complexity, which used to take months, suddenly happens in a few weeks with AI-generated code. Fast and automated feedback in minutes is therefore the only way to catch bugs while this shallow AI context is still fresh in the developer's mind.

### The Test Pyramid is More Important Than Ever: When is a Test Suite AI-Ready?

To truly practice AI-Powered Development in legacy projects, there is only one way out. We don't have to reinvent the test pyramid, but we have to take it more seriously than ever before. The classic test pyramid never went away, but in the age of AI, it is elevated from an important architectural concept to an absolute survival strategy.

Only those who can work without bottlenecks will be able to translate the AI's horsepower to the road. But what does that mean in concrete terms? A test suite is only truly AI-ready if it meets the following criteria:

* **Blazing Fast Base:** Unit and component tests finish in under 5 minutes. They are the first and most important filter for AI-generated code.
* **Fast Feature Cycle:** Feedback at the feature level arrives within a developer's time slot (under 30 minutes) at the latest.
* **Trustful Test Suite:** It's not enough that "the code compiles". Developers must be able to trust it blindly. A green test run means the entire feature and application work flawlessly. Without this trust, developers will request manual re-tests at every step as a safety net.
* **Readable Error Messages:** Error messages and log messages must be as clear as possible and provide concrete hints about the error. A generic "End-to-End test red, good luck" helps neither the developer nor the AI. The AI can only provide real value in automated debugging if the logs are precise.

### AI Writing Our Tests? A Reality Check and the TDD Comeback

Now one might argue: "Then let's just have the AI write the tests too!"

Test generation has undoubtedly improved a lot. However, practice in grown systems shows that the more integrative and complex the dependencies become, the more the AI reaches its limits. (If you want to know exactly where the current limits of AI assistants lie in everyday development, I recommend our article [Bugs, Refactoring, Tests: Where Chatbots Shine in Coding and Where They Fail](https://www.codecentric.de/wissens-hub/blog/bugs-refactoring-tests-wo-chatbots-beim-coden-glaenzen-und-wo-sie-scheitern)).

Here, a surprising phenomenon reveals itself in practice: The return to Test-Driven Development (TDD), but in the new guise of AI. It is much more effective to define well-thought-out, sharp tests upfront. These tests provide the AI with the exact guardrails, business context, and edge cases it needs. The AI generates significantly better production code from pre-written, strong tests than when asked to invent tests retroactively for its own production code. Tests become the most powerful prompt a developer can have.

How well this principle works in practice and how to force the AI to write clean code against hard test specifications is shown in the excellent codecentric blog post [No Cheating Allowed: Isolated Specification Tests with Claude Code](https://www.codecentric.de/wissens-hub/blog/kein-schummeln-erlaubt-isolierte-specification-tests-mit-claude-code).

### Tests as Living Memory and Indispensable Safety Net

Another crucial and often overlooked point is that tests are not just pure quality assurance. They act as an external memory for context that the AI would otherwise swallow or simply not know.

This also shows why regression tests are so extremely important in the AI era. When the AI refactors existing code or integrates new features into a grown system in the future, comprehensive regression tests are the only safety net ensuring that historically, painstakingly developed functions do not break unnoticed. If agreements or complex edge cases are manifested in acceptance or unit tests, the AI will have much easier access to them in the future than to textual descriptions of edge cases gathering dust in some Confluence wiki.

A large test codebase is therefore absolutely not ballast. It is the long-term memory of the system, a living and machine-readable documentation, and a massive boost for future AI development.

### Conclusion: No AI Success Without Test Excellence

> *"Cramming AI into old processes only creates traffic jams faster — we see this with customers every day. The real leverage doesn't lie in code generation, but in the question of whether the entire delivery pipeline can keep up. If you don't bring your test pyramid and CI/CD up to AI speed, you're merely shifting the problem from the developer to QA. Investing in test excellence is no longer optional; it is the ticket to AI-native development."*
> **– Kai Lichtenberg, Head of Business Unit at codecentric**

We are in a time of upheaval. Anyone who wants to benefit from AI in software modernization must not just look at code generation.

Investing in AI development tools only truly pays off at the end of the day if parallel investments are made in the test infrastructure, CI/CD pipelines, and the execution times of test suites. If you neglect your test pyramid, you won't get faster. You merely shift the problem and produce a traffic jam in front of the dam gates.
![qa dam.jpeg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmn8rm3un93ex06upm6vde29c)

It has never been as important as it is today to have an excellent, fast test suite. It is the foundation upon which AI speed can happen in the first place.

***

**Recommended reading:** If AI takes over writing code and we have to focus more on architecture, tests, and quality assurance – what does that mean for our jobs? Read more in our article: [Will AI Replace Software Developers?](https://www.codecentric.de/wissens-hub/blog/ersetzt-ki-die-softwareentwickler)


AI Code Tsunami Hits the QA Dam: The End of Balanced Velocity

Senior IT-Berater

People Solutions Partnerin Frankfurt

Constanze Thomas, People Solutions Partnerin Frankfurt, codecentric AG

IT consultant (Frontend)

Warum digitale Souveränität mehr als ein Buzzword ist

IT-Consultant & Developer

Office Management

Next Generation: Input Management 3.0 – Zukunftsorientierte Input-Management-Systeme bei großen Organisationen

Sales & Business Development

Frankfurt am Main | 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 Frankfurt

Jetzt für unseren Newsletter anmelden