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


Bei der nächsten Gelegenheit trifft Moritz sich mit dem Team. Der einzige Punkt auf der Agenda für diesen Tag ist der Entwurf eines Überblicks über alle Komponenten und Datenflüsse. Moritz hat wieder sein Flipchart aufgestellt. Er hat sich vorbereitet, möchte aber das Bild gemeinsam entwickeln.

« Wie sehen die wichtigsten Komponenten und Datenflüsse des IT-Systems Reise-Butler aus? », fragt Moritz. Er ruft sich und dem Team in Erinnerung, was sie bereits festgelegt haben: « Aus Sicht des Nutzers ist es eine einfache Smartphone-App. »

Er malt einen Kasten und schreibt Smartphone auf. « Wir wollen eine App, die den Nutzer auf seiner Reise begleitet, ihn unterstützt. », erklärt er und malt zwei Quadrate und beschriftet sie mit Nutzer und Reise. Zusätzlich malt er noch kleine Datenbanksymbole in die Kästen: “Dort liegen die Daten des Nutzers und die Reisedaten. »

Zuletzt malt er einen großen Kasten mit Datenbanksymbol und der Überschrift Daten. Er sagt: « Hier liegt das Wissen des Reise-Butlers aus dem Internet oder von Datendrehscheiben. »

Wie kleine Zähne mal er dann noch eine ganze Reihe schmaler Rechtecke auf. Sie repräsentieren die vielen unterschiedlichen Anbindungen an die Datenquellen aus der Recherche zum Topic Reisewissen.

Jetzt möchte Moritz Datenflüsse in das Bild eintragen. Er erklärt zuerst die Symbole. Zur Auswahl stehen eine synchrone Kopplung, also REST oder der Zugriff auf eine Datenbank, und eine asynchrone Kopplung mit Events. Moritz schlägt vor, die Komponenten als Microservice zu realisieren. Danach führen sie noch eine kurze Diskussion über das Konzept Microservice im Allgemeinen. Eine zentrale Datenbank schließt Moritz kategorisch aus.

Bei einem weiteren Punkt sind sie sich schnell einig. Für die Nutzerverwaltung, also Laden und Speichern des Profils und der Einstellungen, wollen sie ein einfaches REST-API verwenden. Beim Start der App werden die Reisedaten geladen. Auch dafür wollen sie ein REST-API. Eine Aktualisierung der Reise soll ähnlich wie bei einer E-Mail-App gelöst werden. Per Event zeigt die App dem Nutzer an, dass es Änderungen in den Reisedaten gibt, geladen werden sie aber via REST. Der Fahrtverlauf soll aber nur mit Events übertragen werden. Bei der Versorgung der App mit den Daten sind sie lange uneins. Am Ende setzt sich die Idee durch, das Reisewissen zeitlich und örtlich so aufzubereiten, dass es passend zum Fahrtverlauf während der Reise kontinuierlich und event-getrieben und so aktuell wie möglich gesammelt, aber per REST-API an die App übertragen wird. Moritz fordert und fördert die Idee, weil er die lose Kopplung durch event-getriebene Verarbeitung am Server als ganz wesentliche Erleichterung für die agile Software-Entwicklung sieht.

Dann hat Tim noch einen echten Geistesblitz: « Jedes Smartphone kennt die Position des Reisenden durch die Standortdienste mehr oder weniger genau. Durch die App wissen wir, in welchem Verkehrsmittel der Nutzer ist. So ist das Smartphone jedes Nutzers der App gleichzeitig eine Datenquelle für den Verlauf einer bestimmten Fahrt. »

Moritz zeichnet sofort diese spannende Verbindung ein.

Zum Abschluss macht Moritz noch eine Abstimmung über die logische Einteilung der Komponenten in drei Schichten. Er schreibt seine Vorschläge auf: Frontend, Assistenz und Backend. Anne fügt noch die Begriffe Client und Server hinzu. Richard reklamiert den Begriff App als Alternative zu Frontend oder Client. Eine kurze Diskussion und eine schnell durchgeführte Abstimmung bringen ein klares Ergebnis.

Zufrieden mit dem Ergebnis gibt Moritz bekannt, dass sie nächste Woche die wichtigsten Informationsobjekte besprechen werden. Das Ziel: Ein Fachklassenmodell.

Zuletzt veröffentlichte Beiträge: