ZIDline
TISS Epistemologie II
M. Suppersberger, A. Knarek, Ch. Ledl, W. Kleinert, Th. Grechenig
Die größten Risiken beim Aufbau großer Verwaltungs-(Software-) Systeme sind nicht technischer Natur. Vielmehr entspringen diese Risiken zumeist einem Mangel an menschlichem Zusammenhalt und gezielter Kommunikation.

Die ZIDline hat in der letzten Ausgabe die Epistemologie modernerer Softwaretechnik und deren Wirkung auf ein Inhouse-Projekt wie TISS reflektiert. Der vorliegende Artikel setzt diesen Blickwinkel auf den Bau des neuen Systems im Kontext des industriellen State-of-the-Art fort.

„No Silver Bullet“ Reloaded

Warum gibt es kein einfaches Allheilmittel gegen die so genannte Softwarekrise? Konkret im Kontext von TISS, warum kann man die Komplexität der existierenden und nunmehr intendierten Abläufe, Use-Cases, Verwaltungsprozesse und Geschäftsfälle nicht unaufwändiger in Code gießen oder durch ein Standardsystem abbilden?

Nun, in aller Kürze zwei Hauptursachen im Fall von TISS und dessen Umfeld:

  1. Fachliche Historie und Komplexität: lässt sich (sehr selten) reduzieren oder gar eliminieren. Sie lässt sich allenthalben ordnen und zähmen, sodass man sie einschätzbar abarbeiten kann. Sie verschwindet nicht ins Nichts. Unsere Universität ist zu groß, die Studienrichtungen sind zu unterschiedlich, die wissenschaftlichen Methoden in den verschiedenen Disziplinen zu vielfältig, die Kulturen zu variant, als dass man einen „Kahlschlag der Anforderungen“ durchführen könnte und so auch nur einen der Stake-Holder „misshandeln“ könnte.
  2. Entscheidungen und Entscheidungsprozesse: fachliche Inhalte sind heikle Entitäten, die je nach Managementkultur mehr oder weniger starke „Gärungsprozesse“ benötigen und selbst nach Ende der Gärung und anschließender Destillierung volatil bleiben. Jede neue betriebliche Software etabliert neue Abläufe, muss die alten „mitnehmen“ und Brücken schlagen. Letztlich bildet Software hier Verwaltungsformen und -ziele ab und muss Abstimmungsprozessen genügen, die formell und informell, bevorschriftet und antizipativ, zentral und dezentral, direktiv und demokratisch gleichzeitig sind. Solche Software lebt die Quadratur des Kreises durch pragmatische Kompromisse und eine sehr flexible Infrastruktur.

Größere software­technische Aufgaben sind immer ein Amalgam aus Problemstellungen auf unterschied­lichen Ebenen: konkret technisch, technisch konzeptiv, strategisch technologisch, operativ management­-sichtig, planerisch, logistisch, personell, kommunikativ, sozial, hierarchisch, projektpolitisch, unternehmenskulturell. Dieses Grundprinzip, dass sich Software, die die Zusammen­arbeit von vielen Usern unterstützt, praktisch nie aus dem fachlichen Kontext herauslösen lässt, ist methodisch ärgerlich, aber ein Faktum. Es hat in der Praxis drastische Konse­quenzen auf die reale Wirksamkeit für hochgelobte Allheilmittel oder „flotte“ Business- oder Techno-Moden in der Systembautechnik der IT. Beispiele dafür:

  • Gutes Instrument, schlechte Anwendung: Es nützt nichts, eine konzeptiv geniale Technologie einzuführen (Smalltalk als Programmiersprache in großen Corporate Environments war historisch so ein Beispielfall), wenn die Human Resources zur Umsetzung am Markt langfristig nicht verfügbar sind oder der Basisaufwand bis zur nachhaltigen Etablierung nicht geleistet und investiert wird.
  • Gute Techniker, schwache Entscheidungsprozesse: Andauernde Richtungsdiskussionen über die Funktion einer Software zwischen zer­strittenen Stakeholdern einer Institution kann man mit der besten Technologie nicht lösen. Dafür gibt es Maßnahmen auf anderen Ebenen, für die Softwaretechniker in der Regel nicht ausgebildet sind.
  • Gute technische Einzelentscheidungen, die nicht ineinandergreifen: Eine bestimmte Entwicklungs­plattform für die Eigenentwicklung eines Unternehmens auszuwählen, ist eine technische Entscheidung mit langfristigen Managementeffekten. Wie viele Unternehmen aner­kennen denn heute schon das Erfordernis einer guten Softwarestrategie? Diese Frage endet zu oft schon mit der eher nebensächlichen Fragestellung Microsoft-Produkte oder Open Source …
  • Eine Unternehmensebene optimiert ihre Ziele, auf Kosten der anderen: SAP (als Beispiel hier für große Standardsoftware) als umfassenden Geschäftsfall-Prozessor in einem Konzern einzuführen, ist in der Regel eine Top-Level-Managemententscheidung mit drastischen langfristigen Aus­wirkungen auf die Beweglichkeit in relevanten technologischen Bereichen. Was den Vorstand formal gut entlastet, ist noch lange keine angemes­sene Strategie für den wirklichen Bedarf des Unter­nehmens. SAP an der richtigen Stelle, angemessen eingeführt, wirkt. – Was und wie sind hier nicht zu trennen.
  • Gute Teile, kein Verbund: Drei schöne, aber technisch unterschiedliche Teillösungen, die heute sehr viel Erfolg/Freude bereiten, sind morgen möglicherweise eine große Qual bei der Bereitstellung einer einheitlichen integrierten Entwicklungslandschaft. Eine Entwick­lung von Software in Richtung der früher oder später jedenfalls notwendigen Ablöse und Migration ist heute nach wie vor eine Seltenheit.

Diese Liste lässt sich beliebig verlängern. In einer Ebene eine Entscheidung zu fällen, hat Auswirkung in einer oder mehreren anderen, ein organisatorisches Problem lässt sich techno­logisch selten gut angehen – eher noch umgekehrt.

TISS hat in seiner Softwarestrategie viele derartige Problembereiche berücksichtigt. Doch wie die Pflege eines schönen Gartens ist die Erhaltung einer vernünftigen Softwarestrategie, die Erhaltung der notwendigen Harmonie ein ständiger Durchforstungsprozess.

Die alte Binsenweisheit in der Softwaretechnik, Fred Brooks „There is no Silver Bullet“, scheint eine Konstante zu bleiben. Gute Softwaretechnik ist harte, ernsthafte und solide Arbeit. Komplexität ver­schwindet nicht irgendwohin, ihre Beherrschung bekommt man nie billig geschenkt. Gute Softwaretechnik ist nie einfach zu erzielen, sie entsteht in vielen kleinen Detailentscheidungen, die durchgängig mit hoher Qualität getroffen werden. – Keine leichte Aufgabenstellung für das Topmanagement eines Unternehmens, hier weise und solide vorzugehen, die richtigen Personalia sowie die richtige Strategie zu finden.

Allein, eine fitte, flexible und effektive Software-(Entwicklungs-)Landschaft liefert einem modernen Unternehmen heute ein unschlagbares strategisch-technologisches Moment. Wer seine Softwaretechnik und die darüberliegende IT im Griff hat, hat einen wesent­lichen Konkurrenzvorteil.

Gehen wir doch gemeinsam kurz anhand von Fallbeispielen näher ins Detail, um zu sehen, warum Softwaretechnik ober­flächlich einfacher zu sein scheint, als sie es tatsächlich ist. Beginnen wir mit einer Anekdote aus dem internationalen IT-Projektgeschäft. Ein lieber Projektpartner – vorzüglicher Techniker, Projektmanager und Bereichsverantwortlicher bei einem deutschen IT-Security-Hersteller – hatte von folgender Projekterfahrung berichtet:

 „Das Projekt in Taiwan ging schon seit mehreren Monaten nicht so recht voran. Die Geschäftsführung schickte mich nach Taipeh, weil ich etwas Erfahrung hatte, technisch fit bin sowie jung, kinderlos und reiselustig, neugierig war. Nach etwa 4 Wochen war ich nach einem Steuerungsmeeting wieder einmal so richtig angep… (techniküblicher Jargon). Alle redeten im Kreis, waren schrecklich höflich zueinander, aber kein wirkliches Problem wurde gelöst oder entschieden. Man redete aneinander vorbei. Irgendwie verstand ich nicht, ob ich nichts verstehe oder alle anderen einfach dämlich sind. Ich nahm mir einen 2-seitigen chinesischen Text aus einer Spezifikation eines Geschäftsfalles, der einfach und allgemein verständlich einen operativen Ablauf erklären sollte. Es handelte sich um ein Projekt, das jeden Taiwanesen mit einer ID-Karte ausstatten würde. Ich fragte meinen Zimmerkollegen, er möge mir übersetzen, was da steht. Dann ging ich zwei Zimmer weiter und fragte die Juristin, was da steht und ob sie es mir übersetzt. Dann ging ich im Bürogebäude unseres taiwane­sischen Partners einen Stock höher in die Marketingabteilung und bat dort jemanden am Gang um Erläuterung.

