Herausforderung Brownfield, Teil 4: Komplexität bewältigen durch Differenzierung
Seite 2: Spezialisierte Frontends
Spezialisierte Frontends differenzieren die User Experience
Wie viele Frontends braucht eine Anwendung? Das kommt darauf an. Wenn die Anwendung auf unterschiedlichen Geräten laufen soll, ist für jedes Gerät ein Frontend zu entwickeln, etwa eines fürs Web, eines für den PDA, eines für den Desktop. Hat jemand entschieden, dass geräteübergreifend nur ein Browser-Frontend zu benutzen ist? "One size fits all", ist ja oft die Devise bei Devices. Auf die Frage, wie viele Frontends eine Anwendung pro Gerät braucht, wenn schon nicht "One size fits all", lautet die Antwort meist eins. Ein Frontend, ein Programm pro Gerät, alles möglichst einheitlich, ist dann die Maxime in vielen Projekten. Und damit läuft die Code-Presse.
Wie anders könnte es sein, wenn die Gleichung etwa lauten würde: "Ein Frontend pro Anwenderrolle" ist eine zu erwägende Alternative. Die könnte für eine simple Fakturaanwendung bedeuten, dass es ein Frontend für die Rechnungslegung inklusive Gutschriften gibt, eines für das Mahnwesen, ein anderes für den Zahlungseingang, noch eines für die Umsatzsteuervoranmeldung, eines für den Datenexport und schließlich noch eines für zumindest einfache Auswertungen. Sechs Frontends statt einem, womit nicht sechs GUI-Fenster gemeint sind, sondern sechs Programme, Icons auf dem Desktop, EXE-Dateien unter Windows und Visual-Studio-Projektmappen.
Durch rollenspezifische Frontends partitioniert man den Umgang mit einem Datenmodell. Jede Partition ist ein schmaler Durchstich von der Benutzerschnittstelle durch die Domänenlogik bis zum Datenzugriff.
Denkt man in Partitionen, bekommt man auch "Verhandlungsmasse" für das agile Vorgehen. Als Durchstiche sind Partitionen anwenderrelevant, das heißt, selbst wenn man die Entwicklungsaktionen auf nur eine Partition beschränkt, bekommt der Kunde einen Wert. Er kann sogar priorisieren und sagen: "Ich hätte gern, dass Sie zuerst Rechnungslegung und Zahlungseingang realisieren."
Solch partitionsbezogene Priorisierung fokussiert die Anstrengungen. Für einen Moment (zum Beispiel einen Sprint) schrumpft die Anwendung auf die Partition und wird viel überschaubarer. Es gibt keinen Zwang, partitionsübergreifend Code wiederzuverwenden (auch wenn sich das beispielsweise für den Datenzugriff anbietet). Wenn man plant, sollte man ein BDUF (Big Design Up Front) vermeiden. Darüber hinaus sind Partitionen geeignet, Anwender zufrieden zu stellen. Denn wenn man nicht mehr alle Rollen durch das eine Frontend zwängt, lässt sich jeder Rolle eine hochspezialisierte, optimale Benutzerschnittstelle zuweisen. Anwender mögen das, weil solche Benutzerschnittstellen sie effizienter machen und weil sie daran ablesen, dass der Entwickler sich wirklich bemüht, ihre Domäne zu verstehen. Das ist Wertschätzung, die später über so manchen Bug-Frust hinweg hilft.
Partitionen sind von sich aus nicht weiter gefeit gegen Kräfte, die ihren Code zu einem Brownfield zusammenpressen. Dagegen muss Architektur Widerstand leisten – davon aber im nächsten Artikel mehr. Hinsichtlich der Gesamtanwendung ist die Partitionierung hingegen ein Brownfield-Gegengewicht. Code, der auf Partitionen verteilt ist, kann nicht "verklumpen".
Mit der Partitionierung der Anwendungen kann man jederzeit beginnen. Sie bezieht sich nur auf den Code. Am Ende ist der Effekt, so gut er sein mag, begrenzt. Auf Partitionen lastet ja immer noch der Druck des einen Datenmodells, das sich alle teilen. Man sollte daher über Partitionen hinaus denken und die Anforderungen noch grundsätzlicher hinterfragen.
