Business im Driver Seat
Applikationsentwicklung mit herkömmlichen Methoden ist langwierig, teuer und häufig erfolglos. Die Branche entwickelt Software immer noch mit mittelalterlichen Methoden. Deshalb sind die Resultate vieler Softwareprojekte unbefriedigend. Das muss nicht sein!
Die Methodik Business-Driven Application Development (BDAD) wurde von Quatico erarbeitet und ermöglicht es dem Business, die Applikationsentwicklung zielgenau zu steuern. Fachexperten können die Anforderungen an die Applikation in ihrer Fachsprache beispielhaft formulieren – ohne langwierigen Umweg über Business Analysten oder Requirements Engineers.
Was ist Business-Driven Application Development?
Mit der Methodik "Business-Driven Application Development", oder kurz BDAD, kann das Business die Applikationsentwicklung zielgenau steuern. Die Fachexperten können die Anforderungen an die Applikation in ihrer Fachsprache beispielhaft formulieren. Ohne langwierigen Umweg über Business Analysten oder Requirements Engineers.
Was ist der Unterschied von BDAD zu herkömmlicher Entwicklungsmethodik?
Bei der herkömmlichen Entwicklungsmethodik stehen Fachexperten, Product Owner, Business Analyst, Requirements Engineer, Software Engineer und Tester in ständigem Austausch. Dabei entstehen fortlaufend Übersetzungsfehler – wie beim Buschtelefon. Der gesamte Round Trip vom Product Owner bis zum Tester ist langwierig, aufwändig und wird in der Regel mehrfach durchlaufen.
Herkömmlich:
Fachexperte → Product Owner → Business Analyst → Requirements Engineer →
Software Engineer → Tester → (Rückfragen) → Repeat...
BDAD:
Fachexperte (in Fachsprache) → Ausführbare Spezifikation → Automatisierte Tests →
Continuous Delivery → Wert für Kunden
Dieses herkömmliche Vorgehen ist zu fehlerhaft, zu langsam und zu teuer. BDAD eliminiert die Übersetzungsfehler durch eine gemeinsame Sprache und automatisierte Ausführung.
Auf welchen Grundlagen basiert BDAD? Was ist daran so fortschrittlich?
Unsere Methodik basiert auf einer gemeinsamen Sprache, auf Quality Gates und Automatisierung.
Das Fundament: Eine gemeinsame Sprache
Business und IT erarbeiten ein gemeinsames fachliches Verständnis, ein gemeinsames Vokabular und formulieren fachliche Abläufe in natürlicher Sprache – sogenannte Anwendungsszenarien. Wichtige Anwendungsszenarien formalisieren wir, so dass eine Maschine sie ausführen kann. Et voilà, damit haben wir automatisiert ausführbare Anwendungsszenarien geschaffen. Wir sprechen von «Ausführbaren Spezifikationen».
Technisch Interessierte erkennen vielleicht die Anwendungspraxis "Behavior Driven Development" (BDD). Wir nutzen Gherkin, um Anwendungsszenarien in einer für Menschen und Maschinen verständlichen Sprache zu formulieren:
Szenario: Kunde bestellt Produkt
Gegeben sei ein Kunde mit gültigem Account
Und das Produkt ist verfügbar
Wenn der Kunde das Produkt bestellt
Dann wird eine Bestellung erstellt
Und das Inventar wird aktualisiert
Quality Gates: Automatisierte Tests
Diese automatisiert ausführbaren Anwendungsszenarien sind ein wichtiges Quality Gate. Schon während der Entwicklung erkennen Developers, ob die Applikation die fachlichen Anforderungen noch erfüllt. Mit Hilfe weiterer automatisierter Quality Gates beispielsweise für Design und Sicherheit gewährleisten wir die Qualität der Releases und reduzieren den manuellen Testaufwand auf das notwendige Minimum.
Continuous Delivery: On Demand Releases
Mittels automatisierter Continuous Delivery Pipeline können wir On Demand releasen – falls erwünscht, mehrmals am Tag. So können wir die Kundenbedürfnisse in kurzen Iterationen zielgenau erfüllen. Diese Fähigkeit haben nur wenige Teams entwickelt. Bei uns hat sie Methode.
Inspiration: DDD und BDD
Unsere Methodik ist von Domain-Driven Design (DDD) und Behavior-Driven Development (BDD) inspiriert. Aber kaum jemand hat den Mut und die Kompetenz, die Methodik auf den Boden zu bringen. Quatico hat auf Open Source Technologie ein Opt-in Framework entwickelt, bei dem jedes Zahnrad passgenau in das andere greift. So gelingt es uns, bereits zum Start eines Projekts Wert zu liefern und unser Versprechen einzulösen, in 30 Tagen mit einem MVP live zu gehen.
Welche Vorteile ergeben sich für die Kunden durch Business-Driven Application Development?
Effizienz und Geschwindigkeit
Durch die zielgenaue Steuerung der Applikationsentwicklung sind unsere Teams sehr effizient in der Erfüllung der Kundenwünsche. Wir produzieren vergleichsweise wenig «Waste». Automatisierung ermöglicht uns, in sehr kurzer Zeit sehr viele kleine Schritte zu gehen. Mit jedem kleinen Schritt können wir lernen und die Richtung ein wenig justieren.
Digitales Gold: Ausführbare Spezifikationen
Unsere automatisiert ausführbaren Anwendungsszenarien sind digitales Gold. Im Gegensatz zu Spezifikationen in einem Jira Ticket, die sich wie instantaner digitaler Müll anfühlen. Wir hegen und pflegen die Anwendungsszenarien, die mit jeder Iteration ausgeführt werden und wissen jederzeit, ob die Applikation noch tut, was sie soll.
Konkrete Vorteile
Kurzum: Dank unserem Vorgehen sind unsere Kunden schnell am Markt, sehr beweglich und preiswert unterwegs. Von Quatico entwickelte Software hat eine 90% tiefere Total Cost of Ownership (TCO) als mit herkömmlicher Methodik entwickelte Software. Deshalb sind wir "revolutionär preiswert".
Zusammenfassung der Vorteile:
- Geschwindigkeit: MVP in 30 Tagen möglich
- Kosten: 90% tiefere Total Cost of Ownership (TCO)
- Qualität: Automatisierte Tests gewährleisten Konsistenz
- Beweglichkeit: Schnell am Markt, sehr beweglich
- Effizienz: Wenig "Waste", zielgenaue Erfüllung von Kundenwünschen
Erfahrungsbericht: ewz Kundenportal
Ein konkretes Beispiel für die erfolgreiche Anwendung von BDAD ist das Kundenportal für das Elektrizitätswerk der Stadt Zürich (ewz).
Projekt-Kontext
Das ewz Kundenportal ist ein komplexes System, das verschiedene Business-Prozesse abbildet und mit Legacy-Systemen wie SAP sowie externen Systemen kommunizieren muss. Die Herausforderungen waren vielfältig: komplexe Business-Prozesse, Legacy-Systeme, Datenaustausch zwischen verschiedenen Systemen und die Notwendigkeit, schnell am Markt zu sein.
Methodik: Event Storming zur MVP-Definition
Zu Beginn des Projekts führten wir ein Event Storming durch, um das MVP zu definieren. Gemeinsam mit den Fachexperten identifizierten wir die wichtigsten Domain Events und erarbeiteten eine gemeinsame Sprache. Diese gemeinsame Sprache wurde im gesamten Team verwendet – von den Fachexperten bis zu den Entwicklern.
Erfolgsfaktoren
Vertrauen war die Basis für die erfolgreiche Zusammenarbeit. Wir haben uns das Vertrauen unserer Kunden erarbeitet und sie vertrauen darauf, dass wir allfällige Fehler schnell korrigieren können, wenn's mal brenzlig wird.
Iterative Entwicklung ermöglichte es, schnell zu lernen und die Richtung anzupassen. Mit jedem kleinen Schritt konnten wir Feedback sammeln und die Applikation entsprechend anpassen.
Automatisierte Tests gewährleisteten, dass die Applikation jederzeit das tut, was sie soll. Die ausführbaren Spezifikationen wurden mit jeder Iteration ausgeführt und dienten als wichtiges Quality Gate.
Learnings
Das Projekt zeigte die Bedeutung von Vertrauen, Onboarding neuer Teammitglieder und agiler Flexibilität. Neue Teammitglieder konnten schnell on-boarded werden, da die gemeinsame Sprache und die ausführbaren Spezifikationen das Verständnis erleichterten.
Welche sind die Erfolgsfaktoren für das Gelingen?
Konsequenz
Neben der handwerklichen Kompetenz braucht es eine gehörige Portion Hartnäckigkeit, um die Methodik auf den Boden zu bringen. BDAD erfordert Disziplin und Konsequenz in der Anwendung.
Mut
Wenn man schnell im Markt lernen will, braucht es zudem Mut, mit unfertiger Funktionalität zu experimentieren. Nicht alle fühlen sich wohl mit Wind im Haar. Aber genau diese Bereitschaft, früh zu experimentieren und zu lernen, ermöglicht es, schnell am Markt zu sein.
Vertrauen
Vertrauen ist die Basis. Wir haben uns das Vertrauen unserer Kunden erarbeitet und sie vertrauen darauf, dass wir allfällige Fehler schnell korrigieren können, wenn's mal brenzlig wird.
Ist die konkrete Formulierung von Anwendungsszenarien nicht anstrengend und fordernd für die Kunden?
Ja und Nein. Wir gehen ja nicht zu den Kunden und sagen: "So, jetzt gebt uns mal eure Key Success Use Cases und formuliert die automatisiert ausführbaren Anwendungsszenarien." Wir leiten die Kunden durch Workshops, machen die Knochenarbeit erst mal selbst und führen die Kunden langsam in die Praxis ein.
Mit den ersten Erfolgen wachsen das Interesse und die Bereitschaft, die gemeinsame Sprache und die Anwendungsszenarien mitzuprägen. Wenn unsere Kunden erlebt haben, was für einen Rennboliden sie fahren, dann wollen sie gar nicht mehr vom Fahrersitz weichen.
Ist eure Methodik für jedes Projekt geeignet?
Grundsätzlich ja, aber ganz besonders lohnt sich die Methodik für Projekte mit fachlich anspruchsvollen Anforderungen.
Für welche Kunden seid ihr die Richtigen?
- Für Kunden, die sich differenzieren wollen: Kunden, die ihren eigenen Kunden einen modernen digitalen Service bieten wollen
- Für Kunden, die schnell im Markt bewegen müssen: Kunden, die sich schnell im Markt bewegen müssen
- Für Kunden, die digitalisieren wollen: Kunden, die ihr Geschäftsmodell oder einzelne Services digitalisieren wollen
- Für partnerschaftliche Zusammenarbeit: Unsere Kunden wollen von uns herausgefordert und beraten werden. Insofern passen wir zu Kunden, die ein partnerschaftliches Verhältnis auf Augenhöhe suchen
Ist BDAD alter Wein in neuen Schläuchen?
Jetzt mal echt, ist das nicht alter Wein in neuen Schläuchen? DDD und BDD gibt es doch schon seit 20 Jahren.
Es stimmt, unsere Methodik ist von Domain-Driven Design (DDD) und Behavior-Driven Development (BDD) inspiriert. Aber kaum jemand hat den Mut und die Kompetenz, die Methodik auf den Boden zu bringen. Quatico hat auf Open Source Technologie ein Opt-in Framework entwickelt, bei dem jedes Zahnrad passgenau in das andere greift.
So gelingt es uns, bereits zum Start eines Projekts Wert zu liefern und unser Versprechen einzulösen, in 30 Tagen mit einem MVP live zu gehen. BDAD ist keine theoretische Methodik, sondern eine praktisch erprobte und erfolgreich angewendete Vorgehensweise.
Best Practices für BDAD
1. Event Storming durchführen
Ein Workshop mit allen Stakeholdern: Business Experten, Entwickler, Product Owner, Designer. Gemeinsam die Domain Events identifizieren und modellieren.
2. Gemeinsame Sprache pflegen
Ein lebendes Glossar: Was bedeuten Fachbegriffe? Wie heissen Konzepte im Code? Regelmässige Reviews und Pflege der gemeinsamen Sprache.
3. Ausführbare Spezifikationen erstellen
Wichtige Anwendungsszenarien in natürlicher Sprache formulieren und formalisieren, so dass sie automatisiert ausgeführt werden können. Diese Spezifikationen sind digitales Gold und werden mit jeder Iteration ausgeführt.
4. Automatisierte Quality Gates einrichten
Nicht nur funktionale Tests, sondern auch Quality Gates für Design, Sicherheit und Performance. Reduziert den manuellen Testaufwand auf das notwendige Minimum.
5. Iterativ vorgehen
Nicht alles auf einmal: Start mit einem MVP, lernen und anpassen, schrittweise erweitern. Mit jedem kleinen Schritt lernen und die Richtung justieren.
6. Continuous Learning
BDAD ist eine Reise: Regelmässige Retrospektiven, Knowledge Sharing, Community-Austausch. Die Methodik entwickelt sich weiter.
Herausforderungen
Legacy-Systeme
Bestehende Systeme wie SAP oder andere Legacy-Systeme müssen integriert werden. Der Datenaustausch zwischen verschiedenen Systemen kann komplex sein. Schrittweise Refactoring und Parallelbetrieb sind oft notwendig.
Teamstruktur-Veränderungen
Neue Teammitglieder müssen on-boarded werden. Die gemeinsame Sprache und die ausführbaren Spezifikationen helfen dabei, aber es braucht Zeit und Geduld.
Agile Vertragsmodelle
Traditionelle Vertragsmodelle passen nicht immer zu agiler Entwicklung. Agile Vertragsmodelle, die auf Vertrauen und Zusammenarbeit basieren, sind notwendig.
Mindset-Shift
Vom Code-First zu Business-First denken erfordert einen kulturellen Wandel. Nicht alle fühlen sich sofort wohl mit dieser Herangehensweise. Es braucht Zeit und Geduld, um das Team auf diese neue Art des Arbeitens einzustellen.
Fazit
Business-Driven Application Development hat unser Verständnis von Software-Entwicklung verändert. BDAD ist eine von Quatico entwickelte, einzigartige Methodik, die auf DDD und BDD basiert, aber durch ein praktisch erprobtes Framework und konsequente Anwendung zu konkreten Ergebnissen führt:
- Besserer Software: Weil sie tut, was das Business braucht
- Schneller am Markt: MVP in 30 Tagen möglich
- Revolutionär preiswert: 90% tiefere Total Cost of Ownership
- Glücklichere Teams: Weil die Arbeit Sinn ergibt
- Zufriedenere Kunden: Weil ihre Sprache gesprochen wird
Weiterführende Informationen
- Agile Breakfast Zürich: Business Driven Application Development - Ein Erfahrungsbericht - Vortrag vom 2. November 2022 mit Natascha Wloka (Product Owner ewz), Christian Kehl (Project Manager Quatico) und Jan Wloka (CTO Quatico)
Interesse?
Möchten Sie mehr über BDAD erfahren oder ein Projekt mit dieser Methodik starten? Kontaktieren Sie uns! Wir zeigen Ihnen gerne, wie BDAD auch für Ihr Projekt funktionieren kann.
Über die Autor:in