Immer exakt derselbe Text. Zuletzt ging ich auf die Straße und fragte einen gut gekleideten Exekutiv, ob er für mich Zeit hätte. Es war ein gebildeter Bankfachmann. Er las und erläuterte gerne auf Englisch. – Am Ende hatte ich vier unterschiedliche Geschichten gehört. Nicht etwa leicht veränderte Geschichten, sondern in wesentlichen Punkten wirklich unte­rschiedliche Abläufe.

Als Reaktion bat ich meine Geschäftsleitung, beim Partner Englisch als Projektsprache zu erzwingen. Danach ging alles besser und wir kamen endlich voran. Ich kann nicht zu 100% sagen, dass die Problemlösung darin lag, dass wir (in Englisch waren wir Europäer sprachlich im Projekt im Vor­teil) mehr Erfahrung hatten und besser führen konnten, aber es war schon offensichtlich, dass Chinesisch zu blumig für die Präzisierung des genannten Sachverhaltes war, sodass die Menge der Interpre­tationen zum großen Hindernis wurde.“

Wir wollen hier mit dem Schwank natürlich keine linguistischen Diskussionen aufwerfen, es geht um die tiefere Lehre aus der Geschichte: In Softwareprojekten sprechen wir alle Chinesisch miteinander! Und müssen uns bemühen, eine andere gemeinsame Sprache zu finden, die präziser ist und Miss­ver­ständnisse vermeidet. Warum? Das Bauen von Softwaresystemen ist ein einziger großer Übersetzungs­vorgang von der Denk- und Interessenswelt der Auftraggeber (Leitung, An­wen­der, Fachexperten) und deren Umfeld (Rechtsrahmen, Branche, Konkurrenz) hin zu den Softwareentwicklern und wieder retour. Der Anwender denkt etwas, formuliert etwas, erzählt es dem Techniker. Der Techniker versteht es, baut ein System nach diesem Verständnis und liefert es an den Anwender, der es dann (hoffentlich) versteht und verwenden kann.

Aus der Sicht der Kommunikationstheorie ist das ein komplexes Problem, das letztlich nur eine wirkliche Lösung hat: Erkläre Deinem Gegenüber so lange, welche Probleme er hat, bis er vollauf zustimmt und sich verstanden fühlt. In die Softwaretechnik übersetzt heißt das: Der Soft­wareentwickler programmiert dem Anwender so lange, was er gemeint hat, bis dieser sagt, ja! das wollte ich. – Soweit die Theorie…

In der Praxis großer Systeme gibt es naturgemäß andere Verfahren, aber dem Prozess des Ein­dringens in die Materie, des Verstehens, des Modellierens, des Allumfassens, über die Zeit Weiterdenkens, der Antizipation dessen, woran der Anwender (heute) noch nicht denkt, kommt große Bedeutung zu. Darin besteht ein großer Teil der Komplexität. Komplexität ist dabei nicht nur fachlich-funktional, sie ist in hohem Maß auch kommunikativ sehr fordernd. Fachliche Dinge kann man objektivieren und versachlichen, Kommunikation, Interpretation und Interessensbildung kann man „nur“ zähmen.

Abbildung 1 stellt diese Kommunikations- und Interessenskomplexität, die jedem Softwaresystem innewohnt, in Form einer Karikatur dar. Zum Zwecke der Erläuterung deklinieren wir die einzelnen Bilder von links nach rechts durch. Dem Cartoon unterliegt eine fiktive Aufgaben­stellung: Der Auftraggeber wünscht sich eine originelle Schaukel im eigenen Garten, die etwas anders ist als die des Nachbarn, sicheres Material verwendet, den Kindern Spaß macht und wirklich robust ist.

Cartoon Kunde – Fragmente, aber kein System: Der Kunde hat keine geschlossene Vorstellung, wie seine Wünsche in ein System zu integrieren sind. Er will, dass es den Kindern gut geht, dass sie sich freuen, Spaß haben und stolz auf den Papa sind. Manchmal sind es drei Kinder, die miteinander spielen. Die sollen sich nicht streiten, vielleicht lässt sich etwas machen, dass mehr als einer gleichzeitig schaukeln kann, ohne sich weh zu tun. Kein Chaos, eine ordentliche Schaukel, aber Sie wissen… Objektiv übersetzt würde dabei wohl etwas Unbrauchbares herauskommen. Es braucht Gespür seitens des Auftragnehmers. – Der Kunde ist typisch, normal. Kein „dummer Kunde“. Wenig Zeit. Qualifiziert.

