Erkenntnisse aus einem Softwareentwicklungsprojekt zur Ablöse einer Standard-Scanlösung

Die Reflektion eines abgeschlossenen Projektes ist ein wichtiger Bestandteil des Projektlebenszyklus. Für eine kontinuierliche Verbesserung muss man identifizieren, welche Tätigkeiten und Aktionen erfolgreich und welche weniger erfolgreich waren. Ein Projekt zur Individualentwicklung einer webbasierte Scanlösung, das in unseren Referenzen aufgeführt ist, ist vor kurzem mit einem erweiterten Produktionsrelease live gegangen. Jetzt ist also ein guter Zeitpunkt die Erfahrungen zu diesem Projekt Revue passieren zu lassen.

Am Ziel einer steinigen Projektreise lohnt sich ein Rückblick auf den zurückgelegten Weg

Geschäftliche Treiber & Motivation

Der Ausgangspunkt für die Entwicklung einer IT-Lösung sind geschäftliche Treiber. Es gibt ein geschäftliches Problem, das mit Technik gelöst werden soll. Diese Motivatoren müssen zu Projektbeginn identifiziert werden, damit Lösungsvorschläge dagegen evaluiert und funktionale Anforderungen davon abgeleitet werden können.

Im konkreten Projekt gab es verschiedene Treiber aus wirtschaftlicher Sicht, bei denen sich die bestehende Lösung für das Posteingangscannen unzureichend darstellte und an denen sich die neue Lösung messen musste:

1. Lizenzkosten: Das eingesetzte Scanprodukt musste pro Arbeitsplatz lizensiert werden, mit einem Scanvolumen von mindestens 300.000 Seiten pro Jahr. Nur ein Bruchteil des Scanvolumens wurde tatsächlich ausgeschöpft. Das zukünftige Lizenzmodell sollte ein Pooling von Lizenzen für mehrere Standorte erlauben oder komplett auf volumenbezogene Lizensierung verzichten.

2. Wartungsaufwand: Die Scanstandorte sind aus rechtlichen Gründen über ein gesamtes Bundesland verstreut. Der Aufbau eines zentralen Posteingangscannen ist nicht möglich. In den Standorten ist kein lokaler IT-Support vorhanden. Die Installation und Konfiguration des Scanprodukts hat erhebliche Reisezeiten gekostet. Durch die Produktstruktur war eine Automatisierung der Installation nicht sinnvoll möglich. Jeder Arbeitsplatz musste bei eine Konfigurationsänderung einzeln aktualisiert werden. Die Erwartungen an den Soll-Zustand waren eine zentrale Konfigurationsverwaltung, automatisierte Installationen und Aktualisierungen sowie Vermeidung von lokalen Einstellungen. Die Lösung muss für alle Scanstandorte und Arbeitsplätze zentral und einheitlich administrierbar sein.

3. Flexibilität: Ein Scanstapel der an einem Arbeitsplatz erstellt wurde, musste mit der bestehenden Lösung an diesem Arbeitsplatz durch den gesamten Arbeitsablauf geführt werden. Ein Wechsel der Arbeitsplätze und/oder Bearbeiter war nicht möglich. Im konkreten Projektumfeld war die zeitaufwändigste Arbeit im Scanablauf die Erfassung der fachlichen Metadaten zu einem Scanstapel. Um diesen Flaschenhals im Prozessablauf zu reduzieren, mussten komplette Scanarbeitsplätze mit eigener Scanhardware angeschafft werden, obwohl die Hardware selbst nicht ausgelastet war. Die neue Lösung sollte eine flexible Zuweisung eines Scanstapels an einen anderen Arbeitsplatz ermöglichen, der ggfs. keine Scanhardware angeschlossen hat, um die Erfassung der Metadaten und Signierung der generierten Dokumente dort durchzuführen und den Scan-Arbeitsplatz für andere Mitarbeiter freizugeben.

Das Identifizieren der geschäftlichen Treiber ist erfahrungsgemäß die richtige Wahl, wenn eine neue Lösungsarchitektur entworfen werden soll und war für uns einer der Erfolgsfaktoren. Anhand der geschäftlichen Perspektive lässt sich das Problem in Kundensprache beschreiben und alle Beteiligten starten mit einem gemeinsamen Verständnis des Projektziels.

Wirtschaftlichkeitsbetrachtung

Mit den drei übergeordneten Anforderungen wurden unter Einsatz von verschiedenen Standardprodukten mehrere Lösungsvorschläge erarbeitet. Neben dem Erfüllungsgrad der Anforderungen wurde auch die Wirtschaftlichkeit jeder Lösung bewertet. Die Kostentreiber waren Lizenz- und Wartungskosten der beteiligten Standardprodukte und die Abschätzung der Implementierungskosten von individuellen Anpassungen. Durch die vorhandene Scanlösung konnte ein Referenzwert ermittelt werden, gegen den sich eine neue Lösung messen musste.

Das Ergebnis dieses Vergleichs war eindeutig. Kein Standardprodukt am Markt hat eine Lösung geboten, die alle Anforderungen vollständig erfüllte. Zusätzlich war aufgrund der hohen Lizenz- und Wartungskosten von ganzheitlichen Standardprodukten auch der Preispunkt bei einer Individualsoftware am besten. Es wurde die Entscheidung getroffen, eine webbasierte Scanlösung individuell für den Kunden und seine dezentralen Scanstandorten zu implementieren. Lediglich ein Standardmodul zur Anbindung von TWAIN-fähigen Scangeräten mit überschaubaren Lizenzkosten wurde im Lösungsentwurf integriert.

Trotz höherer Startinvestition ist die Individualimplementierung auf lange Sicht günstiger. Der Break-Even wird bereits nach ca. 1,5 Jahren erreicht, da bei der alten Lösung die hinzukommenden Lizenz- und Wartungskosten bei neuen Scanstandorten deutlich höher sind.

Es hat sich bewährt die Lösungen zuerst aus funktionaler Perspektive mit dem Erfüllungsgrad der gestellten Anforderungen zu bewerten. Erst im Anschluss wurden die Kosten als Entscheidungsgrundlage hinzugezogen. So lässt sich eine balancierte Entscheidung unter Berücksichtigung der Qualität und Kosten einer Lösung treffen.

Proof of Concept

Die gewählte Lösungsarchitektur beinhaltet technische Risiken, die durch einen "Proof of Concept" entschärft werden sollten. Speziell die Anbindung an die TWAIN-fähigen Scangeräte durch eine zugekaufte Bibliothek wurde initial kritisch bewertet. Es wurde zu Projektbeginn ein Prototyp als minimaler Testfall umgesetzt, der mit der Zielhardware praktisch getestet werden konnte. Dabei konnten folgende Erkenntnisse gesammelt werden:

• Performance: Die vorhandenen Scangeräte haben eine schnelle Durchlaufzeit pro gescannter Seite. Es musste sichergestellt sein, dass diese Geschwindigkeit durch das TWAIN-Modul erreicht werden kann. Obwohl die Geschwindigkeit nach der Spezifikation des TWAIN-Moduls praktisch möglich sein sollte, wurden erhebliche Performance-Einbußen bei älteren TWAIN-Treibern festgestellt. Durch Erneuerung der Treiber konnte die theoretisch verfügbare Geschwindigkeit auch praktisch erreicht werden.

• Lastverhalten: Nach Auswertung der bisherigen Scanstatistiken musste mit Stapelgrößen von bis zu 600 Seiten gerechnet werden. Über einen Lasttest wurde sichergestellt, dass diese Anzahl von gescannten Bildern gleichzeitig im Arbeitsspeicher des Webbrowsers gehalten werden konnte. Zusätzlich wurde Optimierungspotential identifiziert, das in einer späteren Version umgesetzt wurde.

• Hardware-Funktionen: Über die TWAIN-Schnittstelle konnten alle relevanten Funktionen der Scanhardware adressiert werden. Es wurde festgestellt, dass einzelne, erweiterte Fähigkeiten über das TWAIN-Modul nicht adressiert werden können, z.B. Paginierung durch den Scanner. Da diese Fähigkeiten nicht benötigt wurden, war diese Erkenntnis als unkritisch zu bewerten.

• Installation / Rollout: Das lokal zu installierende TWAIN-Modul konnte von den Ziel-Arbeitsplätzen ohne Veränderung der Gruppenrichtlinien installiert werden. Leider wurde im Prototyp nicht auf eine Aktualisierung nach einem Versionsupdate geprüft. Erst im Produktivbetrieb hat sich nach einem Update des TWAIN-Moduls herausgestellt, dass Dateien zwar installiert aber danach nicht verändert werden dürfen. Hier hätte der Prototyp etwas weitreichender testen müssen.

Die praktischen Tests bestätigten die Machbarkeit der geplanten Lösung, da sich keine kritischen Einschränkungen aus technischer Perspektive zeigten. Allerdings wurden verschiedene Risiken bereits frühzeitig erkannt und der Lösungsentwurf darauf abgestimmt.

Wir halten solche Machbarkeitsstudien für dringend empfehlenswert, wenn einzelne Module in der Lösungsarchitektur das gesamte Projekt gefährden. Wenn kein verlässlicher Workaround zu einem technischen Problem bekannt ist und man bisher keine Erfahrungen mit dem gewählten Entwurf sammeln konnte, sollte dieses Risiko durch einen abgegrenzten Prototyp praktisch getestet und bewertet werden. Meistens lassen sich die Unsicherheiten so eingrenzen, dass die Prototypen in geringem Kostenverhältnis zur Gesamtlösung stehen. Trotz der vorhandenen Teillösung im Prototyp, sollte man sich nicht dazu verleiten lassen den Quellcode für die finale Lösung zu verwenden, da dieser unter anderen Qualitätsrichtlinien erstellt wurde. Ein Prototyp dient als "Leuchtspurmunition", der die Realisierbarkeit des geplanten Prozesses sicherstellt und beinhaltet üblicherweise "Wegwerf-Code". Einen guten Artikel zum Thema Leuchtspurmunition beinhaltet das Buch "Der Pragmatische Programmierer".

Frühes Test- und Integrationssystem

Für die Bereitstellung des Prototyps mussten frühzeitig Test- und Integrationssysteme bereitgestellt werden. Da die ditemis GmbH für das Projekt als Partner der Hewlett-Packard GmbH beteiligt war, wurden drei Testumgebungen bereitgestellt: Inhouse, Partnerumgebung und Kundenumgebung. Um manuelle Aufwände zu sparen, wurde dazu ein automatisierter Liefer- und Rolloutprozess im Sinne einer Continuous Delivery umgesetzt. Das hat im Projektverlauf immens geholfen, zu jeder Zeit eine einheitliche Testumgebung für alle beteiligten Parteien bereitzustellen. Im späteren Verlauf konnte das Build Management einfach um Ziele für separate Entwicklungszweige erweitert werden. Jenkins hat sich als Werkzeug zur Continuous Integration für uns für diesen Zweck mehrfach bewährt.

Auch die Kommunikation mit dem Betreiber (Rechenzentrum) musste für den Testbetrieb bereits zu Projektbeginn aufgenommen werden. Eine Prototypisierung hilft dabei, die Lieferwege und Testumgebungen frühzeitig zu etablieren.

Sanfte Integration & pessimistisches Migrationsszenario

Da eine bestehende Lösung bereits existierte und produktiv betrieben wurde, konnte der Rollout der neuen Anwendung stufenweise pro Scanstandort durchgeführt werden. Es wurde ein Pilot-Standort identifiziert, bei dem die Endanwender Erfahrungen mit der Applikation machen durften und das Verhalten der Anwendung mit realen Posteingängen geprüft wurde. Das Feedback aus dieser Pilotierung wurde direkt in den Entwicklungsprozess einbezogen.

Technisch konnte der Rollout so gestaltet werden, dass ein Parallelbetrieb von alter und neuer Lösung möglich war. Damit gab es keinen Druck, dass die Anwendung mit der ersten Version die gesamte Funktionalität der alten Anwendung ablöst. So konnte iterativ entwickelt und eine Migration stufenweise durchgeführt werden.

