Wie bekommt man gute Software hin? Es gibt viele Ansätze und Modelle, die man verfolgen kann. Eines ist jedoch klar: „Nicht zu designen bedeutet nicht, dass man dann kein Design hat, sondern dass man dann ein schlechtes Design hat.“ Ich weiß leider nicht mehr, wo ich das gelesen habe, aber es trifft erschreckend häufig zu. Bei allmyhomes haben wir uns deshalb entschieden den Ansatz  „Domain Driven Design“ (DDD) zu verfolgen, im gesamten Unternehmen einzuführen und erfolgreich zu etablieren.

 

Der Begriff „Domain Driven Design“ (DDD) wurde von Erik Evens in seinem gleichnamigen Buch 2003 geprägt. DDD ist eine Herangehensweise an Softwaredesign und ist gerade in aller Munde. Wie so vieles, was gerade in der IT gehypt wird, wird DDD häufig als ein Wundermittel dargestellt. Dementsprechend ist eine kritische Auseinandersetzung mit DDD notwendig. Doch zuerst möchte ich an dieser Stelle eine vereinfachte Version dessen wiedergeben, was DDD verspricht:

 

„Komplexe Probleme des Business sollen mit Zuhilfenahme der Business-Sprache und für jeden Kontext des Businesses so verständlich für die Entwickler werden, dass die Software, die am Ende herauspurzelt, eine Lösung beinhaltet, die die Business-Sprache benutzt und strukturell dieselben Kontextgrenzen aufweist. Dabei bietet Domain Driven Design eine Reihe von Tools und Terminologien, mit denen man Kernprozesse, Kontexte und Abhängigkeiten identifizieren und Softwaredesignentscheidungen aufgrund von realen Businessbedürfnissen treffen kann.“

 

Dabei fällt einem gleich auf, dass man sich hier von lösungsorientierten Ansätzen zu problemorientierten Ansätzen hin bewegt. Oder einfacher gesagt: Die IT bekommt nicht die Anforderung, eine bestimmte Lösung zu implementieren, sondern eine geeignete Lösung für ein bestimmtes Problem zu finden und dann zu implementieren, was eine viel engere Kommunikation zwischen Business und IT voraussetzt.

 

Entscheidet sich ein Unternehmen DDD einzuführen, so müssen die Mitarbeiter einen nicht unerheblichen „Mind Change“ durchmachen. Die IT muss aus ihrem Keller raus und das Business muss von dem Gedanken „IT = Serviceanbieter“ weg.

 

Als sich allmyhomes für DDD entschieden hat, kam diese Entscheidung IT-getrieben, und wie bei vielen neuen Herangehensweisen sind Akzeptanz und Know-How-Transfer die Dinge, die man von Anfang an im Blick haben sollte.

 

Ein guter Weg, um internes Wissen zu teilen und externes zu bekommen, sowie eine Konversation zu starten mit denen, die noch nicht ganz überzeugt sind, sind Meetups. Gute Vorträge helfen, Wissen zu transferieren, und bei einem Getränk und einem Snack lässt es sich gut miteinander quatschen.

 

Am Tag des Meetups wurde es voll, denn das Thema schien Anklang zu finden. Bei 100 Anmeldungen kamen ca. 40 Personen, wobei der Durchschnitt von Anmeldungen zu Teilnehmern bei ca. 30 % liegt. Da auch ca. 20 Mitarbeiter von allmyhomes dazukamen, war auch der letzte Stuhl in unserer schönen Lounge besetzt. Doch dank unserer Organisatoren waren wir mit allem versorgt und konnten uns auf die Vorträge freuen. 

 

Beide Vorträge fanden großen Anklang. Károlys Vortrag war dahingehend besonders, dass er keinen Text, sondern bestimmte Bilder nutzte. Damit konnte man dem Vortrag sehr gut folgen und die Bilder unterstützten das Gesagte. Ich stellte alles unter das Motto Cowboys, denn der Titel war ja an „The Good, The Bad And The Ugly“ angelehnt und unterstrich vieles mit bewegten Bildern. Nach den Vorträgen wurden wir mit Fragen zum Thema gelöchert und es entstanden viele Diskussionen. Es waren nicht nur Entwickler anwesend, denn es mischten sich auch einige POs und Projektmanager unter die Menge.

 

Damit war das Meetup ein voller Erfolg. Bei uns bekam DDD nochmal Aufwind und durch den externen Input gab es den ein oder anderen „Mind Change“. Natürlich ist so ein Meetup kein Garant für eine erfolgreiche Einführung von DDD im Unternehmen, aber wenn es gut durchgeführt wird und man genug Interesse weckt, kann es helfen, die Akzeptanz zu erhöhen und Wissen zu transferieren.