XML-Datenaustausch / Maintenance

Maintenance

Maintenance

➪ Ein häufiger Wechsel fachlicher Anforderungen bringt es mit sich, dass die Validierungs- und Konvertierungsprogramme zeitnah, schnell und kostengünstig geändert werden können. Zahlreiche Interfaces sind jedoch wenig wartungsfreundlich programmiert.

Auf dieser Seite:

In modernen IT-Systemen werden laufend Botschaften ausgetauscht: sowohl zwischen den diversen Schichten desselben Systems (Multi-Tier: Datenbank-, Logik- und Präsentationsschichten), in Client-Server-Architekturen, zwischen unterschiedlichen Applikationen (A2A) als auch zwischen diversen Systemen und Firmen/Institutionen (B2B).

Dabei kommen unterschiedliche Datenformate zum Einsatz: CSV, EDIFACT, SAP Idoc, ANSI X.12, JSON, XML etc. Zusätzlich gibt es zahlreiche betriebsinterne Formate, die keinen allgemeinen Standards entsprechen. Hierbei gewinnt XML seit Jahren an Bedeutung. XML bietet alle Möglichkeiten eines weltweiten, hersteller- und branchenneutralen Datenaustauschs über prozessrelevante Daten, über grundverschiedene Zeichensätze, Hard- und Softwaresysteme hinweg.

pic/XSL_Workflow3.jpg

Über den direkten (unternehmensinternen wie weltweiten) Datenaustausch hinaus spielt XML auch eine zentrale Rolle bei der Konvertierung anderer Datenformate. Liegen die Informationen beim Datenlieferanten beispielsweise in EDIFACT oder CSV vor, der Empfänger benötigt sie jedoch in SAP Idoc oder hausinternen Formaten, so ist eine Konvertierung der oft komplexen Dokumentstrukturen erforderlich. Bei dieser Datentransformation haben sich XML-Technologien bewährt. In zahlreichen mittelständischen Unternehmen laufen Konvertierungsprozesse dieser Art täglich millionenfach ab.

Auch für die Generierung von Spezial-Reports dient XML als zentrale Mittler-Technologie. Soll etwa aus einer SQL-basierten Datenbankabfrage ein umfangreicher Report in PDF-Format generiert werden, so werden die Ergebnisse der Datenbankabfrage in XML bereitgestellt; leistungsfähige XSL-Stylesheets übernehmen die Generierung von SVG-Grafiken, Barcodes, QR-Codes sowie die Konvertierung in FO-Dokumente, die die Vorstufe von PDF-Dateien darstellen.

pic/XSLFO.jpg

Automatisierte (oft XML-konfigurierte) Aufrufe von Druckprozessen senden die generierten PDF-Dokumente dann gleich an den richtigen Drucker, sodass zwischen der Datenbankabfrage und dem fertig ausgedruckten Report meist nur Sekundenbruchteile liegen. Die Ausdrucke sind oft unentbehrlicher Bestandteil täglicher Arbeitsabläufe in vielen Bereichen, etwa der Medizin.

Wann immer Geschäftsmodelle neu konfiguriert oder technologische Neuerungen eingeführt werden, wechseln die fachlichen Anforderungen der Botschaften. Daher sind (eilige) Aktualisierungen ein Dauerzustand. Die Änderungen können sowohl vom Datenempfänger als auch vom Datenlieferanten ausgehen.

Wichtig ist, dass ein "change" auf der einen Seite nicht einen grundlegenden Wechsel auf der jeweils anderen Seite erzwingt; hier sollte also keine komplette Neukompilierung erfolgen müssen. Für eine strukturelle Änderung auf Empfängerseite muss sich das Basissystem des Lieferanten nicht ebenfalls ändern. Ändert sich die Datenstruktur des Lieferanten, können die verarbeitenden Programme des Empfängers unverändert weiterlaufen.

So gesehen, "sitzt" die Konvertierungslogik zwischen zwei Partnern: der Datenlieferant auf der einen, der Datenkonsument auf der anderen Seite. Jede fachliche oder strukturelle Änderung auf einer der beiden Seiten muss von der Konvertierungslogik zeitnah umgesetzt werden, damit keine Informationen verloren gehen, und ohne notwendige Anpassungen auf der jeweils anderen Seite.

