Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.


Der Architekturentwurf war lange Zeit eine wichtige Aufgabe, der sich Moritz in einer langen Reihe von Projekten für individuelle Software-Produkte in großen Unternehmen gestellt hat. Zu Beginn als Entwickler hat er sich wie seine Kollegen gerne über die Software-Architekten beschwert, weil sie zu viele Vorschriften machten. Später, nun selbst in der Rolle des Software-Architekten, hat Moritz sich über die unternehmensweiten Vorgaben beschwert, weil die sogenannten Baupläne oder Referenzarchitekturen aus dem zentralen Architektur-Management nie wirklich passten oder mittlerweile veraltete Werkzeuge oder bestimmte Software-Produkte vorschrieben. In manchen Fällen kämpfte er zusammen mit Entwicklern für eine vom Unternehmensstandard abweichende Lösung, die in der Regel von der Betriebsorganisation oder vom Gremium der Chef-Architekten genehmigt werden musste. Oft aber stand der zeitliche Aufwand in keinem Verhältnis zum erzielbaren Effekt. Das Software-Produkt wurde dann auf der offensichtlich bestenfalls zweitbesten technologischen Basis realisiert.

Dann wurde agile Software-Entwicklung auch in großen Unternehmen “en vogue”. Moritz war schnell überzeugt von der Wirksamkeit der Methode Scrum. Dann lernte er die Realität in den großen Unternehmen kennen. Projekte hatten zwar eine agile Software-Entwicklung, aber Auftraggeber bzw. Fachabteilungen und Betriebsorganisation waren immer noch die gleichen wie vor der agilen Revolution. Agile Software-Entwicklung wurde häufig gleich von Anfang an mit mehreren Teams gestartet. Der Vorschlag, organisch zu wachsen und erst einmal mit einem Team zu starten wurde abgeschmettert: « Ein Team allein schafft das niemals. » oder « Wir müssen schnell erste Ergebnisse liefern. » waren beliebte Begründungen.

Diese Gedanken macht sich Moritz, als er sich überlegt, wie er seine Rolle als Product-Owner und Software-Experte in Personalunion für den Reise-Butler anlegen soll. Er möchte auf jeden Fall genug Spielraum für kreative Lösungen im Team geben. Es ist ihm völlig klar, dass sich seine eigenen Projekte in den großen Unternehmen nicht mit diesem Hochschulprojekt vergleichen lassen. Nicht in der Komplexität, weil das erstes Ziel die Ausbildung der Studenten ist. Auch nicht in der Kritikalität, weil noch niemand einen wirtschaftlicher Erfolg erwartet.

Moritz entscheidet sich gegen ARC42, obwohl er es als ein durchaus praktisches und pragmatisches Template zur Entwicklung, Dokumentation und Kommunikation einer Software-Architektur kennengelernt hat. – Der Enterprise Architecture Standard TOGAF® erscheint ihm viel zu komplex und der Guide to the Software Engineering Body of Knowledge zu akademisch. Er entscheidet sich auch hier für CARDS+. Er schätzt die Einfachheit des agilen Ansatzes auch beim Architekturentwurf. Er mag die Idee, die Dokumentation der Systemstruktur auf die Bausteine Domain, Service, Event und Entity zu beschränken. Die Begriffe sind ihm noch von Eric Evan’s Buch über Domain Driven Design bekannt. Er glaubt an den Leitspruch, dass eine Software-Architektur die Summe wichtiger Entscheidungen ist. Mit dem Baustein Decision dokumentiert er angemessen jede Entscheidung mit allen betrachteten Optionen und einer Begründung. Den individuellen Einsatz von Fremdprodukten oder wiederkehrende Lösungen erfasst er mit dem Baustein Spec. Am meisten hat ihn aber überzeugt, dass ein wesentliches Ziel von CARDS+ die Vermeidung von expliziter Dokumentation ist, weil Code, code-nahe Artefakte, Testfälle und Konfigurationen als Teil der Dokumentation akzeptiert werden. Testgetriebene Entwicklung erhält dadurch sofort einen noch höheren Wert.

Zu Beginn des Projektes hat Moritz bereits erste wichtige Entscheidungen dokumentiert, die ganz wesentlich die Bildung des Teams beeinflusst haben. Die Wahl der Programmiersprache und die Einschränkung auf Android. Die nächsten wichtigen Entscheidungen beeinflussen die Kosten: Werkzeuge für die Entwicklungsumgebung und der Betrieb. Einige Entscheidungen will er dem Team komplett überlassen, mit einer wichtigen Randbedingung: Keine Lizenzkosten. Die Entscheidung, wie technische Komponenten in der Produktion betrieben werden, kann und will er auf keinem Fall alleine dem Team überlassen. Er sieht sich in seinen beiden Rollen als Product-Owner und Software-Experte in der Pflicht, aktiv einen Vorschlag zu machen. Sein erster Schritt: Der Entwurf eines groben Überblicks über die Komponenten des IT-Systems Reise-Butler.

Zuletzt veröffentlichte Beiträge: