# Miragon > Wir finden heraus, wo es hakt, bauen die Lösung mit deinem Team und setzen KI dort ein, wo sie echten Unterschied macht. Prozessautomatisierung, die wirkt. ## [Prozesse analysieren, transformieren und mit KI schneller umsetzen.](https://www.miragon.io/) Wir finden heraus, wo es hakt, bauen die Lösung mit deinem Team und setzen KI nur dort ein, wo sie wirklich etwas bringt. Kein Hype, sondern Tempo, das bleibt. [Erstgespräch vereinbaren](/kontakt/) ## Konzerne, Banken, Verwaltungen: Sie vertrauen Miragon die Prozesse an, an denen ihr Geschäft hängt. Von dm bis zur ING: Wir bringen Automatisierung dorthin, wo es wirklich darauf ankommt. Unser Weg ## So arbeiten wir Du steigst dort ein, wo du stehst. Wir begleiten dich so lange, bis dein Team es alleine kann. ### Strategie finden Bevor eine Zeile Code geschrieben wird: Wo steckt das größte Automatisierungspotenzial? Was lohnt sich wirklich? ### PoCs & Leuchtturmprojekte Kein PowerPoint, sondern ein funktionierender Prototyp, den dein Team versteht und weiterentwickeln kann. ### Skills vermitteln Dein Team lernt BPMN, Camunda und Clean Architecture und kann danach ohne uns weiterarbeiten. ### In der Organisation skalieren Vom ersten erfolgreichen Prozess zur unternehmensweiten Plattform, mit Templates, CI/CD und klaren Team-Strukturen. ## Partnerschaften Wir setzen auf starke Partner, die wir aus der Praxis kennen, nicht aus dem Katalog. [ Wir kennen Camunda 7 und 8 bis in die Tiefen der Engine. Du bekommst echte Expertise, keine Folien-Beratung. Website besuchen](https://camunda.com/) [ Deine Camunda-7-Prozesse laufen weiter. Mit CIB Seven sicherst du bestehende Investments und entwickelst sie gezielt weiter. Website besuchen](https://cibseven.org/) [ Wenn du Microservices orchestrieren willst, die wirklich skalieren: Temporal ist unser Stack für entwicklungsnahe, hochperformante Workflows. Website besuchen](https://temporal.io/) [ Mit Process Mining siehst du, was in deinen Prozessen wirklich passiert, nicht was im Handbuch steht. Website besuchen](https://noreja.com/) [ Digitale Transformation braucht mehr als Technologie. Mit ditricon verbinden wir Prozessautomatisierung mit strategischer Organisationsentwicklung. Website besuchen](https://ditricon.de/) [ Wir kennen Camunda 7 und 8 bis in die Tiefen der Engine. Du bekommst echte Expertise, keine Folien-Beratung. Website besuchen](https://camunda.com/) [ Deine Camunda-7-Prozesse laufen weiter. Mit CIB Seven sicherst du bestehende Investments und entwickelst sie gezielt weiter. Website besuchen](https://cibseven.org/) [ Wenn du Microservices orchestrieren willst, die wirklich skalieren: Temporal ist unser Stack für entwicklungsnahe, hochperformante Workflows. Website besuchen](https://temporal.io/) [ Mit Process Mining siehst du, was in deinen Prozessen wirklich passiert, nicht was im Handbuch steht. Website besuchen](https://noreja.com/) [ Digitale Transformation braucht mehr als Technologie. Mit ditricon verbinden wir Prozessautomatisierung mit strategischer Organisationsentwicklung. Website besuchen](https://ditricon.de/) ## Was unsere Kunden sagen Langfristige Partnerschaften, keine einmaligen Projekte. **Miragon liefert mehr als exzellente Softwareentwicklung.** Die Architekten und Entwickler hören genau hin, stellen die richtigen Fragen und zerlegen komplexe Anforderungen in präzise, handhabbare Bausteine. Besonders begeistert hat mich das offene, konstruktive Miteinander. **Maximilian Mack** CTO, pyck **Miragon bringt nicht nur technisches Know-how mit, sondern auch ein tiefes Verständnis für unsere Herausforderungen.** Gemeinsam haben wir eine Plattform aufgebaut, die unsere Systeme sinnvoll miteinander verknüpft. Besonders schätze ich den offenen Austausch und das vertrauensvolle Miteinander. **René Zarwel** Landeshauptstadt München **Großes Vertrauen, offene Kommunikation und Austausch auf Augenhöhe.** Das umfassende Fachwissen und hohe Engagement von Miragon sind entscheidende Faktoren bei der erfolgreichen Entwicklung unseres Lagerverwaltungssystems. **Stefan Futterer** dmTech Insights ## Aktuelle Beiträge Die neuesten Artikel aus unserem Blog: technische Deep Dives, Erfahrungsberichte und Einblicke in unsere Arbeit. [ 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Weiterlesen ](/blog/was-ist-eine-prozessapplikation/) [ 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Weiterlesen ](/blog/ai-bpmn-modelle-visuell-sauber-halten/) [ 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Weiterlesen ](/blog/agent-skills-ai-nischen-domaenen-bpmn/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Aktuelle Beiträge zu BPM und Digitalisierung](https://www.miragon.io/blog/) Insights Neueste Erkenntnisse und Best Practices rund um Prozessautomatisierung und digitale Transformation. ## Alle Beiträge Durchsuche und filtere unsere Insights nach Thema Alle47BPM19Softwareentwicklung16Referenzen7AI3Miragon3Transformation2Prozessautomatisierung1 Alle AutorenAlexander Praschek (6)Andreas Riepl (5)Dominik Horn (20)Lukas Mösle (4)Marco Schäck (7)Martin Berner (1)Thomas Heinrichs (4) [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/)[ AI 04\. Mai 2026 ### Miragon AI: Vom Cockpit zur Konversation Wie wir bei Miragon Prozessautomatisierung neu denken: weg vom isolierten Cockpit, hin zur Konversation als Interface. Warum das MCP und MCP Apps das Fundament dafür bilden. Thomas Heinrichs Solution Architecture Lead ](/blog/miragon-ai-vom-cockpit-zur-konversation/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/)[ Softwareentwicklung 01\. Dez. 2025 ### Leveling up! Wie du die Herausforderung verteilter Transaktionen in Zeebe lösen kannst Ein umfassender Guide zu verteilten Transaktionen in Zeebe: Von Phantom-Instanzen über das Outbox Pattern bis hin zu Idempotenz und SAGA. Marco Schäck Process Development Lead ](/blog/leveling-up-verteilte-transaktionen-zeebe/)[ Softwareentwicklung 24\. Okt. 2025 ### Komplexität navigieren: Von Verwirrung zu Klarheit durch klare Perspektiven Zwei Perspektiven zur Kategorisierung von Komplexität in Softwaresystemen: Wo lebt sie (lokal vs. global) und warum existiert sie (essenziell vs. akzidentell)? Marco Schäck Process Development Lead ](/blog/komplexitaet-navigieren-perspektiven/)[ Transformation 12\. Mai 2025 ### Komplexität meistern – Wie Prozessautomatisierung gelingt Erfahrungen aus einem Jahrzehnt Prozessautomatisierung: Warum Kontext, Teamstrukturen und organisatorische Reife wichtiger sind als Technologie allein. Dominik Horn Co-Founder & Geschäftsführer ](/blog/komplexitaet-meistern-prozessautomatisierung/)[ BPM 27\. März 2025 ### Warum übergreifende BPMN-Prozesse gefährlich für moderne Organisationen sind Zentrale BPMN-Prozesse führen zu organisatorischer Kopplung und behindern Teamautonomie. Warum Choreografie besser ist als Orchestrierung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/uebergreifende-bpmn-prozesse-gefaehrlich/)[ BPM 21\. März 2025 ### Mit bpmn-to-code deine Prozesse & Code in Einklang bringen Wie bpmn-to-code die Lücke zwischen BPMN-Modellen und Implementierung schließt und für konsistente Prozessautomatisierung sorgt. Marco Schäck Process Development Lead ](/blog/bpmn-to-code-prozesse-in-einklang/)[ Transformation 17\. März 2025 ### Wie Wardley Mapping das Not-Invented-Here Syndrom vermeiden kann Wie Wardley Mapping Teams hilft, strategische Entscheidungen über Eigenentwicklung vs. Zukauf zu treffen und das NIH-Syndrom zu überwinden. Dominik Horn Co-Founder & Geschäftsführer ](/blog/wie-wardley-mapping-not-invented-here/)[ BPM 11\. März 2025 ### Camunda 7 vs. 8 – Eine Betrachtung durch die Brille von Team Topologies Die Migration von Camunda 7 zu 8 erfordert neue Teamstrukturen. Eine Analyse durch die Brille von Team Topologies. Dominik Horn Co-Founder & Geschäftsführer ](/blog/camunda-7-vs-8-team-topologies/)[ BPM 10\. März 2025 ### Handlungsspielräume in Prozesslandschaften mit Wardley-Mapping identifizieren Wie Wardley Mapping strategische Klarheit in Prozesslandschaften schafft und Handlungsspielräume aufzeigt. Thomas Heinrichs Solution Architecture Lead ](/blog/wardley-mapping-prozesslandschaften/)[ Softwareentwicklung 27\. Jan. 2025 ### Software Architektur dokumentieren Wie Architecture Decision Records (ADRs) helfen, Architekturentscheidungen nachvollziehbar zu dokumentieren und Wissen im Team zu bewahren. Lukas Mösle Consultant ](/blog/software-architektur-dokumentieren/)[ Softwareentwicklung 08\. Okt. 2024 ### Wie sich komplexe Switch-Case-Strukturen durch Interfaces und Dependency Injection vermeiden lassen Wie man mit Spring Dependency Injection und Java Streams komplexe Switch-Case-Strukturen durch ein modulares Interface-basiertes Design ersetzt. Marco Schäck Process Development Lead ](/blog/switch-case-interfaces-dependency-injection/)[ Referenzen 02\. Jan. 2024 ### Prozessautomatisierung in der Intralogistik bei DM Wie Miragon die Intralogistik-IT von DM modernisiert – mit BPMN, Domain-Driven Design und agiler Softwareentwicklung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/prozessautomatisierung-intralogistik-dm/)[ Referenzen 01\. Jan. 2024 ### Digitale Transformation mit Dimacon Wie Miragon mit der Dimacon-Plattform das Kerngeschäft der Handwerksbranche digital transformiert – eine flexible No-Code SaaS-Lösung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digitale-transformation-dimacon/)[ BPM 19\. Sep. 2023 ### Low-Code und BPMN – Eine Kombination mit Fallstricken? Warum die Kombination von Low-Code und BPMN nicht immer hält, was sie verspricht, und worauf du achten solltest. Dominik Horn Co-Founder & Geschäftsführer ](/blog/low-code-und-bpmn-fallstricke/)[ BPM 29\. Apr. 2023 ### Low-Code-Prozessautomatisierung - Herausforderungen und Lösungsansätze bei der Umsetzung von Projekten Herausforderungen und Lösungsansätze bei der Umsetzung von Low-Code-Projekten zur Prozessautomatisierung - von Dependency Management bis CI/CD. Dominik Horn Co-Founder & Geschäftsführer ](/blog/low-code-prozessautomatisierung-herausforderungen/)[ BPM 21\. Apr. 2023 ### Es gibt keine eierlegende Wollmilchsau Warum es keine fertige Software gibt, die alle Prozesse digitalisiert - und wie BPMN und Prozess-Engines Unternehmen zur digitalen Eigenständigkeit verhelfen. Andreas Riepl Consultant ](/blog/es-gibt-keine-eierlegende-wollmilchsau/)[ Softwareentwicklung 16\. Dez. 2022 ### Was ist ein Monorepo? Ein Überblick über den Monorepo-Ansatz in der Softwareentwicklung - Anwendungsgebiete, Vor- und Nachteile sowie Erfahrungen aus der Praxis. Lukas Mösle Consultant ](/blog/was-ist-ein-monorepo/)[ Miragon 11\. Okt. 2022 ### Mac einrichten leicht gemacht - mit Ansible Wie Ansible die Einrichtung und Wartung von MacBooks automatisiert - von Homebrew-Installation bis zur Verwaltung von Git-Repositories. Lukas Mösle Consultant ](/blog/mac-einrichten-leicht-gemacht-ansible/)[ BPM 04\. Aug. 2022 ### Wiederverwendbare Prozessbausteine Wie wiederverwendbare Prozessbausteine in BPMN die Prozessmodellierung vereinfachen und Low-Code durch klare Schnittstellen ermöglichen. Dominik Horn Co-Founder & Geschäftsführer ](/blog/wiederverwendbare-prozessbausteine/)[ Softwareentwicklung 01\. Juli 2022 ### Component-Tests mit JUnit Eine Teststrategie für Spring-Boot Java-Backends mit JUnit 5, Mockito und H2 - vom Testdiamanten bis zur Datenvalidierung. Andreas Riepl Consultant ](/blog/component-tests-mit-junit/)[ Referenzen 01\. Jan. 2022 ### DigiWF – Landeshauptstadt München Wie Miragon die Landeshauptstadt München bei der Konzeption und Umsetzung einer Plattform zur Digitalisierung und Automatisierung von Workflows unterstützt. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digiwf-landeshauptstadt-muenchen/)[ Softwareentwicklung 22\. Nov. 2021 ### Conditional Testing mit Cypress Wie bedingte Logik in Cypress-Tests die Wiederholbarkeit von Testsequenzen sicherstellt und Abhängigkeiten zwischen Tests vermeidet. Martin Berner Consultant ](/blog/conditional-testing-mit-cypress/)[ Softwareentwicklung 12\. Okt. 2021 ### Generierung von Client APIs mit Swagger Teil 3 Im dritten Teil der Serie integrieren wir den Swagger API-Client in eine React Native App mit Auth0-Authentifizierung und Expo. Andreas Riepl Consultant ](/blog/generierung-client-apis-swagger-teil-3/)[ Softwareentwicklung 10\. Sep. 2021 ### Generierung von Client APIs mit Swagger Teil 2 Im zweiten Teil der Serie sichern wir die Endpoints mit Auth0 und autorisieren die Anfragen des Web-Clients mit OAuth2. Andreas Riepl Consultant ](/blog/generierung-client-apis-swagger-teil-2/)[ Softwareentwicklung 20\. Aug. 2021 ### Generierung von Client APIs mit Swagger Teil 1 Integration von Swagger in Spring Boot, Generierung des TypeScript-Axios API-Clients und Verwendung in einer React-Web-App. Andreas Riepl Consultant ](/blog/generierung-client-apis-swagger-teil-1/)[ Referenzen 30\. Juli 2021 ### Durchführung eines t.BPM-Workshops für die Analyse und Visualisierung von Prozessen in der Baubranche Wie Miragon mit der SSB Fidan GmbH in einem t.BPM-Workshop Bauprozesse von der Beauftragung bis zur Rechnungsstellung analysiert und visualisiert hat. Dominik Horn Co-Founder & Geschäftsführer ](/blog/tbpm-workshop-baubranche/)[ Softwareentwicklung 27\. Juli 2021 ### Docker-Images mit GitHub Actions und Google Cloud bauen Wie man mit GitHub Actions und Google Cloud Build Docker-Images als Teil der CI-Pipeline baut und in die Google Cloud Registry pusht. Alexander Praschek Co-Founder ](/blog/docker-images-github-actions-google-cloud/)[ BPM 22\. Dez. 2020 ### Testabdeckung für Prozesse messen Wie die Testabdeckung bei BPMN-Prozessen gemessen, visualisiert und nachvollziehbar in die CI/CD-Pipeline integriert werden kann. Dominik Horn Co-Founder & Geschäftsführer ](/blog/testabdeckung-prozesse-messen/)[ BPM 07\. Dez. 2020 ### Prozessautomatisierung in der Baubranche Gemeinsam mit Studierenden der Hochschule Augsburg und der SSB Fidan digitalisieren wir Prozesse in der Baubranche - von Leistungsnachweisen bis zur Abrechnung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/prozessautomatisierung-baubranche/)[ BPM 20\. Nov. 2020 ### Prozessabhängigkeiten testen Wie man Prozessabhängigkeiten in BPMN testet - von Abhängigkeiten zu anderen Modellen bis hin zu Quellcode-Referenzen mit camunda-bpm-mockito. Dominik Horn Co-Founder & Geschäftsführer ](/blog/prozessabhaengigkeiten-testen/)[ BPM 27\. Okt. 2020 ### Vollständige Prozesspfade testen Wie man vollständige Prozesspfade in BPMN testet - mit camunda-bpm-assert-scenario für effiziente und klare Testfälle. Dominik Horn Co-Founder & Geschäftsführer ](/blog/vollstaendige-prozesspfade-testen/)[ Referenzen 16\. Okt. 2020 ### Umsetzung einer Redaktionsplattform für die Vorbereitung von Hauptversammlungen Wie wir innerhalb von vier Wochen eine vollständige Redaktionsplattform für die Vorbereitung virtueller Hauptversammlungen implementiert haben. Alexander Praschek Co-Founder ](/blog/redaktionsplattform-hauptversammlungen/)[ Referenzen 16\. Okt. 2020 ### Schulungen und Projekte zu BPM-Themen Miragon unterstützt Vorlesungen und Projekte zu BPM-Themen an der Hochschule Augsburg - von tBPM-Workshops über Camunda bis Process Mining. Dominik Horn Co-Founder & Geschäftsführer ](/blog/schulungen-projekte-bpm-themen/)[ BPM 18\. Sep. 2020 ### Nachvollziehbare Test-Coverage für alle Prozess-Stakeholder FlowCov macht die Testabdeckung von BPMN-Prozessen für alle Stakeholder sichtbar und nachvollziehbar - integriert in die Build-Pipeline. Dominik Horn Co-Founder & Geschäftsführer ](/blog/nachvollziehbare-test-coverage-prozess-stakeholder/)[ Softwareentwicklung 12\. Sep. 2020 ### DevOps mit GitHub - Teil 2: Packages bauen und veröffentlichen mit GitHub Actions Wie man GitHub Actions als Build-Pipeline nutzt, um bei jedem Commit automatisch Gradle-Artefakte zu bauen und in GitHub Packages zu veröffentlichen. Alexander Praschek Co-Founder ](/blog/devops-github-teil-2-packages-actions/)[ BPM 30\. Juni 2020 ### Internationalization Plugin für den Camunda Modeler Mit unserem I18N-Plugin für den Camunda Modeler kann der Modeler auch in anderen Sprachen genutzt werden. Deutsch ist bereits integriert. Alexander Praschek Co-Founder ](/blog/internationalization-plugin-camunda-modeler/)[ BPM 30\. Juni 2020 ### Logistikprozesse mit Camunda automatisieren Wie wir im Rahmen eines Hochschulprojekts einen Logistik-Microservice für die Open Source-Plattform RemedyMatch mit Camunda und Spring Boot umgesetzt haben. Dominik Horn Co-Founder & Geschäftsführer ](/blog/logistikprozesse-camunda-automatisieren/)[ Miragon 08\. Juni 2020 ### Mehr in weniger Zeit - mit den richtigen Tools Welche Tools wir bei Miragon verwenden, um effizient zu arbeiten - von Office 365 und Microsoft Teams bis hin zu GitHub und JetBrains. Alexander Praschek Co-Founder ](/blog/mehr-in-weniger-zeit-richtigen-tools/)[ Referenzen 30\. Mai 2020 ### Open Source-Spendenplattform für dringend benötigte Hilfsgüter in der COVID-19-Krise Wie Miragon die technische Architektur und Entwicklung der RemedyMatch-Plattform zur Verteilung von Hilfsgütern in der Corona-Krise übernommen hat. Dominik Horn Co-Founder & Geschäftsführer ](/blog/open-source-spendenplattform-covid19/)[ Softwareentwicklung 29\. Mai 2020 ### DevOps mit GitHub - Teil 1: GitHub Packages mit Gradle Wie GitHub Packages in Verbindung mit Gradle funktioniert - ein Schritt-für-Schritt-Guide zum Veröffentlichen und Verwenden von Artefakten. Alexander Praschek Co-Founder ](/blog/devops-github-teil-1-packages-gradle/)[ Miragon 27\. Mai 2020 ### Vom Studenten zum Lehrbeauftragten Dominik Horn erzählt seinen Weg vom BPM-begeisterten Studenten über die IT-Beratung zur Gründung der Miragon GmbH und zum Lehrauftrag an der Hochschule Augsburg. Dominik Horn Co-Founder & Geschäftsführer ](/blog/vom-studenten-zum-lehrbeauftragten/) Keine Beiträge gefunden. Versuche einen anderen Suchbegriff oder eine andere Kategorie. Weitere Beiträge werden geladen … Du hast alle **47** Beiträge gesehen. ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird](https://www.miragon.io/blog/agent-skills-ai-nischen-domaenen-bpmn/) AI AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead **18\. Juni 2026**21 Min. Lesezeit AI macht Routine-Coding-Aufgaben immer austauschbarer, und dieser Trend beschleunigt sich. Doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Process Engines wie Zeebe liefern reine Prompts noch immer inkonsistente, oft frustrierende Ergebnisse. Das liegt vor allem daran, dass es kaum Trainingsdaten gibt, die Domäne spezialisiert ist und die Varianz zwischen den Engines hoch ist. Skills könnten die Antwort sein. Statt deine Domäne, deine Konventionen und deine Edge Cases jedes Mal aufs Neue zu erklären, dokumentierst du dieses Wissen einmal—und das Modell greift automatisch darauf zu. Ich habe diesen Ansatz in echten Projekten getestet und bin überzeugt, dass er funktioniert. Dieser Post teilt daher, was ich dabei gelernt habe. Er erklärt, was Skills sind, wie du sie in der BPMN-Prozessorchestrierung einsetzt und welche Vorteile sie bieten. Außerdem geht es darum, welche Guardrails du einsetzen solltest, um die Qualität hoch zu halten und gleichzeitig schneller zu werden. Zum Schluss teile ich die Sammlung an Skills, die ich in echten Projekten gebaut und erprobt habe. ## 🚀 Wird Coding austauschbar? In letzter Zeit habe ich viel darüber gelesen, welchen Einfluss AI auf die Software-Entwicklung hat. Und obwohl ich nicht zu denen gehöre, die glauben, dass Entwickler bald komplett ersetzt werden—manches, was gerade passiert, finde ich wirklich überraschend. Erst vor wenigen Tagen soll [Spotify](https://techcrunch.com/2026/02/12/spotify-says-its-best-developers-havent-written-a-line-of-code-since-december-thanks-to-ai/) gesagt haben, dass seine besten Entwickler seit Dezember keine einzige Zeile Code mehr geschrieben haben—weil sie AI-Agents die Implementierung erledigen lassen. Und in einer aktuellen Folge des Pragmatic-Engineer-Podcasts erwähnte [der Macher von Clawd](https://newsletter.pragmaticengineer.com/p/the-creator-of-clawd-i-ship-code), dass er Code shippt, den er nicht einmal mehr liest. Das sind nur zwei Beispiele von vielen — vielleicht Edge Cases, aber vielsagende Edge Cases. Ich will nicht behaupten, dass das überall so ist. Aber diese Beispiele deuten auf echtes Potenzial hin, besonders in gut repräsentierten Domänen. Und dieses Potenzial zeigt sich ganz konkret bei Sprachen wie Java, Python und JavaScript, bei Konstrukten wie HTML und CSS und bei Komponenten wie REST-Endpoints und Datenbankabfragen. Es ist die Art von Code, die seit Jahren—manchmal seit Jahrzehnten—öffentlich verfügbar ist. Er ist eingebettet in Quelldateien auf unzähligen Websites, geteilt über Open-Source-Repositories, diskutiert in Foren wie [Stack Overflow](https://stackoverflow.com/) und dokumentiert in Publikationen und Tutorials. LLMs haben das alles in sich aufgenommen—praktisch das gesamte Wissen des Webs. In diesen gut repräsentierten Domänen sind AI-Agents bemerkenswert leistungsfähig. Mit dem richtigen Prompt können sie Bausteine zu ganzen Services oder Produkten kombinieren—in einem Bruchteil der Zeit, die man früher gebraucht hätte. [OpenClaw](https://openclaw.ai/) ist ein gutes Beispiel: ein echtes Produkt, im Wesentlichen von einem einzigen Entwickler gebaut, wobei die AI den Großteil der Implementierung übernommen hat. Ohne dieses konkrete Produkt zu bewerten (ich habe mir den Code nie angesehen), ist das Ergebnis nicht immer das, was ein erfahrener Entwickler als sauber bezeichnen würde. Es passt selten perfekt zu den Konventionen einer bestehenden Codebase, und oft werden Edge Cases übersehen. Aber es funktioniert. Es ist ein echter Zeitgewinn und ein guter Startpunkt—entweder für die manuelle Weiterarbeit oder für den nächsten Prompt in einer iterativen Schleife. Und in kleinerem Umfang, mit ein paar Runden Review und Feedback, wird daraus tatsächlich sauberer, produktionsreifer Code. Die Produktivitätsgewinne sind also real: weniger Zeit für Boilerplate, mehr freie Kapazität für das, was wirklich zählt. Das ist echt wertvoll. Aber es gibt einen Haken, und der zeigt sich in dem Moment, in dem du dich in eine Nischen-Domäne wagst. ## 🔩 Warum Prozessorchestrierung mit BPMN eine andere Geschichte ist Mit BPMN-Engines wie Zeebe zu arbeiten, um Prozesse zu automatisieren, ist keine Mainstream-Programmierdomäne. Es ist ein ziemlich spezialisierter Bereich der Orchestrierung, mit vergleichsweise wenigen öffentlichen Trainingsdaten. Und das wird ziemlich schnell sichtbar, wenn du versuchst, AI einzusetzen. Wenn du ein LLM zum Beispiel bittest, einen Job Worker zu generieren oder einen Service Task in einer BPMN-Datei zu konfigurieren, bekommst du oft etwas, das _richtig aussieht_, aber nicht funktioniert. Und der Grund dafür ist einfach: Die Domäne ist voll von Konzepten, die es anderswo nicht gibt: Job Worker, Message Correlation, Variable Scoping, Incident Handling, BPMN-Datei-Schemas. Und was es noch kniffliger macht: Diese Konzepte können auch zwischen den Engines variieren—obwohl BPMN selbst ein gemeinsamer Standard der [OMG](https://www.omg.org/bpmn/) ist. Beim Arbeiten mit AI musst du also iterieren. Du fügst Beispielcode hinzu. Du kopierst Dokumentation in den Context. Und nach ein paar Runden, oder manuellem Nachbessern, bekommst du etwas, das funktioniert. Fairerweise: Dieser iterative Ansatz ist bereits wertvoll—aber es gibt klares Verbesserungspotenzial. ### 🔄 Erste Schritte in die richtige Richtung Mehrere Tools und Patterns sind bereits entstanden, um diese Lücke zu verkleinern. [Agent Files](https://agentskills.io/home) sind ein Ansatz. Sie geben dem Modell persistenten Context über dein Projekt—etwa Engine-spezifische Konventionen. Ihre Wirkung lässt jedoch nach, wenn die Datei lang und unscharf wird. Dann zeigt sich das Problem in beide Richtungen: Einerseits geht Zeebe-spezifischer Context im Rauschen der ganzen anderen Projektthemen unter. Und andererseits mischt sich Engine-Rauschen in Aufgaben ein, die mit der Engine gar nichts zu tun haben. Ein weiterer Ansatz ist das Model Context Protocol—kurz [MCP](https://modelcontextprotocol.io/docs/getting-started/intro). Es verbindet AI-Agents mit externen Tools und Datenquellen. Tools wie [Context7](https://context7.com/) sind aus diesem Protokoll entstanden. Über Tool Calls ziehen sie aktuelle Library-Dokumentation direkt in den Context des Modells—etwa die neuesten Camunda-SDK-Docs. Diese Docs verfügbar zu haben, reduziert die Wahrscheinlichkeit deutlich, dass das Modell fehlerhafte oder veraltete API Calls generiert. Ich habe beides ausprobiert. Beides hat geholfen. Aber keines hat wirklich ausgereicht. Der Context war immer nur eine Konversation davon entfernt, wieder verloren zu gehen, und es gab keinen konsistenten Weg, Engine-spezifisches Wissen so zu kodieren, dass das Modell sessionübergreifend zuverlässig darauf zugreifen konnte. Bislang war das so—denn genau diese Lücke sollen Skills füllen. ## 🧠 Skills: Wiederverwendbares Wissen Ein Skill ist ein Ordner mit Anweisungen, den du einmal baust und danach immer wieder verwendest. Er bringt einem AI-Agent bei, wie er eine bestimmte Aufgabe oder einen Workflow handhabt, indem er Domänenwissen, Konventionen und Edge Cases explizit kodiert. So lädt das Modell ihn, wenn er relevant ist, statt darauf angewiesen zu sein, dass du in jeder Session neu promptest. Skills basieren auf einem [offenen Standard](https://agentskills.io/home). Dieser Standard wurde ursprünglich von [Anthropic](https://www.anthropic.com/) entwickelt und frei zugänglich gemacht—ähnlich wie MCP. Das bedeutet, das Konzept ist nicht an ein einzelnes Tool oder einen einzelnen Anbieter gebunden: Es ist ein gemeinsames Fundament, das im gesamten Ökosystem wächst. ### 👩🏽‍💻 Wie man Skills baut Ein Skill besteht aus bis zu drei Teilen. Die `SKILL.md`\-Datei ist die einzige erforderliche Komponente. Sie enthält einen [Frontmatter](https://code.claude.com/docs/en/skills#frontmatter-reference)\-Abschnitt mit Metadaten—wie den `name`, die `description` und `allowed-tools` (Tools, die der Agent während der Ausführung ohne Nachfrage nutzen darf) des Skills. Weitere Felder stehen ebenfalls zur Verfügung—etwa `argument-hint`, `model` und `context`—aber diese drei werden am häufigsten benötigt. Neben diesen Metadaten im Frontmatter enthält das Markdown auch einen Body. Er hält die eigentlichen Anweisungen: wie der Output zu strukturieren ist, welche Patterns zu befolgen sind, welche Edge Cases zu behandeln sind und—entscheidend—wann eine Rückfrage zu stellen ist, bevor weitergemacht wird. Insgesamt könnte ein solcher Skill also genau beschreiben, wie Zeebe Job Worker implementiert werden sollen. In einem vereinfachten Beispiel könnte das in etwa so aussehen: ```` --- name: create-worker argument-hint: "[] [task-type-constant]" allowed-tools: Read, Write, Glob description: Create a new @JobWorker class for a BPMN service task. Accepts a ProcessApi file, a BPMN model, or a plain description. --- ## Key Rules - Use @JobWorker annotations from "io.camunda.client" - Use @Variable annotation to define input variables of the job - Inject the use-case interface as the only constructor parameter - ... ## Pattern ``` package ... import io.camunda.client.annotation.JobWorker import io.camunda.client.annotation.Variable @Component class AbortRegistrationWorker( private val useCase: AbortSubscriptionUseCase ) { private val log = KotlinLogging.logger {} @JobWorker(type = TaskTypes.NEWSLETTER_ABORT_REGISTRATION) fun handle(@Variable subscriptionId: UUID) { log.debug { "Received job to abort registration for subscriptionId: $subscriptionId" } useCase.abort(SubscriptionId(subscriptionId)) } } ``` ## Instructions 1. Find the required serviceTask in the Process-API or the bpmn-file itself 2. If you can’t resolve the process or task, ask the user to provide one 3. Derive package name and class name for the worker and search for existing files 4. If a file exists, report this to the user and ask what to do 5. Otherwise create a new worker using the camunda-spring-boot-starter patterns and key rules listed above 6. If you are missing any information (which annotations to use or use cases to inject), ask the user for feedback 7. Report the result and remind the developer to run `test-worker` ```` Darüber hinaus gibt es zwei optionale Ordner—nicht für jeden Skill erforderlich. `references/` enthält unterstützende Docs, die bei Bedarf geladen werden, um den Context des Modells schlank zu halten: Für einen Worker-Skill könnten das zusätzliche Codebeispiele kompletter Worker-Implementierungen oder Zeebe-spezifische Patterns zum Variable Handling sein. `scripts/` enthält ausführbare Helfer für deterministische Checks. Für einen Worker-Skill könnte das ein Script sein, das ein BPMN-Modell parst, die relevanten Service-Task-Typen herausfiltert und die Prozessvariablen für eine gegebene Task extrahiert—und so jede Mehrdeutigkeit beseitigt, bevor das Modell mit dem Generieren von Code beginnt. Zusammengefasst sieht ein Skill also in etwa so aus: ``` my-skill/ # The parent folder ├── SKILL.md # Required: The skill description with frontmatter & body ├── references/ # Optional: supporting docs loaded on demand └── scripts/ # Optional: executable helpers for deterministic checks ``` Wenn du mehr darüber wissen möchtest, wie man effektive Skills schreibt, ist der [Complete Guide to Building Skills for Claude](https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf) von Anthropic eine solide Referenz. ### 🕵🏽 Wie ein Skill erkannt wird Wenn ein Skill entsprechend definiert ist, können Agents ihn automatisch erkennen und nutzen. Beim Start werden nur `name` und `description` vorab in den Context geladen. Wenn du eine Anfrage stellst, gleicht das Modell sie mit diesen Beschreibungen ab, um zu entscheiden, welcher Skill zu laden ist. Der vollständige Inhalt der `SKILL.md` wird erst gezogen, sobald sie aufgerufen wird—so bleibt der Context standardmäßig schlank. Deshalb ist das `description`\-Feld entscheidend: Es muss klar benennen, sowohl _was_ der Skill tut als auch _wann_ er einzusetzen ist. Die Mechanik dahinter ist ausführlich in der [offiziellen Skills-Dokumentation](https://code.claude.com/docs/en/skills) beschrieben, die Discovery, Lade-Verhalten und Empfehlungen zum Schreiben effektiver Skill-Beschreibungen abdeckt. ### 🗂️ Wo Skills greifen Der Anwendungsbereich von Skills ist breiter, als du vielleicht erwartest. Es gibt vor allem zwei Muster, bei denen sie durchgängig Mehrwert schaffen. Das erste sind Domänen mit dünner Trainingsdatenlage. Bereiche, die entweder neu oder so speziell sind, dass es kaum öffentliche Beispiele gibt: Dazu gehören BPMN und Prozessorchestrierung, aber auch das zuvor genannte Model Context Protocol. In diesen Fällen liefern Skills direkt das, was das Modell aus dem Training nicht ableiten kann. Das zweite ist hochgradig individueller Output. Jedes LLM kann einen REST Controller erstellen. Aber einen zu erstellen, der durchgängig der spezifischen Struktur, den Naming Conventions und den Error-Handling-Patterns deines Teams folgt? Das erfordert eine Anpassungsfähigkeit, die weder Training noch Prompting allein zuverlässig liefern können. Dasselbe gilt für die Analyse von Prozessen gegen einen eigenen Style Guide—oder jedes andere Artefakt, das jedes Mal einer bestimmten Form entsprechen muss. All das liegt daran, dass LLM-Output von Natur aus ein Best Guess und nicht-deterministisch ist. Derselbe Prompt kann über mehrere Durchläufe unterschiedliche Ergebnisse liefern. Skills kodieren die Regeln explizit und geben dem Modell die bestmögliche Chance, konsistenten, strukturell vorhersehbaren Output zu produzieren. ### 📦 Wie sich Skills kategorisieren lassen Bisher lag der Fokus darauf, _wann_ Skills helfen. Aber es ist genauso nützlich, darüber nachzudenken, _was_ sie eigentlich tun—denn das prägt, wie du sie gestaltest. Basierend auf Anthropics Beobachtungen lassen sich Use Cases für Skills tendenziell in drei Kategorien clustern: - **Output-Generierung**—das Erzeugen von Artefakten mit konsistenter Form: Code, Dokumentation, Diagramme. Das `create-worker`\-Beispiel oben ist ein direkter Fall: dieselbe Klassenstruktur, dieselbe Verwendung von Annotations und dieselben Naming Conventions bei jedem Durchlauf, unabhängig davon, wer ihn aufruft. - **Workflow-Automatisierung**—das Kodieren wiederholbarer, mehrstufiger Abläufe. Ein `review-process`\-Skill könnte zum Beispiel ein BPMN-Modell systematisch durchgehen: die Compliance gegen einen Style Guide prüfen, verifizieren, dass jeder Service Task einen zugehörigen Worker hat, bestätigen, dass jede Message einen Adapter hat, der sie mit der Engine verdrahtet, und prüfen, dass für jeden relevanten Pfad Prozesstests existieren—und dann einen strukturierten Report erzeugen, was vorhanden ist und was fehlt. - **MCP-Erweiterung**—Skills, die externen Tool-Zugriff als Teil ihres Workflows einbinden. Statt die Zeebe-API-Details fest in den `create-worker`\-Skill zu schreiben, könntest du ihn erweitern: Der Skill identifiziert zuerst, was gebaut werden muss, nutzt dann ein MCP, um die aktuellen Camunda-SDK-Docs in den Context zu laden, und generiert erst dann den Code—immer auf Basis der neuesten API, ohne manuelles Copy-Pasten von Dokumentation. Diese Kategorien sind nützlich, um Skills einzuordnen, sollten aber nicht als strikte Grenzen behandelt werden. In der Praxis vermischen viele Skills mehrere Kategorien—und während sich das Ökosystem weiterentwickelt, werden wahrscheinlich neue Patterns entstehen, die in keine davon sauber passen. ### 🌐 Das Skill-Ökosystem Das Ökosystem rund um Skills ist sehr aktiv und wächst schnell. Stand Februar 2026 wird der [Agent-Skills-Standard](https://agentskills.io/home) bereits von vielen Agents unterstützt, etwa Claude Code, Gemini CLI, Cursor, GitHub und mehr. Unternehmen veröffentlichen ihre eigenen Skill-Sammlungen—[Anthropics Skills-Repo](https://github.com/anthropics/skills) ist ein gutes Beispiel. Community-kuratierte Listen wachsen daneben. Und auch eigene Marketplaces und Verzeichnisse beginnen zu entstehen. [LobeHub](https://lobehub.com/) und [findskill.ai](http://findskill.ai/) sind zwei frühe Anlaufstellen, die man kennen sollte. Im Bereich der Prozessautomatisierung allerdings sieht das anders aus: Vergleichsweise wenige Skills existieren bisher. Das ist mit ein Grund, warum ich diesen Post geschrieben habe—um die Lücke zu füllen und erste Beispiele aus meiner Arbeit zu teilen. ### 🔬 Wie das in der Praxis aussieht Während ich Skills in einem echten Zeebe-Projekt gebaut und verfeinert habe, habe ich die nützlichsten gesammelt und nach [easy-zeebe](https://github.com/emaarco/easy-zeebe) verschoben—ein Repository, das anfangs einfach nur ein Lösungs-Template zum Automatisieren eines Prozesses mit Zeebe war. Da ich Claude Code nutze, liegen die Skills im Ordner `.claude/skills/`. Aber weil Agent-Skills ein offener Standard ist, ist das keine Einschränkung. Du kannst sie unverändert mit jedem anderen Agent nutzen. Die aktuelle Sammlung sieht so aus: ``` .claude/skills/ ├── automate-process/ ├── create-process-adapter/ ├── create-worker/ ├── review-process/ ├── test-process-adapter/ ├── test-process/ ├── test-worker/ └── ... ``` Sie enthält eine Mischung aus Generierungs-Skills—etwa zum Implementieren von Workern, Adaptern und Controllern. Aber auch einige Quality-Assurance-Skills wie das Reviewen von Prozessen. Kopier dir gern die Skills, die du brauchst, fork das ganze Repo oder pass sie an dein Setup an. Lern von ihnen—und nutze die Vorteile, die sie dir bieten können. Und wenn du auf Lücken stößt oder Patterns entdeckst, die besser funktionieren, teile sie gern—egal ob du mit Zeebe oder einer komplett anderen Engine arbeitest. Mein Ziel ist es, eine Sammlung zu schaffen, die allen in diesem Bereich hilft, schneller voranzukommen und mit mehr Selbstvertrauen zu bauen. ## 📋 Meine persönliche Erfahrung Ich experimentiere jetzt seit ein paar Wochen mit Skills, und ich bin ehrlich überzeugt. Es begann mit Zeebe und BPMN. Aber schnell ertappte ich mich dabei, auch Skills für andere Domänen zu schreiben: das Erstellen und Testen von GraphQL- oder REST-Controllern, jeweils zugeschnitten auf die spezifische Struktur und die Konventionen des Teams. Der Output wurde konsistenter, die Qualität besser, und ich verbrachte weniger Zeit damit, Dinge zu korrigieren, die das Modell subtil falsch gemacht hatte. Wichtiger noch: Ich begann, dem Output zu vertrauen—nicht blind, aber genug, um zu reviewen statt neu zu schreiben. Das ist ein echter Wandel in der Arbeitsweise. Aber die interessantere Veränderung war das, was diese frei gewordene Zeit möglich machte. Ich begann plötzlich, Dinge zu tun, für die ich vorher schlicht keine Zeit gehabt hatte: den Stand unserer ADRs zu prüfen, zu kontrollieren, ob sie tatsächlich befolgt wurden, und die Lücken zu schließen. Ich habe sogar dafür einen Skill geschrieben—und es schneller erledigt, als es sonst gedauert hätte. Ich denke, dieser Effekt kann in Projekten noch wirkungsvoller sein, in denen Teams hauptsächlich damit beschäftigt sind, das Produkt am Laufen zu halten—erdrückt von Tech Debt und mit wenig Raum für anderes. Die gewonnene Zeit könnte genau das sein, was den Raum schafft, um endlich vor die Lage zu kommen, statt nur hinterherzulaufen. Was mir persönlich auch immer wieder auffällt: Skills machen es viel schneller, zu experimentieren und zu iterieren. Weniger Reibung zwischen Idee und funktionierender Implementierung bedeutet, dass du mehr validieren, früher auf Basis von Feedback nachjustieren und mehr deiner Zeit auf Dinge verwenden kannst, die echten Mehrwert für Nutzer schaffen—statt nur Tech Debt hinterherzujagen oder den Laden am Laufen zu halten. Ein gutes Beispiel dafür stammt von einem Kollegen von mir: Er wollte kürzlich MCP als neue Interaktionsebene für ein Produkt testen, das in der Baubranche zur Planung eingehender Aufträge genutzt wird. Die bestehenden Workflows darin—zum Beispiel um einen Kunden zu kontaktieren—waren mühsam: Kundenliste öffnen, suchen, zur Detailseite navigieren, die E-Mail-Adresse kopieren, zum Mail-Client wechseln, die Nachricht schreiben. Mit einem MCP Server, der mit dem Produkt verdrahtet ist, konnte ein AI-Agent das alles übernehmen. Man bittet ihn einfach, die E-Mail des Kunden zu finden und die Nachricht zu entwerfen. Er hat es aus einer bestehenden REST-API-Spezifikation in einer einzigen Session gebaut. Mit einem einfachen Prompt und dem [mcp-builder Skill](https://github.com/anthropics/skills/tree/main/skills/mcp-builder). Von der Idee zum funktionierenden Prototyp in einem Durchgang. Aber lass uns ehrlich über die Grenzen sprechen. ## 👨‍💻 Human in the Loop—nach wie vor nicht verhandelbar Skills sind keine magische Lösung. Die Output-Qualität hängt weiterhin vom Modell ab und davon, wie gut sowohl der Skill als auch dein Prompt geschrieben sind. Vage oder unvollständige Anweisungen führen weiterhin zu Annahmen, und nicht immer zu denen, die du dir wünschst. Und entscheidend: Sie ändern nichts an der Tatsache, dass LLMs von Natur aus nicht-deterministisch sind. Du solltest daher immer ein paar Praktiken berücksichtigen, auf die es wirklich ankommt: - **Vor dem Weitermachen nachfragen**—Ermutige das Modell, bei Unsicherheit Rückfragen zu stellen, bevor es weitermacht. Ohne dieses Signal neigen LLMs dazu, Lücken mit Annahmen zu füllen. Und die sehen oft plausibel aus, bis du den Output reviewst. Eine Rückfrage dauert Sekunden; falsche Implementierungen zu entwirren dauert deutlich länger. - **In Iterationen denken, nicht in Befehlen**—Strukturiere komplexe Skills inspiriert von Features wie dem Planning Mode von Claude Code: Das Modell schlägt vor, du reviewst und verfeinerst, dann führt es aus. Dieses Hin und Her deckt Missverständnisse früh auf, bevor sie zu einem Bug oder zu Tech Debt werden. - **Skills als lebende Artefakte behandeln**—Wenn ein Skill schlechten Output produziert, fixe den Skill. Jede Korrektur zahlt sich langfristig aus. - **Den Output immer reviewen**—Skills verkleinern die Lücke zwischen dem, worum du gebeten hast, und dem, was du bekommst, aber sie schließen sie nicht vollständig. Das Ziel ist, vom Neuschreiben zum Reviewen zu wechseln, nicht vom Reviewen zum blinden Vertrauen. ## 🪴 Exkurs: Qualitätssicherung jenseits von Skills Aber Skills allein reichen nicht—besonders im großen Maßstab. Die harte Wahrheit ist, dass man weder der AI noch den Menschen, die sie nutzen (oder selbst Code schreiben—_wie langweilig_), voll vertrauen kann, dass sie sich zuverlässig an die Regeln halten. Und in einer Welt, in der Code schneller denn je generiert werden kann, kann sich Tech Debt genauso schnell anhäufen. Je produktiver dein Team also wird, desto kritischer ist es, die Dinge wartbar zu halten. Einige Guardrails, die helfen, sind daher: - **Quality Gates** (z. B. SonarQube)—Wenn Code schneller denn je generiert werden kann, müssen die Qualitätsansprüche mithalten. Erzwinge Schwellenwerte für Testabdeckung und Code-Qualitätsregeln automatisch, bevor irgendetwas auf deinem Main Branch landet. - **Linting und Formatting** (z. B. ktlint, Prettier)—Konsistenter Stil ist nicht nur Ästhetik—er hält die Codebase überschaubar und das Onboarding handhabbar, besonders wenn mehrere Leute mit Tempo Code generieren. - **Architektur-Tests** (z. B. ArchUnit, Konsist)—Gute Software lebt innerhalb einer Struktur: klare Layer und explizite Abhängigkeiten. Konsistente Patterns, die es leicht machen, sie zu verstehen, zu erweitern und sich darin zurechtzufinden. Diese Entscheidungen sind es wert, dokumentiert zu werden—ADRs sind ein natürlicher Ort dafür. Aber Dokumentation erzwingt sich nicht selbst. Ein Entwickler nimmt eine Abkürzung, eine AI generiert Code, ohne deine Regeln zu kennen—und Layer-Grenzen weichen unbemerkt auf. Automatisierte Architektur-Tests fangen diese Verstöße ab, bevor sie landen—und verhindern kostspielige Refactorings. Das [easy-zeebe](https://github.com/emaarco/easy-zeebe)\-Repo enthält auch funktionierende Beispiele für diese Guardrails—konkret ein Architektur-Test-Setup auf Basis von [Konsist](https://docs.konsist.lemonappdev.com/)—falls du einen konkreten Startpunkt möchtest. ## ✨ Was möglich wird Zusammengefasst also: Skills gut zu nutzen ist nicht reibungsfrei. Aber meiner Erfahrung nach ist keine der oben genannten Herausforderungen ein Blocker. Sie sind mit den richtigen Praktiken gut handhabbar. Und sobald sie es sind, wird vieles möglich. Zu den Vorteilen gehören aus meiner Sicht unter anderem: - **AI wird auch dort nutzbar, wo es kaum Trainingsdaten gibt**—Skills warten nicht auf bessere Trainingsdaten. Sie liefern direkt, was fehlt—Engine-spezifische Patterns, Constraints und funktionierende Beispiele. Das macht AI-Unterstützung in Nischen-Domänen heute machbar, nicht an irgendeinem undefinierten Punkt in der Zukunft. - **Konsistenterer Output**—Dieselbe Aufgabe liefert ähnliche Ergebnisse, weil der Skill Context, Beispiele und Constraints jedes Mal fest verankert. Füge ein Code-Snippet deines Service-Task-Workers hinzu, und nahezu jeder Worker sieht identisch aus. Gleiche Struktur, gleiche Naming Conventions, gleiche Layer-Grenzen. - **Feedback-basiertes Arbeiten statt Raten**—Rückfragen bringen Unsicherheit früh an die Oberfläche. Du hast die AI angewiesen, ein Signal an einen Prozess zu senden, und sie weiß nicht, welche API sie nutzen soll? Sie fragt nach—und du klärst es—bevor eine einzige Zeile geschrieben wird. Das Ergebnis: keine halluzinierten API Calls, nur eine schnelle Klärung, die vielleicht ein Rewrite verhindert. - **Mehr Tempo = mehr Fokus auf das Wesentliche**—Skills reduzieren die Zeit für repetitive Arbeit erheblich. Worker, Adapter, Tests. All das wird schneller implementiert und fügt sich sauber in deine Architektur ein. Was früher ein paar Stunden dauerte, braucht jetzt vielleicht nur Minuten. Und die zurückgewonnene Zeit fließt in die Arbeit, die tatsächlich menschliches Urteilsvermögen erfordert: Prozessdesign, Domain Modeling und Architekturentscheidungen—Dinge, die nicht wegautomatisiert werden sollten. - **Schnelleres Prototyping**—Willst du testen, ob eine neue Fähigkeit—etwa ein MCP Server—echten Mehrwert für deine Nutzer bringt? Ein Skill kann aus deiner bestehenden REST-Spec in einer einzigen Session einen funktionierenden Prototyp generieren. Weniger Reibung zwischen Idee und funktionierendem Prototyp bedeutet, dass du mehr Ideen validieren kannst, und das früher. - **Teilbares Team-Wissen**—Skills sind nicht nur für Einzelne—sie sind versionierbare Artefakte, die du in dein Repository committest. Eine Person definiert, wie ein Worker strukturiert sein soll, und das ganze Team erbt es automatisch. Der Hauptvorteil: Der Output bleibt im Team konsistent. Kein Drift pro Person, keine wiederholten Erklärungen. Alle folgen denselben Konventionen, im Einklang mit dem, was ihr gemeinsam vereinbart habt. - **Kumulative Verbesserung**—Jede Korrektur, die du vornimmst, kann den Skill verbessern. Ein Skill, der heute in 80 % der Fälle richtig liegt, könnte nächste Woche schon bei 85 % liegen. Und wenn deine Skills geteilt sind, ist diese Verbesserung nicht nur deine—sie gehört dem ganzen Team. Alle profitieren. ## 🎬 Zum Abschluss Kurz gesagt: Skills machen deine AI nicht zum perfekten Entwickler. Aber sie können sie zu einem wirklich nützlichen Mitarbeiter machen. Einem, der deine Domäne versteht, deinen Konventionen folgt und Zugriff auf jeden Context hat, den du ihm gibst: Projektdateien, Dokumentation, Live-Daten via MCP und mehr. Er ist dein Kollege und Pair-Programming-Buddy. Sogar in Domänen, in denen das Modell sonst nicht ausreichen würde. Das Prinzip ist einfach: kodiere, was das Modell nicht weiß, halte einen Menschen im Loop, und lass Guardrails abfangen, was durchrutscht. Wenn du das konsequent machst, summieren sich die Vorteile—konsistenterer Output, schnellere Iteration und ein Team, das mit jedem Durchlauf ein bisschen besser wird. Für Zeebe und BPMN habe ich eine Reihe von Skills zu [easy-zeebe](https://github.com/emaarco/easy-zeebe) hinzugefügt. Kopier dir gern einzelne Skills oder fork das ganze Repository und pass sie an deine Bedürfnisse an. Wenn du auf Probleme stößt oder Verbesserungsvorschläge hast, öffne ein Issue im Repository. Das hilft, die Sammlung für alle besser zu machen. Zwei Dinge sind erwähnenswert: Skills sind nicht agent-spezifisch. Da sie ein [offener Standard](https://agentskills.io/home) sind, kann jeder Agent, der sie unterstützt, sie nutzen—nicht nur Claude Code. Sie sind auch nicht engine-spezifisch. Tausche die Codebeispiele und Konventionen aus, und derselbe Ansatz funktioniert mit jeder Process Engine. Das Konzept zählt mehr als die konkrete Implementierung. Über easy-zeebe hinaus würde ich empfehlen, die wachsende Zahl an Skill-Repositories und Marketplaces zu durchstöbern. Die Chance ist gut, dass jemand bereits etwas Nützliches für deine Domäne gebaut hat. Und wenn du Skills kombinierst—deine eigenen und die anderer—summiert sich der Effekt: Jeder einzelne fügt Context hinzu, auf den sich das Modell stützen kann, was den Output schärfer und zuverlässiger macht. Und zum Schluss: Hör nicht bei Skills auf—erkunde, was dein Agent sonst noch kann. In Claude Code sind zum Beispiel [Sub-Agents](https://docs.anthropic.com/en/docs/claude-code/sub-agents) ein natürlicher nächster Schritt: isolierte Contexts, in denen das Modell in einer spezialisierten Rolle agiert, angetrieben von einem Skill. Denk an einen Reviewer, der BPMN-Konsistenz prüft, oder einen Architecture Guard, der hexagonale Grenzen verifiziert. Auch damit habe ich experimentiert, und in Kombination mit Skills haben sie noch mehr Produktivität freigesetzt—aber das ist ein Thema für einen anderen Post. ## 🔭 Was als Nächstes kommt—und worauf ich neugierig bin Zusammen mit ein paar Kollegen bei [Miragon](https://miragon.io/) baue ich Skills für Zeebe weiter aus und erkunde denselben Ansatz für andere Process Engines. Die Vision: eine geteilte Skill-Library für die Prozessautomatisierung—versionierbar, iterativ verbessert und teamübergreifend nutzbar. Eine, die allen hilft, schneller voranzukommen, ohne Konsistenz oder Qualität zu opfern. Und wenn du diesen Ansatz in dein eigenes Team bringen möchtest: Wir bieten dazu auch ein praxisnahes Training an—[AI in der Prozessautomatisierung](https://miragon.io/trainings/ai-tooling-workshop/). Entlang des BPM-Lifecycles zeigt es, wie du AI-Agents aufsetzt, Skills für deine Domäne baust und die Guardrails etablierst, die die Qualität hoch halten. Ich bin neugierig auf deine Erfahrung. Hast du schon versucht, AI-Unterstützung im Kontext der Prozessautomatisierung einzusetzen? Falls ja: Was funktioniert für dich—und was nicht? Gibt es bestimmte Aufgaben, bei denen der Output durchgängig zu kurz greift? Oder bei denen du einen Ansatz gefunden hast, der gut funktioniert? 👉 Schreib gern einen Kommentar oder melde dich! _This post was originally published in English on [Medium.com](https://medium.com/p/b20685dfa688)._ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fagent-skills-ai-nischen-domaenen-bpmn%2F)[](mailto:?subject=Agent-Skills%3A%20Wie%20AI%20auch%20in%20Nischen-Dom%C3%A4nen%20wie%20BPMN%20%26%20Prozessautomatisierung%20zuverl%C3%A4ssig%20wird&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fagent-skills-ai-nischen-domaenen-bpmn%2F) ## Marco Schäck Process Development Lead bei Miragon [in Marco kennenlernen](https://www.linkedin.com/in/schaeckm/) [Mehr von Marco](/blog/?author=marco-schäck) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ AI 04\. Mai 2026 ### Miragon AI: Vom Cockpit zur Konversation Wie wir bei Miragon Prozessautomatisierung neu denken: weg vom isolierten Cockpit, hin zur Konversation als Interface. Warum das MCP und MCP Apps das Fundament dafür bilden. Thomas Heinrichs Solution Architecture Lead ](/blog/miragon-ai-vom-cockpit-zur-konversation/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten](https://www.miragon.io/blog/ai-bpmn-modelle-visuell-sauber-halten/) AI AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead **28\. Juli 2026**10 Min. Lesezeit Mit jedem großen LLM-Release wird AI merklich besser darin, BPMN zu generieren und zu bearbeiten. Mit einem soliden Setup (wie [agent-skills](https://agentskills.io/home), passenden Code-Beispielen und Guardrails) funktionieren einfache Änderungen an einem Prozess oft schon im _ersten Versuch_. Die technische Konfiguration stimmt, der Prozess ist von der Engine ausführbar. Doch eine Ebene hinkt beharrlich hinterher: die **visuelle**. Ein Modell, das ein Agent bearbeitet, enthält häufig unsichtbare Elemente oder ein chaotisches Layout, weil der Agent nie _sieht_, was er gezeichnet hat. Dieser Post zeigt den Loop, mit dem ich solche Modelle lesbar halte: erst die Probleme **erkennen**, dann **beheben** und am Ende die Checks **erzwingen**. Und darunter liegt eine größere Frage: Wenn AI nun gut genug ist, um einen Prozess fast im Alleingang zu modellieren, zu implementieren und zu prüfen, was sollte ein Mensch dann trotzdem nicht aus der Hand geben? ## 🤖 Warum sieht AI nicht, was sie zeichnet? Bitten wir einen Agenten, einen Service Task zu einem Prozess hinzuzufügen oder eine Routing-Bedingung an einem Gateway zu definieren, ist das entstehende XML beim ersten Versuch immer öfter korrekt. Und trotzdem erzählt die Visualisierung oft eine andere Geschichte. Das Element ist technisch zwar da, aber auf dem Canvas ist es nicht sichtbar, überlappt mit seinen Nachbarn oder sitzt einfach schief. Der Prozess _läuft_, aber ein Mensch kann das Modell nicht einfach ansehen und _verstehen_. Und genau dieses Verständnis ist der Punkt: BPMN ist eine Notation für Business-IT-Alignment. Etwas, auf das sich beide Seiten tatsächlich einigen. Warum zeichnet der Agent also immer wieder falsch? Standardmäßig arbeitet er nur auf Text und XML; ein visuelles Feedback fehlt ihm. Er kann nicht auf das gerenderte Diagramm schauen und bemerken, dass ein Element nicht gerendert wurde oder dass zwei Flows ein Label kreuzen. Er arbeitet blind. ## 🧩 Zwei Ebenen, zwei Fehler Dieser blinde Fleck hat eine strukturelle Ursache. Laut der [OMG-BPMN-2.0-Spezifikation](https://www.omg.org/spec/BPMN/2.0/) trägt eine BPMN-Datei zwei unterschiedliche Arten von Informationen. Zum einen das _semantische_ Modell: die Tasks, Events, Gateways und Sequence Flows, die festlegen, was der Prozess tatsächlich tut. Daneben liegt die **BPMN-DI**\-Ebene (Diagram Interchange), ein separater XML-Block, der beschreibt, _wie_ das Modell gezeichnet wird: die Position und die Bounds jedes Shapes, und die Waypoints der Verbindungen dazwischen. Die Engine liest nur das semantische Modell, Menschen sehen nur die DI. Und genau da bricht es. Bearbeitet ein Agent das Modell, vermasselt aber die DI, läuft der Prozess einwandfrei weiter, während die Zeichnung fehlerhaft aussieht. Zeigen wir es konkret an einem Beispiel: der Anmeldung für ein Membership-Programm eines Fahrrad-Shops, aus meinem [easy-zeebe](https://github.com/emaarco/easy-zeebe)\-Repo. Fast jeder Branch schließt mit einem End Event. Nur der Happy Path nicht: Nach `Send Welcome Mail` hört der Flow einfach auf. Also bitten wir einen Agenten, eins hinzuzufügen. Im semantischen Modell ist das ein Einzeiler. Aber genau bei diesem können die Fehler auftreten – auf zwei typische Arten: ### 👻 Das unsichtbare Element Der Agent fügt das End Event hinzu, gibt ihm aber nie ein `BPMNShape`. Der Branch ist vollständig, das Modell läuft, aber auf dem Canvas sieht `Send Welcome Mail` immer noch wie eine Sackgasse aus. Das neue Event wird schlicht nicht gezeichnet: ``` ``` ### 🌀 Das chaotische Layout Diesmal bekommt das Event sogar ein Shape. Aber der Agent rät bei den Koordinaten und platziert es zu weit oben. `Membership activated` landet in der Ecke, deutlich verschoben gegenüber dem Task, zu dem es gehört. Das BPMN stimmt, das Bild nicht. Um das zu lösen, betten wir den Agenten in einen Loop ein, den ein sorgfältiger Reviewer von Hand durchlaufen würde: erst das kaputte Layout **erkennen**, dann **beheben**, und am Ende einen Check in der Pipeline **erzwingen**, damit nichts nach `main` rutscht. ## 🕵️ Erkennen Viele Probleme lassen sich mit festen, deterministischen Regeln festnageln. Fehlt einem Element seine DI? Trägt jeder Node ein Label? Hat jedes Element genau einen eingehenden Flow? Jede Frage ist ein klares Ja oder Nein. Das lässt sich direkt aus dem XML ablesen. Visuelles Verständnis braucht es dafür nicht. Für solche Fälle können wir einen Linter nutzen. Und zum Glück gibt es einen schon, sogar Open Source: [`bpmnlint`](https://github.com/bpmn-io/bpmnlint) vom bpmn.io-Team. Er fängt Dinge wie fehlende Shapes und Überlappungen out of the box. Dank eines `recommended`\-Presets bleibt eine minimale Config eine einzige Zeile, die ein Agent nach jeder Änderung laufen lassen kann: ``` { "extends": "bpmnlint:recommended" } ``` Was die Defaults nicht abdecken, können wir mit eigenen Regeln ergänzen. Zwei habe ich selbst geschrieben: [`no-crossing-flows`](https://github.com/emaarco/easy-zeebe/blob/main/tools/bpmnlint-plugin-local/rules/no-crossing-flows.js) markiert Sequence Flows, die sich kreuzen, und [`flow-through-element`](https://github.com/emaarco/easy-zeebe/blob/main/tools/bpmnlint-plugin-local/rules/flow-through-element.js) einen Flow, dessen Pfad mitten durch ein Shape läuft, mit dem er nicht mal verbunden ist. Beide arbeiten rein mit der Geometrie des Modells, und beide hängen in der [`.bpmnlintrc`](https://github.com/emaarco/easy-zeebe/blob/main/tools/.bpmnlintrc), neben den geerbten Defaults. Nicht alles lässt sich jedoch in eine Regel fassen. Wirkt der Happy Path prominent? Sind verwandte Aktivitäten sinnvoll gruppiert? Ist ein Label wirklich _gut_, nicht nur vorhanden? Dafür braucht es ein Auge. Ein multimodales LLM kommt dem schon nahe, aber nur, wenn es das Modell tatsächlich _sehen_ kann. Also geben wir ihm die fehlende Hälfte des Loops: Wir rendern das Modell mit [`bpmn-to-image`](https://github.com/bpmn-io/bpmn-to-image) zu einem Bild und lassen es über das Bild urteilen, zusammen mit dem XML. Damit das verlässlich wird, können wir das Review in einem [agent-skill](https://agentskills.io/home) festhalten. Das LLM, das ihn ausführt, bleibt nicht-deterministisch, aber der Skill legt fest, _wie_ jeder Check abläuft, sodass bei jedem Modell dieselben Schritte greifen. Mein [`verify-model-visually`](https://github.com/emaarco/easy-zeebe/tree/main/.claude/skills/verify-model-visually)\-Skill macht genau das, und geht noch einen Schritt weiter: Ein einziger Aufruf verkettet beide Netze nacheinander, erst der Linter, dann das Augenpaar. ## 🔧 Beheben Ein Detector ist noch keine Reparatur. Der Linter, der einen kreuzenden Flow erkennt, hat ihn nicht entkreuzt, und das LLM, das ein schwebendes Event entdeckt, hat es nicht verschoben. Irgendetwas muss die Änderung also noch vornehmen, und diese Arbeit teilt sich genauso auf wie das Erkennen: die mechanischen Fälle an ein Script, die subjektiven an die AI. Die mechanischen Fälle sind reine Geometrie. Ein kreuzender Flow lässt sich gezielt umleiten, etwa mit dem [`ManhattanLayout`](https://github.com/bpmn-io/diagram-js/blob/main/lib/layout/ManhattanLayout.js) von diagram-js. Ein verworrenes Modell lässt sich komplett neu layouten, etwa mit [`bpmn-auto-layout`](https://github.com/bpmn-io/bpmn-auto-layout) – beides, ohne den Prozess je zu verstehen. Was jedoch nur subjektiv feststellbar ist, muss die AI beheben. Etwa, ob sich das _Bild_ wirklich gut liest. Aus den Findings und dem gerenderten Bild verschiebt sie die Shapes und Waypoints, die das Script nicht richtig gesetzt hat, und rendert danach neu, um die eigene Arbeit zu prüfen. Um beides zusammenzubringen, können wir wieder auf einen agent-skill setzen, der die Reihenfolge festlegt: erst der billige, deterministische Reroute, dann die AI, und ein volles Auto-Layout nur als letztes Mittel. Das ist die Aufgabe meines [`fix-model-layout`](https://github.com/emaarco/easy-zeebe/tree/main/.claude/skills/fix-model-layout)\-Skills. Angewendet auf mein Modell sitzt das End Event am Ende genau da, wo es hingehört: ## 🚧 Erzwingen Beide Phasen helfen allerdings nur, wenn sie auch aufgerufen werden. Öffnet jemand einen Pull Request nach `main`, gibt es keine Garantie, dass die Modelle in Ordnung sind. Und sich darauf zu verlassen, dass ein Reviewer den Fehler bemerkt, reicht nicht: Ein Reviewer liest meist nur das Diff und schaut sich nicht zwingend das zugehörige gerenderte Bild an. Ein kaputtes Layout ist im Diff praktisch unsichtbar. Also brauchen wir eine Ebene, die die Checks automatisch ausführt und den Merge blockiert, wenn etwas nicht stimmt. Eine CI-Pipeline ist diese Ebene. In meinem Beispiel-Repo läuft sie als [GitHub-Actions-Workflow](https://github.com/emaarco/easy-zeebe/blob/main/.github/workflows/bpmn-quality-gates.yml) mit zwei Gates auf jedem Pull Request: Erst der deterministische Linter, und das AI-Review nur, wenn der Linter grün ist: ``` on: pull_request: paths: ['**/bpmn/*.bpmn'] # only when a model changed jobs: lint-bpmn: # Gate 1 — deterministic geometry, blocks the PR # ... npm ci ... - run: npm run lint:bpmn visual-review: # Gate 2 — AI judgment needs: lint-bpmn # runs only once the linter is green # ... claude-code-action runs verify-model-visually ... ``` Und über das reine Scheitern hinaus hinterlässt das Review einen Kommentar am Pull Request, der erklärt, was nicht stimmt: Meine Haltung dazu: Ein deterministischer Linter, der den Merge blockiert, ist für mich gesetzt. Das AI-Review nehme ich dazu, aber ich lasse es nicht den Build scheitern. Sein Urteil kommt von einem LLM, bleibt also nicht-deterministisch, und die Pipeline wegen eines Checks rot zu schalten, der sich selbst widersprechen kann, fühlt sich wackelig an. Vorerst postet es seine Findings nur als Kommentar am Pull Request. ## 🔮 Was bedeutet das für BPMN? Stellen wir uns jetzt ein Projekt vor, das stark auf AI setzt. Es übernimmt die komplette Arbeit des Modellierens und Implementierens und prüft dabei die eigene visuelle Arbeit. Ein menschlicher Touchpoint bleibt kaum noch übrig. Darüber nachzudenken, lohnt sich. BPMN war nie nur ausführbarer Code. Es ist eine Methode für Business-IT-Alignment: ein Diagramm, das beide Seiten lesen und dem beide zustimmen. Lassen wir AI das Diagramm schreiben, prüfen und ausliefern, und liest es nie jemand, verschwindet dieses Alignment leise, selbst während der Prozess korrekt weiterläuft. Die eigentliche Frage ist dann nicht nur, welchem Zweck ein Modell noch dient. Sondern wer tatsächlich weiß, dass es stimmt, und wer noch das Wissen hat, einzugreifen, wenn es falsch ist. Chris Banes nennt eine Version davon „the disappearing middle”: Geben wir genug der Arbeit ab, bekommen die Leute, die sich das Verständnis für ein kritisches Review erarbeiten würden, nie die nötige Routine. Wie er es formuliert: [„if you cannot review the output with confidence, you should not delegate the work.”](https://chrisbanes.me/posts/disappearing-middle-ai-software-apprenticeship/) Und diese Zuversicht bleibt nicht bestehen, wenn wir alles abgeben. Mein Fazit: Wir sollten trotzdem so viel wie möglich abgeben. Das Modellieren, die Implementierung, sogar die visuellen Checks der AI. Halten wir zu viel zurück, verlieren wir die Vorteile, die AI bietet. Aber wir dürfen es nicht blind tun. Wir müssen im Loop bleiben, bei jedem Schritt mitarbeiten und die richtigen Guardrails setzen. In gewisser Weise rücken wir dabei in eine begleitende, prüfende Rolle, statt in die eines reinen Umsetzers. Nur so behalten wir das Wissen und treffen die Entscheidungen. Genau die sollten wir nicht abgeben. ## 🎬 Fazit AI ist inzwischen wirklich gut in der _Logik_ eines BPMN-Prozesses. Wo sie noch stolpert, ist die _visuelle_ Ebene: der Teil, den sie nie wirklich sieht und den auch ein Diff-lesender Reviewer übersieht. Diese Lücke zu schließen, braucht einen ganzen Loop, kein einzelnes Tool: erst das kaputte Layout **erkennen**, dann **beheben** und am Ende die Checks **erzwingen**. Alle Bausteine, die Linter-Regeln, die beiden agent-skills und der CI-Workflow, liegen ausgearbeitet in [easy-zeebe](https://github.com/emaarco/easy-zeebe): ein Startpunkt zum Forken und Anpassen an die eigenen Modelle. Die agent-skills und Guardrails, die darunterliegen, sind das Thema meines [Begleit-Posts](/blog/agent-skills-ai-nischen-domaenen-bpmn/). Der Loop selbst ist dabei der leichte Teil. Schwerer wiegt die Frage dahinter: bei den Entscheidungen zu bleiben, auch wenn das Tooling gut genug wird, um sie uns abzunehmen. 👉 Wo zieht ihr die Grenze? Schreibt es gern in die Kommentare. _This post was originally published in English on [Medium.com](https://medium.com/miragon/executable-but-unreadable-keeping-ai-edited-bpmn-clean-b8cdd04d5d7d)._ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fai-bpmn-modelle-visuell-sauber-halten%2F)[](mailto:?subject=Ausf%C3%BChrbar%2C%20aber%20unlesbar%3A%20AI-bearbeitete%20BPMN-Modelle%20sauber%20halten&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fai-bpmn-modelle-visuell-sauber-halten%2F) ## Marco Schäck Process Development Lead bei Miragon [in Marco kennenlernen](https://www.linkedin.com/in/schaeckm/) [Mehr von Marco](/blog/?author=marco-schäck) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ AI 04\. Mai 2026 ### Miragon AI: Vom Cockpit zur Konversation Wie wir bei Miragon Prozessautomatisierung neu denken: weg vom isolierten Cockpit, hin zur Konversation als Interface. Warum das MCP und MCP Apps das Fundament dafür bilden. Thomas Heinrichs Solution Architecture Lead ](/blog/miragon-ai-vom-cockpit-zur-konversation/)[ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Mit bpmn-to-code deine Prozesse & Code in Einklang bringen](https://www.miragon.io/blog/bpmn-to-code-prozesse-in-einklang/) BPM Wie bpmn-to-code die Lücke zwischen BPMN-Modellen und Implementierung schließt und für konsistente Prozessautomatisierung sorgt. Marco Schäck Process Development Lead **21\. März 2025**10 Min. Lesezeit Als Consultant & Entwickler bin ich stets davon angetrieben saubere und intelligente Lösungen zu schaffen - egal ob es sich um technische, architektonische oder organisatorische Herausforderungen handelt. Mein Ziel ist es, Hürden abzubauen & Lösungen zu entwickeln, die nicht nur mir, sondern auch anderen Personen ihre Arbeit erleichtern. Ein Bereich, in dem mir immer wieder kleine, aber lästige Probleme begegnet sind, ist die Prozessautomatisierung mit BPMN und Engines wie Zeebe. Hier unterstütze ich unsere Kunden dabei, ihre Prozesse zu automatisieren und im Umgang mit BPMN sowie entsprechenden Prozess-Engines – sei es beim Modellieren oder bei der Implementierung – effektiv voranzukommen. Ein häufiges Problem, das ich dabei sowohl bei mir selbst als auch bei unseren Kunden beobachte, ist die Notwendigkeit, technische Konfigurationen manuell aus BPMN-Modellen in den Code zu übertragen. Dazu zählen beispielsweise Element-IDs, Message-IDs und Worker-Types. Diese mühsame Aufgabe bringt zahlreiche Fehlerquellen mit sich und erhöht die kognitive Belastung – vor allem, wenn sich die Modelle weiterentwickeln und die Konfigurationen manuell aktuell gehalten werden müssen. Um diese Probleme zu beheben, habe ich ein Maven- und Gradle-Plugin namens **bpmn-to-code** entwickelt. Es generiert etwas, das ich als **Process‑APIs** bezeichne. Code-Artefakte in Kotlin oder Java, die direkt aus BPMN-Modellen erstellt werden und sämtliche technischen Konfigurationen enthalten, die für die Interaktion mit einer Process-Engine notwendig sind. Im Wesentlichen zielt das Plugin darauf ab, den manuellen Aufwand zu reduzieren, Fehler zu vermeiden und letztlich saubere & gut wartbare Lösungen zu entwickeln. Und wer weiß - vielleicht wird die Entwicklung mit BPMN und Process-Engines so für Entwickler auch ein Stück weit einfacher und intuitiver. ## 🕵️ Herausforderungen beim Einsatz einer Prozess‑Engine Hand aufs Herz – die Arbeit mit Prozess-Engines verläuft selten so problemlos, wie man es sich wünscht. Stell dir vor, du wirst beauftragt, einen Newsletter-Abo-Prozess zu automatisieren. In aller Regel startest du damit, das Prozessmodell in BPMN zu entwerfen: Ein Nutzer füllt ein Formular aus, erhält eine Bestätigungs-E-Mail, bestätigt sein Abonnement und bekommt schließlich eine Willkommensmail. Sobald der grundlegende Ablauf steht, verfeinerst du das Modell, um Ausnahmen und zusätzliche Szenarien zu berücksichtigen. In einer detaillierteren Form - oder (um ehrlich zu sein) in einer Form, welche die Verwendung verschiedener Elementtypen zeigt, die das Plugin verarbeiten kann - könnte das Prozessmodell dann in etwa so aussehen: Sobald du den Prozess visuell modelliert hast, gehst du dazu über, ihn technisch zu konfigurieren, indem du z. B. Element- & Message-IDs hinterlegst. Danach kannst du das Modell in einer BPMN-Engine deiner Wahl, wie Camunda 7 oder 8, deployen. So weit, so gut. Aber dann kommt die eigentliche Implementierung. Um den Prozess ausführbar zu machen, werden du zum Beispiel Service-Task-Worker implementieren und Nachrichten an die Engine über deren API senden. In diesem Stadium muss jeder Teil Ihres Codes auf die technischen Details des BPMN-Modells verweisen. Um diese Details abzurufen, müssen Sie sie normalerweise manuell aus dem Modell in Ihren Code kopieren. Eine nostalgische Praxis, die, seien wir ehrlich, im Jahr 2025 nicht mehr zeitgemäß sein sollte. Das Ergebnis daraus sind etwa Service-Task-Worker, die auf hart-codierten Strings für basieren, wie im folgenden Beispiel illustriert: ``` @Component class AbortRegistrationWorker( private val useCase: AbortSubscriptionUseCase ) : DefaultJobWorker( type = "newsletter.abortRegistration", ) { private val log = KotlinLogging.logger {} override fun executeTask( client: JobClient, job: ActivatedJob ): Map { val input = job.getVariablesAsType(Input::class.java) log.debug { "Received job to abort registration: $input" } useCase.abort(SubscriptionId(input.subscriptionId)) return emptyMap() } data class Input(val subscriptionId: UUID) } ``` Und damit nicht genug: Wenn du außerdem auch noch Tests schreibst, kann es passieren, dass du mehrere Instanzen dieser hart-codierten Strings hast. Jede einzelne davon ist eine potenzielle Fehlerquelle - denn du musst sie einzeln in deinen Code kopieren und jederzeit auf dem aktuellen Stand halten. ``` @Test fun `happy path - user subscribes to newsletter`() { val subscriptionId = UUID.fromString("4a607799-804b-43d1-8aa2-bdcc4dfd9b86") processPort.submitForm(SubscriptionId(subscriptionId)) waitForProcessInstanceHasReachedElement("Activity_ConfirmRegistration") processPort.confirmSubscription(SubscriptionId(subscriptionId)) waitForProcessInstanceHasPassedElement("EndEvent_RegistrationCompleted") assertThatProcess().isCompleted() assertThatProcess().hasPassedElementsInOrder( "StartEvent_RequestReceived", "Activity_SendConfirmationMail", "Activity_ConfirmRegistration", "Activity_SendWelcomeMail", "EndEvent_RegistrationCompleted" ) verify { sendConfirmationMailUseCase.sendConfirmationMail(SubscriptionId(subscriptionId)) } verify { sendWelcomeMailUseCase.sendWelcomeMail(SubscriptionId(subscriptionId)) } verify { abortSubscriptionUseCase wasNot Called } confirmVerified(sendConfirmationMailUseCase, sendWelcomeMailUseCase, abortSubscriptionUseCase) } ``` Zusammengefasst ist dieser Ansatz nicht nur frustrierend, sondern erzeugt auch ein regelrechtes Minenfeld. Ein einziger Tippfehler oder ein verpasstes Update kann dazu führen, dass dein Code nicht mehr mit dem Modell übereinstimmt. Wenn sich das Modell weiterentwickelt – was unvermeidlich ist – musst du jede Referenz manuell aufspüren und anpassen. Das Fehlerrisiko ist hoch, und der gesamte Prozess ist alles andere als effizient. Stell dir nun zudem vor, du bist neu in der Welt von BPMN und Prozess-Engines. Begriffe wie Element-IDs oder Service-Task-Topics sind dir kaum geläufig. Kaum hast du begonnen, etwas zu entwickeln, stößt du auf diese Hürden und wirst schnell frustriert. Anstatt das Potenzial zu erkennen, lehnst du die Technologie ab und verpasst so den Mehrwert, den sie bieten könnte. Nach einiger Erfahrung in der Entwicklung von Lösungen mit Process Engines und der Unterstützung von Kunden im Umgang mit BPMN kenne ich diese Herausforderungen nur zu gut. Genau deshalb habe ich **bpmn-to-code** entwickelt. ## 🚀 Eine Idee zur Lösung **bpmn-to-code** ist ein Plugin, das sowohl für [Gradle](https://plugins.gradle.org/plugin/io.miragon.bpmn-to-code-gradle) als auch für [Maven](https://central.sonatype.com/artifact/io.miragon/bpmn-to-code-maven) verfügbar ist. Du kannst es dir vorstellen wie Swagger Codegen, jedoch speziell für BPMN und die Automatisierung von Prozessen mit entsprechenden Engines. So wie Swagger Client-Code aus OpenAPI-Definitionen generiert, erstellt **bpmn-to-code** eine leichtgewichtige Process‑API aus deinen BPMN-Modellen. Diese API-Datei ist eine codebasierte Darstellung deines Prozessmodells – als Java- oder Kotlin-Datei – die alle relevanten technischen Konfigurationen wie Element-IDs, Message-IDs, Worker-Types und die Prozess-ID enthält. Derzeit unterstützt das Plugin sowohl **Camunda** 7 als auch **Zeebe** und wurde mit Blick auf Erweiterbarkeit entwickelt. Das bedeutet, dass bei Bedarf auch weitere Engines unterstützt werden könnten. Derzeit unterstützt das Plugin zwei Engines: Camunda 7 und Zeebe. Engines, mit denen ich lange gearbeitet habe, bzw. aktuell arbeite - weswegen ich einige Modelle hatte, um diese zu testen. Da es jedoch auch viele andere Engines gibt und Camunda 7 bald nicht mehr supported wird, habe ich das Plugin so entwickelt, dass es möglichst einfach um weitere Engines erweiterbar ist - sollte eine Nachfrage hierfür existieren. ## 🎮 Das Plugin in Aktion Schauen wir uns nun an, was sich tatsächlich ändert, wenn du **bpmn-to-code** in deinem Projekt einsetzt. Zunächst einmal: Wie bringst du es zum Laufen? Nutzt du Gradle, füge einfach die folgende Plugin-Deklaration in deine `build.gradle.kts` ein. Nutzt du hingegen Maven findest du eine Anleitung in der README auf GitHub. ``` plugins { id("io.miragon.bpmn-to-code-gradle") version "0.0.1-alpha" } ``` Nun können du deine Dependencies neu laden. Sollte das Plugin noch nicht gefunden werden, stelle bitte sicher, dass du das Gradle Plugin Portal als Quelle für Plugins zu deiner `settings.gradle.kts` Datei hinzugefügt hast. ``` pluginManagement { repositories { gradlePluginPortal() } } ``` Als Nächstes konfigurierst du den Generation-Task. In diesem Task legst du fest, wo sich deine BPMN-Modelle befinden, wohin der generierte Code geschrieben werden soll, in welcher Sprache die API erstellt werden soll, und mit welcher Prozess-Engine du arbeitest. ``` tasks.named("generateBpmnModelApi", GenerateBpmnModelsTask::class) { baseDir = projectDir.toString() filePattern = "src/main/resources/**/*.bpmn" outputFolderPath = "$projectDir/src/main/kotlin" packagePath = "de.emaarco.example" outputLanguage = OutputLanguage.KOTLIN processEngine = ProcessEngine.ZEEBE } ``` Sobald du den Task ausführst, generiert das Plugin deine Process‑API. Zurück zu unserem Newsletter-Abonnement-Beispiel: Das Plugin erzeugt eine **Kotlin**\- oder **Java**\-Datei, die in etwa so aussieht: ``` package com.example.process @Suppress("unused") object NewsletterSubscriptionProcessApiV1 { val PROCESS_ID: String = "newsletterSubscription" object Elements { val Timer_EveryDay: String = "Timer_EveryDay" val Timer_After3Days: String = "Timer_After3Days" val ErrorEvent_InvalidMail: String = "ErrorEvent_InvalidMail" val Activity_ConfirmRegistration: String = "Activity_ConfirmRegistration" val SubProcess_Confirmation: String = "SubProcess_Confirmation" val EndEvent_RegistrationAborted: String = "EndEvent_RegistrationAborted" val EndEvent_SubscriptionConfirmed: String = "EndEvent_SubscriptionConfirmed" val EndEvent_RegistrationCompleted: String = "EndEvent_RegistrationCompleted" val EndEvent_RegistrationNotPossible: String = "EndEvent_RegistrationNotPossible" val Activity_AbortRegistration: String = "Activity_AbortRegistration" val Activity_SendWelcomeMail: String = "Activity_SendWelcomeMail" val Activity_SendConfirmationMail: String = "Activity_SendConfirmationMail" val StartEvent_SubmitRegistrationForm: String = "StartEvent_SubmitRegistrationForm" val StartEvent_RequestReceived: String = "StartEvent_RequestReceived" } object Messages { val Message_FormSubmitted: String = "Message_FormSubmitted" val Message_SubscriptionConfirmed: String = "Message_SubscriptionConfirmed" } object TaskTypes { val EndEvent_RegistrationCompleted: String = "newsletter.registrationCompleted" val Activity_AbortRegistration: String = "newsletter.abortRegistration" val Activity_SendWelcomeMail: String = "newsletter.sendWelcomeMail" val Activity_SendConfirmationMail: String = "newsletter.sendConfirmationMail" } object Timers { val Timer_EveryDay: BpmnTimer = BpmnTimer("Duration", "PT1M") val Timer_After3Days: BpmnTimer = BpmnTimer("Duration", "PT2M30S") data class BpmnTimer( val type: String, val timerValue: String, ) } object Errors { val Error_InvalidMail: BpmnError = BpmnError("Error_InvalidMail", "500") data class BpmnError( val name: String, val code: String, ) } object Signals { val Signal_RegistrationNotPossible: String = "Signal_RegistrationNotPossible" } } ``` Dank dieser generierten Process‑API musst du dich nicht mehr auf hartkodierte Strings verlassen. Stattdessen referenzierst du die in der API bereitgestellten Variablen, wodurch dein Code direkt mit dem Modell verknüpft wird. Die technischen Details des Modells werden so zu einem integralen Bestandteil deines Codes – auf eine typensichere, lesbare und wartbare Weise. So verändert sich unser ursprüngliches Beispiel: Unser Worker nutzt nun die Process‑API, um den Task-Type zu referenzieren: ``` import de.emaarco.example.NewsletterSubscriptionProcessApiV1 import ... @Component class AbortRegistrationWorker( private val useCase: AbortSubscriptionUseCase ) : DefaultJobWorker( type = NewsletterSubscriptionProcessApi.TaskTypes.Activity_AbortRegistration, ) { private val log = KotlinLogging.logger {} override fun executeTask(client: JobClient, job: ActivatedJob): Map { val input = job.getVariablesAsType(Input::class.java) log.debug { "Received job to abort registration: $input" } useCase.abort(SubscriptionId(input.subscriptionId)) return emptyMap() } data class Input(val subscriptionId: UUID) } ``` Auch in deinen Tests werden alle string-basierten Referenzen durch Konstanten aus der Process‑API ersetzt. ``` import de.emaarco.example.NewsletterSubscriptionProcessApiV1 import ... @Test fun `happy path - user subscribes to newsletter`() { val subscriptionId = UUID.fromString("4a607799-804b-43d1-8aa2-bdcc4dfd9b86") processPort.submitForm(SubscriptionId(subscriptionId)) waitForProcessInstanceHasReachedElement(Activity_ConfirmRegistration) processPort.confirmSubscription(SubscriptionId(subscriptionId)) waitForProcessInstanceHasPassedElement( NewsletterSubscriptionProcessApi.Elements.EndEvent_RegistrationCompleted ) assertThatProcess().isCompleted() assertThatProcess().hasPassedElementsInOrder( NewsletterSubscriptionProcessApi.Elements.StartEvent_RequestReceived, NewsletterSubscriptionProcessApi.Elements.Activity_SendConfirmationMail, NewsletterSubscriptionProcessApi.Elements.Activity_ConfirmRegistration, NewsletterSubscriptionProcessApi.Elements.Activity_SendWelcomeMail, NewsletterSubscriptionProcessApi.Elements.EndEvent_RegistrationCompleted ) verify { sendConfirmationMailUseCase.sendConfirmationMail(SubscriptionId(subscriptionId)) } verify { sendWelcomeMailUseCase.sendWelcomeMail(SubscriptionId(subscriptionId)) } verify { abortSubscriptionUseCase wasNot Called } confirmVerified(sendConfirmationMailUseCase, sendWelcomeMailUseCase, abortSubscriptionUseCase) } ``` Wichtig ist allerdings zu wissen: Das Plugin garantiert nicht, dass dein Code bei Modelländerungen synchron bleibt. Allerdings wird die Wartung deutlich vereinfacht, da du lediglich eine neue API-Version generieren und die betroffenen Bereiche anpassen musst. ## 🚀 Vorteile Nachdem wir nun gesehen haben, was **bpmn-to-code** macht und wie es in einem Projekt verwendet werden kann, lass uns einen Schritt zurücktreten und die Hauptvorteile untersuchen, die das Plugin bietet: - **Weniger manueller Aufwand:** Das Plugin extrahiert alle notwendigen API-Elemente direkt aus dem BPMN-Modell und eliminiert mühsames Copy-Paste. - **Schnellere Time-To-Market:** Durch die automatische Generierung von Code-Artefakten optimierst du deinen Entwicklungsprozess und ermöglichst es, deinem Team, sich auf die Bereitstellung der Lösung zu konzentrieren. - **Reduzierung von Fehlerquellen:** Durch die automatische Generierung des Process-APIs wird die Wahrscheinlichkeit von Tippfehlern oder verpassten Aktualisierungen bei Modelländerungen erheblich reduziert. - **Modell-Code-Konsistenz durch Versionierung:** Da Process APIs jederzeit neu generiert werden können, bleibt Ihr Code mühelos mit dem Modell in Einklang. Jede API-Version erhält eine Versionsnummer, sodass Prozessänderungen nachvollziehbar und eindeutig sind. - **Single-Source-of-Truth**: Statt verstreuten Strings in deiner Codebasis, hast du eine zentrale Prozess-API Datei je Prozess. Die Datei fungiert als Repräsentation deines BPMN-Modells und dient als Referenzpunkt für deine Anwendung. - **Verbesserte Transparenz:** Wenn alle Prozessdetails im Code verfügbar sind, verbessern sich Lesbarkeit und Zugänglichkeit. Diese Transparenz hilft, Inkonsistenzen zu erkennen und fördert bessere Modellierungspraktiken, was letztendlich zu saubereren Lösungen führt. - **Vertrauter Ansatz**: Das Plugin orientiert sich an Tools wie Swagger, und zielt daher darauf ab, es Entwickler leichter zu machen in die Automatisierung von Prozessen mit Process Engines einzutauchen oder diese zu nutzen. ## 🏁 Fazit Das manuelle Kopieren technischer Konfigurationen aus BPMN-Modellen in den Code ist nicht nur mühsam, sondern auch fehleranfällig. Es führt zu unnötigen Komplikationen, insbesondere wenn sich die Modelle weiterentwickeln. Genau dieses Kernproblem wollte ich mit **bpmn-to-code** lösen. Das Plugin generiert sog. **Process‑APIs.** Code-Artefakte, die deine BPMN-Modelle direkt in Kotlin oder Java abbilden. So bleiben Code und Modell synchron, der manuelle Aufwand sinkt. Alles in allem ermöglicht das Plugin saubere, robuste sowie entwicklerfreundliche Automatisierungslösungen. Du willst dein Team im sauberen Umgang mit BPMN und Process-Engines fit machen? [Mehr zu unserem BPMN-Training](/trainings/bpmn-training/). Danke fürs Lesen! _Den kompletten Code und die Dokumentation zum Plugin findest du auf [GitHub](https://github.com/miragon/bpmn-to-code), falls du mehr darüber erfahren möchtest._ _This post was originally published in English on [Medium.com](https://medium.com/miragon/simplifying-process-automation-with-bpmn-to-code-from-bpmn-models-to-process-apis-216adafeb0ac)._ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fbpmn-to-code-prozesse-in-einklang%2F)[](mailto:?subject=Mit%20bpmn-to-code%20deine%20Prozesse%20%26%20Code%20in%20Einklang%20bringen&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fbpmn-to-code-prozesse-in-einklang%2F) ## Marco Schäck Process Development Lead bei Miragon [in Marco kennenlernen](https://www.linkedin.com/in/schaeckm/) [Mehr von Marco](/blog/?author=marco-schäck) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Camunda 7 vs. 8 – Eine Betrachtung durch die Brille von Team Topologies](https://www.miragon.io/blog/camunda-7-vs-8-team-topologies/) BPM Die Migration von Camunda 7 zu 8 erfordert neue Teamstrukturen. Eine Analyse durch die Brille von Team Topologies. Dominik Horn Co-Founder & Geschäftsführer **11\. März 2025**7 Min. Lesezeit # Camunda 7 vs. 8 - Eine Betrachtung durch die Brille von Team Topologies Viele Unternehmen nutzen seit Jahren Camunda 7 als Business-Process-Management-Lösung On-Premise. In der Regel wurde dabei die Camunda Engine in bestehende Java-Anwendung eingebunden und vom Entwicklungsteam eigenständig betrieben. Diese Teams waren im besten Fall stream-aligned organisiert: Sie kümmerten sich sowohl um die Entwicklung neuer Features als auch um den Betrieb ihrer Anwendungen, inklusive der eingebetteten Engine. Ich kann mich noch an meine ersten Schritte mit Camunda vor 10 Jahren erinnern. Getting Started gelesen, Übungsaufgaben erledigt, Anwendung gestartet, läuft. Mit Camunda 8 verändert sich die Architektur grundlegend. Die neue Engine basiert auf einer verteilten und hochskalierbaren Infrastruktur. Zwar ermöglicht Camunda 8 Run zukünftig einen vereinfachten Betrieb, der vor allem die lokale Entwicklung beschleunigt, jedoch ist diese Lösung für einen ausfallsicheren produktiven Einsatz nur eingeschränkt geeignet. Auch die einfache Einbettung in eine Java-Anwendung wie bei Camunda 7 entfällt. Stattdessen entstehen neue Anforderungen an das Wissen rund um verteilte Systeme, Messaging, skalierbare Infrastruktur, Kubernetes und andere Cloud-nahe Technologien. Dies stellt viele Organisationen vor die Herausforderung, dass ihre bisherigen Stream-Aligned Teams nicht mehr ohne Weiteres alle notwendigen Kompetenzen abdecken können – insbesondere dann, wenn Camunda 8 On-Premise (also in der eigenen Infrastruktur) betrieben werden soll. Wie wirkt sich die [Migration zu Camunda 8](/portfolio/camunda-7-migration/) auf die Organisationsstruktur aus und wie können Unternehmen den steigenden Bedarf an Spezialwissen effizient adressieren? Nach eingehender Analyse verschiedener Migrationsszenarien zwischen den beiden Engines stellte ich mir die Frage: „Warum fühlt sich Camunda 8 für Teams, die bereits mit Camunda 7 vertraut sind, so grundlegend anders an?“ Eine Erklärung liefert _Team Topologies_. ## Was ist Team Topologies? Um die organisatorische Auswirkungen einer solchen technischen Veränderung zu verstehen, lohnt ein Blick auf _Team Topologies_ von Matthew Skelton und Manuel Pais. Diese beschreiben sowohl vier grundlegende Teamtypen als auch die Interaktionsmuster zwischen diesen Teams. Team Topologies ist ein Organisationsmodell, das beschreibt, wie Teams in einer Produktentwicklungsumgebung strukturiert werden können und miteinander interagieren sollten. Im Kern geht es darum, Teams so zu gestalten, dass sie möglichst autonom arbeiten. Dabei unterscheidet das Modell in **vier grundlegende Teamtypen**: - **Stream-Aligned Team** - Fokussiert auf die schnelle Lieferung von End-to-End-Features und den direkten Mehrwert für Kunden oder Fachabteilungen. - Besitzt in der Regel die Autonomie, Entwicklung und Betrieb (DevOps) weitgehend selbst zu übernehmen. - **Platform Team** - Bietet zentrale Services, Dokumentationen und Plattform-Komponenten für andere Teams. - Das Ziel besteht darin, wiederholende, komplexe Themen zu abstrahieren und als Self-Service zur Verfügung zu stellen um damit die kognitive Last des Stream-Aligend Teams zu verringern. - **Complicated-Subsystem Team** - Verantwortet einen besonders komplexen oder hochspezialisierten Teil des Systems, den ein normales Stream-Aligned Team nicht alleine betreuen kann. - Typischerweise mit ausgeprägtem Fach- oder Technologiewissen in einem Bereich, z. B. KI, hochoptimierte Algorithmen oder eben auch BPM-Engines. - **Enabling Team** - Unterstützt andere Teams durch Coaching, Beratung und temporäres Enabling. - Baut Brücken zwischen Innovation (neue Tools/Methoden) und deren produktivem Einsatz in den Stream-Aligned Teams. Team Topologies definiert zudem klare Interaktionsmuster, um einen reibungslosen Ablauf zu ermöglichen. Ziel ist es, durch diese klaren Strukturen, die kognitive Last der Stream-aligned Teams zu verringern und dadurch die Produktentwicklung zu beschleunigen. > 💡Das Buch zu Team Topologies bietet eine ausführliche Einführung in das Thema. Dort erwarten Dich viele weitere spannende Themen wie Conway’s Law, Interaction Modes und Fracture Planes! ## **Unterschiede in der Architektur von Camunda 7 und Camunda 8** Damit wir verstehen, woher der zusätzliche organisatorische Aufwand bei einer Camunda-8-Migration kommt, ist es wichtig, **die wesentlichen technischen Differenzen zwischen Camunda 7 und Camunda 8** zu beleuchten. Diese Unterschiede helfen dabei aufzuzeigen, **warum** sich der Betrieb nicht mehr „nebenbei“ in einem einzigen Team abbilden lässt und **warum** sich daraus ein größerer Bedarf an spezialisiertem Wissen ergibt. - **Camunda 7** - Monolithische Engine, die meist direkt in Java-Anwendungen eingebettet wurde oder als Remote Engine pro Projekt verwendet wurde. - Häufiger Ansatz: Das Stream-Aligned Team betreut sowohl die fachlichen Prozesse als auch die Technik der Engine. - Einfache Nachvollziehbarkeit der Prozessdaten. - Betrieb On-Premise ohne große Komplexität möglich. - **Camunda 8** - Verteilte Architektur: Eine hochskalierbare, dezentrale Prozess-Engine mit eigenen Komponenten wie Broker, Gateway und Elasticsearch. - Benötigt tiefe Kenntnisse in Cloud-nativen Technologien (Kubernetes, verteilte Systeme, Monitoring). - Höhere Komplexität beim Nachvollziehen der Prozessdaten, da keine relationale Speichertechnologie in der Engine verwendet wird. - Deutlich komplexerer Betrieb, wenn On-Premise (und nicht in Camunda Cloud) genutzt wird. Der **grundlegende Unterschied** ist also, dass Camunda 7 eher monolithisch, vergleichsweise leicht zu betreiben war und bekannte Speichertechnologien verwendet, während Camunda 8 auf eine verteilte Architektur setzt und somit einen deutlich höheren Aufwand bei Installation, Betrieb und Wartung mit sich bringt, speziell wenn es On Premise genutzt wird. ## **Auswirkungen auf die Nutzung und die Teamstruktur** Mit Camunda 7 konnte ein _Stream-Aligned Team_ noch „nebenbei“ den Betrieb sicherstellen: Die Engine war vergleichsweise unkompliziert. Bei Camunda 8 hingegen stößt ein klassisches Stream-Aligned Team schnell an Grenzen: - **Technologische Tiefe**: Die neue Architektur erfordert spezielles Wissen (Kubernetes, Messaging, Skalierbarkeit). - **Monitoring & Observability**: Das Monitoring eines verteilten Systems ist komplexer als in einer integrierten Architektur. - **Wartung & Updates**: Das Update- und Patch-Management der Camunda 8 Infrastruktur ist aufwendiger. Auch Themen wie Backups oder Disaster Recovery erfordern weiterreichende Kenntnisse in Operations. Ein _Stream-Aligned Team_ kann diese Expertise oft nicht vollumfänglich aufbauen und gleichzeitig die eigentliche Fachentwicklung stemmen. Es besteht daher die Gefahr von Engpässen und einer Überlastung einzelner Experten. ## **Plattform- oder Complicated-Subsystem-Team als Lösung** Um Camunda 8 On-Premise professionell zu betreiben, empfiehlt sich die Einführung eines speziellen Teams – je nach Kontext als **Platform Team** oder **Complicated-Subsystem Team**: - **Platform Team** - Stellt die Camunda-8-Infrastruktur als einen klar definierten Service für die Stream-Aligned Teams bereit. Das gilt sowohl für zentrale Cluster, als auch die Bereitstellungen von eigenen Instanzen. - Ähnlich wie bei Datenbanken oder Kubernetes-Clustern entfällt für das Stream-Aligned Team der Betrieb, sodass sie sich auf die fachliche Umsetzung von Prozessen konzentrieren können. **Complicated-Subsystem Team** - Hat tiefgehende Spezialkenntnisse in Kubernetes und ist verantwortlich für die Weiterentwicklung und Betreuung der BPM-Infrastruktur des Teams rund um Camunda 8. - Arbeitet in enger Zusammenarbeit mit den Stream-Aligned Teams, um die Anforderungen umzusetzen ### **Welche Variante ist besser?** Ich würde empfehlen zunächst mit einem Complicated-Subsystem Team zu starten, um die Komplexität besser immer Griff zu haben. So können erste Erfahrungen gesammelt und durch eine enge Collaboration mit dem Stream-Aligned Team schnell Änderungen vorgenommen und Probleme beseitigt werden. Die Änderungs- und Innovationszyklen bleiben so zu Beginn kurz. Sobald das Unternehmen eine gewisse Reife in der Nutzung von Camunda 8 erreicht und sich abzeichnet, dass der Bedarf an Prozessautomatisierung skaliert, kann das Complicated-Subsystem Team in ein Platform Team überführt werden. Damit wird die Lösung so bereitgestellt, dass die Stream-Aligned Teams die BPM-Plattform als Service nutzen können – ähnlich wie bei anderen zentralen Infrastrukturangeboten. Diese Transformation erfolgt in der Regel schrittweise und ermöglicht eine kontrollierte Skalierung über mehrere Projekte und Teams hinweg. ## **Wie Camunda SaaS die Komplexität reduziert** Alternativ zum On-Premise-Betrieb kann **Camunda SaaS** vieles vereinfachen. Dabei übernimmt der Hersteller die Bereitstellung und Wartung der verteilten Infrastruktur. Die Vorteile: - **Outsourcing des Betriebs**: Das komplizierte Cluster-Management liegt bei Camunda. - **Skalierung on demand**: Teams müssen sich nicht um die Skalierung der Engine kümmern. - **Schneller Einstieg**: Weniger Initialaufwand in Wissen, Infrastruktur und Monitoring. Dadurch entfällt die Notwendigkeit eines Plattform Teams und das Unternehmen kann wichtige Ressourcen anderweitig verwenden. ## **Zusammenfassung** Während Camunda 7 On-Premise problemlos von einem Stream-Aligned Team genutzt und betrieben werden konnte, ist das bei einem Camunda-8-Einsatz On-Premise deutlich aufwändiger. Die neue Architektur verlangt spezialisiertes Wissen rund um Cloud-native Technologien und verteilte Systeme. Ein Betrieb durch ein einzelnes Stream-Aligned Team übersteigt oft die vorhandene Expertise und Kapazität. Stattdessen sind dedizierte Experten-Teams gefragt, etwa als Platform Team oder Complicated-Subsystem Team. Eine sinnvolle Herangehensweise ist es, zunächst mit einem Complicated-Subsystem Team zu starten und dieses Team im weiteren Verlauf zu einem Platform Team auszubauen, sobald das Unternehmen Camunda 8 stärker skaliert. Unternehmen, die diese Komplexität umgehen wollen, können auf Camunda SaaS zurückgreifen, wo Betrieb und Skalierung bereits vom Hersteller übernommen werden. Dadurch bleibt mehr Freiraum in den Stream-Aligned Teams, um sich auf das fachliche Prozessdesign und die eigentliche Wertschöpfung zu konzentrieren. Ein punktuelles Enabling Team kann zusätzlich den Know-how-Aufbau beschleunigen und so eine reibungslose Migration zu Camunda 8 unterstützen. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fcamunda-7-vs-8-team-topologies%2F)[](mailto:?subject=Camunda%207%20vs.%208%20%E2%80%93%20Eine%20Betrachtung%20durch%20die%20Brille%20von%20Team%20Topologies&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fcamunda-7-vs-8-team-topologies%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht](https://www.miragon.io/blog/camundacon-2026-schwierige-camunda-8-migrationen/) BPM Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead **01\. Juni 2026**12 Min. Lesezeit Auf der **CamundaCon 2026 in Amsterdam** durfte ich gemeinsam mit [Maria Alish](https://www.linkedin.com/in/maria-alish/), Product Manager & Business Analyst bei der IBA Group, einen Vortrag halten. Der Titel: _„Beyond the Happy Path: Dealing with difficult Migrations”_. Genau darum ging es uns: nicht um die glatte Demo-Migration, sondern um die Stellen, an denen es in echten Projekten knirscht. Wir sehen in Projekten immer wieder dasselbe Muster: [Eine Migration auf Camunda 8](/portfolio/camunda-7-migration/) wird als technisches Upgrade behandelt. Neue Engine, gleiche Prozesse, gleiche Business-Logik und dann ist man auch schon fertig. In der Realität ist das einer der teuersten Denkfehler, den man machen kann. Für alle, die nicht in Amsterdam dabei sein konnten, fassen wir hier die wichtigsten Erkenntnisse zusammen und stellen die vollständige Aufzeichnung des Vortrags zur Verfügung. ## Die Aufzeichnung des Vortrags ## Keine Migration, sondern eine Plattform-Transformation Camunda 7 hat einen konsequenten Developer-First-Ansatz verfolgt. Die Engine ließ sich als Java-Bibliothek direkt in die eigene Anwendung einbetten, meist in einen Spring-Boot-Service, und lief damit in derselben JVM wie der restliche Code. Sie nutzte dieselbe Datenbank wie die Anwendung, nahm an derselben Transaktion teil, und je nach Bedarf standen verschiedene Deployment-Optionen vom embedded Betrieb über eine geteilte bis hin zur Remote-Engine zur Verfügung. Für ein Entwicklungsteam bedeutete das volle Kontrolle, eine durchgängig lokale Ausführung und ein Setup, das sich schlicht beherrschbar anfühlte. Camunda 8 verfolgt dagegen einen grundlegend anderen Anspruch: Es ist keine eingebettete Engine mehr, sondern eine Orchestrierungs-Plattform, die Menschen, Systeme, Geräte und zunehmend auch AI-Agenten miteinander verbindet. Dieser Wechsel verändert nicht nur, _wie_ du die Engine betreibst. Er verändert, _wie deine Teams strukturiert sind_ und was Migration überhaupt bedeutet. Deshalb ist der Schritt zu Camunda 8 kein technisches Upgrade, sondern eine Plattform-Transformation. Wer das ignoriert, geht die Migration mit dem Camunda-7-Mindset an und wundert sich, dass Erwartung und Realität auseinanderlaufen. ## Organizational Readiness: Camunda 8 ist nicht mehr dein Tomcat Der erste und oft unterschätzte Block ist die organisatorische Bereitschaft überhaupt migrieren zu können. Viele Unternehmen, gerade im Corporate-Umfeld und in der DACH Region, verlassen sich noch auf klassische Application Server. Camunda 8 ist aber kein WAR auf einem Tomcat mehr: - **Kubernetes wird vorausgesetzt.** Camunda 8 braucht eine echte Kubernetes-Umgebung mit PersistentVolumeClaims, mehreren Nodes und idealerweise einer Verteilung über mehrere Availability Zones. - **Netzwerk-Latenz wird plötzlich relevant.** Zeebe repliziert seine Daten über das Raft-Protokoll zwischen den Brokern. Camunda empfiehlt deshalb, unter 50 ms Latenz zwischen den Broker- und Datastore-Nodes zu bleiben. - **Der sekundäre Datastore.** Lange war Elasticsearch faktisch Pflicht. Wer dort die Index-Lifecycle-Policies vernachlässigt, sprengt schnell den Heap des Clusters, und ab diesem Punkt wird kein Event mehr exportiert. Die seit Kurzem verfügbare RDBMS-Unterstützung entschärft genau diesen Schmerz erheblich. So weit die Theorie. Wie das in der Praxis kippt, zeigen drei Beispiele aus echten Projekten. ### Banking: Wenn die Infrastruktur die Migration ins Stocken bringt Eine Bank mit entkoppelter Camunda-7-Architektur wollte auf einen geteilten Camunda-8-Cluster wechseln. Schnell zeigte sich dabei das _Noisy-Neighbour-Problem_: Sobald die KYC-Domäne morgens 10.000 Prozesse gleichzeitig startet, leiden sämtliche anderen Domänen auf demselben Cluster mit. Die naheliegende Lösung, nämlich ein eigener Cluster pro Domäne, war schnell gefunden. Doch nach erheblichem zeitlichem Invest stellte sich heraus, dass das Infrastruktur-Team gar keinen Zugriff auf PersistentVolumeClaims hatte und auch keine passende Hardware bereitstand. Die Migration kam dadurch vollständig zum Stillstand. **Nicht wegen der Engine, sondern wegen der Komplexität der Infrastruktur.** ### Retailer: Die Migration, die rückwärts ablief Ein großer Retailer hatte die Anforderung, an jedem einzelnen Standort redundante On-Premise-Cluster zu betreiben, was in Summe auf rund 60 Camunda-8-Cluster hinauslief. Das Operations-Team ging daraufhin auf die Barrikaden und erklärte einen Betrieb in dieser Größenordnung schlicht für nicht leistbar. All dies resultierte in einer Migration zurück auf Camunda 7. Und auch hier lag der Grund nicht in einer schlechten Engine, sondern darin, dass die operative Realität nicht zu den organisatorischen Rahmenbedingungen passte. ### Versicherung: Wenn JBoss auf Zeebe trifft Eine Versicherung migrierte von einer Legacy-BPM-Engine, die ebenfalls als embedded Service eingebunden ist. Entwicklung und Betrieb waren dort strikt voneinander getrennt, und das Infrastruktur-Team kam aus der klassischen Application-Server-Welt rund um JBoss. Den Betrieb eines verteilten Zeebe-Clusters auf Kubernetes empfanden sie entsprechend als eine völlig neue Disziplin, und diese Lücke lässt sich nicht mit einem zweitägigen Training schließen. Das nötige Vertrauen entsteht erst über sogenannte _Game Days_, bei denen das Team Incidents gezielt simuliert und den Ernstfall so lange übt, bis der Betrieb wirklich sitzt. Die Quintessenz dieses Blocks lautet: **Choose SaaS if you can, self-manage if you must.** Wer keine Site Reliability im Haus hat, fährt mit SaaS meist nicht nur einfacher, sondern auch wirtschaftlich besser. Die Total Cost of Ownership eines selbst betriebenen Camunda 8 ist dramatisch höher als beim alten Tomcat-Setup. ## Team Topologies: Dein Dev-Team ist nicht dein Infra-Team Wie im vorherigen Teil erläutert, bricht Camunda 8 das embedded-Engine Modell auf. Das hat auch Konsequenzen für das Teamsetup. In Camunda 7 lag die gesamte Verantwortung bei einem einzigen stream-aligned Team: Die Engine war Teil der Anwendung, also hat dasselbe Team sie deployt, betrieben und damit war die Sache erledigt. Mit Camunda 8 kommen dagegen Broker, Gateways, Exporter, eine eigene Datenbank, Monitoring, Backups und Disaster Recovery hinzu, und all das folgt einem anderen Skillset und einem eigenen Lebenszyklus. In Summe wächst die kognitive Last so stark, dass ein einzelnes Feature-Team sie nicht mehr stemmen kann. Unsere Empfehlung für Teams, die von C7 nach C8 wechseln: nicht sofort ein Platform-Team aufsetzen. Startet stattdessen mit einem **Complicated-Subsystem-Team** aus Kubernetes- und Camunda-8-Experten, das eng mit den stream-aligned Teams zusammenarbeitet und über die nicht-funktionalen Anforderungen der Plattform diskutiert. Erst wenn das stabil läuft, lässt es sich zu einem Platform-Team weiterentwickeln, das Camunda 8 als internen Self-Service bereitstellt. Diese Perspektive haben wir bereits ausführlich beleuchtet. Wer tiefer einsteigen will, findet sie in unserem Beitrag [Camunda 7 vs. 8: Eine Betrachtung durch die Brille von Team Topologies](/blog/camunda-7-vs-8-team-topologies/). ## Wo sollte man anfangen? Mit Camunda 7 wirkten Prozesse oft angenehm strukturiert: klare Pfade mit klaren Übergängen, vergleichbar mit einem Fluss, über den nur ein paar wenige Brücken führen. Die tatsächliche Prozesslandschaft eines Unternehmens gleicht aber eher einer Stadt mit unzähligen, miteinander verbundenen Kanälen, in der zahlreiche Systeme über viele Abläufe hinweg voneinander abhängen. Was auf den ersten Blick einfach aussieht, ist es bei genauerem Hinsehen nur selten. Daraus folgt der wichtigste strategische Grundsatz: **Niemals migrieren um des Migrierens willen. Migriere, um Wert zu schaffen.** Eine Migration, die nur das Bestehende auf einer neuen Engine nachbaut, hat keinen sichtbaren Business Outcome und ist damit das Erste, was gestrichen wird, sobald andere Prioritäten drängen. Der bessere Ansatz: Beginne mit einem Prozess oder einer Domäne, die ohnehin modernisiert gehört, und nutze die Migration als Anlass für diese Verbesserung. Die erste Migration ist die erste Brücke in deinem neuen System. Bau sie an der richtigen Stelle, beweise das Muster an einem **Lighthouse-Projekt**, das sinnvoll, aber nicht geschäftskritisch ist, und der Rest wird zu Execution statt Innovation. ## Key Decisions: Kein Big-Bang Dependency Swap Bei den fundamentalen Entscheidungen, von Deployment bis Implementierung, ist die wichtigste: Tausche nicht einfach die Abhängigkeit aus und hoffe, dass alles läuft. Bewerte zuerst deine Prozesslandschaft. Manche Prozesse, die du vor fünf Jahren automatisiert hast, sind heute kein Wertbeitrag mehr, dafür gibt es inzwischen passende Standardprodukte. Ein hilfreiches Werkzeug für diese Bewertung ist [**Wardley Mapping**](/blog/wardley-mapping-prozesslandschaften/): Es ordnet deine Prozesse entlang ihrer Evolution ein, von der individuellen Eigenentwicklung bis zur austauschbaren Commodity. So wird sichtbar, wo sich ein Standardprodukt lohnt und wo eine eigene Orchestrierung tatsächlich einen Wettbewerbsvorteil schafft. Für die übrigen lohnt sich eine **Abstraktionsschicht** vor der Engine, ähnlich wie niemand mehr herstellerspezifisches SQL direkt schreibt. Genau dafür haben wir vor einiger Zeit die [Process Engine API](https://github.com/bpm-crafters/process-engine-worker) vorgestellt, die bei vielen Kunden produktiv im Einsatz ist und einen sauberen ersten Migrationsschritt ermöglicht. Der Grund, warum ein Big-Bang Dependency Swap so gefährlich ist, ist die **Consistency Trap**, und sie trifft besonders diejenigen, die von embedded Camunda 7 kommen (remote/external Engines sind hier fein raus). In Camunda 7 lief alles in einer ACID-Transaktion: Service Task, Prozesszustand und DB-Write teilten dasselbe Schicksal. Schlug etwas fehl, rollte alles zurück. Camunda 8 arbeitet nach dem BASE-Modell: Das Abschließen eines Zeebe-Jobs und der Write in deine lokale DB sind zwei getrennte Systeme. Es gibt keine gemeinsame Transaktionsgrenze mehr: **Partieller Erfolg wird möglich.** Und das zeigt sich nicht unbedingt in Dev oder Test, sondern unter Last in Produktion. Die daraus entstehenden Failure Modes sind real und keineswegs nur theoretisch: Zeebe arbeitet plötzlich auf Daten, die nach einem Datenbank-Rollback gar nicht mehr existieren, Worker lesen noch nicht committete Zwischenstände, und weil Zeebe nach dem Prinzip _At-least-once_ zustellt, wird dieselbe Aktion gelegentlich doppelt ausgeführt. Eine universelle Lösung für all das gibt es nicht, der richtige Ansatz hängt immer von der konkreten Situation ab. Auf der Bühne haben wir deshalb ein mehrschichtiges Vorgehen gezeigt: - **Layer 1: Steuern, wann Zeebe aufgerufen wird.** Ein After-Transaction-Hook ruft Zeebe erst als Callback auf, nachdem der Datenbank-Commit erfolgreich war. Wer ganz sicher gehen will, greift zum **Outbox Pattern**: Dabei werden die Geschäftsdaten und die Absicht, eine Nachricht zu senden, gemeinsam in einer einzigen ACID-Transaktion gespeichert, und ein separater Scheduler liest diese Nachrichten anschließend aus und stellt sie garantiert an Zeebe zu. Das erkauft man sich allerdings mit zusätzlicher Komplexität in der Codebasis. - **Layer 2: Duplikate sicher behandeln.** Jeder Verarbeitungsschritt muss damit rechnen, dieselbe Nachricht mehrfach zu erhalten. Entweder sind die betroffenen Services von Natur aus idempotent, oder man führt ein Processed-Operations-Log, das festhält, welche Befehle bereits verarbeitet wurden, damit derselbe Befehl garantiert nicht zweimal ausgeführt wird. - **Layer 3: Nutzen, was die Engine selbst bietet.** Zeebe kann eingehende Nachrichten über Message-IDs für eine begrenzte Zeit deduplizieren, und mit ausreichend feingranular modellierten Prozessen lassen sich Mechanismen wie Kompensation und das Saga-Pattern einsetzen, um fehlgeschlagene Teilschritte sauber zurückzurollen. Wie tief dieses Thema geht, zeigt der ausführliche Deep Dive meines Kollegen [Marco](https://www.linkedin.com/in/schaeckm/), der „30-Minuten-Read”, den wir auf der Bühne erwähnt haben: [Leveling up! Wie du die Herausforderung verteilter Transaktionen in Zeebe lösen kannst](/blog/leveling-up-verteilte-transaktionen-zeebe/). Aus diesem Block nehmen wir drei Dinge mit. - **Erstens**: Dein Entwicklungsteam ist nicht automatisch auch dein Infrastruktur-Team, denn beide Rollen verlangen ein unterschiedliches Skillset. - **Zweitens**: Transaktionsgrenzen migrieren nicht von selbst, sondern müssen beim Wechsel auf Camunda 8 bewusst neu durchdacht werden. - **Und drittens**: Binde dich nicht direkt an die API der Engine, sondern an eine Abstraktionsschicht, denn Camunda hat die APIs in den vergangenen Releases mehrfach verändert. ## Die typischen Pitfalls Migrationsprojekte scheitern nur selten allein an der Technologie, viel häufiger sind es falsche strategische Entscheidungen, die ein Projekt zu Fall bringen. Die folgenden Fallen begegnen uns dabei immer wieder: - **Kein Business Value.** Solange eine Migration keinen messbaren Outcome liefert, verliert sie im Wettbewerb mit echten Geschäftsprioritäten schnell an Bedeutung und wird als Erstes zurückgestellt. - **Der Big-Bang.** Der Versuch, alles auf einmal zu migrieren, erzeugt maximale Komplexität und maximales Risiko und nimmt dem Team gleichzeitig jede Möglichkeit, unterwegs zu lernen. So lässt sich nachhaltig keine Erfahrung aufbauen. - **Neues Spiel mit altem Mindset.** Camunda ist längst nicht mehr nur eine eingebettete Engine, sondern entwickelt sich konsequent zur Orchestrierungs-Plattform. Wer das Produkt noch mit der Erwartungshaltung von Camunda 7 betrachtet, wird zwangsläufig enttäuscht, weil Anspruch und Realität nicht mehr zusammenpassen. ## Ein Blick auf Camundas Roadmap Für das [Release **8.10 (Oktober 2026)**](https://roadmap.camunda.com/tabs/27--roadmap) zeichnen sich konkrete Bausteine ab: ein Unified Hub (Modeler + Console), Workspaces & Projects, ein Private Catalog für Wiederverwendung von Prozessbausteinen, AI-Enablement über MCP und Skills sowie automatisiertes Backup & Restore. Aus Business-Sicht geht es dabei nicht um die einzelnen Features, sondern um drei Probleme, die jedes Unternehmen beim Skalieren von Automatisierung trifft: **Coordination** (wie mehrere Teams gemeinsam Prozesse bauen und betreiben), **Governance** (Konsistenz und Compliance) und **Trust** (Orchestrierung zuverlässig genug für produktive, geschäftskritische Workflows). ## Wann migrieren? Es geht nicht um Timing, sondern um Readiness Viele fragen uns: Sollen wir jetzt oder lieber später migrieren? Wir würden die Frage anders stellen: _Sind wir im strategischen Fenster, in dem die Migration tatsächlich Business Value schafft?_ Wer **zu früh** startet, lässt sich vom Hype treiben: Es fehlt an einer Plattformstrategie, an einem Lighthouse-Projekt und an einem Platform-Team, und so experimentiert man zwar, kommt aber nie ins Skalieren. Wer **zu spät** startet, lässt sich von Deadlines treiben, überstürzt die Migration und schleppt dabei technische Schulden mit. Das **strategische Fenster** liegt genau dazwischen, nämlich dort, wo die Migration Teil einer größeren Transformation ist und auf eine vorhandene Cloud-Strategie, echte Orchestrierungs-Bedarfe und klare Geschäftsziele trifft. Erst dann hört die Migration auf, ein reiner Kostenfaktor zu sein, und beginnt tatsächlich, Wert zu schaffen. Deshalb bedeutet „mit der Migration beginnen” zunächst nicht, Code zu schreiben, sondern Klarheit zu schaffen. Es geht darum, die eigenen Prozesse und die gesamte Systemlandschaft wirklich zu verstehen und zu erkennen, an welchen Stellen Orchestrierung überhaupt einen Unterschied macht. Letztlich entscheidest du damit, wie du die nächsten zehn Jahre Prozessautomatisierung betreiben willst. Bevor du startest, solltest du dir deshalb drei ehrliche Fragen stellen: 1. Hast du einen klaren Grund für die Migration? 2. Weißt du, wo du anfängst? 3. Hast du die Fähigkeit, Camunda 8 in Produktion zu betreiben? Bleibt eine dieser Antworten unklar, solltest du dir mehr Zeit für die Vorbereitung nehmen. Denn am Ende entscheidet die Readiness, nicht der Kalender. ## Lass uns über deinen Fall sprechen Wenn dich etwas davon abgeholt hat, freuen wir uns über den Austausch, egal ob du gerade vor der Entscheidung stehst oder schon mitten in einer Migration steckst. Sag einfach Hallo, bei [mir](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/) auf LinkedIn. Ich freue mich darauf, von deinem Projekt zu hören. Und falls du den Vortrag noch einmal in Ruhe ansehen möchtest: Die [vollständige Aufzeichnung von der CamundaCon 2026](https://player.vimeo.com/video/1194380189) findest du auf Vimeo. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fcamundacon-2026-schwierige-camunda-8-migrationen%2F)[](mailto:?subject=Beyond%20the%20Happy%20Path%3A%20Was%20eine%20Camunda-8-Migration%20wirklich%20schwer%20macht&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fcamundacon-2026-schwierige-camunda-8-migrationen%2F) ## Thomas Heinrichs Solution Architecture Lead bei Miragon [in Thomas kennenlernen](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/) [Mehr von Thomas](/blog/?author=thomas-heinrichs) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Component-Tests mit JUnit](https://www.miragon.io/blog/component-tests-mit-junit/) Softwareentwicklung Eine Teststrategie für Spring-Boot Java-Backends mit JUnit 5, Mockito und H2 - vom Testdiamanten bis zur Datenvalidierung. Andreas Riepl Consultant **01\. Juli 2022**6 Min. Lesezeit _Co-Author: Fabian Bösel_ Das Testen eines Systems hat das Ziel, Fehler beim Entwickeln zu minimieren und Fehlerursachen schneller zu finden. Ein Softwaresystem sollte auf mehreren Ebenen getestet werden, wobei sich die jeweiligen Anforderungen unterscheiden und verschiedenen Zielen dienen. In diesem Blog-Post stellen wir unsere Teststrategie vor und zeigen ausführlich, wie wir diese auf unsere in Spring-Boot geschriebenen Java-Backends anwenden. ## Klassischer Ansatz einer Teststrategie Ein klassischer Ansatz zur Abstraktion der verschiedenen Tests veranschaulicht die sog. Testpyramide, die diese in drei Ebenen gliedert: Auf der untersten Ebene befinden sich **Unit-Tests**. Sie sind einfach zu schreiben, können schnell ausgeführt werden und werden dazu eingesetzt, einzelne Komponenten unabhängig vom weiteren System zu testen, um eine hohe Testabdeckung zu erreichen. Die Entwickler sollten die zugehörigen Unit-Tests möglichst bei jeder Änderung ausführen und aktualisieren. So lassen sich potenzielle Fehlerursachen einfach identifizieren. Unit-Tests eignen sich besonders zum Testen von Methoden, wobei deren Abhängigkeiten gemocked sind. **Integrationtests** befinden sich eine Abstraktionsschicht darüber und testen Komponenten im Zusammenspiel mit deren Abhängigkeiten. In diese Kategorie fallen sowohl Tests, die verwendete Frameworks mit einbeziehen (z.B.: Spring MVC), als auch Oberflächentests, wie Cypress- oder Selenium-Tests. Abhängigkeiten werden dabei nicht oder nur teilweise gemockt. In der Regel sind solche Tests nicht nur aufwändiger zu schreiben, sondern brauchen auch mehr Zeit bei der Ausführung. Deshalb bietet es sich an, diese automatisiert bei jedem Push in das Code-Repository auszuführen. Die Spitze der Testpyramide bilden die **manuellen Tests**, wobei ein menschlicher Tester das System auf Benutzer-Ebene testet, um zu gewährleisten, dass bestimmte Anforderungen an das Endsystem, wie vorgesehen funktionieren, ohne dabei auf die konkrete Implementierung einzugehen. Diese Art von Tests dauern am längsten und sind aus Projektsicht am teuersten. Mit dem Vorgehen, die Abdeckung anhand der Ausführungskosten zu skalieren lässt sich die Qualität des Produktes am effizientesten erhöhen. ## Unsere Teststrategie Unser Ziel ist es, die manuellen Tests bei den React Anwendungen so gut es geht zu reduzieren, weshalb wir zur Automatisierung das Oberflächentestframework _Cypress_ einsetzen. Die Backends sind in Java geschrieben und basieren auf dem Spring-Boot Framework. Wie in unserem [Beispielprojekt](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-backend) zu sehen ist, gliedert sich die Backendstruktur für jede Domäne in die drei Ebenen “api”, “domain” und “infrastructure”, wobei unsere Business-Logik (Services & Facades) in der domain-Ebene zu finden ist. Für das Mapping der Objektrepräsentationen zwischen den Ebenen (Transport Objekte, Domain Objekte und Entities) setzen wir Mapstruct ein. Die Entities werden mit der Java Persistence API (JPA) in eine Postgres-Datenbank synchronisiert. Da die eingesetzten Frameworks selbst über eine hohe Testabdeckung verfügen, macht es wenig Sinn, deren Funktionsweise mit eigenen Tests zu überprüfen. Unser Hauptaugenmerk liegt vielmehr auf unserer Business-Logik, die für jede Domäne die grundlegenden Datenoperationen (CRUD: **C**reate, **R**ead, **U**pdate, **D**elete) verwaltet. Zusammengefasst fokussieren wir uns sowohl frontend- als auch backendseitig auf Integrationstests. Um diese besser voneinander differenzieren zu können, beizeichnen wir die Oberflächentests als **“End-To-End-Tests”** und die Service-/ Facadetests der Backends als **“Component-Tests”**. Da die Component-Tests gleichzeitig den Code mittesten, der in private Service-Methoden ausgelagert ist, sind klassische Unit-Tests in unserem Projekt nur noch Tests zur Datenvalidierung. Somit haben wir bildlich gesprochen keine Testpyramide im klassischen Sinne mehr, sondern einen **“Testdiamanten”**. ## Testen eines Spring Boot CRUD Services Unsere Erfahrung hat gezeigt, dass Component-Tests nur dann aussagekräftig sind, wenn sie auch unsere Infrastrukturschicht mittesten. Deshalb starten wir unter Verwendung von _Spring-Boot-Data-JPA_ Tests eine _H2_\-Datenbank und testen so indirekt die von _Mapstruct_ generierten Mapper und unsere JPA Repositories mit. Alle Backend-Tests sind nach dem Arrange/Act/Assert-Pattern aufgebaut. Diese übersichtliche Aufteilung gliedert die Testfunktionen in drei einheitliche Teilbereiche. **1\. Arrange**: Führt Aktionen durch, welche am Anfang des Tests für das Setup und die Initialisierung des Test-Prozesses nötig sind, wie zum Beispiel die Aufbereitung von für den Test erforderlichen Daten. **2\. Act**: Ruft zu testende Funktion wird auf. Dies kann zum Beispiel die Ausführung einer Funktion sein oder die Interaktion mit einem anderen System. **3\. Assert**: Überprüft den vorliegenden Zustand mit dem gewünschten Ergebnis. Dabei wird festgestellt, ob ein Test erfolgreich ist oder fehlschlägt. ### Codebeispiel Als Testframework wird in diesem Projekt _JUnit5_ verwendet. Domänenfremde Abhängigkeiten werden durch eine von dem Mock-Framework _Mockito_ bereitgestellte Dummy-Implementierung ersetzt. Grundsätzlich sollten Tests in sich geschlossen sein, weshalb die JPA-Tests die Datenstände nach jedem Tests zurücksetzen. Beim Testen von Service-Komponenten ist dieses Verhalten jedoch unerwünscht, weil sonst bei jedem Read, Update oder Delete erst wieder Daten eingespielt werden müssten. Zusammen mit der Order-Funktionalität von JUnit kann realisiert werden, dass solche Tests mit den Daten eines zuvor ausgeführten anderen Test arbeiten. Veranschaulichen lässt sich dies gut anhand unseres Service-Tests im Beispielprojekt: ``` package io.miragon.example.base.project.domain; @DisplayName("ProjectService") @Import({ProjectMapperImpl.class}) @TestMethodOrder(MethodOrderer.OrderAnnotation.class) public class ProjectServiceTest extends MiragonServiceTest { private ProjectService projectService; @Autowired private ProjectMapper projectMapper; @Autowired private ProjectRepository projectRepository; @BeforeEach public void initService() { projectService = new ProjectService( projectRepository, projectMapper ); } // saves ids for created projects private static Map savedProjectIds = new HashMap<>(); @Order(1) @DisplayName("createProject() creates new project") @ParameterizedTest(name = "Creating Project with customer={0} and address={1}") @MethodSource("io.miragon.example.base.project.testdata.NewProjectAggregator#newProjectDataProvider") @Rollback(false) public void testCreateProject(@AggregateWith(NewProjectAggregator.class) NewProject newProject) { // Act Project savedProject = this.projectService.createProject(newProject); savedProjectIds.put(savedProjectIds.size(), savedProject.getId()); // Assert assertNotNull(savedProject.getId()); assertEquals(newProject.getCustomer(), savedProject.getCustomer()); assertEquals(newProject.getAddress(), savedProject.getAddress()); } @Test @Order(2) @DisplayName("updateProject() updates project") public void testUpdateProject() { // Arrange UpdateProject updateProject = UpdateProject.builder() .customer("Lambor Gini") .address("2931 Milano, Spagettistr. 2") .build(); // Act Project savedProject = this.projectService.updateProject(savedProjectIds.get(0), updateProject); // Assert assertEquals(savedProjectIds.get(0), savedProject.getId()); assertEquals(updateProject.getCustomer(), savedProject.getCustomer()); assertEquals(updateProject.getAddress(), savedProject.getAddress()); } @Test @Order(2) @DisplayName("deleteProject() deletes project") public void testDeleteProject() { // Act this.projectService.deleteProject(savedProjectIds.get(0)); // Assert assertThrows(ObjectNotFoundException.class, () -> projectService.verifyProjectExists(savedProjectIds.get(0))); } } ``` Der beim Anlegen der neuen Projekte verwendete ParameterizedTest ist ein Feature von JUnit 5. Dieser kann im Zusammenspiel mit einem sogenannten ArgumentsAggregator fertige Objekte entgegennehmen. Dadurch bleibt der Code innerhalb der Testklasse sauber und übersichtlich. ``` package io.miragon.example.base.project.testdata; public class NewProjectAggregator implements ArgumentsAggregator { public static Stream newProjectDataProvider() { return Stream.of( Arguments.of("Seppl GmbH", "Bachstraße 1, 82941 Hintadupfing"), Arguments.of("Schorschi AG", "Bohnenallee 62, 72310 Greifenhofen"), Arguments.of("Vinzenz Mur", "Kuhstraße 12, 10329 Hofen") ); } @Override public Object aggregateArguments(ArgumentsAccessor accessor, ParameterContext context) throws ArgumentsAggregationException { return NewProject.builder() .customer(accessor.getString(0)) .address(accessor.getString(1)) .build(); } } ``` ## Testen der Datenvalidierung einer Spring Anwendung > The first and most fundamental rule in security is ‘NEVER TRUST USER INPUT’. Deshalb validieren wir die Transport-Objekte, die an unsere REST-Controller übergeben werden mit dem von Spring Validation Framework. Die folgenden Codesegmente zeigen _beispielhaft_, wie man Validierungs-Annotationen verwendet und diese testet. ``` package io.miragon.example.base.project.api.transport; @Getter @Builder @ToString @AllArgsConstructor @Schema(description = "Data to create a new io.miragon.example.base.project") public class NewProjectTO { @NotNull @NotBlank private final String customer; @NotNull @NotBlank private final String address; } ``` ``` package io.miragon.example.base.project.api.resource; @Slf4j @Validated @RestController @RequiredArgsConstructor @Tag(name = "Project Controller") @RequestMapping("/api/project") public class ProjectController { private final ProjectService projectService; private final ProjectApiMapper projectMapper; @Transactional @PostMapping() @Operation(summary = "Create a new project") public ResponseEntity createNewProject(@RequestBody @Valid final NewProjectTO projectTO) { log.debug("Received request to create a new project: {}", projectTO); final NewProject newProject = this.projectMapper.mapToNewProject(projectTO); return ResponseEntity.ok(this.projectMapper.mapToTO(this.projectService.createProject(newProject))); } } ``` ``` package io.miragon.example.base.project.api; @DisplayName("NewProjectTO Validation") public class NewProjectToValidationTest extends MiragonValidationTest { @Test @DisplayName("Check valid object") public void checkValid() { // Arrange NewProjectTO validNewProject = NewProjectTO.builder() .customer("Something") .address("Something") .build(); // Act Set> constraintViolations = validator.validate(validNewProject); // Assert assertEquals(0, constraintViolations.size()); } @Test @DisplayName("Check invalid: missing customer") public void checkMissingCustomerInvalid() { // Arrange NewProjectTO validNewProject = NewProjectTO.builder() .address("Something") .build(); // Act Set> constraintViolations = validator.validate(validNewProject); // Assert assertEquals(2, constraintViolations.size()); assertThat( constraintViolations.stream().map(ConstraintViolation::getMessage).collect(Collectors.toList()), Matchers.containsInAnyOrder("must not be blank", "must not be null") ); } } ``` Damit sind wir schon am Ende unseres heutigen Posts angekommen. Danke, dass du bis hier hin dabeigeblieben bist! Den vollständigen Code findest du, wie immer, in unserem [Beispielprojekt auf Github](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-backend). Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fcomponent-tests-mit-junit%2F)[](mailto:?subject=Component-Tests%20mit%20JUnit&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fcomponent-tests-mit-junit%2F) ## Andreas Riepl Consultant bei Miragon [in Andreas kennenlernen](https://www.linkedin.com/in/andreas-riepl) [Mehr von Andreas](/blog/?author=andreas-riepl) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Conditional Testing mit Cypress](https://www.miragon.io/blog/conditional-testing-mit-cypress/) Softwareentwicklung Wie bedingte Logik in Cypress-Tests die Wiederholbarkeit von Testsequenzen sicherstellt und Abhängigkeiten zwischen Tests vermeidet. Martin Berner Consultant **22\. Nov. 2021**3 Min. Lesezeit _Also available in English at [Medium.com](https://medium.com/@miragon/conditional-testing-with-cypress-ff73721dd122)._ In diesem Blogbeitrag werden wir über Cypress sprechen. Falls Sie noch nichts von diesem Tool gehört haben - Cypress ist ein Framework, das für das Testen von Webanwendungen entwickelt wurde. Es läuft innerhalb Ihres Browsers und ermöglicht Ihnen die Manipulation und den Zugriff auf die DOM-Elemente. Bei miragon verwenden wir es für End-to-End-Tests unserer Anwendungen innerhalb unserer CI-Pipeline. Wenn Sie sich für Cypress interessieren, können wir Ihnen [diese Einführung aus der offiziellen Dokumentation](https://docs.cypress.io/guides/overview/why-cypress) empfehlen. Wenn Sie [die gut geschriebene Cypress-Dokumentation](https://docs.cypress.io/guides/core-concepts/conditional-testing) lesen, werden Sie feststellen, dass die Autoren aus gutem Grund von der Verwendung bedingter Logik in Ihren Tests abraten. Dennoch gibt es Situationen, in denen bedingte Tests nützlich sein können. Schauen wir uns eine dieser Situationen einmal genauer an. Das folgende Beispiel enthält ein wenig bedingte Logik, um die Wiederholbarkeit einer Testsequenz zu gewährleisten. Stellen Sie sich einen End-to-End-Test vor, bei dem der Benutzer ein Objekt in der Datenbank erstellt. Der zweite Test versucht dann, dieses Objekt wieder zu entfernen. Aber was passiert, wenn der erste Test fehlschlägt? Sie können sicher sein, dass auch der zweite Test fehlschlagen wird! Für diesen Anwendungsfall zeigen wir ein Beispiel, wie man die von einem Test erstellten Daten in einem beforeEach-Hook aufräumt. Das Problem ist, dass wir nicht wissen, ob der erste Test überhaupt funktioniert hat, bevor wir den zweiten Test starten. Wenn wir dieses Problem ignorieren und jedes Mal versuchen, das Objekt zu löschen, wird der zweite Test mit Sicherheit auch fehlschlagen, wenn der erste Test nicht funktioniert hat, weil die Tabellenzeile mit dem Löschen-Button einfach nicht existiert. Um dies zu verhindern, müssen wir unsere Tests umstrukturieren. Anstatt Abhängigkeiten auf vorherige Tests zu haben, werden wir dafür sorgen, dass jeder Test alles, was er braucht, selbst erstellt. Nachdem der Test durchgeführt wurde, gibt es einen zusätzlichen Schritt, der die erstellten Elemente aufräumt. Auf diese Weise haben die beiden Tests keine Abhängigkeiten mehr voneinander. ## Erstellen des Objekts Um das Objekt zu erstellen, müssen wir das Formular ausfüllen und auf die Schaltfläche “Speichern” klicken. Stellen Sie sich die folgende Benutzeroberfläche vor: Um dieses Formular auszufüllen und das Objekt zu speichern, können wir die folgenden Cypress-Anweisungen verwenden. Um jedes Element eindeutig zu identifizieren, fügen wir jedem anklickbaren Element in unseren Anwendungen das Attribut `data-cy` hinzu. Dies werden wir verwenden, um die richtigen Schaltflächen und Eingaben in den folgenden Snippets zu finden. ``` // Button klicken, um die 'Neues Objekt'-Seite zu öffnen cy.get('[data-cy=button-new-object]').click() // Input-Felder Name und Beschreibung füllen cy.get('[data-cy=input-name] input').type('My Object') cy.get('[data-cy=input-description] input').type('This is my object.') // Speichern-Button klicken cy.get('[data-cy=button-save]').click() ``` Die Tabelle sieht dann so aus: ## Aufräumen Um sicherzustellen, dass der zweite Test das Element selbst erstellen kann, bereinigen wir die Liste im beforeEach-Hook, der von Cypress vor dem Start eines Tests ausgeführt wird. Wir durchlaufen jede Tabellenzeile und prüfen, ob das Element denselben Namen hat wie die gesuchte Zeile, und wenn ja, versuchen wir, es zu löschen. Der Befehl wird für jede Zeile der Tabelle ausgeführt, aber wir klicken nur auf den Button “Löschen”, wenn die Zeile den gesuchten Text enthält. Auf diese Weise schlägt der Code nie fehl, unabhängig vom Inhalt der Tabelle. ``` // Über jede Tabellenzeile iterieren cy.get('[data-cy=table-container] > table > tbody tr').each($row => { // Falls die Zeile denselben Namen hat wie das Objekt, nach dem wir suchen if ($row.text().includes('My Object')) { // Den Löschen-Button klicken... cy.get('[data-cy=delete-object-MyObject]') .click() // ...und den Popup-Dialog bestätigen .get('[data-cy=delete-dialog-button-delete]') .click() // Warten, bis das Objekt entfernt wurde cy.get(`[data-cy=delete-object-MyObject]`) .should('not.exist') } }) ``` > Wie bereits erwähnt, fügen wir zu jedem Element ein data-cy-Attribut hinzu. Bei Tabellenzeilen und Listen müssen Sie jedoch sicherstellen, dass jede Zeile ihre eigene ID hat. Dazu wird eine vorhersehbare und eindeutige ID aus dem Inhalt der Zeile oder des Listenelements erzeugt. In einem zukünftigen Blogbeitrag werden wir vielleicht im Detail darüber sprechen. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fconditional-testing-mit-cypress%2F)[](mailto:?subject=Conditional%20Testing%20mit%20Cypress&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fconditional-testing-mit-cypress%2F) ## Martin Berner Consultant bei Miragon [Mehr von Martin](/blog/?author=martin-berner) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [DevOps mit GitHub - Teil 1: GitHub Packages mit Gradle](https://www.miragon.io/blog/devops-github-teil-1-packages-gradle/) Softwareentwicklung Wie GitHub Packages in Verbindung mit Gradle funktioniert - ein Schritt-für-Schritt-Guide zum Veröffentlichen und Verwenden von Artefakten. Alexander Praschek Co-Founder **29\. Mai 2020**6 Min. Lesezeit Vor ziemlich genau einem Jahr kündigte GitHub die Beta für ihr neuestes Produkt an – die **GitHub Package Registry**. Sie sollte das zentrale Repository für Artefakte werden, die aus dem Code entstehen, der bei GitHub gehostet wird. Neben npm sollten Docker, Maven, NuGet und RubyGems unterstützt werden. Sie ist ein weiterer Baustein in GitHubs Strategie, den gesamten Weg von der Erstellung des Codes bis zur Auslieferung zu begleiten. Gleichzeitig wurde GitHub Actions angekündigt, mit denen wir uns im nächsten Teil der Serie beschäftigen werden. Mittlerweile wurde das Produkt in GitHub Packages umbenannt und die Beta-Phase beendet. In diesem Blogbeitrag werden wir einen ersten Blick darauf werfen, wie GitHub Packages in Verbindung mit Gradle funktioniert. ## Was ist GitHub Packages? Während die meisten Artefakte auf MavenCentral zu finden sind, haben viele große Unternehmen zusätzlich interne Package Registries aufgebaut, in denen ihre internen Bibliotheken liegen. GitHub Packages bietet genau das an, indem jedem GitHub-Account eine Registry bereitgestellt wird und jedes Repository gleichzeitig auch als Registry für Artefakte dienen kann. Der Service ist für öffentliche Repositories kostenfrei, private Repositories erhalten 500MB Speicher und 1GB Traffic pro Monat umsonst. Kostenpflichtige Tarife haben höhere Inklusivvolumina. Zusätzlicher Speicher und Traffic kann kostenpflichtig dazugebucht werden [mehr](https://help.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-packages). ## Wie kann ich es in mein Gradle-Projekt einbauen? In den nächsten Abschnitten werden wir Schritt für Schritt ein neues Gradle-Multi-Module-Projekt anlegen und GItHub Packages integrieren. Wir verwenden dafür IntelliJ, aber eclipse sollte ähnliche Funktionalität bereitstellen. > Sämtlicher Code, den wir in den folgenden Abschnitten erstellen, ist auch in diesem Repository zu finden: [https://github.com/Miragon/devops-github-packages](https://github.com/Miragon/devops-github-packages) Dafür legen wir zunächst ein neues Projekt „_devops-github-packages_“ mit zwei Modulen an: „_devops-github-packages-main_“ und „_devops-github-packages-library_“. Das main-Modul wird später eine Abhängigkeit auf das library-Modul haben, welches direkt aus GitHub Packages geladen wird. Anschließend müssen wir die build.gradle im library-Modul anpassen. Dort aktivieren wir das Plugin „maven-publish“ und konfigurieren das Ziel-Repository: ``` plugins { id 'java-library' // Erlaubt das Publishen der Artefakte im Rahmen des Builds id 'maven-publish' } sourceCompatibility = JavaVersion.VERSION_11 group 'io.flowsquad.blog' version '1.0.0' repositories { mavenCentral() } // Konfiguriert das Publishen publishing { repositories { // Das Ziel-Repository maven { // Der Name kann beliebig gewählt werden name = "GitHubPackages" // Die URL des Repositories, in dem die Artefakte veröffentlicht werden sollen url = "https://maven.pkg.github.com/FlowSquad/devops-github-packages" credentials { // Die Zugangsdaten (weiter unten beschrieben) username = project.findProperty("gpr.user") password = project.findProperty("gpr.key") } } } publications { gpr(MavenPublication) { from(components.java) } } } ``` Die Zugangsdaten, die hier angegeben werden, müssen wir für dieses Modul in einer gradle.properties-Datei konfigurieren. Als Username verwenden wir dabei den GitHub-Login und als Key unseren Personal Access Token konfiguriert werden. Diesen legen wir im nächsten Schritt an. ``` gpr.user=githubUser gpr.key=XXX ``` Um einen Personal Access Token anzulegen, müssen wir zunächst in den Profileinstellungen in GitHub links unten auf „Developer settings“ klicken. Dort wählen wir „Personal access tokens“ und dann „Generate new token“. Als Namen wählen wir „GitHub Packages Access Token“. Dieser benötigt folgende Scopes: repo, write:packages, read:packages und read:org (falls das Ziel-Repository innerhalb einer Organisation liegt). Anschließend klicken wir auf „Generate token“ und kopieren den angezeigten Token in die oben erstellte gradle.properties-Datei. Der Token darf natürlich **niemals eingecheckt werden**, da er wie ein Passwort funktioniert. Im library-Modul legen wir nun eine neue Klasse „LibraryClass“ an, die den Code enthält, den wir später aus dem main-Modul heraus aufrufen werden: ``` package io.flowsquad.blog.devops.github.packages.library; public class LibraryClass { public String utilityMethod() { return "Hi, I'm a very expensive library method and do a lot of heavy calculations!"; } } ``` Wenn wir jetzt das Kommando „_./gradlew :devops-github-packages-library:publish_“ ausführen, baut Gradle unsere Bibliothek und veröffentlicht sie auf GitHub. Wir sollten sie dann im Reiter „Packages“ unseres Repositories sehen können: Nun kümmern wir uns um das main-Modul. Auch hier muss die build.gradle angepasst werden. Der Dependencies-Block enthält das Library-Modul, das wir vorhin gebaut haben. Wir könnten natürlich auch direkt das Modul verlinken, aber wir wollen ja GitHub Packages testen, nicht wahr? ;) ``` plugins { id 'java' } sourceCompatibility = JavaVersion.VERSION_11 group 'io.flowsquad.blog' version '1.0.0' repositories { mavenCentral() maven { // Der Name kann beliebig gewählt werden name = "GitHubPackages" // Die URL des Repositories, in dem die Artefakte veröffentlicht wurden url = "https://maven.pkg.github.com/FlowSquad/devops-github-packages" credentials { // Die Zugangsdaten (weiter unten beschrieben) username = project.findProperty("gpr.user") password = project.findProperty("gpr.key") } } } dependencies { compile "io.flowsquad.blog:devops-github-packages-library:1.0.0" } ``` Auch in diesem Modul müssen wir die Zugangsdaten bereitstellen, genauso wie wir das bereits für das library-Modul getan haben. Dafür kopieren wir die gradle.properties-Datei, die wir bereits erstellt haben, in das main-Modul. > Vorsicht: Ein Access-Token ist immer notwendig, um Artefakte herunterzuladen, auch wenn diese in einem öffentlichen Repository liegen! Jetzt fehlt noch die Main-Klasse, in der wir die Utility-Methode aufrufen, die wir in der Library-Klasse erstellt haben: ``` package io.flowsquad.blog.devops.github.packages.main; import io.flowsquad.blog.devops.github.packages.library.LibraryClass; public class MainClass { public static void main(String[] args) { System.out.println(new LibraryClass().utilityMethod()); } } ``` Wenn wir die Anwendung nun starten, lädt Gradle das Artefakt von GitHub herunter, das wir vorher gebaut haben, baut damit das Main-Modul und führt es aus. Wenn alles klappt, sollten wir folgende Meldung auf der Konsole sehen: Wir haben jetzt erfolgreich ein Artefakt auf GitHub Packages veröffentlicht, es heruntergeladen und verwendet. Allerdings gibt es einige Fallstricke, die man kennen sollte, bevor man die Package Registry produktiv einsetzt: 1. **Snapshots funktionieren nicht** Auch wenn in der Dokumentation steht, dass Snapshots unterstützt werden, konnten wir sie nicht zum Laufen bringen. Während die ersten Builds problemlos funktionieren, werden alte Versionen nicht gelöscht. Stattdessen werden immer neue Artefakte zum selben Release hinzugefügt, was irgendwann nicht mehr funktioniert. Ab diesem Zeitpunkt werden alte Snapshots geladen. 2. **Mehrere Artefakte pro Release funktionieren nicht** Sobald man versucht, neben der Bibliothek selbst auch noch JavaDoc- und Sources-Artefakte hochzuladen, wird das Repository instabil. Selbst das Laden existierender Artefakte oder das Veröffentlichen neuer Bibliotheksversionen scheitern dann mit einem 400-Fehler. In unserem Fall half nur noch das Löschen des Artefakts oder Repositories. 3. **Öffentliche Versionen können nicht gelöscht werden** Es ist zwar möglich, Artefakt-Versionen in privaten Repositories zu löschen, bei öffentlichen Repositories erlaubt GitHub das allerdings nicht. Deshalb sollte man sich vorher gut überlegen, was man veröffentlicht und was man für sich behält ;) 4. **Der Token benötigt die korrekten Scopes** Der Personal Access Token, der zum Zugriff auf die Artefakte benötigt wird, muss exakt die oben aufgelisteten Scopes haben, damit alles ordnungsgemäß funktioniert. Falls einer davon fehlt, erhält man Fehlermeldungen, die häufig nicht auf das Fehlen einer Berechtigung schließen lassen! 5. **Dynamische Versionen verhindern das Release** Falls man Spring Boot und die dynamischen Versionen verwendet, schlägt der Release fehl, weil die Versionen nicht statisch sind. Das hat zwar nicht direkt etwas mit GitHub Packages zu tun, ist aber trotzdem gut zu wissen. Um das zu beheben, muss man die build.gradle so anpassen, dass im Publishing-Block auch noch ein versionMapping vorhanden ist: ``` // Siehe oben // Konfiguriert das Publishen publishing { repositories { // Siehe oben } publications { gpr(MavenPublication) { from(components.java) // Behebt den Fehler mit den dynamischen Versionen von Spring Boot versionMapping { usage('java-api') { fromResolutionOf('runtimeClasspath') } usage('java-runtime') { fromResolutionResult() } } } } } ``` [Im zweiten Teil der Blog-Serie](/blog/devops-github-teil-2-packages-actions/) werden wir uns damit beschäftigen, wie wir GitHub Actions verwenden können, um unsere Build-Pipeline so zu automatisieren, dass immer automatisch die neueste Version veröffentlicht wird sobald wir neuen Code einchecken. Bis zum nächsten Mal! _Also published in English at [medium.com](https://medium.com/p/devops-with-github-part-1-github-packages-with-gradle-c4253cdf7ca6?source=email-db0d46ea6585--writer.postDistributed&sk=4f01340ca6040f4d34ea4da1623eb097)._ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fdevops-github-teil-1-packages-gradle%2F)[](mailto:?subject=DevOps%20mit%20GitHub%20-%20Teil%201%3A%20GitHub%20Packages%20mit%20Gradle&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fdevops-github-teil-1-packages-gradle%2F) ## Alexander Praschek Co-Founder bei Miragon [in Alexander kennenlernen](https://www.linkedin.com/in/alexander-praschek/) [Mehr von Alexander](/blog/?author=alexander-praschek) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [DevOps mit GitHub - Teil 2: Packages bauen und veröffentlichen mit GitHub Actions](https://www.miragon.io/blog/devops-github-teil-2-packages-actions/) Softwareentwicklung Wie man GitHub Actions als Build-Pipeline nutzt, um bei jedem Commit automatisch Gradle-Artefakte zu bauen und in GitHub Packages zu veröffentlichen. Alexander Praschek Co-Founder **12\. Sep. 2020**6 Min. Lesezeit Im zweiten Teil dieser Serie werden wir uns damit beschäftigen, wie wir GitHub Actions als Build-Pipeline nutzen können. Bei jedem Commit wird aus unserem Gradle-Projekt ein Artefakt gebaut, das anschließend automatisch in GitHub Packages veröffentlicht wird. Zeitgleich mit der Ankündigung für GitHub Packages wurde auch GitHub Actions angekündigt. Damit wird es möglich, auf Events mit unterschiedlichen Aktionen zu reagieren. Dabei werden zahlreiche unterschiedliche Events unterstützt. Mit GitHub Packages haben wir uns bereits [im ersten Teil dieser Serie](/blog/devops-github-teil-1-packages-gradle/) beschäftigt. Dieser Teil baut auf dem Projekt auf, das wir im ersten Blogbeitrag erstellt haben. ## Was ist GitHub Actions? Im Grunde lässt sich GitHub Actions als eine Pipeline beschreiben, die bestimmte Aktionen als Reaktion auf die bereits erwähnten Events ausführt. Während herkömmliche Pipelines wie bspw. Jenkins normalerweise nur auf neue Commits reagieren und daraufhin einen Build ausführen, ist GitHub Actions breiter aufgestellt. Auch wenn die vermutlich am häufigsten genutzten Events tatsächlich das Pushen neuer Commits und das Erstellen neuer Pull Requests sind, können damit auch Aktionen angelegt werden, die bspw. beim Anlegen eines neuen Issues ausgeführt werden. Alle verfügbaren Events sind [hier](https://docs.github.com/en/actions/reference/events-that-trigger-workflows) aufgelistet. Der Service ist für öffentliche Repositories kostenfrei, private Repositories erhalten 2000 Build-Minuten pro Monat umsonst. Kostenpflichtige Tarife haben höhere Inklusivminuten. Zusätzliche Minuten können kostenpflichtig hinzugebucht werden [mehr](https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions). Aktionen werden normalerweise in Linux-Containern ausgeführt. Aktionen in Windows- oder macOS-Containern werden mit Faktor 2 bzw. 10 abgerechnet. ## Wie funktioniert es? Eine GitHub Action besteht aus einer YAML-Datei, die im Projekt-Repository abgelegt wird. Darin wird definiert, welche Schritte ausgeführt werden. GitHub prüft für jedes Event, ob eine passende Action definiert ist, und führt diese aus. Neben einfachen Bash-Befehlen können auch Actions aus dem Marketplace verwendet werden, die häufig benötigte Aktionen ausführen wie das Auschecken von Quellcode oder das Bereitstellen einer bestimmten Java-Version. Eigene Actions können per NodeJS definiert werden und in eigenen Repositories wiederverwendet werden. Alternativ können diese im Marketplace veröffentlicht und somit allen Anwendern zugänglich gemacht werden. ## Wie kann ich es in mein Gradle-Projekt einbauen? Wir bauen auf dem Projekt auf, das wir im letzten Teil der Serie bereits angelegt haben. Den Code dafür findet ihr [hier](https://github.com/Miragon/devops-github-packages). Alternativ könnt ihr der Schritt-für-Schritt-Anleitung aus dem [letzten Teil folgen](/blog/devops-github-teil-1-packages-gradle/). Im letzten Post haben wir bereits ausprobiert, wie man die gebauten Artefakte manuell in GitHub Packages veröffentlichen kann. Nun werden wir das mit GitHub Actions kombinieren und bei jedem Commit automatisch ausführen. > Sämtlicher Code, den wir in den folgenden Abschnitten erstellen, ist auch in diesem Repository zu finden: [https://github.com/Miragon/devops-github-actions](https://github.com/Miragon/devops-github-actions) ### Die Action erstellen Dafür legen wir zunächst den Ordner `.github/workflows` im Root-Verzeichnis unseres Projekts an. Darin erstellen wir die Datei `publish.yaml`. Diese definiert die Action und sieht wie folgt aus: ``` name: Build & Publish on: # Defines the events that this action responds to push: # Run whenever new commits are pushed branches: [ master ] # Only if target branch is master jobs: build: runs-on: ubuntu-latest # The container to run this action on steps: - name: Checkout sources uses: actions/checkout@v2 # Use action from marketplace - uses: actions/setup-java@v1 with: # Pass parameters to action java-version: '11.0.4' java-package: jdk architecture: x64 - name: Build and publish JAR # Used to execute gradle commands run: gradle \ -Pgpr.key=${{ secrets.GITHUB_TOKEN }} \ -Pgpr.user=$GITHUB_ACTOR \ :devops-github-packages-library:build \ :devops-github-packages-library:publish ``` Innerhalb der Action wird zunächst der Code ausgecheckt. Anschließend wird Java 11 bereitgestellt, ein Gradle-Build ausgeführt und das Ergebnis veröffentlicht. ### Unser Projekt anpassen Im Repository können wir außerdem die Dateien `gradle.properties` in den beiden Modulen entfernen. Zudem müssen wir die `build.gradle`\-Dateien anpassen: 1. Wir erhöhen die Version auf 1.0.1, um beim Publishen einen Versionskonflikt zu vermeiden. Diese Änderung muss in beiden Modulen und im Root-Projekt vorgenommen werden. 2. Wir ersetzen die URL des Zielrepositories, damit es in unserem neuen Repository landet. Diese Änderung muss in beiden Modulen vorgenommen werden. 3. Wir erhöhen die Version der Library-Dependency ebenfalls auf 1.0.1, um das neue Artefakt zu verwenden. Diese Änderung ist nur im main-Modul notwendig. ### Authentifizierung bei GitHub Packages Um erfolgreich pushen zu können, brauchen wir normalerweise einen entsprechenden Token, der uns den Zugriff erlaubt. Falls wir direkt im selben Repository veröffentlichen, benötigen wir diesen Token nicht. Stattdessen können wir die von GitHub automatisch bereitgestellte Variable `$GITHUB_ACTOR` und das Secret `GITHUB_TOKEN` verwenden. Der GitHub Actor ist der Name des Accounts, welcher die Action ausgelöst hat. Der GitHub Token enthält einen temporären Token, welcher Berechtigungen für das aktuelle Repository enthält. ### In ein anderes GitHub Packages Repository publishen Falls es unser Ziel ist, in einem anderen Repository zu veröffentlichen, müssen wir die Properties `gpr.user` und `gpr.token` überschreiben und dafür den letzten Schritt in der `publish.yaml` anpassen. ``` # ... - name: Build and publish JAR # Used to execute gradle commands run: gradle \ -Pgpr.key=${{ secrets.GPR_KEY }} \ -Pgpr.user=${{ secrets.GPR_USER }} \ :devops-github-packages-library:build \ :devops-github-packages-library:publish ``` Anschließend müssen wir in den Repository-Einstellungen zwei neue Secrets anlegen (`GPR_USER` und `GPR_TOKEN`) und darin die Zugangsdaten speichern, die wir bisher in der `gradle.properties`\-Datei hatten. > Die Secrets schützen zwar die Credentials vor einem unerlaubten Kopieren, allerdings kann jeder mit Push-Zugriff auf das Repository sie im Rahmen einer Action verwenden. ### Namenskonflikte verhindern Da wir in ein anderes Repository als im letzten Teil der Serie publishen wollen, müssen wir den Package-Namen ändern. Andernfalls liefert GitHub einen Fehler `422 Unprocessable Entity` zurück. Das liegt daran, dass Package-Gruppe und -Name innerhalb einer Organisation / eines Accounts eindeutig sein müssen. Aus diesem Grund fügen wir folgende Zeile in der `build.gradle` des library-Moduls ein: ``` // Configures the publishing publishing { publications { gpr(MavenPublication) { artifactId 'devops-github-actions-library' // <-- Add this line from(components.java) // ... } } } ``` Außerdem müssen wir die Dependency im main-Modul ebenfalls umbenennen in `devops-github-actions-library`. ### Die Action ausführen Sobald wir unsere Änderungen committen und nach GitHub pushen, wird die neue Action automatisch gestartet. Um dies zu prüfen, öffnen wir GitHub, wo wir neben unserer letzten Commit-Message einen kleinen gelben Punkt sehen. Dieser gibt an, dass die Action gerade läuft. Das Ergebnis wird nach Abschluss des Builds als grüner Haken oder rotes Kreuz dargestellt. Um die Build-Details zu sehen, klicken wir in unserem Repository auf Actions, wählen unseren Commit aus und klicken links auf `Build & Publish / build`. Dort werden die Logs unserer Action live gestreamt, während sie läuft. Sobald der Build abgeschlossen ist, können wir wieder auf die Startseite unseres Repositories wechseln, um dort die neu erstellte Version zu betrachten. ## Fazit In diesem Teil der Serie haben wir das Bauen und Veröffentlichen eines Gradle-Projekts mithilfe von GitHub Actions betrachtet. Im nächsten Teil werden wir das Bauen eines Docker Images in GitHub Actions ausprobieren. _Also published in English at [medium.com](https://medium.com/@miragon/devops-with-github-part-2-building-and-publishing-packages-with-github-actions-3bbe232066ad?source=friends_link&sk=71cfcda8ac13dd4bbcb7f6d00cfa7bc6)._ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fdevops-github-teil-2-packages-actions%2F)[](mailto:?subject=DevOps%20mit%20GitHub%20-%20Teil%202%3A%20Packages%20bauen%20und%20ver%C3%B6ffentlichen%20mit%20GitHub%20Actions&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fdevops-github-teil-2-packages-actions%2F) ## Alexander Praschek Co-Founder bei Miragon [in Alexander kennenlernen](https://www.linkedin.com/in/alexander-praschek/) [Mehr von Alexander](/blog/?author=alexander-praschek) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Digitale Transformation mit Dimacon](https://www.miragon.io/blog/digitale-transformation-dimacon/) Referenzen Wie Miragon mit der Dimacon-Plattform das Kerngeschäft der Handwerksbranche digital transformiert – eine flexible No-Code SaaS-Lösung. Dominik Horn Co-Founder & Geschäftsführer **01\. Jan. 2024**2 Min. Lesezeit Im Jahr 2020 identifizierten wir gemeinsam mit Fachleuten aus der Handwerksbranche, insbesondere im Bereich Betonbohren und -sägen, einen erheblichen Digitalisierungsrückstand. Diese Erkenntnis war der Ausgangspunkt für die Entwicklung einer maßgeschneiderten Software-as-a-Service (SaaS)-Lösung, die in enger Zusammenarbeit mit Praxispartnern entstand, um [das Kerngeschäft dieser Branche digital zu transformieren](/leistungen/). Das Ergebnis dieser Bemühungen ist die Dimacon-Plattform, ein herausragendes Beispiel für die effektive Zusammenarbeit mit Endanwendern zur Steigerung der Benutzerfreundlichkeit. Innerhalb von sechs Monaten Entwicklungszeit wurde die Plattform von den ersten Pilotkunden in Betrieb genommen. Unser Ziel war es, eine intuitiv bedienbare Software zu entwickeln, die sich flexibel an unterschiedliche Organisationsstrukturen und Prozesse anpassen lässt. Die Dimacon-Plattform hat sich schnell als flexible No-Code-Lösung etabliert, die ohne spezielle IT-Kenntnisse genutzt werden kann, wodurch sie breit einsetzbar ist. ## Aufgaben im Projekt **Organisatorische Aufgaben:** - Detaillierte Erfassung und Analyse der Workflows in der Auftragsabwicklung mittelständischer Handwerksunternehmen. - Analyse und Modellierung von zentralen Prozessen und Aufgaben des Kerngeschäfts mit Hilfe von BPMN und DMN, um Effizienz und Genauigkeit zu steigern. **Technologische Aufgaben:** - Entwurf und Implementierung einer hochskalierbaren SaaS-Plattform, die maßgeschneiderte Zugangspunkte für verschiedene Rollen innerhalb der Unternehmen bietet. - Entwicklung von Microfrontends und umfangreichen Webanwendungen, die ein breites Spektrum von Gastzugängen bis zu Management-Suiten abdecken. - Konzeption und Entwicklung einer Cross-Plattform-Mobile-App, um eine nahtlose Nutzung auf verschiedenen Geräten zu ermöglichen. - Einrichtung von DevOps-Pipelines, einschließlich GitOps und Google Cloud Builds, zur Automatisierung des Softwareentwicklungsprozesses. - Implementierung von Development- und Staging-Systemen sowie Testsuites zur Gewährleistung der höchsten Qualitätsstandards. - Anwendung hoher IT-Security Standards, um die Sicherheit und Integrität der Plattform zu garantieren. - Durchführung von vielschichtigen Performanceoptimierungen, etwa durch Caching oder Pagination, um die Benutzererfahrung zu verbessern. - Betrieb der Platttform in Kubernetes in der Google Cloud Plattform ## Eingesetzte Technologien Unser Projekt nutzte eine Vielzahl fortschrittlicher Technologien, um eine robuste und flexible Lösung zu gewährleisten. Dazu gehören Camunda für die Prozessautomatisierung, Spring Boot als Backend-Framework, React und React Native für die Frontend-Entwicklung, Expo für die Cross-Plattform-App-Entwicklung, Redis für das Caching, sowie moderne Tools und Plattformen wie GraphQL, Websockets, Google Cloud Platform (GCP), Auth0 für Authentifizierung und Autorisierung, und Cypress für End-to-End-Tests. Diese Technologieauswahl ermöglichte es uns, eine skalierbare, sichere und benutzerfreundliche Plattform zu entwickeln, die den spezifischen Anforderungen der Handwerksbranche gerecht wird. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fdigitale-transformation-dimacon%2F)[](mailto:?subject=Digitale%20Transformation%20mit%20Dimacon&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fdigitale-transformation-dimacon%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Referenzen 02\. Jan. 2024 ### Prozessautomatisierung in der Intralogistik bei DM Wie Miragon die Intralogistik-IT von DM modernisiert – mit BPMN, Domain-Driven Design und agiler Softwareentwicklung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/prozessautomatisierung-intralogistik-dm/)[ Referenzen 01\. Jan. 2022 ### DigiWF – Landeshauptstadt München Wie Miragon die Landeshauptstadt München bei der Konzeption und Umsetzung einer Plattform zur Digitalisierung und Automatisierung von Workflows unterstützt. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digiwf-landeshauptstadt-muenchen/)[ Referenzen 30\. Juli 2021 ### Durchführung eines t.BPM-Workshops für die Analyse und Visualisierung von Prozessen in der Baubranche Wie Miragon mit der SSB Fidan GmbH in einem t.BPM-Workshop Bauprozesse von der Beauftragung bis zur Rechnungsstellung analysiert und visualisiert hat. Dominik Horn Co-Founder & Geschäftsführer ](/blog/tbpm-workshop-baubranche/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [DigiWF – Landeshauptstadt München](https://www.miragon.io/blog/digiwf-landeshauptstadt-muenchen/) Referenzen Wie Miragon die Landeshauptstadt München bei der Konzeption und Umsetzung einer Plattform zur Digitalisierung und Automatisierung von Workflows unterstützt. Dominik Horn Co-Founder & Geschäftsführer **01\. Jan. 2022**2 Min. Lesezeit Seit Juni 2020 unterstützen wir die Landeshauptstadt München im Projekt neoIT bei der Konzeption und der Umsetzung einer Plattform zur Digitalisierung und Automatisierung von Workflows. Der Fokus liegt auf der Anbindung und Orchestrierung der vorhandenen heterogenen Systemlandschaft, der Umsetzung eines Aufgabenmanagements zur Einbindung von Sachbearbeitern verschiedenster Referate und der Programmierung neuer Anwendungen. Zudem wird eine Co-Creation Entwicklungsumgebung mit Low-Code Funktionalität bereitgestellt, um die Erstellung von Digitalisierungsvorhaben, gemeinsam mit dem Fachbereich, zu ermgölichen. Seit Mai 2021 wird die Plattform zudem für den Einsatz im Projekt “München Portal der Zukunft” vorbereitet, um die Digitalisierung von Ende-zu-Ende Prozessen mit Unternehmen, Bürgern und Organisationen außerhalb der eigenen Organisationen zu ermöglichen. ## Aufgaben im Projekt Wir haben durch unsere vielfältigen Rollen im Projekt großen Einfluss auf den Erfolg, darunter: [Neukonzeption und Implementierung einer Digitalisierungsplattform auf Basis von Camunda](/leistungen/): - Konzeption und Umsetzung eines Aufgabenmangements für die Verteilung von Aufgaben an verschiedene Sachbearbeiter unterschiedlicher Referate - Konzeption und Implementierung einer Low-Code Plattform für die Erstellung neuer Digitalisierungsvorhaben, gemeinsam mit dem Fachbereich - Konzeption und Umsetzung einer Integrationsplattform für das München Portal der Zukunft auf Basis von Camunda und Apache Kafka - Migration der bestehenden Projekte nach GitHub für die zukünftige Open-Source-Entwicklung - Konzeption und Implementierung eines modularer Formular-Frameworks auf Basis der internen Referenzarchitektur Planung und Umsetzung neuer Digitalisierungvorhaben auf der entstandenen Plattform - Analyse der Anforderungen mit dem Fachbereich - Planung und Durchführung von Modellierungsworkshops - Planung und Durchführung von Workshops zur Schulung von Mitarbeitern Betrieb und Monitoring der Plattform: - Erstellung von Dashboards zur Überwachung der Anwendung mit Micrometer, Grafana und Prometheus - Erstellung von CI/CD Pipelines mit GitLab und OpenShift, inkl. Konzeption und Umsetzung einer neuen GitOps Pipeline Repräsentation des Projektes und der Plattform außerhalb der Organisation - Gemeinsame Vorträge auf Konferenzen - Migration der Projekte und ## Eingesetzte Technologien - Camunda - Spring Boot - Vue.js - Kafka - OpenShift - BPMN - DMN Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fdigiwf-landeshauptstadt-muenchen%2F)[](mailto:?subject=DigiWF%20%E2%80%93%20Landeshauptstadt%20M%C3%BCnchen&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fdigiwf-landeshauptstadt-muenchen%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Referenzen 02\. Jan. 2024 ### Prozessautomatisierung in der Intralogistik bei DM Wie Miragon die Intralogistik-IT von DM modernisiert – mit BPMN, Domain-Driven Design und agiler Softwareentwicklung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/prozessautomatisierung-intralogistik-dm/)[ Referenzen 01\. Jan. 2024 ### Digitale Transformation mit Dimacon Wie Miragon mit der Dimacon-Plattform das Kerngeschäft der Handwerksbranche digital transformiert – eine flexible No-Code SaaS-Lösung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digitale-transformation-dimacon/)[ Referenzen 30\. Juli 2021 ### Durchführung eines t.BPM-Workshops für die Analyse und Visualisierung von Prozessen in der Baubranche Wie Miragon mit der SSB Fidan GmbH in einem t.BPM-Workshop Bauprozesse von der Beauftragung bis zur Rechnungsstellung analysiert und visualisiert hat. Dominik Horn Co-Founder & Geschäftsführer ](/blog/tbpm-workshop-baubranche/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Docker-Images mit GitHub Actions und Google Cloud bauen](https://www.miragon.io/blog/docker-images-github-actions-google-cloud/) Softwareentwicklung Wie man mit GitHub Actions und Google Cloud Build Docker-Images als Teil der CI-Pipeline baut und in die Google Cloud Registry pusht. Alexander Praschek Co-Founder **27\. Juli 2021**4 Min. Lesezeit _Also available in English at [Medium.com](https://medium.com/@miragon/building-docker-images-with-github-actions-and-google-cloud-b8894e0edff0)._ Mithilfe von GitHub Actions als Teil der CI-Pipeline Docker-Images mit Google Cloud Build bauen und in die Google Cloud Registry pushen In den letzten Teilen der GitHub Actions-Serie haben wir uns mit dem Gradle-Build beschäftigt. Doch zum Deployment in der Cloud kommen normalerweise fertige Docker-Images und keine JAR-Files zum Einsatz. Wie können wir diese als Teil unserer CI-Pipeline bauen? Zu diesem Zweck haben wir die GitHub-Action `docker-cloud-build` entwickelt und [Open Source in unserem GitHub-Repository](https://github.com/Miragon/docker-cloud-build) zur Verfügung gestellt. Damit kann in nur einem Schritt aus einem Dockerfile und einer Liste an Input-Dateien ein fertiges Docker-Image gebaut werden, das anschließend in der Google Cloud Registry zur Verfügung steht. Zudem kann der Build-Output in der GitHub-Oberfläche dargestellt werden, um auf einen Blick zu erkennen, welches Tag erstellt wurde und ob der Build erfolgreich war. ## Getting Started Um die Action zu verwenden, müssen wir zunächst in der action.yaml einen neuen Schritt hinzufügen. Das sieht dann z.B. so aus: ``` - name: Build Docker Image uses: FlowSquad/docker-cloud-build@v1.0.1 with: gcp-project-id: my-project-id gcp-service-account-key: ${{ secrets.GCP_SA_KEY }} image-name: my-image-name image-sources: build/libs/*.jar,Dockerfile,some-other-file github-token: ${{ secrets.GITHUB_TOKEN }} ``` Die oben dargestellten Optionen sind die Minimalkonfiguration. Über die verfügbaren Parameter kann das Verhalten der Action umfangreich angepasst werden. Der Parameter `gcp-project-id` enthält die ID des Projekts in Google Cloud, das verwendet werden soll. Als Standard-Region für Google Cloud Registry wird `eu.gcr.io` verwendet. Dies kann mit dem Parameter `gcp-gcr-region` angepasst werden. Unter `image-name` wird dann der Name des Images angegeben, welches gebaut werden soll. Das Tag wird dann jeweils dynamisch erstellt. Als `image-sources` werden die Dateien angegeben, die der Build als Input benötigt. Dabei können sämtliche Dateien und Ordner aus dem GitHub-Actions-Workspace angegeben werden. Es werden auch Wildcards wie `*` oder `?` unterstützt. Die Dateien müssen dann im Dockerfile in das fertige Image kopiert werden. ## Authentifizierung Unter `gcp-service-account-token` muss eine Base64-kodierte Service-Account-JSON-Datei angegeben werden. Diese wird für die Authentifizierung bei GCP verwendet. Der verwendete Service-Account benötigt die folgenden Berechtigungen: ``` cloudbuild.builds.create # Benötigt, um Cloud Builds zu starten cloudbuild.builds.get # Benötigt, um den Build-Status abzufragen storage.objects.create # Benötigt, um die Input-Dateien hochzuladen storage.objects.get # ^ ebenfalls storage.objects.list # ^ ebenfalls storage.objects.delete # Benötigt, um nach dem Build aufzuräumen ``` Die notwendige JSON-Datei kann in Google Cloud IAM unter Dienstkonten erstellt werden. Dazu den gewünschten Service-Account auswählen und unter Schlüssel einen neuen Schlüssel vom Typ JSON erstellen. ## GitHub-Integration Der `github-token` wird nur benötigt, wenn der Parameter `github-disabled` nicht auf `true` gesetzt wird. Normalerweise reicht dafür der Default-Token aus, der von GitHub Actions standardmäßig bereitgestellt wird. Er wird benötigt, um den Commit-Status oder die Release-Notes zu setzen. Mehr dazu später. Bevor wir die Action ausführen können, müssen wir zunächst in Google Cloud Storage einen Bucket anlegen, in dem die Input-Dateien für den Build zwischengespeichert werden können. Standardmäßig wird dafür ein Bucket mit dem Namen `${projectId}_cloudbuild` verwendet. Der Name kann mit dem Parameter `gcp-cloud-storage-bucket` überschrieben werden. Wird die Action nun ausgeführt, wird das entsprechende Image gebaut und standardmäßig als `$branch-$commitSha-$yyyy.$mm.$dd-$hh.$mm.$ss` getaggt. Der erste Teil besteht aus dem (normalisierten) Branch-Namen, der zweite Teil aus dem 7-stelligen Kurz-Hash des verwendeten Commits und der dritte Teil aus dem Datum und der Uhrzeit des Build-Zeitpunkts. Wird der Build durch das Erstellen eines neuen Tags in GitHub ausgelöst, wird der Name des Tags zusätzlich als Image-Tag gesetzt. Über die [verfügbaren Parameter](https://github.com/Miragon/docker-cloud-build#tagging-the-image) können die verwendeten Tags angepasst werden. So können etwa immer das `default` Tag global oder für den entsprechenden Branch gesetzt werden oder das Format des Default-Tags geändert werden. Auch eigene Tags sind möglich. Wenn gewünscht, können die gebauten Image-Tags anschließend als Commit-Status in GitHub angezeigt werden. Damit wird auf einen Blick klar, mit welchem Namen das Image abgerufen werden kann. Das Format der Message kann [ebenfalls angepasst](https://github.com/Miragon/docker-cloud-build#github-commit-status) werden. Wird der Build durch ein neues Release ausgelöst, so können die gebauten Tags außerdem den entsprechenden Release-Notes hinzugefügt werden. Damit kann es den Nutzern des Images erleichtert werden, die entsprechenden Links zu finden. Ob in den Release-Notes nur das Default-Tag oder alle Tags enthalten sein sollen, lässt sich [anpassen](https://github.com/Miragon/docker-cloud-build#github-release-information). Alle verfügbaren Parameter und weitere Informationen sind [hier](https://github.com/Miragon/docker-cloud-build) zu finden. Wir nutzen die Action flächendeckend in unseren Build-Pipelines, um Docker-Images für Frontend-, Backend- und sonstige Anwendungen zu bauen, die anschließend in unseren Kubernetes-Clustern verwendet werden. Dafür verwenden wir das GitOps-Prinzip. Mehr dazu in einem zukünftigen Blog-Post! Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fdocker-images-github-actions-google-cloud%2F)[](mailto:?subject=Docker-Images%20mit%20GitHub%20Actions%20und%20Google%20Cloud%20bauen&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fdocker-images-github-actions-google-cloud%2F) ## Alexander Praschek Co-Founder bei Miragon [in Alexander kennenlernen](https://www.linkedin.com/in/alexander-praschek/) [Mehr von Alexander](/blog/?author=alexander-praschek) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Es gibt keine eierlegende Wollmilchsau](https://www.miragon.io/blog/es-gibt-keine-eierlegende-wollmilchsau/) BPM Warum es keine fertige Software gibt, die alle Prozesse digitalisiert - und wie BPMN und Prozess-Engines Unternehmen zur digitalen Eigenständigkeit verhelfen. Andreas Riepl Consultant **21\. Apr. 2023**5 Min. Lesezeit Disruptive Innovationen, wie ChatGPT oder selbstfahrende Autos führen uns täglich vor Augen, wie rasant die Digitalisierung voranschreitet. Mittlerweile werden zurückhaltende Unternehmen von ihren digitalisierten Konkurrenten abgehängt, die die selbe Leistung schneller und kostengünstiger anbieten können. ## Digitalisierung Heute Die meisten Unternehmen haben bereits Software im Einsatz: Salesforce im Vertrieb, Personio im Personalwesen oder SAP im Finanzbereich. Doch während diese Software-Produkte einzelne Bereiche eines Unternehmens digitalisieren, wird der Großteil der Kernprozesse oft noch manuell oder mit den Microsoft Office Produkten abgearbeitet - Medienbrüche sind überall zu finden. Sogar die Finanzmathematiker der großen Banken, die für mehrere Milliarden Euro verantwortlich sind, lassen ihre Berechnungsmodelle in Excel laufen! Viele Mitarbeiter kennen die Abläufe der Prozesse ihres Arbeitgebers nicht einmal. Sie führen stupide die Aufgaben aus, die sie von ihrem Vorgesetzten delegiert bekommen. Sind sie krank oder im Urlaub, bleibt die Aufgabe liegen. ## One fits it all? Hört man auf gut bezahlte Strategiebrater, kauft man teure Enterprise-Resource-Planning (ERP) Systeme, die mit einem hohen Investitionsaufwand in das bestehende Ökosystem integriert werden. Die Manager haben dann bunte Diagramme und Graphen, die ihnen zeigen, wie langsam ihre Prozesse ablaufen. ## Digitale Eigenständigkeit Es gibt keine fertige Software, die man installieren kann, um alle Prozesse im Unternehmen zu digitalisieren! Jedes Unternehmen muss das selbst machen. Doch ein Schritt nach dem anderen: ### Welche Prozesse soll man eigentlich digitalisieren? Als Erstes ist es wichtig, sich bewusst zu werden, welche Prozesse in seinem Betrieb überhaupt ablaufen und wie diese aussehen. Dabei ist es eine schlechte Idee, die Abläufe ausformuliert in Dokumentationen festzuhalten: Die wenigsten werden sich das durchlesen und oft sind solche Dokus schon nach kurzer Zeit veraltet. Zum Modellieren von Prozessen gibt es den “Business Process Model and Notation”-Standard (BPMN): BPMN-Diagramme bestehen aus einer Reihe von Symbolen, die verschiedenen Elemente des Prozesses repräsentieren. Dazu gehören beispielsweise Aktivitäten, Entscheidungen, Ereignisse oder Gateways. Diese Symbole werden mit Pfeilen verbunden, um den Informationsfluss darzustellen. ### Wie helfen BPMN Diagramme bei der Digitalisierung? Der große Vorteil an solchen Diagrammen ist, dass sie nicht nur gut von Menschen, sondern auch von Maschinen gelesen werden können. An dieser Stelle kommen Prozess-Engines, wie Camunda BPM, Flowable oder IBM BPM ins Spiel, die grundsätzlich aus drei Komponenten bestehen: Einer Workflow-Modellierungskomponente, einer Ausführungskomponente und einer Berichtskomponente. Am Beispiel des obigen Prozesses zur Abarbeitung einer Kundenanfrage lässt sich der Vorgehen einfach erklären: Nachdem die Fachabteilung den Workflow modelliert hat, wird er um technische Details ergänzt. So wird die Anfrage im ersten Schritt an einen Bearbeiter geleitet, der entscheidet, ob die Anfrage angenommen und der Kunde ins System aufgenommen werden soll oder nicht. In beiden Fällen bekommt der Kunde eine Rückmeldung per E-Mail. Deployed man diesen Prozess auf der Ausführungskomponente, stellt diese den entsprechenden Bearbeitern Aufgaben ein und ruft im Hintergrund den E-Mail-Service auf. Über die Berichtskomponente lässt sich überwachen, wie viele Instanzen eines Prozesses gerade ablaufen und an welcher Stelle die Ausführung gerade steht. ### Was passiert bei der Digitalisierung mit meinen Mitarbeitern? Wie das Beispiel zeigt, bleiben Mitarbeiter Teil der Prozesse. Der entscheidende Unterschied ist, dass jetzt transparent ist, wer an welchen Aufgaben arbeitet und an welcher Stelle die Anfrage steht. Allein die Einführung der Prozess-Engine als Aufgaben-Koordinator sorgt für Transparenz. ### Also doch eine eierlegende Wollmilchsau? Nein! Auch Workflow-Engines kann man nicht einfach installieren und schon ist man als Unternehmen digital. Doch man hat die Digitalisierung in der eigenen Hand: - **Kein Big Bang**: Es wird nicht ein System abgeschaltet und ein Neues hochgefahren. Vielmehr baut man auf der bestehenden Systemlandschaft auf. Bestandssysteme können weiter betrieben und sogar in die Prozesse integriert werden. Beispielsweise können Klickbots geschrieben werden, die deren Oberflächen bedienen und die Daten zurück in den Prozess spielen. - **Digitalisierung als Prozess**: Vorgehen ändern sich mit der Zeit. Sei es durch gesetzliche Anforderungen, die umgesetzt werden müssen oder durch den Einsatz neuer Tools, die stupide manuelle Aufgaben automatisieren. So lassen sich auch die in BPMN modellierten Prozesse in eine Version migrieren. - **Low Code**: Einige Anbieter werben damit, eine fertige Software zu haben, die Fachabteilungen alles mitgibt, um deren Prozesse selbst zu digitalisieren und zu automatisieren. In der Realität ist aber das Konfigurieren in komplexeren Prozessen so aufwendig, dass es schwieriger und teurer ist, seine Mitarbeiter dafür zu schulen, anstatt Entwickler einzustellen. Daher sollte es das Ziel sein, Entwickler an den Stellen einzusetzen, an denen ihre Expertise gebraucht wird. Auch die Wiederverwendbarkeit von Prozessbausteinen spielt in diesem Zusammenhang eine wichtige Rolle. Warum sollte die eine Abteilung erneut den E-Mail-Versand automatisieren, wenn er bereits von einer anderen implementiert wurde? - **Weniger Abhängigkeiten**: Mit jeder Software, die man sich als Unternehmen einkauft, macht man sich ein Stück weit von dem Hersteller abhängig, der sie vertreibt. Oft entstehen bei Integrationen zu anderen Systemen starke Kopplungen, die zukünftige Anpassungen aufwendig und zeitintensiv machen. Ein Open-Source Ökosystem, das auf offenen Standards basiert, wie das von Camunda, verringert die Abhängigkeit und macht es einfacher Personen zu finden, die sich damit auskennen. ## Miragon Und genau hier sehen wir den Sinn unserer Arbeit: Unser Ziel ist es, jede Organisation **digital erfolgreich** zu machen und dabei Komplexität und Abhängigkeiten zu reduzieren. Wir setzen auf offene Technologien und eine enge Zusammenarbeit, um [passgenaue Lösungen zu entwickeln](/leistungen/). Das haben wir unter anderem schon bei unseren Kunden, wie der Landeshauptstadt München oder der Europäische Zentralbank unter Beweis gestellt. Die Best-Practices, die sich beim gemeinsamen Entwickeln der Lösungen herauskristallisieren, lassen wir in unsere Open-Source-Tools Miranum-IDE und Miranum-Connect einfließen. Hierzu kommen in den nächsten Wochen mehr Beiträge auf unserem Kanal. Lass gerne einen Like da und folge uns auf den gängigen Social-Media-Plattformen. Wenn du Fragen hast, kannst du dich jederzeit an uns wenden ([info@miragon.io](mailto:info@miragon.io)) oder auch mich direkt anschreiben ([andreas.riepl@miragon.io](mailto:andreas.riepl@miragon.io)). Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fes-gibt-keine-eierlegende-wollmilchsau%2F)[](mailto:?subject=Es%20gibt%20keine%20eierlegende%20Wollmilchsau&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fes-gibt-keine-eierlegende-wollmilchsau%2F) ## Andreas Riepl Consultant bei Miragon [in Andreas kennenlernen](https://www.linkedin.com/in/andreas-riepl) [Mehr von Andreas](/blog/?author=andreas-riepl) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Generierung von Client APIs mit Swagger Teil 1](https://www.miragon.io/blog/generierung-client-apis-swagger-teil-1/) Softwareentwicklung Integration von Swagger in Spring Boot, Generierung des TypeScript-Axios API-Clients und Verwendung in einer React-Web-App. Andreas Riepl Consultant **20\. Aug. 2021**4 Min. Lesezeit _Also available in English at [Medium.com](https://medium.com/@miragon/generating-client-apis-using-swagger-part-1-2d46f13f5e92)._ Mit jedem neuen Backend-Release müssen Frontend-Entwickler\*innen große Teile des API-Clients neu schreiben. Was wäre, wenn es eine Lösung gäbe, um den gesamten Client in nur wenigen Sekunden zu aktualisieren? In diesem Blog-Post stellen wir die Client-Generierung von Swagger vor, zeigen, wie man die generierte API in React-Anwendungen verwendet und wie man das Authentifizierungs-Token von Auth0 integriert. Der Einfachheit halber wird dieses Thema in eine dreiteilige Serie aufgeteilt: 1. _Teil 1:_ Integration von Swagger in Spring Boot, Generierung des API-Clients und Verwendung als Teil einer React-Web-App 2. _Teil 2:_ Sicherung der Endpunkte mit Auth0 und Autorisierung der Anfragen der Web-Clients 3. _Teil 3:_ Verwendung des generierten API-Clients als Teil einer React Native App. ## Integration von Swagger in Spring Boot und Generierung des Clients Ziel dieses Abschnitts ist es, die API-Dokumentation einer Java-Spring-Boot-Anwendung mit Swagger zu generieren, den entsprechenden TypeScript-Axios-Client zu erstellen, der die API-Aufrufe kapselt, und diesen Client in eine React-Web-App zu integrieren. Das Ergebnis wird wie folgt aussehen: **TL;DR** 1. Klonen Sie unser [Beispiel-Backend](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-backend), starten Sie Docker und führen Sie die Anwendung mit dem Spring-Boot-Profil `no-security` aus. 2. Klonen Sie unsere [Beispiel-Web-App](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-webapp), installieren Sie alle Abhängigkeiten mit `yarn install` und führen Sie `yarn generate-api` im Stammverzeichnis des Projekts aus. ### Schritt 1) Integrieren von Swagger in Spring Boot Alle Codeschnipsel sind Teil unseres [Beispiel-Backends](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-backend). Diese Backend-Anwendung ermöglicht die Verwaltung von Projekten, die jeweils den Namen eines Kunden und seine Adresse enthalten. Mit Hilfe der API-Endpunkte kann ein Nutzer Projekte erstellen, lesen, aktualisieren und löschen (CRUD). #### 1a) Kommentieren Sie die Controller und fügen Sie Metadaten über jeden Endpunkt hinzu Nach dem Hinzufügen der Abhängigkeit `springdoc-openapi-ui` zur `build.gradle` bzw. `pom.xml` können Sie die darin enthaltenen Annotationen für die Projekt-Controller verwenden, um Metadaten hinzuzufügen: ``` @Slf4j @Validated @RestController @RequiredArgsConstructor @Tag(name = "Project Controller") @RequestMapping("/api/project") public class ProjectController { private final ProjectService projectService; private final ProjectApiMapper projectMapper; @Transactional(readOnly = true) @GetMapping @Operation(summary = "Get list of all projects") public ResponseEntity> getAllProject() { log.debug("Received request to load all projects"); final List allProjects = this.projectService.getAllProjects(); return ResponseEntity.ok(this.projectMapper.mapToTO(allProjects)); } ... ``` #### 1b) Besuchen Sie die generierte API-Dokumentation 1. Wie in der ReadMe des Projekts beschrieben, müssen beide Docker-Dienste (nginx und postgres) laufen, bevor Sie das Beispiel-Backend starten können. 2. Bitte stellen Sie sicher, dass Sie in den Run-Konfigurationen das Profil `no-security` aktiviert haben: _IntelliJ → Run → Edit Configurations… → Active profiles: `no-security`_ 3. Jetzt sollten Sie in der Lage sein, die API-Dokumentation in Ihrem Browser zu öffnen: [http://localhost:8081/swagger-ui.html](http://localhost:8081/swagger-ui.html) ### Schritt 2) Den API-Client generieren Es gibt mehrere Möglichkeiten, einen API-Client mit Swagger zu erzeugen: Sie können ein Gradle- oder Maven-Plugin verwenden, den Swagger-Editor oder eine JavaScript-Bibliothek eines Drittanbieters verwenden. Unserer Meinung nach sollte die Generierung des API-Clients nicht Teil des Backends sein. Deshalb haben wir uns zunächst für den Swagger-Editor entschieden und haben später auf die Bibliothek `openapi-generator-cli` gewechselt, um die Vorteile von stark typisierten Schnittstellen in TypeScript zu nutzen. In diesem Abschnitt werden wir beide Wege, den Swagger-Editor und die `openapi-generator-cli`, erläutern: #### 2a) Swagger-Editor 1. Öffnen Sie die URL [http://localhost:8081/v3/api-docs](http://localhost:8081/v3/api-docs) und kopieren Sie alles. 2. Rufen Sie den Swagger-Editor ([https://editor.swagger.io/](https://editor.swagger.io/)) auf und fügen Sie die kopierte API-Beschreibung in das Editor-Fenster ein → Sie werden gefragt, ob Sie ihn in .yaml umwandeln wollen → Akzeptieren Sie. 3. Im Menü des Swagger-Editors finden Sie das Dropdown-Menü “Generate Client”. Wählen Sie “TypeScript Axios” und warten Sie, bis der Download abgeschlossen ist. 4. Entpacken Sie es, kopieren Sie `api.ts`, `base.ts`, `configuration.ts`, `apis-folder` und `models-folder` in einen neuen Ordner in Ihrem Frontend-Projekt. #### 2b) `openapi-generator-cli` 1. Fügen Sie `@openapitools/openapi-generator-cli` mit dem folgenden Befehl als `dev`\-Abhängigkeit in Ihre Web-App ein: `yarn add --dev @openapitools/openapi-generator-cli` 2. Vergewissern Sie sich, dass Ihr Backend gestartet ist und läuft. 3. Führen Sie den folgenden Befehl aus: ``` yarn openapi-generator-cli generate \ -i http://localhost:8081/v3/api-docs \ -g typescript-axios \ -o src/api ``` **Optional**: Löschen Sie die Dateien `.npmignore`, `.gitignore` und `git_push.sh`, und fügen Sie sie der Datei `.openapi-generator-ignore` hinzu. Fügen Sie `openapitools.json` und `.openapi-generator` zur Datei `.gitignore` Ihres Projekts hinzu. ### Schritt 3) Verwendung des API-Clients in einer React-Webanwendung Um mit der generierten API unter Verwendung von nginx als Reverse Proxy zu arbeiten, müssen Sie zuerst die `BASE_PATH`\-Variable in `src/api/base.ts` auf einen leeren String setzen: ``` export const BASE_PATH = ""; ``` Jetzt können Sie mit nur drei Zeilen Code Daten vom API-Endpunkt abrufen: ``` const projectController = new ProjectControllerApi(); const response = await projectController.getAllProject(); const data = response.data; ``` In unserer [Beispiel-Web-App](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-webapp) haben wir alle API-Aufrufe in einer Helper-Methode gekapselt, um Fehler abfangen zu können. Zusätzlich verwenden wir `redux-store`, um die empfangenen Daten zu cachen, was uns erlaubt, die Backend-Aufrufe zu reduzieren. [Im nächsten Teil der Serie](/blog/generierung-client-apis-swagger-teil-2/) werden wir uns damit beschäftigen, wie wir die API-Endpoints mithilfe von Auth0 absichern und die Anfragen unserer Web-App entsprechend autorisieren können. Bis zum nächsten Mal! Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fgenerierung-client-apis-swagger-teil-1%2F)[](mailto:?subject=Generierung%20von%20Client%20APIs%20mit%20Swagger%20Teil%201&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fgenerierung-client-apis-swagger-teil-1%2F) ## Andreas Riepl Consultant bei Miragon [in Andreas kennenlernen](https://www.linkedin.com/in/andreas-riepl) [Mehr von Andreas](/blog/?author=andreas-riepl) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Generierung von Client APIs mit Swagger Teil 2](https://www.miragon.io/blog/generierung-client-apis-swagger-teil-2/) Softwareentwicklung Im zweiten Teil der Serie sichern wir die Endpoints mit Auth0 und autorisieren die Anfragen des Web-Clients mit OAuth2. Andreas Riepl Consultant **10\. Sep. 2021**4 Min. Lesezeit _Also available in English at [Medium.com](https://medium.com/@miragon/generating-client-apis-using-swagger-part-2-ab4a95425987)._ In diesem Blog-Post stellen wir die Client-Generierung von Swagger vor, zeigen, wie man die generierte API in React-Anwendungen verwendet und wie man das Authentifizierungs-Token von Auth0 integriert. Der Einfachheit halber wird dieses Thema in eine dreiteilige Serie aufgeteilt: 1. _Teil 1:_ Integration von Swagger in Spring Boot, Generierung des API-Clients und Verwendung als Teil einer React-Web-App 2. _Teil 2:_ Sicherung der Endpunkte mit Auth0 und Autorisierung der Anfragen der Web-Clients 3. _Teil 3:_ Verwendung des generierten API-Clients als Teil einer React Native App. ## Sichern der Endpoints mit Auth0 und Autorisierung der Webclient-Anfragen Im zweiten Teil unserer Blogpost-Serie sichern wir unsere Web-Anwendung mit OAuth2 unter Verwendung von Auth0. Falls du den Einstieg verpasst hast, findest du im [ersten Teil zur Generierung des API-Clients](/blog/generierung-client-apis-swagger-teil-1/) die Grundlagen dazu. Auth0 nennt sich selbst “eine einfach zu implementierende, anpassungsfähige Authentifizierungs- und Autorisierungsplattform” und bietet einen kostenlosen Tarif für bis zu 7000 Benutzer an. In diesem Beitrag wird die Integration von Auth0 in das Spring Boot Backend und die React-Webanwendung behandelt. **TL;DR** 1. Erstellen Sie einen neuen Tenant in Auth0, wie in Schritt 1 beschrieben. 2. Klonen Sie unser [Beispiel-Backend](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-backend) und starten Sie die Docker-Services. 3. Setzen Sie in der `src/main/resources/application.properties` den Wert `spring.security.oauth2.resourceserver.jwt.issuer-uri=https://.eu.auth0.com`, um den neuen Tenant zu nutzen. 4. Starten Sie das Backend **ohne** `no-security`\-Profil. 5. Klonen Sie unsere [Gesicherte Beispiel-Web-App](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-webapp-secured) und installieren Sie alle Abhängigkeiten mit `yarn install`. 6. Setzen Sie die folgenden Umgebungsvariablen in der Run-Konfiguration der Web-Anwendung: ``` REACT_APP_DOMAIN= (z.B.: https://miragon-example-tenant.eu.auth0.com); REACT_APP_CLIENT_ID= (z.B.: yXu7adklfU729Hgsdg93p0gag9dC); ``` 7. Starten Sie die Anwendung mit `yarn start`. ### Schritt 1) Erstellen eines Auth0-Kontos, Anlegen eines neuen Tenants und einer neuen Anwendung. 1. Besuchen Sie Auth0 und erstellen Sie ein neues Konto: [https://auth0.com/](https://auth0.com/). 2. Erstellen Sie einen neuen Tenant: Klicken Sie auf Ihren Default-Tenant und wählen Sie “Create Tenant”. 3. Erstellen Sie eine neue Anwendung: Anwendungen → “Create Application” → “Single Web Page Applications”. 4. Konfigurieren Sie Ihre Anwendung: Ändern Sie den Namen und setzen Sie “Allowed Callback URLs” sowie “Allowed Web Origins” auf “[http://localhost:8080/](http://localhost:8080/)” und speichern Sie die Änderungen (den Button finden Sie am unteren Rand des Formulars”). 5. Erstellen Sie einen Benutzer: User Management → Users → Create User ### Schritt 2) Backend-Anwendung sichern Setzen Sie in der `src/main/resources/application.properties` den Wert `spring.security.oauth2.resourceserver.jwt.issuer-uri=`, um Ihren Auth0-Tenant zu verwenden. Die Domain kann auf der Anwendungsseite in Auth0 gefunden werden. Sie können Ihr Backend mit der folgenden Security-Konfiguration schützen (Sie finden diese Klasse im [Beispiel-Backend](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-backend) im Ordner shared/security): ``` @Profile("!no-security") @EnableWebSecurity @RequiredArgsConstructor public class SecurityConfig extends WebSecurityConfigurerAdapter { @Override public void configure(final HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/actuator/health").permitAll() .antMatchers("/v3/api-docs/**", "/swagger-resources", "/swagger-resources/**", "/configuration/ui", "/configuration/security", "/swagger-ui.html", "/swagger-ui/**", "/webjars/**").permitAll() .anyRequest() .authenticated() .and() .oauth2ResourceServer( OAuth2ResourceServerConfigurer::jwt ); http.headers().frameOptions().sameOrigin(); http.csrf().disable(); http.sessionManagement() .sessionCreationPolicy( SessionCreationPolicy.STATELESS ); } @Bean public JwtDecoder jwtDecoderByIssuerUri( final OAuth2ResourceServerProperties properties ) { final String issuerUri = properties.getJwt().getIssuerUri(); return JwtDecoders.fromIssuerLocation(issuerUri); } } ``` ### Schritt 3) Web-App sichern Wir werden Auth0s Benutzername & Passwort-Authentifizierung verwenden, die erscheinen sollte, wenn der Benutzer nicht angemeldet ist. _Der Login-Screen von Auth0:_ #### 3a) Hinzufügen des Auth0-Providers Installieren Sie die erforderliche Abhängigkeit über `yarn add @auth0/auth0-react` und fügen Sie den Provider in Ihre Anwendung ein (index.tsx): ``` ``` Die Domain und die Client-ID finden Sie in der Auth0-Anwendung, die Sie oben erstellt haben. #### 3b) Speichern des Tokens im Local Browser Storage: Wenn sich der Benutzer erfolgreich angemeldet hat, können wir nun das JWT-Token im lokalen Browser-Speicher ablegen, um von jeder Seite aus darauf zuzugreifen (src/components/Layout/Layout.tsx): ``` (async () => { const token = await getIdTokenClaims(); localStorage.setItem("token", token.__raw) })(); ``` _Der Token im lokalen Browser-Speicher:_ #### 3c) Konfiguration der Swagger-API Verwenden Sie die Configuration-Klasse, um den Authentifizierungsheader zu setzen (src/constants/Functions.tsx): ``` getClientConfig: function (): Configuration { return new Configuration({ baseOptions: { "headers": { 'Authorization': `Bearer ${this.getBearerToken()}`, } } }) }, getBearerToken: function (): string | null { return localStorage.getItem("token"); } ``` #### 3d) Konfiguration beim Erstellen eines API-Client setzen. Mit dieser Konfiguration können Sie jetzt authentifizierte Anfragen an die gesicherten Endpoints Ihres Backends senden: ``` const config = getClientConfig(); const projectController = new ProjectControllerApi(config) const response = await projectController.getAllProject() const data = response.data ``` [Im dritten - und letzten - Teil dieser Serie](/blog/generierung-client-apis-swagger-teil-3/) werden wir einen genaueren Blick darauf werfen, wie man den generierten API-Client als Teil einer React Native App verwendet. Bis zum nächsten Mal! Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fgenerierung-client-apis-swagger-teil-2%2F)[](mailto:?subject=Generierung%20von%20Client%20APIs%20mit%20Swagger%20Teil%202&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fgenerierung-client-apis-swagger-teil-2%2F) ## Andreas Riepl Consultant bei Miragon [in Andreas kennenlernen](https://www.linkedin.com/in/andreas-riepl) [Mehr von Andreas](/blog/?author=andreas-riepl) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Generierung von Client APIs mit Swagger Teil 3](https://www.miragon.io/blog/generierung-client-apis-swagger-teil-3/) Softwareentwicklung Im dritten Teil der Serie integrieren wir den Swagger API-Client in eine React Native App mit Auth0-Authentifizierung und Expo. Andreas Riepl Consultant **12\. Okt. 2021**4 Min. Lesezeit _Also available in English at [Medium.com](https://medium.com/@miragon/generating-client-apis-using-swagger-part-3-cef6d7e6767)._ In diesem Blog-Post stellen wir die Client-Generierung von Swagger vor, zeigen, wie man die generierte API in React-Anwendungen verwendet und wie man das Authentifizierungs-Token von Auth0 integriert. Der Einfachheit halber wird dieses Thema in eine dreiteilige Serie aufgeteilt: 1. _Teil 1:_ Integration von Swagger in Spring Boot, Generierung des API-Clients und Verwendung als Teil einer React-Web-App 2. _Teil 2:_ Sicherung der Endpunkte mit Auth0 und Autorisierung der Anfragen der Web-Clients 3. _Teil 3:_ Verwendung des generierten API-Clients als Teil einer React Native App. ## Verwendung des generierten API-Clients als Teil einer React Native App Im letzten Teil dieser Blogpost-Serie integrieren wir unseren Swagger API-Client in eine React Native App. Dieser Teil baut auf den beiden vorherigen Teilen der Reihe auf, lesen Sie diese also bitte als Vorbereitung auf diesen Teil. Das heutige Ziel ist die Implementierung einer React Native App, welche die Projekte darstellt, die wir in unserer React Web-Anwendung verwalten. **TL;DR** In diesem Teil müssen wir viel Konfiguration durchführen. Aus diesem Grund funktioniert ein TL;DR hier leider nicht. Um möglichst schnell zu einem Ergebnis zu kommen, können Sie sich aber auf die ersten beiden Schritte beschränken und anschließend unsere [Beispiel-App](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-app) verwenden. * * * ### Schritt 1) Einen Expo-Account erstellen Expo ist ein Wrapper für React Native Apps und erleichtert uns den gesamten Entwicklungsprozess, inklusive Dependency-Management sowie Build- und Deployment-Verwaltung. 1. Besuchen Sie [https://expo.io](https://expo.io) und erstellen Sie einen neuen Account. 2. Installieren Sie die [Expo CLI](https://docs.expo.dev/get-started/installation/). 3. Erstellen Sie ein neues Projekt, indem Sie den Befehl `expo init` in einem leeren Ordner ausfühern. 4. Veröffentlichen Sie Ihr Projekt auf Expo, indem Sie den Befehl `expo publish` ausführen. Dadurch sollte eine Projekt-Seite [ähnlich wie unsere](https://expo.io/@miragon/miragon-example-app) erstellt werden. ### Schritt 2) Erstellen und Konfigurieren einer Auth0-Anwendung 1. Erstellen Sie in Auth0 eine neue Native Anwendung für den bestehenden Mandanten: Applications -> Create Application -> Native 2. Fügen Sie die Authentication-URL des Expo-Projekts zur Liste der erlaubten Callback-URLs hinzu (z.B. [https://auth.expo.io/@miragon/miragon-example-app](https://auth.expo.io/@miragon/miragon-example-app)) und speichern Sie die Änderungen, indem Sie auf den Button am Ende der Seite klicken. 3. Aktivieren Sie die Username-Passwort-Authentifizierung, indem Sie in den Einstellungen des Mandanten unter General die API Authorization Settings auf “Username-Passwort-Authentication” setzen. ### Schritt 3) Konfigurieren der React Native App Wenn Sie lieber die Beispielanwendung verwenden wollen, klonen Sie unsere [Beispiel-App](https://github.com/Miragon/code-examples/tree/main/projects/miragon-example-app), fügen Sie die folgenden Umgebungsvariablen in Ihre Run-Konfiguration ein und starten Sie die Anwendung mit dem Befehl `expo start`: ``` AUTH0_DOMAIN= (e.g. https://miragon-example-tenant.eu.auth0.com/authorize); AUTH0_CLIENT_ID= (e.g. yXu7nsklfU495Hgsdg51p0age9dC) ``` Sie werden merken, dass wir den Authentication-Flow von Auth0 verwenden, welcher den Benutzer auf die Login-Seite von Auth0 weiterleitet und nach dem Eingeben der korrekten Zugangsdaten zurück in die App leitet. Die Logik dafür ist in der Datei `constants/Auth.tsx` enthalten und funktioniert wie folgt: Zuerst werden die Zugangsdaten des Nutzers verwendet, um einen langlebigen Token zu erhalten, der 30 Tage lang gültig bleibt. Dieser langlebige Token wird dann verwendet, um einen kurzlebigen Access Token anzufragen. In unseren Apps speichern wir den langlebigen Token im sicheren Expo-Speicher auf dem lokalen Gerät, um einen neuen Access Token anzufragen, sobald der vorherige abgelaufen ist. Aus diesem Grund müssen unsere Nutzer sich nicht bei jedem Öffnen der Anwendung neu anmelden. Für mehr Informationen dazu können Sie auch [diesen Artikel](https://jamesirish.io/blog/auth0-pkce-flow-using-expo-authsession) lesen. Um den Code frei von Abhängigkeiten auf unsere eigenen Auth0-Domains und Clients zu halten, speichern wir diese in Umgebungsvariablen mithilfe der Bibliothek `expo-constants`. Dazu haben wir die folgende Konfiguration in der Datei `app.config.js`: ``` import app_config from "./app.json" export default { ...app_config.expo, extra: { auth0ClientId: process.env.AUTH0_CLIENT_ID, auth0Domain: process.env.AUTH0_DOMAIN, }, }; ``` Wie Sie sehen können, wird die Datei `app.json` erweitert. In dieser Datei stehen alle Konfigurationsparameter für Expo. Um Auth0 in Ihrer Expo-App zu verwenden, müssen Sie sicherstellen, dass die Felder “owner” Ihren Accountnamen und “scheme” einen vorzugsweise eindeutigen Shortcut enthält. Dieser wird für den Protokoll-Teil der Redirect-URL verwendet, mit der die App nach einem erfolgreichen Login wieder geöffnet wird (bspw. `mea://...`). Unten sehen Sie unsere `app.json`\-Datei: ``` { "expo": { "name": "miragon-example-app", "slug": "miragon-example-app", "scheme": "mea", "owner": "miragon", ... } ``` Im letzten Schritt müssen Sie noch die Dependency `react-native-polyfill/auto` hinzufügen und Sie in Ihrer `App.tsx` importieren. Das ist notwendig, um ein Problem mit Axios Fetch zu beheben. Mehr Informationen sind [hier zu finden](https://github.com/facebook/react-native/issues/23922). ### Schritt 4) Integrieren der API Nachdem React Native apps auf React aufbauen, können wir denselben Ansatz wiederverwenden, den wir schon [im vorherigen Teil der Serie](/blog/generierung-client-apis-swagger-teil-2/) verwendet haben, um unsere React-Webanwendung aufzusetzen. Das war’s auch schon! Viel Spaß mit diesem production-ready Ansatz basierend auf Spring Boot, Swagger, Auth0, React und React Native! Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fgenerierung-client-apis-swagger-teil-3%2F)[](mailto:?subject=Generierung%20von%20Client%20APIs%20mit%20Swagger%20Teil%203&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fgenerierung-client-apis-swagger-teil-3%2F) ## Andreas Riepl Consultant bei Miragon [in Andreas kennenlernen](https://www.linkedin.com/in/andreas-riepl) [Mehr von Andreas](/blog/?author=andreas-riepl) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Internationalization Plugin für den Camunda Modeler](https://www.miragon.io/blog/internationalization-plugin-camunda-modeler/) BPM Mit unserem I18N-Plugin für den Camunda Modeler kann der Modeler auch in anderen Sprachen genutzt werden. Deutsch ist bereits integriert. Alexander Praschek Co-Founder **30\. Juni 2020**3 Min. Lesezeit In diesem Blogpost stellen wir unser I18N-Plugin für den Camunda Modeler vor und erklären, welche Herausforderungen bei der Implementierung auftraten und wie neue Sprachen hinzugefügt oder bestehende Sprachen angepasst werden können. > **TL;DR:** Mit unserem I18N-Plugin für den Camunda Modeler kann der Modeler auch in anderen Sprachen genutzt werden. Deutsch ist bereits integriert. Der fertige Modeler kann im [GitHub-Repository Camunda Modeler I18N Plugin](https://github.com/Miragon/camunda-modeler-i18n-plugin) gefunden werden. Dort ist auch beschrieben, wie das Plugin installiert und angepasst werden kann. Im Rahmen eines unserer Kundenprojekte ist geplant, den Camunda Modeler für Nicht-Entwicklungsabteilungen bereitzustellen. Im Zuge dessen ist es notwendig, die Oberfläche auch auf Deutsch anzubieten. Da dies auch für andere Projekte interessant sein könnte, entschlossen wir uns, das Projekt Open Source bereitzustellen. Wir konnten in der Vergangenheit bei der Entwicklung individueller Modellierungstools bereits einige Erfahrungen mit dem Camunda Modeler und dem darunterliegenden Framework bpmn.io sammeln, um uns von der fehlenden Dokumentation nicht abschrecken zu lassen. ## Konzeption Der Camunda Modeler besteht aus mehreren Teilen, die alle einzeln implementiert wurden und daher bei der Konzeption berücksichtigt werden müssen. Die wichtigsten davon sind hier kurz beschrieben: - bpmn.js, cmmn.js und dmn.js: Diese Open-Source-Libraries sind Teil von bpmn.io und erlauben die Modellierung von Diagrammen in BPMN, CMMN und DMN. - bpmn.js-properties-panel: Dieser Teil enthält das Seitenpanel, welches die Konfiguration einzelner Elemente in BPMN erlaubt. Entsprechende Properties Panels existieren auch für CMMN und DMN. - diagram.js: Diese Library übernimmt die eigentliche Darstellung der Elemente. Der Camunda Modeler bietet bereits die Möglichkeit, Übersetzungen bereitzustellen, indem an nahezu allen Stellen eine `translate()`\-Funktion aufgerufen wird, bevor Strings in der Oberfläche dargestellt werden. Allerdings existierte bisher nur eine funktionslose Implementierung davon. Die meisten der oben genannten Teile nutzen ebenfalls diese zentrale Funktion, weshalb wir uns bei der Umsetzung darauf konzentrierten. Unser primäres Ziel war es, den Modeler sowohl auf Deutsch als auch auf Englisch bereitzustellen und die Sprache jederzeit in der Oberfläche dauerhaft, also auch über Neustarts hinweg persistent, wechseln zu können. ## Erstellung des Plugins Zum Erstellen von Plugins stellt Camunda ein [Demo-Repository](https://github.com/camunda/camunda-modeler-plugin-example) bereit, welches wir als Ausgangspunkt verwendeten und nach und nach ergänzten und verbesserten. Für interessierte steht [sämtlicher Quellcode ausführlich dokumentiert in unserem GitHub-Repository](https://github.com/Miragon/camunda-modeler-i18n-plugin) bereit. Die eigentliche Implementierung der Übersetzungsfunktion liegt in der Datei `client/i18n-extension/translate.js`. Die dort am Ende zurückgegebene Funktion ersetzt die oben erwähnte No-Op-Implementierung der `translate()`\-Funktion. Über die darüber eingebundenen Event-Listener kann die Sprache zur Laufzeit jederzeit geändert werden. Die dafür notwendigen Events werden in der Menü-Komponente ausgelöst, welche in der Datei `menu/menu.js` liegt. Aus der darin gespeicherten Konfiguration wird das Menü generiert, welches das Wechseln der Sprache in der Oberfläche erlaubt. Der komplizierteste Teil war dabei das Speichern der gewählten Sprache über Neustarts hinweg. Wir wollten diese Einstellung in die `config.json`\-Datei des Modelers speichern, wofür allerdings keine direkte Schnittstelle bereitstand. Über viel Trial&Error und ein gewisses Maß an „Reverse Engineering“ konnten wir schließlich die in der Klasse `client/configuration/Config.js` gesetzte Implementierung entwerfen. **Diese kann auch jederzeit in anderen Plugins verwendet werden, um zur Laufzeit Konfigurationswerte in die `config.json` zu speichern und wieder zu lesen!** Jetzt war nur noch die eigentliche Übersetzung der verwendeten Strings notwendig. Dabei trennten wir die Strings nach dem Teil des Modelers, in dem sie auftaucht, darunter bpmn.js, dmn.js, das Properties Panel und sonstige Teile. Die Bibliothek cmmn.js verwendet die `translate()`\-Funktion nicht, weshalb dafür auch keine entsprechende Datei existiert. Bei dmn.js funktionieren die Übersetzungen in der neuesten Version analog zu bpmn.js. ## Fazit Das Einbinden der Übersetzungen war dank unserer Erfahrungen kein großes Problem. Die fehlende Dokumentation und der Wunsch, die gewählte Sprache zu speichern, stellte uns aber vor einige Herausforderungen. Das Projekt inklusive einer Anleitung zum Hinzufügen neuer Sprachen ist in unserem [GitHub-Repository](https://github.com/Miragon/camunda-modeler-i18n-plugin) zu finden. Pull Requests mit verbesserten Übersetzungen, neuen Sprachen und sonstigen Weiterentwicklungen sind immer gern gesehen! Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Finternationalization-plugin-camunda-modeler%2F)[](mailto:?subject=Internationalization%20Plugin%20f%C3%BCr%20den%20Camunda%20Modeler&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Finternationalization-plugin-camunda-modeler%2F) ## Alexander Praschek Co-Founder bei Miragon [in Alexander kennenlernen](https://www.linkedin.com/in/alexander-praschek/) [Mehr von Alexander](/blog/?author=alexander-praschek) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Komplexität meistern – Wie Prozessautomatisierung gelingt](https://www.miragon.io/blog/komplexitaet-meistern-prozessautomatisierung/) Transformation Erfahrungen aus einem Jahrzehnt Prozessautomatisierung: Warum Kontext, Teamstrukturen und organisatorische Reife wichtiger sind als Technologie allein. Dominik Horn Co-Founder & Geschäftsführer **12\. Mai 2025**17 Min. Lesezeit Als ich vor knapp zehn Jahren in mein erstes großes Projekt zur Prozessautomatisierung gestartet bin, war ich voller Enthusiasmus. Ich war fest davon überzeugt, dass wir jede Herausforderung mit dem richtigen Prozessdesign und der passenden Technologieplattform lösen können – egal wie komplex das Vorhaben ist. BPMN-Tools, Automatisierungsframeworks, moderne Workflow-Engines – das war meine Welt. Was soll ich sagen: Heute sehe ich viele Dinge anders. Denn nicht alles lief so wie geplant. Viele Projekte blieben hinter den Erwartungen zurück und manche Roadmaps führten in Sackgassen. Was ich in all den Jahren gelernt habe: Es geht nicht nur um Tools, Plattformen oder Prozesse. Es geht vor allem um den Kontext, in dem diese eingesetzt werden – um Teams, um Reifegrade und um die Fähigkeit, Komplexität zu verstehen und zu meistern. In diesem Beitrag möchte ich meine Erfahrungen teilen – ehrlich, praxisnah und mit dem Ziel, dass ihr euch auf eurem eigenen Weg ein paar Umwege ersparen könnt. ## Mein persönlicher Aha-Moment Angefangen hat alles mit meinem ersten Projekt im Jahr 2016: voller Elan, als Camunda-Enthusiast, war ich Teil eines ambitionierten Vorhabens, ein umfassendes Prozessframework im Bankingumfeld zu entwickeln. Die Erwartungen waren hoch – doch nach drei Jahren waren gerade einmal vier Prozesse produktiv umgesetzt. Das Projekt blieb weit hinter seinen Zielen zurück. Nach einigen Erfolgen in späteren Projekten schöpfte ich neuen Optimismus. Ende 2020 war ich überzeugt, endlich verstanden zu haben, wie eine funktionierende Plattform aussehen muss – skalierbar, flexibel und effizient. Mit diesem Selbstverständnis startete ich in mein drittes Plattformprojekt. Doch die Realität holte mich ein: Das Projekt wurde Ende 2022 eingestellt – das Budget war aufgebraucht, die Ergebnisse enttäuschend, der Frust groß. Der Wendepunkt kam für mich Anfang 2024, als ich auf die Konzepte von Wardley Mapping und Team Topologies stieß. Plötzlich wurde mir klar, dass es nicht ausreicht, nur auf Prozesse und Technologien zu setzen. Es geht vielmehr darum, den Kontext zu verstehen, in dem diese eingesetzt werden – und insbesondere darum, wie Teams strukturiert und befähigt werden. Dabei ist es essentiell, die Fähigkeiten und Kompetenzen der jeweiligen Organisation zu berücksichtigen. Erst als ich begann, diese Perspektiven einfließen zu lassen, ergab vieles endlich Sinn: Erfolgreiche Prozessautomatisierung braucht nicht nur gute Werkzeuge, sondern die richtige Einordnung und die passenden Strukturen. ## Die Sackgassen, die uns blockieren Rückblickend habe ich viele typische Fehler gemacht: 1. **Eigenentwicklung statt Produkt**: Warum individuelle Lösungen entwickeln, wenn bewährte Produkte am Markt existieren? 2. **Digitalisierung anstatt echter Transformation**: Häufig fehlte der Mut für echte Veränderung, stattdessen wurden bestehende Prozesse nur digital abgebildet – starre und komplizierte Lösungen waren die Folge. 3. **Der große Wurf**: Wir planen zu groß, wollen sofort eine umfassende Plattform und verlieren dabei an Agilität und Geschwindigkeit. 4. **Blockierte Teams**: Entscheidungen brauchten unzählige Abstimmungen, keiner fühlte sich verantwortlich. 5. **Fachbereich vs. IT**: Die Hoffnung, BPM würde die IT überflüssig machen, führte zu unrealistischen Erwartungen und Frustration. 6. **Die eigenen Fähigkeiten nicht im Blick behalten**: Was in anderen Organisationen funktioniert hat, lässt sich nicht einfach übertragen. Zu oft kopieren wir Best Practices, ohne zu prüfen, ob unsere Teams, unsere Kultur und unsere technische Basis dazu überhaupt passen. Vielleicht erkennt ihr einige dieser Situationen auch aus eurer Praxis? Wenn ja, stellt sich die entscheidende Frage: Wie treffen wir in solchen komplexen Umfeldern bessere Entscheidungen? Wir brauchen einen Kompass, der uns durch die Unsicherheiten der digitalen Transformation navigiert. Und dieser Kompass beginnt mit einem besseren Verständnis unseres Kontexts – und mit einem klaren Blick auf die Landschaft, in der wir agieren. ## Der Kompass für bessere Entscheidungen Eines ist klar: Der Blick nach außen hilft nicht automatisch weiter. Es reicht nicht auf einer Konferenz zu hören: “Unternehmen X hat Camunda erfolgreich eingeführt – und übrigens mit SCRUM gearbeitet.“ Und diese Erfolgsstory dann blind zu kopieren, ohne den Kontext zu hinterfragen. Simon Wardley nennt dieses Verhalten “Blindes Schachspielen”. Wir kopieren Züge, ohne das Spiel zu verstehen oder gar zu wissen, dass wir ein Spiel spielen. Was uns fehlt, ist **Situational Awareness** – das Bewusstsein für unsere eigene Ausgangssituation. Und genau hier setzt Wardley Mapping an. ### Was genau ist Wardley Mapping? Wardley Mapping ist ein strategisches Werkzeug, das hilft, fundierte, kontextabhängige Entscheidungen zu treffen. Es ist eine Art Landkarte, die unsere Ressourcen sichtbar macht – und das auf zwei Achsen: - Die **Y-Achse** beschreibt die Sichtbarkeit oder den Nutzen für den Kunden – oben das, was direkt im Kundenfokus steht, unten die internen Strukturen. - Die **X-Achse** beschreibt den Reifegrad der Komponente – von **Genesis** (etwas völlig Neues) über **Custom** (maßgeschneiderte Lösung), **Product** (ein fertiges Produkt) bis zu **Commodity** (eine standardisierte und austauschbare Komponente). Jede Phase hat ihre eigenen Eigenschaften, Risiken und Anforderungen. Fehler entstehen, wenn wir Technologien oder Lösungen in einer falschen Phase einsortieren. Ein besonders anschauliches Beispiel ist das Thema **Dienstreiseantrag** – ein Prozess, den viele Unternehmen kennen. In einem meiner Projekte wurde dieser Prozess mittels BPMN digitalisiert. Die Begründung: “Unsere Anforderungen sind speziell, wir brauchen dafür eine maßgeschneiderte Lösung, kein Standardsystem ist geeignet.” Die Konsequenz war, dass wir nicht nur den Prozess individuell modellierten, sondern auch ein eigenes Tool für das Formulardesign entwickelten, weil angeblich keine bestehende Lösung passte. Genau hier zeigt Wardley Mapping seinen Wert. Auf der Map lässt sich klar erkennen: Ein Dienstreiseantrag ist ein Prozess mit sehr niedriger Kunden-Sichtbarkeit und hohem Reifegrad – also **Commodity**. Auch das Formulardesign für diesen Anwendungsfall gehört in denselben Bereich. Der Markt bietet unzählige ausgereifte und kostengünstige Lösungen – warum also selbst entwickeln? Natürlich kann es gute Gründe geben, ein eigenes Formulardesign zu bauen – etwa wenn man wirklich in einem Umfeld agiert, in dem extrem hohe Anforderungen an Usability, Accessibility oder dynamische Logik gestellt werden, die kein Produkt am Markt erfüllt. Aber dann sollte auch klar sein: Wir verlassen bewusst den Commodity-Bereich und begeben uns in Custom oder sogar Genesis. Das bedeutet mehr Verantwortung, mehr Risiken und mehr langfristigen Pflegeaufwand. In unserem Fall jedoch war das nicht gerechtfertigt. Wir verschwendeten wertvolle Monate und interne Ressourcen auf ein Problem, das längst gelöst war – und damit meine ich nicht nur das Thema Formulardesign, sondern den gesamten Prozess. War es wirklich notwendig, diesen individuell aufzubauen, anstatt auf eine bewährte Lösung zurückzugreifen? Ein Beispiel zur Verdeutlichung: Angenommen, unsere Dienstreisen stehen hauptsächlich im Zusammenhang mit Workshops, die wir für Kunden anbieten. Wie entscheidend ist in diesem Fall das Reisemanagement für unseren eigentlichen Wertbeitrag? Trägt eine individuelle Abbildung des Dienstreiseprozesses tatsächlich zur Verbesserung unserer Beratungsleistung bei? Oder wäre es sinnvoller, den Prozess zu vereinfachen und ihn in ein Standardsystem zu überführen, um unsere Energie auf das zu richten, was uns als Unternehmen wirklich differenziert? Hier hilft Wardley Mapping dabei, blinde Flecken aufzudecken und diese Diskussionen im Team offen zu führen. Wardley Maps zwingen uns, unbequeme Fragen zu stellen – und genau das ist ihr größter Wert. Sie helfen, knappe Ressourcen gezielt einzusetzen und Klarheit über technologische und organisatorische Entscheidungen zu schaffen. ## Die Komplexität im Griff behalten – Wir brauchen eine Bewertungsgrundlage für Entscheidungen Nachdem wir mit Wardley Mapping einen ersten Kompass gefunden haben, stellt sich die nächste zentrale Frage: Wie bewerten wir unsere Vorgehensweise in komplexen Automatisierungsvorhaben richtig? “The most fundamental problem in software development is complexity.” — Bjarne Stroustrup Die Antwort liegt in einem besseren Verständnis von **Komplexität** – denn sie ist der ständige Begleiter jeder Digitalisierung. Und zwar in zwei Spielarten - der essentiellen und der akzidentellen Komplexität: - **Essentielle Komplexität** ist die Komplexität, die dem eigentlichen Problem innewohnt. Sie gehört zur Domäne, zum Prozess oder zur Geschäftstätigkeit. Diese Komplexität können und sollen wir nicht wegrationalisieren – sie ist Teil der Wertschöpfung. - **Akzidentelle Komplexität** hingegen entsteht durch unsere Entscheidungen: durch zu ambitionierte Plattformstrategien, unnötige Individualentwicklung, technische Fehlgriffe oder Missverständnisse zwischen IT und Fachbereich. Ein konkretes Beispiel: Beim Dienstreiseantrag aus meinem früheren Projekt war die essentielle Komplexität minimal. Es geht im Kern um ein simples Regelwerk: Wer darf wann, wohin, mit welchem Transportmittel reisen. Doch statt diesen Prozess pragmatisch und mit einer vorhandenen Lösung am Markt zu digitalisieren, hielten wir am bestehenden Ablauf fest – mit all den Sonderfällen, Genehmigungsschleifen und historischen Ausnahmen. Der Wille, den Prozess im Zuge der Transformation zu hinterfragen und bewusst zu vereinfachen, fehlte schlichtweg. Stattdessen begannen wir, den Status quo digital nachzubauen. Schnell entstanden Sonderfälle wie “Genehmigung über drei Hierarchieebenen”. Anstatt den Prozess zu transformieren, haben wir ihn zementiert – nur eben digital. Diese Anforderungen führten dazu, dass der Prozess nicht nur komplexer wurde, sondern dass wir meinten, eine eigene BPM-Lösung, ein individuelles Formulardesign und eine umfassende Integrationsplattform zu benötigen. Das Ergebnis: massive akzidentelle Komplexität, die wir selbst erzeugt hatten. Rückblickend war das überdimensioniert und hätte vermieden werden können, wenn wir den Mut gehabt hätten, den Prozess zu vereinfachen und auf vorhandene Standards zu setzen. Der Einsatz einer fertigen Low Code Plattform wäre auch ein möglicher Lösungsweg gewesen. Aber dafür müssen die verantwortlichen Personen bereit sein, die eigenen Anforderungen und Wünsche an die Funktionen der Plattform anzupassen. Sonst laufen wir Gefahr die Vorteile einer solchen Lösung zu verspielen und wundern uns dann, warum der gewünschte Geschwindigkeitsvorteil ausbleibt. Wenn wir verstehen, welche Prozesse im Unternehmen tatsächlich geschäftskritisch und einzigartig sind – und welche nicht –, können wir bewusst entscheiden: Was rechtfertigt Individualaufwand? Und was ist schlichtweg Commodity, das wir zukaufen oder standardisieren sollten? Komplexität lässt sich nicht vermeiden, aber sie lässt sich gestalten. Die wichtigste Leitfrage dabei lautet: **Wie viel von unserer Komplexität ist wirklich notwendig – und wie viel davon haben wir selbst verursacht?** Eine kluge Automatisierungsstrategie fokussiert sich darauf, die akzidentelle Komplexität systematisch zu reduzieren. ## Plattform – Fluch oder Segen? Ein weiterer Stolperstein der auf uns wartet, ist die Bereitstellung und Weiterentwicklung einer zentralen Plattform. Der Gedanke klingt zunächst nachvollziehbar - schließlich verspricht eine Plattform Wiederverwendbarkeit, Konsistenz und Skaleneffekte. Sie erscheint wie das ideale Schweizer Taschenmesser: Ein Tool, das für jeden Prozess, jedes Team und jede Situation gewappnet ist. Doch genau hier lauert die nächste große Falle: Der Versuch, zu früh eine Plattform zu bauen, endet häufig nicht bei einem eleganten Werkzeug, sondern bei einem überdimensionierten Multifunktionsgerät, das unhandlich, schwer wartbar und kaum mehr zu verwenden ist. Plattformen machen dann Sinn, wenn sie sich auf standardisierte, gut verstandene Funktionen konzentrieren – also dort, wo wir uns im Wardley Mapping im Bereich **Product** oder **Commodity** befinden. Eine Plattform für Authentifizierung oder Dokumentengenerierung kann extrem wertvoll sein, weil sie technische Grundlagen effizient bereitstellt. Problematisch wird es jedoch, wenn wir mit dem Bauen eigener Plattformen beginnen, noch bevor wir den tatsächlichen Bedarf und die Prozesse wirklich verstanden haben – oder noch schlimmer: Wenn die Plattform selbst noch im **Custom**\- oder sogar **Genesis**\-Stadium ist. In diesen Fällen zementiert die Plattform Annahmen und Anforderungen, die sich noch im Fluss befinden. Damit erschwert sie Anpassungen, verlangsamt die Entscheidungswege und erhöht massiv die kognitive Last aller beteiligten Teams. Ein zu früher Plattformansatz bedeutet in der Praxis: Man muss Entscheidungen vorwegnehmen, Abhängigkeiten managen, Schnittstellen definieren und gleichzeitig sicherstellen, dass alles stabil und flexibel bleibt. Das funktioniert selten – vor allem nicht mit einem Team, das gerade erst am Anfang der Automatisierung steht. Die Konsequenz ist, dass man mehr mit der Pflege der Plattform beschäftigt ist als mit dem eigentlichen Ziel: Prozesse sinnvoll zu automatisieren und den Fachbereichen echte Mehrwerte zu liefern. Kurz gesagt: Eine Plattform ist kein Allheilmittel – sie ist ein Werkzeug für die richtige Phase, aber kein Startpunkt für jede Initiative. ## Die richtigen Teams finden und organisieren Nach dem Blick auf technologische Plattformen stellt sich eine weitere Frage: Wie müssen wir eigentlich organisiert sein, damit wir die Herausforderungen der Digitalen Transformation erfolgreich bewältigen können? Denn **eine gute technologische Grundlage alleine genügt nicht – es braucht die passenden Menschen in den passenden Strukturen.** Conways Law bringt es auf den Punkt: Die Struktur von Software-Systemen spiegelt die Kommunikationsstrukturen der Organisation wider, die sie hervorgebracht hat. Wenn Teams fragmentiert arbeiten, unterschiedliche Ziele verfolgen oder stark voneinander abhängig sind, wird sich genau das in den Systemen und Plattformen widerspiegeln – mit allen bekannten Problemen. Und hier setzt das Konzept von **Team Topologies** an – ein Modell, das uns hilft, Teams so zu strukturieren, dass sie eigenverantwortlich und effektiv arbeiten können. Team Topologies unterscheidet dabei in vier Teamtypen und drei Interaktionsmodi, mit dem Ziel, **kognitive Last zu reduzieren**, **schnelle Veränderungen zu ermöglichen** und **klare Verantwortlichkeiten** zu schaffen: - **Stream-Aligned Teams** sind das Herzstück: Sie sind entlang eines fachlichen oder wertschöpfenden Flusses ausgerichtet – z.B. eines Prozesses – und sollen möglichst autonom agieren können. Sie tragen Verantwortung von der Anforderung bis zum Betrieb. - **Enabling Teams** unterstützen Stream-Aligned Teams durch Coaching, Schulung oder methodische Beratung, z.B. bei der Einführung neuer Technologien oder Praktiken. - **Complicated Subsystem Teams** kümmern sich um komplexe technische Domänen, bei denen tiefes Spezialwissen erforderlich ist – wie z.B. Machine Learning oder Process Engines. - **Plattform-Teams** stellen wiederverwendbare Services und Tools bereit, welche die Arbeit der Stream-Aligned Teams erleichtern. Sie minimieren kognitive Last durch gute Developer Experience und klar definierte Schnittstellen. Diese Struktur ist nicht nur ein theoretisches Konstrukt – sie hilft ganz praktisch dabei, Verantwortlichkeiten sauber zu trennen und Blockaden zu vermeiden. Statt langwierigen Abstimmung zwischen IT und Fachbereich gibt es ein gemeinsames Ziel: schnelle, fachlich getriebene Veränderungen, die durch autonome Teams realisiert werden. Gerade in der Prozessautomatisierung ist diese Struktur Gold wert. Denn dort treffen häufig klassische Fachbereichslogik, technische Anforderungen und organisatorische Veränderungen aufeinander. Nur wenn Teams in der Lage sind, fachliche Anforderungen direkt umzusetzen – ohne permanent auf zentrale Plattform-Teams oder Gremien angewiesen zu sein – entstehen schnelle Innovationszyklen. Team Topologies liefert dafür den passenden Bauplan. Man kann klein anfangen. Ein einziges gut aufgestelltes Stream-Aligned Team reicht, um erste Automatisierungserfolge zu erzielen. Skaliert wird erst, wenn nötig – und zwar bewusst aufgrund der kognitiven Last, nicht aufgrund abstrakter Organigramme. Ein Vorgehen könnte vereinfacht dargestellt wie folgt aussehen: - Zu Beginn sollten Methoden und Technologien gewählt werden, die es erlauben, in einem Lighthouse-Projekt mit einem einzigen Stream-Aligned Team zu starten. Dieses Team sollte den gesamten Lebenszyklus eines Automatisierungsvorhabens abbilden können – von der Fachanforderung bis zum Betrieb. - Wird die kognitive Last bei weiteren Use Cases für ein einzelnes Team zu hoch, sollte anhand klarer fachlicher Grenzen aufgeteilt werden. An diesem Punkt lohnt es sich, über den Einsatz von Enabling Teams nachzudenken, die methodisch, technisch oder organisatorisch unterstützen können – etwa durch Schulungen, Frameworks oder gezieltes Coaching. - In einer weiteren Ausbaustufe wird es sicherlich zu einem Punkt kommen, an dem verschiedene Funktionalitäten oder Prozessartefakte zwischen Teams geteilt werden sollen – etwa Komponenten für Integration, Formulargenerierung oder Monitoring. Das Ganze ergibt dann eine Plattform – idealerweise in Form eines dedizierten Plattformteams mit klaren Schnittstellen und einem Fokus auf Developer Experience. Wichtig ist, die **richtige organisatorische Komplexität zur richtigen Zeit** zu schaffen. Wer zu früh zu viel will, überfordert Teams und bremst Innovation. ## Erfolg messbar machen Nach der Teamstruktur stellt sich unweigerlich eine weitere zentrale Frage: **Woher wissen wir eigentlich, ob wir auf dem richtigen Weg sind?** In vielen Organisationen kommt dieser Gedanke oft zu spät. Dabei ist es essenziell, Erfolg nicht nur zu vermuten, sondern ihn gezielt zu messen – und das möglichst frühzeitig. Wie messen wir also den Erfolg unserer Initiativen? Diese Frage taucht in fast jedem Transformationsprojekt irgendwann auf – und sie ist absolut berechtigt. Denn ohne ein gemeinsames Verständnis davon, was “Erfolg” überhaupt bedeutet, kann es auch keine gezielte Verbesserung geben. Wir brauchen ein gemeinsames Vokabular, um Fortschritt greifbar zu machen. Ein bewährter Rahmen dafür sind die **DORA-Metriken**, die aus der DevOps-Forschung stammen und in vielen erfolgreichen Unternehmen eingesetzt werden. Sie helfen, die Leistungsfähigkeit von Teams und technischen Systemen messbar zu machen: - **Lead Time for Change** – Wie lange dauert es vom ersten Commit bis zur produktiven Auslieferung einer Änderung? - **Deployment Frequency** – Wie oft werden Änderungen in die Produktion gebracht? - **Failed Deployment Rate** – Wie häufig führen Deployments zu Störungen oder Rollbacks? - **Mean Time to Recovery (MTTR)** – Wie schnell können Systeme nach einem Ausfall wiederhergestellt werden? Diese Metriken liefern ein objektives Bild darüber, wie gut Teams in der Lage sind, Änderungen effizient, stabil und sicher umzusetzen. Gerade bei der Automatisierung von Prozessen im Gensis und Custom Bereich – wo Fachgebiet, IT und Betrieb ineinandergreifen müssen – sind sie eine wertvolle Orientierungshilfe. Wenn wir den BPM Lifecycle ernst nehmen und wirklich leben wollen, bedeutet das auch, den Cost of Change zu reduzieren. Es reicht nicht, Prozesse einmal zu automatisieren – sie müssen auch kontinuierlich angepasst und verbessert werden können. Genau deshalb brauchen wir Teams und Strukturen, die veränderungsbereit und agil sind. Der Fokus verschiebt sich weg vom einmaligen Projekterfolg hin zur dauerhaften Wandlungsfähigkeit einer Organisation – und hier helfen die DORA-Metriken, diese Fähigkeit messbar und transparent zu machen. Doch genauso wichtig ist die Einsicht: Diese Metriken sind ein guter Startpunkt – aber sie sind nicht das Ende der Diskussion. Jede Organisation darf und sollte ihre eigenen Metriken entwickeln. Denn vielleicht ist für euch nicht die reine Deployment-Frequenz entscheidend, sondern eher, wie schnell ein digitalisierter Prozess dem Endanwender spürbaren Nutzen bringt. Oder es ist die **Durchlaufzeit eines Geschäftsprozesses** – etwa vom Eingang eines Antrags bis zur finalen Genehmigung. Das kann eine wertvolle Metrik sein, um den Erfolg einer Automatisierung auf fachlicher Ebene zu bewerten. Aber all diese ergänzenden Metriken haben eines gemeinsam: Sie müssen in einen übergeordneten Rahmen eingebettet sein. Und genau hier liegt der Wert der DORA-Metriken. Sie fokussieren nicht auf das Ergebnis eines einzelnen Prozesses, sondern auf die Fähigkeit eines Teams, **Veränderungen überhaupt zuverlässig und schnell umzusetzen**. Genau das ist essenziell für jede digitale Transformation. Denn Transformation ist mehr als nur Technologie oder Prozesse – sie ist ein kontinuierlicher Wandel. Und dieser Wandel gelingt nur, wenn Teams in der Lage sind, iterativ zu arbeiten, Feedbackzyklen zu verkürzen und Verantwortung zu übernehmen. Deshalb ist DORA so wichtig: Die Metriken messen nicht nur Output, sondern sie zeigen auf, wie gut die Organisation als Ganzes auf Veränderung eingestellt ist. ## Nimm deine Transformation selbst in die Hand! Wenn wir uns nun die Frage stellen, wer eigentlich für die Umsetzung der Transformation verantwortlich sein sollte, stoßen wir auf einen der sensibelsten Punkte in jedem Projekt: **Make or Buy**? Nach all dem, was wir über Prozesse, Teams, Technologien und Metriken gelernt haben, ist klar: Diese Entscheidung sollte nie pauschal, sondern stets kontextbezogen getroffen werden. Und genau hier kommt Wardley Mapping ein letztes Mal zum Tragen. Wardley Maps helfen uns zu erkennen, **welche Fähigkeiten wir intern aufbauen und bewahren müssen**, und **wo es sinnvoll ist, auf externe Partner zu setzen**. Die Grundregel lautet: - **Genesis** und **Custom**: Hier seid ihr im Innovationsbereich. Es geht um neue, noch unausgereifte oder stark an eure Organisation angepasste Lösungen. Diese Komponenten sind eng mit eurer Strategie verbunden – hier braucht ihr Teams, die eure Fachlichkeit verstehen, eng mit euren Stakeholdern arbeiten und schnell reagieren können. - **Product** und **Commodity**: In diesen Bereichen ist die Lösung ausgereift, vergleichbar und am Markt verfügbar. Hier macht es absolut Sinn, externe Dienstleister einzubinden oder ganze Aufgabenpakete auszulagern – zum Beispiel Hosting, Standardintegrationen oder Infrastruktur. Das bedeutet auch: Nicht jede Leistung, die ein externer Partner anbietet, sollte blind beauftragt werden – besonders nicht im Genesis- oder Custom-Bereich. Dort braucht ihr Teams, die eng in eure Geschäftsprozesse eingebunden sind, Verantwortung übernehmen und strategische Entscheidungen treffen können. Und diese Teams bestehen idealerweise aus internen Mitarbeiter:innen, unterstützt durch gezielte externe Expertise. Ich selbst bin Berater – und genau deshalb weiß ich, wo meine Rolle aufhört. Ich kann euch helfen, Geschwindigkeit aufzunehmen, unnötige Fehler zu vermeiden und Struktur zu schaffen. Aber ich würde euch niemals empfehlen, die Verantwortung für eure Transformation in meine Hände zu legen. Denn Transformation bedeutet Wandel – und Wandel gelingt nur gemeinsam. Nur wenn ihr selbst versteht, warum ihr etwas tut, welche Prinzipien euch leiten und welche Ziele ihr verfolgt, kann nachhaltiger Fortschritt entstehen. In diesem Sinne: [Nimm deine Transformation selbst in die Hand](/leistungen/) – mit den richtigen Methoden, mit dem passenden Team und mit der Klarheit darüber, was wirklich zählt. ## Survival-Tipps Nach all den Erfahrungen, Erkenntnissen und auch Rückschlägen der letzten Jahre möchte ich euch zum Abschluss noch einige Kernpunkte mitgeben – meine “Lessons Learned”. Wenn ich heute eine Automatisierungsinitiative starte, sind es genau diese Prinzipien, auf die ich Wert lege. - Schaffe Situational Awareness für bessere Entscheidungen. - Sei bereit für Transformation, nicht nur für Digitalisierung. - Definiere KPIs und Messe deinen Erfolg. - Halte die akzidentelle Komplexität so gering wie möglich. - Stelle deine Teams auf Wandel ein. - Behalte die Hoheit über die wichtigen Ressourcen deiner Transformation. Letztendlich gilt: Die beste Technologie und Methode nutzt nichts ohne Klarheit über den Kontext und Teams, die wirklich autonom arbeiten können. Ich hoffe, meine Erfahrungen helfen euch, einige meiner Fehler zu vermeiden und eure Automatisierungsprojekte nachhaltig und erfolgreich zu gestalten. Lasst uns gemeinsam Komplexität meistern! Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fkomplexitaet-meistern-prozessautomatisierung%2F)[](mailto:?subject=Komplexit%C3%A4t%20meistern%20%E2%80%93%20Wie%20Prozessautomatisierung%20gelingt&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fkomplexitaet-meistern-prozessautomatisierung%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Transformation 17\. März 2025 ### Wie Wardley Mapping das Not-Invented-Here Syndrom vermeiden kann Wie Wardley Mapping Teams hilft, strategische Entscheidungen über Eigenentwicklung vs. Zukauf zu treffen und das NIH-Syndrom zu überwinden. Dominik Horn Co-Founder & Geschäftsführer ](/blog/wie-wardley-mapping-not-invented-here/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Komplexität navigieren: Von Verwirrung zu Klarheit durch klare Perspektiven](https://www.miragon.io/blog/komplexitaet-navigieren-perspektiven/) Softwareentwicklung Zwei Perspektiven zur Kategorisierung von Komplexität in Softwaresystemen: Wo lebt sie (lokal vs. global) und warum existiert sie (essenziell vs. akzidentell)? Marco Schäck Process Development Lead **24\. Okt. 2025**13 Min. Lesezeit Egal wer wir sind — ob Entwickler, Architekten oder Berater — in den meisten IT-Projekten werfen wir mit dem Wort “Komplexität” umher wie mit Konfetti auf einer Silvesterparty. “Das ist zu komplex”, heißt es oft. “Lass uns hier die Komplexität reduzieren.” Aber hast du schon einmal innegehalten und dich gefragt: _Wovon reden wir hier eigentlich genau?_ Durch Recherche und Reflexion zu dieser Frage habe ich zwei Perspektiven entdeckt, die meine Herangehensweise an Komplexität in der Softwareentwicklung verändert haben: das Verständnis dafür, **wo** Komplexität in unseren Systemen lebt (lokal versus global) und **warum** sie überhaupt existiert (essenziell versus akzidentell). Diese Rahmenwerke bieten einen strukturierteren Weg, um Komplexitätsdiskussionen und -entscheidungen anzugehen. Dieser Post ist jedoch nicht als kompakte Erkundung nur dieser beiden Perspektiven gedacht. Stattdessen ist es eine breitere Reflexion über meine Erkenntnisse zur Komplexität — einschließlich Exkursen zu verwandten Ideen und Präventionsstrategien. Mein Ziel ist es, Einsichten zu teilen, die dir nicht nur dabei helfen, Komplexität systematischer anzugehen — sondern auch tiefere Reflexion über das Thema fördern. ## Warum ich begonnen habe, “Komplexität” zu hinterfragen Ich habe unzählige Stunden in Retros, Pair-Programming-Sessions und Architektur-Diskussionen verbracht, in denen alle wissend über Komplexität genickt haben. Dennoch vermute ich, dass wir oft über völlig verschiedene Dinge sprechen. Es ist wie eine Gruppe von Menschen, die einen Elefanten beschreiben, während sie verbundene Augen haben — jeder berührt einen anderen Teil und zieht völlig unterschiedliche Schlüsse. Denk an das letzte Mal, als dein Team in einer endlosen Schleife von “das ist komplex”-Aussagen stecken geblieben ist, ohne Fortschritte zu machen. Kommt dir bekannt vor? Mir fiel auf, dass wir ohne eine präzisere Art, über Komplexität zu diskutieren, immer wieder oberflächliche Gespräche führten, die nirgendwo hinführten. Egal ob wir über Refactorings debattierten oder eine Architektur planten, dieselben vagen Beschwerden kamen immer wieder auf, während die echten Probleme verborgen blieben. Dieses Muster wurde unmöglich zu ignorieren: - Wir identifizierten etwas als “komplex”, konnten uns aber nicht darauf einigen, was es komplex machte - Lösungen verfehlten oft ihr Ziel, weil wir verschiedene Probleme lösten - Team-Diskussionen fühlten sich frustrierend zirkulär an, alle redeten aneinander vorbei Das waren keine isolierten Vorfälle — sie waren Symptome eines tieferen Kommunikationsproblems, das meine Neugier weckte, tiefer zu graben, was Komplexität in unserem Kontext tatsächlich bedeutet. ## 📖 Ein kurzer Exkurs: Komplex vs. Kompliziert Bevor wir tiefer eintauchen, gibt es eine wichtige Unterscheidung, die es wert ist, geklärt zu werden und die oft unsere Komplexitätsdiskussionen verwirrt: der Unterschied zwischen den Begriffen “komplex” und “kompliziert.” Während wir diese Begriffe im Alltagsgespräch als Synonym verwenden, beschreiben sie grundlegend verschiedene Phänomene. Wenn Dinge wie Softwaresysteme **kompliziert** sind, haben sie viele Teile, aber die Beziehungen zwischen diesen Teilen sind vorhersagbar und gut verständlich. Denk an eine mechanische Uhr. Sie hat Hunderte von Komponenten, aber jeder Teil hat eine klare, deterministische Funktion. Wenn Dinge hingegen **komplex** sind, zeigen sie emergente Verhaltensweisen aus den Interaktionen ihrer Teile. Das Verhalten des Ganzen kann nicht einfach durch das Verstehen der einzelnen Komponenten vorhergesagt werden. Betrachte einen Stau zur Hauptverkehrszeit. Selbst wenn du das Verhalten jedes Fahrers verstehst, kannst du nicht genau vorhersagen, wie der Verkehr fließen wird oder wo sich Engpässe bilden werden. ### Warum dies für die Diskussionen rund um Komplexität wichtig ist Diese Unterscheidung ist entscheidend, weil sie unseren Lösungsansatz prägt. Komplizierte Probleme reagieren gut auf Zerlegung und systematische Analyse. Komplexe Probleme hingegen erfordern verschiedene Strategien wie Experimente, Anpassung und die Akzeptanz, dass manche Unsicherheit nicht eliminiert werden kann. Die Perspektiven, die ich unten teilen werde, adressieren primär Komplexität in Softwaresystemen. Jene unvorhersagbaren Eigenschaften, die entstehen, wenn Komponenten auf Weisen interagieren, die schwer vollständig zu antizipieren oder zu kontrollieren sind. Das Verständnis dieser Unterscheidung hilft uns, die richtigen Werkzeuge für jeden Problemtyp auszuwählen. ## Die zwei Arten von Komplexität Im Rahmen meiner Analyse entdeckte ich einige Ansätze, um Komplexität zu kategorisieren und darüber nachzudenken. Vor allem zu zweien von diesen habe ich mich jedoch besonders hingezogen gefühlt, da durch diese die meisten Probleme, die ich erlebte, gelöst werden konnten. Zudem erweisen sie sich als besonders nützlich, weil sie sich ergänzen. Sie umfassen: - **Lokale & Globale Komplexität**: Beantwortung der Frage, wo Komplexität in unseren Systemen lebt - **Essenzielle & Akzidentelle Komplexität**: Betrachtung, warum die Komplexität überhaupt existiert Lass mich diese beiden Konzepte mit einem konkreten Beispiel illustrieren. ## Unser Beispiel: Ein E-Commerce-Benachrichtigungssystem Stell dir vor, du arbeitest an einer Microservice-Architektur für eine E-Commerce-Plattform. Dein Team verwaltet den Benachrichtigungsservice, der Bestellbestätigungen, Versand-Updates und Werbe-E-Mails versendet. Im Laufe der Zeit ist dieser scheinbar einfache Service zu einem Auslöser ständiger Kopfschmerzen geworden. Lass uns dieses Szenario nutzen, um zu erkunden, wie diese Perspektiven uns helfen könnten, anders zu denken. ## Die “Wo”-Frage: Komplexität in deinem System lokalisieren Die erste Dimension konzentriert sich darauf, wo sich Komplexität in unseren Systemen manifestiert: Ob sie innerhalb einzelner Komponenten konzentriert ist oder aus deren Interaktionen entsteht. Diese Perspektive wird detailliert von Vlad Khononov in seiner Arbeit über [untangling microservices](https://vladikk.com/2020/04/09/untangling-microservices/#:~:text=In%20our%20context%2C%20local%20complexity,and%20dependencies%20between%20the%20services) und seinem Buch [Learning Domain-Driven Design](https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/) erkundet. ### Lokale Komplexität: Der Teufel steckt im Detail Wenn die meisten Entwickler den Begriff “Komplexität” hören, ist das wahrscheinlich das, was ihnen zuerst in den Sinn kommt. Es ist der Typ, dem wir täglich in Code-Reviews und Debugging-Sessions begegnen, was ihn zur vertrautesten und unmittelbarsten Form der Komplexität macht. Lokale Komplexität residiert innerhalb einzelner Komponenten, Funktionen oder Services. Es ist die verworrene bedingte Logik, die verschachtelten Schleifen, die Daten verarbeiten, oder die Zustandsmaschinen, die Workflows handhaben. Betrachte diese Funktion aus unserem Benachrichtigungsservice: ``` // Beispiel für lokale Komplexität fun formatNotification(user: User, event: Event, preferences: Preferences) { if (event.type == "order" && user.tier == "premium") { if (preferences.email && preferences.promotions) { // 15 weitere Zeilen bedingter Logik... } } // Du verstehst die Idee... } ``` Funktionen wie diese sind lokal komplex — schwer zu verstehen, zu testen und isoliert zu modifizieren. Doch dieser nach innen gerichtete Fokus auf einzelne Komponenten erzählt nur die halbe Geschichte. ### Globale Komplexität: Das Netz, das wir weben Globale Komplexität entsteht aus den Interaktionen zwischen Komponenten, Services und Systemen. Es geht nicht darum, dass ein einzelnes Stück kompliziert ist; es geht darum, wie die Stücke zusammenpassen und sich gegenseitig beeinflussen. Um diese Perspektive klarer zu illustrieren, betrachte, wie unser Benachrichtigungsservice eine typische Bestellbestätigung orchestriert: ``` fun sendOrderConfirmation(orderId: String) { val order = orderService.getOrder(orderId) val user = userService.getUser(order.userId) val preferences = preferencesService.getPreferences(user.id) if (shouldSendEmail(user, preferences)) { val template = templateService.getTemplate("order_confirmation") val personalizedContent = personalizationService.customize(template, user, order) emailService.send(personalizedContent, user.email) auditService.logNotification(user.id, "email_sent") metricsService.recordEvent("notification.sent", "email") } } ``` Jeder einzelne Service-Aufruf mag einfach sein, aber die koordinierte Choreografie zwischen sechs verschiedenen Services führt zu globaler Komplexität. Die Herausforderungen entstehen nicht aus der individuellen Logik, sondern aus Netzwerklatenz, Service-Ausfällen, eventueller Konsistenz und kaskadierenden Fehlern. ## Die “Warum”-Frage: Den Ursprung der Komplexität verstehen Die zweite Dimension untersucht, warum Komplexität existiert — ob sie ein unvermeidlicher Teil des Problems ist, das wir lösen, oder ob wir sie durch unsere Designentscheidungen geschaffen haben. Diese Unterscheidung wurde ursprünglich von Fred Brooks in seinem einflussreichen Essay [“No Silver Bullet”](https://en.wikipedia.org/wiki/No_Silver_Bullet) artikuliert. ### Essenzielle Komplexität: Das unvermeidbare Herz des Problems Essenzielle Komplexität ergibt sich direkt aus dem Problem, das wir lösen. Es ist die inhärente Schwierigkeit, die im Problem selbst liegt, nicht in unserer Lösung. Egal wie geschickt wir beim Design sind, diese Komplexität kann nicht eliminiert werden — nur verwaltet, gekapselt oder an eine andere Ebene verlagert werden. In unserem E-Commerce-Beispiel stellen Geschäftsregeln wie diese essenzielle Komplexität dar: - Premium-Kunden erhalten andere Benachrichtigungsformate als Standard-Kunden - Bestimmte Produktkategorien erfordern regulatorische Warnungen in spezifischen Regionen - Benutzer können komplexe Präferenz-Kombinationen haben (E-Mail aber keine SMS, Werbe-E-Mails aber keine Versand-Updates) Diese Regeln existieren, weil das Geschäft sie benötigt. Du kannst sie in deinem Code klarer ausdrücken, aber du kannst sie nicht wegwünschen. ### Akzidentelle Komplexität: Selbst geschaffene Probleme Akzidentelle Komplexität entsteht aus den Werkzeugen, Frameworks, Designentscheidungen und Implementierungsdetails, die wir wählen. Es ist Komplexität, die wir eingeführt haben, die aber nicht notwendig für das Problem ist, das wir lösen. Häufige Quellen akzidenteller Komplexität in unserem Benachrichtigungsservice könnten sein: - **Over-Engineering**: Verwendung komplexer Muster, obwohl einfache ausreichen würden - **Technische Schulden**: Ansammlung von Workarounds und Quick-Fixes über die Zeit - **Schlechte Service-Grenzen**: Services aufteilen auf eine Weise, die unnötige Koordination schafft - **Framework-Overhead**: Komplexität, die von den Werkzeugen stammt, die wir gewählt haben Das Erkennen akzidenteller Komplexität ist entscheidend, weil es das ist, was wir tatsächlich reduzieren können, ohne die Geschäftsanforderungen zu beeinträchtigen. ## Die Perspektiven kombinieren: Ein 2x2-Framework Als ich die Erkundung jeder Perspektive für sich abgeschlossen hatte, fragte ich mich, ob ihre Kombination zusätzliche Einsichten schaffen könnte, die keine allein bieten konnte. Dieses Experiment der Verbindung der “Wo”- und “Warum”-Dimensionen offenbarte vier logische Kombinationen, jede mit verschiedenen Charakteristika der Komplexität und spezifischen Strategien zu ihrer Bewältigung: ### 1\. Lokal + Essenziell: Kern-Domänen-Logik Wenn Geschäftsregeln im Code implementiert werden, erhältst du typischerweise komplexe Domänen-Logik innerhalb einzelner Funktionen oder Klassen. Das Ziel ist nicht die Eliminierung, sondern ordnungsgemäße Kapselung und klarer Ausdruck. Ich würde [Domain-Driven Design Prinzipien](https://martinfowler.com/bliki/DomainDrivenDesign.html) als Strategien zur Beherschung dieser inhärenten Komplexität zu betrachten. ### 2\. Lokal + Akzidentell: Unnötige Code-Komplexität Wenn wir unnötige Komplexität innerhalb von Komponenten schaffen, enden wir mit Code, der komplexer ist als nötig. Das resultiert typischerweise aus vorzeitiger Optimierung oder falsch angewandten Mustern. Refactorings, Vereinfachung und das Entfernen unnötiger Abstraktionen könnten es wert sein, als Ansätze zur Bewältigung dieser Komplexität erkundet zu werden. ### 3\. Global + Essenziell: Inhärente System-Koordination Wenn Domänen-Anforderungen Koordination über mehrere Komponenten hinweg erfordern, stehst du vor der inhärenten Komplexität der Orchestrierung von Services oder der Verwaltung verteilter Zustände. Klare Grenzen, ereignisgesteuerte Architekturen und eventuell konsistente Muster könnten helfen, die Koordinationsherausforderungen zu bewältigen, die natürlich in verteilten Systemen entstehen. ### 4\. Global + Akzidentell: Architektur-Schulden Wenn schlechte Designentscheidungen unnötige systemweite Komplikationen schaffen, erhältst du Komplexität, die durch fehlerhafte Service-Grenzen, geteilte Datenbanken oder angesammelte technische Entscheidungen eingeführt wurde. Service-Redesign, klare Schnittstellen und systematische Entkopplungsstrategien könnten Ansätze sein, die für die Bewältigung von Komplexität, die aus architektonischen Entscheidungen anstatt aus Domänen-Anforderungen stammt, zu betrachten sind. ## Was diese Perspektiven für mich verändert haben Seit der Erkundung dieser Konzepte denke ich, dass man präziser über Komplexität denken und sprechen kann. Meiner Meinung & Erfahrung nach kann das in mehreren Kontexten hilfreich sein. **Architektur- und Design-Diskussionen** werden zielgerichteter. Anstatt vage zu sagen “dieses Service-Design scheint zu komplex”, könnte man tiefere Fragen erkunden wie: > “Kommt diese Komplexität aus dem tatsächlichen Geschäftsproblem, oder haben wir sie geschaffen, weil wir Service-Grenzen an den falschen Stellen gezogen haben?” Oder bei der Bewertung von Design-Alternativen können Teams betrachten: > “Wenn wir diese Services konsolidieren, reduzieren wir die Gesamtkomplexität — oder verschieben wir nur globale & lokale Komplexität?” **Code-Reviews könnten ebenfalls profitieren.** Anstatt einfach eine Funktion als “komplex” zu kennzeichnen, könnte man konstruktiveres Feedback geben: > “Diese Funktion handhabt mehrere Geschäftsregeln, was etwas lokale Komplexität schafft. Wir könnten Muster wie das Strategy-Pattern einführen, um das handhabbarer zu machen?” ## Die breiteren Vorteile, die ich sehe Zusammenfassend: Basierend auf meiner Analyse, Reflexion und Nutzung dieser Perspektiven glaube ich, dass mehrere Vorteile entstehen, wenn Teams Komplexität systematischer angehen. Sie umfassen: - **Schärfere konzeptionelle Klarheit.** Das Verständnis der Unterscheidung zwischen “komplex” und “kompliziert” sowie der verschiedenen Typen und Perspektiven der Komplexität bietet eine klarere Sicht auf das, womit wir es tatsächlich zu tun haben. Diese konzeptionelle Grundlage ist wesentlich für bessere Entscheidungen. - **Strategischerer Aufwand und realistischere Erwartungen.** Teams können ihre Energie dort fokussieren, wo es am wichtigsten ist — Reduktion akzidenteller Komplexität während sie akzeptieren, dass essenzielle Komplexität Teil der Problemdomäne ist. Dieser Ansatz hilft bei der systematischeren Bewertung von Trade-offs und hilft Teams zu erkennen, ob sie wirklich Komplexität reduzieren oder sie nur im System umverteilen. - **Bessere Kommunikation führt zu zielgerichteten Lösungen.** Ein spezifisches Vokabular für verschiedene Arten von Komplexität zu haben hilft Teams zu diskutieren, was sie tatsächlich zu lösen versuchen und zu entscheiden, ob Komplexität es wert ist, dokumentiert, refaktoriert oder als gegeben akzeptiert zu werden, was natürlich zu zielgerichteteren architektonischen und Code-Level-Lösungen führt. ## Erwartungen realistisch halten Seien wir realistisch — wird jeder magisch zu dieser Denkweise wechseln? Wahrscheinlich nicht. Zumindest nicht sofort. Teams dazu zu bringen, ihre Art zu ändern, wie sie über Probleme sprechen, ist notorisch schwierig. Und nicht jeder wird diese Unterscheidungen so nützlich finden wie ich. Team-Dynamiken, Zeitdruck und vorhandenes Wissen sowie Kommunikationsmuster beeinflussen alle, ob Ansätze wie dieser tatsächlich haften bleiben. Aber selbst wenn es den Ansatz deines ganzen Teams nicht über Nacht transformiert, könnte dieses Framework dir helfen, bessere Fragen zu stellen oder zielgerichtetere Lösungen vorzuschlagen. Manchmal reicht das aus, um ein Gespräch in eine produktivere Richtung zu lenken. ## Eine Notiz zur Prävention: Über das Verwalten von Komplexität hinaus Während diese Perspektiven uns helfen, existierende Komplexität zu verstehen und zu diskutieren, ist es genauso wichtig, unnötige Komplexität daran zu hindern, überhaupt erst eingeführt zu werden. Die Frameworks, die ich geteilt habe, konzentrieren sich darauf, Komplexität zu navigieren, sobald sie vorhanden ist, aber wie vermeiden wir es, akzidentelle Komplexität von Anfang an zu schaffen? Hier sind einige proaktive Strategien — allerdings sicherlich keine erschöpfende Liste: **Entscheidungstransparenz und Dokumentation** Das Explizitmachen architektonischer Entscheidungen hilft Teams, vergangene Fehler nicht zu wiederholen und bietet Kontext für zukünftige Änderungen. Architecture Decision Records (ADRs) sind hier besonders wertvoll. Mein Kollege hat [einen Post über ADRs](https://www.notion.so/miragon/insert-colleague-adr-link) geschrieben, der ihre Grundlagen abdeckt. Wenn Entscheidungen als ADRs dokumentiert werden, können Teams besser bewerten, ob sie essenzielle oder akzidentelle Komplexität einführen — oder ob es überhaupt notwendig ist, die Alternativen bedenkend. **Kontinuierliche architektonische Verbesserung** Regelmäßige Diskussions- und Review-Prozesse verhindern, dass sich Komplexität unbemerkt ansammelt. Die [Thoughtworks Technology Podcast](https://www.thoughtworks.com/de-de/insights/podcasts/technology-podcasts) Serie über den [Architecture Advice Process](https://www.thoughtworks.com/en-de/radar/techniques/architecture-advice-process) beschreibt eine Methodologie, die alle Team-Mitglieder in architektonische Entscheidungen einbezieht, nicht nur wenige Ausgewählte. Dieser Ansatz fördert eine Kultur der kontinuierlichen Verbesserung anstatt reaktiven Komplexitätsmanagements. **Fitness-Funktionen und automatisierte Leitplanken** Automatisierte Werkzeuge können viele Formen akzidenteller Komplexität verhindern. Architektur-Test-Tools wie [ArchUnit](https://www.archunit.org/) kodieren Designentscheidungen als ausführbare Tests und fangen Verletzungen ab, bevor sie sich festsetzen. Ähnlich stellen Tools wie [Konsist](https://github.com/LemonAppDev/konsist), [ktLint](https://pinterest.github.io/ktlint/latest/), [ESLint](https://eslint.org/) oder [Prettier](https://prettier.io/) sicher, dass Teams bei vereinbarten Coding-Standards bleiben und die graduelle Drift verhindern, die oft zu unnötiger Komplexität führt. Dieses ganze Thema automatisierter Komplexitätsprävention verdient tiefere Erkundung — etwas, was ich in einem zukünftigen Post zu behandeln plane. Diese Präventionsstrategien ergänzen die Perspektiven, die wir diskutiert haben und ermutigen zum Denken über das bloße Verwalten existierender Komplexität hinaus. Das Ziel ist nicht, alle Komplexität zu eliminieren — essenzielle Komplexität wird immer existieren — sondern absichtlicher bezüglich der Komplexität zu sein, die wir durch unsere Entscheidungen einführen. ## Einen Versuch wert? Ich bin neugierig, ob diese Perspektiven mit deiner Erfahrung mitschwingen. Versuch vielleicht, ein System zu betrachten, das dein Team als “komplex” betrachtet, durch diese Linsen: 1. **Wähle etwas aus**, womit dein Team kämpft 2. **Versuche zu kategorisieren**, welche Komplexität du siehst 3. **Bemerke**, ob es ändert, wie du über potenzielle Lösungen denkst ## Was sind deine Erfahrungen? Ich bin wirklich neugierig, wie andere über Komplexität denken und diskutieren. Obwohl diese Konzepte für meine Arbeit wertvoll waren, weiß ich trotzdem, dass jedes Team und jeder Kontext verschiedene Herausforderungen mit sich bringen. Daher meine Frage: Welche mentalen Modelle verwendest im Anblick von Komplexität? Hast du effektive Wege entdeckt, Komplexität mit deinen Teams zu diskutieren — oder stehst du vor Herausforderungen, die sich einer Kategorisierung zu widersetzen scheinen? Du willst Komplexität nicht nur verstehen, sondern in deiner Organisation gezielt reduzieren? [So unterstützen wir dich](/leistungen/). _This post was originally published in English on [Medium.com](https://medium.com/miragon/navigating-complexity-from-confusion-to-clarity-through-clear-perspectives-ecb2860d175c)._ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fkomplexitaet-navigieren-perspektiven%2F)[](mailto:?subject=Komplexit%C3%A4t%20navigieren%3A%20Von%20Verwirrung%20zu%20Klarheit%20durch%20klare%20Perspektiven&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fkomplexitaet-navigieren-perspektiven%2F) ## Marco Schäck Process Development Lead bei Miragon [in Marco kennenlernen](https://www.linkedin.com/in/schaeckm/) [Mehr von Marco](/blog/?author=marco-schäck) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Leveling up! Wie du die Herausforderung verteilter Transaktionen in Zeebe lösen kannst](https://www.miragon.io/blog/leveling-up-verteilte-transaktionen-zeebe/) Softwareentwicklung Ein umfassender Guide zu verteilten Transaktionen in Zeebe: Von Phantom-Instanzen über das Outbox Pattern bis hin zu Idempotenz und SAGA. Marco Schäck Process Development Lead **01\. Dez. 2025**40 Min. Lesezeit Wer mit Zeebe arbeitet, taucht in die Welt verteilter Systeme ein. Eine Welt, die auch im Jahr 2025 für viele Teams noch Neuland ist. Verteilte Systeme bringen eine Reihe von Herausforderungen mit sich, die jedes Team verstehen muss. Eine der kritischsten — oft unterschätzt oder sogar ignoriert — ist **das Distributed Transaction Problem**. Dieses Problem tritt früher oder später auf — egal, was du baust. Es tritt auf, weil Zeebe per Design als externer Service läuft. Getrennt von deiner Anwendung. Mit einer eigenen Datenbank. Nur über das Netzwerk erreichbar. Diese architektonische Entscheidung bringt verschiedene Vorteile: Skalierbarkeit, ein cloud-native Deployment und Resilienz. Diese Entscheidung bedeutet aber auch — im Vergleich zu eingebetteten Engines wie dem Vorgänger Camunda 7 —, dass Operationen, die früher atomisch innerhalb eines einzelnen Systems abliefen, nun mehrere Systeme umfassen. Systeme ohne gemeinsame Transaktionsgrenze. Wenn also etwas schiefgeht, kann es zu Dateninkonsistenzen, fehlgeschlagenen Prozessen und Koordinationsfehlern kommen. Die gute Nachricht: Diese Herausforderung ist nicht Zeebe-spezifisch. Es ist ein bekanntes Problem in verteilten Systemen mit bewährten Lösungen. Dieser Artikel untersucht diese Patterns und zeigt dir, wie du sie effektiv anwenden kannst. Er geht dabei auf **After-Transaction Hooks** (einfach, aber begrenzt) und das **Outbox Pattern** (umfassend, aber komplex) ein. Außerdem etabliert er **Idempotenz** als eine fundamentale Systemeigenschaft, die du beim Bau verteilter Systeme berücksichtigen musst. Schließlich untersucht er **Zeebe-spezifische Tools** wie `messageIDs` und BPMN selbst, die sowohl Sendern als auch Empfängern helfen, Konsistenz zu gewährleisten. Auf dieser Grundlage wird der Überblick über Muster mit einem Blick auf das SAGA-Pattern abgeschlossen. Über Implementierungsmuster hinaus schlägt dieser Artikel vor, wie du die Herausforderungen systematisch angehen kannst: durch den Aufbau von Teambewusstsein in deiner Organisation, die Identifizierung kritischer Szenarien in deiner Codebasis und die Priorisierung von Lösungen basierend auf Business Impact. Denn die Lösung dieser Herausforderung ist nicht nur eine Frage der Implementierung von Patterns im Code — es geht auch darum, sicherzustellen, dass dein gesamtes Team die Herausforderung versteht. Egal, ob du ein Greenfield-Zeebe-Projekt startest, [von Camunda 7 migrierst](/portfolio/camunda-7-migration/) oder bereits mit mysteriösen Problemen zu kämpfen hast: Dieser Leitfaden hilft dir, diese Herausforderungen zu meistern - um die vollen Vorteile von Zeebe und deinem verteilten System zu nutzen. ## 📖 Kontext dieses Artikels Es gibt überraschend wenig Informationen über das Distributed Transaction Problem im Kontext von Remote-Process-Engines wie Zeebe. Daher ist dieser Artikel bewusst umfassend und detailliert. Er ist als Referenzwerk gedacht, das diese Lücke füllen soll. Ich plane jedoch auch in Zukunft, kürzere, fokussiertere Artikel zu spezifischen Aspekten aus diesem Post zu veröffentlichen. Der Artikel basiert auf einem Talk, den ich kürzlich bei einem Camunda University Chapter gehalten habe, und ergänzt ein GitHub Repository mit umfangreichen Beispielen des Problems sowie Lösungsmustern. ## 🎮 Wenn Produktion zusammenbricht: Ein Beispielszenario Stell dir vor: Du betreibst eine erfolgreiche Gaming-Newsletter-Plattform mit vielen Abonnenten, die wöchentliche Updates über ihre Lieblingsspiele erhalten. Dein Zeebe-basierter Subscription-Prozess läuft reibungslos. User abonnieren, erhalten Bestätigungsmails, bestätigen ihr Abonnement und erhalten eine Willkommensmail. Danach bekommen sie die periodischen Newsletter. Alles scheint gut zu laufen. Doch von Zeit zu Zeit häufen sich Support-Tickets: Mehrere User melden dasselbe Problem: “Ich habe mich angemeldet, aber keine Bestätigungsmail erhalten”. Eine Zeit lang stuft das Support-Team dies als User-Fehler ein. Aber irgendwann wird es zu viel, und du musst nachforschen. Dabei stößt du auf ein beunruhigendes Muster: Für keinen dieser Fälle existiert in der Datenbank ein Abonnement. Soweit, so seltsam. Aber dann wird es widersprüchlich: Du findest für jeden Fall eine Instanz in Operate. Eine Instanz mit einem Incident. Ein Incident, der immer dieselbe Fehlermeldung zeigt: `NoSuchElementException`. Der Task zum Senden der Bestätigungsmail kann das Abonnement nicht finden. Dir wird klar: Dies ist kein zufälliger Bug. Das ist systematisch. Etwas Grundlegendes ist kaputt. Also beginnst du zu debuggen. Dein Code sieht korrekt aus. Du speicherst ein Abonnement, sendest eine Message an Zeebe. Und all das wird in einer Operation gemacht, die eine Transaktion verwendet. Was läuft also schief? ``` @Service @Transactional class SubscribeToNewsletterService( private val subscriptionRepository: NewsletterSubscriptionRepository, private val zeebeClient: ZeebeClient ) { fun subscribe(email: String): SubscriptionId { // Save the subscription to the database val subscription = Subscription(email = email, status = PENDING) subscriptionRepository.save(subscription) // Start the process instance in Zeebe val variables = mapOf("subscriptionId" to subscription.id.toString()) zeebeClient.newPublishMessageCommand() .messageName("subscription-form-submitted") .withoutCorrelationKey() .variables(variables) .send() .join() return subscription.id } } ``` Irgendwann erkennst du: Da Zeebe als völlig separates System mit eigener Infrastruktur läuft, hat `@Transactional` darauf überhaupt keinen Einfluss. Es kontrolliert nur deine lokale Datenbanktransaktion. Wenn also die Transaktion fehlschlägt, nachdem die Message erfolgreich an Zeebe gesendet wurde, wird nur deine Datenbank zurückgerollt. Das Abonnement verschwindet. Aber der Prozess? Er läuft bereits und führt Tasks aus. Sucht nach Daten, die nicht existieren. Das ist **das Distributed Transaction Problem** — und diese Incidents sind seine Signatur in deinen Production-Logs. ## 🏛️ Den Wandel verstehen: Von Monolithisch zu Verteilt Um zu verstehen, warum dieses Problem wahrscheinlich viele Teams überrascht und warum es nur in verteilten Systemen existiert, müssen wir uns ansehen, wo die meisten Entwickler herkommen: **aus der monolithischen Einzelsystem-Welt.** Jahrelang war dies das dominierende Muster, wo alles zusammenlebte. Business-Logik, Datenbankinteraktionen und oft die Process-Engine selbst — alles innerhalb einer Anwendung, schreibend in eine Datenbank, geschützt durch eine Transaktion pro Operation. Betrachte unseren Newsletter-Service als Beispiel. REST-Endpoints, Datenbank-Adapter und die Engine selbst konnten in einer einzelnen Anwendung koexistieren. Die Engine läuft embedded als Bibliothek und teilt die Datenbank der Anwendung. Diese Vereinigung machte Operationen sowohl einfach als auch sicher: ``` @Service @Transactional class SubscribeToNewsletterService( private val subscriptionRepository: NewsletterSubscriptionRepository, private val runtimeService: RuntimeService // Embedded engine ) { fun subscribe(email: String): SubscriptionId { val subscription = Subscription(email = email, status = PENDING) subscriptionRepository.save(subscription) val variables = mapOf("subscriptionId" to subscription.id.toString()) runtimeService.startProcessInstanceByKey( "newsletter-subscription", subscription.id.toString(), variables ) return subscription.id // Transaction commits here - atomically! } } ``` Der obige Service war beispielsweise sicher, weil alle Operationen darin in dieselbe Datenbank schrieben - unter Verwendung derselben Transaktion. Und dieselbe Transaktion bedeutete dasselbe Schicksal. Wenn irgendetwas fehlschlug, wurde die gesamte Datenbankoperation automatisch zurückgerollt. Entweder wurden das Abonnement und die Instanz gespeichert - oder keines von beiden: All dies war durch die **ACID**\-Prinzipien geschützt. Sie machten Konsistenz unkompliziert — und damit auch die Arbeit mit Engines einfacher. **ACID** steht für: - **Atomicity**: Entweder gelingt alles oder alles schlägt fehl - **Consistency**: Nur gültige Zustände, keine halbfertigen Operationen - **Isolation**: Andere Transaktionen sehen nur vollständige Ergebnisse - **Durability**: Einmal committed, dauerhaft persistent ### 🧱 Einschränkungen von ACID Aber machen wir uns nichts vor: Selbst in dieser monolithischen Welt konnte ACID dich nicht überall schützen. In dem Moment, in dem du mit externen Systemen interagiert hast — wie Email-Services, Message Brokern oder REST-APIs —, warst du nicht mehr durch ACID geschützt. Deine Transaktion konnte nicht über Netzwerkgrenzen hinweg reichen. Das bedeutet, dass die gleichen Probleme auch damals existierten. Allerdings war es weniger sichtbar, weil die meisten Operationen innerhalb deines Systems blieben. Das Problem tauchte nur auf, wenn du absichtlich mit externen Services integriert hast. Und was im Kontext unserer Perspektive am relevantesten ist: Die Process-Engine selbst war nicht Teil des Problems. Diese relative Sicherheit war möglich, weil Embedding eine Option war. ## 🌐 Die Verteilte Realität: Bei der Verwendung von Remote-Engines Mit Remote-Engines wie Zeebe ändert sich dies. Die Engine selbst wird zu einem externen System, mit dem du koordinierst — per Design. Und dieser Wandel ist fundamental. Was einst ein gelegentliches Problem war — wenn du absichtlich mit externen Services integriert hast — gilt jetzt für jede einzelne Interaktion mit deiner Process-Engine. Denk daran: Embedding war dein Sicherheitsnetz. Mit Zeebe existiert diese Option nicht mehr. Die Architektur besteht nun aus drei separaten Teilen: deiner Anwendung mit ihrer Datenbank, Zeebe mit seiner eigenen Infrastruktur und Netzwerkkommunikation zwischen ihnen. Das bedeutet, dass die meisten Operationen zwei unabhängige Systeme mit zwei unabhängigen Transaktionen betreffen. Aber was das besonders trügerisch macht: Dein Code sieht fast identisch aus. ``` @Service @Transactional class SubscribeToNewsletterService( private val subscriptionRepository: NewsletterSubscriptionRepository, private val zeebeClient: ZeebeClient ) { fun subscribe(email: String): SubscriptionId { // Save the subscription to the database val subscription = Subscription(email = email, status = PENDING) subscriptionRepository.save(subscription) // Start the process instance in Zeebe val variables = mapOf("subscriptionId" to subscription.id.toString()) zeebeClient.newPublishMessageCommand() .messageName("subscription-form-submitted") .withoutCorrelationKey() .variables(variables) .send() .join() return subscription.id // Transaction commits here - but only for the database! } } ``` Jedoch hat sich unter der Oberfläche alles geändert. Das liegt daran, dass die Transaktion deine Engine nicht mehr kontrolliert - sondern nur noch die Datenbank deiner Domain. Die wirkliche Auswirkung erkennst du, wenn du dir ein Sequenzdiagramm anschaust — aber nicht eines mit erfolgreichem Ausgang. Im Happy-Path würdest du nur sehen, dass Datenbankoperationen zu gRPC-Calls über das Netzwerk werden. Das Problem wird nur sichtbar, wenn Dinge fehlschlagen. Und das würde so aussehen: Der Service fügt das Abonnement in die Datenbank ein und sendet die Message an Zeebe. Zeebe bestätigt den Empfang der Message und startet den Prozess sofort. Aber dann — vielleicht aufgrund eines Connection-Timeouts — schlägt der Commit fehl. Die Datenbank rollt zurück, wodurch das Abonnement verschwindet. Zeebe weiß jedoch nichts von diesem Fehler. Es hat die Message empfangen und begonnen zu arbeiten — sucht nun nach Daten, die nicht mehr existieren. Das ist die Exception, die in unserem Beispielszenario auftritt. Und sie erscheint, weil wir die vorherigen ACID-Garantien nicht mehr haben. Stattdessen — mit verteilter Architektur — operieren wir unter einem anderen Paradigma namens **BASE**. Es bedeutet: - **Basically Available**: Das System bleibt verfügbar, auch wenn Teile nicht sofort perfekt synchronisiert sind. - **Soft State**: Der Zustand entwickelt sich über die Zeit durch Synchronisation zwischen Systemen. - **Eventual Consistency**: Alle Systeme werden schließlich konsistent — nur nicht sofort. Aber verinnerliche das: Dies ist keine Einschränkung — es ist ein Trade-off. Wir haben unmittelbare Konsistenz innerhalb eines Systems gegen unabhängige, resiliente Systeme getauscht, die unabhängig skalieren und ausfallen können. Mit ACID waren Operationen atomisch, aber eng gekoppelt. Mit BASE sind Operationen entkoppelt, aber letztendlich konsistent. Lass das kurz sacken. Deine Datenbanktransaktion kann erfolgreich sein. Dein Prozess kann starten. Dennoch ist dein System vorübergehend inkonsistent. Das ist die verteilte Realität — und sie erfordert andere Patterns, um Konsistenz über Systeme hinweg aufrechtzuerhalten. ### 🪜 _Eine Anmerkung zu eingebetteten Engines wie Camunda 7_ > _All diese Herausforderungen können auch bei Camunda 7 auftreten. C7 konnte embedded im selben Service wie deine Business-Logik laufen, oder es konnte in einem separaten Service laufen, der mit deinem Domain-Service über das Netzwerk interagiert. Der Unterschied ist: Embedding war eine Option bei C7. Mit Zeebe ist es das nicht. Wir nutzen C7 zur Einordnung — um zu zeigen, wie Systeme früher aussahen —, besonders weil viele Teams aufgrund des End-of-Life von C7 gerade migrieren. Also ist kein Ansatz besser oder schlechter._ ## ❌ Die Universelle Herausforderung von Distributed Transactions Diese verteilte Realität — wo Systeme vorübergehend inkonsistent sein können — hat einen Namen: **das Distributed Transaction Problem**. Es ist nicht nur eine Zeebe-Herausforderung. Es ist eine grundlegende Eigenschaft jeder Architektur, bei der Operationen mehrere unabhängige Systeme umfassen. ### Was es ist und warum es existiert Die Kernherausforderung ist einfach erklärt: **Wenn eine Operation mehrere unabhängige Systeme umfasst, kannst du nicht garantieren, dass alle Systeme zusammen erfolgreich sind oder zusammen fehlschlagen.** Das öffnet die Tür zur Inkonsistenz. In einer einzelnen Datenbank mit ACID fungiert die Datenbank als Transaction-Coordinator. Sie sperrt Ressourcen, koordiniert Commits und rollt alles zurück, wenn Fehler auftreten. Sobald du Systemgrenzen überschreitest, existiert kein solcher Coordinator mehr. Jedes System verwaltet seinen Zustand unabhängig und trifft eigene Commit- oder Rollback-Entscheidungen — ohne Mechanismus, alle abzugleichen. Das Ergebnis: Partieller Erfolg wird möglich. Ein System committet erfolgreich, während ein anderes fehlschlägt und zurückrollt. Wenn das passiert, sind deine Daten inkonsistent - ohne automatischen Weg zur Behebung. Die Gründe für solche Fehler sind zahlreich: Netzwerk-Timeouts, Verfügbarkeitsprobleme und mehr. Sie sind ein normaler Bestandteil verteilter Systeme, der — wenn auch selten — von Zeit zu Zeit auftritt. Vollständig verhindern kannst du sie nie. ### Wo dieses Problem auftritt Kurz zusammengefasst: Die Herausforderung tritt auf, sobald Operationen über unabhängige Systeme hinweg koordinieren müssen — nicht nur bei Zeebe. Im Allgemeinen kann es auftreten, wenn du mit Folgendem arbeitest: - **Microservices & External APIs**: Ein User möchte sich abmelden. Du aktualisierst seinen Status in deiner Datenbank und rufst die API von SendGrid auf, um eine Bestätigungsmail zu senden. SendGrid bestätigt, dass die Mail gesendet wurde, aber dann schlägt dein Datenbank-Commit fehl. Das Ergebnis: Der User hat eine Bestätigungsmail erhalten, bleibt aber in deinem System abonniert und wird weiterhin Nachrichten erhalten. - **Event-driven Systems & Message Queues**: Ein Autor erstellt eine neue Edition seines Newsletters in deinem Content-System. Das Content-System sendet es an dein Publishing-System über Kafka. Das Publishing-System versucht, es in seine Datenbank einzufügen — schlägt aber fehl. Die Folge: Dein Publishing-System hat vorübergehend oder dauerhaft einen anderen Zustand als dein Content-System. ### Die Konsequenzen Jede Systemgrenze wird zum Risikopunkt. Wenn das Distributed Transaction Problem dort zuschlägt und du keine geeigneten Patterns verwendest, zeigt es sich auf destruktive Weise: - **Dateninkonsistenzen**: Verschiedene Systeme - wie dein Content- & Publishing-System - haben widersprüchliche Sichten auf die Realität. - **Verlorene oder unterbrochene Operationen**: Als Folge solcher Inkonsistenzen kann Arbeit, die ausgeführt werden soll - wie das Veröffentlichen einer neuen Newsletter-Version - niemals oder nur teilweise ausgeführt werden. - **Doppelte Operationen**: Das Gegenteil. Retries, die Fehler behandeln sollten, erzeugen stattdessen Duplikate. Zum Beispiel sendet das System mehrere Bestätigungsmails an einen Abonnenten. - **Manuelle Intervention**: Ohne automatische Wiederherstellung brauchen viele Probleme menschliche Intervention. Support-Teams gleichen Daten manuell ab oder starten Prozesse neu. Entwickler untersuchen und beheben korrupte Zustände. Das skaliert nicht. Das sind keine Kleinigkeiten. Sie wirken sich direkt auf Geschäftsoperationen, Kundenvertrauen und Systemzuverlässigkeit aus. ## 🔮 Das Problem im Kontext von Zeebe Lass uns nun alles zusammenbringen. Wenn du Zeebe adoptierst, baust du ein verteiltes System. Eines, bei dem deine Anwendung und Zeebe über das Netzwerk koordinieren. Jedes hat seine eigene Datenbank. Jedes trifft unabhängige Commit-Entscheidungen. Anders als bei eingebetteten Engines — wo die Engine deine Transaktionsgrenze teilen konnte — ist dieses Sicherheitsnetz mit Zeebe weg. Das bedeutet, dass das Distributed Transaction Problem jede Interaktion mit deiner Engine betrifft: jede Message, die du sendest, jeden Job, den deine Worker verarbeiten. Die spezifischen Herausforderungen, auf die du triffst, hängen von deinen Koordinationsmustern, Error-Handling-Strategien, Netzwerkzuverlässigkeit, Systemlast und Transaktionskonfiguration ab. Aber bestimmte Fehlerszenarien tauchen wiederholt über Implementierungen und Umgebungen hinweg auf. Diese Fehler clustern sich um zwei kritische Momente: wenn deine Anwendung Messages an Zeebe sendet und wenn Worker abgeschlossene Jobs bestätigen. Das Verstehen dieser Manifestationen hilft dir, sie zu erkennen, effektive Abwehrmaßnahmen zu entwerfen und geeignete Lösungen zu wählen: ### Herausforderungen beim Senden von Messages an Zeebe **1\. Phantom-Instanzen: Prozess läuft ohne Daten** Dies ist das Szenario, das wir bereits mehrfach erwähnt haben. Deine Anwendung sendet eine Message an Zeebe, bevor die Datenbanktransaktion committed. Der Prozess startet sofort. Aber dann schlägt deine Transaktion fehl und rollt zurück. Das Ergebnis: Zeebe hat eine laufende Prozessinstanz, aber die Business-Daten, die sie benötigt, existieren nicht. Worker, die versuchen, das Abonnement abzurufen, bekommen eine Exception. **2\. Vorzeitige Ausführung: Lesen von Uncommitted Data** Es gibt jedoch auch andere Varianten dieses Szenarios. Selbst wenn dein Commit schließlich erfolgreich ist, könnte die Engine der erste Task ausführen, bevor der Commit abgeschlossen wurde. Dies stellt ein Timing-Problem dar, weil es zum gleichen Szenario wie oben führen kann: Der Worker kann noch nicht auf die Daten zugreifen, die er benötigt. Aber es könnte auch schlimmer sein - was zu einem dritten Problem führt. **3\. Vorzeitige Ausführung: Überschreiben von Daten** Dieses Szenario tritt auf, wenn wir Änderungen von einer Folge-Task ausführen und committen, bevor der vorherige Task abgeschlossen ist. Es ist besonders problematisch, wenn beide Tasks dieselben Daten aktualisieren. In solchen Fällen können wir den Zustand korrumpieren. Dies führt nicht nur zu Inkonsistenz, sondern auch zu Race Conditions, die manuelle Auflösung erfordern. ### Herausforderungen beim Bestätigen von Jobs Das Koordinationsproblem betrifft nicht nur das Senden von Messages an Zeebe — es wirkt sich auch darauf aus, wie Worker ihre Jobs abschließen. Betrachte dieses Szenario: Ein Worker verarbeitet erfolgreich einen Job und committet Änderungen in deine Datenbank. Alles sieht gut aus. Aber wenn der Worker versucht, die Completion an die Engine zu bestätigen, tritt ein Fehler auf. Jetzt stehst du vor zwei unterschiedlichen Ergebnissen, abhängig davon, _warum_ die Bestätigung fehlgeschlagen ist: **1\. Temporäre Fehler — aufgrund von Connectivity-Problemen** Diese Fehler können aus vielen Gründen auftreten, wie Netzwerkproblemen. Zu diesem Zeitpunkt ist der Job aus Zeebes Perspektive noch aktiv. Das bedeutet, Zeebe wird den Job nach einem Timeout wiederholen. Obwohl problematisch, ist dieses Szenario mit Idempotency-Patterns (die wir später behandeln werden) handhabbar. **2\. Permanente Fehler — aufgrund von Job-Cancellation** Diese Fehler sind viel schwieriger zu handhaben. Sie treten auf, wenn der Job abgebrochen wird — zum Beispiel durch ein Boundary Event, das während der Verarbeitung durch deinen Worker ausgelöst wurde. Aus Zeebes Perspektive ist der Job nicht mehr aktiv. Zudem weiß Zeebe nicht, dass er auf der Domain-Seite erfolgreich ausgeführt wurde. Dies erzeugt eine permanente Inkonsistenz, die schwer zu erkennen ist und wahrscheinlich manuelle Intervention zur Auflösung erfordert. ### Die Kombinierte Realität Diese Szenarien sind keine theoretischen Edge Cases, die du ignorieren kannst. Sie passieren regelmäßig — auch wenn die hohe Zuverlässigkeit moderner Infrastruktur sie relativ selten macht. Was sie besonders herausfordernd macht, ist, dass sie nicht isoliert auftreten. Sie können sich kombinieren, was sie noch schwerer zu erkennen und zu beheben macht. Die Koordinationsmuster, die wir im nächsten Abschnitt untersuchen, adressieren sie systematisch. Anstatt jedes Fehlermodus separat zu behandeln, bieten diese Patterns ein kohärentes Framework zur Aufrechterhaltung der Konsistenz über dein verteiltes System hinweg. Für einen umfassenden Deep-Dive in alle Szenarien mit detaillierten Sequenzdiagrammen, Code-Beispielen und Schritt-für-Schritt-Analyse, schau dir das [distributed-horcruxes Repository](https://github.com/emaarco/distributed-horcruxes) an. ## 🛠 Lösungsmuster: Dein Distributed-Transaction-Toolkit Wo wir stehen: Wir koordinieren zwischen zwei autonomen Systemen — Zeebe und unserem Service — jedes mit eigener Datenbank und ohne gemeinsame Transaktionsgrenze. Fehler in einem der Systeme können unsere Daten inkonsistent lassen. Die gute Nachricht? Weil Distributed Transactions eine allgemeine Herausforderung sind, gibt es bewährte Patterns. Die schlechte Nachricht? Es gibt keine Patentlösung. Jede Lösung hat Trade-offs, und die Wahl der richtigen hängt von deinen Anforderungen ab. Wir schauen uns dein Toolkit in drei Blöcken an: Basis-Patterns, die das Koordinationsproblem direkt angehen, Idempotenz als Sicherheitsnetz für doppelte Operationen und Zeebe-spezifische Features, die dir helfen, diese Patterns effektiver umzusetzen. ## 🎻 Block 1: Basis-Orchestrierungspatterns Diese Patterns zeigen, wie Operationen über Systemgrenzen hinweg koordiniert werden, während Konsistenz erhalten bleibt. ### Das Retry Pattern: Intuitiv, aber meist falsch Wenn Operationen fehlschlagen, lautet der erste Instinkt meist: “einfach wiederholen!” Es ist ein gängiges Pattern in verteilten Systemen - einfach zu implementieren und in vielen Fällen funktioniert es gut. Wenn du beispielsweise das Spring Framework und seine [Retry-Library](https://www.baeldung.com/spring-retry) verwendest, musst du nur ein `@Retryable` zu einer Methode hinzufügen. Sonst nichts. Bei einem Fehler wird die Methode erneut ausgeführt, bis ein Limit erreicht ist. ``` @Service @Transactional class SubscribeToNewsletterService( private val subscriptionRepository: NewsletterSubscriptionRepository, private val zeebeClient: ZeebeClient ) { @Retryable(maxAttempts = 3) fun subscribe(email: String): SubscriptionId { // logic to create a subscription & start the process } } ``` Im Kontext des Sendens von Messages an eine Process-Engine wie Zeebe ist dieser Ansatz jedoch meist falsch. Um zu verstehen warum, lass uns darüber nachdenken, was passiert, wenn ein Call fehlschlägt. Wenn in diesem Fall die gesamte Operation erneut durchgeführt wird und nach einigen Retries erfolgreich ist, haben wir mehrere Prozessinstanzen in der Engine, aber nur ein Abonnement in der Datenbank. Dies ist eine ungelöste Inkonsistenz, die höchstwahrscheinlich Probleme verursacht. **Die Lehre daraus**: Retries sind ein sehr mächtiges Tool in verteilten Systemen. Aber beim Lösen von Orchestrierungsproblemen schafft die alleinige Verwendung von Retries typischerweise mehr Probleme, als sie löst. Retries funktionieren am besten, wenn Operationen idempotent sind — aber das behandeln wir später. Vorerst halten wir fest, dass wir eine Lösung brauchen, die garantiert, dass eine Message nur nach einem erfolgreichen Commit an Zeebe gesendet wird. Und genau das bietet das nächste Pattern. ### After-Transaction Pattern: Einfach, aber begrenzt Die Idee ist elegant: Anstatt es direkt aufzurufen, registrierst du den Call zu Zeebe als Callback, der nach erfolgreichem Commit ausgeführt wird. Für solche Szenarien bietet beispielsweise das SpringBoot Framework sogenannte `TransactionSynchronization` Hooks. Eine Implementierung, die solche Hooks verwendet, zentriert sich um zwei Komponenten. Erstens den Hook selbst, der den Call zu Zeebe implementiert - und falls nützlich, auch einige Pre-Commit-Checks, um die Sicherheit zu erhöhen, dass der Call erfolgreich sein wird: ``` class ProcessEngineCallSynchronization( private val camundaClient: CamundaClient, private val processEngineCall: (): Unit ) : TransactionSynchronization { private val log = KotlinLogging.logger {} override fun afterCommit() = try { processEngineCall() } catch (e: Exception) { log.error(e) { "Failed to execute process engine call" } throw e } override fun beforeCommit(readOnly: Boolean) { val topology = camundaClient.newTopologyRequest().send().join() val healthy = checkBrokerHealth(topology) if (!healthy) { throw IllegalStateException("No healthy broker found") } } } ``` Und zweitens, ein Synchronizer, der diese Callbacks beim Transaction-Manager von Spring registriert. Er sucht nach einer laufenden Transaktion und fügt die Synchronisation zu ihrem Lifecycle hinzu: ``` class ProcessEngineSynchronizer(private val camundaClient: CamundaClient) { fun executeAfterCommit( processEngineCall: () -> Unit ) = TransactionSynchronizationManager.registerSynchronization( ProcessEngineCallSynchronization(camundaClient, processEngineCall) ) } ``` Mit diesen Komponenten bleibt dein Service-Code sauber und aussagekräftig. Er verwendet einfach den Synchronizer und seine `executeAfterCommit`\-Methode, um den Engine-Call zu registrieren und auszuführen. ``` @Service @Transactional class SubscribeToNewsletterService( private val subscriptionRepository: NewsletterSubscriptionRepository, private val engineSynchronizer: ProcessEngineSynchronizer, private val zeebeClient: ZeebeClient ) { fun subscribe(email: String): SubscriptionId { // Save to database within transaction val subscription = Subscription(email = email) val savedSubscription = subscriptionRepository.save(subscription) // Register Zeebe call to happen AFTER commit engineSynchronizer.executeAfterCommit { zeebeClient.newPublishMessageCommand() .messageName("subscription-created") .variables(mapOf("subscriptionId" to savedSubscription.id)) .send() .join() } return savedSubscription.id // Database commits first, then Zeebe call executes } } ``` Der Ausführungsfluss zeigt den entscheidenden Unterschied: Zeebe wird erst benachrichtigt, nachdem die Datenbank erfolgreich committed hat. Das Phantom-Instanz-Problem ist gelöst — Worker finden immer ihre Daten, weil garantiert ist, dass sie existieren, wenn die Message ankommt. **Vorteile** Das After-Transaction Pattern bietet mehrere Vorteile. Deine Datenbank bleibt konsistent. Das Pattern ist einfach zu verstehen sowie zu implementieren. Und du kannst sogar einen optionalen Health-Check vor dem Commit hinzufügen, um deine Erfolgsrate zu erhöhen. **Nachteile** Aber es gibt eine kritische Schwäche: Du hast das Problem gerade auf die andere Seite verschoben. Anstatt also Prozesse ohne Daten zu riskieren, riskierst du jetzt verwaiste Daten — das bedeutet Abonnements ohne Prozesse. Das liegt daran, dass wenn der Zeebe-Call nach dem Commit fehlschlägt, die Message verloren geht. Da es keinen persistenten Storage gibt, ist manuelle Intervention nötig, um dieses Problem zu lösen. **Fazit** After-Transaction funktioniert gut für nicht-kritische Szenarien und Proof-of-Concepts. Für Systeme, die garantierte Zustellung mit einem Minimum an manueller Intervention erfordern, brauchst du Persistenz. Und genau das bietet das dritte Pattern. ### Outbox Pattern: Die umfassende Lösung Das Outbox Pattern verfolgt einen überraschend einfachen Ansatz für dieses komplexe Problem: Es besagt, dass wenn du nicht zuverlässig über zwei Systeme hinweg koordinieren kannst, solltest du es zu einem Problem in einem System machen. Daher schreibt es sowohl deine Business-Daten _als auch_ die Message in deine Datenbank in einer atomaren Transaktion. Es gibt keinen sofortigen Call zu Zeebe — nur zwei Datenbank-Writes. Ein Hintergrundprozess liest später diese Messages und sendet sie an Zeebe. Dies stellt ACID-Garantien wieder her: 👉🏽 Entweder werden sowohl das Abonnement als auch die Message zusammen gespeichert, oder keines überlebt einen Fehler. Das Pattern teilt die Koordinationsherausforderung in zwei unabhängige Belange: atomare Datenbank-Writes und zuverlässige Message-Zustellung. Es verwandelt ein komplexes verteiltes Problem in zwei einfachere, handhabbare Teile. **Belang 1: Atomarer Write in Datenbank und Outbox** Deine Anwendung schreibt sowohl die Business-Daten als auch den Message-Record in die Datenbank in einer einzelnen Transaktion — entweder werden beide gespeichert, oder keines überlebt einen Fehler. Dazu benötigt es eine zusätzliche Tabelle in deiner Datenbank. Die Outbox-Tabelle. Deine anderen Tabellen bleiben unberührt. Die Outbox fungiert als Staging-Area für Messages, die wir an Zeebe senden müssen. ``` -- Your existing business table -- newsletter_subscriptions (id, email, status, created_at) -- Add this new outbox table CREATE TABLE process_messages ( id UUID PRIMARY KEY, message_name VARCHAR(255) NOT NULL, correlation_id VARCHAR(255), variables JSONB NOT NULL, status VARCHAR(50) NOT NULL, -- PENDING or SENT retry_count INT DEFAULT 0, created_at TIMESTAMP NOT NULL, updated_at TIMESTAMP NOT NULL ); ``` Sobald die Tabelle vorhanden ist, muss dein Business-Service die Messages für Zeebe einfach zusätzlich in der Datenbank speichern. Noch keine Netzwerk-Calls zu Zeebe, also bleibt die Transaktion schnell: ``` @Service @Transactional class SubscribeToNewsletterService( private val subscriptionRepository: NewsletterSubscriptionRepository, private val outboxRepository: ProcessMessageRepository ) { fun subscribe(email: String): SubscriptionId { val subscription = subscriptionRepository.save( Subscription(email = email, status = PENDING) ) val message = ProcessMessage( messageName = "subscription-created", correlationId = subscription.id.toString(), variables = mapOf("subscriptionId" to subscription.id), status = MessageStatus.PENDING ) outboxRepository.save(message) return subscription.id // Both saved atomically } } ``` **Belang 2: Background Polling und Sending** Stattdessen übernimmt ein separater Scheduler die Kommunikation mit Zeebe. Er pollt kontinuierlich die Outbox-Tabelle nach pending Messages. Wenn er eine findet, sendet er die Message an die Engine: ``` @Component class ProcessEngineOutboxScheduler( private val camundaClient: CamundaClient, private val transactionManager: PlatformTransactionManager, private val repository: ProcessMessageJpaRepository, ) { private val log = KotlinLogging.logger {} private val objectMapper = ObjectMapper() @Scheduled(fixedDelay = 200) fun sendMessages() { log.debug { "Running scheduler to send messages to zeebe" } var messagesProcessed = 0 while (processNextMessage()) messagesProcessed++ log.debug { "Scheduler finished sending messages to zeebe" } } private fun processNextMessage() = performInTransaction { val message = repository.findFirstByStatusWithLock(MessageStatus.PENDING) if (message == null) { false } else { trySendMessage(message) true } } private fun trySendMessage(message: ProcessMessageEntity) { try { sendMessage(message) val sentMessage = message.copy(status = MessageStatus.SENT) repository.save(sentMessage) log.info { "Successfully sent message ${message.messageName}" } } catch (e: Exception) { val retryCount = message.retryCount + 1 val retryMessage = message.copy(retryCount = retryCount) repository.save(retryMessage) log.warn(e) { "Retrying to send message ${message.messageName}" } } } private fun sendMessage(message: ProcessMessageEntity) { val variables = objectMapper.readValue( message.variables, object : TypeReference>() {} ) val messageId = "${message.correlationId}-${message.messageName}" log.info { "Sending message ${message.messageName}" } camundaClient.newPublishMessageCommand() .messageName(message.messageName) .correlationKey(message.correlationId) .messageId(messageId) .variables(variables) .timeToLive(Duration.of(10, ChronoUnit.SECONDS)) .send() .join() } } ``` Der Scheduler kann beispielsweise alle 200ms laufen. Dabei verwendet er Datenbank-Locks (`SELECT FOR UPDATE SKIP LOCKED`), um Race Conditions zu verhindern — dadurch können mehrere Scheduler-Instanzen parallel laufen. Wenn eine Message erfolgreich gesendet wurde, wird sie als SENT markiert. Wenn das Senden fehlschlägt, wird der Retry-Counter erhöht und die Message bleibt PENDING für den nächsten Polling-Zyklus. Wie schon bei den anderen Patterns lässt sich dieser Fluss in einem Sequenzdiagramm darstellen: **Vorteile** Das Outbox Pattern garantiert eventuelle Message-Zustellung — wenn Zeebe down ist oder die Anfrage fehlschlägt, persistiert die Message in der Datenbank und wird wiederholt. Dies löst alle Timing- und Zuverlässigkeitsprobleme. Der atomare Storage sorgt für einen Alles-oder-Nichts-Ansatz: Entweder werden sowohl die Business-Daten als auch die Message gespeichert, oder keines überlebt. Diese Separation of Concerns trennt Datenbankoperationen sauber von Process-Engine-Interaktionen. Zusätzlich erhältst du einen Audit-Trail, da SENT Messages in der Datenbank bleiben, und eingebaute Retries behandeln Fehler automatisch. **Nachteile** Aber wie immer gibt es Trade-offs. Das Pattern führt zusätzliche Komplexität ein. Du musst die Outbox-Tabelle, den Scheduler implementieren und zusätzliche Infrastruktur handhaben. Daneben wirst du leichte Verzögerungen durch das Polling-Intervall erleben — typischerweise 100-200ms. Weiterhin brauchst du eine Message-Processing-Strategie. Dies könnte sicheres sequentielles Processing oder schnelleres paralleles Processing mit Ordering-Überlegungen sein. Messages könnten auch mehrfach gesendet werden, also sind Mechanismen wie Dead Letter Queues essentiell. Schließlich wird bei wachsender Datenbank eine Cleanup-Strategie für alte Messages notwendig. **Fazit** Auch wenn die Nachteile beträchtlich erscheinen, ist das Outbox Pattern für kritische Business-Prozesse, bei denen garantierte Zustellung essenziell ist, die Investition wert — und meist alternativlos. Für weniger kritische Szenarien kann After-Transaction ausreichen — sollte aber dennoch mit Vorsicht verwendet werden. Die Komplexität, die du heute akzeptierst, baut die Zuverlässigkeit auf, auf die du morgen angewiesen bist. ### Warum die Implementierung von Orchestrierungspatterns nicht ausreicht Selbst mit dem Outbox Pattern hast du das Distributed Transaction Problem nicht als Ganzes gelöst. Es gibt noch eine fundamentale Herausforderung zu adressieren. Betrachte, was passiert, wenn der Scheduler im falschen Moment fehlschlägt: Er liest eine Message aus der Outbox, sendet sie an Zeebe, crasht aber bevor er sie als SENT markiert. Wenn der Service neu startet, zeigt diese Message immer noch PENDING. Der Scheduler holt sie ein zweites Mal ab und sendet sie an Zeebe — erneut. Zeebe empfängt dieselbe Message zweimal. Dies ist **At-Least-Once-Delivery** — eine Charakteristik verteilter Systeme, wo du garantieren kannst, dass eine Message ankommt, aber nicht, dass sie genau einmal ankommt. Dies ist nicht spezifisch für das Outbox Pattern. Viele Tools funktionieren so, einschließlich Message Brokern wie Kafka. Also wie gehst du mit Duplikaten um, wenn sie unvermeidlich ankommen? ## 🎨 Block 2: Idempotenz als Design-Pattern Die Lösung für dieses Problem heißt **Idempotenz**. Es ist ein Design-Prinzip, das häufig in verteilten Systemen verwendet wird. Es stellt sicher, dass die mehrfache Ausführung derselben Operation dasselbe Ergebnis erzeugt wie die einmalige Ausführung. Ohne Idempotenz werden doppelte Messages gefährlich. Ein Abonnent könnte mehrere Willkommensmails erhalten, oder schlimmer — wenn dein Newsletter gebührenpflichtig ist, mehrfach belastet werden. Mit Idempotenz werden Duplikate harmlos. Um es mit einem Beispiel aus der physischen Welt zu veranschaulichen: Denke daran, wie du einen Fahrstuhlknopf drückst: Ob du ihn einmal oder zehnmal drückst, der Fahrstuhl kommt genau einmal zu deiner Etage. Daher verschiebt sich die Herausforderung davon, alle Duplikate zu verhindern, was in verteilten Systemen unmöglich ist, dazu, sie sicher zu handhaben. Und dies ist durch Design erreichbar. ### Nicht-Idempotente Operationen Bevor wir Idempotenz-Patterns untersuchen, lass uns verstehen, was eine Operation nicht-idempotent macht. Es ist das Gegenteil unserer früheren Definition: eine Operation, bei der wiederholte Ausführung jedes Mal unterschiedliche Ergebnisse erzeugt. Dies gilt besonders für Operationen, bei denen sich der neue Zustand dynamisch aus dem aktuellen Zustand berechnet — wie das Inkrementieren von Zählern oder das Anpassen von Salden. Stell dir zum Beispiel vor, dass jedes Mal, wenn ein User einen Newsletter abonniert, wir ein Signal veröffentlichen. Ein Worker fängt dieses Signal ab und verwaltet einen Subscription-Counter: ``` fun incrementSubscriberCount(newsletterId: UUID) { val newsletter = repository.findById(newsletterId) newsletter.subscriberCount++ // Non-idempotent! repository.save(newsletter) } ``` Wenn diese Operation aufgrund eines Fehlers beim Bestätigen des Jobs zweimal läuft, erhöht sich der Counter um zwei statt um eins — was deine analytischen Daten korrumpiert. Jede Ausführung ändert den Zustand auf Weisen, die sich zusammensetzen. Deshalb brauchen wir explizite Idempotenz-Patterns. ### Wie man Idempotenz erreicht Operationen idempotent zu machen funktioniert nicht nach dem Motto “eine Lösung für alle Fälle”. Der richtige Ansatz hängt immer von den Eigenschaften deiner Operation ab. Daher gibt es mehrere Ansätze, wie man dies erreichen kann: **Ansatz 1: Natürliche Idempotenz** Einige Operationen sind natürlich idempotent — oder können so umgestaltet werden. Zum Beispiel erzeugt das Setzen eines Subscription-Status auf `CANCELLED` immer dasselbe Ergebnis, unabhängig vom vorherigen Zustand. Führe es einmal oder zehnmal aus — das Ergebnis bleibt identisch. ``` fun cancelSubscription(subscriptionId: UUID, status: SubscriptionStatus) { val subscription = repository.findById(subscriptionId) subscription.status = CANCELLED repository.save(subscription) } ``` Dies funktioniert perfekt für reine State-Updates ohne Seiteneffekte — keine Mails, keine externen Service-Calls, keine Events. Aber sobald du Seiteneffekte hinzufügst, bricht natürliche Idempotenz zusammen. Du wirst zwei Mails statt einer senden. Und da die meisten Operationen solche Seiteneffekte haben, hat dieser Ansatz begrenzten Nutzen, was uns zum zweiten Ansatz führt. **Ansatz 2: Die Domain als Idempotenz-Guard verwenden** Die Idee dieses Patterns ist, deine Domain-Objekte zu verwenden, um Idempotenz zu erreichen. Eine Lösung, die unter diese Kategorie fällt, wäre, ein Flag wie `confirmationEmailSent` zum Abonnement zu schreiben, um zu tracken, ob die entsprechende Operation bereits ausgeführt wurde. ``` data class Subscription( val id: UUID = UUID.randomUUID(), val email: EMail, val status: SubscriptionStatus, val confirmationEmailSent: Boolean = false // Idempotency flag ) ``` Jedes Mal, wenn der Worker den Task ausführt — egal ob beim ersten Versuch oder bei einem Retry —, können wir dieses Flag prüfen. Wenn es Completion anzeigt, können wir die Operation überspringen: Wie beim ersten Ansatz ist auch dies unkompliziert. Aber wie bei jedem vorherigen Pattern gibt es auch Nachteile. Jede Operation, die Idempotenz benötigt, braucht ihr eigenes Flag, was dein Domain-Modell mit technischen Belangen statt Business-Logik aufbläht. Dies schwächt das Domain-Design, erzeugt Wartungsaufwand und skaliert nicht. **Ansatz 3: Processed Operations Log** Um dieses Problem zu lösen, kann das dritte Pattern helfen: **das Führen eines Logs verarbeiteter Jobs**. Es folgt derselben Philosophie wie das Outbox Pattern. Anstatt das Domain-Modell mit technischen Flags zu überladen, lagert es die Verantwortung für das Erreichen von Idempotenz aus. Daher weist es jeder Operation eine eindeutige `operationId` zu und pflegt eine separate Tabelle, die trackt, welche Operationen bereits ausgeführt wurden. ``` // Separate table for tracking processed operations CREATE TABLE processed_operations ( operation_id VARCHAR(255) PRIMARY KEY, processed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); ``` Bevor irgendeine Operation verarbeitet wird, prüft das System, ob ihre Operation-ID in dieser Tabelle existiert. Wenn ja, wird die Ausführung übersprungen. Wenn nicht, führt es die für den Use-Case erforderlichen Aktionen aus. Schließlich erstellt es einen neuen Eintrag in der Log-Tabelle, um zu erfassen, dass es den Task ausgeführt hat — wobei es erneut ACID-Prinzipien nutzt, um Konsistenz zu gewährleisten. Das liegt daran, dass sowohl der Log als auch die Business-Daten gespeichert werden, oder keines von beiden. ``` @JobWorker(type = "send-confirmation-email") fun sendConfirmationEmail(job: ActivatedJob) { val operationId = job.key.toString() // Check if already processed if (processedOperationRepository.existsById(operationId)) { log.info("Operation $operationId already processed, skipping") return } // Process the job val subscriptionId = job.variablesAsType(ConfirmationVariables::class.java).subscriptionId val subscription = subscriptionRepository.findById(subscriptionId)!! emailService.sendConfirmationEmail(subscription.email) // Record that we processed this operation processedOperationRepository.save( ProcessedOperation(operationId, "send-confirmation-email") ) } ``` Zusammengefasst: Dieser Ansatz hält dein Domain-Modell fokussiert auf Business-Logik, während er ein einzelnes, wiederverwendbares Pattern für alle Worker bereitstellt. Aber am wichtigsten: Da At-Least-Once-Delivery über verteilte Systeme hinweg üblich ist, ist dieser Ansatz nicht auf Zeebe beschränkt. Du kannst dieselbe Tabelle anpassen, um gegen jedes At-Least-Once-Delivery-Szenario zu schützen — wie bei der Verwendung von Kafka. Daher könnte dieses Pattern vielleicht eine deiner Standard-Idempotenz-Strategien sein. ### **Warum beim Thema Idempotenz beide Seiten wichtig sind:** Aber es gibt einen Haken: Das Operation-Log funktioniert nur gut, wenn dein Worker exklusiv in ein System schreibt — deine Datenbank. Wenn du jedoch das Beispiel von oben nochmal betrachtest, bemerkst du vielleicht, dass der Worker mehrere Systeme koordiniert: Er schreibt in die Datenbank und ruft einen Mail-Service auf. Wenn der Worker nach dem Aufruf des Mail-Service crasht, aber bevor das Log committed wird, wird die Mail zweimal gesendet. Bei einem Retry kann das Log davor jedoch nicht schützen, weil es nicht weiß, dass die Mail bereits gesendet wurde. Entsprechend taucht das Distributed Transaction Problem wieder auf. Um dies zu lösen, könntest du eine weitere Outbox für den Call zum Mail-Service hinzufügen. Aber das führt wieder zu denselben At-Least-Once-Delivery-Herausforderungen. Daraus folgt: Idempotenz muss auf beiden Seiten jeder Interaktion existieren. Deine Worker brauchen sie, und auch die Services, die sie aufrufen — einschließlich unserer Engine. Und deshalb müssen wir untersuchen, was Zeebe auf der Empfängerseite bietet. ## 📐 Block 3: Wie Zeebe beim Lösen der Herausforderungen helfen kann Zeebe bietet spezifische Features, die die Orchestrierungs- und Idempotenz-Patterns ergänzen, die wir behandelt haben. Wenn du sie durchdacht anwendest und mit den bereits erwähnten Patterns kombinierst, kannst du wirklich resiliente Systeme bauen. ### Standard Message Correlation: Das Verhalten verstehen Man könnte annehmen, dass Zeebes Message-Correlation bereits Idempotenz bietet. Und in einigen Szenarien imitiert die Correlation das Verhalten von Idempotenz — eine Garantie ist das aber nicht. Wenn du eine Message veröffentlichst, akzeptiert Zeebe sie immer und versucht, sie mit einer wartenden Prozessinstanz unter Verwendung eines Correlation-Keys und Message-Namens zu korrelieren. Daher hängt das Ergebnis von deinem Prozess-Design ab: **Intermediate Message-Catch Events:** Wenn eine Prozessinstanz bei einem Message-Catch-Event wartet, korreliert die erste Message und bringt den Prozess voran. Wenn danach ein Duplikat ankommt, gibt es kein wartendes Event mehr — also verwirft Zeebe es. Dies _imitiert_ Idempotenz und erzeugt ein sicheres Ergebnis, aber es ist nur glückliches Timing. **Message-Start-Events und Event-Subprozesse:** Anders als Intermediate Events profitieren diese nicht von diesem Timing-basierten Schutz. Jede Message erzeugt neue Arbeit — startet eine neue Prozessinstanz oder triggert einen Subprozess. Duplikate werden nicht verworfen; sie multiplizieren deine Business-Logik-Ausführung. **Die wichtige Einsicht:** Zeebes Correlation geht es um das _Routing_ von Messages an die richtigen Instanzen, nicht um das Verhindern von Duplikaten. Es fragt nicht “habe ich diese Business-Message schon gesehen?” Es fragt nur “gibt es gerade ein Event, das wartet?” Also brauchst du für echte Deduplikation einen anderen Mechanismus. ### Message IDs: Zeebes Deduplikationsmechanismus Daher bietet Zeebe einen anderen Mechanismus jenseits von Correlation: `messageIds`. Dies ist eine optionale Property, die du beim Veröffentlichen von Messages hinzufügen kannst. Sie beruht darauf, dass Zeebe alle empfangenen Messages in einem Buffer speichert. Wenn eine neue Message ankommt, prüft die Engine, ob diese `messageId` bereits im Buffer existiert. Wenn ja, lehnt sie das Duplikat ab. ``` fun sendSubscriptionMessage(subscriptionId: UUID) { val messageId = "subscription-created-$subscriptionId" zeebeClient.newPublishMessageCommand() .messageName("subscription-created") .correlationKey(subscriptionId.toString()) .messageId(messageId) // Deduplication key .variables(mapOf("subscriptionId" to subscriptionId)) .timeToLive(Duration.ofSeconds(10)) .send() .join() } ``` Bevor du dich jedoch allein auf dieses Feature verlässt, solltest du Folgendes wissen: Laut der [Dokumentation zu Message Uniqueness](https://docs.camunda.io/docs/components/concepts/messages/#message-uniqueness) behält die Engine Messages nur für eine begrenzte Zeit in ihrem Buffer — die sogenannte Time-to-Live (TTL) der Message. Nur während dieses Zeitfensters wird sie Messages ablehnen, die dieselbe `messageId` teilen wie eine bereits im Buffer befindliche. Sobald die TTL abläuft und die Message den Buffer verlässt, wird Zeebe Messages mit derselben `messageId` erneut akzeptieren. Das bedeutet, die Property bietet nur kurzfristige Deduplikation — was typischerweise Sekunden sind. Es ist kein langfristiger Idempotenz-Schutz. **Eine Strategie zur Begrenzung von Problemen** Dennoch würde ich empfehlen, `messageIds` zu verwenden. Sie sind eine effektive Lösung zum Filtern von Duplikaten während des kritischen kurzfristigen Zeitfensters — wenn beispielsweise Retries durch das Outbox Pattern mehrere Messages in kurzer Zeit veröffentlichen. Du solltest es jedoch immer mit anderen Patterns wie idempotenten Workern für langfristige Sicherheit kombinieren. Dieser defensive Ansatz gibt dir das Beste aus beiden Welten. ### Prozess-Modellierung für Resilienz Neben den technischen Features von Zeebe spielt auch die Art, wie du deine BPMN-Prozesse modellierst, eine wichtige Rolle beim Aufbau von robusten Systemen. Es gibt verschiedene Modellierungsprinzipien, die helfen können — zwei möchte ich besonders hervorheben: **Nutze unterbrechende Boundary Events mit Bedacht** Boundary Events sind mächtige Modellierungskonstrukte, aber sie sollten mit Vorsicht eingesetzt werden. Beschränke ihre Nutzung auf Szenarien, in denen eine Unterbrechung tatsächlich deine Business-Logik widerspiegelt. Wenn du unsicher bist, überlege, ob du das Event nicht nach dem Element modellieren kannst, statt es zu unterbrechen. Vor allem solltest du unterbrechende Boundary Events nicht an Elementen anbringen, die keinen expliziten Wait State haben **und** bei denen du nicht kontrollierst, wann das Event ausgelöst wird. Das ist besonders problematisch bei Service Tasks — vor allem bei lang laufenden mit Boundary Events, die durch Timer oder Messages von außerhalb des Task-Scopes ausgelöst werden. Es spielt keine Rolle, ob das Event am Task selbst oder an einem übergeordneten Element wie einem Subprocess modelliert ist. In beiden Fällen bist du einem kritischen Risiko ausgesetzt: Wenn das Event feuert, wird der Job abgebrochen, aber dein Worker hat vielleicht schon mit der Verarbeitung begonnen. Da der Job nicht mehr aktiv ist, kann der Worker die Completion nicht bestätigen. Das führt genau zu den Koordinationsproblemen, die wir zuvor besprochen haben und lässt deine Systeme in inkonsistenten Zuständen zurück. Ein sichererer Ansatz ist es, unterbrechende Boundary Events hauptsächlich auf **Elementen mit expliziten Wait States** zu verwenden. Das sind vor allem Message Receive Tasks und User Tasks. Diese Elemente pausieren die Ausführung und warten auf externe Eingaben, was bedeutet, dass wir kontrollieren, wann die Completion erfolgt. Wir haben explizite Use Cases, die explizite Commands an die Engine senden. Wenn ein unterbrechendes Event bei einem solchen Element feuert, wird der Task abgebrochen. Wenn wir dann versuchen, ihn zu completen, wirft Zeebe einen Fehler. Soweit ist alles gleich wie bei Service Tasks. Aber hier ist der entscheidende Unterschied: Da wir die Completion explizit auslösen, können wir diesen Fehler in unserem Use Case abfangen und angemessen behandeln — zum Beispiel, indem wir die zugehörige Business-Transaktion ablehnen. Das macht die Unterbrechung vorhersehbar und gibt uns Kontrolle, um Inkonsistenzen zu vermeiden. Aber auch dieser Ansatz ist nicht kugelsicher. Wenn dein Use Case in mehrere Systeme schreibt — wie Zeebe und deine Datenbank — stehst du immer noch vor der Koordinierungsherausforderung und ihren Problemen. Hier wird unser zweites Modellierungsprinzip wichtig. **Splitte Tasks, die mehrere Systeme koordinieren, in separate Tasks** Wenn ein einzelner Use Case deine Datenbank aktualisieren _und_ eine Message an Zeebe senden muss, hast du ein Distributed Transaction Problem innerhalb dieses Tasks geschaffen. Statt sie so zu lassen, modelliere sie als separate Tasks in deinem Prozess. Lass jeden Task ein System handhaben. Wenn einer fehlschlägt, kann der Prozess genau diesen Step wiederholen, ohne die anderen zu beeinflussen. Dieser granulare Ansatz erhöht die Resilienz deines Prozesses und vereinfacht die Implementierung der Idempotenz-Patterns, die wir besprochen haben. Aber beachte, dass es die technische Komplexität deines Prozessmodells erhöht und nicht immer funktioniert. Wenn es nicht funktioniert, kann das ein Hinweis darauf sein, dass du ein Pattern wie Outbox brauchst. ### Nutze Kompensationen, um Fehler mitten im Prozess zu handhaben Selbst mit Outbox Patterns, Idempotenz und vorsichtigem Boundary Event Modeling bleiben manche Szenarien unlösbar durch reine Prävention. Manchmal musst du **bereits committete Arbeit rückgängig machen** — während der Prozess noch läuft. Stell dir einen erweiterten Newsletter-Flow vor: Ein User abonniert einen Premium Gaming Newsletter mit limitierten Plätzen. Dein Prozess reserviert einen Platz in der Subscriber Quota, sendet die Confirmation Email und verarbeitet dann die Payment. Aber die Payment schlägt fehl. Zu diesem Zeitpunkt hast du bereits den Platz reserviert und die Email gesendet — beides in ihre jeweiligen Systeme committed. Den Prozess einfach fehlschlagen zu lassen, hinterlässt einen inkonsistenten Zustand: einen reservierten Platz für einen nicht zahlenden User, der legitime Subscriber blockiert. Hier wird **BPMN Compensation** wichtig. Du würdest ein Compensation Boundary Event an den Payment Task anhängen, das Compensation Handler triggert, wenn Payment fehlschlägt. Diese Handler führen deine “Undo”-Logik aus: den reservierten Platz im Quota-System freigeben und den Subscription-Status aktualisieren. Der Prozess kann dann ordentlich enden oder den User bitten, es erneut zu versuchen, aber dein System bleibt konsistent — der Platz ist verfügbar für andere. Wichtig dabei: Compensations verhindern keine Distributed Transaction Problems. Sie bieten explizite Rollback-Pfade für Szenarien, wo Prevention nicht ausreicht, und halten deine Business-Logik konsistent, selbst wenn Downstream-Steps fehlschlagen. ### SAGA: Das Pattern, das alles zusammenbringt Dieser Ansatz — Koordination von verteilten Operationen durch lokale Transaktionen mit Compensation-Logik — hat einen Namen: **das SAGA Pattern**. SAGA akzeptiert die Realität, dass du keine atomaren Transaktionen über Services hinweg haben kannst. Stattdessen orchestriert es eine Sequenz von lokalen Transaktionen, wo jeder Step entweder bis zum Erfolg retrying kann (Forward Recovery) oder Compensations triggert, um vorherige Arbeit rückgängig zu machen (Backward Recovery). Zeebe ist wie geschaffen für die Implementierung von SAGA als Orchestration Pattern. Dein BPMN-Prozess wird zum SAGA Coordinator, Service Tasks repräsentieren lokale Transaktionen und Compensation Handler definieren deine Rollback-Logik. Das macht lang laufende Multi-Service-Transaktionen handhabbar ohne Distributed Locks oder Two-Phase Commits — und lässt dich resiliente Workflows bauen, die partielle Failures graceful handhaben. Die Patterns, die wir abgedeckt haben — Outbox, Idempotenz, Compensations und SAGA — bilden ein umfassendes Toolkit für Distributed Transactions mit Zeebe. Für Implementierungsdetails und Deep Dives in diese Patterns, schau dir diese Ressourcen vom Camunda Team an: - [Tutorial: How to use Compensation Events in Camunda 8](https://www.youtube.com/watch?v=xoTlE4yd3rk) - [Navigating Technical Transactions in Camunda 8 and Spring](https://camunda.com/blog/2023/12/navigating-technical-transactions-camunda-8-spring/) - [Lost in transaction (by Bernd Ruecker)](https://www.youtube.com/watch?v=8KgTB75VePo) ## 🎯 Verteilte Systeme für dich zum Laufen bringen Wir haben viel Terrain abgedeckt, vom Verstehen des Distributed Transaction Problems bis zur Implementierung von Patterns wie Outbox und Idempotenz. Lass uns nun alles zusammenbringen und seine Implikationen für dein Team und deine Systeme klären. ### Architektur ist immer ein Trade-off Dieser Artikel könnte den Eindruck erwecken, dass verteilte Systeme grundsätzlich problematisch sind — mit Herausforderungen wie dem Distributed Transaction Problem und Lösungen, die wir früher nicht (oder nur selten) brauchten. Aber lassen wir uns nicht täuschen. Architekturentscheidungen waren immer Trade-offs und werden es immer sein. Der Unterschied bei verteilten Systemen: Wir haben jetzt mehr Trade-offs zu navigieren. Dafür, dass wir Herausforderungen wie Koordinationskomplexität in Kauf nehmen, gewinnen wir Vorteile: Skalierbarkeit, Resilienz, cloud-natives Deployment und unabhängige Service-Evolution — Vorteile, die für die meisten Unternehmen unverzichtbar sind. Die Frage ist nicht, ob verteilte Systeme gut oder schlecht sind — sondern, ob diese Trade-offs zu deinem Kontext passen. Das musst du objektiv beurteilen. ### **Die Neue Realität akzeptieren** Mit diesem Verständnis können wir zum Kern dieses Artikels kommen: Das Distributed Transaction Problem ist nicht Zeebe-spezifisch. Es ist eine grundlegende Eigenschaft verteilter Systeme. Ob du mit Zeebe, Kafka oder einem anderen Remote-Service koordinierst - du begegnest immer denselben Herausforderungen. Das sollte dich nicht davon abhalten, Zeebe zu verwenden. Es bleibt eine exzellente Wahl für Prozess-Orchestrierung und löst unzählige Use Cases. Wie jede Architekturentscheidung bringt es Vorteile und Herausforderungen. Der Schlüssel: Akzeptiere seine Natur und wende effektive Patterns an — während du sicherstellst, dass dein gesamtes Team dieses Verständnis teilt. ### **Organisationsweites Bewusstsein aufbauen** Die technischen Patterns, die wir besprochen haben, sind wichtig, aber sie werden ohne organisatorisches Buy-in nicht erfolgreich sein. Jeder in deinem Team muss die oben beschriebene Realität verstehen: - Entwickler müssen wissen, wie man Patterns implementiert und für Idempotenz designed - Operations muss verteilte Koordination überwachen und bei Fehlern alarmieren - Product-Teams sollten UX designen, die Processing-States handhabt - Leadership muss verstehen, warum diese Investition wichtig ist Dies ist nicht nur ein Entwickler-Problem. Es ist ein Team-Problem. Veranstalte Brown-Bag-Sessions. Teile konkrete Beispiele aus deiner Domain. Mache das Unsichtbare sichtbar. ### **Mit den richtigen Patterns handeln** Sobald dein Team das Distributed Transaction Problem versteht, ist der nächste Schritt, systematisch Lösungen zu implementieren. Warte nicht darauf, dass Production-Fehler dich dazu zwingen. Die Patterns, die wir behandelt haben, geben dir die Tools — jetzt musst du sie strategisch anwenden: 1. **Identifizieren**: Identifiziere, wo deine Operationen mehrere Systeme umfassen 2. **Analysieren**: Bewerte die Auswirkung, die das Problem auf dein Business hat 3. **Priorisieren**: Fokussiere zuerst auf business-kritische Pfade 4. **Implementieren**: Wende geeignete Patterns basierend auf Kritikalität an 5. **Standardisieren**: Verwende dieselben Implementierungen wiederholt in deiner gesamten Codebasis, um Synergien zu nutzen Eine einzelne Outbox-Implementierung kann alle deine kritischen Workflows bedienen. Ein Processed-Operations-Log-Pattern kann alle deine Worker schützen — und potenziell auch deine Kafka-Events. Die Vorabinvestition zahlt sich über dein gesamtes System aus. ### **Von Tag Eins an für Idempotenz designen** Über einzelne Patterns hinaus gibt es ein breiteres Prinzip: Mache Idempotenz zu einem grundlegenden Design-Prinzip für alle deine Services, nicht zum Nachgedanken. Jeder Worker, jeder Service, jede Integration sollte Duplikate sauber handhaben. Es geht nicht darum, Komplexität hinzuzufügen — sondern darum, Zuverlässigkeit von Anfang an in deine Architektur einzubauen. ### **Verteilte Systeme überwachen und testen** Zu guter Letzt reicht es nicht aus, nur Patterns zu implementieren — du musst verifizieren, dass sie funktionieren und erkennen, wenn sie fehlschlagen. So gehst du vor: - Teste und überwache die Implementierung deiner Koordinationspatterns - wie eine Outbox - Implementiere Distributed Tracing, um systemübergreifende Flüsse zu verstehen - Richte Alerts ein, die dich proaktiv benachrichtigen, bevor Kunden sich beschweren Dein Monitoring und Testing muss sich zusammen mit deiner Architektur entwickeln. ## 👩🏽‍💻 Erkunde den Code Um diesen Blogartikel und meinen Talk zu diesem Thema zu ergänzen, habe ich ein GitHub Repository erstellt. Es enthält: - **Funktionierende Spring Boot Anwendungen** mit Docker Compose Setup und **Code-Beispiele** für alle Patterns (After-Transaction, Outbox & Idempotenz) - **Detaillierte READMEs**, die jede Implementierung erklären - **Bruno API Collections** zum Testen von Szenarien Clone es, führe die Beispiele aus, bring Dinge zum Brechen und schau, was passiert. Der beste Weg, Distributed Transactions zu verstehen, ist, die Probleme und Lösungen aus erster Hand zu erleben. ## 🎓 **Lass uns gemeinsam lernen** Dies ist ein komplexes Thema, das von Community-Wissen profitiert. Welchen Herausforderungen begegnest du mit Distributed Transactions in deinen Systemen? Welche Patterns haben — oder haben nicht — für dich funktioniert? Hast du einen besseren Ansatz gefunden? Hast du Fragen? Oder auch Szenarien erlebt, die hier nicht behandelt wurden? Ich würde gerne von deinen Erfahrungen hören und von deinen Ansätzen lernen. Teile deine Gedanken in den Kommentaren, öffne ein Issue auf GitHub oder kontaktiere mich direkt. ## 👋🏽 Danksagungen Dieser Artikel wäre ohne die vielen Gespräche, die ich geführt habe, nicht möglich gewesen. Ich bin allen dankbar, die sich die Zeit genommen haben, dieses herausfordernde Thema mit mir zu diskutieren — eines, bei dem im Kontext von Process-Engines umfassende Informationen relativ selten sind. Besonderer Dank geht an Dominik Horn und Stephan Pelikan für ihren wertvollen Input. Eure Perspektiven haben sowohl das Repository als auch diesen Artikel mitgeformt. Und an die Person, die dies genau in diesem Moment liest: Danke, dass du dir die Zeit genommen hast. Ich hoffe, dass, auch wenn dies ein ziemlich langer Artikel war, du das Lesen genossen hast und er dir hilft, resilientere verteilte Systeme zu bauen. _This post was originally published in English on [Medium.com](https://medium.com/p/d4bbbca295d6)._ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fleveling-up-verteilte-transaktionen-zeebe%2F)[](mailto:?subject=Leveling%20up!%20Wie%20du%20die%20Herausforderung%20verteilter%20Transaktionen%20in%20Zeebe%20l%C3%B6sen%20kannst&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fleveling-up-verteilte-transaktionen-zeebe%2F) ## Marco Schäck Process Development Lead bei Miragon [in Marco kennenlernen](https://www.linkedin.com/in/schaeckm/) [Mehr von Marco](/blog/?author=marco-schäck) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Logistikprozesse mit Camunda automatisieren](https://www.miragon.io/blog/logistikprozesse-camunda-automatisieren/) BPM Wie wir im Rahmen eines Hochschulprojekts einen Logistik-Microservice für die Open Source-Plattform RemedyMatch mit Camunda und Spring Boot umgesetzt haben. Dominik Horn Co-Founder & Geschäftsführer **30\. Juni 2020**4 Min. Lesezeit Die Kooperation mit der Hochschule Augsburg startete im April in die nächste Runde. Doch wie gestaltet man ein Hochschulprojekt während des Corona-Lockdown? Wir entschieden uns als Team dafür, das Open Source-Projekt RemedyMatch zu unterstützen - eine Plattform, die sich auf die Verteilung von Hilfsmitteln fokussiert hat und im Rahmen des WirVsVirus-Hackathons entstanden ist. Die Herausforderung bestand vor allem darin, flexibel auf die sich ändernden Rahmenbedingungen eingehen zu können. Außerdem musste die bestehende Plattform modular erweitert werden. Insgesamt entwickelten über zehn Personen an der Lösung, die bisher noch nicht in Berührung mit RemedyMatch gekommen waren. Wir entschieden uns deshalb dafür, für die neue Logistik-Domäne einen eigenen Microservice zu implementieren und diesen in die bestehende Architektur einzubinden. Dabei kümmerten wir uns um sämtliche anfallenden Aufgaben im Rahmen der Entwicklung und des Prozessmanagements. Nach der Analyse der Logistikprozesse modellierten wir diese in BPMN und [automatisierten sie mit Camunda](/portfolio/automate/). Wir orientierten uns bei Technologie und Software-Architektur am bereits bestehenden Stack des RemedyMatch-Projekts. Wir setzten auf Spring Boot im Backend und nutzten das External-Task-Feature von Camunda, um unsere Service Tasks zu implementieren. ## Technologische Rahmenbedingungen Zum Start des Semesterprojekts gab es in der Architektur von RemedyMatch bereits sechs verschiedene Komponenten. Die für uns relevanten sind dabei der SSO-Server, die Process Engine und das Frontend: - **Server**: Für die Authentifizierung setzt das Projekt auf Keycloak mit OpenID Connect. Für Spring Boot kann eine sehr komfortable Integration genutzt werden, sodass die Einbindung der Authentifizierung bereits nach wenigen Stunden umgesetzt war. - **Process Engine**: Für die Automatisierung der in BPMN modellierten Prozesse wird die Process Engine Camunda genutzt. In der Architektur spielt Camunda eine wichtige Rolle für die Orchestrierung der einzelnen Microservices. Dabei wurde das External-Task-Feature verwendet, das es den einzelnen Service-Workern erlaubt, sich ihre Aufgaben direkt von der Engine zu holen und asynchron abzuarbeiten. Dieses Pattern führt zu einer besseren Skalierbarkeit der Anwendung und einer höheren Fehlertoleranz. Zum Einen können bei Bedarf weitere Service-Worker hinzugeschaltet werden, zum anderen können Fehler durch die Process Engine gesondert behandelt werden. - **Frontend**: Dieser Teil der RemedyMatch-Plattform ist eine React-Anwendung. In einer idealen Microservice-Architektur existieren für jede Domäne einzelne Frontends, welche anschließend in einer Anwendung zusammengeführt werden. Mit zwei Frontend-Entwicklern macht dies jedoch wenig Sinn und so entschieden wir uns dafür, die Anforderungen unseres Logistik-Prozesses in die bestehende Frontend-Anwendung zu integrieren. - **Die weiteren Komponenten** waren für unsere Domäne nicht entscheidend. Lediglich für das Abfragen der Bedarfs- bzw. Angebotsdaten musste eine Schnittstelle in den entsprechenden Service integriert werden. Wir hatten dadurch wenig Abhängigkeiten zu den anderen Entwicklern und konnten die Logistik-Lösung eigenständig implementieren. ## Umsetzung des Logistikprozesses Für die Umsetzung starteten wir mit einer fachlichen Analyse der Logistik-Domäne, in der zunächst die Abläufe etablierter Unternehmen näher betrachtet wurden. Für RemedyMatch überlegten wir uns dann ein Konzept, das wie folgt aufgebaut war: 1. Zunächst erhalten der Spender und der Empfänger der Hilfsmittel jeweils die Möglichkeit, sich selbst um den Transport zu kümmern . 2. Sollte sich keiner der beiden um den Transport kümmern können oder wollen, wird der Lieferauftrag für Dritte freigegeben . 3. Nutzer, die sich auf der Plattform als Logistiker registriert haben, können ausgewählte Lieferungen übernehmen. Den Prozess selbst hatten wir in Camunda samt Test-Automatisierung in kurzer Zeit implementiert und konnten uns dadurch auf das Logistik-Backend konzentrieren. Für die REST-Calls nutzen wir den bekannten Feign-Client und für die Speicherung der Daten setzten wir auf Spring Data JPA. Dabei teilten wir die Anwendung in drei Ebenen: - **Infrastruktur**: JPA-Repositories und Entity-Klassen - **Domain**: Application-Services und Domain-Objekte - **API**: Schnittstellen und Transfer-Objekte Das Anlegen des Lieferauftrags implementierten wir mit einem External-Task-Worker, was es uns erlaubte, den neuen Microservice von der restlichen Anwendung zu entkoppeln. Um offene User-Tasks abzuschließen oder Nachrichten an den Prozess zu senden, stellten wir für die bestehende React-Anwendung REST-Aufrufe im Logistik-Service bereit. Dies ermöglicht es den Empfängern und Spendern der Hilfsmittel, die Lieferung eigenständig abzuwickeln. Um die Zustellung durch externe Logistiker zu ermöglichen, entwickelten wir gemeinsam mit dem UI/UX-Team von RemedyMatch einen MVP für eine separate Anwendung und passten unseren BPMN-Prozess darauf an. Insgesamt war es ein rundum gelungenes und lehrreiches Projekt, das vor allem durch das Engagement aller Beteiligten sehr viel Spaß gemacht hat. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Flogistikprozesse-camunda-automatisieren%2F)[](mailto:?subject=Logistikprozesse%20mit%20Camunda%20automatisieren&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Flogistikprozesse-camunda-automatisieren%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Low-Code-Prozessautomatisierung - Herausforderungen und Lösungsansätze bei der Umsetzung von Projekten](https://www.miragon.io/blog/low-code-prozessautomatisierung-herausforderungen/) BPM Herausforderungen und Lösungsansätze bei der Umsetzung von Low-Code-Projekten zur Prozessautomatisierung - von Dependency Management bis CI/CD. Dominik Horn Co-Founder & Geschäftsführer **29\. Apr. 2023**4 Min. Lesezeit # Low-Code und BPMN: Eine Kombination mit Fallstricken? Manchmal träumen wir alle davon, die Welt auf Knopfdruck zu verändern, nicht wahr? In der IT-Welt wäre dieser Knopfdruck die Fähigkeit, digitale Lösungen ohne echte Softwareentwicklung zu kreieren. Ein verlockender Gedanke! Und im Kontext der Prozessautomatisierung haben Tools wie Zapier und n8n bereits beeindruckende Ergebnisse durch Technologieintegration mittels Drag&Drop gezeigt. Aber stellt sich die Frage: Ist diese Low-Code Herangehensweise auch für die Automatisierung von Prozessen mit BPMN geeignet? Lasst mich gemeinsam mit euch in einige Herausforderungen eintauchen, die uns auf dieser Reise begegnen könnten. ## 1\. Technologische Instabilität Ist euch schon mal aufgefallen, dass Technologien in Unternehmen oft wechseln? Datenbanken ändern sich, Mailing-Services wechseln, die allgemeine Anforderung, Benachrichtigngen zu senden aber nicht. Selbst Eventbroker können sich ändern, obwohl das zugrunde liegende Kommunikationsparadigma bestehen bleibt. Wenn Technologien direkt in Prozesse eingebunden sind, führen Änderungen zu direkten Störungen in den Abläufen. Klingt chaotisch, oder? ## 2\. Eine steilere Lernkurve bei der Modellierung Stellt euch vor, eine Funktion, in einem Service Task, wie “Produkt stornieren” zu nutzen. Nun stellt euch vor, die SQL-Queries dafür von Grund auf neu zu schreiben und sie dann in einen Prozess zu integrieren. Plötzlich wird diese einfache Aufgabe zu einer, die Expertise und Know-how erfordert. Und der Wunsch, IT und Business näher zusammenzubringen? Nun, das könnte ein bisschen komplizierter werden. ## 3\. Schwierige Impact-Analysen Bleiben wir bei dem Beispiel mit SQL. Wenn sich die Struktur einer Tabelle ändert, wie verfolgt man dann diese Änderung in BPMN? Zentrale Integrationen für Technologien, die von beliebigen Prozessen genutzt werden können, haben hohe Anforderungen an die Abwärtskompatibilität. Es schwierig zu überblicken welcher Prozess, welche Schnittstelle, in der welcher Version nutzt. Es ist eine komplexe Aufgabe, die viele in den Wahnsinn treiben könnte! ## 4\. Unterschätzte Komplexität Es ist leicht, sich von den schnellen Erfolgen, die Low-Code bieten kann, verzaubern zu lassen. Aber es besteht die Gefahr, dass wir durch diese kurzfristigen Erfolge langfristige Ziele wie Stabilität und Lifecycle-Management übersehen. Hinzu kommt häufig fehlendes automatisiertes Testing, das manuelle Aufwände auf lange Sicht in die Höhe treibt. Wer möchte seine Zeit damit verbringen bei kleinsten Änderungen ständig zu prüfen ob noch alles läuft? ## 5\. Migrationsherausforderungen: Langlaufend vs. kurzlaufend Migration ist ein kniffliges Thema. Angenommen wir haben 20 verschiedene Prozesse in jeweils fünf verschiedenen Versionen. Dann müssten wir die Abhängigkeiten zu 100 (20x5) Prozessen im Blick behalten - ohne oftmals zu wissen welche Funktionalität sie im speziellen nutzen. Wenn Technologien wechseln, kann die Migration von Prozessinstanzen zu einem Albtraum werden. Es ist, als würde man versuchen, einen laufenden Zug auf ein neues Gleis zu setzen! ## 6\. Der fehlende Wettbewerbsvorteil Eine der Herausforderungen, die oft übersehen wird, ist der mangelnde Wettbewerbsvorteil, den standardisierte Low-Code-Lösungen mit sich bringen können. Lasst mich das erläutern: Wenn wir alle das gleiche Toolset nutzen, haben wir alle auch dieselben Grenzen und Möglichkeiten. Jedes Unternehmen, das sich für den Einsatz von Low-Code entscheidet, arbeitet im Grunde mit dem gleichen Bausteinkasten. Das bedeutet, dass unsere kritischen Geschäftsprozesse, die normalerweise eine Quelle der Differenzierung und des Wettbewerbsvorteils sein sollten, plötzlich sehr ähnlich – wenn nicht gar identisch – zu denen unserer Konkurrenten sein könnten. # Wie meistern wir diese Herausforderungen? In jeder Herausforderung steckt auch eine Chance zur Innovation und Optimierung. Und hier sind einige Strategien, mit denen wir diese Stolpersteine angehen können: ## 1\. Dedizierte Schnittstellen programmieren und bereitstellen [Die Zusammenarbeit mit Entwicklern](/leistungen/) ist hier der Schlüssel. Indem sie Schnittstellen maßgeschneidert für unsere Bedürfnisse bereitstellen, können wir die Komplexität umgehen, die oft bei Low-Code-Integrationen auftritt. Warum sich mit generischen, schwammigen Schnittstellen herumschlagen, wenn man genau das haben kann, was man braucht? Der Clou hierbei: Low-Code tritt ins Spiel, indem wir diese Schnittstellen als Templates für die Modellierung nutzen. Anstatt jedes Mal von Grund auf neu zu beginnen, haben wir eine Basis, die sowohl flexibel als auch stabil ist. ## 2\. Verbindung von Low-Code Tools Statt eine “entweder-oder” Herangehensweise zu wählen, können wir das Beste aus beiden Welten nutzen. Indem wir Tools wie n8n, Zapier oder RPA-Lösungen mit BPMN verbinden, schaffen wir eine Brücke zwischen langlaufenden Prozessen und vollautomatisierter Technologieintegration. Der Gedanke dahinter ist einfach: Jedes Tool hat seine Stärken, also warum nicht alle miteinander kombinieren? Ein besonderer Vorteil dabei ist die Vereinfachung. In Tools wie n8n können wir daran arbeiten, die Schnittstelle für den BPMN-Prozess so einfach und kompatibel wie möglich zu gestalten. Dadurch wird der gesamte Prozess nicht nur effizienter, sondern auch zuverlässiger. Vor allem bei Unterstützungsprozessen lassen sich wertvolle Entwicklungsressourcen durch dieses Vorgehen einsparen. Doch für einen geschäftskritischen Ablauf sollte stark hinterfragt werden, ob sich dieser Ansatz eignet! Die Komplexität steigt mit jedem weiteren Tool das eingesetzt wird und wirkt sich somit auf die Stabilität und Skalierbarkeit aus. # Fazit Die Integration von Low-Code-Ansätzen in die Prozessautomatisierung mittels BPMN ist verlockend und bietet sicherlich einige Vorteile. Doch wie bei allem gibt es auch hier Herausforderungen und Stolpersteine. Als jemand, der tief in diese Welt eingetaucht ist, empfehle ich, sich genau zu überlegen, welche Technologien und Ansätze für euer Unternehmen am besten geeignet sind. Es könnte sich lohnen, den glänzenden neuen Trends zu widerstehen und stattdessen auf bewährte Methoden zu setzen. Aber egal welchen Weg ihr wählt: Bleibt neugierig und offen für Neues! Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Flow-code-prozessautomatisierung-herausforderungen%2F)[](mailto:?subject=Low-Code-Prozessautomatisierung%20-%20Herausforderungen%20und%20L%C3%B6sungsans%C3%A4tze%20bei%20der%20Umsetzung%20von%20Projekten&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Flow-code-prozessautomatisierung-herausforderungen%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Low-Code und BPMN – Eine Kombination mit Fallstricken?](https://www.miragon.io/blog/low-code-und-bpmn-fallstricke/) BPM Warum die Kombination von Low-Code und BPMN nicht immer hält, was sie verspricht, und worauf du achten solltest. Dominik Horn Co-Founder & Geschäftsführer **19\. Sep. 2023**4 Min. Lesezeit # Einleitung Automatisierung von Geschäftsprozessen ist ein entscheidender Faktor, um im Wettbewerb zu bestehen. Low-Code-Entwicklung ist eine spannende Möglichkeit, um fehlende Entwicklungsressourcen auszugleichen und Geschwindigkeit bei der Digitalisierung aufzunehmen. In diesem Blogbeitrag beleuchten wir die Herausforderungen sowie Lösungsansätze, die bei der Umsetzung von Low-Code-Projekten auftreten können. # Ein kurzer Überblick Low-Code-Prozessautomatisierung ermöglicht es Experten, Projekte schnell und effizient umzusetzen, indem sie sie dabei unterstützt, - visuelle Entwicklungswerkzeuge und vorgefertigte Komponenten zu nutzen, um Anwendungen mit wenig oder keinem Programmieraufwand zu erstellen; - auf bestehenden Integrationen, Bausteinen oder anderen Artefakten aufzubauen, um die Entwicklung zu beschleunigen und die Komplexität zu reduzieren; - eine Vielzahl von Artefakten wie Formulare, Prozesse, Entscheidungstabellen, Dokumentvorlagen oder E-Mail-Templates für die Automatisierung zu erstellen. Zahlreiche Softwarehersteller haben integrierte Web-Plattformen mit dem Versprechen bereitgestellt, vollständig auf klassische Softwareentwicklung verzichten zu können. Wenn dann aber doch irgendwann stärkere Anpassungen notwendig sind, ist der Einsatz der klassischen Softwareentwicklung häufig nicht oder nur mithilfe proprietärer Sprachen möglich. Bei der Entwicklung von Automatisierungslösungen mit Low-Code Plattformen treten häufig Herausforderungen auf. Diese werden verstärkt, je mehr Systemintegrationen in einem Prozess verwendet werden oder je mehr unterschiedliche Tools benötigt werden. # Herausforderungen bei der Umsetzung Bei der Entwicklung und Umsetzung von Low-Code-Projekten können verschiedene Herausforderungen auftreten: - **Management von Artefakten und Abhängigkeiten:** Die Vielzahl von Artefakten und deren Abhängigkeiten untereinander müssen zur Laufzeit berücksichtigt werden. Dies erfordert ein effektives Dependency Management und Versionskontrolle. Häufig werden unterschiedliche Low-Code-Tools eingesetzt; Deployments in spezifische Umgebungen müssen daher organisatorisch gelöst werden, weil jedes Tool seine eigene Projektverwaltung inkl. individuellem Deploymentprozess mit sich bringt. - **Fehlerbehebung und Migrationen:** Fehler in laufenden Prozessen müssen identifiziert und behoben werden. Dabei ist es wichtig, Migrationen durchzuführen, um sicherzustellen, dass alle Prozesse und Artefakte auf dem neuesten Stand sind. Die Anpassungen müssen dann zusätzlich auf den aktuellsten Entwicklungsstand und in unterschiedlichen Tools angewendet werden - der sichere Weg in die “Versionshölle”. - **Nachvollziehbarkeit:** Den Überblick der verschiedenen Prozessversionen und ihrer Abhängigkeiten in unterschiedlichen Systemen zu behalten kann komplex sein, insbesondere wenn es um die Verwaltung verschiedener Versionen von Artefakten und Integrationen geht. Wann wurde welche Version in welcher Umgebung ausgebracht? - **Impact-Analysen und Vulnerability-Checks:** Es ist wichtig, mögliche Auswirkungen von Systemausfällen oder Sicherheitslücken auf die entwickelten Prozesse zu untersuchen und entsprechende Gegenmaßnahmen zu treffen. Was passiert, wenn Schnittstellen geändert werden? Welche Prozesse oder Formulare sind von Fehlerbehebungen und Schwachstellen betroffen? # Lösungsansätze Um die Herausforderungen bei der Umsetzung von Low-Code-Projekten zu bewältigen, können folgende Lösungsansätze hilfreich sein: - **Projektverwaltung inkl. Berechtigungen:** Git-Repositories ermöglichen ein effizientes Management von Projekten, einschließlich der Zugriffsrechte für verschiedene Teammitglieder. Zudem können Entwicklungsstände einzelner Artefakte gemeinsam versioniert werden. - **Versionskontrolle:** Auch hier bietet Git mithilfe von Branches und Tags einfache Möglichkeiten, zwischen Entwicklungsständen zu navigieren. Über Git lassen sich ganz einfach verschiedene Artefakte gemeinsam verwalten. Dadurch ist transparent welche Dateien in welcher Version zusammengehören. Fehlersuche und Wiederherstellen von vorherigen Entwicklungsständen werden einfacher. - **Testing- und Deployment-Pipelines:** Continuous Integration (CI) und Continuous Deployment (CD) ermöglichen automatisiertes Testen und Ausrollen von Artefakten, wodurch die Qualität und Geschwindigkeit der Entwicklung erhöht werden kann. Die klassische Softwareentwicklung hat an dieser Stelle schon zahlreiche Probleme gelöst - es stehen Tools und Frameworks bereit, die auch für die Low-Code-Entwicklung genutzt werden können. - **Code-Qualitäts-Tools:** Tools wie SonarQube helfen, Code-Standards einzuhalten und potenzielle Probleme frühzeitig zu erkennen. Es können Regeln entworfen werden, die automatisch bei jeder Änderung geprüft werden. Das Ausbringen von Entwicklungsständen in produktive Umgebungen, die eine unzureichende Qualität aufweisen, kann ganz einfach verhindert werden. - **Impact-Analysen und Vulnerability-Checks:** Tools wie Dependabot oder Snyk ermöglichen die Überwachung von Sicherheitslücken und die Durchführung von Impact-Analysen, um potenzielle Risiken zu minimieren. Paketmanager wie npm ermöglichen das versionierte Verwalten unterschiedlicher Dateien. Wiederverwendbare Integrationen oder Formulare können in einem Paket gemeinsam versioniert und anderen Projekten zur Verfügung gestellt werden. Durch die Kombination mit den zuvor genannten Tools ergeben sich weitreichende Möglichkeiten, Integrationen einfach, transparent und nachhaltig in Low-Code-Projekten zu nutzen. # Zusammenfassung Low-Code-Prozessautomatisierung bietet viele Vorteile bei der Implementierung von Automatisierungsprojekten, bringt jedoch auch einige Herausforderungen mit sich. Anwender sollten sich daher der möglichen Schwierigkeiten bewusst sein und bestehende Entwicklungs-Technologien und Lösungsansätze nutzen, um diese zu bewältigen. Durch die Kombination von Low-Code- und Pro-Code-Ansätzen können Anwender effizientere und sicherere Automatisierungslösungen erstellen, die den Anforderungen der modernen Geschäftswelt gerecht werden. Du willst dein Team in sauberer BPMN-Modellierung fit machen, bevor die ersten Fallstricke zuschlagen? [Mehr zu unserem BPMN-Training](/trainings/bpmn-training/). Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Flow-code-und-bpmn-fallstricke%2F)[](mailto:?subject=Low-Code%20und%20BPMN%20%E2%80%93%20Eine%20Kombination%20mit%20Fallstricken%3F&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Flow-code-und-bpmn-fallstricke%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Mac einrichten leicht gemacht - mit Ansible](https://www.miragon.io/blog/mac-einrichten-leicht-gemacht-ansible/) Miragon Wie Ansible die Einrichtung und Wartung von MacBooks automatisiert - von Homebrew-Installation bis zur Verwaltung von Git-Repositories. Lukas Mösle Consultant **11\. Okt. 2022**10 Min. Lesezeit Jeder von uns hat seinen ganz eigenen Ablauf seinen PC einzurichten. Für gewöhnlich dauert es immer ein paar Tage bis man alle Programme installiert und konfiguriert, alle Git Repositories gecloned und die Entwicklungsumgebung eingerichtet hat. Nachdem das immer sehr Zeit aufwendig und um ehrlich zu sein auch ein bisschen nervig ist, habe ich damit begonnen mein PC Setup in Infrastructure as Code (IaC) Manier zu beschreiben, um schließlich meinen PC automatisiert einrichten zu können. IaC Tools gibt es wie Sand am Meer ich hab mich hierbei für Ansible entschieden, da es Open Source Software ist und ich mit Ansible bereits zuvor gearbeitet habe. Nachdem ich meinen privaten Linux PC bereits mit einem Ansible Setup automatisiert aufsetze und verwalte, habe ich auch ein solches Setup für mein Arbeits-Macbook bei Miragon erstellt. Die Basis dieses Setups verwenden wir bei Miragon mittlerweile sogar, um Macbooks für neue Kollegen einzurichten und die bereits vorhandenen Macbooks auf einem aktuellen Stand zu halten. In diesem Blogpost zeige ich, wie wir Ansible einsetzen, um Software auf unseren Macs mit Homebrew zu installieren, die Konfiguration von Entwicklungstools vorzunehmen und Git Repositories zu clonen und zu aktualisieren. ## Was ist Ansible > Ansible ist ein Open-Source-Automatisierungswerkzeug zur Orchestrierung und allgemeinen Konfiguration und Administration von Computern > > Quelle: [https://de.wikipedia.org/wiki/Ansible](https://de.wikipedia.org/wiki/Ansible) Mit Ansible beschreibt man den Zielzustand eines Systems in sogenannten **Playbooks** (`.yml` Dateien). Zusätzlich definiert man in einem sogenannten Inventory File die Zielsysteme auf denen das Playbook ausgeführt wird. Wenn man anschließend das Playbook ausführt baut Ansible eine SSH Verbindung zu den Zielsystemen auf und führt die einzelnen Tasks des Playbooks aus. Ansible ist agentless und dementsprechend muss Ansible nur auf dem Host System und nicht auf den Zielsystemen installiert werden. Infrastructure as Code ist heute zum Standard für die Serveradministration geworden. In diesem Kontext gehört Ansible auch am zu den Bekanntesten und Verbreitesten IaC Tools. Um Ansible (oder ein anderes IaC Tool) führt kein Weg herum bei der Administration von Server. In diesem Kontext trifft man auch besonders häufig auf diese Tools. Aber nachdem ein Desktop Betriebssystem nichts anderes ist, wie ein Server mit grafischer Oberfläche, kann Ansible auch hier problemlos eingesetzt werden. Insbesondere wenn man Linux aber auch Mac als Betriebssystem verwendet. ## Ansible trifft Mac Vor der Verwendung von Ansible müssen lediglich drei manuelle Einrichtungsschritte ausgeführt werden: Den Paketmanager Homebrew installieren, Ansible installieren und unseren SSH-Key in Github hinterlegen. **Homebrew** Homebrew verwenden wir als Paketmanager, um Programme zu installieren ([https://brew.sh/index\_de](https://brew.sh/index_de)) **SSH Key** Bevor wir Git Repositories von z.B. Github clonen können muss zuerst ein SSH Key erstellt und in Github hinterlegt werden **Ansible** Nachdem wir Homebrew installiert haben muss nur noch Ansible mit `brew install ansible` installiert werden und wir sind startklar. ### Software installieren mit Homebrew Die einfachste Art Software zu installieren ist mit einem Paketmanager. Unter Mac verwenden wir den Paketmanager Homebrew, den wir zuvor bereits installiert haben. Um ein Programm wie z.B. _asciiquarium_ mit Homebrew zu installieren verwenden wir das Ansible Module [homebrew](https://docs.ansible.com/ansible/latest/collections/community/general/homebrew_module.html). Folgender Ansible Task entspricht dem Befehl `brew install asciiquarium`. ``` - name: Install packages with homebrew homebrew: name: - asciiquarium ``` #### Software mit Homebrew Cask installieren Software mit einer grafischen Oberfläche (GUI) kann in Mac OS über Homebrew Cask installiert werden. Hierfür gibt es leider kein eigenes Ansible Module, jedoch können wir hierfür das Shell Module verwenden und direkt den Befehl `brew install --cask firefox` ausführen. Bei Ansible definieren wir hierfür einen eigenen Task, der das Shell Modul verwendet und das Command `brew install --cask firefox` ausführt. In diesem speziellen Fall müssen wir noch zusätzlich die Shell angeben, in der der Befehl ausgeführt werden soll. In unserem Fall ist das die `/bin/zsh` Shell. > Ansible führt jeden Befehl in einer eigenen non interactive Shell aus. Dabei werden Shell Hooks nicht ausgeführt und Konfigurationsdateien wie z.B. die `.zshrc` oder `.bashrc` nicht berücksichtigt. In unserem konkreten Fall kann es passieren, das das `brew` Executable nicht zur Verfügung steht in einer solchen Shell. Um das Problem zu beseitigen muss der Befehl in der richtigen Shell ausgeführt werden. In diesem Fall ist das die `bin/zsh`. ``` - name: Install homebrew cask packages shell: cmd: brew install --cask {{ item }} executable: /bin/zsh with_items: - google-chrome - firefox ``` Um mehrere Ansible Befehl hintereinander auszuführen kann das `with_items` Feature von Ansible verwendet werden. Dieses Feature erlaubt es über einen Task mit einer Liste an Werten zu iterieren. Bei der Installation von Cask Paketen müssen wir auf dieses Feature zurückgreifen, um mehrere Programme zu installieren. #### Regelmäßige Updates Eine weitere Aufgabe von Server-Administrator ist es, die auf den Servern installierte Software aktuell zu halten. Bei PCs sind die Benutzer dafür selbst verantwortlich. Auch diese Aufgabe lässt sich mit Ansible vereinfachen. Das Homebrew Module verfügt hierfür über die Optionen `update_homebrew`, um Homebrew selbst zu aktualisieren und `upgrade_all`, um alle installierten Homebrew Pakete zu aktualisieren. Der dazugehörige Ansible Task sieht wie folgt aus. ``` - name: Update homebrew homebrew: update_homebrew: true upgrade_all: true ``` Ich füge einen solchen Update Task gerne am Anfang eines Playbooks ein, damit dieser jedes mal ausgeführt wird. Dadurch kann sichergestellt werden, dass Homebrew und alle von Homebrew installierten Pakete auf einem aktuellen Stand sind. ### Konfigurationen vornehmen Konfigurationen werden unter Linux und Mac OS in speziellen Konfigurationsdateien vorgenommen. Um Konfigurationen automatisch anzupassen können diese Dateien mit Ansible bearbeitet werden. Es gibt unterschiedliche Möglichkeiten Konfigurationsdateien mit Ansible zu bearbeiten. Zum einen können Konfigurationsdateien erstellt werden, in dem diese an die richtige Stelle im System kopiert werden. Zum anderen können auch nur einzelne Zeilen zu einer bereits bestehenden Datei hinzugefügt werden. Zusätzlich gibt es noch viele weitere Möglichkeiten Konfigurationen vorzunehmen. Beispielsweise haben wir eine (sehr) einfach gestaltete `.zshrc` Datei in unserem Ansible Setup, die bei erstmaliger Ausführung erstellt wird. Diese Datei beinhaltet lediglich einige praktische Aliase, um die tägliche Entwicklung zu vereinfachen. ``` alias ll='ls -la' ``` Diese `.zshrc` Datei wird mit folgendem Ansible Command in das Home Verzeichnis des Users kopiert mit der passenden Berechtigung, falls die Datei nicht bereits vorhanden ist. ``` - name: Create .zshrc if it does not exist copy: dest: ~/ src: .zshrc mode: 0644 force: no ``` Die andere Alternative, die wir für Konfigurationen verwenden ist eine zusätzlich Zeile zu einer Datei hinzuzufügen. Hierfür kann man das Ansible Module `lineinfile` verwendet werden. In unserem Ansible Setup nutzen wir dieses Module, um z.B. einen Hook für das Tool [direnv](https://direnv.net/) in der `.zshrc` zu registrieren. Der Vorteil dieses Vorgehens im Vergleich zum Kopieren einer Konfigurationsdatei ist, dass sichergestellt ist, dass die Zeile in der Konfigurationsdatei vorhanden ist. ``` - name: Enable direnv lineinfile: path: ~/.zshrc line: eval "$(direnv hook zsh)" ``` ### Git Repos clonen und updaten Insbesondere wenn man mit vielen Repos Git Repositories arbeiten muss, weil man beispielsweise einem Poly Repo Ansatz folgt oder an unterschiedlichen Projekten arbeitet verliert man schnell den Überblick. Mit Ansible kann man dem ein bisschen Abhilfe schaffen, in dem man die Git Repos in einem eigenen Task oder Playbook verwaltet. Um Git Repos zu clonen und aktuell zu halten kann folgender Task definiert werden. Analog zu Homebrew Cask Installationen kann auch hier das `with_items` Feature verwendet werden. Zusätzlich sollte man zu diesem Task `ignore_errors` aktiviert werden, damit das Playbook nicht beendet wird sollte der Task fehlschlagen. ``` - name: Clone Miragon Git Repos git: repo: "git@github.com:Miragon/{{item}}.git" clone: yes update: yes dest: "~/source/miragon/{{item}}" ignore_errors: yes with_items: - code-examples ``` > Sobald Uncommited Changes im Repository sind oder der Branch auf dem man sich aktuell befindet nicht existiert schlägt der Task fehl und das Playbook wird abgebrochen, wenn `ignore_errors` nicht aktiviert ist. ## Ansible bei Miragon In den vorangegangenen Abschnitten habe ich einen kurzen Überblick über Ansible gegeben habe und erklärt welche Ansible Module und Tasks wir bei Miragon verwenden, um Software auf unseren Macs zu installieren, aktuell zu halten und Git Repositories zu clonen. An dieser Stelle soll es jetzt noch konkreter werden, in dem ich erkläre, wie unser aktuelles Mac Setup aufgebaut ist und wie wir es verwenden. Für unser Mac Setup verwenden wir [Roles](https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html). Aktuell haben wir die beiden Playbooks `initial.yml` und `site.yml`. > [Roles](https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html) in Ansible sind eine Möglichkeit wiederverwendbare Bausteine zu definieren. Zusätzlich geben Roles eine Struktur für den Quellcode vor, die den Code übersichtlicher und verständlicher macht. ### initial.yml für die Ersteinrichtung eines Macs Das Playbook `initial.yml` nutzen wir für die Ersteinrichtung eines neuen Macbooks. Hierbei wird die Role _mac_ auf jedem Mac und die Roles _macdev_ und _miragon_ zusätzlich nur auf Entwicklerpcs ausgeführt. ``` --- - hosts: - mac roles: - mac - hosts: - macdev roles: - macdev - miragon ``` Die Role _mac_ installiert mit Homebrew eine Auswahl an Standardprogrammen, die jeder von uns im täglichen Doing gebrauchen kann. Darunter fallen die Browser Firefox und Google Chrome, der Passwordmanager 1Password, die Office 365 Tools und der Window Manager Rectangle. Zusätzlich fügen wir auf dem Desktop des Users eine `links.txt` Datei hinzu mit den wichtigsten Links zu den Cloud Tools, die wir bei Miragon verwenden. ``` . ├── README.md ├── roles │   ├── acs │   │   ├── tasks │   │   └── vars │   ├── itm │   │   ├── tasks │   │   └── vars │   ├── mac │   │   └── tasks │   ├── macdev │   │   ├── files │   │   ├── tasks │   │   └── vars │   ├── miragon │   │   ├── tasks │   │   └── vars │   └── processide │   ├── tasks │   └── vars ├── initial.yml └── site.yml ``` Die Role _macdev_ funktioniert analog zur _mac_ Role. Sie installiert zusätzlich eine Auswahl an Software mit Homebrew, die die Entwickler für ihre tägliche Arbeit benötigen. Darunter fallen bekannte Commandline Tools wie z.B. curl, wget, direnv, maven, gradle und die kubernetes-cli. Zusätzlich installieren wir die Java jdks, die wir aktuell für unsere Anwendungen verwenden sowie den Nodejs Versions Manager nvm. Zudem führen wir auf Entwickler-PCs auch noch die Role _miragon_ aus. Diese fügt einige allgemeine Git Repositories von Miragon auf dem PC in dem Ordner `~/source/miragon/` hinzu. Darunter fällt unsere Miragon Website, Code Beispiele und Templates sowie user Ansible Mac Setup. ### site.yml für die alltägliche Nutzung Nachdem das Playbook `inital.yml` sehr viel Zeit bei der Ausführung in Anspruch nehmen kann, habe ich mich dazu entschlossen für die alltägliche Nutzung ein eigenes Playbook anzulegen. Diese Playbook ist die `site.yml` und dient dazu Homebrew sowie die installierten Pakete aktuell zu halten und für unsere verschiedenen Projekte die Git Repositories zur Verfügung zu stellen. ``` --- - hosts: - mac - macdev tasks: - name: Update homebrew homebrew: update_homebrew: true upgrade_all: true ignore_errors: yes - hosts: - macdev - miragon roles: - miragon - hosts: - acs roles: - acs - hosts: - itm roles: - itm - hosts: - processide roles: - processide ``` Auch wenn jeder Entwickler Zugriff auf die vollständige Code Base von Miragon hat, braucht nicht jeder alle Projekte auf seinem PC für die täglich Arbeit. Deswegen legen wir für jedes Projekt eine eigene Role mit dem Projektnamen sowie einen Task in der `site.yml` an. Um diese Role auszuführen muss der User nur noch eine Gruppe mit dem Projektnamen im Inventory anlegen. Dadurch kann jeder Entwickler selbst entscheiden, von welchen Projekten er die Git Repositories clonen möchte. > Bei der Landeshauptstadt München sind wir Teil eines Entwicklungsteams, das die Prozessautomatisierungsplattform DigiWF entwickelt. Du möchtest mehr über DigiWF erfahren, dann schau dir gerne unseren Blog Post zu [DigiWF bei der Landeshauptstadt München](https://www.miragon.io/blog/digiwf-landeshauptstadt-munchen/) an. Wenn beispielsweise ein Entwickler in unserm Kundenprojekt bei der Landeshauptstadt München startet, kann dieser folgende 2 Zeilen im Inventory hinzufügen und bekommt alle Repositories, die für das Projekt benötigt werden in den Ordner `~/source/miragon/itm/` gecloned. ``` [itm] localhost ansible_user= ansible_connection=local ansible_python_interpreter=python3 ``` Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fmac-einrichten-leicht-gemacht-ansible%2F)[](mailto:?subject=Mac%20einrichten%20leicht%20gemacht%20-%20mit%20Ansible&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fmac-einrichten-leicht-gemacht-ansible%2F) ## Lukas Mösle Consultant bei Miragon [in Lukas kennenlernen](https://www.linkedin.com/in/lukas-moesle) [Mehr von Lukas](/blog/?author=lukas-mösle) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Miragon 08\. Juni 2020 ### Mehr in weniger Zeit - mit den richtigen Tools Welche Tools wir bei Miragon verwenden, um effizient zu arbeiten - von Office 365 und Microsoft Teams bis hin zu GitHub und JetBrains. Alexander Praschek Co-Founder ](/blog/mehr-in-weniger-zeit-richtigen-tools/)[ Miragon 27\. Mai 2020 ### Vom Studenten zum Lehrbeauftragten Dominik Horn erzählt seinen Weg vom BPM-begeisterten Studenten über die IT-Beratung zur Gründung der Miragon GmbH und zum Lehrauftrag an der Hochschule Augsburg. Dominik Horn Co-Founder & Geschäftsführer ](/blog/vom-studenten-zum-lehrbeauftragten/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Mehr in weniger Zeit - mit den richtigen Tools](https://www.miragon.io/blog/mehr-in-weniger-zeit-richtigen-tools/) Miragon Welche Tools wir bei Miragon verwenden, um effizient zu arbeiten - von Office 365 und Microsoft Teams bis hin zu GitHub und JetBrains. Alexander Praschek Co-Founder **08\. Juni 2020**5 Min. Lesezeit Vor der Gründung unseres Unternehmens waren wir alle in verschiedenen anderen Firmen tätig. Eines hatten diese jedoch alle gemein: Die internen Abläufe waren langwierig und kompliziert, es waren für jeden Antrag unzählige Mails und Telefonate notwendig und für jedes Problem gab es mindestens zwei verschiedene Tools. Das verhindert ein effizientes Arbeiten, was insbesondere in kleinen Unternehmen und Start-Ups absolut überlebensnotwendig ist. Aus diesem Grund haben wir im Verlauf der letzten Monate viele verschiedene Tools ausprobiert. Mittlerweile sind wir mit unserer Auswahl sehr zufrieden. In diesem Artikel gehen wir genauer darauf ein, welche Tools wir wofür verwenden. Wir haben uns bewusst dafür entschieden, nur gehostete Anwendungen zu verwenden, da wir unsere begrenzten Ressourcen auf unser Kerngeschäft konzentrieren wollen und nicht unsere Zeit mit der Installation und der Konfiguration von Software verbringen wollen. ## Zusammenarbeit Auch wenn viele eine Abneigung gegenüber Microsoft hegen, so ist es aus unserer Sicht unstrittig, dass **Office 365** eine wirklich gute Lösung zu einem niedrigen Preis ist. Neben den bekannten Tools Word, Excel, PowerPoint und Outlook sind auch gehostete E-Mail-Postfächer sowie ausreichend Cloud-Speicher inklusive. ## Kommunikation Neben den bereits genannten Tools ist auch **Microsoft Teams** in Office 365 enthalten. Es ermöglicht unkomplizierte Chats sowie Telefon- und Videokonferenzen. Durch die Integration in Outlook ist es mit einem Klick erledigt, ein Meeting zu einem Termin hinzuzufügen. Es ist auf allen Plattformen verfügbar und bietet außerdem die Möglichkeit, zahlreiche Drittanbieter-Tools zu integrieren. Außerdem können beliebige Webanwendungen eingebunden werden, wodurch wir unsere Zeiterfassungssoftware mit nur einem Klick erreichbar machen konnten. ## Notizen Bisher waren Notizen meist auf viele verschiedene Orte verteilt. Hier ein Word-Dokument, dort ein Notizblock, da ein einfaches Textdokument. Obwohl es sicherlich zahlreiche gute Notizen-Apps gibt, haben wir uns für **OneNote** entschieden. Es ist ebenfalls plattformübergreifend verfügbar und erlaubt außerdem das gemeinsame Lesen und Bearbeiten einzelner Seiten. ## Aufgabenverwaltung Für das Sammeln, die Verteilung und das Tracken von Aufgaben gibt es eine Flut von Apps. Wir haben uns schließlich für **Microsoft To Do** entschieden, den Nachfolger des viel gelobten Wunderlist. Es bietet geteilte Aufgabenlisten, Zuweisungen und Fälligkeitsdaten. Auch verschiedene automatische Listen existieren. Wir nutzen allerdings nur einen kleinen Teil der Features. Wir verwenden dabei eine Abwandlung des **Eisenhower-Prinzips** in Verbindung mit Time Blocking. Neue Aufgaben landen auf der gemeinsamen Liste „Unkategorisiert“. Diese Liste gehen wir regelmäßig durch, legen fest, welche Aufgaben bis wann erledigt werden müssen und wer sich darum kümmert. Dann landen sie entweder in der Liste „Delegiert“, falls sich jemand anderes darum kümmert, oder in der Liste „Geplant“, wobei wir dann für die Aufgabe einen festen Block im Kalender reservieren. Ist die Aufgabe erledigt, wird sie abgehakt und verschwindet. ## Time Tracking Um unsere Zeiten zu tracken, verwenden wir **Clockify**. Es bietet die Möglichkeit, Kunden, Projekte und einzelne Tasks anzulegen, mit denen man den Zeitaufwand sehr gut verfolgen kann. Man erhält außerdem einen guten Überblick über die eigenen geleisteten Stunden. Nicht zu verachten sind außerdem die Möglichkeiten, Reports anzulegen, die wir unter anderem für die Abrechnung unserer Leistungen verwenden. Clockify ist zudem mit $10 bzw. $30 monatlich für unbegrenzte Nutzer sehr kostengünstig. ## Rechnungsstellung und Buchhaltung Für das Erstellen von Rechnungen und das Erfassen unserer Ausgaben verwenden wir **Debitoor**. Es bietet eine einfache Lösung, um die eigenen Aufwände zu kategorisieren und Auswertungen zu erstellen. Rechnungen können ebenfalls im Handumdrehen geschrieben werden und über die Integration des eigenen Bankkontos werden auch keine Abbuchungen vergessen. Der Steuerberater kann außerdem ebenfalls Zugriff auf die eigenen Daten haben, sodass alle Rechnungen nur einmal erfasst werden müssen. ## Cashflow-Planung Für kleine Unternehmen ist der Cashflow entscheidend. Offene Rechnungen an Kunden sind wertlos, wenn das eigene Konto leer ist und die Löhne nicht bezahlt werden können. Um solche Szenarien zu vermeiden, verwenden wir **Commitly**. Es erlaubt eine einfache Cashflow-Planung auf Basis der tatsächlichen Geldflüsse. Die einzelnen Transaktionen werden kategorisiert und es können geplante Einnahmen und Ausgaben inklusive des Stichtags erfasst werden. Daraus werden automatisch Pläne generiert, die tagesgenau den Kontostand vorhersagen. ## Passwort-Manager In der Presse ist regelmäßig von Datenschutzskandalen und Passwort-Leaks zu lesen. Bei der Vielzahl an Accounts ist es schlichtweg unmöglich, für jeden Zugang ein eigenes, starkes Passwort zu haben und sich jedes zu merken. Stattdessen wird irgendwann auf dasselbe Passwort zurückgegriffen oder die Passwörter werden schwach gewählt. Um dieses Problem zu vermeiden, verwenden wir **1Password** als Passwortmanager. Es ist für alle wichtigen Plattformen und Browser vorhanden und bietet viele Features zu einem geringen Preis. Jeder Benutzer erhält außerdem eine Familienlizenz zum privaten Gebrauch kostenfrei dazu. Neben einem privaten Tresor gibt es auch einen geteilten Tresor, sodass einzelne Passwörter einfach mit ausgewählten Personen und Gruppen geteilt werden können. Zudem funktioniert die Integration mit den verschiedenen Login-Formularen äußerst gut. ## Quellcodeverwaltung Für das Hosting unseres Quellcodes haben wir uns für **GitHub** entschieden. Neben dem reinen Speichern des Codes bietet es mit den Issues und den Projects gute Möglichkeiten, um Anforderungen und deren Umsetzung zu tracken. Der Zugang zu einzelnen Boards kann auch mit externen Auftraggebern geteilt werden. Zudem bietet GitHub mit Actions eine Möglichkeit, eigene Pipelines zu definieren, die z.B. automatisch neue Builds bauen und veröffentlichen, wenn ein neuer Commit gesetzt wird. [Mit GitHub Packages gibt es passend dazu ein Repository für Maven, NPM und Co. kostenlos dazu, die auch für private Packages verwendet werden kann.](/blog/devops-github-teil-1-packages-gradle/) Für das Hosting von Docker-Images verwenden wir jedoch DockerHub, da GitHub Packages nur begrenzten kostenlosen Speicherplatz bietet. ## Entwicklungsumgebung Zu Beginn verwendeten wir für die Entwicklung eclipse und Visual Studio Code. Wir hatten jedoch immer wieder Probleme mit verschiedenen Features. Das mag an unserer fehlenden Expertise gelegen haben, jedoch haben wir wie bereits eingangs erwähnt weder Zeit noch Lust, uns mit solchen Dingen herumzuschlagen. Deshalb haben wir uns schließlich für die IDEs von JetBrains entschieden. Auch wenn eclipse und VS Code sicherlich die meisten der Features ebenfalls anbieten, funktionieren sie bei **IntelliJ und WebStorm** out of the box. Die Software ist zwar verhältnismäßig teuer, dennoch sind wir der Meinung, dass es die gesparte Zeit wert ist. Zudem erhalten junge Unternehmen 50% Rabatt auf den normalen Preis. ## Fazit Wir haben in den letzten Monaten zahlreiche verschiedene Tools ausprobiert. Die oben aufgezählten sind die, die wir im Moment verwenden. Sie erlauben uns ein effizientes Arbeiten, ohne dass wir auf Komfort verzichten müssten. Wir sind sehr zufrieden mit dieser Auswahl, auch wenn es sicherlich zu jeder Anwendung gute Alternativen gibt, und können sie nur jedem ans Herz legen. Diese Liste wird sich sicherlich im Laufe der Zeit verändern und erweitern. Neue Tools werden hinzukommen und alte entfernt. Sollten sich große Veränderungen ergeben, werden wir dazu zu gegebener Zeit einen neuen Blog-Post verfassen. Bis zum nächsten Mal! _Also published in English at [medium.com](https://medium.com/@miragon/get-more-done-in-less-time-d725ade72a8?source=friends_link&sk=943e696121be984cf1eea96010259735)._ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fmehr-in-weniger-zeit-richtigen-tools%2F)[](mailto:?subject=Mehr%20in%20weniger%20Zeit%20-%20mit%20den%20richtigen%20Tools&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fmehr-in-weniger-zeit-richtigen-tools%2F) ## Alexander Praschek Co-Founder bei Miragon [in Alexander kennenlernen](https://www.linkedin.com/in/alexander-praschek/) [Mehr von Alexander](/blog/?author=alexander-praschek) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Miragon 11\. Okt. 2022 ### Mac einrichten leicht gemacht - mit Ansible Wie Ansible die Einrichtung und Wartung von MacBooks automatisiert - von Homebrew-Installation bis zur Verwaltung von Git-Repositories. Lukas Mösle Consultant ](/blog/mac-einrichten-leicht-gemacht-ansible/)[ Miragon 27\. Mai 2020 ### Vom Studenten zum Lehrbeauftragten Dominik Horn erzählt seinen Weg vom BPM-begeisterten Studenten über die IT-Beratung zur Gründung der Miragon GmbH und zum Lehrauftrag an der Hochschule Augsburg. Dominik Horn Co-Founder & Geschäftsführer ](/blog/vom-studenten-zum-lehrbeauftragten/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Miragon AI: Vom Cockpit zur Konversation](https://www.miragon.io/blog/miragon-ai-vom-cockpit-zur-konversation/) AI Wie wir bei Miragon Prozessautomatisierung neu denken: weg vom isolierten Cockpit, hin zur Konversation als Interface. Warum das MCP und MCP Apps das Fundament dafür bilden. Thomas Heinrichs Solution Architecture Lead **04\. Mai 2026**15 Min. Lesezeit Am 29. April durften [Dominik](https://www.linkedin.com/in/dominik-horn/) und ich am **Weizenbaum-Institut in Berlin** einen Vortrag halten. Geplant war er unter dem Titel _“Deterministische und Agentic Workflows. Wie wähle ich die richtige Variante?”_. Drei Monate nach der Planung des Vortrags war diese Frage in unseren Köpfen längst nicht mehr die spannendste, denn die AI-Welt war weitergezogen. Was uns in den Wochen davor eigentlich beschäftigt hatte, war eine andere Frage: **Wie machen wir AI für die Prozessautomatisierung wirklich zugänglich?** Nicht nur, indem wir AI aus Prozessen heraus nutzen, sondern auch andersherum gedacht: Wie kommen unsere Prozesse in die AI? Genau diese Perspektive haben wir in Berlin auf die Bühne gebracht. Für alle, die nicht dabei sein konnten oder noch tiefer einsteigen wollen, ist dieser Blogbeitrag genau das Richtige. ## Die Frage hat sich verschoben Als wir den Talk eingereicht haben, war Agentic Orchestration ein heißes Eisen. Hersteller wie Camunda und ServiceNow hatten gerade angekündigt, AI-Agenten in ihre Engines einzubetten, ohne den deterministischen Prozess zu beeinträchtigen. Der Prozess dient dabei als Leitplanke für die Agenten, sodass sie sich z. B. selbständig in einem Ad-hoc-Subprozess bewegen können. Drei Monate später ist genau das ein akzeptiertes Mittel der Wahl, und die alte Diskussion damit weitgehend abgeräumt. Klar sollte trotzdem immer hinterfragt werden, ob ein Agent wirklich notwendig ist oder ob sich das Problem nicht deterministisch und mit weniger Overhead lösen lässt. Aber diese Diskussion wollten wir nicht noch einmal aufwärmen, vor allem weil wir das größere Potential woanders sehen. Stattdessen interessierte uns eine Frage, die deutlich weniger beantwortet ist: > **Was passiert mit unserem Tooling, wenn die AI nicht mehr in den Prozess eingebettet wird, sondern der Prozess in die AI?** Das klingt nach einer rhetorischen Spielerei, ist es aber nicht. Um zu verstehen, warum das so ist, lohnt sich ein kurzer Blick in die Geschichte des Internets, denn AI macht gerade exakt dieselbe Bewegung durch. ## Vom “AI im Tool” zum “Tool in der AI” ### Phase 1: Pro Online-Dienst eine eigene Software Wer in den späten 90ern online war, hat das Internet nicht über einen offenen Browser betreten, sondern über die Software seines Anbieters. T-Online lieferte ein eigenes StartCenter aus, AOL den AOL-Client. Das Internet kam gewissermaßen huckepack mit dem Tool, das man installiert hatte. Wer wechselte, wechselte die ganze Welt. ### Phase 2: Der Browser als Universalwerkzeug Mit Netscape und später dem Internet Explorer entstand eine neutrale Laufzeit für alle Inhalte. Der Browser kannte das eigentliche Ziel nicht, sondern stellte nur dar, was eine beliebige Website lieferte. Anbieter mussten ihr Internet nicht mehr mitliefern. Sie integrierten ihre Inhalte in das Internet, das es jetzt unabhängig von ihnen gab. ### Phase 3: Fast jede Anwendung ist eine Webanwendung Spotify, Slack, Notion, Figma, Teams. Selbst was wie eine native Desktop-App aussieht, ist im Kern eine Webanwendung. Die Frage, ob ein Anbieter sein eigenes Browser-Frontend ausliefert, stellt sich gar nicht mehr. Browsertechnologie ist Commodity. ### Der Link zur AI Genau dieses Muster sehen wir gerade mit AI, nur deutlich schneller. Die ersten Versuche bestanden darin, AI in das eigene Produkt zu integrieren. Camunda baute “Generate with AI”-Buttons in den Web Modeler, jedes SaaS-Tool bekam einen Chat-Assistenten unten rechts. Inzwischen zeichnet sich aber eine Gegenbewegung ab. Noch ist sie ein Rand-Phänomen, gewinnt aber spürbar an Traction und wird absehbar Fahrt aufnehmen: Erste Hersteller integrieren nicht mehr AI in ihr Produkt, sondern ihr Produkt in den AI-Client. Der Client, in dem ohnehin schon gearbeitet wird, wird damit zum neuen Interface. Salesforce hat im April beispielsweise mit _[Headless 360](https://www.salesforce.com/news/stories/salesforce-headless-360-announcement/)_ das erste CRM angekündigt, das nur noch über API, MCP und CLI zugänglich ist, ohne mitgelieferte Oberfläche. _“Why should you ever log into Salesforce again?”_ fragt Co-Founder Parker Harris. Nicht als Provokation, sondern als Richtungsentscheidung. Wenn diese Vision aufgeht, gilt sie genauso für Process Engines und die Tools drumherum: Cockpit, Tasklist, Monitoring und Reporting. ## Das Problem mit dem klassischen Tooling Schauen wir uns den Status quo der Prozessautomatisierung an. Im Zentrum steht die Engine. Drumherum: **Cockpit** für Operations, **Tasklist** für die Abarbeitung von User-Tasks, **Dashboards** fürs Management, **Monitoring** für Development und Ops. Vier Rollen, vier Oberflächen, vier Lernkurven. Sobald etwas nicht nach Plan läuft, springen alle Beteiligten zwischen den Tools, um sich Kontext zusammenzusuchen. Daten der Umsysteme wie CRM, Fachsystem oder Identitätsmanagement fehlen ohnehin und müssen zusätzlich noch reingeholt werden. Die Engine ist, was Daten und Co. angeht, quasi isoliert. Sie orchestriert zwar, aber für den gesamten Überblick reicht das nicht. Das ist auch ein wesentlicher Grund, warum der BPM-Lifecycle in vielen Organisationen nicht wirklich gelebt wird. Iterative Optimierung scheitert oft schlicht an der Datenfragmentierung und an der Reibung im Tooling. Schnell reicht z. B. [Camunda Optimize](https://camunda.com/platform/optimize/) allein nicht mehr aus, sondern es braucht zusätzlich [Tableau](https://www.tableau.com/) und Co., um die Daten der Process Engine mit denen aus anderen Fachsystemen zu kombinieren. Unsere These, um genau diese Schmerzen zu lindern, ist daher: **Den Prozess zur AI bringen.** Wir verlagern die Interaktion mit dem Prozess dorthin, wo Wissensarbeit ohnehin schon stattfindet: in den AI-Client. Das Interface ist dann die Konversation selbst. Kein zusätzliches Feature in der Engine, sondern eine vollständige Interaktionsschicht über die Rollen hinweg. Genau diese Schicht haben wir mit **Miragon AI** gebaut. Wie sie technisch funktioniert, schauen wir uns als nächstes an. ## Die Technologie hinter der Interaktionsschicht Die Architektur ist bewusst schlank. Im Zentrum steht ein beliebiger MCP-fähiger LLM-Client, also Claude, ChatGPT oder was im Team ohnehin schon im Einsatz ist. Über das **Model Context Protocol (MCP)** sprechen wir die Process Engine, Fachsysteme, Stammdaten und beliebige weitere Quellen an. Die Engine selbst bleibt unverändert. ### Exkurs: Was ist MCP? Das [Model Context Protocol](https://modelcontextprotocol.io/) ist ein offener Standard, der von Anthropic initiiert wurde und mittlerweile von Claude, ChatGPT und vielen weiteren Clients unterstützt wird. Man kann es sich vorstellen wie _USB-C für AI-Anwendungen_: Statt für jede Integration einen eigenen Adapter zu bauen, sprechen Client und Datenquelle ein gemeinsames Protokoll. Ein **MCP-Server** stellt einer LLM-Anwendung dabei drei Dinge bereit: - **Tools**: ausführbare Funktionen, etwa _“Incident lösen”_ oder _“Prozessdefinition starten”_. - **Resources**: lesbare Daten wie XML-Modelle oder Stammdaten. - **Prompts**: vorgefertigte Anweisungen für wiederkehrende Aufgaben. Der Client entdeckt diese Fähigkeiten zur Laufzeit und stellt sie dem LLM zur Verfügung, ohne dass das anbindende System an einen bestimmten AI-Anbieter gebunden ist. ### Mehrere Systeme in einem Chat zusammenführen Diese Architektur eröffnet einen weiteren Hebel: Wir können beliebige Systeme anbinden. Mit Miragon AI haben wir ein Framework, um mehrere MCP-Server zu kombinieren. So greifen wir nicht nur auf die Daten einer Engine zu, sondern auch auf die anderer Systeme. Der AI-Agent kann diese Daten dann miteinander korrelieren. Auf dieser Basis bieten wir drei rollenspezifische Profile an: - **Insight** für das Management. Dashboards, Kennzahlen, Trends. - **Pulse** für Operations. Live-Status, Incidents, Eskalationen. - **Resolve** für Development und Modellierung. Diff, Refactoring, Debugging. Die Profile sind im Wesentlichen kuratierte Prompt-Bündel mit Tool-Berechtigungen. Kein neuer Client, kein neues Frontend. ### Wenn Text nicht reicht: MCP Apps So weit, so MCP. Was MCP allein **nicht** löst: Wie zeige ich dem Nutzer eine UI, die mehr ist als Text? Ein Dashboard, eine Heatmap, ein Diff. Genau diese Lücke schließt **MCP Apps**, ein neuer Standard, der die MCP-Spezifikation um interaktive UIs erweitert. Mit einem einzigen Tool-Call entsteht eine vollwertige, interaktive Oberfläche im Chat. Kein Aneinanderreihen von fünf Tool-Calls, kein wiederholtes Output-Auswerten. Genau das ist für Analyse-Use-Cases entscheidend, in denen Latenz alles ist. Der Standard lebt im Repository [`modelcontextprotocol/ext-apps`](https://github.com/modelcontextprotocol/ext-apps/) (daher die Kurzform “ext-apps”) und wird inzwischen von Claude, ChatGPT und weiteren Clients unterstützt. Technisch greifen vier Schritte ineinander: 1. **Tool-Definition.** Ein MCP-Tool deklariert eine `ui://`\-Resource, in der eine HTML/JS-Oberfläche steckt. 2. **Tool-Call.** Das LLM ruft das Tool auf dem Server auf. 3. **Host rendert.** Der Chat-Client holt sich die Resource und rendert sie in einer **sandboxed iframe** direkt in der Konversation. 4. **Bidirektionale Kommunikation.** Der Host reicht Tool-Daten per Notification an die UI, die UI kann ihrerseits über den Host weitere Tools aufrufen. Wie sich das in der Praxis anfühlt, zeigen wir am Beispiel eines fiktiven Kunden. ## Szenario: Bike-Leasing bei MiraVelo > **MiraVelo** baut und vertreibt Fahrräder selbst und bietet sie zusätzlich als Leasing an. Wir betrachten den **Leasing-Prozess**: vom eingehenden Antrag bis zur Bewilligung oder Ablehnung. Der Prozess startet mit dem Leasing-Antrag eines Kunden. Im besten Fall läuft er **dunkelverarbeitet** durch: Stammdaten werden aus dem CRM gezogen, der Bonitätscheck ist in Ordnung und die Police verschickt. Schlägt der Bonitätscheck fehl oder werden Risiken identifiziert, übernimmt ein menschlicher Sachbearbeiter die Entscheidung über Bewilligung oder Ablehnung. Bleibt eine solche Entscheidung länger als zwei Stunden liegen, wird der zuständige Manager benachrichtigt und kann nachsteuern. Wir haben hier also eine Mischung aus User Tasks, Service Tasks und einer Call Activity für die Bonitätsprüfung. Damit ist der Prozess repräsentativ für viele BPMN-Modelle, die wir in Kundenprojekten sehen. Anhand dieses Beispiels wollen wir nun den **BPM-Lifecycle** mit Miragon AI durchlaufen und schauen, wo das Potential liegt. Die Implementierungsphase überspringen wir bewusst. Dort gibt es bereits viel funktionierendes Tooling, und unsere Wette liegt auf den anderen drei Phasen. ## Model: Live-Feedback im BPMN iQ Modeler Bevor MiraVelo überhaupt mit der Modellierung startet, sitzen Fachbereich und Entwicklung in mehreren **Collaborative-Modeling-Workshops** zusammen. Dort werden Scope und Abgrenzungen festgelegt, Begriffe definiert und alle Stakeholder auf einen gemeinsamen Stand gebracht. Erst wenn dieses Fundament steht, läuft die anschließende Detailmodellierung auch in die richtige Richtung. Auf dieser Basis übersetzt ein Entwickler den Prozess im **BPMN iQ Modeler** in eine erste ausführbare BPMN-Version und gibt per Klick auf _Share_ einen Link an den Fachbereich weiter. Dieser kommentiert direkt im Diagramm, etwa an der Bonitätsprüfung, die als eigener Subprozess `miravelo-creditworthiness` modelliert ist. Während die Stakeholder kommentieren, arbeitet ein AI-Agent im Hintergrund die offenen To-Dos an der XML-Repräsentation ab: etwa eine vollständige Übersetzung des Prozesses ins Deutsche, eine Vereinheitlichung der Activity-Namen oder das Einsetzen passender Listener. Der Entwickler reviewt die Änderungen unter anderem mit Hilfe einer Diff-Ansicht. Der Fachanwender sieht im Gegenzug direkt, welche Auswirkungen seine Kommentare auf den Prozess haben. Das Feedback, das wir auf diese Weise im Modeler einarbeiten, betrifft nur noch Details, die sich ohne erneuten Workshop ergänzen lassen. Die Grundsatzentscheidungen sind vorher in den Workshops gefallen, und gerade durch den Einsatz von AI werden diese sogar wichtiger: Sie setzen das Fundament, auf dem die nachgelagerte AI-Arbeit überhaupt zielgerichtet bleibt. ## Execute: Incident-Analyse direkt im Chat Der Leasing-Prozess läuft inzwischen produktiv. Eines Morgens häufen sich plötzlich die Beschwerden: Kundenanträge bleiben offenbar irgendwo im Prozess hängen. Statt sich ins Cockpit einzuloggen und sich durch drei Reiter zur richtigen Definition zu klicken, genügt im Chat die Frage: _“Zeig mir das Incident-Dashboard.”_ Die AI ruft den Analytics-Server auf, aggregiert Daten über Engine und Fachsysteme hinweg und liefert eine kompakte ext-app zurück: Aus dieser Übersicht lässt sich direkt in die betroffene Prozessdefinition oder in eine einzelne Instanz drillen. Lässt sich das Problem unmittelbar in der Engine beheben, kann der Operations-Verantwortliche den Incident aus derselben Oberfläche heraus auflösen. Stellt sich heraus, dass ein Eingriff durch die Entwicklung erforderlich ist, lässt sich per weiterem Tool-Call am angebundenen GitHub direkt ein Ticket mit den entsprechenden Informationen erstellen, ohne den Chat zu verlassen. Das erstellte Issue greift der Entwickler (bzw. dessen Coding-Agent) dann direkt auf und löst es. ## Optimize: Dashboards, Heatmaps und Versionsvergleich Operations kümmert sich jeden Tag um den stabilen Betrieb des Prozesses, aber die spannendere Frage kommt danach: _Warum_ hängt der Leasing-Prozess regelmäßig an dieser Stelle? Welche Pfade laufen häufig, welche selten? Welche Modellversion war eigentlich besser? Genau hier setzen die analytischen Funktionen von Miragon AI an. > **Hinweis zu den Screenshots:** Die Werte in den folgenden Oberflächen basieren auf synthetischen Demo-Daten. Einzelne Zahlen können daher fachlich unlogisch oder inkonsistent wirken. Entscheidend ist hier nicht der konkrete Wert, sondern die Art der Interaktion und die Darstellung im AI-Client. ### Dashboards im Dialog bauen Der Stakeholder beschreibt im Chat, was er sehen will. Die AI generiert eine passende UI und rendert sie inline. Iterieren funktioniert genauso direkt. Ein Folgeprompt wie _“Füge mir noch einen weiteren Tab hinzu, damit ich die letzten 7 Tage mit den letzten 30 Tagen vergleichen kann.”_ erweitert die bestehende ext-app, ohne sie neu zu bauen. Reicht der Dialog im Chat für die Feinjustierung nicht, geht es per **Build-Modus** weiter. In einer Drag-and-Drop-Oberfläche mit Widget-Katalog lassen sich Tabs, Reihen und einzelne Widgets gezielt anordnen oder austauschen, immer auf derselben Daten-Pipeline, die auch die ext-app im Chat nutzt. Der Unterschied zu einem klassischen Setup, in dem fünf Tool-Calls nacheinander aufgerufen und die Ergebnisse vom LLM zusammengetragen werden: Wir definieren in **einer einzigen Pipeline**, welche Daten wann aus welchem System extrahiert werden, um daraus die passenden Widgets zu befüllen. Das macht selbst komplexere Analysen interaktiv, schnell und nicht nur theoretisch agentic. ### Aus der Analyse ein wiederverwendbares Werkzeug machen Das eigentlich Spannende kommt danach: Das Dashboard lässt sich **abspeichern**. Beim Speichern wird eine ID vergeben, das gespeicherte JSON-Konstrukt landet im MCP-Backend. Will der Manager dieselbe Sicht später erneut öffnen, genügt eine kurze Chat-Nachricht mit dieser ID. Die Oberfläche wird dann mit frischen Daten direkt aus der Engine gerendert. So entsteht aus jeder einmaligen Analyse ein wiederverwendbares Werkzeug. Über [Routinen in Claude](https://www.anthropic.com/news/projects-and-routines) lassen sich diese Reports zusätzlich automatisiert in regelmäßigen Abständen ausführen und zustellen. ### Heatmaps und Pfadanalysen Wo verbringen die Leasing-Instanzen die meiste Zeit? Welche Pfade durch das BPMN-Diagramm werden tatsächlich genutzt? Das schreit fast nach einer Heatmap. Auch die lässt sich als gerenderte UI direkt in den Chat zurückgeben. Die Heatmap legt die Pfadfrequenz auf das tatsächliche Diagramm. Modellnah, sofort interpretierbar, keine Übersetzung nötig. ### Versionsvergleich von BPMN-Modellen Eine Frage wie _“Welche Prozessversion war die bessere?”_ führt zu einem tabellarischen Vergleich von Failure Rate, Incident Rate und Durchlaufzeiten, inklusive Hypothese, warum sich die Werte verändert haben. Im Beispiel: Eine restriktivere Bonitätsprüfung führt mehr Fälle in den manuellen Pfad und verlängert das 95. Perzentil deutlich. Auf Basis der Laufzeitdaten lassen sich darüber hinaus Optimierungsvorschläge durchsimulieren. Zum Beispiel: Was passiert, wenn ich eine weitere Bedingung an meinem Exclusive Gateway hinzufüge? Wie wirkt sich das auf die Durchlaufzeit aus? Werden die Mitarbeiter im Prozess dadurch entlastet? ### Zurück in den Modell-Zyklus Die gewonnenen Erkenntnisse aus der Optimize-Phase, etwa neue Bedingungen, geänderte Reihenfolgen oder ein zusätzlicher Pfad, landen wieder im **BPMN iQ Modeler** und damit am Anfang des Lifecycles. Aus der Analyse wird wieder ein Modell, der Loop schließt sich. ## Bringt eure Prozesse in den Chat Die Verschiebung des Interface ist aus unserer Sicht die deutlich größere Veränderung als ein AI-Agent im Prozess. Genau deshalb bauen wir bei Miragon unser AI-Tooling in diese Richtung auf. Wir wollen unseren Kunden nicht nur bei der Beratung und Umsetzung von Prozessen helfen, sondern sie auch befähigen, auf eine ganz neue Art und Weise mit Prozessen umzugehen, um noch mehr Potential aus diesen herauszuholen. Die vorgestellten Tools sind dabei nur der Anfang. Sie werden weiter ausgearbeitet und mit dem Feedback unserer ersten Kunden weiterentwickelt. Das Ziel: Prozessautomatisierung dort verfügbar machen, wo ohnehin schon gearbeitet wird, also im AI-Client. Welcher Client das ist, entscheidet das Team. Alle gezeigten Screenshots stammen aus der Claude Desktop App, weil wir intern dort am häufigsten arbeiten. Da Miragon AI aber auf reinem MCP und MCP Apps aufsetzt, läuft dieselbe Funktionalität genauso in der Claude-Mobile-App auf dem Handy oder in einem anderen Frontier-Model-Client wie ChatGPT von OpenAI. Mit ersten Kunden bringen wir Miragon AI bereits in die Praxis und etablieren [diese Funktionalität in echten Automatisierungsumgebungen](/portfolio/ki-integration/). Wenn euch das interessiert und ihr eure Prozesse in den Chat holen wollt, gibt es zwei Wege: Schaut auf [miragon.ai](https://www.miragon.ai/) vorbei und tragt euch ein, wenn ihr auf dem Laufenden bleiben oder in einem Deep Dive mehr über das Tooling und die Einsatzmöglichkeiten erfahren wollt. Oder einfach Hallo sagen, bei [Dominik](https://www.linkedin.com/in/dominik-horn/) oder [mir](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/) auf LinkedIn. Wir freuen uns auf den Austausch. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fmiragon-ai-vom-cockpit-zur-konversation%2F)[](mailto:?subject=Miragon%20AI%3A%20Vom%20Cockpit%20zur%20Konversation&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fmiragon-ai-vom-cockpit-zur-konversation%2F) ## Thomas Heinrichs Solution Architecture Lead bei Miragon [in Thomas kennenlernen](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/) [Mehr von Thomas](/blog/?author=thomas-heinrichs) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben](https://www.miragon.io/blog/modularer-monolith-camunda-7-statt-microservices/) Softwareentwicklung Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant **31\. März 2026**5 Min. Lesezeit **Original:** [LinkedIn-Artikel](https://www.linkedin.com/pulse/warum-wir-uns-gegen-microservices-und-f%25C3%25BCr-einen-modularen-lukas-m%25C3%25B6sle-hbikf/?trackingId=Ok95RaCN76eWefljnsoojQ%3D%3D). **Englische Version:** [Medium-Artikel](https://medium.com/@lmoesle/why-we-chose-a-modular-monolith-with-camunda-7-instead-of-microservices-e44e37648664). In meinem letzten Kunden-Projekt bei einer staatlichen Organisation standen wir vor einer Situation, die in vielen Digitalisierungsprojekten ähnlich ist. Es gibt ein kleines, motiviertes Projektteam, aber nur begrenzte Kapazitäten auf Kundenseite. Gerade bei der Automatisierung von Verwaltungsprozessen ist das ein entscheidender Faktor. Die Herausforderung besteht nicht nur darin, Prozesse fachlich korrekt abzubilden, sondern sie auch mit vertretbarem Aufwand produktiv zu betreiben und über mehrere Jahre weiterzuentwickeln. Gleichzeitig war früh klar, dass zusätzliche Infrastruktur keine realistische Option ist. Komplexe Plattform-Komponenten erzeugen Betriebs- und Abstimmungsaufwände, die das Projektteam weder fachlich noch organisatorisch sinnvoll hätte tragen können. Wir mussten also eine Lösung finden, die ein kleines Team eigenständig entwickeln, ausrollen und weiterentwickeln kann. ## Worauf wir optimiert haben Unsere wichtigste Zielgröße war eine kurze Time-to-Value. Das Projekt sollte nicht erst nach langer Vorarbeit einen Nutzen erzeugen, sondern möglichst schnell erste Prozesse automatisieren. Gerade in einem Umfeld mit begrenzten Kapazitäten ist das wichtig, weil frühe Ergebnisse Vertrauen schaffen und den Weg für weitere Prozesse ebnen. Genauso wichtig war Team-Autonomie. Wir wollten die Abhängigkeit von zusätzlicher Infrastruktur und komplexen Betriebsmodellen so klein wie möglich halten. Ein kleines Team kann viel erreichen, wenn es seinen Tech-Stack vollständig versteht und selbst beherrschen kann. Es wird aber schnell ausgebremst, wenn jede technische Entscheidung neue Plattformen, Spezialwissen oder zusätzliche Betriebsverantwortung nach sich zieht. Der dritte Optimierungsfaktor war Flexibilität. Die Lösung sollte nicht nur kurzfristig funktionieren, sondern auch später anpassbar bleiben. Dazu gehört für uns vor allem die Trennung von Fachlichkeit und Technik sowie die Möglichkeit, technische Komponenten bei Bedarf auszutauschen, ohne die gesamte Anwendung neu denken zu müssen. ## Unsere Architektur Auf dieser Basis haben wir uns für einen modularen Monolithen (einen Modulithen) im Backend sowie ein React-Frontend entschieden. Im Backend lief eine Spring-Boot-Anwendung mit eingebetteter Workflow-Engine. Diese Betriebsform war für uns ein guter Kompromiss zwischen fachlich sauber strukturiert, aber operativ deutlich einfacher beherrschbar als ein verteiltes Setup mit mehreren eigenständigen Services und zusätzlichen Infrastruktur-Komponenten. Für die fachliche Zusammenarbeit war BPMN ein zentraler Baustein. Mit BPMN konnten wir Prozesse gemeinsam mit den Fachabteilungen modellieren und anschließend in der Camunda 7 Engine automatisieren. Genau dieses Biz-Tech-Alignment war für uns wichtig, um die Anforderungen an den jeweiligen Anwendungsfall zu verstehen. Der Prozess sollte nicht in einem Fachkonzept beschrieben und später separat implementiert werden, sondern als gemeinsames Artefakt zwischen Fachbereich und Entwicklung dienen. Die fachliche Struktur der Anwendung haben wir mit DDD abgebildet. Das war im staatlichen Kontext besonders hilfreich, weil Regeln, Begriffe und Abläufe sehr stark von der jeweiligen Domäne geprägt sind. Statt eine generische Plattform zu bauen, die alle Fälle irgendwie abdeckt, haben wir die Fachlichkeit explizit in der Anwendung modelliert. Jede Domäne bekam dafür ihr eigenes Modul im Modulithen. Ergänzt wurde die fachliche Struktur mit DDD durch eine hexagonale Architektur, die dabei hilft die Domäne vor technischen Details zu schützen und Infrastruktur sauber über Ports und Adapter zu abstrahieren. Das macht die Anwendung verständlicher und reduziert die Gefahr, dass fachliche Logik über Zeit mit Framework-, Datenbank- oder Integrationscode vermischt wird. Ein besonders wichtiger Punkt war für uns außerdem die Abstraktion der Workflow-Engine. Um schnell Ergebnisse liefern zu können haben wir bewusst auf eine Camunda 7 Engine gesetzt. Die technischen Abhängigkeiten zur Engine haben wir über die Process-Engine-API Bibliothek der BPM-Crafters gekapselt. Damit haben wir die Kopplung an eine konkrete Engine bewusst reduziert, um eine technische Austauschbarkeit zu gewährleisten und einen Wechsel der Engine zu erleichtern. ## Trade-offs Die Wahl von Camunda 7 war eine bewusste Trade-off-Entscheidung. Uns war klar, dass Camunda 7 sich dem End of Life nähert. Der Kunde war skeptisch gegenüber Software as a Service Lösungen und gleichzeitig war ein On-Premise-Betrieb von Camunda 8 im Kontext des Projekts nicht realistisch, weil dafür zusätzliches Betriebs-Know-how und Infrastruktur-Kapazität nötig gewesen wären. Die Nachhaltigkeit der Camunda 7 Forks war zu Projektstart noch nicht absehbar. Wir haben deshalb die für das Projekt pragmatischere Lösung gewählt und gleichzeitig mit hexagonaler Architektur und der Process-Engine-API dafür gesorgt einen späterer Austausch der Engine nicht unnötig zu erschweren. Ein weiterer Trade-off ergibt sich aus dem Modulithen selbst. Obwohl die Domänen fachlich klar getrennt sind, betrifft jeder Release weiterhin das gemeinsame Backend-Artefakt. Das reduziert die operative Komplexität, bedeutet aber auch, dass Releases über Domänengrenzen hinweg koordiniert werden müssen. Ein schlanker gemeinsamer Release-Prozess ist damit kein Nice-to-have, sondern Voraussetzung. Dazu kommt, dass sich einzelne Module nicht unabhängig voneinander skalieren lassen. Solange die Domänen ähnliche Lastprofile haben, ist das in vielen Fällen unkritisch. Wenn sich diese Profile stark unterscheiden, wird eine gemeinsame Deployment-Einheit aber schnell zum Nachteil. Darüber hinaus haben wir uns bewusst gegen eine generische Prozessautomatisierungs- bzw. Low-Code-Plattform entschieden. Das erhöht den Entwicklungsaufwand, weil neue Anforderungen aktiv umgesetzt werden müssen. Im Gegenzug haben wir deutlich mehr Präzision in der Umsetzung und stoßen seltener an Grenzen, die bei generischen Tools oder Low-Code-Ansätzen schnell sichtbar werden. ## Wann anders entscheiden Diese Architektur ist nicht universell richtig. Ich würde anders entscheiden, wenn viele unabhängige Teams parallel Prozesse entwickeln, wenn Domänen sehr unterschiedliche Skalierungsprofile haben oder wenn unabhängige Deployments zwingend notwendig sind. Auch stark voneinander abweichende Release- und Freigabeprozesse zwischen Domänen sprechen eher gegen ein gemeinsames Backend-Artefakt. Ebenso würde ich einen anderen Ansatz wählen, wenn Citizen Developer Prozesse eigenständig umsetzen sollen. Dann verschieben sich die Optimierungsziele von fachlich präziser codebasierter Umsetzung durch ein Entwicklungsteam hin zu stärker standardisierten Plattform- und Self-Service-Ansätzen. Für den Kontext des Projekts war der gewählte Stack für uns trotzdem die richtige Entscheidung. Nicht, weil dieser in der Theorie am elegantesten war, sondern weil er zur Realität des Projekts gepasst hat: kleines Entwicklungsteam, begrenzte Infrastruktur, hohe fachliche Anforderungen und der Wunsch, schnell Mehrwert zu schaffen. Wenn ihr schon einmal zwischen fachlicher Flexibilität, geringer Betriebs-Komplexität und technologischer Zukunftssicherheit abwägen musstet, würde mich eure Erfahrung interessieren. Welche Trade-offs haben sich in euren Projekten als richtig herausgestellt und welche eher nicht? Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fmodularer-monolith-camunda-7-statt-microservices%2F)[](mailto:?subject=Warum%20wir%20uns%20gegen%20Microservices%20und%20f%C3%BCr%20einen%20modularen%20Monolithen%20mit%20Camunda%207%20entschieden%20haben&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fmodularer-monolith-camunda-7-statt-microservices%2F) ## Lukas Mösle Consultant bei Miragon [in Lukas kennenlernen](https://www.linkedin.com/in/lukas-moesle) [Mehr von Lukas](/blog/?author=lukas-mösle) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 01\. Dez. 2025 ### Leveling up! Wie du die Herausforderung verteilter Transaktionen in Zeebe lösen kannst Ein umfassender Guide zu verteilten Transaktionen in Zeebe: Von Phantom-Instanzen über das Outbox Pattern bis hin zu Idempotenz und SAGA. Marco Schäck Process Development Lead ](/blog/leveling-up-verteilte-transaktionen-zeebe/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Nachvollziehbare Test-Coverage für alle Prozess-Stakeholder](https://www.miragon.io/blog/nachvollziehbare-test-coverage-prozess-stakeholder/) BPM FlowCov macht die Testabdeckung von BPMN-Prozessen für alle Stakeholder sichtbar und nachvollziehbar - integriert in die Build-Pipeline. Dominik Horn Co-Founder & Geschäftsführer **18\. Sep. 2020**3 Min. Lesezeit Ursprünglich am 18.09.2020 auf dem offiziellen Camunda Blog gepostet: [https://camunda.com/blog/2020/09/traceable-test-coverage-for-all-process-stakeholders/](https://camunda.com/blog/2020/09/traceable-test-coverage-for-all-process-stakeholders/) In der Softwareentwicklung ist die Testabdeckung ein wichtiger Indikator für die Qualität einer Anwendung. Nur durch flächendeckendes und systematisches Testen können Fehler frühzeitig erkannt und behoben werden. Aus diesem Grund gibt es für nahezu jede Programmiersprache zahlreiche Testbibliotheken. Unter Java ist JaCoCo eine sehr bekannte Lösung für das Reporting der Test-Coverage. Um die Testabdeckung für alle Stakeholder sichtbar und nachvollziehbar zu machen, gibt es Tools, die in einem zweiten Schritt die generierten Coverage-Reports aufbereiten und übersichtlich darstellen. Darunter fallen etwa SonarQube oder Codecov. Durch einen automatischen Upload der Reports kann die Berechnung der Testabdeckung in die Build-Pipeline integriert werden. BPMN ist technisch betrachtet ebenso eine Programmiersprache, auch wenn sie ein anderes Ziel verfolgt und andere Stakeholder anspricht. Aus diesem Grund ist es auch bei automatisierten BPMN-Prozessen wichtig, [eine hohe Testabdeckung zu erreichen](/blog/testabdeckung-prozesse-messen/). Hierfür gibt es bereits ein Tool, welches die Berechnung der Test-Coverage erlaubt: Camunda BPM Test Coverage ([https://github.com/camunda/camunda-bpm-process-test-coverage](https://github.com/camunda/camunda-bpm-process-test-coverage)). Diese Bibliothek erzeugt aus Testfällen automatisch eine grafische Darstellung der Testabdeckung in Form von HTML-Dateien. Die Bereitstellung dieser Berichte für die unterschiedlichen Stakeholder, insbesondere für die fachlichen Prozessexperten, ist aufgrund des statischen Formats jedoch äußerst schwierig. In verschiedenen Kundenprojekten hatten wir darüber hinaus immer wieder mit zusätzlichen Anforderungen zu kämpfen, die damit ebenfalls nicht umzusetzen waren: - Freigabe neuer Prozessversionen durch Prozessverantwortliche - Kollaboration und Transparenz gegenüber allen Stakeholdern - Nachvollziehbarkeit und Historie der Testabdeckung - Anreicherung der Reports mit eigenen Daten - Darstellung nach Commits und Branches Aus diesen Gründen haben wir FlowCov entwickelt – eine Plattform, die genau diese Anforderungen abdeckt. Sie ermöglicht es, im Rahmen der eigenen Build-Pipeline die generierten Reports hochzuladen, um sie grafisch aufzubereiten und allen Stakeholdern zugänglich zu machen. Bei der Entwicklung war es uns wichtig, dass die Struktur sich an der bekannten Arbeitsweise mit Git orientiert. Aus diesem Grund gibt es auch in FlowCov Repositories, Branches und Commits. Zu jedem Commit können Reports hochgeladen werden, die die Testabdeckung zum entsprechenden Zeitpunkt darstellen. Am Ende lässt sich so ein Überblick über die Entwicklung der Coverage schaffen. Dabei lässt sich die Testabdeckung nicht nur auf Commit-Ebene anzeigen, sondern sogar zu einzelnen Modellen, Testklassen und Methoden. Der Einstieg in FlowCov ist sehr einfach und lässt sich in vier Schritten zusammenfassen: - Neuen Account unter [https://app.flowcov.io/](https://app.flowcov.io/) anlegen - FlowCov-Repository anlegen - Die FlowCovCoverageRule statt der ProcessCoverageRule verwenden - Die Reports mit unserem Bash-Skript lokal oder im Rahmen der Build-Pipeline hochladen Eine Schritt-für-Schritt-Anleitung haben wir unter [https://flowcov.io/docs](https://flowcov.io/docs) veröffentlicht. Ein ausführliches Beispiel inklusive GitHub-Action-Pipeline ist unter [https://github.com/Nlea/NY-Cheesecake-process](https://github.com/Nlea/NY-Cheesecake-process) zu finden. FlowCov ist momentan in einer öffentlichen Beta-Version verfügbar. Unser Ziel ist es, eine Plattform zu schaffen, die alle Stakeholder in die Entwicklung und insbesondere in die Qualitätssicherung bei der Implementierung von Prozessen einbezieht. Damit stellt FlowCov ein weiteres Tool für die kollaborative Prozessentwicklung sein. Um dieses Ziel zu erreichen und dabei auch die Ideen der Community zu berücksichtigen, werden wir FlowCov dauerhaft kostenlos in der Cloud zur Verfügung stellen. Um auch die höchsten Datenschutzanforderungen erfüllen zu können, ist außerdem eine On-Premise-Installation im eigenen Rechenzentrum möglich. Eine separat gehostete (dedicated) Installation in der Cloud ist ebenfalls verfügbar. Wir arbeiten ständig daran, FlowCov zu verbessern und neue Features hinzuzufügen. Bei Fragen, Ideen oder Feedback sind wir jederzeit in unserem Slack-Channel erreichbar: [https://join.slack.com/t/flowcov/shared\_invite/zt-gyh1d6d1-esd4cAZJnLuFObsiH7OCNA](https://join.slack.com/t/flowcov/shared_invite/zt-gyh1d6d1-esd4cAZJnLuFObsiH7OCNA) **Die nächsten Schritte auf unserer Roadmap sind bereits geplant:** - Vollständiger Support für DMN - Unterstützung für Call Activities - Visuelle Simulation von Testmethoden Wir freuen uns auf das Feedback und die Ideen der Community. Du willst deine BPMN-Prozesse nicht nur testen, sondern von der Analyse bis zur produktiven Automatisierung sauber aufsetzen? Dann schau dir an, [wie wir dich dabei unterstützen](/leistungen/). Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fnachvollziehbare-test-coverage-prozess-stakeholder%2F)[](mailto:?subject=Nachvollziehbare%20Test-Coverage%20f%C3%BCr%20alle%20Prozess-Stakeholder&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fnachvollziehbare-test-coverage-prozess-stakeholder%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Open Source-Spendenplattform für dringend benötigte Hilfsgüter in der COVID-19-Krise](https://www.miragon.io/blog/open-source-spendenplattform-covid19/) Referenzen Wie Miragon die technische Architektur und Entwicklung der RemedyMatch-Plattform zur Verteilung von Hilfsgütern in der Corona-Krise übernommen hat. Dominik Horn Co-Founder & Geschäftsführer **30\. Mai 2020**2 Min. Lesezeit RemedyMatch ist eine Plattform für die bedarfsgerechte Verteilung von Hilfsmittelspenden. Das Projekt ist während des von der Bundesregierung gesponserten WirVsVirus-Hackathons im März 2020 entstanden und hat sich inzwischen zu einer professionellen Organisation mit eingetragenem Verein entwickelt. ## Problem Der marktübergreifende Bedarf an Hilfsmitteln hat während der Corona-Krise ab März 2020 dazu geführt, dass vor allem kleinere Einrichtungen wie Pflegeheime, Hospize oder Obdachlosenheime keine notwendige Schutzausrüstung zur Verfügung hatten. Diesem Problem hat sich das Team RemedyMatch während des Hackathons angenommen. ## Lösung Inzwischen haben sich sowohl die Zielgruppe als auch die Einsatzszenarien der Plattform deutlich erweitert. Die Vision ist es, eine einfache und unbürokratische Plattform für die Verteilung von Gütern in Krisensituationen bereitzustellen und zudem eine mögliche Lösung für Institutionen wie das Rote Kreuz, die verschiedenen Tafeln oder andere NGOs, die auf Spenden angewiesen sind, zu liefern. ## Unsere Aufgaben Wir haben während des Hackathons und auch darüber hinaus den Großteil der [technischen Architektur und Entwicklung](/leistungen/) übernommen und konnten mit unserem Know-how bei der Prozessautomatisierung unterstützen. Dabei haben wir auf einen modularen Technologie-Stack gesetzt, mit dem neue Anforderung sehr schnell umgesetzt werden können. Dies erreichten wir vor allem durch den Einsatz von Camunda BPM und der Entkopplung unserer Microservices durch den Einsatz des External-Task-Patterns. Für die Authentifizierung unseres Software-Stacks wählten wir Keycloak mit OpenID Connect. ## Unsere Eindrücke Unsere Eindrücke haben wir hier in einem Blogpost aufgeschrieben: [Gemeinsam gegen Corona: Der #WirVsVirus-Hackathon](https://www.miragon.io/blog/gemeinsam-gegen-corona-der-wirvsvirus-hackathon/). > Ohne das Team der Miragon GmbH hätten wir es nicht geschafft, in dieser kurzen Zeitspanne eine lauffähige Plattform zur Verfügung zu stellen. Speziell das Wissen bei der Automatisierung von Prozessen und der Entwicklung einer modularen Plattform war sehr hilfreich für uns. Wir sind ihnen für ihr soziales Engagement wirklich dankbar. _Julian Haupt, Vorstand RemedyMatch e.V._ * * * ## Eingesetzte Technologien - Java & Spring Boot - React - Keycloak - Docker - Camunda ## Kennzahlen - Kernteam: > 20 Personen - Projektstart bis Go-Live: < 6 Wochen - Platzierung im Hackathon: Top 5 Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fopen-source-spendenplattform-covid19%2F)[](mailto:?subject=Open%20Source-Spendenplattform%20f%C3%BCr%20dringend%20ben%C3%B6tigte%20Hilfsg%C3%BCter%20in%20der%20COVID-19-Krise&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fopen-source-spendenplattform-covid19%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Referenzen 02\. Jan. 2024 ### Prozessautomatisierung in der Intralogistik bei DM Wie Miragon die Intralogistik-IT von DM modernisiert – mit BPMN, Domain-Driven Design und agiler Softwareentwicklung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/prozessautomatisierung-intralogistik-dm/)[ Referenzen 01\. Jan. 2024 ### Digitale Transformation mit Dimacon Wie Miragon mit der Dimacon-Plattform das Kerngeschäft der Handwerksbranche digital transformiert – eine flexible No-Code SaaS-Lösung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digitale-transformation-dimacon/)[ Referenzen 01\. Jan. 2022 ### DigiWF – Landeshauptstadt München Wie Miragon die Landeshauptstadt München bei der Konzeption und Umsetzung einer Plattform zur Digitalisierung und Automatisierung von Workflows unterstützt. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digiwf-landeshauptstadt-muenchen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Prozessabhängigkeiten testen](https://www.miragon.io/blog/prozessabhaengigkeiten-testen/) BPM Wie man Prozessabhängigkeiten in BPMN testet - von Abhängigkeiten zu anderen Modellen bis hin zu Quellcode-Referenzen mit camunda-bpm-mockito. Dominik Horn Co-Founder & Geschäftsführer **20\. Nov. 2020**7 Min. Lesezeit Ursprünglich am 20.11.2020 auf dem offiziellen Camunda-Blog gepostet: [https://camunda.com/blog/2020/11/testing-process-dependencies/](https://camunda.com/blog/2020/11/testing-process-dependencies/) Heute geht es um das Thema “Testing process dependencies”. Für die Ausführung eines Modells werden häufig weitere Ressourcen benötigt. Dabei kann es sich um Quellcode oder die Abhängigkeit zu anderen Modellen handeln. Doch wie gehen wir damit beim Testen unserer Modelle um? In diesem Post werden wir die folgenden Abhängigkeiten genauer unter die Lupe nehmen: - **Modelle**: Abhängigkeiten zu BPMN-Diagrammen, die vom ausgeführten Modell referenziert werden. - **Code**: Abhängigkeiten zu Quellcode, der im BPMN referenziert wird. Dabei werden wir eine weitere Library kennenlernen, die uns das Testen erleichtert: [camunda-bpm-mockito](https://github.com/camunda/camunda-bpm-mockito). Die Beispiele für diesen Blogbeitrag findet ihr in diesem [GitHub-Repository](https://github.com/Miragon/camunda-testing-examples). Im letzten Post haben wir uns einen kleinen Bestell-Prozess näher angeschaut und getestet. Diesen könnt ihr in unserem Beitrag zum [Testen vollständiger Prozesspfade](/blog/vollstaendige-prozesspfade-testen/) finden. In diesem Teil wollen wir das nun weiter ausbauen und um Funktionalitäten erweitern, die wir beim Testen berücksichtigen müssen: - Ein weiterer Prozess, der in einer Call Activity referenziert wird - Ein Java Delegate, das weitere Abhängigkeiten zu einem Service hat ## Abhängigkeiten zu anderen BPMN-Modellen Es gibt verschiedene Gründe dafür, BPMN-Diagramme als Call Activities einzubinden oder aus dem Code heraus zu starten: - **Komplexität reduzieren**: Umfangreiche BPMN-Modelle können sich negativ auf das Verständnis für den eigentlichen Prozessfluss auswirken. Deshalb ist es manchmal sinnvoll, technische Details und Besonderheiten in ein eigenes Diagramm auszulagern. - **Wiederverwendbare Komponenten**: Mit der Anzahl an automatisierten Prozessen steigt häufig die Anzahl an Funktionen, die an unterschiedlichen Stellen verwendet werden können. Wenn es sich dabei nicht nur um einfache Service-Aufrufe handelt, kann es sinnvoll sein, diese Funktionen in separate Prozesse auszulagern. - **Starten von Prozessen**: Manchmal ist es notwendig, Prozesse asynchron zu starten. Dies kann der Fall sein, wenn nach der Beendigung einer Instanz weitere Verarbeitungsschritte durchgeführt werden sollen, ohne, dass der Prozess bis zum Abschluss warten soll. Alle drei Fälle führen dazu, dass wir beim Testen eine Abhängigkeit auf ein weiteres Prozessmodell haben. Doch wie sollen wir damit umgehen? ### Das referenzierte Modell verwenden Wir können das referenzierte Modell in einem Unit-Test verwenden und testen. Dies ist jedoch aus den folgenden Gründen nicht zu empfehlen: - Das BPMN-Modell muss mitgetestet werden und der Testfall wird umfangreicher - Wiederverwendbare Komponenten werden unnötig mehrfach getestet - Gibt es im referenzierten Modell unterschiedliche Rückgabewerte oder Fehler, auf die im Prozess reagiert werden muss, führt dies zu einem enormen Mehraufwand im Testfall - Es müssen die Abhängigkeiten des referenzierten Modells im Testfall berücksichtigt werden - Modifikationen im referenzierten Modell wirken sich auf den Testfall des anderen Prozesses aus ### Ein anderes Modell mit dem gleichen Key verwenden Anstatt das referenzierte Diagramm zu verwenden, kann ein eigenes Modell mit dem gleichen Key deployed werden, dessen Ergebnis parametrisiert werden kann. Dies ist mit wenigen Zeilen Code erledigt: ``` BpmnModelInstance modelInstance = Bpmn.createExecutableProcess() .id("callActivity") .startEvent() .serviceTask().camundaResultVariable("result").camundaExpression(result) .endEvent() .done(); Deployment deployment = rule.getProcessEngine() .getRepositoryService() .createDeployment() .addModelInstance("callActivity" + ".bpmn", modelInstance) .deploy(); ``` Für einfache Modelle ist dies durchaus ein praktikabler Weg. Es gibt jedoch Fälle, die wiederum zu Mehraufwand führen. Besonders dann, wenn es im referenzierten Modell unterschiedliche Rückgabewerte oder Fehler gibt, auf die im Prozess reagiert werden muss. ### Das Modell mit `camunda-bpm-mockito` mocken Anstatt einen eigenen Mock des Modells zu bauen, kann hierfür die [camunda-bpm-mockito](https://github.com/camunda/camunda-bpm-mockito) library verwendet werden. Dies bringt folgende Vorteile: - Übersichtliche Tests, die sich auf den eigentlichen Prozess konzentrieren - Fehler in einem verwendeten Modell wirken sich nicht auf den Test des übergeordneten Prozesses aus - Unterschiedliches Verhalten des referenzierten Modells kann einfacher simuliert werden - Schnellere Durchlaufzeiten bei Tests Werfen wir nun einen Blick auf unseren Bestellprozess. Die Lieferung soll als eigenständiger, wiederverwendbarer Prozess ausgelagert werden, der als Call Activity referenziert wird. Diesen Lieferprozess referenzieren wir nun als Call Activity im Bestellprozess. Doch wie gehen wir damit nun in unserem Test um? Es gibt zwei Aufgaben für uns: - Den Lieferprozess im Test mocken - Einen separaten Test für den Lieferprozess schreiben #### Den Lieferprozess im Test mocken Hierzu ergänzen wir die _defaultScenario()_\-Methode wie folgt: ``` ProcessExpressions.registerCallActivityMock(DELIVERY_PROCESS_KEY) .deploy(rule); when(testOrderProcess.runsCallActivity(TASK_DELIVER_ORDER1)) .thenReturn(Scenario.use(deliveryRequest)); ``` Im _shouldExecuteOrderCancelled_ müssen wir das Verhalten des Call Activity-Mocks anpassen, um bei der Ausführung einen Fehler zu werfen: ``` ProcessExpressions.registerCallActivityMock(DELIVERY_PROCESS_KEY) .onExecutionDo(execution -> { throw new BpmnError("deliveryFailed"); }) .deploy(rule); ``` Und schon haben wir unterschiedliche Varianten für unseren aufgerufenen Bestellprozess definiert - ziemlich einfach! Mit camunda-bpm-mockito ist noch vieles mehr möglich, ausprobieren lohnt sich. #### Einen separaten Test für den Lieferprozess schreiben Als nächstes erstellen wir für den Lieferprozess noch eine eigene Testklasse und übernehmen die Methoden _shouldExecuteOrderCancelled_ und _shouldExecuteDeliverTwice_. ``` @Deployment(resources = "deliver-process.bpmn") public class DeliveryProcessTest { public static final String PROCESS_KEY = "deliveryprocess"; public static final String TASK_DELIVER_ORDER = "Task_DeliverOrder"; public static final String VAR_ORDER_DELIVERED = "orderDelivered"; public static final String END_EVENT_DELIVERY_COMPLETED = "EndEvent_DeliveryCompleted"; public static final String END_EVENT_DELIVERY_CANCELLED = "EndEvent_DeliveryCancelled"; @Rule public ProcessEngineRule rule = new ProcessEngineRule(); @Mock private ProcessScenario testDeliveryProcess; @Before public void defaultScenario() { MockitoAnnotations.initMocks(this); //Happy-Path when(testDeliveryProcess.waitsAtUserTask(TASK_DELIVER_ORDER)) .thenReturn(task -> { task.complete(withVariables(VAR_ORDER_DELIVERED, true)); }); } @Test public void shouldExecuteHappyPath() { Scenario.run(testDeliveryProcess) .startByKey(PROCESS_KEY) .execute(); verify(testDeliveryProcess) .hasFinished(END_EVENT_DELIVERY_COMPLETED); } @Test public void shouldExecuteOrderCancelled() { when(testDeliveryProcess.waitsAtUserTask(TASK_DELIVER_ORDER)).thenReturn(task -> { taskService().handleBpmnError(task.getId(), "DeliveryCancelled"); }); Scenario.run(testDeliveryProcess) .startByKey(PROCESS_KEY) .execute(); verify(testDeliveryProcess) .hasFinished(END_EVENT_DELIVERY_CANCELLED); } @Test public void shouldExecuteDeliverTwice() { when(testDeliveryProcess.waitsAtUserTask(TASK_DELIVER_ORDER)).thenReturn(task -> { task.complete(withVariables(VAR_ORDER_DELIVERED, false)); }, task -> { task.complete(withVariables(VAR_ORDER_DELIVERED, true)); }); Scenario.run(testDeliveryProcess) .startByKey(PROCESS_KEY) .execute(); verify(testDeliveryProcess, times(2)) .hasCompleted(TASK_DELIVER_ORDER); verify(testDeliveryProcess) .hasFinished(END_EVENT_DELIVERY_COMPLETED); } } ``` ## Abhängigkeiten zu Quellcode Schauen wir nun, wie wir mit Code-Abhängigkeiten umgehen können: - Alle Abhängigkeiten mit Mocks ersetzen - Den gesamten Kontext bereitstellen - Ausgewählte Klassen mit Abhängigkeiten bereitstellen Werden alle Abhängigkeiten durch Mocks ersetzt, verliert der Test an Aussagekraft. Stattdessen den kompletten Kontext bereitzustellen, würde wiederum am Ziel eines Unit-Tests vorbeigehen, wäre bei größeren Anwendungen sehr aufwendig und würde zu längeren Test-Laufzeiten führen. Die Lösung liegt somit im letzten Punkt. Doch welche Klassen sollen bereitgestellt und welche durch Mocks ersetzt werden? Schauen wir uns dieses Beispiel anhand des Java-Delegates an, das im _Send Cancellation_\-Task verwendet wird, und ergänzen es um einen Mailing-Service: ``` @Component public class SendCancellationDelegate implements JavaDelegate { private final MailingService mailingService; @Autowired public SendCancellationDelegate(MailingService mailingService) { this.mailingService = mailingService; } @Override public void execute(DelegateExecution delegateExecution) throws Exception { //input final String customer = (String) delegateExecution.getVariable("customer"); //processing mailingService.sendMail(customer); //output delegateExecution.setVariable("cancellationTimeStamp", Instant.now().getEpochSecond()); } } ``` Dieses Delegate liest eine Prozessvariable, verwendet den Mailing-Service, um die Stornierung zu versenden und schreibt den Zeitpunkt der Stornierung zurück in den Prozess. Es ist durchaus von Vorteil, dieses Delegate während eines Testfalls auszuführen, denn es erhöht die Aussagekraft des Tests. Das Versenden der Mail ist jedoch nicht sinnvoll. **Zusammengefasst:** Klassen, die aus dem Diagramm referenziert werden, sollen wenn möglich ausgeführt werden. Deren Abhängigkeiten wiederum gilt es zu mocken. Hierfür erweitern wir den Test wie folgt: 1. MailingService-Mock erstellen: ``` @Mock private MailingService mailingService; ``` 2. Mock an das Delegate übergeben: ``` Mocks.register("sendCancellationDelegate", new SendCancellationDelegate(mailingService)); ``` 3. Nichts tun, wenn _sendMail()_ aufgerufen wird: ``` doNothing().when(mailingService).sendMail(any()); ``` 4. Prüfen, ob der Mailing-Service aufgerufen wird: ``` @Test public void shouldExecuteCancellationSent() { when(testOrderProcess.waitsAtUserTask(TASK_CHECK_AVAILABILITY)).thenReturn(task -> { task.complete(withVariables(VAR_PRODUCTS_AVAILABLE, false)); }); Scenario.run(testOrderProcess) .startByKey(PROCESS_KEY, withVariables(VAR_CUSTOMER, "john")) .execute(); verify(testOrderProcess) .hasFinished(END_EVENT_CANCELLATION_SENT); //verfiy execution of mailingService verify(mailingService, (times(1))).sendMail(any()); verifyNoMoreInteractions(mailingService); } ``` Bei komplexen Kontexten kann es schwierig werden, den Überblick über alle in einem Testfall verwendeten Mocks zu behalten. In diesem Fall ist es sinnvoller, diese in Factory-Klassen auszulagern, um auch die Abhängigkeiten untereinander zu berücksichtigen. ### Fazit Mit der camunda-bpm-mockito library ist noch vieles mehr möglich. Es können bspw. Messages gemockt werden, die beim Ausführen des Modells korreliert werden sollen oder es ist möglich, das Ergebnis einer Camunda Query zu simulieren. All diese Funktionen erleichtern das Testen von komplexeren Prozessen. Dieser Blog-Post war eine Einführung in das Testen von Prozessabhängigkeiten. Code und Modelle sind häufig eng miteinander verknüpft, was sich auch auf den Umfang der Testfälle auswirkt. Die hier gezeigten Beispiele und Empfehlungen können jedoch dabei helfen, die eigenen Tests zu vereinfachen und den Aufwand zu reduzieren. Aber woher wissen wir, ob die geschriebenen Tests ausreichend sind und alle notwendigen Teile des Prozesses abdecken? Und wie können wir das kontrollieren? Mit diesem Thema beschäftigen wir uns in unserem nächsten Post, in dem wir die [Testabdeckung für Prozesse messen](/blog/testabdeckung-prozesse-messen/). Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fprozessabhaengigkeiten-testen%2F)[](mailto:?subject=Prozessabh%C3%A4ngigkeiten%20testen&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fprozessabhaengigkeiten-testen%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Prozessautomatisierung in der Baubranche](https://www.miragon.io/blog/prozessautomatisierung-baubranche/) BPM Gemeinsam mit Studierenden der Hochschule Augsburg und der SSB Fidan digitalisieren wir Prozesse in der Baubranche - von Leistungsnachweisen bis zur Abrechnung. Dominik Horn Co-Founder & Geschäftsführer **07\. Dez. 2020**4 Min. Lesezeit Die Zusammenarbeit mit Studierenden der Hochschule Augsburg geht in die nächste Runde. In diesem Semesterprojekt werfen wir gemeinsam mit der SSB Fidan einen Blick in die Baubranche. Die [SSB Fidan](https://ssb-fidan.com/) ist eine Spezialfirma für das Sägen, Schneiden, Bohren und Sprengen von Beton. Der Prozess, den wir genauer unter die Lupe nehmen, dreht sich um die Erstellung und Abrechnung von Leistungsnachweisen. Von der Beauftragung bis hin zur Fertigstellung eines Bauvorhabens sind verschiedene Schritte notwendig, die dokumentiert werden müssen. Darunter fallen etwa die Erstellung eines Angebots, die Erfassung der Tätigkeiten inklusive aller Mehraufwände und die Übertragung der Daten in eine Rechnung. Dies passiert derzeit noch zu großen Teilen in Papierform. Das ist nicht nur aufwendig sondern auch fehleranfällig. Gemeinsam mit den Studierenden prüfen wir deshalb, in wieweit die verschiedenen Abläufe digitalisiert werden können. Der folgende Prozess gibt einen groben Überblick, welche Schritte für die Durchführung notwendig sind. Die Anforderungen an die Digitalisierung dieses Prozesses sind vielfältig, Usability und Anpassbarkeit sind essentiell. Um diese Herausforderungen zu meistern, muss viel Engagement in die Konzeption und Analyse gesteckt werden. Unser Team besteht aus acht Teilnehmerinnen und Teilnehmern und ist in drei kleinere Gruppen aufgeteilt. - **Prozessanalyse**: t.BPM Workshops, Prozessanalyse, Modellierung, Toolvergleich, Konzeption - **UI/UX**: Konzeption der Oberfläche, Umsetzung eines Prototypen in _Adobe XD_ - **Entwicklung**: Prototypische Entwicklung der Anwendung, Implementierung des Prozesses ## Prozessanalyse Um eine besseres Verständnis für die Domäne zu bekommen, haben wir zunächst mit einem t.BPM-Workshop bei der SSB Fidan ins Projekt gestartet. Dabei gab es auch eine kurze Einführung in die Arbeitsweise und die verwendeten Geräte. Mithilfe der t.BPM-Methode visualisierten und analysierten wir den Prozess von der Beauftragung eines Bauvorhabens über die Planung bis hin zur Erstellung und Dokumentation eines Leistungsnachweises. Dabei wurden auch eventuell auftretende Probleme im Verlauf der Erfassung berücksichtigt. Bei t.BPM handelt es sich um eine interaktive Methode, bei der alle Beteiligten des Workshops gemeinsam am Prozess arbeiten und dadurch viele Diskussionen rund um das Modell entstehen. Anschließend wurde der Prozess in BPMN digital erfasst. In einem weiteren Workshop haben wir den Prozess verfeinert und diskutiert, welche Daten benötigt werden. Aufgrund des aktuellen Infektionsgeschehens mussten wir auf ein Treffen vor Ort verzichten. Deshalb setzten wir für den digitalen Prozess-Workshop die Plattform [Miro](https://miro.com/) ein. Für diese Veranstaltungen mit verschiedene Teilnehmer ist das Tool sehr empfehlenswert. Es handelt sich dabei um eine große Zeichenfälle, an der gemeinsam gearbeitet werden kann. Dabei werden die Anwender durch verschiedene Vorlagen und Kollaborationsfunktionen unterstützt. Im nächsten Schritt wird analysiert, in wieweit die Genehmigung und Kontrolle durch die Bauleiter im Rahmen des Prozesses digitalisiert werden kann. ## UI/UX Durch die Analyse hat sich herausgestellt, dass wir zwei verschiedene Anwendungen brauchen. Eine Webapplikation für die Verwaltung, Planung und Bearbeitung der Aufträge im Backoffice und eine App für die Dokumentation und Planung auf der Baustelle. Speziell die Anforderungen an die Usability sind bei der mobilen Version der Anwendung kritisch. Die Monteure auf der Baustelle müssen in der Lage sein, in kurzer Zeit die verschieden Arbeitsschritte und Mehraufwände zu dokumentieren. Außerdem soll die Einarbeitung in die Software einfach und leicht verständlich sein. In mehreren digitalen Workshops haben wir gemeinsam die Anforderungen an die Software analysiert. Um einen ersten Eindruck von der App zu bekommen wird momentan mit Adobe XD ein erster UI-Prototyp erstellt. Dieser ist hilfreich, um einen ersten Eindruck der Oberfläche zu bekommen und die Anforderungen zu verfeinern. ## Entwicklung Bei der Entwicklung haben wir uns im ersten Schritt auf die [Automatisierung des Prozessentwurfs mit Camunda](/portfolio/automate/) konzentriert. Dazu war es notwendig, das BPMN-Diagramm mit den entsprechenden Metadaten anzureichern. Im nächsten Schritt modellierten wird das Datenmodell unserer Anwendung und setzten das Backend auf. Technologisch setzen wir auf Spring Boot und JPA für die Speicherung der Objekte. Im nächsten Schritt wird die Entwicklung der Web-Anwendung fokussiert. Diese besteht aus folgenden Komponenten: - **Aufgabenliste**: Eine übergreifende Liste an Aufgaben, die für die unterschiedlichen Aufträge erledigt werden müssen. Die Aufgabenverwaltung und Bereitstellung der Services im Backend übernimmt dabei Camunda. - **Auftragsverwaltung**: Eine Oberfläche für die Verwaltung der Aufträge, vom Einplanen bis zur Freigabe des Leistungsnachweises. - **Kundenverwaltung**: In der Applikation wird ebenfalls eine kleine Kundenverwaltung benötigt. Dies ist wichtig, um die einzelnen Bauvorhaben und Ansprechpartner zu verwalten. Wir freuen uns auf die Ergebnisse dieses spannenden Projekts! Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fprozessautomatisierung-baubranche%2F)[](mailto:?subject=Prozessautomatisierung%20in%20der%20Baubranche&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fprozessautomatisierung-baubranche%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Prozessautomatisierung in der Intralogistik bei DM](https://www.miragon.io/blog/prozessautomatisierung-intralogistik-dm/) Referenzen Wie Miragon die Intralogistik-IT von DM modernisiert – mit BPMN, Domain-Driven Design und agiler Softwareentwicklung. Dominik Horn Co-Founder & Geschäftsführer **02\. Jan. 2024**2 Min. Lesezeit In unserer Rolle als Spezialisten für Prozessautomatisierung, Softwareentwicklung und Softwarearchitektur sind wir derzeit an einem spannenden und herausfordernden Projekt bei der renommierten Drogeriemarktkette DM beteiligt. Unser Ziel ist es, das Herzstück der IT-Intralogistik, ein umfangreiches und über Jahre hinweg gewachsenes Bestandssystem, das die Abläufe in den Verteilzentren steuert, schrittweise zu modernisieren und zu optimieren. Die Herausforderung in diesem Projekt liegt in der integration der neuen Prozesse in das bestehende System, da immer nur Teile des Systems ersetzt werden. Die neue modular aufgebaute Architektur wird schrittweise durch weitere Domänen ergänzt, wie den Wareneingang oder die Qualitätssicherung bei der Kommissionierung. Mit Hilfe von Domain-Driven Design (DDD) schaffen wir eine solide Basis, um den Monolithen erfolgreich in einzelne, besser handhabbare Komponenten zu zerlegen. Ein wesentlicher Bestandteil unseres Ansatzes ist die [Implementierung von Business Process Model and Notation (BPMN)](/portfolio/automate/), um die Transparenz und Konfigurierbarkeit des Systems zu verbessern. Dies ermöglicht es DM, ihre Prozesse genauer zu steuern und anzupassen, was eine erhebliche Steigerung der Effizienz nach sich zieht. Die agile Vorgehensweise mittels SCRUM bildet das Rückgrat unseres Projektes und ermöglicht es uns, flexibel auf Änderungen zu reagieren und in enger Zusammenarbeit mit dem Kunden die bestmöglichen Lösungen zu entwickeln. ## Aufgaben im Projekt: - **Analyse und Modellierung:** Durchführung von detaillierten Analysen der bestehenden Abläufe und Modellierung optimierter Prozesse in BPMN und DMN. - **Architektur:** Aktive Beteiligung an der Gestaltung der Softwarearchitektur durch Vorschläge und Diskussionen, um die Zukunftsfähigkeit und Skalierbarkeit des Systems zu gewährleisten. - **DDD Workshops:** Teilnahme und aktive Mitwirkung an DDD Workshops zur präzisen Ausarbeitung der Anforderungen und deren Umsetzung. - **BPMN Schulungen:** Durchführung von Schulungen für das Team und weiteren Stakeholdern zur Vermittlung von Kenntnissen und Fähigkeiten im Umgang mit BPMN, um eine breite Akzeptanz und effektive Nutzung der modellierten Prozesse sicherzustellen. - **Schnittstellen:** Analyse und Implementierung von Schnittstellen zum bestehenden Bestandssystem für eine reibungslose Integration. - **Softwareentwicklung:** Entwicklung von robusten Backend-Lösungen mit Kotlin, ergänzt durch fortschrittliche Frontend-Technologien wie Typescript und Angular. - **DevOps:** Unterstützung im Bereich DevOps, insbesondere bei der Automatisierung von Prozessen mit GitLab Runner und dem Deployment mit Helm charts auf Kubernetes. - **Monorepo:** Aufbau und Pflege eines Monorepos zur Vereinfachung der Entwicklung und Wartung der neuen Microservices. ## Eingesetzte Technologien: Unsere technologische Basis für dieses Projekt umfasst fortschrittliche Tools und Frameworks wie Camunda 8, Kafka, Kotlin, Spring Boot, Typescript, Angular, Kubernetes und GitLab. Diese Technologien ermöglichen es uns, eine hochmoderne, skalierbare und wartbare Lösung zu implementieren, die nicht nur den aktuellen Anforderungen von DM entspricht, sondern auch neue Maßstäbe in der Intralogistik setzt. Durch diesen umfassenden und zukunftsorientierten Ansatz sind wir in der Lage, die spezifischen Herausforderungen von DM zu meistern und einen signifikanten Mehrwert für ihr Geschäft zu schaffen, indem wir Effizienz, Flexibilität und Skalierbarkeit ihrer Intralogistiksysteme maßgeblich verbessern. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fprozessautomatisierung-intralogistik-dm%2F)[](mailto:?subject=Prozessautomatisierung%20in%20der%20Intralogistik%20bei%20DM&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fprozessautomatisierung-intralogistik-dm%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Referenzen 01\. Jan. 2024 ### Digitale Transformation mit Dimacon Wie Miragon mit der Dimacon-Plattform das Kerngeschäft der Handwerksbranche digital transformiert – eine flexible No-Code SaaS-Lösung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digitale-transformation-dimacon/)[ Referenzen 01\. Jan. 2022 ### DigiWF – Landeshauptstadt München Wie Miragon die Landeshauptstadt München bei der Konzeption und Umsetzung einer Plattform zur Digitalisierung und Automatisierung von Workflows unterstützt. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digiwf-landeshauptstadt-muenchen/)[ Referenzen 30\. Juli 2021 ### Durchführung eines t.BPM-Workshops für die Analyse und Visualisierung von Prozessen in der Baubranche Wie Miragon mit der SSB Fidan GmbH in einem t.BPM-Workshop Bauprozesse von der Beauftragung bis zur Rechnungsstellung analysiert und visualisiert hat. Dominik Horn Co-Founder & Geschäftsführer ](/blog/tbpm-workshop-baubranche/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Umsetzung einer Redaktionsplattform für die Vorbereitung von Hauptversammlungen](https://www.miragon.io/blog/redaktionsplattform-hauptversammlungen/) Referenzen Wie wir innerhalb von vier Wochen eine vollständige Redaktionsplattform für die Vorbereitung virtueller Hauptversammlungen implementiert haben. Alexander Praschek Co-Founder **16\. Okt. 2020**1 Min. Lesezeit Die ACS Solution GmbH ist ein Software- und Dienstleistungsunternehmen, das sich auf Produkte und Services für die Vorbereitung und Durchführung von Hauptversammlungen von Aktiengesellschaften spezialisiert hat. ## Problem Während der Corona-Krise kam es zu drastischen Einschränkungen bei der Durchführung von Großveranstaltungen. Vor diesem Hintergrund passte die Regierung die Gesetzgebung an und ermöglichte AGs die Durchführung von virtuellen Hauptversammlungen. Durch die damit verbundene Änderung des Fragerechts mussten bestehende Lösungen und Prozesse für das Erfassen, Bearbeiten und Beantworten der Fragen der Anteilseigner angepasst werden. ## Lösung Als einen Teil der neuen Lösung haben wir innerhalb von vier Wochen [eine vollständige Redaktionsplattform implementiert](/leistungen/). Das Ziel bestand darin, eine Cloud-Anwendung bereitzustellen, in der Fragen aus verschiedensten Quellen importiert werden können. Im Anschluss werden diese durch die Redakteure bearbeitet und ggf. für den Bearbeitungs- und Beantwortungsprozess freigegeben. Hierfür war ein Export in das jeweilige Kundensystem essenziell. ## Unsere Aufgaben - Software-Architektur - Backend-Entwicklung - Frontend-Entwicklung - Deployment und Hosting ## Eingesetzte Technologien - Spring Boot - React - Keycloak - Docker - Kubernetes ## Projektkennzahlen - Kernteam: 4 Personen - Projektstart bis Go-Live: 4 Wochen - Eingesetzt bei: 20 Kunden * * * > Trotz der geringen Vorlaufzeit und der sehr kurzen Projektlaufzeit von nur ca. 4 Wochen bis zum ersten Einsatz, stellte die Miragon GmbH rechtzeitig eine qualitativ hochwertige Anwendung bereit, mit der unsere Kunden sehr zufrieden sind. _Manfred Michel, Geschäftsführer ACS Solution GmbH_ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fredaktionsplattform-hauptversammlungen%2F)[](mailto:?subject=Umsetzung%20einer%20Redaktionsplattform%20f%C3%BCr%20die%20Vorbereitung%20von%20Hauptversammlungen&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fredaktionsplattform-hauptversammlungen%2F) ## Alexander Praschek Co-Founder bei Miragon [in Alexander kennenlernen](https://www.linkedin.com/in/alexander-praschek/) [Mehr von Alexander](/blog/?author=alexander-praschek) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Referenzen 02\. Jan. 2024 ### Prozessautomatisierung in der Intralogistik bei DM Wie Miragon die Intralogistik-IT von DM modernisiert – mit BPMN, Domain-Driven Design und agiler Softwareentwicklung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/prozessautomatisierung-intralogistik-dm/)[ Referenzen 01\. Jan. 2024 ### Digitale Transformation mit Dimacon Wie Miragon mit der Dimacon-Plattform das Kerngeschäft der Handwerksbranche digital transformiert – eine flexible No-Code SaaS-Lösung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digitale-transformation-dimacon/)[ Referenzen 01\. Jan. 2022 ### DigiWF – Landeshauptstadt München Wie Miragon die Landeshauptstadt München bei der Konzeption und Umsetzung einer Plattform zur Digitalisierung und Automatisierung von Workflows unterstützt. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digiwf-landeshauptstadt-muenchen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Schulungen und Projekte zu BPM-Themen](https://www.miragon.io/blog/schulungen-projekte-bpm-themen/) Referenzen Miragon unterstützt Vorlesungen und Projekte zu BPM-Themen an der Hochschule Augsburg - von tBPM-Workshops über Camunda bis Process Mining. Dominik Horn Co-Founder & Geschäftsführer **16\. Okt. 2020**1 Min. Lesezeit Wir unterstützen an der Hochschule Augsburg Vorlesungen und Projekte zu BPM-Themen. Dafür gestalten wir [interaktive Vorlesungen zu relevanten Bereichen im Prozessmanagement](/trainings/bpmn-training/) und steigen gemeinsam mit den Studenten anhand von praxisbezogenen Beispielen in die einzelnen Phasen des BPM-Lifecycles ein. Angefangen bei interaktiven tBPM-Workshops zur Analyse und Aufnahme von Prozessmodellen, über die Automatisierung von Geschäftsprozessen mit Camunda, bis hin zum Process Mining zur Analyse und Überwachung von Abläufen in bestehenden Systemen. Seit März 2020 ist unser Co-Founder Dominik Horn außerdem als Lehrbeauftragter an der Hochschule Augsburg für Prozessmanagement und -automatisierung engagiert. quoteAuthor: Prof. Dr. Nikolaus Müssigmann, Hochschule Augsburg > Durch den Einsatz von Miragon erhalten die Studenten anhand von praxisnahen Beispielen wertvolle Einblicke in die BPM-Welt. Ich finde es toll, mit welcher Begeisterung das Wissen rund um die Prozessautomatisierung vermittelt wird! _Prof. Dr. Nikolaus Müssigmann, Hochschule Augsburg_ * * * ## Vorgestellte Technologien - BPM - Java & Spring Boot - Camunda - t.BPM ## Kennzahlen - Engagement: Seit 2016 - Durchgeführt: 8 Projekte - Lehrauftrag: seit März 2010 Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fschulungen-projekte-bpm-themen%2F)[](mailto:?subject=Schulungen%20und%20Projekte%20zu%20BPM-Themen&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fschulungen-projekte-bpm-themen%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Referenzen 02\. Jan. 2024 ### Prozessautomatisierung in der Intralogistik bei DM Wie Miragon die Intralogistik-IT von DM modernisiert – mit BPMN, Domain-Driven Design und agiler Softwareentwicklung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/prozessautomatisierung-intralogistik-dm/)[ Referenzen 01\. Jan. 2024 ### Digitale Transformation mit Dimacon Wie Miragon mit der Dimacon-Plattform das Kerngeschäft der Handwerksbranche digital transformiert – eine flexible No-Code SaaS-Lösung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digitale-transformation-dimacon/)[ Referenzen 01\. Jan. 2022 ### DigiWF – Landeshauptstadt München Wie Miragon die Landeshauptstadt München bei der Konzeption und Umsetzung einer Plattform zur Digitalisierung und Automatisierung von Workflows unterstützt. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digiwf-landeshauptstadt-muenchen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Software Architektur dokumentieren](https://www.miragon.io/blog/software-architektur-dokumentieren/) Softwareentwicklung Wie Architecture Decision Records (ADRs) helfen, Architekturentscheidungen nachvollziehbar zu dokumentieren und Wissen im Team zu bewahren. Lukas Mösle Consultant **27\. Jan. 2025**5 Min. Lesezeit # Software Architektur dokumentieren Im Laufe meiner Karriere als Softwareentwickler bin ich häufig auf Legacy-Systeme gestoßen, die über Jahre hinweg organisch gewachsen sind. Das ursprüngliche Entwicklungsteam ist oft längst nicht mehr da, und die hinterlassene Dokumentation ist entweder veraltet oder nicht existent. Dieser Mangel an Kontext macht es neuen Teams unglaublich schwer, die bestehende Software zu verstehen und effektiv zu warten. In solchen Situationen greifen Entwickler oft zu einem von zwei gleichermaßen problematischen Ansätzen: Entweder akzeptieren sie frühere Architekturentscheidungen blindlings oder ändern sie ohne ausreichendes Verständnis. In solchen Fällen beginnen Teams in der Regel damit, technische Diagramme zu erstellen, um die aktuelle Softwarearchitektur festzuhalten. Diese helfen zwar, den gegenwärtigen Zustand des Systems zu verstehen, beantworten jedoch nicht die entscheidende Frage: Warum hat das frühere Team das System auf diese Weise entworfen? Genau hier kommen Architecture Decision Records (kurz ADRS), ins Spiel. Sie liefern eine Dokumentation, die nicht nur erklärt, was gebaut wurde, sondern auch, warum es so gebaut wurde. ### Was sind Architecture Decision Records? Architecture Decision Records (ADRs) sind eine systematische Methode, um die kritischen Designentscheidungen zu dokumentieren, die von Softwarearchitekten und Entwicklungsteams während des Softwaredesign- und Implementierungsprozesses getroffen werden. ADRs liefern entscheidende Kontextinformationen, indem sie die Gründe hinter den Architekturentscheidungen erklären. Durch die Erfassung des „Was“ und des „Warum“ helfen ADRs den Beteiligten, die Überlegungen, potenziellen Auswirkungen, Kompromisse und strategischen Vorteile von Architekturentscheidungen zu verstehen. Das verbessert die Kommunikation und die langfristige Wartbarkeit des Systems. Ein Architecture Decision Record (ADR) enthält typischerweise fünf zentrale Komponenten: einen Titel, den Status, den Kontext, die Entscheidung und die Konsequenzen. Obwohl diese Standard sind, können Projekte zusätzliche Felder für eine umfassendere Dokumentation hinzufügen. **Titel** Wähle einen prägnanten, nummerierten Titel, der die Essenz der Architekturentscheidung präzise einfängt, um eine schnelle Identifikation und Referenzierung zu ermöglichen. **Status** Markiere den aktuellen Status der Entscheidung klar: vorgeschlagen, akzeptiert, abgelehnt oder ersetzt. Für abgelehnte oder ersetzte ADRs sollte ein Verweis auf das alternative ADR enthalten sein. **Kontext** Umreiße die spezifischen Umstände, Einschränkungen und die technische Landschaft, die diese Architekturentscheidung erforderlich machten. **Entscheidung** Formuliere die Architekturentscheidung klar und unmissverständlich. Verwende deutliche, bejahende Sprache, die keinen Raum für Fehlinterpretationen der gewählten Vorgehensweise lässt. **Konsequenzen** Dokumentiere die potenziellen kurz- und langfristigen Auswirkungen der Entscheidung. Analysiere kritisch und präsentiere sowohl die Vorteile als auch die potenziellen Herausforderungen dieser Architekturentscheidung. **Zusätzliche Felder** Passe deine ADRs mit zusätzlichen Feldern an, die auf dein Projekt- und Teampräferenzen abgestimmt sind. Zum Beispiel kannst du einen Abschnitt für Alternativen hinzufügen, um alternative, aber nicht gewählte Lösungen zu präsentieren. ### Wie ein ADR aussehen könnte? Betrachten wir ein Beispiel aus der Praxis eines typischen Softwareprojekts, um zu veranschaulichen, wie ein ADR funktioniert. Angenommen, du arbeitest an einer wachsenden Anwendung, die ein API-Gateway benötigt, um die Kommunikation zwischen Client und Service zu verwalten. Ohne ein zentrales Gateway sind die Frontend- und Backend-Services locker gekoppelt, was zu inkonsistenter Weiterleitung, Authentifizierung und Sicherheitsrichtlinien führt. Die finale Architektur könnte etwa so aussehen: Um die Entscheidung zur Nutzung von NGINX und dessen Konfiguration gemäß dem Diagramm zu dokumentieren, würde folgendes ADR erstellt: ``` ### ADR-001 Nutzung eines NGINX-API-Gateways **Status** akzeptiert **Kontext** Unsere Anwendung benötigt ein API-Gateway, um die Kommunikation zwischen Clients und Services zu optimieren und einen einheitlichen Zugriff sowie eine konsistente Weiterleitung zu gewährleisten. Dieses Gateway wird die Weiterleitung zentralisieren, einheitliche Sicherheitsrichtlinien durchsetzen und die Kommunikation zwischen Frontend und Backend vereinfachen. **Entscheidung** Wir verwenden NGINX als API-Gateway mit folgender Konfiguration: - SPA-Frontend-Bereitstellung: Die SPA-Frontend-Anwendung wird unter dem Endpoint `/` ausgeliefert. - Backend-Weiterleitung: Alle Backend-Services sind über den Endpoint `/api/**` zugänglich. - SSO-Integration: Der SSO-Dienst wird unter dem Endpoint `/auth` bereitgestellt. **Konsequenzen** - Einheitlicher Zugriff: Alle Client-Anfragen werden über das API-Gateway geleitet. - Verbesserte Sicherheit: Direkter Zugriff auf Backend-Services über deren interne Domains wird eliminiert, wodurch die Angriffsfläche reduziert wird. NGINX wurde aufgrund folgender Gründe ausgewählt: - Bewährte Fähigkeit, hohe Concurrency und Traffic zu bewältigen - Flexible Konfigurationsoptionen für Routing und Load-Balancing - Kompatibilität mit modernen Authentifizierungs- und API-Sicherheitsmustern ``` Mit dem _ADR-001 Nutzung eines NGINX-API-Gateways_ dokumentierst du erfolgreich die Architekturentscheidung. Dies hilft allen Projektbeteiligten, diesen speziellen Teil der Architektur besser zu verstehen. ### Wie mit ADRs anfangen? Der beste Zeitpunkt, um mit der Dokumentation von Architekturentscheidungen zu beginnen, ist jetzt. Erstelle zunächst eine wiederverwendbare ADR-Vorlage, die dein Team für zukünftige Entscheidungen leicht duplizieren kann. Für bestehende Projekte konzentriere dich zunächst auf die Dokumentation neuer Architekturentscheidungen, anstatt jede vergangene Entscheidung zu erfassen, was überwältigend sein kann. Wenn du bei deiner aktuellen Aufgaben auf frühere, nicht dokumentierte Entscheidungen stlößt, nehmen dir einen Moment Zeit, um diese zu dokumentieren. Das Hauptziel ist es, Zugänglichkeit und Sichtbarkeit für alle Projektbeteiligten zu gewährleisten. Wählen einen Speicherort für die ADRs, die zum Workflow deines Teams und zu den Dokumentationsstandards der Organisation passen. Für Softwareprojekte empfehle ich folgende Speicherort: - In Open-Source-Projekten, die Git-Repositories verwenden, speicherne ADRs als Markdown-Dateien neben Code und Dokumentation. - Für Teams, die Wiki-Plattformen wie Confluence verwenden, erstelle einen speziellen ADR-Space, der leicht durchsuchbar ist. - Enterprise-Teams könnten spezialisierte Dokumentationstools oder versionierte Repositories nutzen, die sich nahtlos in bestehende Entwicklungs-Workflows integrieren lassen. ### Warum die Erstellung von ADRs wichtig ist? Das Schreiben von Architektur-Entscheidungsprotokollen (ADRs) ist aus mehreren Gründen hilfreich: - **Alignment:** ADRs stellen sicher, dass alle Teammitglieder ein klares, gemeinsames Verständnis der wichtigen Architekturentscheidungen haben. Sie bieten eine zentrale Informationsquelle, die die technische Vision zwischen verschiedenen Teams, Abteilungen und zukünftigen Mitwirkenden, die nicht an der ursprünglichen Entscheidungsfindung beteiligt waren, ausrichtet. - **Wissensaustausch:** ADRs dienen als lebendige Dokumentation, die nicht nur festhält, welche Entscheidungen getroffen wurden, sondern auch die Gründe dafür. Dieser Wissensaustausch ist entscheidend für die Einarbeitung neuer Teammitglieder und verhindert den Verlust von Wissen bei Personalwechseln. - **Langfristige Wartbarkeit:** Durch die Dokumentation von Architekturentscheidungen schaffen Teams ein historisches Protokoll, das künftigen Entwicklern hilft zu verstehen, warum bestimmte technische Ansätze gewählt wurden. Dieser Kontext ist bei der Wartung, Refactorings oder Skalierung von Softwaresystemen von unschätzbarem Wert. - **Teamwork:** Jedes Teammitglied kann Vorschläge zur Verbesserung der Softwarearchitektur einbringen. ADRs schaffen eine transparente, kollaborative Umgebung, in der technische Entscheidungen nicht isoliert, sondern durch kollektiven Input, Überprüfung und Konsens getroffen werden. Dieser Ansatz fördert eine Kultur der kontinuierlichen Verbesserung und gemeinsamen Verantwortung für die technische Strategie. ### Fazit Architektur-Entscheidungsprotokolle (ADRs) sind ein mächtiges Werkzeug, um Architekturentscheidungen in der Softwareentwicklung zu dokumentieren und zu kommunizieren. Sie liefern Klarheit über das „Warum“ hinter Architekturentscheidungen, fördern die Ausrichtung im Team, erleichtern den Wissensaustausch und verbessern die Wartbarkeit. _This post was originally published in English on_ [Medium.com](https://medium.com/miragon/how-to-document-your-software-architecture-decisions-3e357f5bcfd4) _._ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fsoftware-architektur-dokumentieren%2F)[](mailto:?subject=Software%20Architektur%20dokumentieren&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fsoftware-architektur-dokumentieren%2F) ## Lukas Mösle Consultant bei Miragon [in Lukas kennenlernen](https://www.linkedin.com/in/lukas-moesle) [Mehr von Lukas](/blog/?author=lukas-mösle) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Wie sich komplexe Switch-Case-Strukturen durch Interfaces und Dependency Injection vermeiden lassen](https://www.miragon.io/blog/switch-case-interfaces-dependency-injection/) Softwareentwicklung Wie man mit Spring Dependency Injection und Java Streams komplexe Switch-Case-Strukturen durch ein modulares Interface-basiertes Design ersetzt. Marco Schäck Process Development Lead **08\. Okt. 2024**5 Min. Lesezeit In vielen Softwaresystemen führt die Notwendigkeit, verschiedene Geschäftsregeln auf Grundlage von unterschiedlichen Bedingungen anzuwenden, oft zu komplexem und schwer wartbarem Code. Ohne ein flexibles Design können Strukturen wie ein `if-else` oder ein `switch-case` schnell unübersichtlich werden - insbesondere wenn das System wächst. Dieser Post zeigt, wie dieses Problem gelöst werden kann. Mithilfe von [Spring’s Dependency Injection (DI)](https://docs.spring.io/spring-framework/reference/core/beans/dependencies/factory-collaborators.html) und [Java Streams](https://www.baeldung.com/java-8-streams) wird ein Ansatz vorgestellt, der die Auswahl von Services vereinfacht. Dadurch entsteht ein modularerer und leichter wartbarer Code, der sich problemlos erweitern lässt - selbst wenn das System wächst. Nehmen wir an, eine E-Commerce-Plattform muss je nach Land des Käufers unterschiedliche Steuer- oder Versandvorschriften anwenden. Um den Code modular und testbar zu halten, wird für jedes Land ein eigener Service erstellt. Trotzdem erfolgt die Auswahl des jeweiligen Services weiterhin über eine einfache `if-else`\- oder `switch-case`\-Strukturen. Auf den ersten Blick scheint dies praktikabel – jeder Service wird basierend auf dem Standort des Käufers ausgewählt. Doch sobald die Plattform wächst und weitere Länder hinzukommen, wird diese Lösung zunehmend problematisch. Je mehr Länder verwaltet werden müssen, desto komplexer wird der Codeblock. Das Ergebnis: ohne ein skalierbares Design entsteht ein stark gekoppelter, monolithischer Code, der anfällig für Fehler, schwer zu testen, sowie schwer zu erweitern ist. Doch keine Sorge – dies ist ein häufiges Problem in Softwaresystemen. Und die gute Nachricht ist: Es gibt skalierbare Lösungen, um dem entgegenzuwirken. Dieser Post zeigt eine davon: den Einsatz von Schnittstellen und der Dependency Injection von Spring, um ein sauberes, modulares System zu entwerfen. Anhand des oben genannten Beispiels wird veranschaulicht, wie diese Prinzipien den Code vereinfachen und gleichzeitig dafür sorgen, dass er flexibel und wartbar bleibt – auch wenn das System wächst. ### **Das Problem:** Nehmen wir an, ein Service zur Abwicklung von Regulierungsprüfungen verwendet einen „Switch-Case“-Block, um die Logik an länderspezifische Services zu delegieren. Je nach Standort des Käufers wird der passende Service ausgewählt. Dieser Ansatz funktioniert gut, solange nur wenige Länder verwaltet werden. Doch sobald die Anzahl der Länder wächst, steigt auch die Komplexität des „Switch-Case“-Blocks, was zu den bereits genannten Problemen führt: Der Code wird monolithisch, schwer wartbar, anfällig für Fehler und schwer zu erweitern. ``` @Component @RequiredArgsConstuctor public class CheckRegulationsService { private final USARegulationService usaRegulationService; private final UKRegulationService ukRegulationService; private final GermanyRegulationService germanyRegulationService; private final FranceRegulationService franceRegulationService; public String checkRegulations(String country) { switch (country.toUpperCase()) { case "USA": return usaRegulationService.check(); case "UK": return ukRegulationService.check(); case "DE": return germanyRegulationService.check(); case "FR": return franceRegulationService.check(); default: throw new IllegalArgumentException("Unsupported country: " + country); } } } ``` ### **Die Lösung: Dependency Injection, List Injection und Streams** Um dieses Problem zu lösen und den Code skalierbarer zu gestalten, bietet sich die Dependency Injection von Spring an. Eine Liste von Services kann injiziert werden, und der passende Service wird dynamisch mithilfe von Streams ausgewählt. Dieser Ansatz ist flexibel und lässt sich einfach erweitern, ohne den bestehenden Code anzupassen. Die Lösung lässt sich folgendermaßen umsetzen: ### **Schritt 1: Definition eines gemeinsamen Interfaces** Zuerst wird ein Interface `RegulationService` definiert, die von allen länderspezifischen Services implementiert wird: ``` public interface RegulationService { String getCountryCode(); String check(); } ``` Dieses Interface sorgt für eine einheitliche Struktur aller Services, was die Wartung und das Verständnis des Codes erleichtert. Standardisierte Methodensignaturen machen den Zweck eines jedes Services klarer, was die Lesbarkeit verbessert. Zudem bildet das Interface die Basis dafür, dass Spring alle länderspezifischen Services erkennt und als Liste injizieren kann. ### **Schritt 2: Implementierung länderspezifischer Services** Nachdem das Interface definiert wurde, wird es für jeden länderspezifischen Service implementiert. Die dabei resultierenden Services könnten wie folgt aussehen: ``` @Service public class USARegulationService implements RegulationService { @Override public String getCountryCode() { return "USA"; } @Override public String check() { return "USA regulations applied"; } } @Service public class UKRegulationService implements RegulationService { @Override public String getCountryCode() { return "UK"; } @Override public String check() { return "UK regulations applied"; } } ``` Jeder Service ist für die spezifische Regulierungslogik seines Landes zuständig, folgt aber einem einheitlichen Vertrag. Will man nun ein neues Land hinzufügen, muss man nur einen neuen Service erstellen, der sich vom Interface ableitet – ohne den bestehenden Code anzupassen. ### **Schritt 3: Liste von Services injizieren und Auswahl per Streams** Sobald alle Implementierungen des Interfaces vorhanden sind, kann eine Liste der Services injiziert werden. Mithilfe von Streams kann diese Liste gefiltert und der passende Service ausgewählt werden. Um den Hauptservice dabei übersichtlich zu halten, wird diese Auswahllogik in eine separate Klasse ausgelagert. Diese separate Klasse nennen wir `RegulationServiceSelector`. ``` @Component @RequiredArgsConstructor public class RegulationServiceSelector { private final List regulationServices; public RegulationService getRegulationService(String country) { return regulationServices.stream() .filter(service -> service.getCountryCode().equalsIgnoreCase(country)) .findFirst() .orElseThrow(() -> new IllegalArgumentException("No regulation service found for country: " + country)); } } ``` Der `RegulationServiceSelector` filtert die Services anhand des Ländercodes und gibt den passenden Service zurück. Wird kein passender Service gefunden, so wirft er eine Exception. ### **Schritt 4: Integration des Selektors in den Hauptservice** Nun wird der `CheckRegulationsService` so angepasst, dass der `RegulationServiceSelector` für die dynamische Auswahl des passenden Services genutzt wird. Dadurch wird der bisher benötigte „Switch-Case“-Block überflüssig. ``` @Service @RequiredArgsConstructor public class CheckRegulationService { private final RegulationServiceSelector regulationServiceSelector; public String checkRegulations(String country) { final RegulationService regulationService = regulationServiceSelector.getRegulationService(country); return regulationService.check(); } } ``` ### **Vorteile dieses Ansatzes:** - **Sauberer Code:** Die Streams vereinfachen die Logik und reduzieren die Anzahl der Abfragen. Zudem schafft das Interface einen einheitlichen Vertrag für alle Services, was Klarheit und Konsistenz fördert. - **Erweiterbarkeit:** Neue länderspezifische Services können leicht hinzugefügt werden, ohne den Hauptservice oder die Auswahllogik anpassen zu müssen. - **Klare Verantwortlichkeit:** Durch die Trennung der Verantwortlichkeiten wird das Design verbessert und die Wartbarkeit erleichtert. Der `RegulationServiceSelector` übernimmt die Auswahllogik, der Hauptservice orchestriert die Aufrufe, und die länderspezifischen Services verwalten ihre Regeln. - **Bessere Testbarkeit:** Das modulare Design ermöglicht das isolierte Testen jeder Komponente. Dies verringert den Aufwand für Mocking und erleichtert das Testen verschiedener Szenarien. All dies resultiert in einer höheren Zuverlässigkeit des Systems. ### **Schlussfolgerung:** Durch die Verwendung von Spring’s Dependency Injection und Java Streams lässt sich ein flexibler und simpel wartbarer Mechanismus zur Auswahl von Regulierungsservices entwickeln. Dieses Muster ist besonders hilfreich, wenn unterschiedliche Geschäftsregeln basierend auf Bedingungen wie Ländern, Kundentypen oder Produktkategorien angewendet werden müssen. Es sorgt für eine vereinfachte Codebasis und erleichtert die Skalierung sowie Erweiterung, wenn neue Anforderungen entstehen. _This post was originally published in English on [Medium.com](https://medium.com/miragon/use-interfaces-and-dependency-injection-instead-of-switch-case-63f54eac77c4)._ _Co-Author: Andreas Riepl_ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fswitch-case-interfaces-dependency-injection%2F)[](mailto:?subject=Wie%20sich%20komplexe%20Switch-Case-Strukturen%20durch%20Interfaces%20und%20Dependency%20Injection%20vermeiden%20lassen&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fswitch-case-interfaces-dependency-injection%2F) ## Marco Schäck Process Development Lead bei Miragon [in Marco kennenlernen](https://www.linkedin.com/in/schaeckm/) [Mehr von Marco](/blog/?author=marco-schäck) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Durchführung eines t.BPM-Workshops für die Analyse und Visualisierung von Prozessen in der Baubranche](https://www.miragon.io/blog/tbpm-workshop-baubranche/) Referenzen Wie Miragon mit der SSB Fidan GmbH in einem t.BPM-Workshop Bauprozesse von der Beauftragung bis zur Rechnungsstellung analysiert und visualisiert hat. Dominik Horn Co-Founder & Geschäftsführer **30\. Juli 2021**1 Min. Lesezeit Die SSB Fidan GmbH ist eine Spezialfirma für das Sägen, Schneiden, Bohren und Sprengen von Beton. Sie ist in ganz Bayern aktiv. ## Problem Von der Beauftragung bis hin zur Fertigstellung eines Bauvorhabens sind verschiedene Schritte notwendig, die dokumentiert werden müssen. Darunter fallen etwa die Erstellung eines Angebots, die Erfassung der Tätigkeiten inkl. aller Mehraufwände und die Übertragung der Daten in eine Rechnung. Dies passiert derzeit noch zu großen Teilen händisch in Papierform. Um diesen Prozess zu beschleunigen, verfolgt SSB Fidan das Ziel, ihn zu digitalisieren. Aus diesem Grund musste der bestehende Prozess in einem ersten Schritt erfasst und analysiert werden. ## Lösung Zu diesem Zweck haben wir [gemeinsam mit der SSB Fidan mehrere Workshops durchgeführt](/leistungen/), bei denen alle Beteiligten involviert waren. Mithilfe der t.BPM-Methode visualisierten und analysierten wir den Prozess von der Beauftragung eines Bauvorhabens über die Planung bis hin zu Erstellung und Dokumentation eines Leistungsnachweises. Dabei wurden auch evtl. auftretende Probleme im Verlauf der Erfassung berücksichtigt. Abschließend wurde der Prozess als BPMN-Diagramm digital erfasst und damit die Basis für die zukünftige Digitalisierung des Prozesses gelegt. > In kurzer Zeit konnten wir im Rahmen eines interessanten und interaktiven Workshops mit der Miragon GmbH unseren gesamten Prozess visualisieren und analysieren. Durch die Einbeziehung aller Beteiligten konnten wir sicherstellen, dass alle Fälle berücksichtigt wurden. Nun haben wir eine detaillierte Übersicht unserer Abläufe und können die nächsten Schritte in Richtung Digitalisierung gehen. _Adnan Fidan, Geschäftsführer SSB Fidan GmbH_ * * * ## Eingesetzte Technologien - t.BPM - BPMN - Camunda Modeler ## Projektkennzahlen - Beteiligt (SSB Fidan): 4 Personen - Beteiligt (Miragon): 2 Personen - Dauer: 1 Tag Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Ftbpm-workshop-baubranche%2F)[](mailto:?subject=Durchf%C3%BChrung%20eines%20t.BPM-Workshops%20f%C3%BCr%20die%20Analyse%20und%20Visualisierung%20von%20Prozessen%20in%20der%20Baubranche&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Ftbpm-workshop-baubranche%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Referenzen 02\. Jan. 2024 ### Prozessautomatisierung in der Intralogistik bei DM Wie Miragon die Intralogistik-IT von DM modernisiert – mit BPMN, Domain-Driven Design und agiler Softwareentwicklung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/prozessautomatisierung-intralogistik-dm/)[ Referenzen 01\. Jan. 2024 ### Digitale Transformation mit Dimacon Wie Miragon mit der Dimacon-Plattform das Kerngeschäft der Handwerksbranche digital transformiert – eine flexible No-Code SaaS-Lösung. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digitale-transformation-dimacon/)[ Referenzen 01\. Jan. 2022 ### DigiWF – Landeshauptstadt München Wie Miragon die Landeshauptstadt München bei der Konzeption und Umsetzung einer Plattform zur Digitalisierung und Automatisierung von Workflows unterstützt. Dominik Horn Co-Founder & Geschäftsführer ](/blog/digiwf-landeshauptstadt-muenchen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Testabdeckung für Prozesse messen](https://www.miragon.io/blog/testabdeckung-prozesse-messen/) BPM Wie die Testabdeckung bei BPMN-Prozessen gemessen, visualisiert und nachvollziehbar in die CI/CD-Pipeline integriert werden kann. Dominik Horn Co-Founder & Geschäftsführer **22\. Dez. 2020**5 Min. Lesezeit Es geht weiter mit unserer Blogreihe “Treat your processes like code – test them!”. Heute wollen wir uns ein häufig diskutiertes Thema genauer anschauen - Testabdeckung. Doch welche Rolle spielt die Coverage beim Testen von BPMN-Modellen und wie kann die Abdeckung gemessen werden? In diesen Post werden wir dazu die folgenden Fragen behandeln: - Warum brauchen wir Testabdeckung? - Wie können wir die Testabdeckung bei BPMN-Prozessen messen? - Wie können wir die Testabdeckung nachvollziehbar verfolgen? Dazu werden wir das Beispiel aus dem Post zum [Testen von Prozessabhängigkeiten](/blog/prozessabhaengigkeiten-testen/) erweitern. Dieses ist in [GitHub](https://github.com/Miragon/camunda-testing-examples) verfügbar. Außerdem gibt es einen kleinen Einblick in die Weiterentwicklung der Camunda BPM Process Test Coverage. Doch warum ist die Testabdeckung eine wichtige Kennzahl für die Entwicklung automatisierter Prozesse? Die kurze Antwort ist: Aus technischer Sicht ist die BPMN eine Programmiersprache, deshalb sollte sie wie Code behandelt werden. Eine hohe Testabdeckung bringt viele Vorteile mit sich, zum Beispiel: - **Größeres Vertrauen in das Modell:** Automatisierte Prozesse beinhalten Ablauflogik, Abhängigkeiten zu Daten und können mit der Zeit wachsen. Ist nicht sichergestellt, dass alle Pfade bei einer Änderungen noch funktionieren, wirkt sich dies negativ auf die Agilität aus. Denn fehlendes Vertrauen bei einer Änderung des Modells führt häufig dazu, dass seltener neue Versionen ausgebracht werden und Abnahmetests aufwändiger werden. - **Fehler werden frühzeitig erkannt:** Beim detaillierten Testen von Modellen können technische und fachliche Fehler im Modell frühzeitig erkannt werden. Denn nicht nur Fehler in der Ablauflogik sind relevant. Beim Testen auf technischer Ebene fallen häufig Zustände im Modell auf, die fachlich überhaupt nicht gewünscht sind. - **Tests werden definitiv ausgeführt:** Wird die Testabdeckung als Kennzahl in die Entwicklung mitaufgenommen und in die Pipeline integriert, dann führt daran kein Weg mehr vorbei. Dadurch entsteht ein größeres Vertrauen in das Deployment. Außerdem führt eine nahtlose und automatisierte Integration dazu, dass das Messen dieser Kennzahl keinen zusätzlichen Mehraufwand darstellt. ## Wie kann Testabdeckung bei der Entwicklung automatisierter Prozesse überwacht werden? Dafür gibt es eine Community Erweiterung: die [Camunda BPM Process Test Coverage](https://github.com/camunda/camunda-bpm-process-test-coverage). Diese visualisiert und überprüft den Abdeckungsgrad des Prozessmodells. Das Ausführen von JUnit-Tests erzeugt html-Dateien im Build-Ordner. Diese sehen wie folgt aus: Die Erweiterung bietet dabei folgende Features: - Visualisierung der Ergebnisse von Testmethoden und Testklassen im BPMN-Modell - Visualisierung von Expressions an Sequenzflüssen und Service-Tasks - Visualisierung von Transaktionsgrenzen - Berechnung und Visualisierung des Abdeckungsgrads Erweitern wir dazu unser Beispiel. Hierfür brauchen wir zunächst die Branch `02_process_dependencies` aus unserem [GitHub-Repository](https://github.com/Miragon/camunda-testing-examples). Für den ersten Setup sind lediglich 3 Schritte notwendig: 1. **Maven-Dependencies** hinzufügen Dafür fügen wir der `pom.xml` die folgende Dependency hinzu: ``` org.camunda.bpm.extension camunda-bpm-process-test-coverage 0.3.2 test ``` 2. `camunda-cfg.xml` anpassen ``` ... ``` 3. **TestCoverageProcessEngineRule** im Test verwenden Passen wir dafür unseren `WorkflowTest` an und ändern unsere `@Rule` wie folgt: ``` @Rule @ClassRule public static TestCoverageProcessEngineRule rule = TestCoverageProcessEngineRuleBuilder.create() .excludeProcessDefinitionKeys(DELIVERY_PROCESS_KEY) .build(); ``` Wichtig ist, dass wir den `Delivery Process` von der Coverage ausschließen. Denn dieser wird im Test lediglich als Mock bereitgestellt und steht somit nicht zur Verfügung. Nun können wir den Test ausführen. Die Testergebnisse landen unter `./target/process-test-coverage`. Wir sehen, dass 95% Coverage erreicht wurden, obwohl alles erfolgreich getestet wurde. Dies liegt jedoch an einem Bug in der Coverage-Library, die Compensation-Events nicht richtig nachverfolgt. ## Coverage-Minimum festlegen Schauen wir uns nun an, wie wir ein Coverage-Minimum definieren können, das automatisch geprüft wird. Hierfür haben wir zwei Möglichkeiten: - Coverage auf Klassenebene - Coverage auf Methodenebene Diese sind ebenfalls miteinander kombinierbar. Auf Klassenebene können wir die Coverage wie folgt definieren: ``` @Rule @ClassRule public static TestCoverageProcessEngineRule rule = TestCoverageProcessEngineRuleBuilder.create() .excludeProcessDefinitionKeys(DELIVERY_PROCESS_KEY) .assertClassCoverageAtLeast(0.9) .build(); ``` Eine Coverage von `1.0` ist auch aufgrund der vorhandenen Bugs nicht zu empfehlen. Auf Methodenebene können wir eine Coverage-Assertion wie folgt hinzufügen: ``` @Test public void shouldExecuteHappyPath() { Scenario.run(testOrderProcess) .startByKey(PROCESS_KEY, withVariables(VAR_CUSTOMER, "john")) .execute(); verify(testOrderProcess) .hasFinished(END_EVENT_ORDER_FULLFILLED); rule.addTestMethodCoverageAssertionMatcher("shouldExecuteHappyPath", greaterThanOrEqualTo(0.5)); } ``` Dabei stehen uns verschiedene `org.hamcrest.Matchers` zur Verfügung, für diesen Anwendungsfall sind folgende sinnvoll: - `greaterThan` - `greaterThanOrEqualTo` - `lessThan` - `lessThanOrEqualTo` Die Camunda BPM Process Test Coverage bietet noch ein paar weitere Features, wie das Ausschalten der Coverage auf Klassen- oder Methodenebene. Es lohnt sich somit einen Blick in das [GitHub-Repository](https://github.com/camunda/camunda-bpm-process-test-coverage) zu werfen. ## Nachvollziehbare Testabdeckung Die grafische Darstellung der Testabdeckung in Form von HTML-Dateien ist für die lokale Entwicklung ausreichend. Es gibt jedoch speziell zwei Bereiche in denen die Library an ihre Grenzen stößt: ### Nachvollziehbarkeit Die Testabdeckung ist eine großartige Kennzahl, wenn wir sie messen. Aber messen bedeutet auch, dass wir die historischen Daten im Auge behalten. Es geht darum, Verbesserungen oder Verschlechterungen transparent zu machen und damit für Motivation und Nachvollziehbarkeit zu sorgen. Dies bedeutet, dass wir eine Lösung brauchen, um die erstellten Reports zu sammeln und grafisch aufzubereiten. ### CI/CD Integration Auf der einen Seite haben wir die lokale Entwicklung. Dort wird zunächst der Prozess angepasst, dann der dazugehörige Test implementiert und ausgeführt, das Testergebnis geprüft und anschließend beginnt alles von vorn. Ist das Modell und der Test fertiggestellt, wird der entsprechende Code ins Git-Repository gepusht. In der Build-Pipeline wird dann der Test erneut durchgeführt. Doch wie werden bspw. bei einer Pull-Request die Ergebnisse visualisiert? Wie kann eine Veränderung der Coverage zum vorherigen Stand nachvollzogen werden? Mit der Camunda BPM Process Test Coverage ist das nicht out-of-the-box möglich. Unter anderem aus diesen Gründen haben wir [FlowCov](https://flowcov.io/) entwickelt – eine Plattform, die genau diese Anforderungen abdeckt. Sie ermöglicht es, im Rahmen der eigenen Build-Pipeline die generierten Reports hochzuladen, um sie grafisch aufzubereiten und allen Stakeholdern zugänglich zu machen. Wie das aussieht, zeigen wir dir im Beitrag zur [nachvollziehbaren Test-Coverage für alle Prozess-Stakeholder](/blog/nachvollziehbare-test-coverage-prozess-stakeholder/), und wer noch tiefer einsteigen will, dem empfehlen wir unsere [Docs](https://docs.flowcov.io/). ## Ausblick und Entwicklung Momentan wird die Camunda BPM Process Test Coverage neu entwickelt. Dabei werden verschieden Anpassungen und Features umgesetzt: - Möglichkeit zur Implementierung in Junit5 - Trennung von Coverage-Messung und Report-Erzeugung - Neuentwicklung des lokalen HTML-Reports - Nahtlose Integration in [FlowCov](https://flowcov.io/) (ohne eigene Rule möglich) - Möglichkeit zur Verwendung für Integrationstests Falls du Lust hast mitzuwirken und eigene Ideen einbringen möchtest, würden wir uns über Contributions und Diskussionen freuen! Die Neuentwicklung findet in diesem Fork statt: [https://github.com/holunda-io/camunda-bpm-process-test-coverage/tree/develop/extension](https://github.com/holunda-io/camunda-bpm-process-test-coverage/tree/develop/extension) Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Ftestabdeckung-prozesse-messen%2F)[](mailto:?subject=Testabdeckung%20f%C3%BCr%20Prozesse%20messen&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Ftestabdeckung-prozesse-messen%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Warum übergreifende BPMN-Prozesse gefährlich für moderne Organisationen sind](https://www.miragon.io/blog/uebergreifende-bpmn-prozesse-gefaehrlich/) BPM Zentrale BPMN-Prozesse führen zu organisatorischer Kopplung und behindern Teamautonomie. Warum Choreografie besser ist als Orchestrierung. Dominik Horn Co-Founder & Geschäftsführer **27\. März 2025**4 Min. Lesezeit In vielen Unternehmen gelten übergreifende, sogenannte Ende-zu-Ende-Prozesse in BPMN noch immer als Königsweg der Prozessoptimierung. Schließlich versprechen sie Transparenz, Standardisierung und Effizienz über Abteilungs- und Teamgrenzen hinweg. Doch diese Herangehensweise hat ihren Preis – sie führt zu Kopplung. Und Kopplung ist Gift für jede skalierende Organisation. ## Die unsichtbare Gefahr: Organisatorische Kopplung Ein übergreifender BPMN-Prozess beschreibt oft nicht nur den “Happy Path”, sondern auch detaillierte Entscheidungen und Abläufe, die eigentlich innerhalb einzelner Teams stattfinden sollten. Das Problem: Sobald zentrale Prozesse diese Details festlegen, greifen sie tief in die Arbeitsweise autonomer Teams ein. Das Resultat ist organisatorische Kopplung: Teams sind können innerhalb ihrer Grenzen nicht selbst Veränderungen und Optimierungen vornehmen. ## Team Topologies und Fracture Planes: Warum Autonomie zählt Die Erkenntnisse aus **Team Topologies** liefern hier wertvolle Impulse. Dort wird beschrieben, dass **Software- und Organisationsarchitektur Hand in Hand** gehen müssen. > 💡 Das Buch zu Team Topologies bietet eine ausführliche Einführung in das Thema. Dort erwarten Dich viele weitere spannende Themen wie Conway’s Law, Team Types und Interaction Modes! Ein zentrales Konzept dabei: **Fracture Planes** – natürliche Bruchlinien, entlang derer man ein System sinnvoll aufteilen kann. Dazu zählen z. B. Domänen (Bounded Contexts), Compliance-Anforderungen oder Veränderungen in der Technologie. Ein übergreifender Prozess, der die interne Logik mehrerer Teams orchestriert, verletzt diese Bruchlinien. Er erzeugt implizite Abhängigkeiten zwischen Teams, die eigentlich entlang dieser Fracture Planes getrennt sein sollten – zum Beispiel entlang von **Bounded Contexts** in DDD (Domain Driven Design). Die Folge: Fehlende Flexibilität, lange Abstimmungszyklen und eine Organisation, die schlecht auf Veränderungen reagieren kann. > 💡 Wer mit Domain Driven Design und dem Konzept des Bounded Contexts noch nicht vertraut ist, bekommt in diesem Video einen kompakten Überblick über das Thema: [https://www.youtube.com/watch?v=4rhzdZIDX\_k](https://www.youtube.com/watch?v=4rhzdZIDX_k) ## Conway’s Law und der Irrtum zentraler Orchestrierung **Conway’s Law** sagt: „Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.“ Will heißen: Wenn Teams stark gekoppelt arbeiten müssen, spiegeln sich diese Abhängigkeiten früher oder später auch in der Software wider – in Form von Monolithen, komplexer Prozesslogik und fehlender Modularität. Ein BPMN-Prozess, der Entscheidungen über mehrere Teams hinweg trifft, widerspricht also nicht nur dem Gedanken von Teamautonomie, sondern auch den Prinzipien von skalierbarer, dezentraler Architektur. ## Die Lösung: Orchestrierung an den Rändern – nicht im Inneren Statt übergreifende Prozesse zentral zu orchestrieren, braucht es einen Paradigmenwechsel: - **Keine Einmischung in die interne Orchestrierung von Teams**: Jedes Team ist Herr über seine internen Abläufe und Prozesse. Ein übergreifender Prozess darf hier nicht eingreifen. - **Orchestrierung über Schnittstellen, nicht über Details**: Wenn eine übergreifende Koordination notwendig ist, dann über explizite Schnittstellen – beispielsweise über Events, APIs oder klar definierte Kontrakte an den Boundaries. - **Choreografie statt Orchestrierung**: In vielen Fällen ist eine lose gekoppelter Ansatz über Choreografie der bessere Weg. Hier reagieren Teams auf Events, treffen eigene Entscheidungen und behalten ihre Autonomie. Der Vorteil: Hohe Resilienz, bessere Skalierbarkeit, schnellere Anpassungsfähigkeit. * * * ## Beispiel: Order-Fulfillment mit und ohne Kopplung Schauen wir uns dazu einen vereinfachten Order-Fulfillment-Prozess an. Um das Beispiel greifbarer zu machen, konzentrieren wir uns dabei speziell auf den Bezahlvorgang innerhalb des Gesamtprozesses. Gerade hier zeigt sich besonders deutlich, wie eine zentrale Orchestrierung schnell zu unerwünschter Kopplung zwischen Teams und Domänen führen kann – und wie man dies durch saubere Abgrenzung entlang von Fracture Planes vermeiden kann. ### Die Ausgangslage – klassisch übergreifend Viele Prozessmanager:innen in Organisationen streben übergreifende Abläufe an, die in Prozessen enden, die wie folgt aussehen: Der Order-Fulfillment-Prozess orchestriert unter anderem direkt den Bezahlvorgang. Das Prozessmodell legt fest, wann und wie bezahlt wird – inklusive aller Fehlerbehandlungen, Rückmeldungen und Eskalationen. Die ist aus mehreren Gründen problematisch: - **Kopplung an Implementierungsdetails:** Der Fulfillment-Prozess kennt Details über Zahlungslogik (z. B. Retry-Strategien, Fraud Checks). - **Verletzung von Team-Grenzen:** Änderungen in der Payment-Domäne (z. B. Einführung von Stripe) erfordern Änderungen im zentralen Prozess. Dies wiederum führt dazu, dass teamübergreifende Abstimmungen notwendig werden. - **Geringe Eigenverantwortung:** Das Payment-Team kann ihren Prozess nicht selbstständig optimieren oder erweitern. Diese Form der zentralen Prozesssteuerung ignoriert die natürlichen **Fracture Planes** zwischen Order und Payment – z. B. unterschiedliche Verantwortlichkeiten, rechtliche Anforderungen, Release-Zyklen, usw. * * * ## Die Lösung: Entkopplung über Domänengrenzen In der entkoppelten Version respektieren wir den Fracture Plan. Der Order-Prozess orchestriert nicht mehr, sondern kommuniziert über klare Schnittstellen: **Was sich verbessert:** - **Bounded Contexts werden respektiert:** Payment ist eine eigenständige Domäne mit eigener Logik und Verantwortung. - **Teams sind autonom:** Das Payment-Team kann unabhängig iterieren, Technologien wechseln oder Abläufe optimieren – solange das Event-Interface stabil bleibt. Der Order-Prozess kann weiterhin in der Verantwortung eines Teams bleiben – ohne dass dieses Team die fachlichen Details anderer Domänen mitverantworten muss. ## Fazit: Die Teamstruktur muss zu den Domänen passen, Prozesse liegen dann innerhalb der Domänen. Übergreifende BPMN-Prozesse sind ein Relikt aus Zeiten zentraler Steuerung und Kontrolle. In modernen, teamzentrierten Organisationen mit klaren Fracture Planes und Bounded Contexts **sollten Prozesse entlang der Teamgrenzen geschnitten werden** – nicht darüber hinweg. Die Zukunft gehört leichtgewichtiger Koordination, klaren Schnittstellen und dezentraler Entscheidungsfindung. Nur so entsteht eine Organisation, die wirklich beweglich, skalierbar und anpassungsfähig ist. Du willst dein Team lernen lassen, Prozesse sauber entlang von Teamgrenzen zu schneiden? [Mehr zu unserem BPMN-Training](/trainings/bpmn-training/). Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fuebergreifende-bpmn-prozesse-gefaehrlich%2F)[](mailto:?subject=Warum%20%C3%BCbergreifende%20BPMN-Prozesse%20gef%C3%A4hrlich%20f%C3%BCr%20moderne%20Organisationen%20sind&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fuebergreifende-bpmn-prozesse-gefaehrlich%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Vollständige Prozesspfade testen](https://www.miragon.io/blog/vollstaendige-prozesspfade-testen/) BPM Wie man vollständige Prozesspfade in BPMN testet - mit camunda-bpm-assert-scenario für effiziente und klare Testfälle. Dominik Horn Co-Founder & Geschäftsführer **27\. Okt. 2020**5 Min. Lesezeit Ursprünglich am 27.10.2020 auf dem offiziellen Camunda Blog gepostet: [https://camunda.com/blog/2020/10/testing-entire-process-paths/](https://camunda.com/blog/2020/10/testing-entire-process-paths/) Warum sollte ich meine Modelle testen? Die kurze Antwort ist: Aus technischer Sicht ist BPMN eine Programmiersprache. Deshalb sollten die Diagramme wie Code behandelt werden. Dafür steht inzwischen eine Vielzahl an Bibliotheken bereit, die das Testen vereinfachen. Viele dieser Bibliotheken werden wir genauer unter die Lupe nehmen, darunter: - [camunda-bpm-assert](https://github.com/camunda/camunda-bpm-assert) - [camunda-bpm-assert-scenario](https://github.com/camunda/camunda-bpm-assert-scenario) - [camunda-bpm-mockito](https://github.com/camunda/camunda-bpm-mockito) - [camunda-bpm-jgiven](https://github.com/holunda-io/camunda-bpm-jgiven) - [flowcov-camunda](https://github.com/Miragon/flowcov-camunda) - [camunda-bpm-process-test-coverage](https://github.com/camunda/camunda-bpm-process-test-coverage) Beim Testen von Modellen stellen sich häufig Fragen wie: - Wann und wie setze ich die verschiedenen Bibliotheken ein? - Was soll genau getestet werden - das Modell und der ausgeführte Code? - [Wie gehe ich mit Abhängigkeiten zu anderen Modellen um?](/blog/prozessabhaengigkeiten-testen/) - [Wie messe ich meine Testabdeckung?](/blog/testabdeckung-prozesse-messen/) Mit diesen Fragen beschäftigt sich unsere neue Blogreihe “Treat your processes like code - test them!” Wir wollen Best Practices und Vorgehensweisen sammeln, um das Testen zu vereinfachen. An dieser Stelle gibt es eine kleine Leseempfehlung - die [Camunda Best Practices](https://camunda.com/best-practices/testing-process-definitions/) zum Thema Testing. Wir werden uns in den ersten Posts überwiegend im ersten Test-Scope bewegen und Unit Tests mit Java schreiben. ## Testen vollständiger Prozesspfade _Die Implementierung für diesen Post liegt in [diesem GitHub-Repository](https://github.com/Miragon/camunda-testing-examples)._ Schauen wir uns dazu folgenden Prozess zur Auftragsabwicklung an: “Vollständige Prozesspfade” bedeutet von Anfang bis Ende zu testen. Bei komplexen Modellen haben wir schon häufig gesehen, dass Testfälle nur Teile abdecken. In unserem Prozess wäre ein Beispiel dafür, wenn der Abbruch der Bestellung und die Stornierung separat getestet werden. Der Grund für dieses Vorgehen kann sein, dass die Abläufe davor und danach schon getestet sind oder die einzelnen Testfälle dann viel größer und aufwendiger in der Anpassungen werden. Aus folgenden Gründen sollten jedoch immer vollständige Prozesspfade getestet werden: - **Abhängigkeiten im Prozess werden berücksichtigt**: Änderungen an Elementen, die im Prozess davor oder danach durchlaufen werden, können Auswirkungen haben. Insbesondere bei Änderungen an Variablen, die zur Abarbeitung benötigt werden. - **Definition von Testfällen wird vereinfacht**: Das klingt im ersten Moment widersprüchlich. Doch haben wir die Erfahrung gemacht, dass die Betrachtung vollständiger Prozessfalle, die Definition von Testfällen vereinfacht. Insbesondere, wenn in alternativen Szenarien, nur das abweichende Verhalten von Aktivitäten und Daten betrachtet wird. - **Anpassungen im Prozess werden leichter**: Dadurch, dass immer der gesamte Ablauf betrachtet wird, können Anpassungen am Prozess mit größerer Sicherheit gemacht werden. Es gibt jedoch auch Fälle, in denen es durchaus sinnvoll ist, einzelne Aktivitäten eines Prozesses zu testen. Ein Beispiel hierfür sind wiederverwendbare Komponenten. Der Task “Send cancellation” könnte bspw. ein wiederverwendbarer Service Tasks zum Senden von E-Mails sein. Dieser sollte jedoch dann nicht isoliert im Prozess zur Auftragsabwicklung getestet werden, sondern in einem eigenen Scope. Mit der [camunda-bpm-assert](https://github.com/camunda/camunda-bpm-assert) Bibliothek können diese kleinen, wiederverwendbaren Komponenten sehr einfach getestet werden. Das Testen von komplexeren Abläufe führt jedoch zu redundantem oder unübersichtlichen Code. Für das Testen vollständiger Prozesspfade steht deshalb die [camunda-bpm-assert-scenario](https://github.com/camunda/camunda-bpm-assert-scenario) bereit. Schauen wir uns nun ein Vorgehen an, wie mit dieser Library ganze Prozesspfade einfach und effizient getestet werden können. Wer diese Projekt noch nicht kennt, kann zunächst einen genauen Blick ins [GitHub Repository](https://github.com/camunda/camunda-bpm-assert-scenario) werfen. **Standardverhalten definieren**: Zunächst wird für alle Elemente ein Standardverhalten definiert. Dies gilt auch für Aufgaben, die nicht auf dem “Happy-Path” liegen, wie der “Cancel Order” Task. Dadurch muss in den einzelnen Szenarien nur noch die Abweichung neu definiert werden. ``` @Before public void defaultScenario() { MockitoAnnotations.initMocks(this); Mocks.register("sendCancellationDelegate", new SendCancellationDelegate()); //Happy-Path when(testOrderProcess.waitsAtUserTask(TASK_CHECK_AVAILABILITY)) .thenReturn(task -> { task.complete(withVariables(VAR_PRODUCTS_AVAILABLE, true)); }); when(testOrderProcess.waitsAtUserTask(TASK_PREPARE_ORDER)) .thenReturn(TaskDelegate::complete); when(testOrderProcess.waitsAtUserTask(TASK_DELIVER_ORDER)) .thenReturn(task -> { task.complete(withVariables(VAR_ORDER_DELIVERED, true)); }); //Further Activities when(testOrderProcess.waitsAtUserTask(TASK_CANCEL_ORDER)) .thenReturn(TaskDelegate::complete); } ``` **Aktivitäten mit weiterem Verhalten erkennen**: In diesem Schritt geht es darum, Aktivitäten zu erkennen, die einen alternativen Output liefern, sodass der Prozess einen weiteren Pfad nimmt. Häufig stehen diese Aktivitäten vor Inklusiven oder Exkulsiven Gateways. In unserem Beispiel trifft das auf zwei Tasks zu. Der Task “Deliver order” hat sogar zwei weitere Szenarien. - Die Bestellung konnte nicht erfolgreich zugestellt werden und es wird am nächsten Tag nochmals versucht - Die Zustellung ist nicht möglich und die Bestellung muss storniert werden. Nachdem die unterschiedlichen Szenarien erkannt wurde, können nun die spezifischen Testfälle implementiert werden. **Implementierung der Testfälle**: Um die Implementierung so einfach wie möglich zu halten, werden nur Variablen berücksichtigt, die für den Ablauf des Prozesses relevant sind. **Happy Path** Hierfür muss lediglich das Scenario gestartet werden. Danach kann geprüft werden ob bestimmte Elemente oder End Events abgeschlossen wurden. ``` @Test public void shouldExecuteHappyPath() { Scenario.run(testOrderProcess) .startByKey(PROCESS_KEY) .execute(); verify(testOrderProcess) .hasFinished(END_EVENT_ORDER_FULLFILLED); } ``` **Send Cancellation** Hierfür muss der Task “Check availability” überschrieben werden: ``` @Test public void shouldExecuteCancellationSent() { when(testOrderProcess.waitsAtUserTask(TASK_CHECK_AVAILABILITY)).thenReturn(task -> { task.complete(withVariables(VAR_PRODUCTS_AVAILABLE, false)); }); Scenario.run(testOrderProcess) .startByKey(PROCESS_KEY) .execute(); verify(testOrderProcess) .hasFinished(END_EVENT_CANCELLATION_SENT); } ``` **Cancel Order** Hierfür ist es notwendig, einen Error im Task “Deliver Order” zu werfen, anstatt diesen abzuschließen. ``` @Test public void shouldExecuteOrderCancelled() { when(testOrderProcess.waitsAtUserTask(TASK_DELIVER_ORDER)).thenReturn(task -> { taskService().handleBpmnError(task.getId(), "OrderCancelled"); }); Scenario.run(testOrderProcess) .startByKey(PROCESS_KEY) .execute(); verify(testOrderProcess) .hasCompleted(TASK_CANCEL_ORDER); verify(testOrderProcess) .hasFinished(END_EVENT_ORDER_CANCELLED); } ``` **Deliver twice** Um den Loop mit dem Timer Event zu durchlaufen und anschließend den Prozess abzuschließen, müssen für den Task “Deliver Order” zwei verschiedene Szenarien definiert werden. ``` @Test public void shouldExecuteDeliverTwice() { when(testOrderProcess.waitsAtUserTask(TASK_DELIVER_ORDER)).thenReturn(task -> { task.complete(withVariables(VAR_ORDER_DELIVERED, false)); }, task -> { task.complete(withVariables(VAR_ORDER_DELIVERED, true)); }); Scenario.run(testOrderProcess) .startByKey(PROCESS_KEY) .execute(); verify(testOrderProcess, times(2)) .hasCompleted(TASK_DELIVER_ORDER); verify(testOrderProcess) .hasFinished(END_EVENT_ORDER_FULLFILLED); } ``` ## Fazit Mit der [camunda-bpm-assert-scenario](https://github.com/camunda/camunda-bpm-assert-scenario) Bibliothek ist es sehr einfach vollständige Prozesspfade zu testen. Mit dem zuvor beschrieben Vorgehen, lassen sich die definierten Tests effizient und übersichtlich umsetzen. Aber was ist mit Code Abhängigkeiten oder eingebunden Call Activities? Sollen diese mitgetestet werden oder mit Mocking Frameworks versteckt werden? Diesem Thema widmen wir uns im nächsten Post. Bleibt dran! Falls euch weitere Themen im Testing Bereich interessieren oder ihr eigene Erfahrung teilen wollt, schreibt uns! Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fvollstaendige-prozesspfade-testen%2F)[](mailto:?subject=Vollst%C3%A4ndige%20Prozesspfade%20testen&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fvollstaendige-prozesspfade-testen%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Vom Studenten zum Lehrbeauftragten](https://www.miragon.io/blog/vom-studenten-zum-lehrbeauftragten/) Miragon Dominik Horn erzählt seinen Weg vom BPM-begeisterten Studenten über die IT-Beratung zur Gründung der Miragon GmbH und zum Lehrauftrag an der Hochschule Augsburg. Dominik Horn Co-Founder & Geschäftsführer **27\. Mai 2020**3 Min. Lesezeit Mein Name ist Dominik Horn, ich bin 27 Jahre alt und Mitgründer der Miragon GmbH. Während meines Studiums an der Hochschule Reutlingen kam ich das erste Mal mit Prozessmanagement und -automatisierung in Berührung. Ich arbeitete in einem lokalen Startup und konnte dabei erste Erfahrungen bei der Automatisierung von Prozessen sammeln – mein Interesse war geweckt. Durch den Einsatz von RFID-Technologie digitalisierten und automatisierten wird Abläufe in den verschiedensten Bereichen – von der Gastronomie bis hin zur Qualitätssicherung an Fertigungslinien. Als ich 2015 mein Master-Studium an der [Hochschule Augsburg](https://www.hs-augsburg.de/) begann, fokussierte ich mich weiter auf diesen Bereich. Ich hatte das Glück, an Gastvorträgen von Matus Mala zum Thema Process-Engine teilnehmen zu können. Ich richtete meinen gesamten Fokus in den Projekt- und Studienarbeiten darauf, mein Wissen auf diesem Gebiet weiter zu vertiefen. [Camunda](https://camunda.com/) begleitete mich dabei als Softwareprodukt vom ersten Tag an. Durch meinen Einsatz konnte ich noch vor Abschluss meines Studiums erste eigene Vorlesungen zum Thema BPM halten und dadurch wertvolle Erfahrungen für spätere Schulungen sammeln – auch wenn ich mir gelegentlich anhören musste, dass in jedem meiner Sätze das Wort „Prozess“ oder „Camunda“ vorkommt… Mit meiner Abschlussarbeit, die den zugegeben etwas sperrigen Titel „Analyse und Umsetzung von Verbesserungspotentialen im Business Process Management durch den Einsatz von CMMN und DMN“ trug, startete ich meine berufliche Laufbahn bei der it-economics, einer IT-Beratungsfirma in München. Gemeinsam mit Matus Mala baute ich dort den Geschäftsbereich Prozessmanagement und -automatisierung auf. Wir wurden zertifizierter Camunda-Partner und betreuten mehrere Projekte, bei denen wir die Process-Engine einsetzten. Dabei ging der Kontakt zur Hochschule Augsburg über die letzten 3 Jahre nie verloren. In zahlreichen Gastvorträgen und Schulungen in den BPM-Vorlesungen von Prof. Müssigmann, versuchte ich den Studenten mein gesammeltes Wissen und meine Erfahrungen weiterzugeben. Ich betreute die verschiedensten Projektarbeiten und konnte mit engagierten Studenten an zukunftsrelevanten BPM-Themen forschen. Nach über zwei Jahren Beratung, Pendeln und anspruchsvollen Projekten brauchte ich eine Veränderung. Ich suchte nach einer neuen Herausforderung, bei der ich mehr Zeit für eigene Projekte und mehr Verantwortung haben würde. Auf der CamundaCon 2019 in Berlin wurde dann der Gedanke der Selbständigkeit geboren. Diese Idee teilte ich mit Alexander Praschek. Wir hatten die letzten 3 Jahre gemeinsam in einem Team gearbeitet, das mehrere Prozessframeworks im Banking-Umfeld umgesetzt hatte. Wie sich herausstellte, hatte auch er das mittelfristige Ziel, ein eigenes Unternehmen zu gründen. In den folgenden Monaten konkretisierten wir unsere Idee und gründeten schließlich am 01. Januar 2020 die Miragon GmbH. Wir sind begeistert von den Themen und Herausforderungen im Bereich der Automatisierung von Geschäftsprozessen und sind überzeugt davon, dass Unternehmen für ihre Kernprozesse eigene Software entwickeln sollten. Nur so wird die notwendige Flexibilität geschaffen, auf Veränderungen schnell reagieren zu können und sich vom Wettbewerb zu unterscheiden. Diese Begeisterung für Automatisierungsthemen ist es, die dazu geführt hat, dass ich nun Lehrbeauftragter der Hochschule Augsburg bin. Nach zahlreichen Jahren der Zusammenarbeit mit Prof. Müssigmann, freut es mich, dass er mir einen Lehrauftrag angeboten hat und ich nun offiziell Teil des Lehrstuhls bin. Es macht mir Spaß, den Informatik- und Wirtschafsinformatik-Studenten Automatisierungstechnologien näherzubringen und zu zeigen, welche Möglichkeiten hinter der Modellierungssprache BPMN stecken. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fvom-studenten-zum-lehrbeauftragten%2F)[](mailto:?subject=Vom%20Studenten%20zum%20Lehrbeauftragten&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fvom-studenten-zum-lehrbeauftragten%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Miragon 11\. Okt. 2022 ### Mac einrichten leicht gemacht - mit Ansible Wie Ansible die Einrichtung und Wartung von MacBooks automatisiert - von Homebrew-Installation bis zur Verwaltung von Git-Repositories. Lukas Mösle Consultant ](/blog/mac-einrichten-leicht-gemacht-ansible/)[ Miragon 08\. Juni 2020 ### Mehr in weniger Zeit - mit den richtigen Tools Welche Tools wir bei Miragon verwenden, um effizient zu arbeiten - von Office 365 und Microsoft Teams bis hin zu GitHub und JetBrains. Alexander Praschek Co-Founder ](/blog/mehr-in-weniger-zeit-richtigen-tools/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Handlungsspielräume in Prozesslandschaften mit Wardley-Mapping identifizieren](https://www.miragon.io/blog/wardley-mapping-prozesslandschaften/) BPM Wie Wardley Mapping strategische Klarheit in Prozesslandschaften schafft und Handlungsspielräume aufzeigt. Thomas Heinrichs Solution Architecture Lead **10\. März 2025**9 Min. Lesezeit Vor kurzem hat mich mein Kollege Dominik auf ein faszinierendes Mapping-Tool für strategische Entscheidungsfindung aufmerksam gemacht. Zunächst war ich skeptisch, aber nach ein paar Wochen und einem tiefen Einblick in die Methodik war ich fasziniert. Das Tool heißt Wardley-Mapping. Es ist bekannt für seine Wirksamkeit bei strategischen Entscheidungen, insbesondere in der IT. In letzter Zeit hat es in der Community für Domain Driven Designs (DDD) an Popularität gewonnen, da es hilft zu entscheiden, ob Komponenten gebaut oder gekauft werden sollen. Ich habe Wardley-Mapping in internen Strategieworkshops bei Miragon angewendet und festgestellt, dass es sich nahtlos auf Geschäftsprozessmanagement anwenden lässt. Es führt nicht nur zu guten strategischen Entscheidungen, sondern ermöglicht auch das Abbilden verschiedener Zukunftsszenarien für Prozesslandschaften. In diesem Post werde ich dich Schritt für Schritt durch diese Technik führen und sie auf ein zunehmend komplexes Geschäftsprozessszenario anwenden. Wir beginnen mit einer vereinfachten Map zur Klassifizierung von Prozessen, dann widmen wir uns einem detaillierten, kundenorientierten Beispiel und schließen mit Beziehungen und Abhängigkeiten in den Maps ab. Anschließend zerlegen wir die aktuelle Map und erkunden mögliche zukünftige Zustände. Dieser Blog-Post stellt dir ein praktisches Werkzeug vor, um proaktive Entscheidungen bezüglich der Prozesslandschaft in deinem Unternehmen zu treffen. So kannst du Investitionspotentiale identifizieren und Bereiche mit geringerem ROI erkennen, um dort effizienter zu werden. Wardley-Mapping, entwickelt von Simon Wardley im Jahr 2005, zielt darauf ab, neue Gelegenheiten zu identifizieren, Verschwendungen zu eliminieren und Teams bei der Formung der Unternehmensstrategie zu unterstützen. Da die Geschäftsprozesslandschaft entscheidend für den Erfolg eines Unternehmens ist, kann sie zwischen disruptivem Erfolg und Insolvenz entscheiden. Inspiriert davon, dass herkömmlicher Werkzeuge wie der SWOT-Analyse nicht ausreichend sind, erkannte Wardley, dass die Visualisierung strategischer Elemente auf einer Karte, basierend auf historischen und militärischen Kontexten, die Entscheidungsfindung verbessern könnte. Die untenstehende Abbildung zeigt die Evolution auf der x-Achse (von Genesis bis Commodity) und den Kundennutzen auf der y-Achse. Das Evolution-Konzept ist hier entscheidend. - **Genesis** umfasst Versuche im Unbekannten, wie z. B. die Integration von agentenbasierter KI in Kundenaufnahmeprozesse oder das Design neuer Geschäftsprozesse. Es kann auch infrastrukturelle Innovationen wie revolutionäre Prozessengines beinhalten, die einen Wettbewerbsvorteil verschaffen. - **Custom-Built** repräsentiert selbst entwickelte Lösungen, die uns von der Konkurrenz abheben und einen substantiellen Kundennutzen bieten, aber nicht so neu wie Genesis sind. Ein Beispiel ist Know Your Customer (KYC), bei dem die meisten Banken ähnliche Lösungen entwickeln. - **Produkt** bezieht sich auf Komponenten, die wir kaufen oder mieten, anstatt sie selbst zu erstellen. Ein Beispiel ist ein HR-System wie Personio. Die Neuentwicklung von HR-Prozessen mit Pro-Code fügt dem Kunden nicht notwendigerweise einen Mehrwert zu, daher ist eine fertige Lösung sinnvoller. - **Commodity** umfasst Outsourcing oder effizienz-fokussierte Methoden wie Six Sigma. Da Geschäftsprozesse selbst meist zu wichtig sind, um gesamtheitlich ausgelagert zu werden, gilt dieser Bereich oft für infrastrukturelle Elemente wie das Betreiben von Prozessengines in einer Cloud-Umgebung. Diese vereinfachte Wardley Map bietet einen klaren Überblick über die entscheidenden Aspekte deines Geschäfts. Sie hilft dir dabei, Wertschöpfung sichtbar zu machen und Bereiche zu identifizieren, in die du zukünftig investieren möchtest. Wenn deine Karte keine Genesis-Elemente zeigt, verfolgst du möglicherweise keine disruptiven Möglichkeiten, was zu einem verpassten Wettbewerbsvorteil führen könnte. Du solltest auch deine Ausgaben in Bereichen geringen Werts hinterfragen. Beispielsweise solltest du dir überlegen, ob sich der hohe Aufwand für maßgeschneiderte Talent-Management-Lösungen lohnt. Fertige Lösungen könnten sinnvoller sein. Schon zu diesem frühen Stadium kannst du Chancen erkennen und deine bestehenden Investitionen kritisch hinterfragen. Von allgemeinen Prozesslandschaften bis hin zu einzelnen Abläufen – du kannst deine Wardley Map so detailliert gestalten, wie es für strategische Entscheidungen nötig ist. Nun drehen wir den Fokus, um einen einzelnen Prozess genauer zu betrachten und seine aktuelle Position sowie mögliche zukünftige Entwicklungen zu analysieren. ## Hinzufügen von Beziehungen und Kundennutzen Zoomen wir näher ran und fokussieren uns auf einen konkreten Geschäftsprozess, sagen wir mal „Customer Onboarding“. Dieser Prozess bringt uns einen deutlichen Mehrwert und ist für Kunden direkt sichtbar, daher eignet er sich hervorragend als nächstes Element für unsere Karte. Auf dieser fortgeschrittenen Karte führen wir einen Anker ein – den Kunden. Wir kartieren die Bedürfnisse des Nutzers rund um den Onboarding-Prozess ein und listen die Komponenten auf, die erforderlich sind, um diese Bedürfnisse zu erfüllen. Diese Komponenten sind über eine Wertkette miteinander verbunden. Vergiss nicht, dass diese Karte kein statisches Bild ist. Sie zeigt Entwicklungen mit der Zeit. Ein Element, das heute noch in der Genesis-Phase steht, könnte innerhalb eines Jahres oder zwei schon zur Custom-Built- oder sogar zur Produktphase wandern. Hier siehst du eine Beispielauswertung der Karte für den Onboarding-Prozess im Banken- und Finanzsektor. Der Ankerpunkt ist das blaue Feld mit dem Label „Kunde“. Dieser Kunde hat beim Onboarding zwei zentrale Ziele: 1. Eröffnung eines neuen Bankkontos 2. Vervollständigung des Aufnahmeprozesses (nachdem das Konto erstellt wurde) Da diese beiden Schritte eng miteinander verbunden sind, sind sie auf der Karte verknüpft. Die Eröffnung eines Bankkontos erfordert in der Regel eine KYC-Prüfung. Viele Banken haben maßgeschneiderte KYC-Verfahren, insbesondere wenn fortschrittliche Betrugsfrüherkennung ein wichtiges Alleinstellungsmerkmal ist. Eine risikobasierte Bewertung mit KI ist noch hypothetisch und wird als Genesis-Stufe betrachtet. Ein weiteres wichtiges Element ist die biometrische Identitätsprüfung. Während es fertige Lösungen wie ID Now gibt, haben wir uns für eine maßgeschneiderte Lösung entschieden, um den Onboarding-Prozess ohne Video-Call zu optimieren. Dieses System greift auch auf staatliche Identifikationsendpunkte zurück, die wir als Lizenzeinzelstücke erwerben. Wir müssen uns den regulären Rahmenbedingungen des Geschäftslandes unterordnen, was einem „Basisservice“ gleichzusetzen ist. Im technischen Hintergrund sorgt eine Prozess-Engine dafür, dass alles zusammenwirkt. Sie läuft im Cloud-Umfeld, das nicht nur fürs Onboarding sorgt, sondern auch machine-learning-basierte Analysen ermöglicht. Viele dieser Tätigkeiten werden ausgelagert und können als Basisservice/Nutzungsrechte betrachtet werden. Diese Elemente bilden die Grundlagen der Wertkette für unser KYC-Senezio. ### Kontoeinrichtung und Onboarding Der Kontoeinrichtung und dem Onboarding-Prozess liegt ein KI-Assistent zugrunde, der zwar in letzter Zeit an Bekanntheit gewonnen hat, für viele aber noch Neuland ist. Neben moderner Betrugserkennung spielt hier ein nahtloses Kundenerlebnis eine ebenso große Rolle, daher liegt der Fokus auch hier auf KI-gestützten Funktionen. Wie bei den KYC-Prüfungen bauen wir hier auf derselben Cloud-Recheninfrastruktur und den gleichen maschinellen Lernverfahren auf, die unserem ganzen Prozess eine solide Grundlage bieten. ### Vereinfachtes Beispiel, greifbare Einblicke Dies ist ein vereinfachtes Beispiel, das zeigt, wie sich jede Komponente des Prozesses einfügt, sei es KI-basierte Risikobewertung, biometrische Verifikation oder regulatorische Konformität innerhalb der gesamten Wertkette. Indem du solche Abhängigkeiten und Entwicklungsstufen einzeichnest, wirst du klarer erkennen können, wo deine strategischen Alleinstellungsmerkmale liegen und in welchen Bereichen Fertiglösungen dir möglicherweise weitaus sinnvoller und kosteneffizienter erscheinen. ## Zerlegen des Gegenwärtigen und Abbilden von Zukunftsszenarien Wir haben ja schon eine detailliertere Karte unseres Customer Onboarding-Prozesses. Es gibt da noch ganz viel zu entdecken! Wir analysieren unsere aktuelle Karte, indem wir Climatic Patterns und Doctrines einsetzen — das hilft uns dabei neue Chancen zu erkennen und zukünftige Szenarien abzustecken. Fangen wir an: Zuerst erkläre ich dir kurz, was Climatic Patterns und Doctrines bedeuten, bevor wir sie in unsere bisherige Karte einbauen. Ein **Climatic Pattern** umfasst die äußeren Kräfte, die unsere Landschaft beeinflussen — beispielsweise Komponenten selbst oder finanzielle Faktoren wie Geschwindigkeit, Wettbewerbsdruck, Trägheit (Widerstand gegen Veränderung) und Vorhersagekraft (Antizipation von Marktdurchbrüchen oder Technologiewellen). Du kannst zwar nicht direkt Einfluss auf diese Kräfte nehmen, aber du beobachtest sie und passt deine Strategien danach an. Die Trägheit hilft dir dabei einzuschätzen, wo Widerstände deinen BPM-Initiativen den Tritt ausweisen könnten — und so Ressourcen effizienter einsetzen sowie Zeitpläne realistischer planen. Wenn du solche Muster in deine Wardley-Karte einbindest, gewinnst du Einblicke über mögliche künftige Entwicklungen — und so bessere Voraussetzungen für proaktive Entscheidungen. Eine **Doctrine** hingegen bezeichnet ein Satz von universellen Best Practices und Leitprinzipien innerhalb der Wardley Mapping-Methode — Ideen wie Fokus auf Nutzerbedürfnisse, im Kleinen denken, Fluss optimieren sowie Wirkung stärker priorisieren als bloße Effizienz. Solche Grundsätze sorgen dafür, dass deine strategischen Schritte auch dann noch Sinn machen, wenn sich Die Landschaft um dich herum verändert sich. Wenn du also zukünftig deine Prozesse steuerst, kannst du dich auf solide Methoden verlassen — und so sicherer entscheiden wissen, dass dein Handeln stets im Einklang mit den relevantesten Werten steht. ### Hinzufügen von Doctrines und Climatic-Patterns Auf der Karte dominieren zwei Doctrines den Mittelpunkt. Erstens, im roten Kreis steht die Doctrine der reibungslosen Onboarding-Erlebnisse im Fokus — hier geht es darum, den Kundenservice beim Konto-Einrichten und der frühen Nutzung besonders zu begeistern. Zweitens, im blauen Bereich sorgt die Doctrine für außergewöhnliche Standards durch Fokus auf Top-Sicherheit, regulatorische Vorgaben einhalten und schnelle, schmerzfreie ID-Verifikationen. Diese beiden Doctrines sorgen für stabile Prozesse, die Betrug minimieren und dennoch ein nahtloses Nutzererlebnis liefern — so entsteht Vertrauen. Kunde glücklich, Prozess gesichert. Wenn wir uns die Klimatischen Muster ansehen, fällt uns Trägheit auf – also Widerstände gegen Veränderungen –, insbesondere bei Komponenten wie dem KI-Assistenten. Der interne KI-Assistent von heute könnte morgen schon ein Standardprodukt sein, was uns zwingt, zu überlegen: Soll er bleiben oder outsourcen wir ihn, um Ressourcen für Genesis-orientierte Innovationen freizusetzen? Solche Entscheidungen könnten uns Rückschläge bereiten – Widerstände sind hier nicht ungewöhnlich. Ähnlich könnte es bei Risk Scoring zugehen, das von einer „neuen, inhouse-entwickelten Fähigkeit“ zur Standard-Lösung mutieren könnte. Die orangen „Where to?“-Pfeile regen uns an, in die Zukunft zu blicken und abzuwägen: Soll man weiterhin in kundenspezifische Lösungen investieren oder lieber auf etablierte Anbieter warten, sobald die reifen genug sind, um zu überzeugen? ### Abbilden der Zukunft Sobald du die Doctrines und Klimatischen Muster auf deiner Wardley-Karte platziert hast, kannst du dir mögliche Zukunftsszenarien für deinen Customer Onboarding-Prozess anschauen. Stell dir vor: Dein KI-Assistent steht kurz davor, zur Standard-Lösung zu werden – da kannst du Ressourcen in ein neues Genesis-orientiertes Projekt steuern, etwa einen hyperpersonalisierten AI-Concierge, der Kunden in Echtzeit durch Tipps leitet, oder eine nächste-Generation-Biometrie-Authentifizierung, die sich nahtlos an neue Regeln anpasst und gleichzeitig Sicherheit aufs nächste Level hebt. Wenn du solche Innovationen auf deiner Karte einzeichnest, siehst du besser durch, wie diese über die Zeit vom Genesis-Geist zur Commodity wandern könnten. Ausrichtung deiner nächsten Züge an Doctrines wie „Exzellente Standards“ und Fokus auf Nutzerbedürfnisse — so stellst du sicher, dass deine Investitionen nicht nur Sicherheit und Compliance stärken, sondern auch ein unverwechselbares Nutzererlebnis schaffen. Und das, obwohl sich der Markt um dich herum weiterentwickelt. So bleibt dein Prozess spannend — und du denkst voraus. ## Fazit Wardley Mapping ist ein vielseitiges Instrument, das sich auf viele strategische Entscheidungsprozesse anwenden lässt — und da kenne ich’s aus eigener Erfahrung so: Es hat besonders in der Business Process Management-Landschaft seine Stärken. Es hilft dir dabei, Entscheidungen zwischen „selber machen“ oder „einkaufen“ klarer zu treffen und fokussiert auf die wirklich entscheidenden Themen. Gleichzeitig schafft es einen vorwärtsgerichteten Blick, der für Prozesse essenziell ist — schließlich entwickeln sich diese stetig weiter und müssen effizienter werden sowie Anpassung an veränderte Märkte oder Unternehmensstrategien schaffen. Du kannst Wardley Mapping auch mit anderen Methoden kombinieren — etwa Team Topologies. Inzwischen gibt’s da so einige spannende Vorträge und Diskussionen rund um solche Schnittstellen. Im nächsten Post werde ich da nochmal Schau dir diese Kombination genauer an, um geschmeidige Automatisierungsteams aufzubauen, die Prozesse wie Onboarding nachhaltig verändern. Du willst deine Prozesslandschaft strategisch weiterentwickeln? [So unterstützen wir dich](/leistungen/). Für mehr zum Thema Wardley Mapping im Kontext von BPM — [melde dich gerne!](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/) Dieser Post ersetzt nicht das [hervorragende Buch von Simon Wardley](https://learnwardleymapping.com/book/), das ich dir für ein umfassendes Verständnis wärmstens empfehle. Viel Spaß beim Mappen! Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwardley-mapping-prozesslandschaften%2F)[](mailto:?subject=Handlungsspielr%C3%A4ume%20in%20Prozesslandschaften%20mit%20Wardley-Mapping%20identifizieren&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwardley-mapping-prozesslandschaften%2F) ## Thomas Heinrichs Solution Architecture Lead bei Miragon [in Thomas kennenlernen](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/) [Mehr von Thomas](/blog/?author=thomas-heinrichs) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht](https://www.miragon.io/blog/warum-ich-npm-dependencies-pinne/) Softwareentwicklung Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead **27\. Apr. 2026**7 Min. Lesezeit Wenn du JavaScript oder TypeScript schreibst, hast du Dependency-Deklarationen wie `^1.7.2` schon unzählige Male gesehen. Wahrscheinlich sieht es in deiner eigenen `package.json` gerade genauso aus. Bei mir war das lange genauso. Es fühlt sich sicher an. Du gibst dir damit Spielraum: Minor-Versionen und Patches laufen automatisch mit, ohne dass du darüber nachdenken musst. Aber diese Art, Dependencies zu deklarieren, tut mehr, als du vielleicht annimmst. Sie macht aus deiner `package.json` unbemerkt einen _Pointer_ statt einer _Spezifikation_. Und ein Pointer zeigt nicht immer auf dasselbe Ziel — mit jeder neuen Version ändert sich, worauf er zeigt. Dieser Beitrag ist eine kurze Reflexion darüber, warum ich dazu übergegangen bin, jede npm-Dependency auf eine exakte Version zu pinnen: was das konkret bedeutet, wo die echten Tradeoffs liegen, und wie eine kleine Open-Source-GitHub-Action, die ich gebaut habe — [`pin-npm-dependencies`](https://github.com/Miragon/pin-npm-dependencies) — dabei hilft, diese Praxis in unseren Projekten durchzusetzen. ## 🔍 Was bedeutet “Pinning” eigentlich? So verstehe ich _gepinnt_: drei Dinge, die aufeinander aufbauen. 1. **Eine exakte Version in der `package.json`** — `"axios": "1.7.2"`, nicht `"^1.7.2"` oder `"~1.7.2"`. 2. **Ein committetes Lockfile** — `package-lock.json`, `yarn.lock` oder `pnpm-lock.yaml`, eingecheckt in Git. Das friert die aufgelöste Version jeder transitiven Dependency ein, dazu einen Content-Hash für jedes Tarball. 3. **Ein strikter Installer in CI und Docker** — `npm ci` installiert exakt das, was im Lockfile steht, und schlägt fehl, wenn das nicht geht (yarn und pnpm haben Äquivalente). Ein einfaches `npm install` ist da großzügiger: Fehlt das Lockfile oder passt es nicht zur `package.json`, löst es einfach neu auf und schreibt das Lockfile still um. Schritt 2 ist bei den meisten Teams bereits Standard. Schritt 1 erfüllen deutlich weniger — und Schritt 3 fällt häufiger unter den Tisch, als du denkst. Die Integritäts-Hashes im Lockfile schützen dich gegen _Manipulation_ an bereits gelockten Paketen. Aber sie können dich nicht schützen, wenn das Lockfile selbst neu generiert wird — jemand fügt eine Dependency hinzu, ein Renovate-PR wird gemerged, ein CI-Job führt `npm install` statt `npm ci` aus. In diesem Moment löst jede Range in der `package.json` frisch auf, eine neue Version kommt rein, und nichts schlägt Alarm. Genau hier setzt Schritt 1 an und schließt diese Lücke. ## ⚠️ Warum lockere Versionen ein Supply-Chain-Risiko sind Diese Unberechenbarkeit ist genau die Lücke, die ein Angreifer braucht. Jede Range in deiner `package.json` ist eine offene Einladung, beim nächsten `npm install` einfach das zu nehmen, was gerade aktuell in `1.x` verfügbar ist — ohne Prüfung, ohne dass es jemand bemerkt. Was durch diese Lücke kommt, folgt fast immer demselben ernüchternden Muster: Die npm-Credentials eines Maintainers werden gephisht, oder ein populäres Paket bekommt unauffällig einen neuen Maintainer. Manchmal wird auch ein aufgegebener Paketname einfach neu registriert. Dann erscheint eine bösartige Version. Oft mit einem `postinstall`\-Hook — einem Skript, das npm automatisch direkt nach dem Download ausführt, bevor irgendein Stück deines Codes das Paket je importiert. Ein eingechecktes Lockfile verschafft dir einen zeitlichen Puffer. Du ziehst die neue Version nicht bei jeder Installation rein. Aber das nächste Mal, wenn das Lockfile neu generiert wird — jemand fügt eine Dependency hinzu, ein Renovate-PR wird gemerged, ein CI-Job führt `npm install` statt `npm ci` aus — löst die Range frisch auf, und die neue Version fließt rein. Es gibt keinen PR, der diese Dependency betrifft, kein echtes Review eines 200-Zeilen-Lockfile-Diffs — niemand wirft noch einen zweiten Blick darauf. Das ist nicht theoretisch. Im März 2026 wurde `axios` — der meistinstallierte JavaScript-HTTP-Client der Welt — von einem staatsnahen Threat Actor kompromittiert. Die Angreifer haben den axios-Quellcode nicht einmal direkt verändert. Sie nutzten einen gekaperten Maintainer-Account, um zwei neue Versionen zu veröffentlichen, die im Verborgenen eine vorgelagerte bösartige Dependency hinzufügten, deren `postinstall`\-Hook einen plattformübergreifenden Remote-Access-Trojaner ablegte. Das [Post-Mortem der axios-Maintainer](https://github.com/axios/axios/issues/10636) und [Microsofts Threat-Intel-Analyse](https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/) gehen die ganze Kette durch. Die bösartigen Versionen waren nur wenige Stunden online — aber wer das Pech hatte, dass sein Lockfile genau in diesem Zeitfenster neu generiert wurde, hat sie automatisch mit installiert, vermutlich ohne überhaupt zu bemerken, dass sich die axios-Version geändert hatte. Und axios ist nur der jüngste Eintrag auf einer Liste, die immer länger wird — [`event-stream`](https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident) im Jahr 2018, [`ua-parser-js`](https://github.com/advisories/GHSA-pjwm-rvh2-c87w) 2021, und Dutzende mehr. Die Motive unterscheiden sich, die Angriffsfläche bleibt dieselbe. ## 🤖 Und dann ist da noch der AI-Aspekt In den letzten zwei Jahren — vielleicht sogar erst in den letzten Monaten — hat sich diese Diskussion spürbar verändert. AI-Coding-Agenten wie Copilot, Cursor und Claude Code schlagen nicht mehr nur gelegentlich ein Autocomplete vor. Bei vielen Teams schreiben sie inzwischen einen erheblichen Teil der Codebasis: ganze Features, Refactorings, Dependency-Entscheidungen, Install-Befehle, CI-Workflows. Wie groß ist dieser Anteil? Groß genug, dass [Spotify kürzlich öffentlich gemacht hat](https://techcrunch.com/2026/02/12/spotify-says-its-best-developers-havent-written-a-line-of-code-since-december-thanks-to-ai/), dass ihre stärksten Engineers seit Dezember keine Zeile Code mehr getippt haben. Sie shippen mit Agenten. Spotify ist damit sicher ein Extremfall. Aber die Richtung ist überall dieselbe. Daraus folgen zwei Dinge, die Pinning wichtiger machen — nicht weniger wichtig. **Erstens erben Agenten die Defaults des Ecosystems, auf dem sie trainiert wurden.** Das bedeutet: Sie schreiben ohne zu zögern `"react": "^18.3.0"` hin, solange dein Tooling nicht gegensteuert. Bei Hunderten kleinen Änderungen durch Agenten wächst der ungepinnte Anteil in deinem Repo schleichend. **Zweitens fällt in agentischen Flows der menschliche Review-Schritt oft weg.** Wenn ein Agent autonom Dependencies installiert und Tests ausführt, fehlt der Reflex, kurz innezuhalten und zu fragen: “Moment, warum fügen wir diese Dependency überhaupt hinzu?” — ein Reflex, den ein menschlicher Reviewer manchmal hat. Die Zahl der `package.json`\-Entscheidungen, die niemand bewusst getroffen hat, steigt weiter. Eine CI-Guardrail, die exakte Versionen erzwingt, ist einer der billigsten Wege, die Kontrolle zu behalten, während sich der Rest des Workflows beschleunigt. ## ⚖️ Der ehrliche Tradeoff: Pinning ist nicht gratis Pinning ist nicht umsonst. Wäre es das, hätte npm es längst zum Standard gemacht. Wenn du jede Dependency pinnst, tauschst du _impliziten Drift_ gegen _expliziten Aufwand_: - Jeder Patch-Release wird zu einem kleinen PR — Dependabot oder Renovate funktionieren weiter, sie produzieren nur mehr Rauschen. - Lockfile-Konflikte werden häufiger, wenn zwei Branches gleichzeitig Versionen bumpen. - Wenn dein Team diese PRs nicht wirklich anschaut, hängst du bei Security-Patches hinterher und stehst am Ende schlechter da als vorher. Pinning ist ein Constraint, den du dir bewusst auferlegst. Es zahlt sich nur aus, wenn du es mit echter Update-Disziplin paarst — automatisierten Upgrade-PRs, einem festen Zeitfenster, um sie zu reviewen, und `npm ci` überall, wo es zählt. Ohne das frierst du lediglich den aktuellen Stand der Sicherheitslücken in deinem Repo ein. Was du im Gegenzug bekommst, ist konkret: Jede Dependency-Änderung taucht als reviewbarer Diff auf. Ein Upgrade wird zu einer bewussten Entscheidung. Die Chance, etwas Seltsames zu erkennen, bevor es in Production landet, steigt von praktisch null auf spürbar mehr. ## 🛡️ Mach einen Check daraus, keine Konvention All das zu wissen und ein Team dazu zu bringen, sich daran zu halten, sind zwei verschiedene Probleme. Konventionen in einer README verblassen mit der Zeit; ein einziges `npm install ` ohne `--save-exact` schreibt wieder einen Caret hinein. Wenn dir Pinning wichtig ist, lohnt es sich, es so zu behandeln wie jede andere Invariante in deinem Code: als etwas, das die CI bei jedem PR prüft — nicht als etwas, das sich jeder Entwickler merken muss. Dieser Check lässt sich einfach umsetzen — den Build fehlschlagen lassen, sobald irgendeine `package.json` eine nicht-exakte Version enthält, mutable Git-Refs wie `#master` eingeschlossen. Du kannst dir das mit ein paar Zeilen Skript selbst bauen, oder die kleine Open-Source-GitHub-Action nehmen, die ich genau dafür gebaut habe: [`pin-npm-dependencies`](https://github.com/Miragon/pin-npm-dependencies). Sie funktioniert mit npm, yarn und pnpm. Kombiniere sie mit `save-exact=true` in deiner `.npmrc`, damit `npm install ` lokal exakte Versionen schreibt — dann hast du beide Seiten abgedeckt. Der Punkt ist nicht das spezifische Tool. Es ist, dass Pinning nur dann von Dauer ist, wenn etwas anderes als Disziplin es durchsetzt. ## 🤝 Wie siehst du das? Hat dir schon mal eine transitive Dependency ungefragt den Boden unter den Füßen weggezogen, oder hat dein Team Frieden mit Caret-Ranges geschlossen? Mich würde interessieren, wo für dich in deinem Kontext die Linie richtig sitzt. _This post was originally published in English on [Medium.com](https://medium.com/p/13bb22c78ae3)._ Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwarum-ich-npm-dependencies-pinne%2F)[](mailto:?subject=Warum%20ich%20jede%20npm-Dependency%20pinne%3A%20eine%20kleine%20Gewohnheit%2C%20die%20ein%20kompromittiertes%20Paket%20%C3%BCbersteht&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwarum-ich-npm-dependencies-pinne%2F) ## Marco Schäck Process Development Lead bei Miragon [in Marco kennenlernen](https://www.linkedin.com/in/schaeckm/) [Mehr von Marco](/blog/?author=marco-schäck) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/)[ Softwareentwicklung 01\. Dez. 2025 ### Leveling up! Wie du die Herausforderung verteilter Transaktionen in Zeebe lösen kannst Ein umfassender Guide zu verteilten Transaktionen in Zeebe: Von Phantom-Instanzen über das Outbox Pattern bis hin zu Idempotenz und SAGA. Marco Schäck Process Development Lead ](/blog/leveling-up-verteilte-transaktionen-zeebe/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Was ist ein Monorepo?](https://www.miragon.io/blog/was-ist-ein-monorepo/) Softwareentwicklung Ein Überblick über den Monorepo-Ansatz in der Softwareentwicklung - Anwendungsgebiete, Vor- und Nachteile sowie Erfahrungen aus der Praxis. Lukas Mösle Consultant **16\. Dez. 2022**6 Min. Lesezeit Bei der Frage _Sollen wir ein Monorepo für das neue (oder bestehende) Softwareentwicklungsprojekt erstellen_ spalten sich die Geister. Es gibt die 2 starken Lager, das eine, dass Monorepos liebt und das andere das sie verteufelt. Wie man sich schon beim Titel des Blogposts denken kann, gehöre ich zu der Fraktion der Entwickler, die gerne in einem Monorepo arbeiten und dementsprechend möchte ich gerne meine bisherigen Erfahrungen mit Monorepos in diesem Blogpost teilen. ## Was ist der Monorepo Ansatz Bei einem Monorepo wird der Quellcode einer oder mehrerer Anwendungen oder Bibliotheken in einem einzigen Git Repository entwickelt. Im Gegensatz dazu steht die sogenannte Poly- bzw. Multirepo Strategie, bei der für jede Anwendung oder Bibliothek ein eigenes Repository angelegt wird. Die konkrete Umsetzung des Monorepo Ansatzes ist jedem Entwicklungsteam selbst überlassen. Es kann die Anwendungen einfach nur in unterschiedlichen Ordner im selben Repository entwickeln, sich selbst ein eigenes Build System mit einem Maven Multi-Module Projekt konfigurieren oder auf ein spezielles Monorepo Tool wie z.B. Lerna oder NX zurückgreifen. ## Anwendungsgebiete Je nach Anwendungsgebiet kann ein Monorepo mehr oder auch weniger Sinn machen. Einige Anwendungsgebiete, für die ich gerne auf den Monorepo Ansatz zurückgreife sind folgende: - **Anwendungen bestehend aus einem SPA Frontend und einem Backend** Wenn ich beispielsweise eine React App mit einem Spring Boot Backend entwickle, dann erstelle ich gerne eine Monorepo, um pro Feature nur einen Pull Request erstellen zu müssen, der sowohl Front- als auch Backend Änderungen beinhalten kann. Durch die Verbindung des Frontend und Backend Codes fällt es mir leicht die beiden Komponenten gemeinsam zu bauen und zu veröffentlichen. - **Microservice Applications** Aufbauend auf dem vorangegangenen Punkt eignet sich ein Monorepo selbstverständlich auch für eine Anwendung, die aus mehreren (Micro-) Services besteht. Hierbei fällt es leichter zu verstehen, welche Services zusammen gehören und es können sich überschneidende Logiken in eigene Bibliotheken ausgelagert und in mehreren Services eingebunden werden. - **OpenSource Projekten mit mehreren Komponenten** Für OpenSource Projekte kann eine Monorepo Ansatz ebenfalls von Vorteil sein, um alle zum Projekt dazugehörigen Ressourcen in einem Repository zu vereinen. Dadurch fällt es neuen Entwicklern leichter zu verstehen, wie die Anwendung aufgebaut bzw. die unterschiedlichen Komponenten zusammenhängen. Neben den zuvor genannten Anwendungsgebieten gibt es selbstverständlich viele weitere Anwendungsgebiete, in denen ein Monorepo eingesetzt werden kann. ## Vor- und Nachteile Bei den Anwendungsgebieten bin ich bereits kurz auf einige Vorteile von Monorepos eingegangen. Diese möchte ich hier gerne nochmals zusammenfassen und ergänzen, sowie auch auf die Nachteile von Monorepos eingehen. ### Vorteile - **Transparenz**: Jeder Entwickler hat Zugriff auf den Gesamtenquellcode und alle zum Projekt dazugehörigen Anwendungen. Dadurch fällt es leichter sich als Entwickler einen Überblick über alle Projektressourcen zu verschaffen. - **Einfachere Zusammenarbeit**: Dadurch, dass mehrere Anwendung im selben Repository entwickelt werden, muss bei der Umsetzung eines neuen Features nur ein Pull Request gestellt und gemerged werden. So lässt sich das Mergen über die verschiedenen Teilprojekte hinweg vereinfachen und die Zusammenarbeit verbessern. - **Auslagern von Komponenten und Logik in eigene Bibliotheken**: Bei einem Monorepo können einzelne Komponenten und Funktionen relativ schnell in eine eigene Bibliothek ausgelagert und wiederum von der Anwendung verwendet werden. Der große Vorteil eines Monorepos ist hierbei, dass die Bibliothek nicht in einem externen Paketmanager veröffentlicht werden muss, sondern direkt in den Build Prozess integriert werden kann. - **Geteilte Ressourcen**: In einem Monorepo gibt es häufig eine zentrale Dokumentation und einen zentralen Changelog, der gepflegt wird. So können sich neue Entwickler schnell einen Überblick verschaffen, da die Dokumentation des Gesamtprojekts nicht auf mehrere Repositories verteilt ist. - **Weniger Repositories**: Häufig platzen Projekte aus allen Nähten und es gibt eine Vielzahl von Repositories, die lokal ausgecheckt und aktuell gehalten werden müssen. Bei einem Monorepo wird die Anzahl der Repositories auf ein Minimum reduziert. ### Nachteile - **Höhere Komplexität**: Einer der größten Nachteile eines Monorepos ist die Komplexität, die bei diesem Ansatz steigt. Als Entwickler reicht es in einem Monorepo oftmals nicht aus sich nur den Quellcode auszuchecken, sondern man muss sich auch mit der Struktur des Monorepos und der Vielzahl an Anwendungen und Bibliotheken auseinander setzen. Zudem werden Build sowie CI/CD Konfigurationen komplexer und anspruchsvoller. Auch die Versionierung der Anwendung wird deutlich anspruchsvoller und muss gut durchdacht werden. - **Einschränkungen bei OpenSource Projekten**: Monorepos sind für OpenSource Projekte gut geeignet. Mit Verhältnis wenig Aufwand können einzelne Teile einer Anwendung in eine Bibliothek ausgelagert und direkt wieder verwendet werden. Auch die Bibliothek in einer öffentlichen Registry zu veröffentlichen stellt kein großes Problem dar. Aber sobald man proprietären Code mit Bibliotheken, die OpenSource veröffentlicht werden sollen in einem Repository vermischt, wird es kompliziert. Bei OpenSource Software muss auch der Quellcode veröffentlicht werden, der zusammen mit proprietärem Code im selben Repository gepflegt wird. Ganz nach dem Motto _ganz oder gar nicht_ kann der Quellcode in einem Monorepo veröffentlicht werden. - **Struktur und Dokumentation**: Eine gut durchdachte Repository Struktur und eine gut gepflegte Dokumentation sind für die Entwicklung in einem Monorepo sehr wichtig, um unkontrolliertem Wildwuchs vorzubeugen. Insbesondere die Dokumentation der Monorepo Struktur ist von zentraler Bedeutung für Entwickler, die neu zum Projekt dazustoßen. Damit diese sich schnell einfinden können, sollte die Struktur des Repositories sowie die Entwicklung der einzelnen Module dokumentiert sein. Bei der (Entwickler-) Dokumentation hapert es leider sehr häufig in Softwareprojekte und diese (falls vorhanden) ist oftmals veraltet. ## Wo setzen wir Monorepos ein > Bei Miragon entscheidet jedes Projekt-Team selbst, wie es sich organisiert und welche Technologie es gerne einsetzen möchte. Auf dem Kundenprojekt bei der Landeshauptstadt München haben wir erstmals ein Monorepo für die Entwicklung der OpenSource [Prozessautomatisierungsplattform DigiWF](https://github.com/it-at-m/digiwf-core) angelegt. Das Monorepo bei der Landeshauptstadt München beschreibe ich in einem noch folgenden Blogpost näher. Nachdem wir erste erfolgreiche Versuche mit einem Monorepo bei der Landeshauptstadt München machen konnten, haben wir uns beim Projekt [Miranum-IDE](https://github.com/Miragon/miranum-ide) ebenfalls dazu entschieden ein Monorepo anzulegen und dort die VS-Code Extensions sowie eine CLI App für die Prozessentwicklung zu entwickeln. Über dieses Projekt werde ich ebenfalls zeitnah einen Blogpost veröffentlichen. ## Unsere bisherigen Learnings bei der Entwicklung von Monorepos Bei der Umsetzung eines Monorepos gibt es einige Punkte, die man beachten sollte, um das Team mitzunehmen und eine gute Softwareentwicklungsexperience zu schaffen. In einem Monorepo sollten die Befehle für Builds, das Ausführen von Tests, etc. einheitlich und für die gesamte Codebasis ausführbar sein. Insbesondere wenn unterschiedliche Technologien (z.B. Java und TypeScript) in einem Projekt eingesetzt werden, sollte man sich intensiv Gedanken darüber machen welche Build Tools für die beiden Sprachen verwendet werden sollen und ob bzw. wie man diese am besten miteinander integrieren kann. Beispielsweise könnte man den TypeScript-Build mit in den Maven Build Cycle integrieren. Dadurch können auch Entwickler, die nur an einem bestimmten Teil des Monorepos arbeiten die Tests oder den Build für alle Anwendungen ausführen. Zusätzlich können diese einheitlichen Befehle wiederum in den CI/CD Pipelines wiederverwendet werden, wodurch sich die Konfiguration dieser etwas einfacher gestaltet. Die Dokumentation der Module und Anwendungen, die im Monorepo entwickelt werden sollte möglichst früh begonnen werden, damit jeder (neue) Entwickler nachlesen kann wie die einzelnen Komponenten zusammenhängen. Die Umsetzung des Monorepos sollte das Team gemeinsam machen und Entscheidungen zu Tools, der Struktur, etc. gemeinsam getroffen werden. Bei uns hat sich hierbei der Ansatz etabliert, dass einzelne Personen einen Vorschlag ausarbeiten und diesen dann vorstellen und das Team nach dem Ansatz der integrativen Entscheidungsfindung über den Vorschlag abstimmt. ## Fazit und Ausblick Es gibt viele gute Gründe, die für Monorepos sprechen. Ebenso gibt es viele Gründe, die dagegen sprechen. Am Ende ist es eine Glaubensfrage, die jedes Team für sich selbst entscheiden sollte. Ich persönlich arbeite gerne in Monorepos, da mich der Dschungel an Repositories stört, der häufig entsteht, wenn ein Projekt wächst und immer neue Services dazukommen. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwas-ist-ein-monorepo%2F)[](mailto:?subject=Was%20ist%20ein%20Monorepo%3F&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwas-ist-ein-monorepo%2F) ## Lukas Mösle Consultant bei Miragon [in Lukas kennenlernen](https://www.linkedin.com/in/lukas-moesle) [Mehr von Lukas](/blog/?author=lukas-mösle) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Marco Schäck Process Development Lead ](/blog/agent-skills-ai-nischen-domaenen-bpmn/)[ Softwareentwicklung 27\. Apr. 2026 ### Warum ich jede npm-Dependency pinne: eine kleine Gewohnheit, die ein kompromittiertes Paket übersteht Eine kurze Reflexion darüber, warum sich der Mehraufwand beim Upgrade lohnt, wenn du npm-Dependencies pinnst – und wie eine kleine CI-Guardrail dafür sorgt, dass die Praxis im Team auch Bestand hat. Marco Schäck Process Development Lead ](/blog/warum-ich-npm-dependencies-pinne/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Was ist eine Prozessapplikation?](https://www.miragon.io/blog/was-ist-eine-prozessapplikation/) BPM Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead **17\. Aug. 2026**6 Min. Lesezeit “Prozessapplikation” klingt nach einem weiteren Buzzword, und je nachdem, wen du fragst, bekommst du eine andere Antwort. Für die einen ist es ein Workflow-Tool, für die anderen eine zentrale Taskliste oder eine Integrationsplattform. Der Grund: Es gibt sehr unterschiedliche Vorstellungen davon, wie man Prozesse automatisiert. Hersteller, Berater und Fachbereiche meinen oft etwas anderes, wenn sie dasselbe Wort benutzen. Genau deshalb lohnt sich eine saubere Abgrenzung. Wer den Begriff klar fasst, trifft bessere Entscheidungen: Was gehört in welche Schicht, wo lebt die Fachlichkeit, und wann brauchst du überhaupt eine Prozessapplikation. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von verwandten Konzepten ab. ## Integrativer Prozess vs. Fachprozess Bevor wir die Prozessapplikation definieren, braucht es eine Unterscheidung zwischen einem integrativen und einem fachlichen Prozess. Ein integrativer oder orchestrierender Prozess verbindet vor allem Systeme oder Domänen. Er sorgt dafür, dass ein Aufruf von A nach B geht, dass Reihenfolgen eingehalten werden und dass am Ende alle beteiligten Systeme ihren Teil getan haben. Eigene Fachlichkeit bringt er kaum mit. Die Logik lebt in den Systemen, die er koordiniert. Ein Fachprozess dagegen enthält konkrete Domänenlogik. Er bildet einen fachlichen Ablauf ab, trifft fachliche Entscheidungen und arbeitet mit den Regeln und Begriffen einer bestimmten Domäne. Er ist nicht nur Koordinator, er ist der eigentliche “Inhalt”. Dieser Unterschied ist der Kern: Eine Prozessapplikation dreht sich um einen Fachprozess, nicht um reine Integration. _Oben ein integrativer Prozess, der nur Systeme verbindet. Unten ein Fachprozess mit eigener Domänenlogik. Integration koordiniert, der Fachprozess trägt den Inhalt._ ## Was ist eine Prozessapplikation? Damit lässt sich der Begriff klar fassen: Thomas HeinrichsSolution Architecture Lead bei Miragon Definition Eine Prozessapplikation ist ein eigenständig versioniertes und deploybares Software-Bundle, das einen oder mehrere konkrete Fachprozesse innerhalb einer Domäne ausführt. Zwei Dinge stecken darin: - Sie enthält Fachlichkeit und bildet genau eine konkrete Domäne ab, statt über mehrere Domänen hinweg zu wachsen. Sie bleibt fokussiert. - Prozess, Formulare, Entscheidungslogik und weitere fachliche Logik werden als Einheit gebündelt und gemeinsam ausgeliefert. Eine Prozessapplikation ist also nichts Loses. Sie ist ein Software-Bundle, das man als Ganzes versioniert und deployt. Und sie führt echte Fachprozesse aus, nicht nur einen Ablaufplan. Der Begriff hat eine Geschichte. Bei Technologien wie Camunda 7, [CIB seven](https://cibseven.org/) oder [Operaton](https://operaton.org/) sind häufig sogenannte Application-Programming-Use-Cases entstanden: Die Engine war in eine Anwendung eingebettet, und diese Anwendung enthielt viel Fachlichkeit. Genau solche Anwendungen sind Prozessapplikationen. Der Name macht nur explizit, was da ohnehin gebaut wurde. ## Bestandteile einer Prozessapplikation Eine Prozessapplikation bündelt typischerweise mehrere Bestandteile. Nicht jeder ist immer nötig, aber sie gehören zusammen und werden gemeinsam ausgeliefert: - **BPMN-Prozesse**, sofern sinnvoll. BPMN muss nicht zwingend verwendet werden, kann aber ein zentraler Bestandteil sein. - **Entscheidungslogik**, optional, zum Beispiel als DMN, für fachliche Regeln. - **Formulare** für die Schritte, die ein Mensch bearbeitet. - **Fachliche Validierungen**, die prüfen, ob eine Eingabe für die Domäne gültig ist. - **Domänenlogik**, der eigentliche fachliche Kern. - **UI- bzw. Frontend-Anteile**, mit denen konkrete Anliegen bearbeitet werden. Die Aufzählung ist nicht abschließend. Genauso gehören zum Beispiel PDF-Templates und Vorlagen dazu, die im Prozess erzeugt oder genutzt werden. Entscheidend ist, dass diese Teile eine Einheit bilden. Sie werden zusammen versioniert und zusammen deployt. Die Prozessapplikation läuft auf einer Prozess-Engine, aber die Engine ist keiner dieser Bestandteile. Sie ist Infrastruktur. _Die Bestandteile bilden ein Deployment-Bundle. Die Prozess-Engine trägt das Bundle als Infrastruktur, sie ist selbst kein Bestandteil._ ## Die Prozess-Engine ist Infrastruktur Die Prozess-Engine führt die Prozesse aus, hält ihren Zustand und kümmert sich um Timer, Wiederholungen und Historie. Das ist wichtig für den Betrieb, aber es ist nicht die Fachlichkeit. Der beste Vergleich ist eine Datenbank. Kaum jemand würde sagen, die Datenbank sei seine Anwendung. Sie ist notwendig, damit die Anwendung läuft, aber der fachliche Wert steckt in der Anwendung darüber. Genauso ist es mit der Prozess-Engine: Sie ist notwendige Infrastruktur, nicht der Kern. Und weil sie nur Infrastruktur ist, sollte sie austauschbar bleiben. Auch eine Datenbank bindet man selten direkt in die Fachlogik ein, sondern greift über eine Abstraktion wie JPA darauf zu. Für die Prozess-Engine gilt dasselbe: Ob darunter [Temporal](https://temporal.io/), [Camunda](https://camunda.com/), CIB seven, Operaton oder etwas ganz anderes läuft, sollte die Prozessapplikation nicht interessieren müssen. So entsteht keine Bindung an einen einzelnen Hersteller. Für genau diese Abstraktion gibt es die [process-engine-api der BPM-Crafters-Community](https://github.com/bpm-crafters/process-engine-api), an der wir selbst mitarbeiten. Sie entkoppelt die Fachlichkeit von der konkreten Engine, so wie JPA die Anwendung von der konkreten Datenbank entkoppelt. Dieselbe Haltung, offene Standards und Herstellerunabhängigkeit mit der Fachlichkeit im Zentrum, vertritt auch das [BPM Manifesto](https://bpm-crafters.dev/). Die Fachlichkeit liegt in der Prozessapplikation selbst. Die Engine lässt sich einkaufen, bereitstellen oder austauschen, den Fachprozess und seine Domäne muss man selbst besitzen. ## Prozessapplikation im End-to-End-Prozess Eine Prozessapplikation steht selten allein. Sie ist oft Teil eines größeren End-to-End-Prozesses, der sich über mehrere Fachbereiche zieht. Dieser übergreifende Prozess ist selbst eher integrativ. Er orchestriert mehrere Domänen und ruft mehrere Prozessapplikationen auf, jede für ihren fachlichen Teil. Die einzelne Prozessapplikation bleibt dabei auf ihre Domäne fokussiert. Sie wächst nicht in fremde Domänen hinein, nur weil sie in einem größeren Ablauf mitspielt. Warum das wichtig ist, haben wir in unserem Post zu [übergreifenden BPMN-Prozessen](/blog/uebergreifende-bpmn-prozesse-gefaehrlich/) beschrieben. So bleibt jede Prozessapplikation überschaubar und klar einem Team zugeordnet, während der End-to-End-Prozess das Zusammenspiel koordiniert. _Ein übergreifender End-to-End-Prozess orchestriert mehrere domänenfokussierte Prozessapplikationen. Jede bleibt auf ihre Domäne fokussiert._ ## Zentrale Taskliste vs. Prozessapplikation Eine häufige Verwechslung ist die mit einer zentralen Taskliste. Eine solche Liste, manchmal auch Portal oder Aufgabenliste genannt, kann unternehmensweit anzeigen, welche Aufgaben anstehen und wer sie erledigen soll. Häufig wird sie sogar für Workforce-Steering genutzt und in diese Richtung ausgebaut, also um Arbeit über Teams hinweg zu verteilen und zu steuern. Aber die eigentliche Bearbeitung gehört woanders hin. Die domänenspezifischen Formulare, die fachlichen Validierungen und die Fachlogik liegen in der Prozessapplikation. Die zentrale Taskliste zeigt die Aufgabe an, die Prozessapplikation liefert den fachlichen Inhalt dazu, oft als eingebettete Web Components. Ein modulares Formular-Framework dieser Art haben wir zum Beispiel bei [DigiWF für die Landeshauptstadt München](/blog/digiwf-landeshauptstadt-muenchen/) gebaut. Es wäre ein Fehler, domänenspezifische Validierungen in die zentrale Taskliste zu verlagern. Sie würde damit Fachlichkeit übernehmen, die nicht ihre ist, und müsste über kurz oder lang alle Domänen kennen. Die Taskliste macht Arbeit sichtbar. Die Fachlichkeit bleibt in der Prozessapplikation. _Die zentrale Taskliste zeigt Aufgaben an. Die Prozessapplikation liefert Aufgabe und Formular samt Validierung und Fachlogik._ ## Gegenüberstellung: Orchestrierung, Integration, Prozessapplikation Zum Abschluss die drei Begriffe klar nebeneinander, damit du sie im Gespräch sicher auseinanderhältst: Orchestrierungsprozess Integrationsprozess Prozessapplikation Zweck Koordiniert Schritte und Systeme über einen Ablauf Verbindet Systeme und Domänen, reicht Daten weiter Führt konkrete Fachprozesse einer Domäne aus Eigene Fachlichkeit Wenig: die Logik liegt in den koordinierten Systemen Kaum: verbindet, entscheidet aber nicht fachlich Ja: Domänenlogik, Regeln, Validierungen, Formulare Domänenbezug Übergreifend, oft mehrere Domänen Übergreifend Genau eine Domäne, fokussiert Typische Rolle Klammer um einen End-to-End-Ablauf Brücke zwischen Systemen Fachlicher Baustein, der echte Arbeit erledigt ## Fazit Eine Prozessapplikation hält die Fachlichkeit: sie ist ein eigenständig deploybares Bundle, das die Fachprozesse einer Domäne ausführt. Die Engine darunter ist austauschbare Infrastruktur, nicht der Kern. Orchestrierung koordiniert, Integration verbindet, die Taskliste zeigt an, aber die Fachlichkeit gehört in die Prozessapplikation. Wer das sauber trennt, baut Systeme, die man versteht, besitzt und weiterentwickeln kann. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwas-ist-eine-prozessapplikation%2F)[](mailto:?subject=Was%20ist%20eine%20Prozessapplikation%3F&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwas-ist-eine-prozessapplikation%2F) ## Thomas Heinrichs Solution Architecture Lead bei Miragon [in Thomas kennenlernen](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/) [Mehr von Thomas](/blog/?author=thomas-heinrichs) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/)[ Softwareentwicklung 31\. März 2026 ### Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben Warum ein modularer Monolith mit Camunda 7 für ein kleines Projektteam die bessere Wahl war und welche Trade-offs diese Architektur mit sich bringt. Lukas Mösle Consultant ](/blog/modularer-monolith-camunda-7-statt-microservices/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Wie Wardley Mapping das Not-Invented-Here Syndrom vermeiden kann](https://www.miragon.io/blog/wie-wardley-mapping-not-invented-here/) Transformation Wie Wardley Mapping Teams hilft, strategische Entscheidungen über Eigenentwicklung vs. Zukauf zu treffen und das NIH-Syndrom zu überwinden. Dominik Horn Co-Founder & Geschäftsführer **17\. März 2025**7 Min. Lesezeit In den letzten Jahren ist mir in der Welt der Softwareentwicklung immer wieder ein Phänomen über den Weg gelaufen, das mit dem Schlagwort **Not Invented Here (NIH)** beschrieben wird. Es bezeichnet die Tendenz, lieber eigene Lösungen zu entwickeln, statt auf bereits vorhandene, erprobte Alternativen zurückzugreifen. Dieses Verhalten kann hohe Kosten verursachen, die Innovationsgeschwindigkeit bremsen und dafür sorgen, dass wichtige Chancen am Markt verpasst werden. Leider wird es immer komplexer, die richtigen Entscheidungen zu treffen: neue Technologien, wachsende Konkurrenz, rasche Veränderung und Vernetzung – all das zwingt uns, ständig den Überblick zu bewahren. Welche Dinge sollten wir selbst entwickeln - und was nicht? Hier kann **Wardley Mapping** unterstützen. Es handelt sich um eine strategische Technik, die uns dabei hilft, unsere Wertschöpfungsketten, Abhängigkeiten und strategische Zielsetzungen zu visualisieren und zu verstehen. In diesem Artikel schauen wir uns an, wie Wardley Mapping einen klaren Blick auf unsere technischen und organisatorischen Entwicklungsmöglichkeiten gibt – und uns so helfen kann, das Not Invented Here-Syndrom zu vermeiden. ## Was ist das Not Invented Here-Syndrom? Das **Not Invented Here-Syndrom** beschreibt die Haltung oder Kultur innerhalb eines Teams oder einer Organisation, in der man lieber eigene Lösungen entwirft, als bereits existierende Produkte, Bibliotheken oder Services zu nutzen. Gründe dafür sind häufig: - **Kontrollbedürfnis:** Die Sorge, Abhängigkeiten von externen Anbietern zu haben. - **Misstrauen:** „Wer weiß, ob dieser Drittanbieter in ein paar Jahren noch existiert?“ - **Unkenntnis:** Keine Marktübersicht, was es schon gibt und wie stabil diese Lösungen sind. - **Teamkultur:** Ein gewisser Stolz auf „unser eigenes System“ oder „so haben wir es schon immer gemacht“. - **Qualitätsanspruch:** „Wenn wir es selbst bauen, können wir jeden Schritt optimieren.“ Diese Einstellung kann jedoch sehr teuer sein. Ein klassisches Beispiel: Ein Team entwickelt eine eigene Datenbanktechnologie oder ein eigenes Framework von Grund auf neu, obwohl es bereits umfangreich getestete Alternativen gibt. Das kostet nicht nur Zeit, sondern auch Geld, senkt die Produktivität und erhöht das Risiko, in eine Sackgasse zu geraten, wenn Know-how verloren geht oder technische Schulden entstehen. Wardley Mapping kann uns genau dabei helfen: Die richtigen Prioritäten bei der Produktentwicklung zu setzen. ## Was ist Wardley Mapping? **Wardley Mapping** wurden von Simon Wardley entwickelt und ist eine Methode, den strategischen Kontext einer Organisation oder eines Geschäftsmodells systematisch zu betrachten. _Bei der Grafik handelt es sich um das Beispiel von Simon Wardley aus dem Buch “Wardley Maps”_ Eine Wardley Map besteht aus mehreren Elementen: 1. **Anwender und Wertversprechen**: Am oberen Rand findet man den Endnutzer und das, was dieser konkret benötigt. 2. **Wertschöpfungskette**: Darunter werden alle Komponenten (Software, Infrastruktur, Prozesse, Partner, Rohstoffe usw.) angezeigt, die notwendig sind, um dieses Wertversprechen zu erfüllen, sowie deren Abhängigkeiten untereinander. 3. **Evolutionsstufen**: Jede Komponente wird von Genesis (Neuheiten in der Entstehung, sehr innovativ) über Custom Built (Individuelle Anforderungen und daher selbst entwickelt) bis hin zu Product (einige Optionen am Markt verfügbar) und Commodity (Massenprodukt mit zahlreichen verschiedenen Anbietern) positioniert. Ziel ist es, einen Überblick über den Status und die Wichtigkeit jedes Elements in der Wertschöpfungskette zu erhalten. Die zentrale Frage dabei: **Wo stehen wir gerade mit unseren Technologien, Prozessen und Fähigkeiten?** Dadurch wird sichtbar, welche Elemente **sich noch in der frühen Entwicklungsphase befinden** (also lieber selbst entwickelt werden sollten) und welche **bereits einen Standard erreicht** haben und folglich nicht mehr eigenentwickelt werden müssen, weil externe Lösungen günstig, zuverlässig und praktisch „austauschbar“ sind. ## Wie hilft Wardley Mapping, das NIH-Syndrom zu vermeiden? ### 1\. Klarheit über Evolutionsstufen Wardley Maps zwingen uns, jede Komponente einzeln zu betrachten und zu bewerten. Befindet sich eine Komponente eher in der „Genesis“- oder „Produkt“-Phase? Ist sie schon zu einer „Commodity“ geworden? Diese Einordnung regt die Diskussion an, ob man wirklich **einen eigenen Service** bauen sollte, wenn es beispielsweise schon unzählige gute Anbieter gibt oder besser eine **Commodity-Lösung** einkauft bzw. in der Cloud mietet. Indem wir die Position einer Komponente in der Map klar sehen, fällt es leichter, das Team davon zu überzeugen, dass eine interne Entwicklung **keinen Wettbewerbsvorteil** bietet, wenn dieselbe Technologie eigentlich längst **Standard** ist. ### 2\. Strategisches Bewusstsein Wardley Maps machen **Handlungsoptionen** transparent. Statt rein intuitiv zu entscheiden: „Ich habe gehört, dass Microservices gerade in sind, lass uns alles in Microservices aufteilen!“, zeigt die Map, welche Teile des Systems tatsächlich differenzierend sind und welche nicht. So lassen sich Ressourcen gezielt auf den strategischen Kern konzentrieren, während Standard-Komponenten von außen bezogen werden können. Das vermeidet, dass man Zeit und Energie in Technologien steckt, die bereits ausgereift am Markt verfügbar sind. ### 3\. Kultureller Wandel Wardley Mapping ist nicht nur eine technische Übung, sondern kann auch einen **Kulturwandel** anstoßen. Durch das offene Diskutieren von Komponenten und deren Reifegrad wird transparent, wo genau ein **Wettbewerbsvorteil** entsteht und **wo** es sinnvoller wäre, auf **bestehende Lösungen** zu setzen. Durch das gemeinsame Diskutieren der Prioritäten führt Wardley Mapping so zu einer Demokratisierung der Unternehmens- und Produktstrategie. Diese gesteigerte Transparenz konfrontiert das NIH-Syndrom direkt: Ein Team erkennt klar, dass es mehr Nutzen bringt, die Energie auf wirklich differenzierende Themen zu legen, anstatt das Rad ständig neu zu erfinden. ### 4\. Gemeinsame Sprache Wardley Mapis bieten eine **visuelle, einfache Sprache**, mit der unterschiedliche Stakeholder (Management, Entwickler, Produktmanager) gemeinsam über strategische Entscheidungen diskutieren können. Indem alle auf die gleiche Karte schauen und die gleichen Begrifflichkeiten nutzen, verschwindet das typische Silo-Denken schneller – ein wichtiger Schritt, um eine realistische Einschätzung von Eigenentwicklungen versus Fremdlösungen zu erreichen. * * * ## Konkretes Beispiel > Es handelt sich dabei um ein vereinfachtes Beispiel, das Konzepte wie Domain Driven Design und Team Topologies außen vor lässt. Wer mehr über das Zusammenspiel mit Wardley Mapping erfahren möchte, dem empfehle ich diesen Vortrag von Susanne Kaiser: [https://www.youtube.com/watch?v=lpNzR0fvxDw](https://www.youtube.com/watch?v=lpNzR0fvxDw) Stellen wir uns ein Software-Unternehmen vor, das eine neue SaaS-Lösung für Terminbuchungen entwickelt. 1. **Identifizierung der Komponenten**: Ganz oben steht der Kunde, der einen einfachen Buchungsvorgang möchte. Darunter befinden sich Komponenten wie **Benutzeroberfläche**, **Buchungslogik**, **Benachrichtigungssystem**, **Bezahlung** und **Datenbank**. 2. **Positionierung auf der Evolutionsachse**: - Die **Benutzeroberfläche** befindet sich am linken Rand, weil sie sehr speziell ist und dem Produkt ein Alleinstellungsmerkmal verschafft. - Die **Datenbank** liegt rechts, denn relationale oder NoSQL-Datenbanken sind mittlerweile Commodity. - Das **Benachrichtigungssystem** und das **Bezahlsystem** werden ebenfalls hinzugekauft, da es bereits viele externe Lösungen gibt. - Eine **Live API** für zuverlässige Updates der Benutzeroberfläche wird bisher selbst entwickelt 3. **Entscheidungen treffen**: Statt selbst ein komplexes Live API System zu bauen, greift man auf einen bewährten Anbieter wie [pusher.com](http://pusher.com) oder [synadia.com](https://www.synadia.com/) zurück. Die Entwicklungskapazitäten werden lieber in das **User Interface** und die **Buchungslogik** investiert, um sie an spezifische Kundenbedürfnisse anzupassen. Auf diese Weise wird das Unternehmen nicht nur schneller am Markt sein, sondern auch das Risiko reduzieren, sich in einer aufwändigen Eigenentwicklung zu verstricken, die wenig Mehrwert bringt. * * * ## Tipps für den erfolgreichen Einstieg in Wardley Maps 1. **Fange klein an**: Versuche nicht, sofort das gesamte Unternehmen zu mappen. Wähle ein Teilprojekt oder eine spezifische Produktkomponente, um erste Erfahrungen zu sammeln. - Einen sehr guten Einstieg in das Thema bietet der Onlinekurs auf [https://learnwardleymapping.com/](https://learnwardleymapping.com/). - Falls du Miro im Unternehmen nutzt, kann ich dir dieses Template empfehlen → [https://miro.com/de/templates/wardley-map/](https://miro.com/de/templates/wardley-map/) 2. **Hol die richtigen Leute ins Boot**: Eine Wardley Map kann nur so gut sein wie das Wissen derer, die sie erstellen. Lade also sowohl technische Expert:innen als auch Entscheidungsträger:innen ein. 3. **Sei bereit zu diskutieren**: Die Map dient als Diskussionsbasis. Lass Raum für unterschiedliche Perspektiven und Meinungen. 4. **Aktualisiere die Map regelmäßig**: Die Welt und das Produkt verändern sich – entsprechend sollte man Wardley Maps immer wieder an neue Erkenntnisse anpassen. 5. **Nutze die Ergebnisse**: Eine Map allein ist kein Selbstzweck. Leite konkrete Actions ab (z. B. „Wir entscheiden uns für eine externe Lösung für Feature X“ oder „Wir bauen Feature Y selbst, weil es strategisch essenziell ist“). * * * ## Fazit Das **Not Invented Here-Syndrom** kann für Unternehmen teuer werden und die Wettbewerbsfähigkeit gefährden. Durch **Wardley Mapping** erhalten Teams und Entscheider:innen eine klare, visuelle Darstellung ihrer Wertschöpfungsketten und verstehen besser, wo sie **Ressourcen konzentrieren** sollten und wo es sinnvoller ist, bereits **etablierte Lösungen** zu nutzen. Wardley Mapping fördert einen **kulturellen Wandel** hin zu mehr Offenheit und Kooperation und liefert zugleich die strategischen Erkenntnisse, die notwendig sind, um Innovationsprojekte erfolgreich zu priorisieren. So wird deutlich, dass es oft effizienter ist, Standard-Komponenten einzukaufen und die Energie auf den **einzigartigen Wert** für den Kunden zu richten. Auf diese Weise kann Wardley Mapping maßgeblich dabei helfen, das NIH-Syndrom zu überwinden und nachhaltige Wettbewerbsvorteile zu erzielen. **Kurz gesagt:** Wer Wardley Maps klug einsetzt, lernt, die richtigen Dinge selbst zu entwickeln – und andere Dinge guten Gewissens wegzulassen oder zuzukaufen. Du willst diese strategische Klarheit in deiner Organisation verankern? [So unterstützen wir dich](/leistungen/). Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwie-wardley-mapping-not-invented-here%2F)[](mailto:?subject=Wie%20Wardley%20Mapping%20das%20Not-Invented-Here%20Syndrom%20vermeiden%20kann&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwie-wardley-mapping-not-invented-here%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ Transformation 12\. Mai 2025 ### Komplexität meistern – Wie Prozessautomatisierung gelingt Erfahrungen aus einem Jahrzehnt Prozessautomatisierung: Warum Kontext, Teamstrukturen und organisatorische Reife wichtiger sind als Technologie allein. Dominik Horn Co-Founder & Geschäftsführer ](/blog/komplexitaet-meistern-prozessautomatisierung/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Wiederverwendbare Prozessbausteine](https://www.miragon.io/blog/wiederverwendbare-prozessbausteine/) BPM Wie wiederverwendbare Prozessbausteine in BPMN die Prozessmodellierung vereinfachen und Low-Code durch klare Schnittstellen ermöglichen. Dominik Horn Co-Founder & Geschäftsführer **04\. Aug. 2022**4 Min. Lesezeit # Einleitung Bei der Automatisierung von End-to-End-Prozessen müssen häufig verschiedene Anwendungen und Systeme integriert werden - nur wenig findet auf der grünen Wiese statt und hat keinerlei Schnittstellen. Doch selbst wenn dies der Fall ist, bieten Wiederverwendbarkeit und Low-Code einige Vorteile bei der Automatisierung von Prozessen - wie diese implementiert werden, ist jedoch entscheidend. Wäre es nicht praktisch, wenn man verschiedene Funktionalitäten einfach und unkompliziert in unterschiedlichen Prozessen verwenden könnte? Das betrifft sowohl Basis-Funktionalitäten wie das Versenden einer E-Mail, das Erzeugen einer Rechnung oder das Speichern eines Dokuments, als auch prozessspezifische Aufgaben wie das Reservieren eines bestimmten Produktes in einem Warenlager - also nahezu alle Aktivitäten eines Prozesses. Über die Verwendung von BPMN haben wir ein Low-Code-Tooling und eine Sprache an die Hand bekommen, um uns gemeinsam mit dem Fachbereich über den Ablauf eines Prozesses zu unterhalten. Außerdem haben wir Prozessexperten in die Lage versetzt, gemeinsam mit Entwicklern automatisierbare Workflows zu entwerfen. Es mag sogar Anbieter von Zero-Code-Tools am Markt geben, die eine Automatisierung komplett ohne Entwickler versprechen. Um diese Art von Low-Code oder Wiederverwendbarkeit geht es in dieser Blogreihe aber nicht. > **Für uns bedeutet Low-Code, dass Entwickler mit Standard-Technologien Funktionalitäten bereitstellen, die einfach wiederverwendet werden können.** Bei der Landeshauptstadt München haben wir im Projekt DigiWF, in dem vieler der hier vorgestellten Konzepte erarbeitet und angewendet wurden, genau dieses Vision-Statement definiert. Wir entwickeln unter Einsatz von offenen Standards Wiederverwendbarkeit für den Fachbereich. Wiederverwendbare Prozessbausteine werden dabei von Entwicklern bereitgestellt und bei der Prozessmodellierung verwendet. Dadurch können Modelle einheitlicher gestaltet und [die Modellierung vereinfacht](/trainings/bpmn-training/) werden. In einfachen Prozessen ist es uns sogar möglich, vollständig auf Entwickler zu verzichten. Low-Code durch Eigenentwicklung - in diesem Fall kein Widerspruch, sondern unser Vision-Statement. In diesem ersten Blogpost der Reihe werden die grundlegenden Konzepte vorgestellt und aufgezeigt, welcher Nutzen für die Prozessmodellierung dadurch entstehen kann. # Anforderungen an die Wiederverwendbarkeit Doch welche Eigenschaften müssen Schnittstellen und Aktivitäten erfüllen, damit sie in verschiedenen Prozessen wiederverwendet werden können? Eine Aktivität im Sinne der BPMN zeichnet sich dadurch aus, dass sie Daten für die Ausführung übergeben bekommt, Logik ausführt und Daten für die weiteren Schritte des Prozesses liefert. Um Wiederverwendbarkeit bei einem Prozessbaustein zu ermöglichen, sollten zunächst die Schnittstellen definiert werden. Welche Daten werden für die Verarbeitung benötigt und welche Daten werden für die weitere Ausführung bereitgestellt? ## Zugriff auf Daten Bei der Automatisierung von Workflows kann in den entsprechenden Schnittstellen auf Daten zugegriffen werden, die sich in verschiedenen Kontexten befinden: - Prozessinstanz - Subprozess - Aktivität - … _Ein Task hat stets auf die eigenen und die übergeordneten Daten Zugriff. Durch das Input- / Output-Mapping können einzelne Tasks in unterschiedlichen Kontexten wiederverwendet werden._ Wenn eine Aktivität in verschiedenen Prozessen wiederverwendet werden soll, sollte der Zugriff auf die Daten einheitlich erfolgen. Hier besteht die Möglichkeit, Daten prozessübergreifend unter dem gleichen Schlüssel zur Verfügung zu stellen oder ausschließlich auf die lokalen Daten der Aktivität zuzugreifen. Aus verschiedene Gründen bietet es sich an, ausschließlich auf lokale Variablen zuzugreifen: - bessere und einfachere Wiederverwendbarkeit - geringere Fehleranfälligkeit bei paralleler Verwendung - klare Definition der Schnittstelle - Versionierung der Schnittstelle - Keine Überlappung verschiedener Schnittstellen - Datenschutz und -sicherheit - … ## Schreiben von Daten Das Gleiche gilt für das Bereitstellen von Daten. Entweder stellt die Schnittstelle lokale Daten bereit oder schreibt diese direkt in einen übergeordneten Scope der Aktivität. Auch hier sprechen die gleichen Argumente dafür, ausschließlich lokale Variablen zu schreiben und bei der Modellierung ein manuelles Mapping der bereitgestellten Daten zu definieren. ## Vorteile Zusammengefasst sollten die folgenden beiden Regeln eingehalten werden: - Es wird ausschließlich auf lokale Variablen zugegriffen - Es werden ausschließlich lokale Variablen geschrieben Wenn wir uns daran halten, können wir uns langfristig eine Bibliothek an Schnittstellen aufbauen, deren Einsatzmöglichkeiten nicht auf einen einzelnen Prozess beschränkt sind. # Wiederverwendbarkeit anhand eines Beispiels Im Prozess ist ein Ausschnitt eines vereinfachten Bestellprozesses zu sehen. Nachdem wir eine Bestellung erhalten haben, muss diese zunächst kontrolliert werden. Nach der Kontrolle wird die Bestellbestätigung und die Rechnung versendet. Bei genauere Betrachtung handelt es sich in beiden Fällen um dasselbe: den Versand einer E-Mail. Die Funktionalität “E-Mail versenden” kann auf das Bereitstellen der Daten - Empfänger - Text - Dokument reduziert werden. Dadurch erhalten wir eine Funktion, die nicht nur im gleichen Prozessmodell, sondern auch prozessübergreifend wiederverwendet werden kann. # Ausblick Doch wie können wir diese Schnittstellen bei der Modellierung verwenden, ohne das Mapping der Daten manuell vornehmen zu müssen? Im nächsten Blogpost lernen wir das Feature “Element-Templates” der Process Engine Camunda kennen und schauen uns an, wie wir durch Low-Code einfache Wiederverwendung ermöglichen und eine Bibliothek aufbauen können, die von unterschiedlichen Prozessen eingesetzt werden kann. Teilen:[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwiederverwendbare-prozessbausteine%2F)[](mailto:?subject=Wiederverwendbare%20Prozessbausteine&body=https%3A%2F%2Fwww.miragon.io%2Fblog%2Fwiederverwendbare-prozessbausteine%2F) ## Dominik Horn Co-Founder & Geschäftsführer bei Miragon [in Dominik kennenlernen](https://www.linkedin.com/in/dominik-horn/) [Mehr von Dominik](/blog/?author=dominik-horn) ## Fandest du den Artikel interessant? Abonniere unseren Newsletter und erhalte neue Beiträge direkt ins Postfach. Abonnieren Ich willige in die Verarbeitung meiner E-Mail zum Newsletter-Versand ein (jederzeit widerrufbar). [Datenschutz](/datenschutz/). ## Das könnte dich auch interessieren Ähnliche Beiträge aus unseren Insights [ BPM 17\. Aug. 2026 ### Was ist eine Prozessapplikation? Eine Prozessapplikation ist ein eigenständig deploybares Software-Bundle, das konkrete Fachprozesse einer Domäne ausführt. Dieser Beitrag definiert den Begriff, zeigt die Bestandteile und grenzt ihn von integrativen Prozessen und der zentralen Taskliste ab. Thomas Heinrichs Solution Architecture Lead ](/blog/was-ist-eine-prozessapplikation/)[ AI 28\. Juli 2026 ### Ausführbar, aber unlesbar: AI-bearbeitete BPMN-Modelle sauber halten AI schreibt BPMN oft schon im ersten Versuch korrekt. Trotzdem kommt das Diagramm häufig kaputt heraus, denn sie sieht nie, was sie zeichnet. Dieser Post zeigt den Loop aus Erkennen, Beheben und Erzwingen, mit dem ich diese visuelle Lücke schließe. Und die Grenze, die ich dabei ziehe. Marco Schäck Process Development Lead ](/blog/ai-bpmn-modelle-visuell-sauber-halten/)[ BPM 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Thomas Heinrichs Solution Architecture Lead ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Redirecting to: /portfolio/camunda-7-migration/](https://www.miragon.io/c7-migration/) ## [Datenschutzerklärung](https://www.miragon.io/datenschutz/) Diese Erklärung beschreibt, welche personenbezogenen Daten wir verarbeiten, wenn du unsere Website besuchst, mit uns in Kontakt trittst, dich bewirbst oder Kunde wirst. Wir halten uns dabei an die DSGVO und das BDSG. Klicke auf eine der Anbieter-Karten unten, um direkt zur Datenschutzerklärung des jeweiligen Dienstleisters zu gelangen. Verantwortlich für die Datenverarbeitung [Impressum](/impressum/) Miragon GmbH Böheimstr. 8, 86153 Augsburg [E-Mail anzeigen](#) ## Deine Rechte Du hast jederzeit das Recht auf: - **Auskunft** über die Daten, die wir zu dir gespeichert haben (Art. 15 DSGVO) - **Berichtigung** falscher oder unvollständiger Daten (Art. 16 DSGVO) - **Löschung** deiner Daten (Art. 17 DSGVO), soweit keine gesetzlichen Aufbewahrungspflichten dem entgegenstehen - **Einschränkung der Verarbeitung** (Art. 18 DSGVO) - **Datenübertragbarkeit** in einem maschinenlesbaren Format (Art. 20 DSGVO) - **Widerspruch** gegen Verarbeitungen, die auf berechtigtem Interesse beruhen (Art. 21 DSGVO) - **Widerruf** einer erteilten Einwilligung (Art. 7 Abs. 3 DSGVO) - der Widerruf wirkt für die Zukunft - **Beschwerde** bei einer Aufsichtsbehörde (Art. 77 DSGVO) Schreib uns einfach an [E-Mail anzeigen](#). Für förmliche Beschwerden ist für uns das **Bayerische Landesamt für Datenschutzaufsicht (BayLDA)** in Ansbach zuständig. Eine automatisierte Entscheidungsfindung einschließlich Profiling im Sinne des Art. 22 DSGVO findet bei uns nicht statt. ## Wenn du unsere Website besuchst ### Hosting & Server-Logs Unsere Website läuft auf der Infrastruktur von Netlify. Bei jedem Aufruf werden in Server-Log-Dateien technische Daten temporär gespeichert: Browsertyp, Betriebssystem, Referrer, Hostname, Zeitstempel und IP-Adresse. Das ist nötig, damit die Seite ausgeliefert werden kann und um Angriffe abzuwehren. Diese Daten werden nicht mit anderen Datenquellen zusammengeführt. **Rechtsgrundlage:** Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am sicheren Betrieb der Seite). **Speicherdauer:** 7 Tage. [ Netlify USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Hosting der Website und Auslieferung der Inhalte. Netlify, Inc., San Francisco, USA 2325 3rd Street, Suite 215, San Francisco, CA 94107, USA ](https://www.netlify.com/privacy/) ### Cookies & Einwilligungen Wir setzen nur die Cookies, die wir wirklich brauchen. Für alles, was darüber hinaus geht (z. B. eingebettete Inhalte von Personio), holen wir vorher deine Einwilligung über unser Consent-Tool ein. Du kannst deine Auswahl jederzeit über das Datenschutz-Symbol unten links anpassen. Die vollständige Liste der eingesetzten Cookies findest du [direkt im Consent-Tool](#). Eine Übersicht der vom Consent-Tool gesetzten Cookies stellt der Anbieter unter [diesem Link](https://help.consentmanager.de/books/cmp/page/cookies-set-by-the-cmp) bereit. **Rechtsgrundlage:** § 25 Abs. 2 Nr. 2 TDDDG (notwendige Speicherung deiner Cookie-Entscheidung); Art. 6 Abs. 1 lit. a DSGVO i.V.m. § 25 Abs. 1 TDDDG (Einwilligung für alle weiteren Cookies und eingebetteten Inhalte). [ consentmanager EU Zeigt das Cookie-Banner und speichert deine Entscheidung. consentmanager GmbH, München, Deutschland Häberlstraße 17, 80337 München, Deutschland ](https://www.consentmanager.net/de/datenschutz/) ### Reichweitenmessung Wenn du der Reichweitenmessung über unser Consent-Tool zustimmst, setzen wir Google Analytics ein, um zu verstehen, welche Inhalte gut ankommen und welche nicht. Ohne deine Einwilligung werden keine Daten an Google übermittelt. **Was wir verarbeiten:** Pseudonyme User-ID, gekürzte IP-Adresse, Geräte- und Browserinformationen, besuchte Seiten, Verweildauer und Referrer. **Rechtsgrundlage:** Art. 6 Abs. 1 lit. a DSGVO (Einwilligung). **Speicherdauer:** 14 Monate (Standardeinstellung in Google Analytics 4); danach werden die Daten automatisch gelöscht. [ Google Analytics EU Reichweitenmessung der Website-Nutzung. Google Ireland Ltd., Dublin, Irland Gordon House, Barrow Street, Dublin 4, Irland ](https://policies.google.com/privacy) ## Wenn du mit uns interagierst ### Kontaktformular Wenn du uns über das Kontaktformular schreibst, verarbeiten wir die von dir eingegebenen Daten (Vorname, Nachname, E-Mail, Unternehmen, Betreff, Nachricht) sowie technische Daten (IP, User Agent, Zeitstempel). Wir nutzen diese Daten ausschließlich, um deine Anfrage zu beantworten. **Rechtsgrundlage:** Art. 6 Abs. 1 lit. b DSGVO (vorvertragliche Maßnahmen) bzw. Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an effizienter Bearbeitung und an Bot-Schutz durch Cloudflare Turnstile). **Speicherdauer:** Bis zur Erledigung deiner Anfrage, längstens 3 Jahre. **Pflicht zur Bereitstellung:** Alle Felder im Formular sind Pflichtfelder - ohne diese Angaben können wir deine Anfrage nicht bearbeiten. [ Notion USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Speichert deine Anfrage zur internen Bearbeitung. Notion Labs, Inc., San Francisco, USA 548 Market Street Suite 74567, San Francisco, CA 94104, USA ](https://www.notion.so/notion/Privacy-Policy-3468d120cf614d4c9014c09f6adc9091)[ Resend USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Versendet die Benachrichtigung an uns und die Bestätigungsmail an dich. Resend Inc., San Francisco, USA 2261 Market Street #5039, San Francisco, CA 94114, USA ](https://resend.com/legal/privacy-policy)[ Cloudflare Turnstile USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Schützt das Formular vor Bots - ohne Captcha, ohne Cookies. Cloudflare, Inc., San Francisco, USA 101 Townsend St., San Francisco, CA 94107, USA ](https://www.cloudflare.com/privacypolicy/) ### Newsletter Für unseren Newsletter nutzen wir Mailchimp. Wir verwenden das Double-Opt-in-Verfahren: Nach deiner Anmeldung bekommst du eine Bestätigungsmail - erst nach dem Klick darauf erhältst du tatsächlich den Newsletter. Du kannst dich jederzeit über den Abmeldelink in jeder Mail wieder austragen. Mailchimp wertet Öffnungs- und Klickraten der Newsletter pseudonymisiert aus, damit wir verstehen, welche Themen für euch interessant sind. Diese Auswertung ist von deiner Newsletter-Einwilligung mit umfasst und endet mit deiner Abmeldung. **Was wir verarbeiten:** E-Mail-Adresse, Anmeldezeitpunkt, Bestätigungszeitpunkt, IP zum Anmeldezeitpunkt. **Rechtsgrundlage:** Art. 6 Abs. 1 lit. a DSGVO (Einwilligung); für den Bot-Schutz durch Cloudflare Turnstile: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Schutz vor Missbrauch). **Speicherdauer:** Bis zum Widerruf deiner Einwilligung (Abmeldung über den Link in jeder Mail). Anschließend werden deine Daten gelöscht. [ Mailchimp USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Verwaltet die Newsletter-Liste und versendet die Mails. The Rocket Science Group LLC, Atlanta, USA 675 Ponce de Leon Ave NE, Suite 5000, Atlanta, GA 30308, USA ](https://www.intuit.com/privacy/statement/)[ Cloudflare Turnstile USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Schützt das Formular vor Bots - ohne Captcha, ohne Cookies. Cloudflare, Inc., San Francisco, USA 101 Townsend St., San Francisco, CA 94107, USA ](https://www.cloudflare.com/privacypolicy/) ### Terminbuchung Wenn du einen Termin buchen möchtest, leiten wir dich auf calendly.com weiter. Calendly verarbeitet deine Daten dort eigenverantwortlich - wir selbst übermitteln keine Daten an Calendly. Die Terminabwicklung erfolgt dann über Microsoft 365. **Rechtsgrundlage** (für die Terminabwicklung): Art. 6 Abs. 1 lit. b DSGVO (vorvertragliche Maßnahmen). **Speicherdauer:** Wenn aus dem Termin eine Geschäftsbeziehung wird, gelten die Speicherfristen aus dem Abschnitt „Wenn du Kunde oder Vertragspartner bist”. Andernfalls löschen wir die Termin- und Mail-Daten nach längstens 6 Monaten. [ Calendly USA Terminplanungs-Tool für Erstgespräche und Workshops. Calendly LLC, Avondale Estates, USA 88 N Avondale Rd #603, Avondale Estates, GA 30002, USA ](https://calendly.com/privacy)[ Microsoft 365 USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Mail-Kommunikation und Videokonferenzen. Microsoft Corporation, Redmond, USA One Microsoft Way, Redmond, WA 98052-6399, USA ](https://privacy.microsoft.com/privacystatement) ## Wenn du unsere Tools nutzt Wir entwickeln und betreiben eigene Tools, die teilweise über Links auf dieser Website erreichbar sind. Sie laufen auf unserer Infrastruktur bei Fly.io in der EU-Region Frankfurt. Fly.io ist unser Auftragsverarbeiter nach Art. 28 DSGVO. Solange du auf dieser Webseite bleibst, werden dafür weder Cookies gesetzt noch Daten an Fly.io übermittelt, die Verarbeitung beginnt erst, wenn du dem Link folgst. **Was wir verarbeiten:** Bei jedem Aufruf entstehen Server-Logs mit IP-Adresse, Zeitstempel, aufgerufener Adresse, Browsertyp und Betriebssystem. Einen Teil der Tools kannst du ohne Anmeldung nutzen. In diesen Fällen erfassen wir keine weiteren Daten. Bei Tools mit Nutzerkonto kommen die Registrierungsdaten (Name, E-Mail-Adresse, GitHub-Handle, GitLab-Handle) und die Inhalte hinzu, die du im Tool anlegst oder hochlädst. **Rechtsgrundlage:** Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am sicheren und stabilen Betrieb) für die Server-Logs; Art. 6 Abs. 1 lit. b DSGVO (Erfüllung des Nutzungsverhältnisses) für Konten und die darin gespeicherten Inhalte. **Speicherdauer:** Server-Logs 30 Tage. Kontodaten und Inhalte, bis du dein Konto löschst oder die Löschung verlangst. **Pflicht zur Bereitstellung:** Für Tools ohne Anmeldung musst du nichts angeben. Für ein Nutzerkonto brauchen wir deinen Name, E-Mail-Adresse und GitHub- bzw. GitLab-Handle. Welche dieser Informationen notwendig sind, ist vom gewählten Tool abhängig. [ Fly.io USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Betrieb unserer selbst entwickelten Tools (EU-Region Frankfurt). Fly.io, Inc., San Francisco, USA 2261 Market Street #4990, San Francisco, CA 94114, USA ](https://fly.io/legal/privacy-policy/) ## Wenn du dich bei uns bewirbst Auf unserer Karriere-Seite binden wir die offenen Stellen direkt aus Personio ein. Das Iframe wird **erst nach deiner ausdrücklichen Einwilligung** geladen - vorher fließen keine Daten an Personio. Bewirbst du dich, verarbeiten wir deine Bewerbungsdaten (Name, Anschreiben, Lebenslauf, Zeugnisse), um deine Eignung zu prüfen. Wir behandeln deine Unterlagen vertraulich und teilen sie nur mit Personen, die im Bewerbungsprozess aktiv eingebunden sind. Wir fragen keine besonderen Kategorien personenbezogener Daten nach Art. 9 DSGVO (z. B. Gesundheit, Religion, ethnische Herkunft) ab und bitten dich, solche Angaben auch unaufgefordert zu vermeiden, soweit sie für die Stelle nicht erforderlich sind. **Rechtsgrundlage:** Art. 6 Abs. 1 lit. a DSGVO (Einwilligung für die Stellenanzeigen-Einbettung); Art. 6 Abs. 1 lit. b DSGVO (vorvertragliche Maßnahmen) bzw. Art. 6 Abs. 1 lit. c DSGVO (gesetzliche Pflichten). **Speicherdauer:** Bei Absage löschen wir deine Daten spätestens 6 Monate nach Abschluss des Verfahrens (Beweissicherung gem. AGG); bei Zusage übernehmen wir sie in deine Personalakte. Eine Aufnahme in den Talent-Pool erfolgt nur mit deiner ausdrücklichen Einwilligung; deine Daten verbleiben dort bis zu deinem Widerruf, der jederzeit möglich ist. **Pflicht zur Bereitstellung:** Für die Bewertung deiner Eignung benötigen wir Name, Anschreiben, Lebenslauf und Zeugnisse - ohne diese Angaben können wir deine Bewerbung nicht prüfen. Weitere Angaben (z. B. Foto) sind freiwillig. [ Personio DE Stellenanzeigen und Bewerbungsverwaltung. Personio SE & Co. KG, München, Deutschland Rundfunkplatz 4, 80335 München, Deutschland ](https://www.personio.de/datenschutzerklaerung/)[ Microsoft 365 USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Mail-Kommunikation und Videokonferenzen. Microsoft Corporation, Redmond, USA One Microsoft Way, Redmond, WA 98052-6399, USA ](https://privacy.microsoft.com/privacystatement)[ Notion USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Interne Dokumentation des Bewerbungsprozesses. Notion Labs, Inc., San Francisco, USA 548 Market Street Suite 74567, San Francisco, CA 94104, USA ](https://www.notion.so/notion/Privacy-Policy-3468d120cf614d4c9014c09f6adc9091) ## Wenn du Kunde oder Vertragspartner bist Im Rahmen unserer Geschäftsbeziehung verarbeiten wir Stamm-, Kontakt-, Vertrags- und Zahlungsdaten - alles, was nötig ist, um Verträge zu erfüllen, Rechnungen zu schreiben und mit dir zu kommunizieren. Wir geben Daten nur an Dienstleister weiter, die uns bei der Leistungserbringung unterstützen, und schließen mit ihnen Auftragsverarbeitungsverträge nach Art. 28 DSGVO. **Rechtsgrundlage:** Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung), Art. 6 Abs. 1 lit. c DSGVO (gesetzliche Pflichten, z. B. Steuer- und Handelsrecht), Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an der Pflege bestehender Geschäftsbeziehungen, an der Sicherung von Forderungen sowie an der Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen). **Speicherdauer:** So lange wie für die Geschäftsbeziehung erforderlich, danach Löschung. Gesetzliche Aufbewahrungspflichten (z. B. 10 Jahre für Rechnungen nach HGB/AO) bleiben unberührt. **Pflicht zur Bereitstellung:** Für den Abschluss und die Erfüllung des Vertrags benötigen wir die Stamm-, Kontakt- und Zahlungsdaten - ohne diese kann kein Vertrag zustande kommen. [ Microsoft 365 USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Mail-Kommunikation, Office-Dokumente und Videokonferenzen. Microsoft Corporation, Redmond, USA One Microsoft Way, Redmond, WA 98052-6399, USA ](https://privacy.microsoft.com/privacystatement)[ LexWare Office DE Rechnungsstellung und Kundenverwaltung. Haufe Service Center GmbH, Freiburg, Deutschland Munzinger Straße 9, 79111 Freiburg, Deutschland ](https://www.lexoffice.de/datenschutz/)[ Amazon Web Services EU Cloud-Infrastruktur für Kundenprojekte (EU-Regionen). AWS EMEA SARL, Luxemburg 38 avenue John F. Kennedy, L-1855 Luxemburg ](https://aws.amazon.com/de/privacy/)[ Google Cloud EU Cloud-Infrastruktur für Kundenprojekte (EU-Regionen). Google Ireland Ltd., Dublin, Irland Gordon House, Barrow Street, Dublin 4, Irland ](https://cloud.google.com/security/privacy)[ Fly.io USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Cloud-Infrastruktur für unsere Tools und Kundenprojekte (EU-Region Frankfurt). Fly.io, Inc., San Francisco, USA 2261 Market Street #4990, San Francisco, CA 94114, USA ](https://fly.io/legal/privacy-policy/)[ Auth0 USA DPF Datenübermittlung in die USA über das EU-U.S. Data Privacy Framework Authentifizierung in Kundenanwendungen. Auth0, Inc. (Okta), Bellevue, USA 10800 NE 8th Street, Suite 600, Bellevue, WA 98004, USA ](https://www.okta.com/privacy-policy/) ## Social Media Wir sind auf einigen Plattformen präsent. Wenn du dort mit uns interagierst, gelten die Datenschutzbedingungen der jeweiligen Plattform - auf deren Datenverarbeitung haben wir nur begrenzten Einfluss. **Rechtsgrundlage:** Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Außendarstellung und Kommunikation mit Interessenten). Bei LinkedIn besteht für die statistische Auswertung von Besucherinteraktionen unserer Unternehmensseite (Page Insights) eine gemeinsame Verantwortlichkeit mit LinkedIn nach Art. 26 DSGVO. Die Verteilung der datenschutzrechtlichen Pflichten ist im [Page Insights Joint Controller Addendum](https://legal.linkedin.com/pages-joint-controller-addendum) geregelt. [ LinkedIn EU Unternehmensprofil und Networking. LinkedIn Ireland Unlimited Co., Dublin, Irland Wilton Place, Dublin 2, Irland ](https://www.linkedin.com/legal/privacy-policy)[ GitHub EU Open-Source-Repositories und Projektarbeit. GitHub B.V., Amsterdam, Niederlande Vijzelstraat 68-72, 1017 HL Amsterdam, Niederlande ](https://docs.github.com/site-policy/privacy-policies/github-general-privacy-statement)[ Medium USA Blog- und Content-Publishing. A Medium Corporation, San Francisco, USA P.O. Box 602, San Francisco, CA 94104, USA ](https://policy.medium.com/medium-privacy-policy-f03bf92035c9) ## Übermittlung in Drittländer Einige der oben genannten Tools verarbeiten Daten außerhalb der EU - überwiegend in den USA. Damit dort ein angemessenes Schutzniveau gewährleistet ist, stützen wir uns auf die Garantien nach Art. 44 ff. DSGVO: - **DPF - Data Privacy Framework:** Angemessenheitsbeschluss der EU-Kommission vom 10.07.2023 zum EU-U.S. Data Privacy Framework - **SCC - Standard Contractual Clauses:** EU-Standardvertragsklauseln nach Art. 46 Abs. 2 lit. c DSGVO (Beschluss 2021/914 vom 04.06.2021), ergänzt um zusätzliche technische und organisatorische Maßnahmen Welche Garantie für welchen Anbieter gilt, siehst du oben am Badge **DPF** bzw. **SCC** der jeweiligen Karte. Den aktuellen Zertifizierungsstatus kannst du in der [offiziellen DPF-Liste](https://www.dataprivacyframework.gov/list) prüfen. Bei Anbietern mit EU-Vertragspartner kann es zu konzerninternen Übermittlungen in Drittländer kommen - diese sind durch DPF/SCC abgesichert. Trotz dieser Garantien können US-Behörden auf Grundlage von Gesetzen wie dem CLOUD Act oder FISA 702 unter bestimmten Voraussetzungen auf Daten zugreifen. Ein vollständig gleichwertiges Schutzniveau wie in der EU lässt sich daher nicht in jedem Fall zusichern. Die von uns verwendeten Standardvertragsklauseln entsprechen dem [Durchführungsbeschluss (EU) 2021/914](https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj) der EU-Kommission und sind dort öffentlich einsehbar. Stand: 10. August 2026 - wir aktualisieren diese Erklärung bei rechtlichen Änderungen oder neuen Tools. Kein Datenschutzbeauftragter bestellt (§ 38 BDSG). ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Impressum](https://www.miragon.io/impressum/) Miragon GmbH Böheimstr. 8 86153 Augsburg ## Geschäftsführung - Alexander Praschek - Dominik Horn ## Kontakt E-Mail [E-Mail anzeigen](#) Kontaktformular [miragon.io/kontakt](/kontakt/) ## Rechtliche Angaben Handelsregister HRB 34395 · Amtsgericht Augsburg Umsatzsteuer-ID (§ 27a UStG) DE328157372 ## Redaktionelle Verantwortung (§ 18 Abs. 2 MStV) Alexander Praschek und Dominik Horn Miragon GmbH Böheimstr. 8 86153 Augsburg ## Berufshaftpflichtversicherung Versicherer Markel Insurance SE Sophienstr. 26, 80333 München Registereintrag HRB 233618 · Amtsgericht München Geltungsraum Weltweit ## Verbraucherstreitbeilegung Wir sind nicht bereit oder verpflichtet, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen. Quelle: [eRecht24](https://www.e-recht24.de/impressum-generator.html) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Zeig uns, was du bewegen kannst.](https://www.miragon.io/karriere/) Wir schreiben keine Stellen aus und suchen auch keine Lebensläufe, die auf ein Anforderungsprofil passen. Wir suchen Menschen, die uns und unsere Kunden voranbringen. Wenn du glaubst, dass du das kannst, dann melde dich bei uns. Wer wir sind ## Wir befähigen Teams, ihre Prozesse selbst zu transformieren. Nachhaltiger Erfolg kommt nicht von außen. Er entsteht, wenn ein Team seine Prozesse selbst versteht und weiterentwickelt. Genau dahin bringen wir Unternehmen. Und das ist unsere Mission. Why ### Warum wir das tun Um Teams zu befähigen. - Um Teams ihre Prozesse selbst transformieren zu lassen - Um Unternehmen unabhängig zu machen, nicht abhängig von uns - Um sie handlungsfähig zu halten, egal wie sich der Markt dreht - Um echten Erfolg von innen entstehen zu lassen, nicht von außen How ### Wie wir arbeiten Gemeinsam umsetzen. - Wir setzen gemeinsam um, statt nur zu beraten - Wir nutzen offene, herstellerunabhängige Technologien - Wir empfehlen ehrlich, auch mal „braucht ihr nicht" - Wir coden mit dem Team, damit das Wissen bleibt What ### Was wir tun Von Analyse bis Betrieb. - Wir analysieren, welche Prozesse sich lohnen - Wir entwerfen Architektur, entwickeln und betreiben - Wir schulen: BPMN, Workflow-Engines, KI-gestütztes Entwickeln - Wir denken Technik, Organisation und Menschen zusammen Unsere Werte ## Drei Werte, die im Alltag gelebt werden. Wir bauen auf Vertrauen statt Regeln. Diese drei Werte sind für uns der Kern davon. ### Wohlwollend Wir begegnen Menschen unvoreingenommen, fragen nach statt zu urteilen und teilen unser Wissen offen. ### Mutig & aufgeschlossen Wir sprechen Herausforderungen an, geben konstruktives Feedback und probieren neue Ideen aus. ### Verantwortungsvoll Wenn wir eine Aufgabe übernehmen, können sich alle darauf verlassen. Wir halten Zusagen ein. So arbeiten wir ## Zwei Rollen, keine Schubladen Versteh die beiden Rollen nicht als feste Kategorien, sondern als Orientierung: So denken wir oft über unsere Arbeit. In der Praxis bewegen sich die meisten zwischen beiden, je nach Projekt und Phase. Wo du dich einbringst, finden wir gemeinsam mit der Zeit heraus. Solution Architect ### Den roten Faden über Projekte hinweg. Eher der Blick über mehrere Projekte hinweg. Das gibt Perspektive statt Tunnelblick. - Begleitet oft mehrere Kunden und bringt Querschnittserfahrung in jedes Projekt ein. - Schaut eher aufs große Ganze: Enterprise-Architektur, Schnittstellen, Organisation, Leitplanken. - Bringt übergeordnete, für den Kunden relevante Themen in die Projektarbeit ein. - Gibt Wissen weiter und stärkt andere, sodass sie mit der Zeit selbst Architekturverantwortung übernehmen. Kurz: Du hebst einzelne Projekte auf ein gemeinsames, höheres Niveau, mit Breite statt Dauerlast. Solution Engineer ### Aus einer Idee wird eine Lösung. Eher die Schnittstelle zwischen Problem und Lösung: tief im Projekt, nah am Kunden, mit KI als Delivery-Beschleuniger im Rücken. - Ist meist tief in ein bis zwei Projekten und kennt Stakeholder, Domäne und Historie im Detail. - Bringt die Umsetzung voran, gemeinsam mit dem Team. Nutzt KI-Agenten als Hebel und schreibt bei Bedarf auch selbst Code. - Denkt eher in fachlichen Lösungen als in Features. Technik ist Werkzeug, nicht Selbstzweck. - Bringt starke Beratungs-Skills mit: Stakeholder-Arbeit, Scoping, Moderation, Facilitation. Kurz: Du machst aus einer groben Richtung strukturiert eine funktionierende Lösung. Keine Leiter, keine festen Grenzen: zwei Denkweisen, die ineinander übergehen. Stimmen aus dem Team ## Wie es ist, bei Miragon zu arbeiten. > Ich kann Architektur-Entscheidungen wirklich mitgestalten, statt nur Tickets abzuarbeiten. Verantwortung gibt's hier ab Tag eins. Marco Schäck Process Development Lead [Marco kennenlernen](https://www.linkedin.com/in/schaeckm/) > Ich kann mich bei Miragon überall einbringen und Themen auf ganz verschiedenen Ebenen vorantreiben. Beim Kunden genauso wie in unserer eigenen Organisation. Kein Tag ist wie der andere und das gefällt mir besonders. Thomas Heinrichs Solution Architecture Lead [Thomas kennenlernen](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/) > Bei Miragon bringen wir nicht nur unsere Kunden voran, sondern auch uns gegenseitig. Jeder hat andere Schwerpunkte und Erfahrungen - davon profitiert das Team. Andreas Riepl Senior IT-Consultant [Andreas kennenlernen](https://www.linkedin.com/in/andreas-riepl) > Das 4+1-Modell ist kein Marketing: Ein Tag pro Woche gehört wirklich meiner Weiterentwicklung. Lukas Mösle IT-Consultant [Lukas kennenlernen](https://www.linkedin.com/in/lukas-moesle) > Hier darf ich neue Technologien ausprobieren, statt nur Bewährtes zu verwalten – das hält die Arbeit spannend. Peter Heinemann IT-Consultant [Peter kennenlernen](https://www.linkedin.com/in/peter-heinemann-465054393/) > Als Werkstudent bekomme ich viel Raum, meinen Kompetenzbereich auszubauen: erfahrene Kollegen als Sprungbrett in komplexe Themen und Mitsprache bei strategischen Entscheidungen, trotz geringer Erfahrung. Lukas Weber Werkstudent [Lukas kennenlernen](https://www.linkedin.com/in/lukas-weber-87a762259/) > Ich entwickle und berate prozessorientierte Anwendungen mit Camunda und Spring Boot, von der BPMN-Analyse bis in den Betrieb. Jakob Arndt IT-Consultant [Jakob kennenlernen](https://www.linkedin.com/in/jakob-arndt-795008ab/) + Noch frei Hier fehlt noch eine Stimme – deine. Bewirb dich, und in einem Jahr erzählst du an dieser Stelle, wie es wirklich ist. [Jetzt bewerben](https://miragon.jobs.personio.de/job/1005272?apply) + Worauf wir schauen ## Nicht, was auf dem Papier steht. Sondern, wie du denkst. Vier Dinge sagen uns mehr als jede Zertifikatsliste. Wenn du dich hier wiederfindest, sollten wir reden. ### Technische Tiefe Du willst verstehen, warum etwas funktioniert, nicht nur, dass es funktioniert. ### Kommunikation Du erklärst Komplexes so, dass ein CTO und ein Junior es beide verstehen. ### Eigenverantwortung Du wartest nicht auf Aufgaben. Du erkennst, was fehlt, und machst es. ### Beratungs-Mindset Du denkst in Kundenproblemen, nicht in Technologien. Kein Anforderungskatalog ## Wir haken keine Listen ab. Wir hören dir zu. Du musst nicht jeden Punkt „erfüllen". Uns interessiert nicht, ob du zehn Jahre Erfahrung in Framework X hast, sondern wie du denkst und was du bei uns bewegen würdest. Kein Coding-Test als Hürde, sondern ein echtes Gespräch. ✕„Mindestens 5 Jahre Erfahrung mit …" ✕„Abgeschlossenes Studium der Informatik zwingend erforderlich" ✕Zwanzig Bullet-Points, die du zu 100 % abhaken musst ✓Was du wirklich schon gebaut hast, nicht was im Lebenslauf steht ✓Ob du Neugier mitbringst und gerne dazulernst ✓Ob du zu uns und unseren Werten passt [Zeig uns, was du kannst](https://miragon.jobs.personio.de/job/1005272?apply) Was du zurückbekommst ## Impact heißt nicht Dauerstress. Wir stellen nicht die Benefits in den Vordergrund, sondern dich. Aber weil sie zeigen, wie wir ticken, hier das Wichtigste, mit Fokus auf Autonomie und Balance. ### 4+1-Modell Bis zu ein Tag pro Woche für Open Source, neue Technologien oder eigene Ideen. Du wählst das Thema. ### Echte Flexibilität Remote, Büro oder Workation, ohne Genehmigung und ohne schlechtes Gewissen. 30 Tage Urlaub. ### Freie Hardwarewahl Top-Equipment nach deinem Geschmack: Laptop, 49"-Monitor, höhenverstellbarer Tisch. Auch fürs Home-Office. ### Gewinnbeteiligung Wenn Miragon erfolgreich ist, profitierst du direkt davon. Gute Arbeit zahlt sich für alle aus. ### Faires, transparentes Gehalt Wir suchen starke Menschen und bezahlen fair, transparent und überdurchschnittlich. ### Sachbezugskarte Monatliches Extra für Alltag, Einkauf oder Mittagspause. Ohne komplizierte Prozesse. Wo wir arbeiten ## In Augsburg, in Hamburg oder komplett remote. Arbeite dort, wo du am produktivsten bist. Wichtig ist, was du beiträgst, nicht wo dein Schreibtisch steht. Augsburg Unser Büro im Großraum Augsburg und München. Hier schlägt das Herz des Teams. Hamburg Hier hat schon ein Kollege aus unserem Team seinen festen Platz. Vielleicht bald nicht mehr allein? Full Remote Ein Teil des Teams arbeitet komplett und dauerhaft remote. Bewerbungsprozess ## Transparent, persönlich, schnell. Du lernst uns digital kennen, triffst das Team vor Ort und zeigst uns, wie du denkst und arbeitest. Danach entscheiden wir klar, in beide Richtungen. 1 ### Zeig dich Ein Link zu dir (LinkedIn, GitHub oder Portfolio) und ein paar Sätze. Kein Anschreiben nötig. 2 ### Digitales Kennenlernen Wir sprechen über dich, deine Art zu denken und was dich reizt. 3 ### Team & Praxis Du triffst das Team vor Ort und arbeitest an einer echten Aufgabe. 4 ### Klare Entscheidung Wir entscheiden schnell und transparent. Kein Warten im Ungewissen. Noch Fragen? ## Sprich uns gerne direkt an. Keine Anonymität, kein Formular-Dschungel. Melde dich mit deiner Frage einfach direkt bei einem von uns. ### Thomas Heinrichs Growth Lead Kennt die Projekte von innen und beantwortet dir alle fachlichen Fragen zu den Rollen und zum Arbeiten bei uns. [](mailto:thomas.heinrichs@miragon.io "E-Mail an Thomas Heinrichs")[](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/ "Thomas Heinrichs auf LinkedIn")[](https://calendly.com/thomas-heinrichs/30min "Termin mit Thomas Heinrichs buchen") ### Marion Götz People & HR Deine erste Ansprechpartnerin für Bewerbung, Kennenlernen und alles rund um den Einstieg bei Miragon. [](mailto:marion.goetz@miragon.io "E-Mail an Marion Götz")[](https://www.linkedin.com/in/marion-g%C3%B6tz-08685a208/ "Marion Götz auf LinkedIn") ## Überzeugt, dass du zu uns passt? Dann sende uns eine Initiativbewerbung. Kein Anschreiben nötig. Ein Link, der zu dir passt (LinkedIn, GitHub oder Portfolio), und ein paar Sätze, warum du glaubst, dass du uns voranbringst, reichen uns. [Initiativbewerbung senden](https://miragon.jobs.personio.de/job/1005272?apply) Wir melden uns innerhalb von 3 Tagen. ## [Lass uns deinen größten Hebel finden.](https://www.miragon.io/kontakt/) Beschreib uns kurz deine Situation. Innerhalb eines Tages bekommst du eine ehrliche Einschätzung, ob und wo wir helfen können. Adresse Böheimstraße 8, 86153 Augsburg E-Mail [E-Mail anzeigen](#) Keine Lust auf Formulare? [Direkt Termin vereinbaren](https://calendly.com/thomas-heinrichs/30min) Vorname Nachname E-Mail \* Firma Betreff \* Nachricht \* Ich stimme der Verarbeitung meiner Daten zur Bearbeitung meiner Anfrage zu. [Datenschutz](/datenschutz/) \* Anfrage senden FAQ ## Häufig gestellte Fragen Die wichtigsten Fragen, bevor wir zusammenarbeiten. Wie läuft ein Erstgespräch ab? Wir hören zu, stellen Fragen und geben dir eine ehrliche Einschätzung. Innerhalb eines Tages. Kein Pitch-Deck, kein Vertriebsgespräch. Wenn wir helfen können, sagen wir dir wie. Wenn nicht, sagen wir dir das auch. Für welche Unternehmen arbeitet ihr? Mittelstand bis Konzern, branchenunabhängig. Überall dort, wo Prozesse manuell laufen, die nicht manuell laufen müssten. Unsere Kunden reichen von Drogeriemärkten über Stadtverwaltungen bis zu Software-Unternehmen. Müssen wir Camunda einsetzen? Nein. Wir sind herstellerunabhängig und empfehlen die Technologie, die zu eurer Architektur passt, ob Camunda, CIB Seven, Temporal oder etwas anderes. Manchmal ist die Antwort auch: bleibt bei dem, was ihr habt. Wie stellt ihr sicher, dass wir nicht abhängig von euch werden? Alles, was wir bauen, bauen wir mit eurem Team. Pair Programming, Code Reviews, Wissenstransfer. Unser Ziel ist, dass ihr nach dem Projekt eigenständig weiterarbeiten könnt. Das ist kein Lippenbekenntnis, sondern unser Geschäftsmodell. Was kostet die Zusammenarbeit? Das hängt vom Scope ab. Ein Quickcheck ist in einem Tag erledigt, ein Pilotprojekt dauert Wochen, eine Skalierung Monate. Im Erstgespräch klären wir, was für euch sinnvoll ist, bevor wir über Kosten reden. ## [Analyse. Architektur. KI-gestütztes Enablement.](https://www.miragon.io/leistungen/) Wir begleiten dich von der Prozessanalyse über die technische Umsetzung bis zu dem Punkt, an dem dein Team eigenständig weiterbaut. Mit KI-Tools, die im Alltag wirklich Tempo bringen. ### Analyse & Collaborative Modelling Prozesse verstehen, bevor wir sie verändern. Gemeinsam mit deinem Team modellieren wir Ist- und Soll-Zustände, datenbasiert und visuell. ### Architektur & Implementierung Vom Architekturentwurf bis zum produktiven System. Wir bauen skalierbare Lösungen, die sich in deine bestehende IT-Landschaft einfügen. ### KI-Tooling Enablement Wir bringen KI-Werkzeuge in den Alltag deines Teams. Kein Hype, sondern Tempo, das bleibt: Code entsteht schneller und hält trotzdem. ## Unsere Lösungen im Detail [ ### Prozessautomatisierung Systeme verbinden und manuelle Schritte automatisieren, technologieneutral und hands-on. ](/portfolio/automate/) [ ### KI-Integration KI mit deinen ERP-, CRM- und Fachsystemen verbinden, damit sie im Alltag wirklich arbeitet. ](/portfolio/ki-integration/) [ ### Camunda 7 Migration C7-Landschaft analysieren und ehrlich den richtigen Migrationspfad wählen. ](/portfolio/camunda-7-migration/) Im Detail ## Was hinter den drei Säulen steckt Jede Säule steht für eine Phase in der Zusammenarbeit: von der ersten Analyse bis zur eigenständigen Weiterentwicklung durch dein Team. - ### Analyse & Collaborative Modelling Process Mining auf realen Daten, Interviews mit Prozessbeteiligten und gemeinsame BPMN-Modellierung. Wir identifizieren Engpässe, priorisieren nach Impact und schaffen ein gemeinsames Prozessverständnis als Grundlage jeder erfolgreichen Automatisierung. - ### Architektur & Implementierung Camunda, Flowable, Temporal, Event-Driven Architecture. Wir wählen die Technologie, die passt, und setzen sie um. Clean Architecture, API-Integration und schrittweiser Rollout sorgen dafür, dass Lösungen nicht nur funktionieren, sondern wartbar bleiben. - ### KI-Tooling Enablement Wir bringen KI-Werkzeuge in den Arbeitsalltag deines Teams: Code-Generierung, automatisierte Testabdeckung, intelligente Prozessoptimierung. Am Ende baut dein Team selbst weiter, ohne bei jedem Schritt auf uns zu warten. Workshop ## Soziotechnische Systeme: Automatisierung als Gesamtsystem Automatisierung ist kein reines IT-Projekt. In unserem Workshop verbindet dein Team Technik, Organisation, Prozesse und Kultur und vermeidet die Fallen, an denen Initiativen scheitern. 1-2 TageBis 12 PersonenVor Ort oder Remote - Automatisierung als Gesamtsystem aus Technik, Mensch und Prozess denken - Team Topologies und Wardley Mapping als Entscheidungsgrundlage - Build-vs-Buy fundiert klären, statt nach Bauchgefühl - Wirkung messen statt Features zählen [Workshop ansehen](/trainings/soziotechnische-systeme-workshop/) Enablement ## Trainings, mit denen dein Team unabhängig wird Unsere Trainings sind praxisnah, hands-on und maßgeschneidert. Egal ob CIB seven, BPMN oder AI im Projektalltag, am Ende ist dein Team in der Lage, eigenständig weiterzubauen. [ 4 Tage · Java & Architektur ### Camunda 8 Developer Training Vom ersten Modell bis zum stabilen Camunda 8 Betrieb. Vier Tage Hands-on für Java-Entwickler und Architekten, mit allen Patterns für robuste Camunda-8-Projekte. Mehr erfahren ](/trainings/camunda-8-developer-training/)[ 3 Tage · Java & Architektur ### CIB seven Developer Training Vom ersten BPMN-Modell bis zum getesteten External-Task-Worker. Drei Tage Hands-on für Java-Entwickler und Architekten, mit allen Patterns für robuste CIB-seven-Projekte. Mehr erfahren ](/trainings/cib-seven-developer-training/)[ 2 Tage · vendor-agnostisch ### Quickcheck Prozessautomatisierung Strukturierte Ist-Aufnahme, Zielbild, Wardley Mapping und priorisierte Roadmap. In zwei Tagen aus der Analyse-Schleife in die Umsetzung. Mehr erfahren ](/trainings/process-automation-quickcheck/)[ 3+1 Tage · Fach & IT ### BPMN 2.0 & DMN Training Drei Tage BPMN 2.0 für Fachbereiche und IT, plus optionaler DMN-Deep-Dive-Tag. Praxisnah, mit eigenen Prozessen als Übungsmaterial. Mehr erfahren ](/trainings/bpmn-training/)[ 1 Tag · vendor-agnostisch ### AI in der Prozessautomatisierung AI als Entwicklungspartner entlang des BPM-Lifecycles. Ein Tag, der dein Team befähigt, AI-Agenten gezielt und mit klaren Guardrails einzusetzen. Mehr erfahren ](/trainings/ai-tooling-workshop/) Tools ## Werkzeuge, die deine Prozessarbeit beschleunigen Quelloffene Tools, die wir in Kundenprojekten selbst einsetzen. Sofort startklar, mit Support und Weiterentwicklung direkt vom Team, das sie baut. [ ### Miragon AI Sprich mit deinen Prozessen: Status, Kennzahlen und Incident-Lösungen zu Camunda & CIB seven, direkt in deinem Agenten statt im Cockpit. Mehr erfahren ](/tools/)[ ### BPMN Modeler Modelliere BPMN 2.0 und DMN dort, wo du ohnehin arbeitest. Vom sauberen Modell bis zum Rollout bleibt alles in einem Werkzeug, ganz ohne Tool-Wechsel. Mehr erfahren ](/tools/)[ ### Wardley Maps Modeler Modelliere Wardley Maps für strategische Architektur- und Geschäftsentscheidungen. Als Web-App und VS-Code-Extension, sofort einsatzbereit. Mehr erfahren ](/tools/) [Alle Tools ansehen](/tools/) Weiterlesen ## Einblicke aus unserem Blog [ 18\. Juni 2026 ### Agent-Skills: Wie AI auch in Nischen-Domänen wie BPMN & Prozessautomatisierung zuverlässig wird AI macht Routine-Coding austauschbar – doch in Nischen-Domänen wie der Prozessautomatisierung mit BPMN und Zeebe liefern reine Prompts inkonsistente Ergebnisse. Wie Agent-Skills Domänenwissen kodieren und AI auch hier zuverlässig machen. Weiterlesen ](/blog/agent-skills-ai-nischen-domaenen-bpmn/) [ 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Weiterlesen ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) [ 04\. Mai 2026 ### Miragon AI: Vom Cockpit zur Konversation Wie wir bei Miragon Prozessautomatisierung neu denken: weg vom isolierten Cockpit, hin zur Konversation als Interface. Warum das MCP und MCP Apps das Fundament dafür bilden. Weiterlesen ](/blog/miragon-ai-vom-cockpit-zur-konversation/) ## Bereit für den nächsten Schritt? Egal ob Analyse, Implementierung oder KI-Enablement: Lass uns in einem kurzen Gespräch herausfinden, wo der größte Hebel für dich liegt. [Erstgespräch vereinbaren](/kontakt/) ## [Redirecting to: /leistungen/](https://www.miragon.io/portfolio/) ## [Automate Anything, Everywhere.](https://www.miragon.io/portfolio/automate/) Deine Systeme sind da. Deine Prozesse auch. Was fehlt, ist die Verbindung. Wir automatisieren, was dein Team ausbremst, technologieneutral und hands-on. [Erstgespräch vereinbaren](/kontakt/) Das Problem ## Was dich manuelle Prozesse wirklich kosten Jede manuelle Übergabe ist ein Risiko. Jede Excel-Liste ein Single Point of Failure. Jede E-Mail-Kette ein blinder Fleck. Das summiert sich, jeden Tag. - ### Tage statt Minuten Drei Unterschriften, zwei Postfächer, ein Schreibtisch. Fünf Tage Durchlaufzeit für eine Freigabe, die zehn Minuten dauern sollte. - ### Fehler, die niemand sieht Ohne zentrale Steuerung fehlt der Überblick. Du erfährst von einem hängenden Vorgang erst, wenn ein Kunde anruft. Oder ein Auditor. - ### Wissen, das mit Leuten geht Implizites Wissen lässt sich nicht skalieren, dokumentierte, automatisierte Abläufe schon. Krankheitstage legen sonst ganze Prozesse lahm. Unser Ansatz ## Wir verkaufen keine Lizenzen. Wir lösen Probleme. Egal ob Camunda, n8n, Power Automate oder eine eigene Lösung: Wir wählen die Technologie, die zu deiner Organisation passt, nicht die, an der wir am meisten verdienen. - ### Erst verstehen, dann automatisieren Process Mining auf realen Daten, Interviews mit denen, die den Prozess täglich leben, Priorisierung nach Impact statt nach Aufwand. - ### Verbinden statt ersetzen APIs, Events und Workflows orchestrieren deine bestehende IT-Landschaft. Offene Standards, kein Vendor Lock-in. So arbeiten wir ## In 4 Schritten zur laufenden Automatisierung Kein monatelanges Konzeptpapier. Wir starten schnell, liefern früh sichtbare Ergebnisse und skalieren, was funktioniert. 1 ### Verstehen Wir analysieren deine Prozesse, sprechen mit den Beteiligten und finden heraus, wo Automatisierung den größten Hebel hat. 2 ### Entwerfen Gemeinsam modellieren wir den Ziel-Prozess und wählen die passende Technologie, abgestimmt auf deine IT-Landschaft. 3 ### Umsetzen Schnelle Ergebnisse durch Proof of Concepts, dann schrittweiser Rollout. Du siehst Fortschritt, nicht nur Folien. 4 ### Befähigen Dein Team übernimmt. Durch Trainings und Wissenstransfer könnt ihr Prozesse eigenständig weiterentwickeln, ohne dauerhafte Abhängigkeit. Technologien ## Das richtige Werkzeug für jede Aufgabe Wir sind zertifizierte Partner führender Plattformen, viele davon Open Source. Wir empfehlen die Technologie, die zu dir passt, nicht die, die uns am besten passt. ### Workflow Engines Camunda 7 & 8, Flowable, Temporal: für orchestrierte Geschäftsprozesse mit BPMN, die skalieren und auditierbar sind. ### Integration & Automatisierung n8n, Apache Kafka, REST/GraphQL APIs: für nahtlose Systemintegration und event-basierte Architekturen. ### Process Mining & Analytics Celonis, Signavio, eigene Analysetools. Damit identifizieren wir datenbasiert die richtigen Prozesse zur Automatisierung. ## Prozess oder kein Prozess? Was wie eine philosophische Frage klingt, entscheidet über das richtige Werkzeug. Nicht jede Abfolge von Schritten ist ein Prozess, der eine Process Engine erfordert. Falsch eingesetzt wirft eine Process Engine oder gar Agentic Orchestration dein Projekt zurück, anstatt es voranzubringen. Unser Onepager beantwortet die Fragen rund um BPMN, DMN, Process Engines und Agentic Orchestration kompakt. - Welche Fragen muss ich mir stellen, um das richtige Werkzeug zu wählen? - Wo liegen die Vorteile von BPMN, DMN und Process Engines? - Und wann spielt Agentic Orchestration ihre Vorteile aus? E-Mail \* Ich stimme der Verarbeitung meiner Daten zu, um das Dokument zu erhalten. [Datenschutz](/datenschutz/) \* Onepager anfordern ## Was unsere Kunden sagen Langfristige Partnerschaften, keine einmaligen Projekte. **Miragon liefert mehr als exzellente Softwareentwicklung.** Die Architekten und Entwickler hören genau hin, stellen die richtigen Fragen und zerlegen komplexe Anforderungen in präzise, handhabbare Bausteine. Besonders begeistert hat mich das offene, konstruktive Miteinander. **Maximilian Mack** CTO, pyck **Miragon bringt nicht nur technisches Know-how mit, sondern auch ein tiefes Verständnis für unsere Herausforderungen.** Gemeinsam haben wir eine Plattform aufgebaut, die unsere Systeme sinnvoll miteinander verknüpft. Besonders schätze ich den offenen Austausch und das vertrauensvolle Miteinander. **René Zarwel** Landeshauptstadt München **Großes Vertrauen, offene Kommunikation und Austausch auf Augenhöhe.** Das umfassende Fachwissen und hohe Engagement von Miragon sind entscheidende Faktoren bei der erfolgreichen Entwicklung unseres Lagerverwaltungssystems. **Stefan Futterer** dmTech Weiterlesen ## Automatisierung in der Praxis [ 02\. Jan. 2024 ### Prozessautomatisierung in der Intralogistik bei DM Wie Miragon die Intralogistik-IT von DM modernisiert – mit BPMN, Domain-Driven Design und agiler Softwareentwicklung. Weiterlesen ](/blog/prozessautomatisierung-intralogistik-dm/) [ 07\. Dez. 2020 ### Prozessautomatisierung in der Baubranche Gemeinsam mit Studierenden der Hochschule Augsburg und der SSB Fidan digitalisieren wir Prozesse in der Baubranche - von Leistungsnachweisen bis zur Abrechnung. Weiterlesen ](/blog/prozessautomatisierung-baubranche/) [ 30\. Juni 2020 ### Logistikprozesse mit Camunda automatisieren Wie wir im Rahmen eines Hochschulprojekts einen Logistik-Microservice für die Open Source-Plattform RemedyMatch mit Camunda und Spring Boot umgesetzt haben. Weiterlesen ](/blog/logistikprozesse-camunda-automatisieren/) ## Weiter zur passenden Leistung [ ### Alle Leistungen im Überblick Von der Analyse über die Architektur bis zum eigenständigen Betrieb deiner Prozesse. ](/leistungen/) [ ### KI-Integration KI mit deinen ERP-, CRM- und Fachsystemen verbinden, statt nur Prompts zu beantworten. ](/portfolio/ki-integration/) [ ### Quickcheck Prozessautomatisierung In zwei Tagen von der Analyse-Schleife in die priorisierte Umsetzung. ](/trainings/process-automation-quickcheck/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Camunda 7 Support endet. Dein Migrationspfad noch nicht klar?](https://www.miragon.io/portfolio/camunda-7-migration/) Wir haben dutzende C7-Installationen analysiert und migriert. Wir beraten dich ehrlich, ob Camunda 8, CIB Seven oder Abwarten der richtige Weg ist. [Erstgespräch vereinbaren](/kontakt/) Typische Fragen ## Kennst du das? ### Wann muss ich migrieren? Camunda stellt den Community-Support ein, aber niemand sagt dir klar, bis wann du handeln musst. ### Wie aufwändig wird das? Hunderte Prozessdefinitionen, Custom Worker, gewachsene Integrationen, und keiner hat eine vollständige Übersicht. ### Camunda 8 oder CIB Seven? Zwei grundverschiedene Architekturen, unterschiedliche Lizenzmodelle. Und beide Seiten versprechen dir, die bessere Wahl zu sein. ### Weiterlaufen oder umstellen? Solange es läuft, fühlt sich Abwarten sicher an. Bis ein Security-Patch fehlt oder dein bester Entwickler geht, weil er moderne Tools will. ### Wer kann uns helfen? Die meisten Berater kennen nur eine Seite. Du brauchst jemanden, der C7, C8 und CIB Seven im Detail versteht. Unsere Lösung ## Migration mit Plan, nicht mit Hoffnung Wir nutzen Camunda 7 seit Tag 1, haben Erweiterungen dafür mitentwickelt und arbeiten seit Jahren mit C8 und CIB Seven. Das heißt: Wir kennen die Fallstricke, bevor du drüber stolperst. - ### Tiefe C7-Expertise Engine-Interna, APIs, typische Patterns: Wir debuggen C7-Probleme, die andere Berater noch nie gesehen haben. - ### Camunda 8 Know-how Zeebe, Operate, Tasklist: Wir wissen, welcher C7-Code 1:1 übertragbar ist und wo du neu denken musst. - ### CIB Seven Partner Wenn CIB Seven besser zu deiner Architektur passt, sagen wir dir das. Auch wenn Camunda 8 der populärere Weg wäre. - ### Migrationstoolbox Bewährte Migrationsscripts, Testframeworks und Vorgehensmodelle. Kein Neuerfinden bei jedem Projekt. ## Dein Migrationspfad ### Assessment Wir analysieren deine bestehende C7-Landschaft: Prozesse, Worker, Integrationen, Custom Code. Das Ergebnis ist eine ehrliche Aufwandschätzung, keine Wunschzahlen, keine Überraschungen. ### Strategieentscheidung Camunda 8 oder CIB Seven? Big Bang oder schrittweise? Wir beraten dich ehrlich, auch wenn die Antwort ist: "Bleib erstmal auf C7." ### Pilotmigration Wir migrieren einen abgegrenzten Bereich als Pilot. Du siehst echte Ergebnisse, dein Team lernt mit, und du hast eine Entscheidungsgrundlage für das Management. ### Rollout Wir übertragen die bewährten Patterns auf weitere Prozesse. Mit erprobten Templates wird jede Migration schneller als die vorherige. ## Warum Miragon für deine C7-Migration? ### Offizieller Camunda Partner Direkter Zugang zu Camunda Engineering und Support. ### C7 seit Tag 1 Wir arbeiten mit Camunda 7, seit es Camunda 7 heißt, und mit C8 seit der ersten Beta. ### Herstellerunabhängig Wir empfehlen den Weg, der zu dir passt, nicht den, der uns die höchste Marge bringt. ### Ehrlich, auch wenn es wehtut Manchmal ist die beste Empfehlung: Bleib erstmal auf C7 und investier woanders. Weiterlesen ## Mehr zur Camunda-Migration [ 01\. Juni 2026 ### Beyond the Happy Path: Was eine Camunda-8-Migration wirklich schwer macht Warum der Wechsel auf Camunda 8 kein technisches Upgrade ist, sondern eine Plattform-Transformation: Erkenntnisse aus unserem CamundaCon-2026-Vortrag in Amsterdam. Weiterlesen ](/blog/camundacon-2026-schwierige-camunda-8-migrationen/) [ 01\. Dez. 2025 ### Leveling up! Wie du die Herausforderung verteilter Transaktionen in Zeebe lösen kannst Ein umfassender Guide zu verteilten Transaktionen in Zeebe: Von Phantom-Instanzen über das Outbox Pattern bis hin zu Idempotenz und SAGA. Weiterlesen ](/blog/leveling-up-verteilte-transaktionen-zeebe/) [ 11\. März 2025 ### Camunda 7 vs. 8 – Eine Betrachtung durch die Brille von Team Topologies Die Migration von Camunda 7 zu 8 erfordert neue Teamstrukturen. Eine Analyse durch die Brille von Team Topologies. Weiterlesen ](/blog/camunda-7-vs-8-team-topologies/) ## Weiterführende Wege [ ### Alle Leistungen im Überblick Von der Analyse über die Architektur bis zum eigenständigen Betrieb deiner Prozesse. ](/leistungen/) [ ### Prozessautomatisierung Nach der Migration weitere Prozesse end-to-end automatisieren. ](/portfolio/automate/) [ ### Camunda 8 Developer Training Vier Tage Hands-on für Java-Entwickler und Architekten. ](/trainings/camunda-8-developer-training/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [KI, die eure Systeme versteht, nicht nur Prompts beantwortet](https://www.miragon.io/portfolio/ki-integration/) Wir verbinden KI mit euren ERP-, CRM- und Fachsystemen. Per MCP-Server, autonome Agents und Workplace-Automatisierung, damit KI dort arbeitet, wo euer Team sie braucht. [Use-Case-Check anfragen](/kontakt/) Das Problem ## KI-Projekte starten vielversprechend, versanden aber im Alltag Euer Team experimentiert mit ChatGPT, testet Copilot, baut interne Demos. Aber nichts davon ist an eure echten Systeme angedockt. Die KI weiß nichts über eure Kunden, eure Prozesse, eure Daten. ### KI ohne Kontext Generische Modelle beantworten generische Fragen. Sobald es um euer ERP, euer Ticketsystem oder eure Kundendaten geht, ist Schluss. Jede Antwort braucht manuelles Copy-Paste. ### Insel-Lösungen statt System Abteilung A nutzt Tool X, Abteilung B Tool Y. Kein einheitlicher Zugang zu Unternehmensdaten, keine Governance, kein wiederverwendbares Pattern. ### Wettbewerbsvorteil, der verfällt Während ihr noch evaluiert, haben andere bereits KI in ihre Kernprozesse integriert. Jeder Monat ohne strukturierte Integration ist ein Monat, den eure Konkurrenz nutzt. Was wir bauen ## Vier Hebel, um KI in euren Alltag zu bringen Keine generische 'KI-Strategie', kein Foliensatz. Wir bauen konkrete Integrationen, die ab Tag eins arbeiten und die euer Team danach allein weiterentwickelt. ### MCP-Server & Skills Maßgeschneiderte MCP-Server, die eure Systeme für KI-Modelle zugänglich machen. Kontrolliert, auditierbar, mit klaren Berechtigungen. Das offene Protokoll verhindert Vendor Lock-in. ### KI-Agents Autonome Agents, die mehrstufige Aufgaben eigenständig ausführen: Daten prüfen, Workflows anstoßen, Entscheidungen vorbereiten. Nicht als Black Box, sondern mit transparentem Audit-Trail. ### Workplace-Automatisierung KI direkt in Slack, Microsoft 365, Jira und eure internen Apps. Kein Tab-Wechsel, kein Copy-Paste. KI als natürlicher Teil der täglichen Werkzeuge. ### KI-gestützte Analyse Automatisierte Auswertung von Geschäftsdaten, Prozess-Logs und Dokumenten. Muster erkennen, Anomalien aufdecken, Entscheidungsgrundlagen liefern, ohne manuelles Reporting. Vorher vs. Nachher ## Was sich konkret ändert Keine abstrakten Versprechen. Drei echte Szenarien, wie KI-Integration den Arbeitsalltag verändert. ### Kundenanfrage bearbeiten Vorher Mitarbeiter öffnet CRM, sucht Kundennummer, wechselt ins ERP, kopiert Auftragsstatus, formuliert Antwort manuell. 12 Minuten. Nachher Agent prüft CRM und ERP automatisch, formuliert Antwortvorschlag mit allen relevanten Daten. Mitarbeiter prüft und sendet. 2 Minuten. ### Monatliches Reporting Vorher Daten aus 4 Systemen exportieren, in Excel zusammenführen, Diagramme bauen, Abweichungen manuell kommentieren. 2 Arbeitstage. Nachher KI aggregiert Daten automatisch, erkennt Abweichungen, liefert kommentierten Report-Entwurf. Review und Freigabe: 2 Stunden. ### Neuen Mitarbeiter onboarden Vorher Zugänge manuell anlegen, Wikis durchforsten, Kollegen fragen, wochenlang Kontext aufbauen. Nachher MCP-Server gibt KI Zugriff auf Wikis, Prozessdoku und Tooling. Neuer Mitarbeiter fragt die KI und bekommt kontextbezogene Antworten ab Tag 1. So arbeiten wir ## Vom Use Case zum produktiven System Kein Monats-Projekt im Blindflug. Wir arbeiten in schnellen Iterationen mit sichtbaren Zwischenergebnissen, mit ehrlichem Feedback, wenn etwas nicht funktioniert. 1 ### Use-Case-Check 30 Minuten, kostenfrei. Wir prüfen gemeinsam, ob und wo KI-Integration in eurem Setup den größten Hebel hat. 2 ### PoC & iterativer Ausbau Funktionierender Prototyp in 1–2 Wochen an euren echten Systemen. Danach schrittweiser Ausbau: Jede Iteration liefert einen produktiven Baustein, nicht nur eine Demo. 3 ### Wissenstransfer & Übergabe Euer Team übernimmt. Dokumentation, Pair Programming, Code Reviews: Ihr seid nach der Zusammenarbeit eigenständig arbeitsfähig. ## Von der Idee zur produktiven KI-Integration Bei [Dimacon](https://dimacon.io/) haben wir genau diese Methodik umgesetzt: MCP-Server an ERP- und CRM-Systeme angedockt, Agent Skills für Auftragsbearbeitung und Kundenkommunikation gebaut, Workplace-Automatisierung in den täglichen Workflow integriert. Die Lösung läuft heute produktiv, und Dimacons Team entwickelt sie eigenständig weiter. [dimacon.io ansehen](https://dimacon.io/) ## Was unsere Kunden sagen Langfristige Partnerschaften, keine einmaligen Projekte. **Miragon liefert mehr als exzellente Softwareentwicklung.** Die Architekten und Entwickler hören genau hin, stellen die richtigen Fragen und zerlegen komplexe Anforderungen in präzise, handhabbare Bausteine. Besonders begeistert hat mich das offene, konstruktive Miteinander. **Maximilian Mack** CTO, pyck **Miragon bringt nicht nur technisches Know-how mit, sondern auch ein tiefes Verständnis für unsere Herausforderungen.** Gemeinsam haben wir eine Plattform aufgebaut, die unsere Systeme sinnvoll miteinander verknüpft. Besonders schätze ich den offenen Austausch und das vertrauensvolle Miteinander. **René Zarwel** Landeshauptstadt München **Großes Vertrauen, offene Kommunikation und Austausch auf Augenhöhe.** Das umfassende Fachwissen und hohe Engagement von Miragon sind entscheidende Faktoren bei der erfolgreichen Entwicklung unseres Lagerverwaltungssystems. **Stefan Futterer** dmTech FAQ ## Häufige Fragen zur KI-Integration Was Entscheider typischerweise wissen wollen, bevor sie ein KI-Integrationsprojekt starten. Was ist ein MCP-Server? MCP (Model Context Protocol) ist ein offener Standard, der KI-Modellen kontrollierten Zugriff auf eure Systeme gibt, ähnlich wie eine API, aber speziell für KI-Interaktionen optimiert. Statt Daten manuell zu kopieren, kann die KI direkt auf CRM, ERP oder Datenbanken zugreifen, mit klaren Berechtigungen und vollständigem Audit-Trail. Wie lange dauert eine typische KI-Integration? Der erste Proof of Concept steht in 1–2 Wochen. Er zeigt an echten Daten und Systemen, ob und wie KI-Integration bei euch funktioniert. Der iterative Ausbau danach hängt vom Scope ab, typischerweise 2–4 weitere Iterationen à 2 Wochen. Was passiert mit unseren Daten? Eure Daten bleiben in eurer Infrastruktur. MCP-Server laufen in eurer Umgebung und geben der KI nur die Informationen weiter, die ihr freigebt. Wir setzen auf Zero-Trust-Prinzipien: jeder Zugriff ist explizit autorisiert und wird protokolliert. Können wir das danach selbst weiterentwickeln? Ja, das ist das Ziel. Wir übergeben nicht nur Code, sondern befähigen euer Team durch Pair Programming, Code Reviews und Dokumentation. Nach der Zusammenarbeit könnt ihr neue MCP-Server und Agent Skills eigenständig bauen und anpassen. Was unterscheidet euch von einer KI-Beratung? Wir liefern keine Slide-Decks und Strategiepapiere. Wir bauen funktionierende Systeme: MCP-Server, die an euren Daten hängen, Agents, die echte Aufgaben erledigen, Integrationen, die im Alltag genutzt werden. Am Ende steht produktiver Code, kein Konzept. Was kostet eine KI-Integration? Das hängt vom Scope ab. Der Use-Case-Check ist kostenfrei und gibt euch eine realistische Einschätzung. Danach scopen wir gemeinsam: ein einzelner MCP-Server mit Agent Skill ist ein überschaubares Projekt, eine unternehmensweite Integration ein größeres. Wir arbeiten transparent und iterativ, keine versteckten Kosten. Weiterlesen ## Mehr zu KI in der Automatisierung [ 04\. Mai 2026 ### Miragon AI: Vom Cockpit zur Konversation Wie wir bei Miragon Prozessautomatisierung neu denken: weg vom isolierten Cockpit, hin zur Konversation als Interface. Warum das MCP und MCP Apps das Fundament dafür bilden. Weiterlesen ](/blog/miragon-ai-vom-cockpit-zur-konversation/) ## Das passt zu deiner KI-Integration [ ### Alle Leistungen im Überblick Von der Prozessanalyse über die Architektur bis zum eigenständigen Betrieb. ](/leistungen/) [ ### Prozessautomatisierung Systeme verbinden und manuelle Schritte automatisieren, technologieneutral. ](/portfolio/automate/) [ ### AI in der Prozessautomatisierung Dein Team lernt, KI-Agenten gezielt und mit klaren Guardrails einzusetzen. ](/trainings/ai-tooling-workshop/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [Quelloffene Werkzeuge, die deine Prozessarbeit beschleunigen](https://www.miragon.io/tools/) Miragon Tools Sofort einsatzbereite Open-Source-Tools für Modellierung, Software-Entwicklung und KI, die du direkt einsetzen kannst. Gebaut von unserem Beratungsteam und im Einsatz in Kundenprojekten. Modellierung ## Prozesse & Strukturen sichtbar machen Schaff dir eine saubere Basis für deine Automatisierung: Strategie, Abläufe und Teamstrukturen als Modelle. ### BPMN Modeler Modelliere BPMN 2.0 und DMN dort, wo du ohnehin arbeitest – als VS-Code-Extension, IntelliJ-Plugin oder Standalone-App. Vom sauberen Modell bis zum Rollout bleibt alles in einem Werkzeug, ohne Tool-Wechsel. [Demo](https://miragon-bpmn-modeler-demo.netlify.app)[Mehr erfahren](https://miragon.github.io/bpmn-modeler/) Ansprechpartner Marco Schäck Process Development Lead [](mailto:marco.schaeck@miragon.io "E-Mail an Marco Schäck")[](https://www.linkedin.com/in/schaeckm/ "Marco Schäck auf LinkedIn") ### Wardley Maps Modeler Modelliere Wardley Maps für strategische Architektur- und Geschäftsentscheidungen. Als Web-App und VS-Code-Extension. [Demo](https://wardley-maps.netlify.app)[Mehr erfahren](https://github.com/Miragon/wardley-maps-modeler) Ansprechpartner Dominik Horn Co-Founder & Geschäftsführer [](mailto:dominik.horn@miragon.io "E-Mail an Dominik Horn")[](https://www.linkedin.com/in/dominik-horn/ "Dominik Horn auf LinkedIn")[](https://calendly.com/dominik-horn-miragon/30min "Termin mit Dominik Horn buchen") ### Team-Topologies Modeler Modelliere Team-Typen und Interaktionsmodi nach Skelton und Pais. Unabhängige, nicht-affiliierte Umsetzung als Web-App und VS-Code-Extension. [Demo](https://team-topologies.netlify.app/)[Mehr erfahren](https://github.com/Miragon/team-topologies-modeler) Ansprechpartner Dominik Horn Co-Founder & Geschäftsführer [](mailto:dominik.horn@miragon.io "E-Mail an Dominik Horn")[](https://www.linkedin.com/in/dominik-horn/ "Dominik Horn auf LinkedIn")[](https://calendly.com/dominik-horn-miragon/30min "Termin mit Dominik Horn buchen") ### Context Maps Modeler Modelliere Context Maps aus dem strategischen Domain-Driven Design: Bounded Contexts nach Subdomain-Typ und ihre Beziehungen. Als Web-App und VS-Code-Extension. [Demo](https://context-maps-modeler.netlify.app)[Mehr erfahren](https://github.com/Miragon/context-maps-modeler) Ansprechpartner Andreas Riepl Consultant [](mailto:andreas.riepl@miragon.io "E-Mail an Andreas Riepl")[](https://www.linkedin.com/in/andreas-riepl "Andreas Riepl auf LinkedIn") Miragon AI ## KI-Unterstützung für deine Prozessautomatisierung Setze KI in deiner Prozessarbeit gezielt dort ein, wo sie echten Mehrwert bringt und nicht bloß für zusätzliche Komplexität sorgt. ### Miragon AI Sprich mit deinen Prozessen: Status, Kennzahlen und Incident-Lösungen zu Camunda & CIB seven – direkt in deinem Agent wie Claude Code statt im Cockpit. [Mehr erfahren](https://miragon.ai) Ansprechpartner Dominik Horn Co-Founder & Geschäftsführer [](mailto:dominik.horn@miragon.io "E-Mail an Dominik Horn")[](https://www.linkedin.com/in/dominik-horn/ "Dominik Horn auf LinkedIn")[](https://calendly.com/dominik-horn-miragon/30min "Termin mit Dominik Horn buchen") Software-Entwicklung ## Software, die Bestand hat Werkzeuge für saubere, stabile Software, die wartbar bleibt und sich flexibel erweitern lässt. ### bpmn-to-code Hält dein BPMN-Modell und deinen Code zuverlässig im Einklang: Fehler fallen sofort auf, nicht erst im Betrieb. [Demo](https://bpmn-to-code.miragon.io/)[Mehr erfahren](https://miragon.github.io/bpmn-to-code/) Ansprechpartner Marco Schäck Process Development Lead [](mailto:marco.schaeck@miragon.io "E-Mail an Marco Schäck")[](https://www.linkedin.com/in/schaeckm/ "Marco Schäck auf LinkedIn") ### Sofort einsatzbereit Open Source und startklar: nutzen, ausprobieren, loslegen. Ganz ohne uns. ### Support Du bekommst Support direkt vom Team, das die Tools baut: beim Rollout, bei der Fehleranalyse und bei Versions-Updates. ### Anpassung Wir entwickeln die Tools nach deinen Bedürfnissen weiter, damit ein Tool mit deinem Unternehmen mitwächst. Beratung ## Du möchtest ein Tool bei dir im Unternehmen skalieren? Wir zeigen dir, wie es geht: mit Support direkt vom Team, das die Tools baut, und Anpassungen, die zu deiner Systemlandschaft passen. [Erstgespräch vereinbaren](/kontakt/?thema=tools) ## [Lerne Prozess­automatisierung von denen, die sie täglich in echten Projekten umsetzen.](https://www.miragon.io/trainings/) Workshops & Trainings Sechs Formate von BPMN-Grundlagen bis zur Prozess-Engine im Betrieb. Hands-on, in kleinen Gruppen, inhouse oder als offenes Training. Über 50 % Hands-onInhouse & offene TermineTrainer aus echten Projekten ## Unser Kursprogramm Von der ersten Strategie bis zum produktiven Betrieb. Jedes Format hands-on und auf euren Projektalltag zugeschnitten. [ Camunda ### Camunda 8 Developer Training (Java) Vom ersten Modell bis zum stabilen Camunda-8-Betrieb. 4 TageFortgeschrittenJava-Entwickler & Architekten ](/trainings/camunda-8-developer-training/) [ CIB seven ### CIB seven Developer Training Vom BPMN-Modell zum getesteten, automatisierten Prozess. 3 TageFortgeschrittenJava-Entwickler & Architekten ](/trainings/cib-seven-developer-training/) [ BPMN & DMN ### BPMN 2.0 & DMN Training BPMN sicher modellieren, DMN sauber integrieren. 3 + 1 TageEinstiegFachbereich & IT ](/trainings/bpmn-training/) [ KI ### AI in der Prozessautomatisierung AI-Agenten gezielt entlang des BPM-Lifecycles einsetzen. 1 TagFortgeschrittenTech-Leads & Entwickler ](/trainings/ai-tooling-workshop/) [ Strategie ### Quickcheck Prozessautomatisierung In 2 Tagen wisst ihr, wo ihr ansetzt. 2 TageStrategischEntscheider & Architekten ](/trainings/process-automation-quickcheck/) [ Soziotechnische Systeme ### Workshop Soziotechnische Systeme Automatisierung als soziotechnisches System denken. 1 TagStrategischIT-Leitung, Architektur & Projektleitung ](/trainings/soziotechnische-systeme-workshop/) ## Deine Trainer Keine reinen Folien-Trainer. Bei uns stehen Leute vorne, die Prozessautomatisierung in echten Projekten bauen. ### Thomas Heinrichs Solution Architecture Lead ### Dominik Horn Co-Founder & Geschäftsführer ### Marco Schäck Process Development Lead ## Nächste offene Termine Offene Termine für einzelne Teilnehmende. Inhouse-Trainings vereinbaren wir individuell zu eurem Wunschtermin. 13.–15. Oktober 2026 [CIB seven Developer Training](/trainings/cib-seven-developer-training/) Präsenz · Augsburg · Plätze frei [Platz anfragen](/kontakt/?kurs=CIB+seven+Developer+Training&termin=13.%E2%80%9315.+Oktober+2026) 14\. Oktober 2026 [AI in der Prozessautomatisierung](/trainings/ai-tooling-workshop/) Online · Plätze frei [Platz anfragen](/kontakt/?kurs=AI+in+der+Prozessautomatisierung&termin=14.+Oktober+2026) 16.–18. November 2026 [CIB seven Developer Training](/trainings/cib-seven-developer-training/) Online · Plätze frei [Platz anfragen](/kontakt/?kurs=CIB+seven+Developer+Training&termin=16.%E2%80%9318.+November+2026) Kein passender Termin dabei? [Sprich uns gerne an](/kontakt/) ## Konzerne, Banken, Verwaltungen: Sie vertrauen Miragon die Prozesse an, an denen ihr Geschäft hängt. Von dm bis zur ING: Wir bringen Automatisierung dorthin, wo es wirklich darauf ankommt. ## Was unsere Kunden sagen Langfristige Partnerschaften, keine einmaligen Projekte. **Miragon liefert mehr als exzellente Softwareentwicklung.** Die Architekten und Entwickler hören genau hin, stellen die richtigen Fragen und zerlegen komplexe Anforderungen in präzise, handhabbare Bausteine. Besonders begeistert hat mich das offene, konstruktive Miteinander. **Maximilian Mack** CTO, pyck **Miragon bringt nicht nur technisches Know-how mit, sondern auch ein tiefes Verständnis für unsere Herausforderungen.** Gemeinsam haben wir eine Plattform aufgebaut, die unsere Systeme sinnvoll miteinander verknüpft. Besonders schätze ich den offenen Austausch und das vertrauensvolle Miteinander. **René Zarwel** Landeshauptstadt München **Großes Vertrauen, offene Kommunikation und Austausch auf Augenhöhe.** Das umfassende Fachwissen und hohe Engagement von Miragon sind entscheidende Faktoren bei der erfolgreichen Entwicklung unseres Lagerverwaltungssystems. **Stefan Futterer** dmTech ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit. ## [AI als Entwicklungspartner im echten Projektalltag.](https://www.miragon.io/trainings/ai-tooling-workshop/) AI in der Prozessautomatisierung Ein Tag, in dem euer Team lernt, AI-Agenten gezielt entlang des BPM-Lifecycles einzusetzen: von der Modellierung über die Implementierung bis zu Tests. Thema KI Dauer 1 Tag Level Fortgeschritten Zielgruppe Tech-Leads & Entwickler Nächster Termin 14\. Oktober 2026 [Training anfragen](#format) Das Problem ## Raus aus dem Digitalisierungsstau, ohne Qualitätsverlust BPMN, XML und Engine-APIs bringen AI-Agenten ins Straucheln. Wir zeigen euch, wie ihr Prozesse trotzdem schneller umsetzt, ohne dass die Qualität dabei leidet. ### Halluzinationen bei BPMN & Engine-APIs Generischen Code generiert AI zuverlässig. Sobald es um BPMN-Syntax, Engine-spezifische APIs oder eure Architekturkonventionen geht, halluziniert sie häufiger. ### Generieren ohne Struktur und Reviews Ohne Setup, Skills und Guardrails entstehen unkontrollierte Generierungs-Schleifen. Was ein Produktivitäts-Booster sein sollte, wird zum Review-Bottleneck. ### BPMN-Modellierung bleibt Teamsport BPMN lebt vom Dialog zwischen Fach und IT. Wenn AI Modelle im Alleingang erzeugt, geht dieser Abstimmungsschritt verloren. Wir zeigen, wo AI in der Modellierung unterstützt und wo der Mensch unverzichtbar bleibt. Agenda ## Ein Tag, der AI in eurem BPM-Alltag verankert Vier Blöcke entlang des BPM-Lifecycles, mit Live-Demos, Hands-on-Übungen und einem klaren Bild, wo AI heute trägt und wo nicht. 1Block 1Grundlagen: AI im BPM-Lifecycle & Setup - AI im BPM-Lifecycle: wo AI die Spielregeln verändert - Von CHOP zu Agenten, Abgrenzung zu Vibe-Coding - Tool-Landschaft: Copilot, Cursor, Claude Code, Junie - Setup eines Agenten am Beispiel - Live-Demo: vom leeren IDE zum ersten laufenden Prozess 2Block 2Skills & Kontext für die eigene Domäne - Wo AI an Grenzen stößt: spezialisierte Domänen, BPMN-XML - Agent Files und MCP als Kontext-Erweiterung - Skills als Schlüssel zur Domänenanpassung - Hands-on: Skill in ein Beispielprojekt integrieren 3Block 3Modellierung, Code & Tests mit AI - BPMN und AI: kollaboratives Modellieren bleibt Menschenaufgabe - Code- und Test-Generierung für Prozessapplikationen - Eigene Skills für projektspezifische Patterns 4Block 4Team-Workflow & Governance - Team-Workflow: Shared Skills, Onboarding, Reviews - Guardrails: ADRs, Testabdeckung, Verantwortung - Datenschutz, Compliance und Subscription-Realität ### Für wen ist dieses Training? ### Java-Entwickler Ihr arbeitet mit BPM-Engines und wollt AI-Agenten ernsthaft in euren Workflow integrieren, ohne Hype und mit klaren Erwartungen. ### Software-Architekten Ihr verantwortet Architektur und Standards eurer Prozessapplikationen und wollt AI als verlässliches Werkzeug etablieren, mit Guardrails. ### Tech-Leads Ihr führt Entwickler-Teams und wollt AI als Team-Werkzeug verankern: Shared Skills, gemeinsame Konventionen und sichere Reviews. Unsere Methode ## Dem BPM-Lifecycle entlang, mit klaren Leitplanken Wir folgen dem BPM-Lifecycle als rotem Faden: Design, Modellierung, Implementierung, Tests. An jedem Punkt zeigen wir, wo AI Mehrwert liefert und wo menschliches Urteilsvermögen unverzichtbar bleibt. ### Skills statt immer neue Prompts Statt der AI jede Aufgabe neu zu erklären, haltet ihr euer Projektwissen einmal als Skill fest, damit der Agent Codebasis und Standards von Anfang an kennt. Diese Skills bauen wir im Training gemeinsam mit euch. ### Der Mensch behält die Verantwortung Architektur, Testabdeckung und das letzte Qualitätsurteil bleiben bei eurem Team. Gemeinsam legen wir fest, was der Agent übernehmen darf und wo ein Review unverzichtbar bleibt. ### Aktuelle Modelle, jede Engine Wir arbeiten mit den stärksten AI-Modellen und vermitteln die Methodik dahinter, nicht die Bedienung eines einzelnen Tools. Ob Camunda, CIB seven oder eine andere Engine: Die Muster funktionieren überall. 1Tag kompakt 12max. Teilnehmer 80%Hands-on 4BPM-Lifecycle-Phasen ### Dein Trainer Meist übernimmt eine dieser Personen euer Training. Je nach Termin kann es auch jemand anderes aus unserem Team sein. Sprecht sie direkt an, den Rest klären wir gemeinsam. ### Marco Schäck Process Development Lead [](mailto:marco.schaeck@miragon.io "E-Mail an Marco Schäck")[](https://www.linkedin.com/in/schaeckm/ "Marco Schäck auf LinkedIn") Format ## Privates Training oder Open Classroom Zwei Formate, eine Entscheidung: ein ganzes Team auf einmal befähigen oder einzelne Teilnehmende aus eurer Organisation entsenden. ### Privates Training Maßgeschneidert Exklusiv für euer Team und individuell anpassbar. Wir greifen eure Engine, eure Codebase und eure AI-Tool-Landschaft auf, statt mit generischen Beispielen zu arbeiten. Vor Ort bei euch, bei uns in Augsburg oder remote. ### Open Classroom Offene Termine Öffentliches Training mit festem Termin und standardisierter Agenda für Teilnehmende aus unterschiedlichen Unternehmen. Bei uns in Augsburg, ideal um einzelne Personen aus eurem Team gezielt zu entsenden. ## Pakete und Preise Transparenter Preis für unser privates AI-Training. Open-Classroom-Termine bitte direkt anfragen. ### Privates Training 1 Tag exklusiv für euer Team 3.000 € 1 Tag · bis zu 12 Teilnehmende Maßgeschneidertes 1-Tages-AI-Training exklusiv für euer Team, vor Ort bei euch, bei uns in Augsburg oder remote. - Bis zu 12 Teilnehmende ohne Aufpreis - Inhalte auf eure Codebase und AI-Tool-Landschaft zugeschnitten - Gemeinsam gebauter Skill als Blueprint - Guardrail-Checkliste und Lifecycle-Landkarte zum Mitnehmen [Privates Training anfragen](/kontakt/?kurs=AI%20in%20der%20Prozessautomatisierung) ## Termine für diesen Kurs Offene Termine für einzelne Teilnehmende. Als Inhouse-Training kommen wir zu eurem Wunschtermin. 14\. Oktober 2026 Online · Plätze frei [Platz anfragen](/kontakt/?kurs=AI+in+der+Prozessautomatisierung&termin=14.+Oktober+2026) ## Ihr wollt eure Prozessautomatisierung mit AI beschleunigen? Lasst uns in einem kurzen Gespräch klären, ob das Training zu eurem Vorhaben passt und welche Schwerpunkte für euch zählen. [Training anfragen](/kontakt/?kurs=AI%20in%20der%20Prozessautomatisierung) Unverbindlich, kostenfrei und ohne Pitch-Deck. ## [BPMN sicher modellieren. DMN sauber integrieren.](https://www.miragon.io/trainings/bpmn-training/) BPMN 2.0 & DMN Training Drei Tage BPMN 2.0 für Fachbereiche und IT, plus ein optionaler DMN-Deep-Dive-Tag für Teams, die Geschäftsregeln strukturiert auslagern wollen. Praxisnah, max. 12 Teilnehmer. Thema BPMN & DMN Dauer 3 + 1 Tage Level Einstieg Zielgruppe Fachbereich & IT [Training anfragen](#format) Das Problem ## Was passiert, wenn Teams BPMN ohne Schulung einsetzen Prozessmodellierung wirkt einfach, bis die Modelle in die Umsetzung gehen. Ohne fundiertes Training entstehen Probleme, die Automatisierung später teuer machen. ### Modelle, die niemand versteht Ohne gemeinsame Standards modelliert jeder anders. Fachbereich und IT reden aneinander vorbei und das Modell wird zum Missverständnis statt zur Brücke. ### Wochen statt Tage Autodidaktisches Lernen kostet Zeit. Was in einer strukturierten Schulung in drei Tagen sitzt, zieht sich sonst über Monate, mit Umwegen und Sackgassen. ### Regeln im Code begraben Wer Geschäftsregeln in If-Else-Bäumen versteckt, verliert die Hoheit darüber. DMN macht Regeln sichtbar, testbar und versionierbar, ohne tiefes Tooling-Setup. Agenda ## 3 Tage BPMN, 1 Tag DMN als Add-On Tag 1 bis 3 vermitteln BPMN 2.0 von Grundlagen bis weiterführenden Praktiken. Der DMN-Tag kann optional dazugebucht werden, ideal als Vertiefung für IT-nahe Teilnehmende. 1Tag 1Grundlagen der Prozessmodellierung - Motivation und Nutzen von BPM und BPMN - BPMN-2.0-Basics: Kernelemente und Ablauflogik - Modellierungskonventionen für Fach und IT - Prozesssteckbriefe: Zweck, Scope, Rollen, KPIs - Erste eigene Modelle und Übungen 2Tag 2Vertiefung des BPMN-Know-Hows - Events: Timer, Messages, Signals, Errors - Boundary-Events und typische Muster - Pools, Lanes, Message-Flows, Verantwortlichkeiten - Daten in Prozessen: Datenobjekte und Variablenlogik - Übungen mit eigenen Prozessbeispielen 3Tag 3Modellierungspraktiken & Standards - Subprozesse, Wiederverwendung, Variantenmanagement - Ausnahmen, Eskalationen, alternative Pfade - Kompensation und robuste Rückabwicklung - Exkurs: DMN und FEEL als Brücke zur Vertiefung - BPMN-Style-Guide, Reviews, Qualitätskriterien +Tag +DMN Deep Dive (Add-On, 1 Tag) - DMN-Grundlagen und Positionierung - Entscheidungstabellen modellieren und validieren - FEEL und JUEL praxisnah anwenden - DMN sauber in Prozesse integrieren - Hands-on-Lab von Regelbeschreibung bis Ausführung - Governance-Leitplanken für große Entscheidungstabellen ### Für wen ist dieses Training? ### Prozessmanager & Business-Analysten Ihr erhebt Geschäftsprozesse strukturiert, modelliert sie verständlich und schafft eine belastbare Grundlage für Optimierung und Automatisierung. ### Requirement-Engineers Ihr wollt fachliche Anforderungen technisch interpretierbar machen und eine gemeinsame Sprache zwischen Business und IT etablieren. ### Entwickler & Architekten Ihr wollt BPMN-Modelle nicht nur lesen, sondern aktiv mitgestalten und mit dem optionalen DMN-Tag Geschäftsregeln sauber implementieren. Unsere Methode ## Hands-on statt Frontalunterricht Theorie allein reicht nicht. Mehr als die Hälfte der Zeit verbringen wir mit echten Übungen: an euren Prozessen, mit echten Werkzeugen, mit echten Problemen. ### Kleine Gruppen, individueller Fokus Maximal 12 Personen. Jede Frage findet Platz, jeder kommt zum Modellieren. ### Von der Praxis zur Theorie Wir spannen den Bogen von eurer Praxis und euren Herausforderungen zur Theorie, statt euch durch ein abstraktes Lehrbuch zu führen. ### Mit Werkzeugen, die ihr wirklich einsetzt Wir modellieren mit gängigen, browserbasierten Tools wie dem Miragon Modeler oder dem Camunda Cloud Modeler, sofort startklar, ohne Setup-Hürden. 3+1Tage inkl. DMN 50%+Hands-on-Zeit 12max. Teilnehmer 100%Weiterempfehlung (anonyme Feedbacks) ### Dein Trainer Meist übernimmt eine dieser Personen euer Training. Je nach Termin kann es auch jemand anderes aus unserem Team sein. Sprecht sie direkt an, den Rest klären wir gemeinsam. ### Thomas Heinrichs Solution Architecture Lead [](mailto:thomas.heinrichs@miragon.io "E-Mail an Thomas Heinrichs")[](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/ "Thomas Heinrichs auf LinkedIn")[](https://calendly.com/thomas-heinrichs/30min "Termin mit Thomas Heinrichs buchen") Stimmen ## Was unsere Kunden sagen Eine fachliche Einordnung von außen und ungefilterte Stimmen direkt aus den Sessions. > Dass ich BPMN schon früher machen hätte sollen. > Ich fühle mich sehr gut vorbereitet, in Zukunft mit BPMN arbeiten zu können. > Wie viel mithilfe von BPMN ausgedrückt werden kann, deutlich mehr als gedacht. > Wie wichtig es ist, nicht nur funktionale, sondern auch verständliche und schöne Prozesse zu modellieren. > Ich hätte es nicht besser gekonnt. (auf die Frage, was man anders machen würde) > Sehr gut verwendbar für meinen Bedarf. > Nichts. (auf die Frage, was man anders machen würde) > Beim Design von Prozessen sollte man explizit die Automatisierung mitberücksichtigen. > Ganz grundsätzlich war spürbar, dass Thomas über enormes Fachwissen und viel Erfahrung verfügt und sich mit großem Einsatz darum bemüht hat, dieses Wissen weiterzugeben. > BPMN ist, wenn man weiß, was man tut, nicht so schwer. > Wir haben sehr gute Tipps bekommen, wie wir unsere Software weiter in die richtige Richtung entwickeln und verbessern können. Nichts. Es war super. > Dass ich BPMN schon früher machen hätte sollen. > Ich fühle mich sehr gut vorbereitet, in Zukunft mit BPMN arbeiten zu können. > Wie viel mithilfe von BPMN ausgedrückt werden kann, deutlich mehr als gedacht. > Wie wichtig es ist, nicht nur funktionale, sondern auch verständliche und schöne Prozesse zu modellieren. > Ich hätte es nicht besser gekonnt. (auf die Frage, was man anders machen würde) > Sehr gut verwendbar für meinen Bedarf. > Nichts. (auf die Frage, was man anders machen würde) > Beim Design von Prozessen sollte man explizit die Automatisierung mitberücksichtigen. > Ganz grundsätzlich war spürbar, dass Thomas über enormes Fachwissen und viel Erfahrung verfügt und sich mit großem Einsatz darum bemüht hat, dieses Wissen weiterzugeben. > BPMN ist, wenn man weiß, was man tut, nicht so schwer. > Wir haben sehr gute Tipps bekommen, wie wir unsere Software weiter in die richtige Richtung entwickeln und verbessern können. Nichts. Es war super. Mit Miragon und insbesondere [Thomas Heinrichs](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/) arbeiten wir schon lange zusammen. Seine Expertise im Bereich der Prozessautomatisierung hilft unseren Studierenden an der Humboldt-Universität zu Berlin als auch unseren Partnern bei [Noreja Intelligence](https://noreja.com/). Es zeichnet Miragon aus, dass sie sowohl die strategischen Potenziale der Digitalisierung als auch das Handwerkszeug der technischen Umsetzung bestens verstehen. So bringen sie ihre Kunden auf den Wachstumspfad. **Prof. Dr. Jan Mendling** Einstein Professor, Humboldt-Universität zu Berlin Format ## Privates Training oder Open Classroom Zwei Formate, ein Ziel: euer Team kann BPMN danach selbst. Ob ihr ein ganzes Team gemeinsam fit macht oder einzelne Leute in einen offenen Termin schickt, entscheidet ihr. ### Privates Training Maßgeschneidert Exklusiv für euer Team und individuell anpassbar. Inhalte, Beispiele und Schwerpunkte werden auf eure Prozesse, Systeme und Modellierungsfragen zugeschnitten. Meist vor Ort bei euch, alternativ in unserem Office in Augsburg. ### Open Classroom Offene Termine Öffentliches Training mit festem Termin und standardisierter Agenda für Teilnehmende aus unterschiedlichen Unternehmen. Bei uns in Augsburg, ideal um einzelne Personen aus eurem Team gezielt zu entsenden. ## Pakete und Preise Transparente Preise für unser privates Training und das Kick-Starter-Paket. Open-Classroom-Termine bitte direkt anfragen. ### Privates Training 3 Tage exklusiv für euer Team 6.000 € 3 Tage à 2.000 € · bis zu 12 Teilnehmende Maßgeschneiderte 3-Tage-Schulung exklusiv für euer Team, vor Ort bei euch oder bei uns in Augsburg. - Bis zu 12 Teilnehmende ohne Aufpreis - Inhalte auf eure Prozesse und Beispiele zugeschnitten - Optionaler DMN-Deep-Dive-Tag (+2.000 €) - Schulungsmaterial digital und gedruckt [Privates Training anfragen](/kontakt/?kurs=BPMN%202.0%20%26%20DMN%20Training) Empfohlen ### Kick-Starter-Paket Quickcheck + CIB seven + BPMN 16.000 € Komplettpaket statt einzelner Buchungen Quickcheck Prozessautomatisierung, CIB seven Developer Training und BPMN-Training für die Fachabteilung als ein durchgehendes Enablement-Programm. - 2-tägiger Quickcheck Prozessautomatisierung - 3-tägiges CIB seven Developer Training - 3-tägiges BPMN-Training für die Fachabteilung - Aufeinander abgestimmte Inhalte und Termine [Kick-Starter-Paket anfragen](/kontakt/?kurs=BPMN%202.0%20%26%20DMN%20Training) ## Termine für diesen Kurs Offene Termine für einzelne Teilnehmende. Als Inhouse-Training kommen wir zu eurem Wunschtermin. Aktuell sind keine offenen Termine ausgeschrieben. Wir richten dieses Format als Inhouse-Training nach eurem Wunschtermin aus. [Wunschtermin anfragen](/kontakt/?kurs=BPMN+2.0+%26+DMN+Training) ## Ihr wollt euer Team befähigen, BPMN sicher einzusetzen? Lass uns in einem kurzen Gespräch klären, ob ein privates Training oder ein Platz im Open Classroom besser zu eurem Vorhaben passt. [Training anfragen](/kontakt/?kurs=BPMN%202.0%20%26%20DMN%20Training) Unverbindlich, kostenfrei und ohne Pitch-Deck. ## [Vom ersten Modell bis zum stabilen Camunda 8 Betrieb.](https://www.miragon.io/trainings/camunda-8-developer-training/) Camunda 8 Developer Training (Java) Vier Tage Hands-on für Java-Entwickler und Architekten. Wir vermitteln alle Patterns, mit denen euer Team Camunda 8 Projekte sicher und schnell umsetzt. Thema Camunda Dauer 4 Tage Level Fortgeschritten Zielgruppe Java-Entwickler & Architekten [Training anfragen](#format) Das Problem ## Camunda 8 tickt anders als Camunda 7. Die Architektur ist grundlegend anders: asynchron, verteilt, Job-Worker statt Delegates. Viele Teams unterschätzen das und verlieren Wochen mit Trial and Error, statt produktiv zu liefern. Die Folgen: ### Versteckte Anti-Patterns Fehlende Idempotenz, unsaubere Korrelation, die falsche Wahl zwischen Connector und Job-Worker. Solche Fehler zeigen sich erst im Echtbetrieb und sind teuer zu reparieren. ### Verzögertes Time-to-Market Ohne gemeinsame Standards baut jeder anders. Jedes Code-Review wird zur Grundsatzdiskussion, jedes Feature dauert länger. ### Falsch geschnittene Teams Camunda 8 ist verteilt und asynchron. Wer Team-Schnitt und Zuständigkeiten aus der Monolith-Welt übernimmt, erzeugt Reibung, statt sie aufzulösen. Agenda ## 4 Tage, die euer Team in Camunda 8 sattelfest machen Jeder Tag baut auf dem vorherigen auf. Am Ende habt ihr eine vollständige Camunda 8 Prozessapplikation gebaut, getestet und kennt die Betriebsthemen, die euer Cluster stabil halten. 1Tag 1Plattform und erste Implementierung - Kickoff & Tooling: IDE, Desktop Modeler, Spring Boot, Self-Managed via Docker Compose oder SaaS-Cluster - Camunda 8 Plattform: Zeebe, Operate, Tasklist, Optimize, Identity, Connector-Runtime - Cloud-native Architektur: Partitionen, Exporter, Elasticsearch, gRPC-API - SaaS vs. Self-Managed: Trade-offs in Betrieb, Customizing und Compliance - Wichtige Unterschiede zu Camunda 7: keine geteilte DB, Event-Sourcing, Job-Worker statt Delegates - Übungsumgebung & Beispiel-Repo gemeinsam aufsetzen - Übung: Cluster lokal hochfahren, Komponenten erkunden, einfaches Modell deployen 2Tag 2Modellierung und Low-Code-Integration - BPMN 2.0 in Camunda 8: Symbol- und Attribut-Whitelist, typische Fallstricke beim Wechsel von C7 - Guidelines zur Modellierung: Verständlichkeit, Wartbarkeit, Fehlervermeidung - Web Modeler vs. Desktop Modeler: Wann was sinnvoll ist - Variablen, Scopes, Input/Output-Mappings - Gateways: XOR, Parallel, Event-basiert, Inclusive und ihre Stolperfallen - FEEL als Expression-Sprache: Conditions, Mappings, Datentypen, häufige Fehler - Connector-Konzept: Inbound vs. Outbound, Element-Templates, Connector-Runtime - Out-of-the-box-Connectors: REST, Kafka, E-Mail, Webhooks, generische Integrationen - Connector vs. Job-Worker: Entscheidungskriterien - Übung: Erstes ausführbares Modell, Routing-Logik mit FEEL, REST-Connector-Integration 3Tag 3Java-Integration, User-Tasks und Tests - Spring Zeebe SDK: Job-Worker-Pattern, Topics/Job-Types, Locking, Retries, Threading - Spring-Zeebe-Annotations, Variablen-Zugriff und Typmapping - Idempotenz, Exactly-Once, Correlation-IDs, Outbox-Pattern - Fehlerbehandlung: technische Exceptions, BPMN-Errors, Incidents - User-Tasks: Lifecycle, Assignment, Candidate Groups, Identity-Integration - Camunda Forms, Form-Linking, Tasklist und API-basierter Zugriff für eigene Frontends - Zeebe-Ausführungsmodell: Streams, Records, Job-Aktivierung, Backpressure - Architekturmuster: Bounded Contexts, Modulgrenzen, Observability mit OpenTelemetry - Prozesstests mit camunda-process-test: BPMN-Pfade, Variablen, Asynchronität, Mocking - Übung: Job-Worker, User-Task-Flow und vollständige Testsuite für einen Beispielprozess 4Tag 4Events, DMN, Betrieb und Migration - Event-Handling: Messages, Timer, Signals, Error-Events, Boundary- und Event-Subprozesse - Korrelation: Korrelationsschlüssel, Message-Buffer, Time-to-Live - Eskalations- und Kompensationspatterns - DMN: Decision-Tables, Hit-Policies, FEEL in DMN, Versionierung und Testbarkeit - DMN sauber in Prozesse einbinden und im Variablen-Mapping verankern - Betrieb: Helm auf Kubernetes, Hybrid-Setups, Cluster-Sizing, Brokerrollen - Exporter und Elasticsearch: Datenfluss, Retention via Index Lifecycle Management (ILM), typische Engpässe - Monitoring: Prometheus-Metriken, Grafana-Dashboards, Alerting auf Backpressure und Exporter-Lag - Versionierung, Process Instance Migration, Hinweise zur Migration von Camunda 7 nach 8 - Wrap-up: Best-Practice-Checkliste, Starter-Template, Architektur-Blueprint, Q&A ### Für wen ist dieses Training? ### Java-Entwickler Ihr seid mit Java, Spring Boot, Dependency-Injection und Unit-Testing vertraut und wollt Camunda 8 produktiv in eure Projekte integrieren, von der Modellierung bis zum Job-Worker. ### Software-Architekten Ihr verantwortet die Architektur eurer Prozessapplikation und wollt fundierte Entscheidungen zu Connector vs. Job-Worker, SaaS vs. Self-Managed und Async-Strategien treffen. ### Entwicklungsteams Ihr startet ein Camunda 8 Vorhaben oder migriert von Camunda 7 und wollt mit gemeinsamen Standards, klaren Patterns und einer geteilten Sprache loslaufen. Unsere Methode ## Damit euer Team Camunda 8 erfolgreich einsetzen kann Wir trainieren entlang einer realistischen Projektstruktur, nicht an abstrakten Folien. Was ihr dabei baut, nehmt ihr als Blueprint mit ins nächste Projekt. ### Am echten Projekt, nicht an Folien Ihr baut Schritt für Schritt eine lauffähige Camunda 8 Applikation: Spring-Zeebe-Worker, Connectors, Tests und Incident-Analyse in Operate. ### Blueprint zum Mitnehmen Die realistische Projektstruktur, eine Testsuite und eine Best-Practice-Checkliste nehmt ihr direkt mit ins nächste Projekt. ### Patterns aus dem Projektalltag Idempotenz, Outbox-Pattern, Incident-Handling und Migration C7→C8, so wie sie sich in echten Kundenprojekten bewährt haben. Kompakt & fokussiert4Tage à 6 Stunden Kleine Gruppe12max. Teilnehmer Praxis vor Theorie50%+Hands-on-Zeit Offizieller PartnerGoldCamunda Partner-Status ### Unsere Trainer Meist übernimmt eine dieser Personen euer Training. Je nach Termin kann es auch jemand anderes aus unserem Team sein. Sprecht sie direkt an, den Rest klären wir gemeinsam. ### Dominik Horn Co-Founder & Geschäftsführer [](mailto:dominik.horn@miragon.io "E-Mail an Dominik Horn")[](https://www.linkedin.com/in/dominik-horn/ "Dominik Horn auf LinkedIn")[](https://calendly.com/dominik-horn-miragon/30min "Termin mit Dominik Horn buchen") ### Marco Schäck Process Development Lead [](mailto:marco.schaeck@miragon.io "E-Mail an Marco Schäck")[](https://www.linkedin.com/in/schaeckm/ "Marco Schäck auf LinkedIn") Format ## Privates Training oder Open Classroom Zwei Formate, eine Entscheidung: ein ganzes Team auf einen Stand bringen oder einzelne Leute aus eurer Organisation entsenden. ### Privates Training Maßgeschneidert Exklusiv für euer Team und individuell anpassbar. Inhalte, Beispiele und Schwerpunkte werden auf eure Architektur, Cluster-Topologie und konkreten Fragen zugeschnitten. Meist vor Ort bei euch, alternativ in unserem Office in Augsburg oder vollständig remote. ### Open Classroom Offene Termine Öffentliches Training mit festem Termin und standardisierter Agenda für Teilnehmende aus unterschiedlichen Unternehmen. Bei uns in Augsburg, ideal um einzelne Personen aus eurem Team gezielt zu entsenden. ## Pakete und Preise Transparente Preise für unser privates Camunda 8 Developer Training und das Kick-Starter-Paket. ### Privates Training 4 Tage exklusiv für euer Team ab 8.000 € 4 Tage à 2.000–2.500 € · bis zu 12 Teilnehmende Maßgeschneidertes 4-Tage-Camunda 8 Training exklusiv für euer Team, vor Ort bei euch, bei uns in Augsburg oder remote. - Bis zu 12 Teilnehmende ohne Aufpreis - Inhalte auf eure Architektur und Patterns zugeschnitten - Hands-on entlang einer realistischen Projektstruktur - Trainer mit Camunda-Gold-Partner-Erfahrung - Schulungsmaterial digital [Privates Training anfragen](/kontakt/?kurs=Camunda%208%20Developer%20Training%20\(Java\)) Empfohlen ### Kick-Starter-Paket Quickcheck + Camunda 8 + BPMN 16.000 € Komplettpaket statt einzelner Buchungen Quickcheck Prozessautomatisierung, Camunda 8 Developer Training und BPMN-Training für die Fachabteilung als ein durchgehendes Enablement-Programm. - 2-tägiger Quickcheck Prozessautomatisierung - 4-tägiges Camunda 8 Developer Training - 3-tägiges BPMN-Training für die Fachabteilung - Aufeinander abgestimmte Inhalte und Termine [Kick-Starter-Paket anfragen](/kontakt/?kurs=Camunda%208%20Developer%20Training%20\(Java\)) ## Termine für diesen Kurs Offene Termine für einzelne Teilnehmende. Als Inhouse-Training kommen wir zu eurem Wunschtermin. Aktuell sind keine offenen Termine ausgeschrieben. Wir richten dieses Format als Inhouse-Training nach eurem Wunschtermin aus. [Wunschtermin anfragen](/kontakt/?kurs=Camunda+8+Developer+Training+%28Java%29) ## Ihr wollt Camunda 8 sicher in eurem Team einführen? Lass uns in einem kurzen Gespräch klären, ob das Training zu eurem Vorhaben passt und welche Schwerpunkte für euch besonders relevant sind. [Training anfragen](/kontakt/?kurs=Camunda%208%20Developer%20Training%20\(Java\)) Unverbindlich, kostenfrei und ohne Pitch-Deck. ## [Vom ersten BPMN-Modell bis zum getesteten & automatisierten Prozess.](https://www.miragon.io/trainings/cib-seven-developer-training/) CIB seven Developer Training Drei Tage Hands-on für Java-Entwickler und Architekten. Wir vermitteln alle Patterns, mit denen euer Team CIB-seven-Projekte sicher und schnell umsetzt, von der Modellierung bis zum produktiven Worker. Thema CIB seven Dauer 3 Tage Level Fortgeschritten Zielgruppe Java-Entwickler & Architekten Nächster Termin 13.–15. Oktober 2026 [Training anfragen](#format) Das Problem ## Die Engine verzeiht keine Anfängerfehler CIB seven deckt viel ab, aber die Lernkurve ist steil. Ohne strukturierten Einstieg verlieren Teams Wochen mit Trial and Error, statt produktiv zu liefern. ### Trial-and-Error mit der Engine Ohne Anleitung tasten sich Teams an Delegates, External-Tasks und Transaktionsgrenzen heran. Was strukturiert in drei Tagen sitzt, kostet sonst Wochen. ### Anti-Patterns in Produktion Falsch gewählte Async-Continuations, fehlende Idempotenz oder schlechte Variablen-Konzepte werden erst im Echtbetrieb sichtbar und sind teuer zu reparieren. ### Time-to-Market verzögert Ohne gemeinsame Standards modelliert jeder anders, jede Code-Review wird zur Diskussion. Klare Patterns aus dem Training sparen Zeit in jedem weiteren Projekt. Agenda ## 3 Tage, die euer Team in CIB seven sattelfest machen Jeder Tag baut auf dem vorherigen auf. Am Ende habt ihr eine vollständige Prozessapplikation gebaut, getestet und deploybar. 1Tag 1Grundlagen, Plattform & erste Implementierung - Tooling-Setup: IDE, Build, Runtime, Deployment-Modell - BPMN-2.0-Grundlagen für ausführbare Modelle - Komponenten der CIB-seven-Plattform: Engine, Modeler, Tasklist - Java Delegates, Execution Listener und Task Listener - Datenobjekte, Gateways und Expressions - Übung: Service-Task mit sauberer Schnittstelle 2Tag 2User-Tasks, Transaktionen, Architektur, Tests - User-Task-Lifecycle, Assignment und Formulare - Async-Continuations, Job-Executor, Retries - Incidents systematisch analysieren und beheben - Architekturmuster für Prozessapplikationen - Unit- und Engine-Tests für BPMN-Pfade - External-Tasks: Topics, Locking, Idempotenz 3Tag 3Events, DMN & Enterprise-Themen - Messages, Timer, Signals, Boundary- und Event-Subprozesse - DMN-Grundlagen: Decision-Tables und Hit-Policies - DMN sauber in Prozesse einbinden und testen - Governance, Deployment-Strategien, Migration - CIB flow, easyForms und coSys im Überblick - Q&A, Best-Practice-Checkliste, nächste Schritte ### Für wen ist dieses Training? ### Java-Entwickler Ihr seid mit Java, Spring Boot und Unit-Testing vertraut und wollt CIB seven sicher in eure Projekte integrieren, ohne Lehrgeld zu zahlen. ### Software-Architekten Ihr verantwortet die Architektur eurer Prozessapplikation und wollt fundierte Entscheidungen zu Delegates vs. External-Tasks, Async-Strategien und Deployment treffen. ### Entwicklungsteams Ihr startet ein neues CIB-seven-Vorhaben und wollt mit gemeinsamen Standards, klaren Patterns und einer geteilten Sprache loslaufen. Unsere Methode ## Von den Anforderungen zum laufenden Prozess Wir trainieren entlang einer realistischen CIB seven Projektstruktur, nicht an abstrakten Folien. Was ihr dabei baut, übernehmt ihr direkt als Blueprint für euer nächstes Projekt. ### Am echten Projekt, nicht an Folien Ihr baut Schritt für Schritt eine lauffähige CIB seven Applikation: BPMN-Modelle, Delegates, External-Task-Worker, Tests und Incident-Analyse. ### Blueprint zum Mitnehmen Die realistische Projektstruktur, eine Testsuite und eine Best-Practice-Checkliste nehmt ihr direkt mit ins nächste Projekt. ### Patterns aus dem Projektalltag Async-Continuation, Idempotenz, Incident-Handling und Test-Strategien, so wie sie sich in echten CIB seven Projekten bewährt haben. Kompakt & fokussiert3Tage kompakt Kleine Gruppe12max. Teilnehmer Praxis vor Theorie50%+Hands-on-Zeit Offizieller PartnerCIB sevenPartner für Trainings ### Unsere Trainer Meist übernimmt eine dieser Personen euer Training. Je nach Termin kann es auch jemand anderes aus unserem Team sein. Sprecht sie direkt an, den Rest klären wir gemeinsam. ### Thomas Heinrichs Solution Architecture Lead [](mailto:thomas.heinrichs@miragon.io "E-Mail an Thomas Heinrichs")[](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/ "Thomas Heinrichs auf LinkedIn")[](https://calendly.com/thomas-heinrichs/30min "Termin mit Thomas Heinrichs buchen") ### Marco Schäck Process Development Lead [](mailto:marco.schaeck@miragon.io "E-Mail an Marco Schäck")[](https://www.linkedin.com/in/schaeckm/ "Marco Schäck auf LinkedIn") Format ## Privates Training oder Open Classroom Zwei Formate, eine Wahl: ein ganzes Team gezielt befähigen oder einzelne Teilnehmende aus eurer Organisation entsenden. ### Privates Training Maßgeschneidert Exklusiv für euer Team und individuell anpassbar. Inhalte, Beispiele und Schwerpunkte werden auf eure Prozesse, Architektur und Fragen zugeschnitten. Meist vor Ort bei euch, alternativ in unserem Office in Augsburg. ### Open Classroom Offene Termine Öffentliches Training mit festem Termin und standardisiertem Rahmen für Teilnehmende aus unterschiedlichen Unternehmen. Generische Beispiele entlang einer geprüften Agenda. In Augsburg bei Miragon oder in München bei der CIB. ## Pakete und Preise Transparente Preise für unser privates Training und das Kick-Starter-Paket. Open-Classroom-Termine bitte direkt anfragen. ### Privates Training 3 Tage exklusiv für euer Team 6.000 € 3 Tage à 2.000 € · bis zu 12 Teilnehmende Maßgeschneidertes 3-Tage-Developer-Training exklusiv für euer Team, vor Ort bei euch oder bei uns in Augsburg. - Bis zu 12 Teilnehmende ohne Aufpreis - Inhalte auf eure Architektur und Patterns zugeschnitten - Hands-on entlang einer realistischen Projektstruktur - Schulungsmaterial digital und gedruckt [Privates Training anfragen](/kontakt/?kurs=CIB%20seven%20Developer%20Training) Empfohlen ### Kick-Starter-Paket Quickcheck + CIB seven + BPMN 16.000 € Komplettpaket statt einzelner Buchungen Quickcheck Prozessautomatisierung, CIB seven Developer Training und BPMN-Training für die Fachabteilung als ein durchgehendes Enablement-Programm. - 2-tägiger Quickcheck Prozessautomatisierung - 3-tägiges CIB seven Developer Training - 3-tägiges BPMN-Training für die Fachabteilung - Aufeinander abgestimmte Inhalte und Termine [Kick-Starter-Paket anfragen](/kontakt/?kurs=CIB%20seven%20Developer%20Training) ## Termine für diesen Kurs Offene Termine für einzelne Teilnehmende. Als Inhouse-Training kommen wir zu eurem Wunschtermin. 13.–15. Oktober 2026 Präsenz · Augsburg · Plätze frei [Platz anfragen](/kontakt/?kurs=CIB+seven+Developer+Training&termin=13.%E2%80%9315.+Oktober+2026) 16.–18. November 2026 Online · Plätze frei [Platz anfragen](/kontakt/?kurs=CIB+seven+Developer+Training&termin=16.%E2%80%9318.+November+2026) ## Reden wir über euer Team. In einem kurzen Gespräch klären wir ehrlich, ob das Training zu eurem Vorhaben passt und welches Format euch wirklich weiterbringt. Wenn nicht, sagen wir das auch. [Training anfragen](/kontakt/?kurs=CIB%20seven%20Developer%20Training) Unverbindlich, kostenfrei und ohne Pitch-Deck. ## [In 2 Tagen wisst ihr, wie ihr weiterkommt.](https://www.miragon.io/trainings/process-automation-quickcheck/) Quickcheck Prozessautomatisierung Wir analysieren Prozesse und Systemlandschaft, schärfen das Zielbild gemeinsam mit euch und liefern eine priorisierte Liste an Handlungsempfehlungen. Thema Strategie Dauer 2 Tage Level Strategisch Zielgruppe Entscheider & Architekten [Training anfragen](#format) Das Problem ## Wenn Automatisierungsvorhaben in der Analyse-Phase steckenbleiben Viele Initiativen verbrennen Monate mit Diskussionen über Plattform, Standards und Governance, bevor der erste Prozess produktiv läuft. Der Quickcheck bringt euch in zwei Tagen aus der Schleife. ### Unklarheit über den Hebel Welcher Prozess bringt den größten Impact? Ohne strukturierte Analyse wird nach Lautstärke priorisiert, nicht nach Wirkung. Quick-Wins bleiben liegen, Großprojekte überfordern. ### Tool-Diskussionen ohne Fundament Bevor klar ist, was automatisiert werden soll, wird über Camunda, CIB seven, Temporal oder Flowable gestritten. Wir drehen die Reihenfolge: erst Anforderungen, dann Tool. ### Nicht-funktionale Anforderungen erst im Betrieb sichtbar Skalierbarkeit, Verfügbarkeit, Sicherheit und Compliance werden oft erst im Betrieb sichtbar. Wir machen Architecture Characteristics früh explizit, damit Architektur und Vorgehen darauf zahlen. Agenda ## 2 Tage, die euer Vorhaben aus der Analyse-Schleife holen Tag 1 dient der Ist-Aufnahme und gemeinsamem Verständnis, Tag 2 schärft das Zielbild und liefert konkrete Handlungsempfehlungen. 1Tag 1Ist-Aufnahme & gemeinsames Verständnis - Kickoff: Ziele, Scope, Teilnehmer, Vorgehen - Review der dokumentierten Prozesse end-to-end - Konstruktives Challenging: Engpässe, Risiken, Hebel - Review der Systemlandschaft, Integrationen, Datenflüsse - Einordnung möglicher Plattformen und Live-Demos - Konsolidierung der Erkenntnisse als Input für Tag 2 2Tag 2Zielbild & priorisierte Maßnahmen - Erhebung und Priorisierung von Architecture Characteristics - Wardley-Mapping-Workshop für strategische Klarheit - Prozess-Zielbild und Systemarchitektur - Wirkungspotenziale und konkrete Angriffspunkte - Priorisierte Handlungsempfehlungen, Quick-Wins vs. Grundlagen - Umsetzungsplan und nächste Schritte mit Ownern ### Für wen ist dieser Quickcheck? ### Entscheider & Management Ihr wollt Zielkonflikte zeitnah auflösen, Prioritäten setzen und Investitionen in Plattform und Architektur fundiert treffen. ### Projektteams & Architekten Ihr kennt die dokumentierten Prozesse, Schnittstellen und Datenflüsse und wollt eine belastbare Grundlage für die Umsetzung schaffen. ### Fachliche Experten Ihr bringt End-to-End-Wissen aus den Domänen ein: Varianten, Ausnahmen, Compliance und operative Schmerzpunkte werden direkt sichtbar. Unsere Methode ## Strukturierte Analyse mit eurem Team Wir verbinden Prozess- und Architekturanalyse mit Wardley Mapping. Am Ende habt ihr eine priorisierte Liste konkreter Handlungsempfehlungen. ### Ist-Aufnahme & Challenge Wir reviewen eure dokumentierten Prozesse end-to-end, identifizieren Engpässe und Standardisierungspotenziale und challengen Annahmen konstruktiv. ### Wardley Mapping Wir kartieren Nutzerbedürfnisse, Value-Chain und Komponenten und treffen Build-vs-Buy-Entscheidungen anhand von Reifegraden, nicht nach Bauchgefühl. ### Priorisierte Maßnahmen Quick-Wins, Grundlagen und Großprojekte priorisiert nach Nutzen, Risiko und Abhängigkeiten. Mit klarer Reihenfolge und Aufwand-Nutzen-Einschätzung. 2Tage Workshop 4Artefakte: Wardley Map, Zielbild, Architecture Characteristics, Maßnahmenliste 12max. Teilnehmer 1Plan, wie es weitergeht ### Dein Trainer Meist übernimmt eine dieser Personen euer Training. Je nach Termin kann es auch jemand anderes aus unserem Team sein. Sprecht sie direkt an, den Rest klären wir gemeinsam. ### Thomas Heinrichs Solution Architecture Lead [](mailto:thomas.heinrichs@miragon.io "E-Mail an Thomas Heinrichs")[](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/ "Thomas Heinrichs auf LinkedIn")[](https://calendly.com/thomas-heinrichs/30min "Termin mit Thomas Heinrichs buchen") Stimmen ## Was Kunden über den Quickcheck sagen Aus Projekten, in denen wir Automatisierungsvorhaben gemeinsam mit Entscheidern, Architekten und Fachbereichen geschärft haben. Automatisierungsstrategien auf Unternehmensebene sind herausfordernd und sind unter falscher Ausrichtung oft zum Scheitern verurteilt. Über den Quickcheck ließen wir unsere Ansätze und Lösungen professionell auf den Prüfstand stellen. Mit der unterstützten Ausarbeitung nächster Schritte und den Empfehlungen zum methodischen Vorgehen fühlen wir uns nachhaltig gewappnet für die Umsetzung zielgerichteter Prozessautomatisierungslösungen innerhalb der gesamten Organisation. **Tim Stawowski** Wertgarantie ## Pakete und Preise Transparente Preise für den privaten Quickcheck und das Kick-Starter-Paket. ### Privater Quickcheck 2 Tage exklusiv für euer Vorhaben 4.000 € 2 Tage à 2.000 € · bis zu 12 Teilnehmende Maßgeschneiderter Quickcheck exklusiv für euer Team und Vorhaben, vor Ort bei euch oder remote. - Bis zu 12 Teilnehmende ohne Aufpreis - Wardley Map, Zielbild, Architecture Characteristics - Priorisierte Maßnahmenliste mit Aufwand-Nutzen-Einschätzung - Konkreter Umsetzungsplan mit Ownern [Quickcheck anfragen](/kontakt/?kurs=Quickcheck%20Prozessautomatisierung) Empfohlen ### Kick-Starter-Paket Quickcheck + CIB seven + BPMN 16.000 € Komplettpaket statt einzelner Buchungen Quickcheck Prozessautomatisierung, CIB seven Developer Training und BPMN-Training für die Fachabteilung als ein durchgehendes Enablement-Programm. - 2-tägiger Quickcheck Prozessautomatisierung - 3-tägiges CIB seven Developer Training - 3-tägiges BPMN-Training für die Fachabteilung - Aufeinander abgestimmte Inhalte und Termine [Kick-Starter-Paket anfragen](/kontakt/?kurs=Quickcheck%20Prozessautomatisierung) ## Termine für diesen Kurs Offene Termine für einzelne Teilnehmende. Als Inhouse-Training kommen wir zu eurem Wunschtermin. Aktuell sind keine offenen Termine ausgeschrieben. Wir richten dieses Format als Inhouse-Training nach eurem Wunschtermin aus. [Wunschtermin anfragen](/kontakt/?kurs=Quickcheck+Prozessautomatisierung) ## In 2 Tagen wisst ihr, wo ihr ansetzt. Bringt euer Automatisierungsvorhaben aus der Schleife. Nach dem Quickcheck habt ihr eine priorisierte Liste an Handlungsempfehlungen und wisst, wie es konkret weitergeht. Lasst uns in einem kurzen Gespräch klären, ob der Quickcheck zu eurem Vorhaben passt. [Quickcheck anfragen](/kontakt/?kurs=Quickcheck%20Prozessautomatisierung) Unverbindliches Erstgespräch, ca. 30 Minuten. ## [Prozessautomatisierung, die wirklich funktioniert](https://www.miragon.io/trainings/soziotechnische-systeme-workshop/) Workshop Soziotechnische Systeme Automatisierung ist kein reines IT-Projekt, sondern ein soziotechnisches System. Sie greift tief in Technik, Organisation und Kultur ein. In diesem Workshop lernst du, wie du sie strategisch planst und umsetzt, ohne die typischen Fallen. Thema Soziotechnische Systeme Dauer 1 Tag Level Strategisch Zielgruppe IT-Leitung, Architektur & Projektleitung [Training anfragen](/kontakt/?kurs=Workshop%20Soziotechnische%20Systeme) Das Problem ## Warum Automatisierung oft scheitert Zu viele Teams setzen Automatisierung als reines Technikprojekt auf. Drei Muster führen immer wieder zum Scheitern. ### Als IT-Projekt statt als Transformation Automatisierung wird technisch sauber aufgesetzt, aber ohne Teams, Prozesse und Organisation mitzudenken. Am Ende läuft die Software, doch niemand nutzt sie wirklich. Technik ohne Organisation ist Digitalisierung, keine Transformation. ### Zu groß gestartet, zu spät geliefert Bevor der erste Prozess produktiv läuft, wird monatelang über Plattform-Strategie, Standards und Governance diskutiert. Wenn die Lösung endlich live geht, hat sich das Problem längst verändert, und das Vertrauen ist verbraucht. ### Selbst gebaut statt klug gelöst Monate an Eigenentwicklung für Probleme, die von der Stange gelöst sind. Der Fokus liegt auf Technik, nicht auf der Wirkung für Fachbereich und Kunden. Build vs. Buy wird entlang von Gewohnheit entschieden, nicht entlang des Reifegrads. Zielgruppe ## Für wen ist dieser Workshop? ### IT-Leitung & CTOs Du spürst den Transformationsdruck und willst eine Strategie, bevor das Budget in Technologie und Plattformen fließt. Der Workshop liefert die Entscheidungsgrundlage, um die richtigen Prioritäten zu setzen, statt die teuersten. ### Architekten & Entwickler Du willst Automatisierung sauber aufsetzen und langfristig wartbar halten. Hier siehst du, wie Teamschnitte, Architekturentscheidungen und Prozessdesign zusammenhängen, und wie du von Anfang an die richtigen Weichen stellst, statt sie später teuer umzubauen. ### Projektleitung & Business Analysten Du modellierst Prozesse strukturiert und willst den Überblick über das Gesamtvorhaben behalten. Du bekommst Werkzeuge an die Hand, um fachliche Anforderungen und technische Umsetzung sauber zu verbinden, statt sie aneinander vorbeilaufen zu lassen. Inhalte ## Was du im Workshop lernst ### Automatisierung als Gesamtsystem denken Erfolgreiche Automatisierung entsteht im Zusammenspiel von Menschen, Technik, Prozessen und Kultur. Wer nur die technische Seite optimiert, scheitert an der Organisation. Du lernst, wie du alle vier Dimensionen gleichzeitig gestaltest und warum gemeinsames Modellieren mit Fachbereichen und Entwicklung der Schlüssel ist, um Silos aufzubrechen. ### Teams richtig aufstellen Deine Teamstruktur bestimmt deine Architektur, ob du willst oder nicht. Mit dem Team-Topologies-Framework lernst du die vier Teamtypen kennen und wie du sie so kombinierst, dass Teams autonom liefern können. Wir schauen uns an, wie Cognitive Load als Design-Prinzip funktioniert und wann Plattform-Teams sinnvoll werden. ### Make, Buy oder Adapt? Nicht alles muss selbst gebaut werden, aber auch nicht alles lässt sich einkaufen. Mit Wardley Mapping analysierst du den Reifegrad jeder Komponente deines Vorhabens und triffst fundierte Build-vs-Buy-Entscheidungen. Praxisbeispiel: In einem realen Geschäftsreiseprozess war nur 1 von 11 Komponenten tatsächlich Custom. Den Rest hätte man von Anfang an anders lösen können. ### Wirkung messen statt Features zählen Erfolg heißt nicht '5 Prozesse automatisiert'. Erfolg heißt: kürzere Durchlaufzeiten, weniger manuelle Fehler, mehr Autonomie für Teams. Du lernst Prozess-KPIs, DORA-Metriken und Fitness Functions kennen. Vor allem lernst du, wie du sie so einsetzt, dass sie echtes Verhalten in deiner Organisation verändern statt nur Dashboards zu füllen. ### Komplexität gezielt steuern Fachliche Komplexität lässt sich durch Automatisierung reduzieren, aber technische und organisatorische Komplexität steigen dabei oft unbemerkt. Das ist das Automatisierungsparadox. Du lernst den Unterschied zwischen essentieller und akzidenteller Komplexität kennen und bekommst konkrete Strategien, um die richtige Balance zu finden statt Komplexität nur zu verschieben. ### Unsere Trainer Meist übernimmt eine dieser Personen euer Training. Je nach Termin kann es auch jemand anderes aus unserem Team sein. Sprecht sie direkt an, den Rest klären wir gemeinsam. ### Dominik Horn Co-Founder & Geschäftsführer [](mailto:dominik.horn@miragon.io "E-Mail an Dominik Horn")[](https://www.linkedin.com/in/dominik-horn/ "Dominik Horn auf LinkedIn")[](https://calendly.com/dominik-horn-miragon/30min "Termin mit Dominik Horn buchen") ### Thomas Heinrichs Solution Architecture Lead [](mailto:thomas.heinrichs@miragon.io "E-Mail an Thomas Heinrichs")[](https://www.linkedin.com/in/thomas-heinrichs-907b0015a/ "Thomas Heinrichs auf LinkedIn")[](https://calendly.com/thomas-heinrichs/30min "Termin mit Thomas Heinrichs buchen") Ergebnis ## Was du mitnimmst Keine Theorie für die Schublade, sondern Werkzeuge, die du direkt in deinem nächsten Projekt einsetzen kannst. ### Entscheidungs-Checkliste Ein strukturierter Fragenkatalog, mit dem du früh erkennst, ob dein Vorhaben echte Transformation ist oder nur Digitalisierung bestehender Abläufe. Damit vermeidest du die häufigsten Fehlstarts. ### Deine Wardley Map Eine strategische Landkarte deines Automatisierungsvorhabens mit klaren Build-vs-Buy-Empfehlungen. Du siehst auf einen Blick, wo Eigenentwicklung sinnvoll ist und wo du besser auf bestehende Lösungen setzt. ### Team-Analyse Eine Bewertung deiner aktuellen Teamstruktur anhand des Team-Topologies-Frameworks. Du erhältst konkrete Vorschläge, wie du Teams so aufstellst, dass sie autonom liefern können, ohne sich gegenseitig zu blockieren. ### Messbare Zielmetriken Ein Set aus Prozess-KPIs und Fitness Functions, zugeschnitten auf dein Vorhaben. Statt vager Ziele wie 'mehr Effizienz' hast du Indikatoren, an denen du den Erfolg deines Projekts wirklich ablesen kannst. ### Priorisierte Handlungsempfehlungen Klare nächste Schritte, sortiert nach Wirkung und Aufwand. Du weißt genau, wo du anfangen solltest und welche Hebel in deinem Kontext den größten Unterschied machen, damit du nicht an zu vielen Stellen gleichzeitig ansetzt. ## Termine für diesen Kurs Offene Termine für einzelne Teilnehmende. Als Inhouse-Training kommen wir zu eurem Wunschtermin. Aktuell sind keine offenen Termine ausgeschrieben. Wir richten dieses Format als Inhouse-Training nach eurem Wunschtermin aus. [Wunschtermin anfragen](/kontakt/?kurs=Workshop+Soziotechnische+Systeme) ## Bereit, Automatisierung als soziotechnisches System zu denken? In einem unverbindlichen Gespräch schauen wir gemeinsam auf dein Vorhaben: Wo stehst du, welche der vier Dimensionen (Mensch, Technik, Prozess, Kultur) sind unterversorgt, und ist der Workshop für deinen Kontext der richtige Hebel? [Workshop anfragen](/kontakt/?kurs=Workshop%20Soziotechnische%20Systeme) 30 Minuten. Kein Verkaufsgespräch, keine Verpflichtung. ## [Redirecting to: /leistungen/](https://www.miragon.io/transformation/) ## [Wie automatisiere ich einen Prozess?](https://www.miragon.io/wie-automatisiere-ich-einen-prozess/) Leitfaden Einen Prozess automatisierst du in fünf Schritten: den richtigen Prozess verstehen, das Potenzial priorisieren, den Ziel-Prozess modellieren, mit der passenden Technologie umsetzen und dein Team befähigen. Der größte Hebel liegt nicht im Tool, sondern in der Auswahl des richtigen Prozesses und darin, Komplexität früh zu reduzieren. [Erstgespräch vereinbaren](/kontakt/) So gehst du vor ## In 5 Schritten zur laufenden Automatisierung Kein monatelanges Konzeptpapier. Du startest klein, lieferst früh sichtbare Ergebnisse und skalierst, was funktioniert. 1. 1 ### Den richtigen Prozess auswählen und verstehen Nicht jeder Prozess lohnt die Automatisierung. Finde mit Process Mining und Gesprächen mit den Beteiligten heraus, wo Durchlaufzeiten, Fehler und manuelle Übergaben am meisten kosten. Priorisiere nach Wirkung, nicht nach Aufwand. [Mehr dazu](/trainings/process-automation-quickcheck/) 2. 2 ### Reifegrad einordnen und Komplexität reduzieren Bevor du baust: ordne jede Komponente per Wardley Mapping nach Reifegrad ein. Was am Markt Standard ist, kaufst du. Nur was dich wirklich differenziert, baust du selbst. So vermeidest du Komplexität, die später jeden Monat Geld kostet. [Mehr dazu](/blog/komplexitaet-meistern-prozessautomatisierung/) 3. 3 ### Den Ziel-Prozess modellieren Modelliere den Ablauf gemeinsam mit Fachbereich und IT in BPMN 2.0. Ein gemeinsames Modell schafft Klarheit und wird zur ausführbaren Grundlage. Anforderungen wie Skalierbarkeit, Sicherheit und Compliance gehören jetzt auf den Tisch, nicht erst im Betrieb. [Mehr dazu](/trainings/bpmn-training/) 4. 4 ### Die passende Technologie wählen und umsetzen Workflow-Engine, Integrationsplattform oder beides? Entscheide nach Anforderung, nicht nach Hype. Beweise die Lösung mit einem Proof of Concept an echten Daten, dann rolle schrittweise aus. Du siehst Fortschritt, nicht nur Folien. [Mehr dazu](/portfolio/automate/) 5. 5 ### Das Team befähigen und skalieren Automatisierung ist erst fertig, wenn dein Team ohne uns weiterbaut. Über Trainings, wiederverwendbare Bausteine und klare Team-Strukturen wird aus dem ersten Prozess eine organisationsweite Plattform. Erfolg misst du an Durchlaufzeit und Fehlerrate, nicht an der Zahl der Diagramme. [Mehr dazu](/trainings/) Warum es oft scheitert ## Die häufigsten Fehler bei der Automatisierung Die meisten Automatisierungsprojekte scheitern nicht an der Technik. Sie scheitern an den Entscheidungen davor. ### Tool vor Prozess Erst die Lizenz, dann die Frage, was eigentlich automatisiert werden soll. Wer mit dem Werkzeug startet, baut am Problem vorbei. ### Alles selbst gebaut Maßgeschneidert, wo Standard gereicht hätte. Jede selbst gebaute Komponente, die es am Markt gibt, kostet dich in der Wartung dauerhaft Geld. ### Insellösungen statt System Jede Abteilung ihr eigenes Tool, kein gemeinsames Prozessverständnis. Was nicht zusammenspielt, skaliert nicht. ### Wirkung nie gemessen Fünf Prozesse automatisiert klingt gut. Aber wurde die Durchlaufzeit kürzer, die Fehlerrate kleiner? Ohne Messung bleibt es Bauchgefühl. ### Der größte Hebel ist nicht technisch Die meisten Vorhaben scheitern nicht an der Engine, sondern an Struktur, Kultur und Führung. Technologie kannst du kaufen, die passende Organisation nicht. Plane Change Management von Anfang an mit und etabliere ein Mindset, das Automatisierung als gemeinsame Verbesserung versteht, nicht als Bedrohung. - Vertrauen statt Micromanagement. Führung gibt Verantwortung ab, die Teams entscheiden im Tagesgeschäft selbst. Wer jeden Schritt kontrolliert, erstickt genau die Eigeninitiative, die Automatisierung am Laufen hält. - Klare Teamgrenzen. Ein Team besitzt seinen Prozess end-to-end, statt dass fünf Stellen mitreden. Unscharfe Grenzen erzeugen Reibung, Wartezeiten und am Ende niemanden, der sich verantwortlich fühlt. - Weniger Abstimmung. Zu viele Meetings und Freigabeschleifen bremsen stärker als jede Technologie. Gib Teams die Autonomie, die sie für ihren Prozess brauchen, und halte den Koordinationsaufwand klein. Technologien ## Das richtige Werkzeug für jede Aufgabe Wir sind zertifizierte Partner führender Plattformen, viele davon Open Source. Faustregel: Geschäftskritisches und Langlebiges gehört auf eine Workflow-Engine, schnelle Integrationen erledigt Low-Code. Die Technologie richtet sich nach deiner Anforderung, nicht nach unserem Lizenzgeschäft. ### Workflow Engines Camunda 7 & 8, CIB seven, Flowable, Temporal. Für orchestrierte Geschäftsprozesse mit BPMN, die skalieren und auditierbar sind. ### Integration & Automatisierung n8n, Apache Kafka, REST- und GraphQL-APIs. Für nahtlose Systemintegration und event-basierte Architekturen. ### Process Mining & Analytics Celonis, Signavio, eigene Analysetools. Damit findest du datenbasiert die Prozesse, die sich wirklich lohnen. KI im Prozess ## Wo KI wirklich Tempo bringt, und wo nicht KI ersetzt keine saubere Modellierung. An den richtigen Stellen spart sie aber echte Arbeit, mit klaren Guardrails statt Prompt-Bastelei. Wo KI nicht hingehört: die Modellierung im Alleingang. Prozesse entstehen kollaborativ zwischen Fachbereich und IT. ### Code aus dem Modell Aus BPMN-Elementen Service-Tasks und Adapter generieren. KI beschleunigt die Fleißarbeit, das Modell bleibt in Menschenhand. ### Tests automatisch erzeugen Mehr Prozesspfade abgedeckt, weniger manueller Aufwand. Mehr Sicherheit beim nächsten Refactoring. ### Engpässe erkennen KI wertet Prozess-Logs aus, deckt Anomalien auf und liefert Entscheidungsgrundlagen, ohne manuelles Reporting. FAQ ## Häufige Fragen zur Prozessautomatisierung Was Teams typischerweise wissen wollen, bevor sie ihren ersten Prozess automatisieren. Was bedeutet Prozessautomatisierung? Prozessautomatisierung heißt, einen Ablauf aus mehreren Schritten, Systemen und Beteiligten so zu orchestrieren, dass er ohne manuelle Übergaben läuft. Eine Workflow-Engine steuert die Reihenfolge, ruft Systeme auf und übergibt nur dort an Menschen, wo eine Entscheidung nötig ist. Das verkürzt Durchlaufzeiten und macht den Status jederzeit sichtbar. Welchen Prozess sollte ich zuerst automatisieren? Den, der viel manuelle Arbeit bindet, oft fehleranfällig ist und häufig vorkommt. Hoher Hebel, überschaubares Risiko. Prozesse mit vielen Sonderfällen und unklaren Regeln eignen sich schlechter für den Start. Beginne mit einem Leuchtturm, der schnell sichtbaren Nutzen zeigt und im Team Vertrauen schafft. Welche Technologie brauche ich? Muss es Camunda sein? Nein. Camunda ist stark für geschäftskritische, langlebige Prozesse mit BPMN, aber nicht für jede Aufgabe nötig. Schnelle Integrationen erledigt oft Low-Code wie n8n. Lang laufende, robuste Workflows passen zu Temporal. Wir wählen technologieneutral nach Anforderung, nicht nach Lizenzgeschäft. BPMN, Low-Code oder eigener Code? BPMN macht Prozesse für Fachbereich und IT gemeinsam lesbar und zugleich ausführbar. Low-Code beschleunigt einfache Integrationen, stößt bei komplexer Logik aber an Grenzen. Eigener Code lohnt nur dort, wo du dich wirklich differenzierst. Meist ist die Kombination richtig: BPMN für die Orchestrierung, Code für die Fachlogik. Camunda 7, Camunda 8 oder CIB seven? Camunda 7 läuft in vielen Bestandssystemen stabil, der Hersteller-Support läuft aber aus. Camunda 8 ist cloud-nativ und hochskalierbar, verlangt dafür ein anderes, asynchrones Architektur-Mindset. CIB seven ist die Open-Source-Fortführung der Camunda-7-Plattform. Welche zu dir passt, klären wir in einem ehrlichen Assessment. Wie lange dauert eine Prozessautomatisierung und was kostet sie? Ein erster Proof of Concept an echten Daten steht meist in ein bis zwei Wochen. Der Ausbau danach hängt vom Umfang ab und läuft in Iterationen. Die Kosten richten sich nach dem Scope. Das Erstgespräch ist kostenfrei und liefert dir eine realistische Einschätzung, bevor du dich festlegst. Brauche ich dafür KI? Nein, KI ist kein Muss. Sie beschleunigt aber die Fleißarbeit: Code aus Modellen generieren, Tests erzeugen, Logs auswerten. Die Prozesslogik und die Modellierung gehören weiter in Menschenhand, mit klaren Guardrails. KI setzen wir nur dort ein, wo sie messbar Tempo bringt. Selbst bauen oder kaufen? Nicht alles muss selbst gebaut werden, aber auch nicht alles lässt sich einkaufen. Mit Wardley Mapping ordnest du jede Komponente nach Reifegrad ein. Was am Markt Standard ist, kaufst du. Nur was dich differenziert, baust du selbst. Das spart oft den Großteil der Entwicklungsressourcen. Wie messe ich, ob die Automatisierung erfolgreich ist? An der Wirkung, nicht an der Zahl der Diagramme. Miss Durchlaufzeit, Fehlerrate und manuelle Eingriffe pro Vorgang vor und nach der Automatisierung. Für die technische Lieferfähigkeit helfen DORA-Metriken. So zeigst du schwarz auf weiß, was die Automatisierung gebracht hat. Wie fange ich am besten an? Mit einem klar abgegrenzten Prozess und einem ehrlichen Blick auf Potenzial und Aufwand. In einem kostenlosen Erstgespräch schauen wir gemeinsam auf deinen konkreten Fall und sagen dir offen, ob und wo sich Automatisierung lohnt. Sehen wir keinen tragfähigen Hebel, sagen wir das auch. ## So gehen wir es gemeinsam an [ ### Prozessautomatisierung Systeme verbinden und manuelle Schritte automatisieren, technologieneutral und ohne Vendor Lock-in. ](/portfolio/automate/) [ ### Quickcheck Prozessautomatisierung Zwei Tage Ist-Aufnahme und priorisierte Roadmap. Klarheit, wo Automatisierung den größten Hebel hat. ](/trainings/process-automation-quickcheck/) [ ### BPMN 2.0 & DMN Training Dein Team lernt, Prozesse sauber zu modellieren und ausführbar zu machen. ](/trainings/bpmn-training/) [ ### KI-Integration KI an eure echten Systeme andocken: per MCP-Server, Agents und Workplace-Automatisierung. ](/portfolio/ki-integration/) [ ### Camunda Migration Von Camunda 7 zu Camunda 8 oder CIB seven. Ehrliches Assessment statt Migration ins Blaue. ](/portfolio/camunda-7-migration/) [ ### Alle Leistungen im Überblick Von der Prozessanalyse über die Architektur bis zum eigenständigen Betrieb. ](/leistungen/) Weiterlesen ## Tiefer einsteigen [ 12\. Mai 2025 ### Komplexität meistern – Wie Prozessautomatisierung gelingt Erfahrungen aus einem Jahrzehnt Prozessautomatisierung: Warum Kontext, Teamstrukturen und organisatorische Reife wichtiger sind als Technologie allein. Weiterlesen ](/blog/komplexitaet-meistern-prozessautomatisierung/) [ 11\. März 2025 ### Camunda 7 vs. 8 – Eine Betrachtung durch die Brille von Team Topologies Die Migration von Camunda 7 zu 8 erfordert neue Teamstrukturen. Eine Analyse durch die Brille von Team Topologies. Weiterlesen ](/blog/camunda-7-vs-8-team-topologies/) [ 10\. März 2025 ### Handlungsspielräume in Prozesslandschaften mit Wardley-Mapping identifizieren Wie Wardley Mapping strategische Klarheit in Prozesslandschaften schafft und Handlungsspielräume aufzeigt. Weiterlesen ](/blog/wardley-mapping-prozesslandschaften/) [ 29\. Apr. 2023 ### Low-Code-Prozessautomatisierung - Herausforderungen und Lösungsansätze bei der Umsetzung von Projekten Herausforderungen und Lösungsansätze bei der Umsetzung von Low-Code-Projekten zur Prozessautomatisierung - von Dependency Management bis CI/CD. Weiterlesen ](/blog/low-code-prozessautomatisierung-herausforderungen/) [ 04\. Aug. 2022 ### Wiederverwendbare Prozessbausteine Wie wiederverwendbare Prozessbausteine in BPMN die Prozessmodellierung vereinfachen und Low-Code durch klare Schnittstellen ermöglichen. Weiterlesen ](/blog/wiederverwendbare-prozessbausteine/) [ 07\. Dez. 2020 ### Prozessautomatisierung in der Baubranche Gemeinsam mit Studierenden der Hochschule Augsburg und der SSB Fidan digitalisieren wir Prozesse in der Baubranche - von Leistungsnachweisen bis zur Abrechnung. Weiterlesen ](/blog/prozessautomatisierung-baubranche/) ## Innerhalb eines Tages weißt du, wo du stehst. Kein Verkaufsgespräch, sondern eine ehrliche Einschätzung, ob und wie Automatisierung dir hilft. [Erstgespräch vereinbaren](/kontakt/) Kein Commitment. Kein Pitch-Deck. Nur Klarheit.