Von zentraler Bedeutung für eine Änderung der Geschäftsmodelle oder der Einführung technischer Neuerungen ist daher die Wartungsfreundlichkeit der Programmierschnittstellen. Wartbarkeit ist kein Luxus, sondern ein Qualitätsmerkmal.

ISO/IEC 9126 definiert Softwarequalität als die Eignung, die Aufgaben zu erfüllen, für die sie erstellt wurde, und legt Kriterien für die Messung von Softwarequalität fest:

Effizienz Die Aufgaben sollen angemessen schnell und mit möglichst wenig Verbrauch von Rechenzeit und Speicherplatz durchgeführt werden.
Funktionalität Die Anwendung muss technisch die Aufgaben angemessen und richtig erledigen.
Pflegbarkeit Die Anwendung muss gut dokumentiert und im Ablauf leicht nachvollziehbar sein und muss sich problemlos ändern lassen.
Portierbarkeit Es soll möglich sein, das System an andere Gegebenheiten anzupassen und es gegebenenfalls auch zu ersetzen.
Verwendbarkeit Das System soll leicht verständlich und erlernbar sein.
Zuverlässigkeit Es sollen keine technischen Fehler auftreten, Benutzungsfehler sollen toleriert werden und leicht korrigierbar sein.

Häufige Änderungen fachlicher Anforderungen

In der häufigen Änderung fachlicher Anforderungen liegt die Hauptarbeit für die Entwickler von Schnittstellen, die oft auch die Betreuung jener Interfaces übernehmen. Die Neuentwicklung der Applikationen nimmt im Vergleich hierzu nur relativ kurze Zeit in Anspruch. Deutlich zeit- und damit kostenintensiver sind die Änderungen.

Bereits in den 90er Jahren wurden die durchschnittlichen Kosten für Wartungsaufwand auf 80 bis 90 Prozent des Software-Lebenszyklus (für Software allgemein) geschätzt. Grob geschätzt, ist das das Fünf- bis Zehnfache der Implementierungskosten.

Es kommt viel darauf an, dass die Anpassungen zeitnah und schnell erfolgen können. Nicht nur, um den reibungslosen Ablauf betrieblicher Prozesse sicherzustellen, bei denen es im Ernstfall um viel Geld, sogar um Menschenleben gehen kann. Sondern auch, um den Kostenaufwand der Anpassungen im Rahmen zu halten.

Genau hier gibt es in vielen Firmen resp. Institutionen ein Problem. Zahlreiche Interfaces sind wenig wartungsfreundlich programmiert. Der spätere Maintenance-Aufwand ist umso höher, was bei einigen Tausend parallel zu betreuenden Interfaces schwer zu Buche schlagen kann.

Wartungsintensive Projekte wie Datenaustauschprozesse weisen häufig eine andere Arbeitsrealität auf als reine Implementierungsprojekte, in denen das Entwicklungsteam (gut entlohnt und beurteilt: "Budget und Deadline wurden eingehalten") nach Fertigstellung und Abnahme auseinandergeht und sich neuen Aufgaben zuwendet. Der Auftraggeber steht mit seiner bestellten und bezahlten Software da. Viel Spaß damit!

Wenn die Entwickler von Schnittstellen auch deren Betreuung übernehmen, bleibt das Team in der Regel zusammen, Know-how geht seltener verloren. Aber auch hier konzentrieren sich viele Systementwürfe für Neuprojekte auf die Minimierung der Erstimplementierungskosten bis zur Inbetriebnahme. In kaum einer Spezifikation steht das Wort "Wartungsfreundlich", ebenso selten sind Kriterien für deren Umsetzung benannt.

Auch die Finanzierung des später zu erwartenden Mehraufwands für Wartung und Pflege steht vermutlich in keiner Planung. (Das gehört schließlich auch nicht zu den Projektkosten, sondern wird den Betriebskosten zugerechnet.) Gerade dann, wenn häufige fachliche Änderungen zu erwarten sind, spielt das aber eine zentrale Rolle.

Die Wartungsphase

Die Wartungsphase zerfällt häufig in zwei Teile.

Mangelhafte Planung, Testing und Dokumentation stellen daher beträchtliche Kostentreiber dar: nicht nur im Hinblick auf vermeidbar erhöhte Wartungskosten, sondern über den erhöhten Stressfaktor für die Mitarbeiter auch im Hinblick auf eine mögliche Steigerung der Krankheitsquote.