Der Kunde ist natürlich nicht erfahren in der Komposition seiner Wünsche. Er ist kein Schaukelspezialist! Er hat eine Reihe von Vorgängen im Kopf. Ihr innerer Zusammenhang ist nicht Gegenstand seiner Expertise. Er hat Wünsche und Ziele und einzelne Geschäftsfälle und Fragmente im Kopf. Das ist einer der Gründe, warum der Auftraggeber selten selbst eine Spezifikation, ein Analysedokument, eine textuelle Darstellung für den Softwaretechnikprozess erstellen kann. Er ist Experte für die Verwendung eines Systems, er hat aber im Normalfall überhaupt keine Übung darin, ein vollständiges Dokument im Sinne eines Fachkonzeptes zu fertigen, das Ent­wicklern als Basis dienen kann.

Gute Analyse muss man lernen und erfahren. Ein guter Analytiker lernt durch gute und schlechte Erfahrung, was für seine Softwaretechnikkollegen als Anforderungssammlung taugt und was nicht. Der Kunde ist kein Analytiker. Gute Analytiker wissen das, nehmen die Konzepte des Kunden als Teil mit, machen aber jedenfalls ein Expertenkonzept. Natürlich gibt es Ausnahmen.

An der TU Wien zum Beispiel hatten einzelne Einheiten eine extrem klare Vorstellung von dem neuen Zielsystem in ihrem Bereich und sehr planerische betriebswirtschaftliche Konzepte im Kopf. Solche Diagramme und Niederschriften können eins zu eins in das Fachkonzept des Systems übernommen werden. Andererseits gibt es natürlich eine Reihe von Fachexperten im Haus TU, die  ihre Probleme gut im Griff haben, diese aber im Sinne eines „Gehirnmonopols“ nicht in ein strategisches Papier mit konzeptiver Bedeckung bringen können. – Warum auch, diese Fragestellung ist einmalig. – Es gehört zu den nachhaltigen Ergebnissen von TISS, im Laufe des Projektes schrittweise Transparenz in Form von Fachkonzepten zu etablieren.

Cartoon Projektleiter – Sicher, aber nicht funktional: Jeder Projektleiter hat Vorerfahrung. Positive und negative Erfahrungen in seinem beruflichen Werdegang als Entwickler oder Manager. Oft hat er schon vom Top-Management viel Druck bekommen, wenn er im Sinne des Projektes, des Kunden, seiner Projektmitarbeiter ein persönliches Risiko auf sich genommen hat. In einem kurz zurückliegenden Projekt mag er/sie hier ein Haftungsproblem verursacht haben, das ihn beinahe seine Position gekostet hätte. Überhaupt ist er/sie vom Charakter her eine vorsichtige Person. Den Ausführungen des Kunden hat er gut zugehört, er weiß, seine Analytiker werden sich der Sache dann im Detail annehmen. Was er für sich mitgenommen hat, war Sicherheit, Sicherheit, Sicherheit! „Alle Last an einem Ast, dieses Risiko werden wir nicht eingehen. Ansonsten, Leute, eine ganz normale Schaukel!“. – Ein durchschnittlicher Projektleiter.

Projektleiter, die in kleineren Softwareunternehmen tätig sind, sind in der Regel mehr Eigenständigkeit gewöhnt und daher auch risikofreudiger. Projektleiter in stärker hier­archischen Großunternehmen haben oft gelernt, auf wirtschaftliche Aspekte mehr zu achten als auf die gute Lösung des Problems allein. Risiko, Haftung, Profit, mit dem vorhandenen Personal auskommen sind tägliche Mantras und werden ihm vom oberen Management eingebläut. Ein derartiger Projektleiter hat de facto drei „Kunden“: den wirklichen Kunden, seine eigenen Vorgesetzten und die Ziele des eigenen Unternehmens. Je „älter“ und „zentralistischer“ hier größere Systemhäuser sind, desto frustrierender kann diese Tätigkeit sein, gleich drei Unzufriedenheitsherde zu be­ruhigen: den unnachgiebigen Vorgesetzten, den grantigen Kunden und das unzufriedene Team, das trotz hoher Performanz wenig positive Reputation erntet.

Erfolgreiche Projektleiter machen in der Regel positiven Druck auf alle drei: Beim eigenen Top-Management holen sie sich Ressourcen und Freiheiten für das eigene Team sowie Goodies, die den Kunden freuen. Sie holen vom Kunden das finanziell Angemessene heraus und erklären rechtzeitig, was er für sein Investment erwarten kann und was nicht. Sie motivieren das eigene Team zu guten Leistungen und zum Verstehen des Kunden. Ein guter, entspannter, erfahrener Projektleiter versteht den Kunden. Er denkt sicher nie an eine Schaukel, die zwar nicht runterfällt, aber nicht schaukelt.

TISS hat ein operatives Führungsteam (zwei Frauen, zwei Männer), das sowohl das Haus, als auch seine Fachlichkeit ausgezeichnet kennt. Gäbe es ein Diplom für Universitätsverwaltung, sie könnten alle eines verliehen bekommen. Das gehört zu den großen existierenden Werten des laufenden Projektes: Projektleiter mit umfassendem fachlichem Tiefenverständnis, sodass der vorliegende Effekt wohl hintangehalten werden kann.

