Die Migration einer Software auf eine neue Plattform steht an, und die Machbarkeit soll getestet werden, außerdem sollen die größten technischen Herausforderungen identifiziert werden. Die Entwicklung eines Prototypen ist dafür die beste Methode. Was sollte dazu gehören?

Der Prototyp sollte einen Durchstich durch alle Schichten der Anwendung realisieren, somit etwa das Lesen und Schreiben von Daten, die Businesslogik und die Oberfläche umfassen. Allerdings muss hier genauer hingesehen werden. Wenn z.B. die GUI verschiedene Typen von Funktionen umfasst, sollte jeder Typ im Prototypen repräsentiert sein, Masken ebenso wie die Programmsteuerung und Reports. Das Gleiche gilt für die anderen Schichten der Anwendung.

Der Prototyp soll zeigen, wie die Migration erfolgen kann, und das betrifft zweierlei:

1. Wie wird aus den Architekturzusammenhängen der Altanwendung die Architektur der zukünftigen Anwendung? Wenn die Altanwendung z.B. eine Client-Server-Anwendung ist, die in eine Webumgebung migriert werden soll, dann ist damit zumeist auch eine neue Anwendungsarchitektur verbunden. Ein Prototyp ist also immer auch Architekturprototyp.
2. Wie kann der Code der Altanwendung möglichst systematisch (automatisch oder nach engen Programmierrichtlinien) in die neue Architektur übertragen werden? In der Regel ist das mit einem Refactoring der Businesslogik verbunden. Der Prototy sollte es erlauben, strikte Anweisungen für die “Umarbeitung” einer Anwendungsfunktion auf die neue Plattform zu definieren, oder sogar Codegeneratoren zu konzipieren, die aus dem alten Code den neuen erzeugen – wenigstens zum großen Teil.

Schließlich sollte ein Migrationsprototyp möglichst auch ein Oberflächenprototyp sein. An der Oberfläche muss eine Applikationsmigration immer den größten Spagat vollbringen: Einerseits soll der Anwender die vertrauten Funktionen ohne weiteres intuitiv wiederfinden, andererseits hat er zumeinst auch eine Erwartung, wie eine Anwendung in der neuen Umgebung auszusehen hat. Eine PC-Anwendung hat bestimmte typische Oberflächenelemente, die eine Web-Applikation nicht oder anders implementiert – und umgekehrt. Ein Oberflächenprototyp kann zeigen, wie die vertrauten Elemente sich plausibel in der neuen Umgebung wiederfindenlassen – Migration von Anwendungen ist immer ein bisschen so wie behutsame Fassadensanierung, man möchte modernisieren, aber den vertrauten Charme auch bewahren.

Es gibt viele Gründe, gewachsene Unternehmensanwendungen ins Web zu bringen. Nicht nur die Verfügbarkeit der Anwendungsfunktionen außerhalb des lokalen Netzes spricht dafür. Deployment-Kosten für neue Versionen sinken, Patches und Change Requests können einfacher verteilt werden. Außerdem entsprechen Web-Anwendungen immer mehr den Look&Feel-Erwartungen der Anwender. Schließlich kann durch eine Web-Anwendung die Verfügbarkeit der Funktionalität auf verschiedenen Plattformen bis hin zu mobilen Geräten wie Smartphones und Tablets sicher gestellt werden.

All diese Aspekte können dafür sprechen, auch über Jahre gewachsene Client-Server-Anwendungen in eine Web-Architektur zu überführen. Dazu sind allerdings eine Reihe von Vorüberlegungen nötig. Von einer kompletten Neuprogrammierung ist, auch wenn Ausgangs- und Ziel-Technologien weit auseinander liegen, zumeist abzuraten. Neue Anforderung und neue Technologien  in einem Projekt zu vereinen vergrößert die Gefahr, dass das Projekt zu einem Millionengrab wird und nie zu einem erfolgreichen Ende gebracht wird.

Welcher Ansatz der richtige ist, hängt oft nicht primär von der Technologie der bisherigen Anwendung ab. Ob sie in Visual Basic oder C/C++ oder in Java geschrieben ist, oder ob es sich gar um eine Großrechner-Anwendung handelt, ist zumeist nicht so wichtig wie die Frage, ob die Anwendung eine klare Schichten-und Modul-Architektur hat und ob Entwicklungsstandards während der gesamten Lebenszeit der Anwendung weitgehend eingehalten wurden.

Eine einfache Checkliste kann zu einer ersten Beurteilung eines Software-Migrationsprojekts hilfreich sein. Auf ihrer Basis ist eine Analyse möglich die zeigt, welche Bestandteile ein Durchstich-Prototyp haben sollte, mit dessen Hilfe eine seriöse Kosten- und Zeitschätzung für eine erfolgreiche Migration möglich ist.

Vor einigen Wochen ging es in diesem Blog schon einmal um das Thema, wie gesetzliche Reglungen in Software-Lösungen berücksichtigt werden sollen. Dabei ist ein Aspekt noch nicht zur Sprache gekommen: soll die Software den Anwender dazu zwingen, gesetzliche Reglungen einzuhalten, oder ist er selbst dafür verantwortlich?