Wenn möglich ist bei einer Neuentwicklung einer bestehenden Lösung eine Integration in die bestehende Anwendungslandschaft stufenweise vorzunehmen und bei der Migration von einem pessimistischen Szenario auszugehen. Dadurch werden Big-Bang-Integrationsrisiken vermieden, es gibt einen einfachen Weg zur Rückabwicklung und der Stress für alle Beteiligten bei einem mangelhaften Release wird reduziert. Das ermöglicht eine einfache Pilotierung unter realen Bedingungen mit produktiven Daten und den Endanwendern.

Agile Entwicklung

Wir entwickeln gerne agil, da der Fokus von Beginn an auf ein lieferfähiges Produkt gelegt wird und man sich mit einem iterativen Vorgehen der Lösung nähert. Scrum bietet sich auch bei kleineren Projekten und Teams an und wurde für diesen Fall von uns gewählt.

Bereits parallel zur Spezifikationsphase konnten wir den ersten Sprint durchführen und die Konzeption mit ersten Erkenntnissen unterstützen. Es ist typischerweise möglich einige Module der Anwendung zu entwickeln, bevor die gesamte Lösung spezifiziert ist. Für die Kundenworkshops war dieses Vorgehen besonders hilfreich, da erste GUI-Interaktionen bereits möglich waren und Feedback zu den Entwürfen direkt in den Entwicklungsprozess einfließen konnte.

Wenn man eine gute Vertrauensbasis mit einem Kunden aufgebaut hat, hilft die agile Entwicklung dabei, erste Resultate als technische und optische Entscheidungshilfen während der Konzeptionsphase zu liefern. Gerade wenn die Zeit drängt und man technische Unsicherheiten prüfen muss, hilft der agile Ansatz.

Als leichtgewichtiges Taskmanagement, was sich mit Einschränkungen auch für Scrum eignet, verwenden wir Asana und haben gute Erfahrungen damit gemacht.

Statistiken sammeln

Für den Entwurf der neuen Lösung wurden verschiedene Annahmen zu der Beschaffenheit der gescannten Daten getroffen:

• Anteil DIN A3 Pläne
• durchschnittliche Anzahl Seiten pro Stapel
• durchschnittliche Anzahl Seiten pro Dokument
• durchschnittliche Größe (Kilobyte) einer Seite
• ...

Die bestehende Lösung bietet leider keine Möglichkeit diese Annahmen durch gesammelte Statistiken zu validieren. Deshalb wurde für die neue Lösung eine Erfassung von statistischen Daten vorgesehen, um in Zukunft aussagefähig zu dem Volumen und der Beschaffenheit der gescannten Inhalte zu sein.

Bereits in mehreren Fällen hat sich der Zusatzaufwand zum Sammeln dieser statistischen Daten gelohnt. Zum einen konnten anhand der Daten Aussagen zum Nutzungsverhalten getroffen werden und zum anderen lassen sich Kapazitäts- und Lastplanung für zukünftige Projekte dadurch verlässlicher durchführen. Aussagen zum Nutzungsverhalten sind vom Kunden oft gefordert und bei einer Individualentwicklung einfach umzusetzen.

Identifizieren und Sammeln Sie die wichtigsten Metriken, um das Nutzungsverhalten Ihrer Anwendung analysieren zu können

Angemessenes Logging

Wir präferieren ein umfassendes Logging, selbst wenn es mehr Speicherplatz und etwas Performance kostet. Im Produktivbetrieb ist es fatal, wenn man auf Fehlerzustände läuft und keine Aussage treffen kann, an welcher Stelle der Fehler aufgetreten ist oder welche Ursache der Fehler hat, weil die Loginformationen zu sehr eingeschränkt wurden. Gerade in der Anfangszeit ist es durchaus empfehlenswert ein hohes Loglevel zu wählen. Typischerweise zeigen sich einige Fehler erst durch die echte Nutzung von mehreren Anwendern, die Eingaben tätigen, die so nicht erwartet wurden. Auch das Verhalten einer Anwendung unter Last mit Echtdaten kann für Szenarien sorgen, die unerwartete Fehlerzustände hervorrufen.