Cartoon Analytiker – Vorgaben erfüllt, Ziel verfehlt: Die Tragödie nimmt ihren theatralischen Lauf: Der Projektleiter hat aus Ressourcengründen große Teile seiner Mitschrift zu einem ersten Konzept zusammengefasst und intern an einen seiner Analytiker weitergeleitet. Die entscheidende Person beim Kunden ging auf Geschäftsreise für einen Monat, der Analytiker hat den Kunden zwar einmal besucht, aber nur nett Kaffee getrunken und die Kinder gesehen. Die Kinder hat er genau untersucht. Er kennt ihr Alter, Gewicht, Größe, deren Freunde sowie ihr Psychogramm. Die strikten Vorgaben seines Projektleiters, der mit dem Entscheider beim Kunden als einziger gesprochen hat, nimmt er mit ins Konzept auf und eliminiert die offen­sichtlichen Schwächen: „Wenn es daher – warum auch immer, der Kunde ist König – Bedingung ist, dass auf jedem Ast eine Aufhängung sitzen soll, dann müssen wir am Baum etwas tun, damit das System auch wirklich schaukelt. Ist zwar etwas eigenartig, aber der Kunde will ja eine sehr originelle Schaukel.“

Natürlich ist das hier surreal übersteigert dargestellt. Dennoch, der beschriebene Effekt ist vom Prinzip her real und empirisch evident. Softwareprojekte haben oft „heilige Kühe“, die das Gesamtdesign kompliziert und eigenartig machen. Ist die Kuh heilig genug, dann bestimmt ihre Pflege das gesamte Projekt. Gar nicht so selten wäre das Problem beseitigbar, wenn man am Pfad seiner Entstehung entlang, Konsequenz und Alter­nativen nach oben ins Management tragen könnte. Ein Softwaresystem besteht oft aus mehreren 10.000 Einzelentscheidungen. Da hat nicht immer jeder alles in Übersicht und in Evidenz und nicht jeder Entscheider ist laufend im Bilde, was gerade im Detail gemacht wird. – Der Start eines der größten IT-Projekte in Europa wäre beinahe an der Frage gescheitert, ob Gesundheitsdaten auf der persönlichen Gesundheitskarte exklusiv ge­speichert werden sollen oder nicht. Eine Interessensvertretung verband fälschlicher­weise damit das eigene Versinken in die Bedeutungslosigkeit. Sachlich diskutierbar, emotional jedoch ausweglos verbunden mit der Zerschlagung der etablierten Abläufe und Wege.

Ein direktes Gespräch zwischen Eigentümer der Schaukel und Analytiker hätte genügt, um das Problem zu beseitigen. Ist ein Projekt groß genug, wird der Effekt der stillen Post wirksam. Menschen neigen dazu, aus den Dingen das herauszuhören, was ihrer Vorerfahrung entspricht. Vorerfahrungen, Annahmen, Erwartungen und nicht zuletzt emotionale Gewichtungen sind höchst unterschiedlich und begleiten jede Systemanalyse.

TISS gießt seine Analyseergebnisse so rasch wie möglich in Systempiloten und diskutiert diese mit ausgewählten Usern und Experten im Haus. Dadurch werden derartige Effekte weitestgehend vermieden. Natürlich – das gehört zu den Paradoxen des Softwarebaus – kann man ein Grundsyndrom der Softwaretechnik auch hier nicht ausschalten: Auch die beste Analyse eines Neusystems in der Verwaltung wird gerade mal 80% des endgültigen Zielsystems abdecken und beinhalten können, oft gar nur 50%. Warum? Heutige IT-Systeme unterliegen einer Evolution durch Gebrauch und Erfahrung. Solche Effekte lassen sich grundsätzlich kaum vorwegnehmen.

Cartoon Programmierer – Baum gerettet, Schaukel geerdet: Der Entwickler bekommt ein Analysedokument und eine mündliche Zusatzbeschreibung des Analytikers. Er kennt die Stärken und Schwächen seines Chefs, macht sich seinen eigenen Reim daraus. Eventuell ist die Anforderung, dass es eine Schaukel für Kinder sein soll, etwas in den Hintergrund gerückt und das, was im Kopf des Programmierers landete, hört sich in etwa so an: „Es soll ausschauen wie eine typische Kinderschaukel, vor allem sehr, sehr sicher fixiert werden. Die Lösung mit dem Stamm ist eigenartig. Aber der Kunde will es so. Er hat wohl was Spezielles vor.“