Ein Beispiel: In unserer Software SceddyPro werden natürlich auch die Regelungen des Arbeitszeitgesetzes berücksichtigt, und zwar schon in dem Moment, in dem der Benutzer die bevorzugten Schichtmuster vorgibt. Soll die Software nun verbieten, dass Muster definiert werden, in denen die Zeit zwischen zwei Schichten kürzer ist, als nach dem Gesetz erlaubt, oder soll nur eine Warnung angezeigt werden?

Wir haben uns dafür entschieden, dem Benutzer einen Hinweis zu geben, wenn er die gesetzlichen Vorgaben verletzt, ihm jedoch die Entscheidung zu überlassen, ob er streng nach dem Gesetz plant oder nicht.

Die Situation ist mit der eines Autofahrers vergleichbar, dem das Navigationssystem anzeigt, welche maximale Geschwindigkeit zulässig ist. Theoretisch wäre es denkbar, dass das System unmittelbar dafür sorgt, dass diese Vorschrift auch eingehalten wird. Auch wenn eine solche technische Lösung von manchem gewünscht wird, lehnen die meisten Fahrer sie ab. Einerseits trauen wir der Technik nicht zu, für jede Veränderung der konkreten lokalen Verkehrsvorschriften immer die aktuellen Daten ins Auto übertragen zu können, ganz davon abgesehen, dass das Navigationsystem auch Fehler machen kann. Andererseits kann es Ausnahmesituationen geben, in denen wir selbst entscheiden müssen, welche Geschwindigkeit wir fahren müssen.

So ist es auch im Fall einer Personaleinsatzplanungslösung wie SceddyPro. Einerseits ist trotz Softwarewartung und Aktualisierungsservice nicht sicher, ob die Software jeden Fall und jede Veränderung der Regelungen sofort enthalten kann. Andererseits, und das ist noch wichtiger, muss der Planer selbst in jedem Moment entscheiden können, wie er das Personal plant. Für die Einhaltung der Vorschriften ist er verantwortlich, und wie er dieser Verantwortung gerecht wird, muss er auch selbst entscheiden.

Zurück zu obigem Beispiel: ein Mitarbeiter wird für die Spätschicht und die Frühschicht am Tag darauf eingeplant. Die Ruhezeit dazwischen entspricht nicht den Vorschriften.  Der Planer vereinbart mit dem Mitarbeiter deshalb, dass er die Spätschicht etwas früher verlässt und etwas später zur Frühschicht kommt und dann entsprechend länger bleibt. Damit wird die Regelung eingehalten, das aber bei der Planung im System schon zu berücksichtigen, würde einen großen Aufwand bedeuten.

Zumeist ist, so zeigt sich an diesem Bispiel, eine Softwarelösung dann der praktischen Situation am besten angemessen, wenn sie dem Benutzer die Entscheidung über die konkrete Regeleinhaltung überlässt. Denn gearbeitet wird nicht in der Software, sondern am tatsächlichen Arbeitsplatz, und da passiert manches, was sich unsere Softwareweisheit kaum träumen lässt.

Immer häufiger hört man in den Service-Centern von Unternehmen, dass irgend etwas nicht ginge, weil die Software es nicht zulässt. Der Kunde hat einen Wunsch, aber die Software verbietet, dass er erfüllt wird. Er hat noch nicht alle Daten für den Auftrag zusammen. Er will eine spezielle Auskunft haben. Er bittet, eine zusätzliche Telefonnummer zu notieren, die bei der Lieferung gewählt werden soll.

In der Anforderungsanalyse werden die Geschäftsprozesse oft aus Idealsituationen heraus beschrieben, genauer gesagt, es werden die Notwendigkeiten beschrieben, die, wie wir glauben, in der Sache selbst liegen, die Sachzwänge. Um einen Auftrag abarbeiten zu können, benötigt man bestimmte Kundendaten, diese Daten sind in der Datenbank Pflichtfelder. Werden sie nicht gefüllt, dann kann der Auftrag nicht angelegt werden.

Hat also der Kunde eine Detailinformation nicht zur Hand, dann wird die ganze Bestellung nicht ausgelöst. Software macht, wenn sie so programmiert ist, das Leben nicht einfacher, sondern bürokratischer. Online-Portale erscheinen heute oft auf den ersten Blick kundenfreundlich, aber unter der Oberfläche lauert in der Software kein Freund und Helfer, sondern ein Bürokrat.

Softwareentwickler schaffen formale Lösungen für Probleme, die oft formal nicht beschreibbar sind. Nur der Idealfall passt zur Software. Aber damit fordert die Technik, dass die Wirklichkeit sich ihren Idealprozessen anzupassen habe – und eigentlich war es doch umgekehrt gedacht, eigentlich wollten wir Softwarehersteller das Leben doch vereinfachen, statt es durch starre Vorgaben und Zwänge  an die Leine zu nehmen.

