…und es gab Nymphen, die unsterblich waren… Das soll jemand verstehen.

Aus Herkules, Pro 7

Die Herstellung von Software beschränkt sich nicht nur auf die eigentliche Codierung. Diese ist zwar wichtig, denn sie setzt die vorher angestellten Ideen in etwas real existierendes um, aber nicht allein entscheident. Aus diesem Grund sollte man die eigentliche Programmierung nicht als schnödes doing abqualifizieren. Ebenso wichtig wie die Programmierung ist die Analyse dessen, was in Software umgesetzt werden soll. Grob kann man dies auch als Anforderungsermittlung bezeichnen. Heraus kommen Anforderungen unterschiedlichster Art, seien es Anwendungsfälle oder nichtfunktionale Anforderungen, die einen oder mehrere Geschäftsvorgänge dokumentieren.

Leider sehen die meisten Menschen, die ein Softwaresystem entwickelt haben wollen oder entwickeln sollen, die Arbeit der Anforderungsermittlung als lässtig an. Zugegeben, es ist schwer Menschen zu dieser Tätigkeit zu ermutigen. Insbesondere dann, wenn es erst einmal Geld kostet und die Kosten, die entstehen, wenn man es nicht macht, im Nebel der Zukunft verschwinden. Nach mir die Sintflut ist ein implizit weitverbreiteter Gedanke in der Softwareentwicklung. Aus diesen Gründen werden die Investitionen in Anforderungen meistens auf Sparflamme betrieben und die Dokumentation ist entsprechend schlecht.

Meistens bekommen die Entwickler dann trotzdem irgendwie ein funktionierendes System hin, welches den Geschäftsprozess auf die eine oder andere Art abbildet. Das Projekt wird natürlich teurer als geplant, die Fehler die zu Beginn gemacht wurden lassen sich eben im Projektverlauf nur durch höhere Kosten auffangen. Soweit im Grunde nichts Neues und auch nicht gerade eine spektakuläre Erkenntnis.

Geschäftsprozessquelle

Die Quelle für die Ermittlung von Geschäftsprozessen sind meistens die Mitarbeiter, die bisher den Prozess bearbeitet haben. Vor der Einführung der EDV wurden diese Prozesse von diesen Mitarbeitern händisch ausgeführt. In einer ersten technischen Evolutionsstufe haben diese Mitarbeiter den Technikern ihr Wissen vermittelt. Sie wussten worauf es bei einem Vorgang ankam und kannten die Fallen und Kniffe. Die nächste Generation der Bearbeiter orientierte sich bei der Arbeit dann an den Bildschirmmasken. Diese ursprüngliche Mitarbeitergeneration scheidet im Verlauf der Zeit aus dem Unternehmen aus und mit ihr auch das fachliche Know-How. In der nächsten technischen Generation konnte vielleicht noch bedingt auf das menschliche Fachwissen zurück gegriffen werden. Daneben musste auf die Dokumentation der Programme oder gar deren Quellcode zurückgegriffen werden. In der Anforderungsermittlung wird soetwas auch als Archäologie bezeichnet.

Wohl den Unternehmen, die zu diesem Zeitpunkt in die Dokumentation der Anforderungen und der Geschäftprozesse investieren. Denn nach ein paar Softwaregenerationen, wenn der Bildschirmarbeiter nur noch ein Maskenausfüller ist und die eigentliche Arbeit irgendwo im Hintergrund von einer Maschine durchgeführt wird, wird das fachliche Wissen im Unternehmen verkümmert sein. Die Optimierung der Geschäftsprozesse, die für ein Unternehmen lebenswichtig ist, wird immer schwieriger, weil die codierten Zeilen in den Tiefen der Server ihr Fachwissen nicht einfach offenbaren. Es besteht die Gefahr, dass das Unternehmen nur wegen des Verkümmerns des kollektiven Gedächnisses, aus dem Markt gemendelt wird.

Lösungen

Agile Prozessmodellierung und serviceorientierte Software, wie sie zur Zeit in Mode sind, werden nur bedingt eine Lösung bringen. Es ist eine typische Technikerlösung. Technische Probleme werden durch noch mehr Technik erschlagen. Dabei wird gerne die Schnelllebigkeit und Komplexität der Technik übersehen. In der IT wird alle 2 Jahre eine neue heilige Kuh durchs Dorf getrieben. Sie verspricht alle bisherigen Probleme auf einen Schlag zu erledigen. Funktioniert natürlich nie, sondern der Ertrinkende im Moor wird immer tiefer in selbiges hineingezogen.

Auch die Dokumentation der Geschäftsprozesse mit Werkzeugen wie UML wird nur bedingt Linderung verschaffen, wenn die Diagramm nicht ausgedruckt auf Papier vorliegen. Ablagen nur als elektronisches Dokument sind unter Umständen in einigen Jahren nicht mehr lesbar, auch wenn mit PDF/A jetzt ein Dokumentenstandard für die Langzeitarchivierung verabschiedet wurde. Sehr problematisch ist in diesem Zusammenhang die Zerfaserung der Prozessbeschreibung durch sogenannte Domain Specific Languages, wie sie im MDA Umfeld verstärkt zum Einsatz kommen.

Eine sichere Lösung erscheint mir immer noch die textuelle Erfassung von Anforderungen und Geschäftsprozessen. Diese können zusätzlich durch grafische Beschreibungen unterstützt werden. Allerdings sollten sie immer ausgedruckt archiviert werden. Dies scheint eine ziemlich langweilige Erkenntnis zu sein. Gerade für einen Techniker, wie ich es zuerst einmal bin. Aber ich bin mir sicher, wir werden in einigen Jahren, vielleicht Jahrzehnten, einen speziellen Wirtschaftinformatikstudiengang für EDV-Archäologie bekommen, wenn wir unsere Dokumentationsprobleme nicht lösen.

300 € sind nicht sehr viel, wenn man die Unendlichkeit als Messlatte nimmt.

Meine Güte bin ich in letzter Zeit alltagsphilosophisch.

Bedarfsmeldungen können einen manchmal schon ins Grübeln bringen: Ist ein Buch Hardware oder Software? Eigentlich interessiert mich an einem Buch nur der geschriebene Inhalt. Das kann man als Software ansehen, ganz besonders wenn es als PDF, neudeutsch E-Book, kommt. Als gedrucktes Buch kann ich es jemanden an den Kopf schmeissen. Definitiv Hardware.