In der Praxis kommt es häufig vor, dass gute Developer Fehler der Analyse mit viel Hausverstand und mit der Erfahrung der Umsetzung kompensieren, ergänzen oder ausbessern. Eine zweite praktische Erfahrung deutet die Karikatur auch gut an: Systemnahe Programmierer neigen dazu, Usability nicht so ernst zu nehmen, und sehen beobachtbar ganz gerne den User als ein Problem. Das ist er natürlich manchmal wirklich. Nur kann man seiner Rolle nicht entfliehen: Softwaretechnik ist Dienst am User! – Das Brett hängt an den beiden Seilen. Die Seile sind am Baumstamm festgemacht. Wer will schaukeln? Was zählt, ist die Spezifikation.

Die Hälfte der TISS-Developer kommt aus dem Haus und ist mit dem Zielsystem seit Jahren befasst. Das verhindert nicht alle programmiertechnischen „Blindheiten“, vermeidet aber doch so manche. TISS hat überdies einen Mechanismus etabliert, rasch nachzubessern, falls im Betrieb ernste Interaktionsprobleme für die User auftreten.

Cartoon Berater – Das Blaue vom Himmel ist für Sie gerade gut genug: Der an sich ehrenhafte und wichtige Beruf des Beraters ist in den letzten Jahren bei IT-Leitern etwas in Verruf geraten. Das Gewerbe des erfahrenen Senior-Experten, der jene IT-Profile ergänzt, die für Unter­nehmen einfach zu teuer oder zu speziell wären, um sie als Dauerangestellte im Personal vorzusehen, ist ein wichtiger Teil des IT-Personal-Spektrums und in jeder Ingenieurbranche der wesentliche Kitt und Klebstoff zwischen verschiedenen Interessenwelten. Gute Berater lösen alle jene Probleme, die Angestellte in der Linienstruktur eines Unternehmens nicht lösen können oder nicht wollen, weil es für sie ein hohes Risiko bedeuten würde. Ein guter Berater ist Therapeut, Menschenfreund, Problemlöser, Enabler, Stratege, ein Wunder an Geduld. Ein Übermensch;-).

Durch das Bild mit Sofa verweist der Zeichner auf negative Erfahrungen mit sehr vertriebsorientierten Beratern. Solche Berater können der Versuchung nicht widerstehen, das Wahrscheinliche zum Todsicheren zu erklären, das Mögliche zum Wahrscheinlichen und das Wunder zur normalen Möglichkeit zu erheben.

Klar braucht es Visionen für große Projekte, nur hat sich über die wenigen Jahrzehnte der Informations- und Softwaretechnik auch eine Abart des Konsulenten herausgebildet, die „mit Glasperlen bei Naturbewohnern billigen Ein­druck schindet“. Zwei Arten von negativen Über­treibungen sind dabei nicht selten: das persönliche Folgebudget über den Kundennutzen stellen, die mittelfristige Machbarkeit mit einer zu optimistischen Kosten-Nutzen-Bewertung zu unterlegen. Manche große Beratungshäuser und die Beraterstäbe großer IT-Häuser nutzen dabei das über Jahre aufgebaute gute Image ihrer Marken, um Abhängigkeit und Umsatz zu erzielen und nicht unbedingt Lösungen bereitzustellen. Zum Schaden der ganzen Branche.

TISS ist als „No-Nonsense“ Projekt etabliert. Die verantwortliche Projektleitung ist vom Fach und benötigt keine Berater. Das verantwortliche Topmanagement wird regelmäßig über die Fortschritte informiert, sodass kaum „Kunstziele“ auftreten.

Cartoon Dokumentation – Ein Schatten ihrer selbst: Man muss eine zeitlang Softwaretechniker gewesen sein oder von Anfang an in einer Softwarewartungsumgebung angelernt worden sein, um am eigenen Leibe gespürt zu haben, was es bedeutet, wenn Code, Systemaufbau, Entwürfe oder andere Systemkonstrukte nicht ausreichend dokumentiert wurden oder inkonsistent sind. Beim eigenen Programm, das man alleine schreibt, ist es schon schlimm genug, wenn es sechs Monate später wieder angegriffen wird. Zwar findet sich so ein Solist in der Regel nach zwei Tagen wieder in den eigenen Strukturen zurecht, aber der Prozess selbst ist schon ein emotional schmerz­haftes Gefühl. Bei größeren Systemen ist mangelhafte Dokumentation deutlich fataler für den Gesamtzustand eines Softwaresystems. Durch die größere Anzahl an Personen wächst zuerst einmal die Möglichkeit des Miss- oder Nichtverstehens. Selbst gut dokumentierte Projekte hinterlassen eine ordentliche Menge an Einlese-Komplexität für neue Mitarbeiter. Ist wenig Dokumentation vorhanden, dann sind im günstigen Fall die Autoren und Hersteller des Systems noch verfügbar, dann kann man über Nachfrage und gemeinsame Diskussion das „Geheimnis lüften“. Schlechte oder wenig Dokumentation hat ähnliche Effekte wie schlechte Führung eines Projektes. Effektivität und Funktionsdichte eines Systems sinken dann rascher ab.