Aus rechtlicher Sicht ist darauf zu achten, dass keine personenbezogenen Daten in den Logs enthalten sind, aus der man eine Aussage über die Produktivität einzelner Mitarbeiter ableiten kann. Ansonsten bedeutet es Prüfungen durch den Betriebsrat, was sich vermeiden lässt, da die Daten auch anonymisiert aussagekräftig sind. Das gilt auch für das Sammeln von Statistiken zum Nutzungsverhalten.

Ein Beispiel aus dem konkreten Projekt ist die Vermischung von technischen und fachlichen Daten. Ein Anwender nutzt zur Identifizierung eines Stapels eine Stapelkennung, die er selbst vergeben kann. In den Logs wurde der Primärschlüssel der Stapel, eine Nummer, verwendet. Falls ein Fehler zu einem Stapel aufgetreten ist, musste in der Fehleranalyse zuerst eine Zuordnung zwischen der Stapelkennung aus dem Anwenderticket und dem Primärschlüssel aus den Logs hergestellt werden. Die Lösung war einfach: Neben dem Primärschlüssel wurde bei jeder Logausgabe zu einem Stapel auch die eindeutige Stapelkennung ausgegeben, sodass eine Fehleranalyse in vielen Fällen bereits ohne Datenbankabfrage möglich war.

Unbekanntes Framework

Vor dem Projekt haben wir Backbone.js mit Marionette.js für unsere Single-Page-Applications (SPAs) eingesetzt. Da wir in einem größeren Team entwickelt haben, mussten wir ein Framework finden, dass für die Lösung angemessen ist und mit dem sich die Entwickler wohl fühlen. Viele der beteiligten Personen hatten im Umfeld der Entwicklung von Enterprise-Software Erfahrungen mit Java. Auf dem Java Forum Stuttgart 2014 gab es eine Vielzahl von Vorträgen über Angular.js und die Integration mit einem Java-Backend. Das hat uns in der Entscheidung gestärkt die Entwicklung mit Angular.js durchzuführen. Obwohl Angular.js nicht ohne Ecken und Kanten ist, haben wir den Vorteil in der großen Community, den vielen vorhanden Open-Source-Modulen und dem relativ strikten Entwicklungsmodell gesehen. Persönlich halte ich Angular.js für eine gute Wahl, um in die JavaScript-Entwicklung von SPAs einzusteigen.

Die Nutzung eines Frameworks mit dem das Team bisher wenig Erfahrungen hat, war ein technisches Risiko, das wir bewusst eingegangen sind. Auch wenn dieses Vorgehen in unserem Fall erfolgreich war, ist es sinnvoll ein neues Framework zumindest in einem kleinen Nebenprojekt zu testen. Für uns war das durch den Proof-of-Concept mit dem dazugehörigen Prototyp gegeben.

Fazit & Ausblick

Trotz einiger Fehltritte und Lernerfahrungen, kann das Projekt aus objektiver Sicht als Erfolg gewertet werden. Die Entwicklung entspricht in Zeit, Kosten und Qualität den Wünschen des Kunden und hat, was mich persönlich besonders stolz macht, sehr positive Rückmeldungen von den Endanwendern bekommen. Die Zufriedenheit der Endanwender ist sogar so hoch, dass Mitarbeiter explizit danach gefragt haben, wann sie endlich mit der neuen Anwendung arbeiten können. Da der Mensch Veränderungen eigentlich scheut, werte ich das als große Zustimmung.

Der Ausblick auf eine Weiterentwicklung der webbasierten Scanlösung ist gegeben, da bereits weitere Kunden angefragt haben. Um volle Funktionsfähigkeit zu erreichen, wird als erster Schritt zur Verbesserung der Lösungsarchitektur ein eigenes Clientmodul entwickelt. Damit können z.B. die Begrenzungen des Browsers in Bezug auf die möglichen Stapelgrößen bewältigt werden. Diese Lösungsarchitektur werden wir in einem der nächsten Artikel aufgreifen.