Redundanzen zu vermeiden, ist nach wie vor das Ziel der meisten Systementwickler. Um komplexe Systeme überschaubarer zu machen, plädiert Dieter Schultze* jedoch für kleine, spezialisierte, nahezu Identische Programme für jede Geschäftsfall-Variante.
Warum werden aber immer noch zentral orientierte, weitverzweigte Systeme entwickelt? Weil die eigentlichen Geschäftsvorfälle gar nicht bekannt oder nie erfragt wurden. Interessiert haben immer nur dateiorientierte Funktionen statt der Felder, die der Benutzer in einem Geschäftsvorfall benötigt. Trotz Datenbanken wird immer noch in Dateien und DV-Funktionen gedacht.
Und vielleicht schämen sich auch manche ein wenig vor leeren und einfachen Bildern sowie Programmen aus 30 Befehlen. Vielleicht fühlen sich Programmierer erst wohl, wenn sie komplexe 10000-Statements-Programme beherrschen. Genau darin liegt wohl das psychologische Problem. Es zieht sich von der Ausbildung bis in die Praxis hinein. Wer komplexe Programme meistert, ist ein Meister. Wirklich? Statt dessen sollten Programmierer im gleichen Rhythmus denken wie ihre Benutzer - in den Kategorien von Geschäftsfällen und äußeren Ereignissen die zu behandeln sind. Dadurch würden sie auch einiges zusätzlich lernen und wären begehrtere und bessere Gesprächspartner für ihre Fachabteilungen.
Das geschäftsfallorientierte Design, Es würde dem Verlangen nach schnellem Entwickeln direkt an der Maschine mit 4GL hervorragend entsprechen.
Eine Anwendung in ihre 200 Geschäftsfälle aufzuteilen und konsequent zu entwickeln, ergibt einen höheren Nutzen bei niedrigen Kosten.
Vorteile für den Benutzer:
Schnelle Sachbearbeitung, hoher Bedienungskomfort, hohe Bedienungssicherheit, Selbsterklärungs-Fähigkeit, gute Antwortzeiten, kurze Anlernzeit, gute Dezentralisierbarkeit, optimierte Abläufe, frühe Einführung, billiger im Betrieb, lange Verwendbarkeit.
Vorteile für die Entwickler:
Einfache Aufwandschätzung, Prioritäten setzbar, mehr Benutzer-Mitarbeit, Prototyping mit 4GL, Arbeiten gut teilbar, höhere Motivation durch ganzheitliche Entwicklung, wenig Entwicklungspapiere, reduzierte Testarbeit, kurze Bedienungsanleitungen, weniger Wegwerf-Code.
Vorteile für die Wartung:
Fehler rasch lokalisierbar, lineare Programme, Änderungen immer lokal, einfaches Testen, vereinfachte Dokumentation, weniger Telefon-Support.
Bei geschäftsfallorientierter Entwicklung mit Datenbanken auf Feldebene ist Protoypting pro Geschäftsfall eben nicht mehr quick and dirty, sondern genau die Art, große Systeme zu bauen.
Was ist im Rahmen eines Phasenkonzepts anders als bei geschäftsfallorientiertem Entwurf? Zunächst einmal müßen die paar hundert Geschäftsfälle eines Arbeitsgebietes ermittelt werden: Auslösendes Ereignis, Anzahl, erwartete Resultate, möglicher neuer Ablauf. Das erfolgt in der Vorstudie- und Konzeptphase. Das fachliche Sollkonzept wird nach Geschäftsfällen geordnet, die Projektplanung ebenfalls, das konzeptionelle Daten-Design sowie die Hard- und Software-Auswahl kann wieder übergreifend erstellt werden (siehe Abbildung auf Seite 21).
Bei der alten dateiorientierten Entwicklung würde jetzt in wenigen großen Teilprojekten pro Subsystem phasenweise weitergefahren. Bei geschäftsfallorientierter Entwicklung wäre der Verlauf etwas anders: Nach einer sehr kurzen, übergreifenden Spezifikation von Standards und Konventionen startet man auf breiter Front in kleinen und kleinsten Teilprojekten pro Geschäftsart. Dabei würden die Phasen Detailspezifikation, Programmierung, Rahmenorganisation und Einführung je nach Projektgröße dieser Geschäftsarten in angemessener Form zusammengefaßt.
Parallel hierzu läuft ein übergreifendes Mantelprojekt, in dem ein Dienste-Team die physische Datenbank sowie die mehrfach verwendeten Programmteile begleitend verwaltet. Unabdingbar als Hilfsmittel ist dabei ist eine Datenbank; die logischen Datensichten der einzelnen Geschäftsart-Programme können dabei von der physischen Sicht auf Files und Segmente getrennt sein.
Die einzelnen Geschäftsarten werden, falls sinnvoll, laufend eingeführt und freigegeben. "Evolution delivery"; Tom Gilb hier läßt grüßen. Der Benutzer kann die ersten Programme schon nach wenigen Wochen einsetzen, Daten erfassen, und die Ablauforganisation geschäftsfallorientiert umstellen.
Benutzerhandbücher könnten reduziert werden, da die Bedienung vereinfacht ist, und viele Erläuterungen direkt auf den Masken und in den kleinen Programmen stecken.
Die Schulung wird vereinfacht; der Test reduzierte sich massiv, weil in linearen Programmen keine unerwünschten Interaktionen von anderen Geschäftsfällen mehr wären. Damit verliert der große Ketten- und Integrationstest am Ende der Programmierung seine eigentliche Bedeutung.)
Warum wird so nicht gearbeitet? Gibt es eine Angst vor der Flut von nicht beherrschbaren kleinen Programmen oder vor der Redundanz von Programmteilen? Sie verlangt schon ein bißchen ingenieurmäßige Disziplin, die Verwendung von Standard-Modulen. Das wäre für manchen doch relativ neu, konsequent Standards, Calls, Routinen anzuwenden. Ebenso das Verwenden von Datensichten und Subschemata statt Files und Segmenten. Aber es wäre es wert.
Ein anderer Nachteil heutiger Pipeline-Entwicklung kann nämlich ebenfalls dabei behoben werden: Meist sind in den Projekten ein oder mehrere Fachabteilungsvertreter mit mehr oder weniger gutem DV-Verständnis einbezogen. Nun ist es äußerst unwahrscheinlich, daß gerade diese Mitarbeiter über alle Geschäftsvorfälle auch nur annähernd fundierte, praktische Kenntnisse hätten. Also besteht das Risiko, trotz vieler Rückfragen bei den entsprechenden Spezialisten an den echten Bedürfnissen vorbeizuentwickeln.
Wenn aber geschäftsfallorientiert entwickelt wird, sollte von Anfang an jeder neue Geschäftsfall direkt mit denjenigen Benutzern entwickelt werden, die diese Geschäftsart auch tatsächlich abwickeln. Die Entwickler bleiben für eine kurze Zeit bis zum Schlußtest dieser Geschäftsart mit den Fachspezialisten zusammen. Das entlastet den Benutzer-Verantwortlichen und verbessert die Qualität der Lösung. Darüber hinaus sind mehr Personen in den Entwicklungsprozeß eingebunden, und die allgemeine Motivation steigt.
Aber das entscheidende Argument soll organisatorischer Natur sein. Kleine, einfache Masken und Datensichten können dezentralisiert werden - direkt an die Front. Den vorher erwähnten, Geschäftsfall "Heirat" könnte eigentlich die Personalabteilung selbst am Bildschirm eingeben. Oder warum soll das nicht gleich der Vorgesetzte des entsprechenden Mitarbeiters erledigen, sowie er davon Kenntnis erhält? Oder der Mitarbeiter selber - der "Kunde" in diesem Fall?
Der Informationsgehalt der Maske ist reduziert auf genau diesen einen Geschäftsvorfall. Mit Erläuterungen, klaren Feldbezeichnungen, Code-Legenden. Der Spezialist in der Lohnabteilung wird nicht mehr für triviale Datenerfassung gebraucht. Die Masken lassen sich über Paßwörter auf Abteilungsebene problemlos absichern - ohne Programmieraufwand. Der Weg vom Zentralismus, hin zu den leichten dezentralen Truppen ist frei. Paß der Rechner dabei noch zentral steht, spielt ja keine Rolle.)
Eine komplexe Maskenfolge von fünf oder zehn Masken zum Aufnehmen eines neuen Artikels in einem Großbetrieb ist Arbeit, die von Spezialisten gemacht werden muß. Einfache Masken aber können an die Front. Warum soll nicht der Abteilungsleiter die 20 Felder für eine Neu-Eintrittsmeldung eines gewerblichen Mitarbeiters im Monatslohn selbst eingeben?
Oder der Mitarbeiter selber? Das könnte dann ja immer noch vom autorisierten Abteilungsleiter und/ oder einem Spezialisten in der Zentrale am Bildschirm visiert werden. Aber die zentrale Datenerfassung mit ihrem kontraproduktiven Belegablauf entfällt. Ein Schritt zu weniger Papier ist ein Schritt zu mehr Produktivität.
Mancher wird hier Bedenken anmelden. Warum eigentlich? Sind das nicht Denkhürden aus den 70er Jahren vorhanden? Auch Geschäftsfälle haben immer dezentrale "Ur-Ereignisse", bis sie zu zentralen Geschäftsfällen werden.
Das alles gilt nicht nur für Neuentwicklungen. Auch Altlasten lassen sich nachträglich geschäftsfallorientiert entflechten, wenn man zu Beispiel den kompliziertesten Geschäftsfall und den häufigsten jeweils in eigene Masken eigene Programme und eigene Jobs aufnimmt. Daß dabei redundanter Code anfällt - so what?
Beim häufigsten Geschäftsfall werden Eingaben, Jobabläufe und Output optimiert. Dabei wird der Code für alle nicht benötigten Fälle gelöscht. Ergebnis ist eine effiziente, lineare Programmkette, die häufig läuft. Dann eine weitere Kette, die wenigstens um den häufigsten und den kompliziertesten Fall entlastet ist; sie dient für die übrigen Fälle mit einer Ausnahme: Der komplizierteste Fall bekommt ebenfalls seine eigene, verzweigungsfreie Programm-Kette. Das wäre eine Strategie, Anwendungen zu längerem Leben zu verhelfen. Andere Strategien zum Entflechten auf Geschäftsfall-Ebene sind möglich.
Geschäftsfallorientierte Systementwicklung steigert die Produktivität an vielen Orten: Bei den Benutzern, bei den Projektentwicklern und bei der Wartungsgruppe. Neue originelle Lösungen je Geschäftsfall entstehen - schnelle Sachbearbeitung, schnelle System-Einführung, kurze Testzeiten und enger Benutzerkontakt.
Das alles führt zu kürzeren Entwicklungszeiten, rascherem Nutzen, weniger Koordinationsaufwand, wenig Korrekturen gegen Projektende, rascherer Anpassung an Änderungen und kleinerem Wartungsaufwand. Schnelle Antwortzeiten trotz 4GL-Sprachen und Datenbanken, motivierte Programmierer/Analytiker, schnelle Ergebnisse und Prototyping mit Wiederverwendbarkeit sind auf diese Weise möglich. Der Ruf der DV als Ganzes wird wieder besser.
* Dieter Schultze ist Unternehmensberater in Buchs/Zürich.