Wenn über die Jahre dann auch noch die Entwickler das Unternehmen wechseln, tritt sehr rasch der Effekt der zunehmenden Unwartbarkeit des Systems ein. Man kann dann eventuell noch Konstanten identifizieren und lokalisieren (z. B. Steuersätze ändern oder Lohntabellen anpassen), aber sehr schwer grundlegende Ergänzungen vornehmen. Schlechte Dokumentation beschleunigt den Alterungsprozess von Software und erhöht die Komp­lexi­tät in der Ablöse des Altsystems durch ein neues.

Es ist wie eine Art gesundheitlicher Langzeitschaden verursacht durch jahrelange schlechte Gewohnheit. Es fällt beim Tun zuerst nicht auf, wäre im Moment der Erstellung wenig aufwändig, es besser zu machen, und bewirkt unter Umständen doppelte Kosten bei der Sanierung. TISS löst ein derartiges, „zu Tode“ gewar­tetes, in einem eskaliert des­integrierten Zustand vorliegendes Altsystem (Legacy-System) ab. Derartige Arbeiten kann man schon als hochwertige Softwarearchäologie bezeichnen.

Das Problem ist nunmehr schon seit den 80ern in der Softwareindustrie bekannt. Nichtsdestotrotz sind gute 40–50% der in Europa in Betrieb befindlichen Nicht-Standard-Software (sehr optimis­tische und positive Schätzung) de facto unterdokumentiert und 75–85% nicht dahingehend optimiert, dass die Pflege durch Dritte bzw. die Ablöse durch ein Neusystem merkbar unterstützt wird. Das Entwicklungsparadigma „Development for Relay“ hat heute noch kaum Anhänger, wird erst langsam zum Prinzip reifen.

Natürlich kann man es auch übertreiben. Falsche und schlechte Dokumentation sowie Dokumentation, die höchstwahrscheinlich nie benötigt wird und viel Aufwand und Kosten verursacht, ist Alibi-Dokumentation und damit noch schlechter als keine Dokumentation. Wirtschaftlichkeit, Ange­messenheit und Brauchbarkeit von Dokumentation sind von Projekt zu Projekt zweckmäßig anzupassen. Eine inhaltlich verlorene, aber vollständige Papierlage mag den Zertifizierer nach einem Standard zum Ausstellen des Zertifikats genügen, den Rechenstift am Ende des Lebenszyklus wird das nicht im Geringsten beeindrucken.

TISS geht mit dem Thema der angemessenen Dokumentation kontext-sensitiv um. Um Kosten zu sparen, werden wesentliche Teile der Dokumentation erst dann erstellt, wenn die Ziellösung etabliert ist. Die Erfahrung hat gezeigt, dass einzelne Entscheidungen im Haus lange kreisen und dass die Dokumentation aller Kreise ineffektiv sein kann. Das Team sorgt dafür, dass TISS mit verträglichem Aufwand auf eine neue Technologie umstellbar ist, dass ein relevanter Minimalgrad an technischer Dokumentation vorliegt. Gleichzeitig werden höhere Grade der Dokumentation erst dann erstellt, wenn relevante Freeze-Zustände des Systems erreicht wurden.

Cartoon Installation – Gute Freunde, strenge Rechnung: Die Phase der Inbetriebnahme ist in der Softwaretechnik ein sehr entscheidender Abschnitt: Der Kunde oder Betreiber setzt das System erstmals in Gang. Histo­risch gesehen wird diese Phase ähnlich wenig be­achtet, so wie die Wartung und Ent­sorgung von Software. Während der Inbetriebnahme tritt nicht nur der Realtest ein, in der Regel trifft das Softwaresystem auf eine neue Betriebsumgebung, auf Personen, die vorher nicht beteiligt waren. Dabei treten häufig unerwartete oder unvorhersehbare Effekte auf. Es werden außerdem natürlich auch alle Defizite der Entwicklung sichtbar, die im Tunnelblick der Entwicklung niemandem aufgefallen sind. – Dann kann es passieren, dass Teile nicht geliefert oder fertig sind, dass wesentliche Systemteile weggelassen werden müssen (das Holz der Sitzbank, die vom Sublieferanten geliefert wurde, hatte einen Sprung und könnte unter Last brechen) oder zum Wunschtermin wesentliche Teile nicht fertig sind.