Aber auch sonst erscheinen viele Anwendungen wenig wartungsfreundlich. Das hat mehrere Gründe. Einer davon dürfte sein, dass in großen Teams zahlreiche, manchmal Hunderte Entwickler nebeneinanderher arbeiten, jeder für sich, ohne ein gemeinsames Prozessverständnis, ohne klar formulierte Minimalanforderungen für ein maintenance-freundliches Design oder für entsprechende Qualitätsstandards.

Nicht immer ist derjenige, der eine Applikation ursprünglich geschrieben hat, auch derjenige, der im Bedarfsfall (Monate oder Jahre später) die Anpassungen vornehmen darf. Der Übernehmer steht zunächst vor der Herausforderung, sich in die vorhandene Logik einfinden zu müssen.

Ohne eine hilfreiche Dokumentation (die der vorherige Entwickler in wenigen Minuten bis Stunden hätte schreiben können), dauert die Informationsrecherche für den Übernehmer dann überproportional länger (Stunden bis mehrere Tage). Die Suche nach jenen wenigen Zeilen im Code, die letztlich geändert werden müssen, kostet dann viel Zeit.

Wenn das Qualitätsmanagement (das es möglicherweise gar nicht gibt) solide Dokumentations- und Testverfahren nicht zwingend einfordert, dann werden sie auch nicht befolgt. Sprich: Auch bei der nächsten Anpassung wird der dann zuständige Entwickler ohne hilfreiche Dokumentation, ohne Testszenarien dastehen. Jede marginale Änderung wird wieder überproportional lange dauern und wieder viel Geld kosten.

Während Konzepte zur Software-Neuentwicklung im Regelfall eine Deadline haben, also ein klar definiertes Projektende, ist Maintenance ein Dauerzustand permanenter Änderungen. Hier kann die Entwicklung teaminterner Funktionsbibliotheken sinnvoll sein, um

Die Code-Hölle

Selbstverständlich sollte die Wartung von Software von dem Nutzen abhängen, den sie dem Anwender bringt. Eine Software ohne erkennbaren Nutzen ist überflüssig. Gehen Sie also davon aus, dass eine Software, die aktualisiert werden soll, auch einen Nutzen hat. Lohnt es sich aber, eine Software auch dann zu aktualisieren, wenn der Aufwand für die Änderungen außerordentlich hoch zu werden droht?

Im Extremfall sind Interfaces in einer Weise implementiert, die sich kaum noch warten lässt. Der Programmcode steht aufgrund hochgradiger gegenseitiger Abhängigkeiten quasi als gordischer Knoten da, den aufzuknüpfen aussichtslos erscheint. Welche Mühe mag es gekostet haben, die Programmierlogik so zu perfektionieren, dass sie nicht mehr gewartet werden kann! Und nun bleibt nur die Entsorgung und Neuentwicklung als Ausweg.

Die Wiederverwendung von Quellcode ist allgemein sinnvoll, solange der vorhandene Quellcode dazu beiträgt, ein Problem effizient zu lösen. Das steht jedoch infrage, wenn die verwendeten Teile sehr stark voneinander abhängen, so dass eine Code-Hölle entsteht. Eine solche Situation kann sich ergeben, wenn notwendige Änderungen an der Programmlogik eines Codeteils A die Wirkung hat, dass andere Programmteile, die A einbinden, nicht mehr wunschgemäß laufen.

Code-Höllen gibt es in zahlreichen Sprachen bzw. komplexen Entwicklungsprojekten, auch in XSL habe ich sie schon gesehen. Schlecht oder gar nicht dokumentierte Templates, globale Variablen und Parameter, Functions, Attribute-Sets, die sich zu Tausenden gegenseitig aufrufen und deren Verhalten im Einzelfall schwer nachvollziehbar ist: Da wird Maintenance zum (betriebswirtschaftlichen) Alptraum.

Gerade im Maintenance-lastigen Bereich der Datenaustauschprozesse sollte sich eine zukunftsorientierte Strategie auf eine konsequente Entflechtung der gegenseitigen Abhängigkeiten konzentrieren.

wg / 5. April 2018



Fragen? Anmerkungen? Tips?

Bitte nehmen Sie Kontakt zu mir auf.






Vielen Dank für Ihr Interesse an meiner Arbeit.


V.i.S.d.P.: Wilfried Grupe * Klus 6 * 37643 Negenborn

☎ 0151. 750 360 61 * eMail: info10@wilfried-grupe.de

www.wilfried-grupe.de/maintenance.html