Die Alternative besteht nicht einfach in einem schlichten “Weniger Muss – mehr Kann!”. Wir müssen in die Konzeption unserer Lösungen schon ein wenig mehr Nachsichtigkeit mit Anwendern und Betroffenen stecken. Statt simpler Muss-Felder eher Sicherheitshinweise, dass bestimmte Informationen noch gebraucht werden. Genau überlegen, welche Daten zwingend benötigt werden, welche anderen Informationen hingegen nachgeliefert werden können. Größere Notizfelder, die auf Aufträgen und Lieferscheinen auch zu sehen sind. Am Ende haben doch immer lebendige Menschen mit dem Geschäftsprozess zu tun, die können denken und lesen, auf deren Klugheit können wir vertrauen.

Wird die Software auf diese Weise teurer? Das ist nicht so einfach zu beantworten. Eine Standarddatenbankprüfung eines Muss-Feldes mit einer nichts-sagenden Fehlermeldung ist natürlich schnell programmiert, die kann sogar schon im Framework eingebaut sein. Legt man auf mehr Benutzerfreundlichkeit wert, so muss man jeden Fall ohnehin einzeln bedenken, spezifizieren und implementieren. Beachtet man zudem, dass Benutzerzufriedenheit ein wesentliches Qualitätsmerkmal ist, dann ist es in jedem Fall ökonomisch, diese Zufriedenheit und die der anderen Betroffenen im Blick zu behalten. Der höhere Aufwand bei der Anforderungsanalyse zahlt sich am Ende aus.

Es ist jedoch vor allem eine Frage der Sichtweise, die alle Entwicklungsbeteiligten einnehmen: Betrachten wir einen Idealzustand, oder wollen wir die reale Welt der Softwarebenutzer besser gestalten? Wenn man sich bei Designentscheidungen diese Frage immer wieder stellt, dann wird man auch Lösungen finden, welche die Benutzer in realen Situationen nicht beschränken, sondern unterstützen.

Vor dem Siegeszug der Online-Portale war es selbstverständlich: Eine Software wurde auf dem eigenen PC installiert und blieb dann unverändert, bis der Hersteller ein Update ankündigte und der Benutzer sich entschied, dieses zu installieren. Daran orientierte sich auch die Welt der Individual- und Branchenlösungen, und dort ist es im Wesentlichen bis heute so.

Aber die Dinge ändern sich gegenwärtig. Dass sich die Erwartungen der Benutzer von Individualsoftware auch an Standardlösungen orientieren, wenn es um intuitive Bedienbarkeit und die Benutzerführung geht, war vor einigen Wochen schon einmal Gegenstand eines Blogartikels. Gegenwärtig gibt es darüber hinaus Anzeichen, dass sich auch die Erwartungshaltungen zur Softwarepflege ändern werden.

Wer ein Einkaufs-Portal benutzt, ist nicht überrascht, wenn sich eines Tages das Design ein wenig ändert, wenn neue Features auftauchen, bisher komplizierte Abläufe vereinfacht werden. Auch, wer eine App auf seinem Smartphone oder seinem Tablet installiert, erwartet, dass sie im Laufe der Zeit durch (automatische) Updates neue Funktionen erhält, dass ihr Design in unmerklichen, kleinen Schritten modernisiert wird, dass Ungereimtheiten oder Umständlichkeiten “von selbst” verschwinden.

In Kundengesprächen deutet sich in den letzten Monaten an, dass diese Erwartung sich auch auf kommerzielle Branchen- und Individualsoftware ausdehnt. Hier war das aber bisher nicht selbstverständlich: Der Kunde kauft eine bestimmte Version und die – möglicherweise vereinbarte – Wartung erstreckt sich zumeist nur auf Fehlerbehebung oder das UpGrade auf neue Versionen des Betriebssystems oder der Datenbank – wenn überhaupt. Wünscht der Kunde ein “Facelifting” oder eine Anpassung der Benutzerführung an veränderte Erwartungen, dann wird die Lieferung eines neues Releases vereinbart.

Ist eine Veränderung dieses Vorgehensmodells überhaupt möglich? Können mehr oder weniger permanente Aktualisierungen einschließlich Modernisierungsmaßnahmen und Verbesserungen in der Benutzerfreundlichkeit z.B. im Rahmen der Wartung vertraglich vereinbart werden? Lässt sich so etwas sinnvoll kalkulieren, sodass es für beide Seiten sinnvoll ist?

Diese Fragen lassen sich nicht ganz einfach beantworten, und sie hängen von den konkreten Umständen und der Art und Struktur der jeweiligen Lösungen ab. Aber wir Softwarelieferanten müssen darüber nachdenken und uns selbst um Lösungen kümmern, die den Erwartungen der Benutzer entgegenkommen. Denn daran, dass die Nutzer unserer individuellen Lösungen ihre Erfahrungen mit Portalen und Apps in den Büroalltag mitbringen, kommen wir nicht vorbei.