Ihr Entwicklungsteam hat drei Monate mit der Entwicklung eines maßgeschneiderten Kundenportals verbracht, nur um am Ende festzustellen, dass die Vertriebsabteilung es nicht nutzen kann, weil es deren tatsächlichen Workflow ignoriert. Jeder Entwicklungstag hat 1.200 USD verbrannt, und nun stehen Sie vor einer kompletten Neuentwicklung. Dies ist kein Kompetenzproblem der Entwickler, sondern ein Kommunikationsfehler. Sage und schreibe 68 % aller maßgeschneiderten Softwareprojekte überschreiten ihr Budget oder scheitern gänzlich aufgrund nicht aufeinander abgestimmter Anforderungen.
Stefan Priebsch, ein renommierter Berater für Software-Erfolg, fasste dieses Dilemma in einer einfachen Regel zusammen: „Diskutieren Sie nie etwas Unsichtbares.“ Wenn Fachexperten und Entwickler über Softwareanforderungen sprechen, stützen sie sich auf abstrakte Konzepte in ihren Köpfen. Diese unsichtbaren mentalen Modelle weichen drastisch voneinander ab, was zu einer trügerischen Übereinstimmung führt. Collaborative Software Modeling schließt diese Lücke, indem es Prozesse für alle Beteiligten sichtbar, greifbar und verständlich macht.
Die unsichtbare Wand in der Softwareentwicklung
Softwareentwicklung ist im Grunde ein menschliches Kommunikationsproblem, das sich als technische Herausforderung tarnt. Business-Stakeholder sprechen von Kunden, Umsätzen und regulatorischer Compliance. Entwickler sprechen von Datenbanken, Endpoints, Microservices und Zustandsübergängen (State Transitions). Wenn diese beiden Welten in einem 150-seitigen Lastenheft aufeinandertreffen, gehen Details in der Übersetzung verloren.
Traditionelle Spezifikationen scheitern, weil sie passiv sind. Ein Entwickler liest eine Anforderung, interpretiert sie auf Basis seiner technischen Prägung und schreibt Code. Der Business-Stakeholder geht davon aus, dass der Entwickler seine Absicht verstanden hat. Diese Diskrepanz bleibt bis zur ersten Demo verborgen, die oft erst Wochen oder Monate nach Beginn des Entwicklungszyklus stattfindet.
Laut dem CHAOS Report der Standish Group sind nur etwa 30 % aller Softwareprojekte im Zeit- und Budgetrahmen erfolgreich. Der Hauptgrund dafür ist nicht schlechter Code, sondern mangelhaftes Requirements Engineering. Die Behebung eines Anforderungsfehlers nach dem Deployment der Software ist bis zu 100-mal teurer als die Behebung während der Designphase. Durch die Visualisierung des Systems, noch bevor die erste Zeile Code geschrieben wird, können Unternehmen Zehntausende von Dollar an verschwendeten Entwicklungsstunden einsparen.
Einführung in das Collaborative Software Modeling
Um diese Kommunikationslücke zu schließen, nutzt die moderne Softwareentwicklung Collaborative Software Modeling. Diese Methodik bringt Fachexperten, Tech Leads und Entwickler zusammen, um das Strukturmodell der Software gemeinsam zu erstellen. Anstatt flache Textdokumente zu lesen, baut das Team eine gemeinsame visuelle Landkarte der Business-Domäne auf.
Diese frühzeitige Abstimmung bringt erhebliche Vorteile durch Collaborative Software Modeling (Collaborative Software Modeling Benefits) mit sich. Durch den Einsatz haptischer und visueller Werkzeuge schaffen Teams eine „Ubiquitous Language“ – ein gemeinsames Vokabular, das sowohl von Business-Stakeholdern als auch von Entwicklern verwendet wird. Wenn das Business-Team das Wort „Consignment“ verwendet, nutzt auch der Code den Begriff „Consignment“, was die kognitive Last der Übersetzung eliminiert.
Darüber hinaus hilft Collaborative Modeling dabei, versteckte Edge Cases zu identifizieren, lange bevor die Entwicklung beginnt. Es zwingt Teams dazu, schwierige Fragen zu Prozessgrenzen und Fehlerszenarien zu beantworten. Anstatt erst während der Tests unter realen Bedingungen festzustellen, dass eine Payment-API keinen Fallback-Mechanismus besitzt, entwirft das Team den Recovery-Flow bereits während des Modellierungsworkshops. Dieser proaktive Ansatz stellt sicher, dass die resultierende Architektur den realen betrieblichen Anforderungen entspricht.
Event Storming: Den Ablauf visualisieren
Event Storming ist eine der leistungsstärksten Techniken im Werkzeugkasten des Collaborative Modeling. Entwickelt von Alberto Brandolini, handelt es sich um einen schnellen Modellierungsworkshop, bei dem Haftnotizen auf einer riesigen Wand verwendet werden, um einen Geschäftsprozess abzubilden. Der Workshop ist hochgradig interaktiv und erfordert die aktive Teilnahme sowohl von technischen Experten als auch von Fachexperten.
Der Prozess beginnt mit orangefarbenen Haftnotizen, die Domain Events darstellen. Ein Domain Event ist ein Ereignis von Bedeutung, das bereits in der Business-Domäne stattgefunden hat, geschrieben in der Vergangenheitsform. Beispiele sind OrderPlaced oder InvoiceGenerated. Die Teilnehmer platzieren diese Ereignisse chronologisch von links nach rechts an der Wand.
Als Nächstes identifiziert das Team die Commands (blaue Haftnotizen), die diese Ereignisse auslösen. A Command repräsentiert eine Benutzeraktion oder einen System-Trigger, wie SubmitOrder oder ProcessPayment. Durch die Verknüpfung von Commands mit Events bildet das Team die kausalen Zusammenhänge innerhalb des Systems ab. Schließlich identifizieren sie die Aggregates (gelbe Haftnotizen), die Business-Regeln durchsetzen und den Zustand verwalten.
Event Storming ist ein kollaboratives Workshop-Format, das sich hervorragend eignet, um Silos aufzubrechen. In einem typischen Unternehmen agieren Vertrieb, Lagerhaltung, Buchhaltung und Versand oft als unabhängige Königreiche. Jeder Bereich hat eigene Ziele und Sichtweisen. Event Storming zwingt sie dazu, sich an einen Tisch zu setzen und eine Zeitleiste des gesamten Geschäftsablaufs zu erstellen. Diese visuelle Darstellung ermöglicht es den Teilnehmern zu sehen, wie sich ihre Aktionen auf nachgelagerte Prozesse auswirken, und verdeutlicht die systemischen Auswirkungen ihrer lokalen Abläufe.
Die physische Natur des Workshops ist entscheidend. Indem die Teilnehmer vor einer breiten Papierwand stehen, nehmen sie an einer haptischen, kinästhetischen Aktivität teil, die das kreative Denken anregt. Meinungsverschiedenheiten werden direkt an der Wand gelöst, nicht in endlosen E-Mail-Verläufen. Wenn sich zwei Abteilungen über die Reihenfolge von Ereignissen uneinig sind, können sie die Haftnotizen einfach umordnen, um verschiedene Abläufe zu testen. Dieser interaktive Prozess schafft einen sicheren Raum für Experimente, was zu einer besseren Abstimmung der Architektur führt.
Domain Storytelling: Die Geschäftslogik erzählen
Eine weitere wertvolle Methode ist Domain Storytelling, das sich darauf konzentriert, wie Menschen und Softwaresysteme interagieren. In diesen Sessions zeichnet ein Moderator eine von Fachexperten erzählte Geschichte mithilfe eines einfachen, standardisierten Satzes von Piktogrammen auf. Diese Piktogramme repräsentieren Akteure, Arbeitsgegenstände (Work Objects) und Aktivitäten.
Beispielsweise könnte eine Geschichte zeigen: „Der Sachbearbeiter (Akteur) gibt die Bestelldaten (Arbeitsgegenstand) in das ERP-System (System) ein.“ Dieses visuelle Narrativ wird live gezeichnet, sodass jeder die Abfolge der Aktionen sehen kann. Es fungiert als Brücke zwischen dem Business-Workflow und der technischen Architektur.
Domain Storytelling setzt auf einen kooperativen Ansatz, bei dem die Geschichte in Echtzeit aufgezeichnet wird. Die visuelle Feedbackschleife ist unmittelbar. Wenn der Moderator eine falsche Linie vom Kunden zum Lagermitarbeiter zeichnet, kann der Fachexpert dies sofort korrigieren: „Nein, der Kunde spricht nie direkt mit dem Lagermitarbeiter, das läuft immer über das automatische Dispositionssystem.“ Diese Korrektur erfolgt in Sekundenschnelle und spart Tage potenziell fehlgeleiteter Entwicklung.
Darüber hinaus sind diese visuellen Geschichten auch für nicht-technische Stakeholder leicht verständlich. Während ein Entwickler ein komplexes UML-Aktivitätsdiagramm oder ein BPMN-Diagramm interpretieren kann, wirken diese auf einen Business-Stakeholder oft verwirrend. Domain Storytelling nutzt einfache Symbole und Pfeile, die jeder lesen kann. Diese Transparenz entmystifiziert den Software-Design-Prozess und fördert das Vertrauen und die Zusammenarbeit zwischen Fachbereich und IT-Team.
Domain Roleplay: Den Code schauspielern
Stefan Priebsch plädiert nachdrücklich für Domain Roleplay, um Softwaremodelle auf Herz und Nieren zu prüfen. Bei diesem Ansatz spielen die Workshop-Teilnehmer die Ausführung der Software nach. Jede Person übernimmt die Rolle einer bestimmten Systemkomponente, eines Benutzers oder eines externen Services.
Beispielsweise könnte ein Entwickler das Aggregat Order spielen, während ein anderer das Payment-Gateway verkörpert. Sie reichen physische Karteikarten, die Daten-Payloads darstellen, hin und her, um die Kommunikation zu simulieren. Dieses Rollenspiel erweckt das System auf eine Weise zum Leben, wie es statische UML-Diagramme niemals könnten.
Das Durchspielen des Systems deckt sofort Kommunikationsengpässe und fehlende Parameter auf. Wenn der Akteur „Payment Gateway“ eine Karteikarte erhält, aber feststellt, dass die Rechnungsadresse fehlt, muss er den Akteur „Customer“ nach diesen Daten fragen. Dies weist auf eine fehlende Eigenschaft im Datenmodell hin. Durch das Durchspielen verschiedener Fehlerszenarien verfeinert das Team das Systemdesign in Echtzeit.
Ein konkretes Beispiel: Das Order-Fulfillment-System
Betrachten wir ein konkretes Szenario, das ein E-Commerce-Order-Fulfillment-System betrifft. Ein Großhändler möchte seinen Versandprozess automatisieren, um ein hohes Bestellvolumen abzuwickeln. Während eines Domain-Roleplay-Workshops simuliert das Team den Ablauf von der Bestellung bis zum Versand.
Am Rollenspiel sind drei Akteure beteiligt: der Customer, das Payment Gateway und der Warehouse Clerk. Der Entwickler, der den Warehouse Clerk spielt, sagt: „Ich sehe die Bestellung auf meinem Bildschirm, also drucke ich das Versandetikett, packe den Karton und versende ihn.“ Der Stakeholder, der das Payment Gateway verkörpert, stoppt ihn: „Halt! Die Kreditkarte des Kunden wurde abgelehnt. Warum haben Sie die Bestellung versandt?“
Diese Interaktion deckt einen kritischen Fehler im ursprünglichen Design auf. Das System hätte es dem Lagerpersonal fast ermöglicht, unbezahlte Bestellungen zu versenden. Um dies zu beheben, vereinbart das Team, dass die State Machine der Klasse Order das Fulfillment so lange verhindern muss, bis ein PaymentCleared-Event ausgelöst wurde. Die folgende TypeScript-Implementierung zeigt, wie diese Domänenlogik direkt in sauberen Code übersetzt wird.
export interface DomainEvent {
occurredAt: Date;
}
export class OrderPlaced implements DomainEvent {
constructor(public readonly orderId: string, public readonly occurredAt: Date = new Date()) {}
}
export class PaymentCleared implements DomainEvent {
constructor(public readonly orderId: string, public readonly amount: number, public readonly occurredAt: Date = new Date()) {}
}
export class OrderFulfillmentReserved implements DomainEvent {
constructor(public readonly orderId: string, public readonly occurredAt: Date = new Date()) {}
}
export type OrderState = 'Draft' | 'Placed' | 'Paid' | 'FulfillmentReserved' | 'Shipped';
export class Order {
private state: OrderState = 'Draft';
private events: DomainEvent[] = [];
constructor(public readonly id: string) {}
public getEvents(): DomainEvent[] {
return [...this.events];
}
public clearEvents(): void {
this.events = [];
}
public place(): void {
if (this.state !== 'Draft') {
throw new Error("Order can only be placed from Draft state.");
}
this.state = 'Placed';
this.events.push(new OrderPlaced(this.id));
}
public recordPayment(amount: number): void {
if (this.state !== 'Placed') {
throw new Error("Payment can only be recorded for a Placed order.");
}
this.state = 'Paid';
this.events.push(new PaymentCleared(this.id, amount));
}
public reserveFulfillment(): void {
// The roleplay workshop revealed that fulfillment MUST check the state is Paid.
if (this.state !== 'Paid') {
throw new Error(`Cannot reserve fulfillment. Current order state is '${this.state}', expected 'Paid'.`);
}
this.state = 'FulfillmentReserved';
this.events.push(new OrderFulfillmentReserved(this.id));
}
public getCurrentState(): OrderState {
return this.state;
}
}
In diesem Code bildet die Klasse Order den Lebenszyklus einer Bestellung ab. Die Zustandsübergänge (State Transitions) werden streng durch Domänenregeln gesteuert. Beispielsweise prüft die Methode reserveFulfillment vor dem Übergang, ob der Status der Bestellung „Paid“ ist. Versucht ein Entwickler, eine unbezahlte Bestellung auszuführen (Fulfillment), wird eine Exception geworfen, was die im Rollenspiel entdeckte Business-Regel erzwingt. Dies übersetzt die PaymentCleared-Logik direkt in unsere Architektur.
Durch die Verwendung von Domain Events wie OrderPlaced und PaymentCleared kann das System problemlos asynchrone nachgelagerte Workflows auslösen. Wird beispielsweise ein PaymentCleared-Event veröffentlicht, triggert dies den Bestandsdienst im Lager, um die Artikel zu reservieren. Diese entkoppelte Architektur ist sauber, hochgradig skalierbar und entspricht dem realen asynchronen Ablauf, der in den kollaborativen Sessions modelliert wurde.
Technische und geschäftliche Vorteile in Zahlen
Der Einsatz von Collaborative Software Modeling bietet messbare finanzielle Vorteile. Bei einem typischen Softwareprojekt machen Nachbesserungen (Rework) seitens der Entwickler 30 % bis 50 % des Gesamtbudgets aus. Diese Nacharbeiten werden fast ausschließlich durch Missverständnisse bei den Geschäftsanforderungen verursacht. Durch eine frühzeitige Investition in Collaborative Modeling können Unternehmen diesen Rework-Anteil auf unter 5 % senken und den Entwicklungszeitraum erheblich verkürzen.
Werfen wir einen Blick auf die finanziellen Auswirkungen. Betrachten wir ein Projekt mit einem Team von vier Entwicklern, einem Stundensatz von 120 USD und einer Laufzeit von 6 Monaten (ca. 4.000 abrechenbare Stunden). Ein typischer Projektverlauf mit traditioneller Anforderungsdokumentation könnte so aussehen:
- Traditioneller Spezifikationspfad: Kein Collaborative Modeling. Entwickler bauen das System auf Basis von Textdateien. Im 4. Monat bemerkt das Business-Team, dass die Inventarlogik fehlerhaft ist. Das Refactoring der Kerndatenstruktur dauert 4 Wochen und kostet 76.800 USD an unerwarteten Entwicklungsstunden.
- Kollaborativer Modellierungspfad: Das Team verbringt 3 Tage mit Event Storming und Roleplay-Workshops, was 11.520 USD kostet (inklusive der Zeit der Fachexperten). Die Edge Cases im Inventar werden an Tag 2 identifiziert. Das System wird von Tag 1 an korrekt entworfen, was zu null größeren Refactoring-Kosten führt.
Über die direkte Einsparung von Entwicklerstunden hinaus minimiert Collaborative Modeling die versteckten Kosten von Projektverzögerungen. Wenn sich der Start eines Softwareprojekts aufgrund von Anforderungs-Rework um drei Monate verzögert, verliert das Unternehmen die Möglichkeit, Umsätze zu generieren oder betriebliche Effizienzgewinne zu realisieren. Bei einer Plattform, die zur Automatisierung eines manuellen Abrechnungsprozesses entwickelt wurde, könnte eine dreimonatige Verzögerung 50.000 USD an unnötigen Verwaltungskosten bedeuten. Collaborative Modeling stellt sicher, dass Projekte im Zeitplan starten, indem es Architektur-Redesigns in späten Phasen eliminiert.
Zudem sind die Vorteile für die Codequalität erheblich. Wenn Entwickler ein klares, visuelles Modell der Domäne haben, schreiben sie modularen, kohäsiven Code. Sie müssen keine unsauberen Workarounds einbauen, um Regeln zu berücksichtigen, von denen sie zuvor nichts wussten. Dieser saubere Code ist einfacher zu warten und zu erweitern, was die langfristigen Gesamtbetriebskosten (Total Cost of Ownership, TCO) des Software-Assets senkt. Langfristig zahlt sich die kleine Anfangsinvestition in kollaborative Workshops über Jahre hinweg aus.
Wenn Sie beispielsweise komplexe Systeme für mehrere Stakeholder konzipieren – ähnlich wie wir Anforderungen bei der Entwicklung von Lösungen wie in Wie die Deutsche Bahn maßgeschneiderte Mobile-App-KI-Integrationsszenarien nutzt, um die Echtzeit-Fahrgastkommunikation zu lösen analysiert haben – hilft die visuelle Modellierung dabei, die Lücke zwischen technischen Teams und operativem Personal zu schließen. Dies stellt sicher, dass jeder Stakeholder, vom Tech Lead bis zum Business-Executive, den genauen Umfang und das Verhalten des Systems versteht, bevor die Entwicklung beginnt.
Praxisnahe Best Practices für Ihr nächstes Projekt
Wenn Sie planen, Collaborative Modeling in Ihrem Unternehmen einzuführen, befolgen Sie diese praxisnahen Best Practices, um die Effektivität Ihres Workshops zu maximieren:
-
Etablieren Sie eine Ubiquitous Language: Erstellen Sie ein gemeinsames Glossar, bevor Sie mit dem Mapping beginnen. Stellen Sie sicher, dass Begriffe wie „Customer“, „Order“ und „Transaction“ eine einzige, vereinbarte Definition haben. Erlauben Sie Entwicklern nicht, diese Konzepte im Code umzubenennen. Wenn das Business es „Consignment“ nennt, muss die Softwareklasse auch
Consignmentheißen. -
Bringen Sie die richtigen Leute in einen Raum: Eine Modellierungs-Session ist nutzlos ohne die Fachexperten, die die eigentliche Arbeit erledigen. Sie benötigen Product Owner, Fachexperten, Entwickler und QA-Ingenieure im selben Raum. Lassen Sie die Anforderungen nicht durch Vermittler übersetzen. Direkte Kommunikation ist der einzige Weg, um Informationsverlust zu vermeiden.
-
Fokussieren Sie sich zuerst auf Events und Commands: Wenn Sie einen Prozess modellieren, beginnen Sie nicht mit dem Datenbankschema oder dem User Interface. Starten Sie mit dem, was im System passiert (Events), und dem, was diese Ereignisse auslöst (Commands). Dieser funktionale Fokus verhindert, dass sich das Team in Implementierungsdetails wie CSS-Styling oder Datenbankindizes verliert.
-
Prüfen Sie das Modell durch Rollenspiele: Sobald Sie ein Entwurfsmodell haben, spielen Sie es durch. Lassen Sie einen Entwickler einen Systemzustand verkörpern und einen Fachexperten einen Benutzer spielen. Gehen Sie den „Happy Path“ und mindestens drei Fehlerszenarien durch, wie etwa einen Zahlungsausfall oder einen ausverkauften Artikel. Diese interaktive Simulation wird versteckte Annahmen und Designfehler schnell aufdecken.
Professionelle Umsetzung: Partnerschaft für den Erfolg
Die interne Einführung von Collaborative Software Modeling kann eine Herausforderung sein, insbesondere wenn Ihr Team an traditionelle Wasserfall-Spezifikationen gewöhnt ist. Es erfordert Moderationskompetenz (Facilitation Skills), um die Diskussionen fokussiert zu halten und zu verhindern, dass Meetings in technische Debatten ausarten. Darüber hinaus erfordert die Entwicklung komplexer Software, mobiler Apps oder maßgeschneiderter KI-Integrationen die Übersetzung dieser Modelle in robuste Code-Architekturen.
Hier macht ein erfahrener Entwicklungspartner den Unterschied. ProjectMakers ist auf individuelle Softwareentwicklung, mobile Apps und Game Development unter Verwendung agiler Methoden spezialisiert. Durch die Nutzung von Domain-Driven Design und kollaborativem Prototyping stellen wir sicher, dass Ihre Software von Anfang an richtig gebaut wird, was Sie vor teurem Re-Engineering im weiteren Verlauf bewahrt.
Die Entwicklung individueller Software sollte sich nicht wie ein Glücksspiel anfühlen. Eine Partnerschaft mit ProjectMakers bedeutet, dass Sie ein Team an Ihrer Seite haben, das den geschäftlichen Nutzen, klare Kommunikation und eine saubere Architektur in den Vordergrund stellt. Wir helfen Ihnen dabei, Ihre digitalen Produkte ohne die typischen Projektreibungen zu konzipieren, zu validieren und zu entwickeln.
Planen Sie ein Software- oder KI-Projekt? Nehmen Sie Kontakt mit ProjectMakers auf für ein kostenloses Erstgespräch.
Quelle: heise meets … „Diskutiere nie etwas Unsichtbares“ beim Modellieren