Noch schlimmer, nicht nur die geplante Zeit war nicht ausreichend, im Laufe der Entwicklung kam es zu einem Streit zwischen Auftraggeber und Auftragnehmer über den Leistungsrahmen. Eine Situation, die in der Softwaretechnik ein Loose-Loose-Szenario darstellt. Zu weich sind die Bausteine und zu fragil die Konstrukte, um im vertraglichen Infight über solche Probleme hinwegklettern zu können. Gute Partnerschaft ist alles in der jungen Disziplin Softwaretechnik. Schlechte Partnerschaft macht hier den Wohl­meinenden zur Geisel des anderen.

Bei größeren Projekten empfiehlt sich immer ein Pilot- und Testbetrieb vor der vollen Inbetrieb­nahme. Sehr große Projekte evolvieren sich von Ausbaustufe zu Ausbaustufe und eliminieren so schrittweise die Kinderkrankheiten und Wachstumsprobleme.

Die zweite, tiefere Weisheit im Comic zum Thema Installation besagt, dass ein allseits zufrieden stellendes Dreieck aus a) Wunsch & Auftrag, b) Schätzung & Aufwand, c) Qualität & Resultat sehr schwer errichtbar ist. Dafür gibt es letztlich nur ein wirksames Mittel: gute, erfahrene Fachleute und Lieferanten in realer Per­for­manceblüte.

TISS hat durch die Verwendung von internem Fach-Know-how sowie durch niedrige Kostenniveaus eine langfristige Risikominimierung etablieren können, das so in industriellen Umgebungen nicht möglich sein würde.

Cartoon Wartung – Operation gelungen, Patient tot: Die Langzeitfolgen von schlechter Wartung wurden in Zusammenhang mit schlechter Dokumen­tation schon skizziert. Die Handelnden sind im Laufe der Zeit andere. Vielleicht wurden Haus und Garten verkauft und es sind jetzt andere Nutzer am Werk. Gar nicht so selten werden überdies für die Wartung entweder schlechter qualifizierte Personen eingesetzt als für die Neuentwicklung oder das Thema wurde überhaupt an Dritte weiter­gegeben. Die originelle Schaukel wird jetzt von einem Garten­- oder Poolunter­nehmen mitgewartet.

Die Illustration mit dem abgeschnittenen Baum ist ein Symbol für den Verlust der ursprünglichen Projektvision und/oder des Promotors, oft auch als schleichender Vorgang. Wenn ein System lieblos gepflegt wird, dann hat das Gründe. Gute Wartung zeichnet sich durch laufende Ver­besserung und Anpassung an neue Anforderungen und Bedürfnisse aus. Derart werden Systeme zu so genannten Gründungs- oder Nukleussystemen. Sie erzeugen Nachkommen und eine ganze Familie an geschätzten Lösungskomponenten mitsamt entsprechenden Service-Organisationen. Überspitzt dargestellt: Gute Wartung ist laufende Neuentwicklung und lässt ein System zu einem ganzen Organismus weiterwachsen. Schlechte Wartung ist wie schleichendes Hinausekeln. Die Software geht dann sprichwörtlich so lange zur Wartung, bis sie abgesägt wird!

Die TISS-Planung ist einerseits nach modernen Grundsätzen der Softwarewartung aufgebaut, rein methodisch wird der bisher vorliegende Zustand der Unwartbarkeit des Altsystems nunmehr eliminiert. TISS 2025 wird die Sanierungsprobleme von TISS 2010 nicht erleben. Sofern es dann überhaupt zu einer Totalablöse kommen muss – derzeit wird eher eine evolutionäre Weiterentwicklung angedacht – wird diese ein wohlbestalltes „Brownfield“ vorfinden, ein System, das seinen eigenen Abbruch bzw. seine eigene Ablöse mit eingeplant hat.

TISS wird im Herbst 2010 eine Reihe von Altsystemen ablösen. Die Belastungsproben und Einführungsschmerzen für alle Beteiligten werden spürbar sein. Die Nutzerinnen und Nutzer an der TU sowie die Studierenden, für die wir letztlich alle unseren Dienst leisten, mögen jedoch versichert sein, dass TISS nicht nur ein undurchschaubar gewordenes Altsystem ablösen, sondern auch ein nachhaltiges Applikationsmanagement etablieren wird, das allen Anwendern die Leistungsfähigkeiten anbieten kann, erforderliche Verwaltungsänderungen in einer dynamischen Zeit rasch aufnehmen und umsetzen zu können. TISS ist nicht nur neu, es ist vor allem „System design prepared for change!

In der folgenden Ausgabe der ZIDline wird die Betrachtung von TISS als neues Verwaltungsmedium der TU in einem Artikel zur Epistemologie III abgeschlossen.

Literatur

Grechenig et al., 2009, Softwaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten, Pearson Studium, München, Deutschland.