Dei schwarze Kiste der Pandora

Die schwarze Kiste der Pandora

Viele Dinge, die wir benutzen, verstehen wir nicht. Wir verlassen uns darauf, daß der Hersteller weiß, was er da macht und sind zufrieden, wenn wir soviel wissen, das wir das Ding benutzen können. Das geht häufig auch überhaupt nicht anders. Zum einen sind viele Dinge zu kompliziert, als das ein einziger innerhalb der ihm zur Verfügung stehenden Lebenszeit das Wissen ansammeln könnte, um sie vollständig zu verstehen. Das gilt nicht nur für den Computer, an dem ich diesen Text schreibe. Das ist auch gerade das Geheimnis, wie die Gesellschaften seit Jahrtausenden zu Wohlstand gekommen sind. Durch Arbeitsteilung macht jeder das, was er am besten kann. Wenn die so entstandenen Waren und Dienstleistungen dann ausgetauscht werden, haben alle wesentlich mehr, als wenn jeder es auf eigene Faust versuchen würde.

Es gibt aber Situationen, wo man vorsichtig sein und sich nicht beliebig ausliefern sollte. So wollen wir zwar nicht alle unsere Lebensmittel selber herstellen, erwarten aber doch, daß wir auf der Packung nachlesen können, was drin ist.

Quelloffene gegen geschlossene Software

Heute hat man in vielen Fällen die Wahl zwischen Software, deren Quellen man einsehen kann und die meistens frei verfügbar ist, und solcher, die als fertiges Programm von einem Hersteller geliefert wird und über deren Funktionsweise man nur soviel erfährt, wie uns der Hersteller gnädigerweise in der hoffentlich mitgelieferten Dokumentation verrät. Die Dinge sind natürlich nicht so einfach schwarz und weiß. Brauchbare quelloffene Software wird in aller Regel auch von Leuten geschrieben, die damit Geld verdienen wollen, allerdings nicht durch den Verkauf der Software sondern ihres Wissens um die Möglichkeiten derselben. Diese Leute haben oft nicht nur keine Lust, gute Dokumentation zu schreiben, sondern es gehört zu ihrem Geschäftsprinzip, das kompliziertere Dinge nur möglich sind, indem man entweder versteht, wie die Software aufgebaut ist oder teure Beratungleistung einkauft. Allerdings ist es in den meisten Fällen immer noch billiger, sich ein oder zwei Wochen durch fremden Code durchzuarbeiten wie ein Projekt an der unzureichenden Dokumentation einer eingekauften Komponente scheitern zu lassen.

Über eins darf man sich aber nicht täuschen. Die Offenheit von Software bedeutet nicht unbedingt, daß ich auch verstehe, was da abläuft, oder gar Änderungen vornehmen kann. Einige Dinge sind so komplex, daß es nur wenige Spezialisten gibt, die da eine Chance habe. Auch die Rolex ist quelloffen. Ich bin aber sicher nicht in der Lage, eine solche Uhr zu öffnen und dann wieder so zusammenzusetzen, daß sie weiterhin funktioniert. Wenn behauptet wird, daß ein quelloffener Verschlüsselungsalgorithmus von jedem auf Hintertürchen überprüft werden kann, ist das eine rein theoretische Aussage, da es jahrelange Studien braucht, die Konsequenzen von dem, was da abläuft, zu verstehen.

Datenstrukturen

Zumindest im Umfeld von Geschäftssoftware geht es fast immer um Daten. Wenn Daten abgelegt werden, so daß sie nur mit der Software verwendet werden können, die sie einmal geschrieben hat, so kann es sein, daß die Daten verloren gehen, wenn es z.B. für dann aktuelle Betriebssysteme keine Version dieser Software mehr gibt.

Hier ist es wichtig, daß bekannt ist, wie die Daten abgespeichert sind, so daß man notfalls eine Software erstellen kann, um an sie heranzukommen.

Abläufe

In einem Geschäftsprozeß werden Daten immer wieder verändert. Dabei kann es vorkommen, daß Zustände entstehen, die so nicht vorgesehen sind. Die Daten sind dann im weiteren Verlauf gar nicht oder nicht mehr korrekt verarbeitbar. Wenn die verwendete Software die Daten in für den Benutzer nicht zugänglichen Strukturen ablegt, ist das Problem nicht zu lösen. Zumindest muß die Software eine Zugriffsmöglichkeit bieten, daß solche Fehler behoben werden können. Ist das nicht der Fall, so ist die Software für den Gebrauch in realen Anwendungen nicht geeignet, denn Fehler werden immer vorkommen. Einen Datenverlust aufgrund dieser Fehler kann man sich aber nicht leisten.

Neben Fehlern gibt es auch die Änderung der äußeren Umstände. Wenn eine Anwendung mit langlaufenden Geschäftsfällen umgeht, kann das im echten Leben bedeuten, daß im ersten Schritt eine Bestellung in China aufgegeben wird. Das Containerschiff braucht Wochen, bis es in Europa ist. Wenn es von Piraten überfallen wird, können daraus auch Monate werden. Bis dahin können schon etliche Partner, des ursprünglich vorgesehenen Geschäftsablaufs, ausgetauscht worden sein. Wenn keine Möglichkeit besteht, den einmal gestarteten Prozeß  nachträglich an die geänderten Rahmenbedingungen anzupassen, so ist er untauglich.

Beispiele

Bei Datenbanken sind die konkreten Datenstrukturen auf der Platte in der Regel nicht bekannt, sofern die Datenbank nicht quelloffen ist. Dies ist solange kein Problem, solange das jeweilige Produkt noch von irgendeinem Hersteller unterstützt wird. Die Zugriffsmöglichkeiten sind hinreichend flexibel, daß alle benötigten Manipulationen an den Daten durchgeführt werden können.

Anders sieht das bei BPEL aus. Dies ist eine neuere Technik, bei der bislang übersehen wurde, eine Zugriffsmöglichkeit auf die damit verarbeiteten Daten und Geschäftsprozesse zu definieren. Wenn mein Container in China abgeschickt worden ist, weiß ich schon Monate zuvor, daß es bei der Anlieferung Probleme geben wird, wenn die Daten aus irgendeinem Grund falsch angelegt worden sind. Machen kann man da aber in der Regel wenig.

Empfehlung

Wenn man schon ein Werkzeug wie BPEL einsetzen muß, daß die genannten Probleme aufweist, sollte das System so gebaut werden, daß das Werkzeug nur Daten intern hält, die für den Ablauf notwendig sind. Alle anderen Daten werden unabhängig - z.B. in einer Datenbank - abgelegt und intern nur referenziert. Das bedeutet konkret, daß die Daten über den Inhalt unseres Containers und die Empfänger nicht im BPEL-Prozeß gehalten werden. Statt dessen werden nur Referenznummern übergeben und die Services, die konkreten Daten benötigen holen sich diese jeweils bei Bedarf anhand der Referenzen.
Damit wird allerdings nur das Problem der beschädigten Daten gelöst. Die Anpassung des laufenden Geschäftsprozesses bleibt weiterhin ein Problem. Dies kann aber zumindest leichter von Beratern des Herstellers gelöst werden, die eventuell einen Hack im Inneren des Systems durchführen können.
Es gibt weitere Gründe für einen solchen Ansatz: Erstens wird die Verarbeitunggeschwindigkeit so erheblich verbessert, da weniger Daten bewegt werden müssen. Zweitens braucht man die Daten in aller Regel meist sowieso zu direktem Zugriff außerhalb, so daß jetzt eine doppelte Datenhaltung vermieden wird.

Nichts als Problem

Das Nichts zeichnet sich durch das Fehlen aller Dinge aus. Ein Physiker würde vielleicht sogar unterscheiden zwischen dem Nichts, bei dem es nicht mal die Dimensionen eines Raumes gibt, und dem Vakuum, dem leeren Raum. Die alten Philosophen waren der Meinung, daß die Natur immer versucht, diese Lehre zu vermeiden. Sie sprachen vom Horror Vacui. Auch dem Informatiker kann das Fehlen von Daten manchmal Angst bereiten. Es gibt zwei Probleme mit fehlender Information: was bedeutet sie und wie stellen wir sie dar.

Interpretation von fehlender Information

Es kann drei Gründe geben, warum eine bestimmte Information ein Datensatz nicht vorhanden ist:

1. Die Information ist nicht anwendbar. Zum Beispiel ist es den deutschen Adressen nicht üblich, das Bundesland anzugeben, während bei amerikanischen Adressen der Staat zugehört. Somit muß eine korrekte Modellierung einer Adresse erlauben, daß für deutsche Adressen das Feld Staat leer bleibt.
2. Information ist (noch) nicht bekannt. Die Situation tritt auf, wenn ein Datensatz schon angelegt wird, aber einige Daten erst in späteren Schritten der Bearbeitung anfallen.
3. Der leere Wert ist Information. Wenn die Bestellungen im Restaurant erfaßt werden soll und es je ein Feld für Speise und Getränk gibt, und dafür Getränk leer bleibt, so bedeutet das, daß der Gast kein Getränk bestellt hat.

Fehlende Information in Datenbanken

Bei der Modellierung von Datenbanken unterscheidet man zwischen optionalen und Pflichtfeldern. Nur bei Ersteren darf die Information fehlen. Fehlt Information in einem Pflichtfeld, so verhindert die Datenbank das Einfügen eines solchen Datensatzes. Was eine Datenbank in der Regel nicht macht, ist die Unterscheidung zwischen leerer und nicht vorhandener Information. Das heißt, es ist nicht möglich, einen Text von der Länge Null abzuspeichern.

Bei der Verwendung von optionalen Feldern sollte man beachten, daß die Suche nach leeren Feldern in der Regel sehr aufwendig ist, da sich nicht vorhandene Information nicht indizieren läßt.

Es ist durchaus möglich, eine relationale Datenbank auch so zu modellieren, daß es ausschließlich Pflichtfeld ergibt. Dies geschieht, indem man optionale Information in gesonderte Tabellen ausgelagert. Für ein einzelnes Feld ist das in der Regel nur theoretisch interessant. Wenn aber eine Gruppe von Feldern nur gemeinsam auftreten oder fehlen kann, ist die Auslagerung die sauberste Modellierung. Wenn die Daten ausschließlich gemeinsam verwendet werden, kann eine Einbuße bei der Zugriffsgeschwindigkeit bei vielen Datenbanken verhindert werden, indem man die beiden Tabellen clustert.

Fehlende Information in Objekten

Solange alles aus Objekten besteht, so wird fehlende Information in einem Objekt durch das Fehlen von Referenzen zu anderen Objekten dargestellt. Diese Darstellung hat eine große Ähnlichkeit mit der oben für Datenbanken vorgeschlagenen Modellierung zur Vermeidung optionaler Felder. Wenn nun versucht wird, über diese Referenz auf das Objekt zuzugreifen, so kommt es zu einem Fehler. In Java ist das die berüchtigte NullPointerException - ein komischer Name bei einer Sprache, die doch versprochen hat im Gegensatz zu C ohne Pointer auszukommen. Für den Entwickler bedeutet das, daß er vor jeder Verwendung eines referenzierten Objekts auch überprüfen muß, ob es wirklich existiert. Das zu vergessen ist wohl der häufigste Programmierfehler überhaupt in objektorientierter Programmierung.

Die Prüfung auf fehlende Referenzen ist ein Fall von extremer Codewiederholung. Wiederholung von Code sollte aber immer vermieden werden. Eine Möglichkeit, die Behandlung der fehlenden Information an genau einer Stelle zu konzentrieren, ist die Einführung von Objekten, die die fehlende Information repräsentieren. Das heißt, es wird ein neues Objekt definiert, daß sich von dem an dieser Stelle erwarteten ableitet und das verwendet wird, wenn die Information nicht vorhanden ist. Die Methoden werden so überschrieben, daß sie bei Aufruf die Behandlung durchführen, die sonst verteilt im Code passieren würden, wenn ein leerer Wert auftritt. Beispielsweise ist es häufig sinnvoll, bei der Ausgabe von leerer Information eine leere Zeichenkette zu verwenden. Also würde eine Funktion toString eben diese zurückgeben. Eine Addition eines nicht vorhandenen Wertes mit etwas beliebig anderem sollte meist wiederum einen nicht vorhandenen Wert ergeben. Auf diese Weise wird eine konsistente Behandlung der fehlenden Information erreicht.

Ein weiterer Vorteil dieses Vorgehens ist, daß die Möglichkeit besteht, für die oben erwähnten unterschiedlichen Interpretationen von fehlender Information unterschiedliche Repräsentationen zu haben, die entsprechend der Interpretation anders reagieren können.

Zeichenketten können fehlen oder leer sein. Wenn die Daten in einer Datenbank abgelegt werden sollen, so empfiehlt es sich, nur eine der beiden Darstellungen zu verwenden. Nach dem eben gesagten, würde ich die leer Zeichenkette vorziehen.

In Java, C# und C++ gibt es neben Objektreferenzen auch primitive Typen (Zahlen, Wahrheitswerte und Datumsangaben). Diese besitzen keine offensichtlichen Möglichkeiten mitdem Fehlen der Information umzugehen. Häufig werden als Ausweg „magische“ Werte verwendet. So kann eine negative Zahl oder ein bestimmtes Datum (z.B. 1.1.1970) für das Fehlen des Wertes stehen. Dies ist recht unschön. Eine andere Möglichkeit besteht bei Java und C# darin, grundsätzlich die auch vorhandene Objektrepräsentation der Werte zu verwenden (Integer statt int). Dies führt aber zu Performanceeinbußen, da der Compiler uns ja schon gesagt hat, daß er nicht bereit ist, intern die Verwendung der verschiedenen Darstellungen zu optimieren. In älteren Java-Versionen, die noch kein Auto(un)boxing kennen, führt das auch zu sehr unschönem Code.

C# hat ab Version 2.0 den Nullable-Wrapper eingeführt. Dieser wird von den Datentypen verwendet, deren Name mit „?“ endet, wie z.B. int?. Dies erleichtert insbesondere die Kommunikation mit Datenbanken erheblich. In anderen Programmiersprachen läßt sich so etwas leicht nachbilden.

Fehlende Information in XML

In XML muß man zuerst unterscheiden zwischen einen leeren Tag (<tag></tag>) und einem fehlenden Tag. Wenn ein XML-Schema verwendet wird, so muß das entsprechende Element im ersten Fall leere Zeichenketten zulassen (<minLength value=“0“/>) und im zweiten Fall als optional gekennzeichnet sein (minOccurs=“0“). Ein gutes Schema sollte sich um eine einheitliche Darstellung bemühen. Alles andere führt bei der Verwendung der XML-Dokumente in Schnittstellen zu endlosen Diskussionen. Persönlich würde ich in der Regel leere Tags zu vermeiden suchen, da es einige XML-APIs gibt, bei denen diese wesentlich schwieriger zu handhaben sind wie optionale Tags. Bei der Serialisierung von Daten in XML müssen dann nämlich nicht nur die Daten betrachtet werden, sondern auch das Schema, denn die fehlenden Daten können nicht das Erstellen des leeren Tags auslösen (sie fehlen ja). Dies muß über die Schemadefinition gehen.

Zusätzlich gibt es noch eine dritte, in meinen Augen etwas obskure, Methode in XML mit fehlender Information umzugehen: nillable. Hier ein Beispiel direkt von der W3C-Website geklaut:

<xsd:element name="shipDate" type="xsd:date" nillable="true"/>

<shipDate xsi:nil="true"></shipDate>

Elemente, die keine Information haben, bekommen hier also das Attribut xsi:nil=”true”. Wozu das gut sein soll, muß mir noch mal jemand erklären. Eigentlich zeigt ja schon das leere Tag, daß da nichts ist. Diese Darstellung wird nur selten benutzt; daher kann man sich auch nicht darauf verlassen, daß jede API sie unterstützt. Falls es nicht sehr, sehr gute Gründe gibt, sollte man von der Verwendung absehen.

Ausweichverhalten des Benutzers

In zahlreichen Anwendungen findet man Eingabefelder, die einen Wert verpflichtend erwarten. Wenn man aber nachher in die wirklich erfaßten Daten schaut, so findet man, daß dort meist nur ein Punkt („.“) oder ein „x“ stehen. Dies bedeutet, daß das Feld für die Bearbeitung nicht wirklich relevant ist und die Benutzer die genannten Werte als Ersatzdarstellung für fehlende Information verwenden. Dies erhöht die Nutzbarkeit der Daten nicht gerade. In diesem Fall sollte eine Änderung der Datenmodellierung erwogen werden, die diese Felder optional macht.

Und die Lehre von der Geschicht …

Fehlende Information kann unterschiedlich interpretiert werden. Die verschiedenen Techniken, die wir zur Erstellung einer Anwendung verwenden, haben unterschiedliche und nur beschränkt miteinander kompatible Darstellungen dafür. Wenn man keine klare Strategie hat, wie man damit umgehen will, handelt man sich jede Menge von Ärger ein. Leider wird dieses Problem von den meisten Softwarearchitekten sträflich ignoriert. Die Entwickler kommen dann mit einer Vielzahl von meist ad hoc gefundenen Lösungen und bei der Integration kommt es zu teuren aber vermeidbaren Problem.

Satyam

Der viertgrößte IT-Anbieter Indiens ist von einem Finanzskandal betroffen. Es besteht der Verdacht, daß die Gewinne der letzten Jahre nicht erarbeitet wurden, sondern kreativer Buchführung zu verdanken sind. Dies wurde in den letzten Wochen in den Wirtschaftsseiten der Zeitungen ausgiebig diskutiert. Die Vorgänge setzen ein Fragezeichen für die gesamte indische Softwarebranche. Allerdings haben die meisten Kommentatoren immer noch eine gute Chance gesehen, daß der Aufschwung in Indien weitergehen könnte, wenn die Firmen, die jetzt von der Finanzkrise betroffen sind, weitere Einsparmöglichkeiten suchen werden. Ich muß allerdings gestehen, daß mich die Ereignisse weniger überrascht haben, als der Umstand, daß es solange gedauert hat, bis es dazu gekommen ist. Wenn man in der Branche arbeitet, lernt man mit der Zeit immer mehr große Softwareprojekte kennen, die von indischen Firmen übernommen wurden und dann scheitern. Entweder werden sie mit großer Verspätung geliefert oder ganz aufgegeben. Es geht da um wirklich große Beträge. Wenn bei Airbus sich die Fertigstellung einer A380 verspätet, befindet sich die Firma in einer Krise. Trotz offensichtlicher Rückschläge bei den indischen Softwarefirmen hörte man bislang aber nur Erfolgsmeldungen.

Zudem habe ich Zweifel, ob es im Geschäft mit der Produktion von Individualsoftware den indischen Firmen wirklich gelingen kann, wesentlich günstiger zu produzieren wie einheimische Konkurrenten. Wenn ich damit recht habe, so rechnen entweder die Auftraggeber falsch oder die Inder zahlen bei vielen Projekten drauf.

Softwareproduktion in Indien

Die indische Softwareindustrie ist in den letzten Jahren enorm gewachsen. Jedes Jahr stellt sie Tausende neue Mitarbeiter ein. Das ist die optimistische Sicht der Dinge. Die Kehrseite ist, daß ein großer Teil der Mitarbeiter kaum Erfahrung hat. Die billigen Kräfte besitzen die Qualifikation eines Studenten, wie wir ihn in den 90er Jahren bei uns mitarbeiten haben lassen zu einem Stundenlohn unter dem eines indischen Mitarbeiters. Allerdings hatten wir dann immer Kandidaten für Neueinstellungen, die wir genau kannten und die praktisch keine Einarbeitung brauchten.

In Indien herrscht eine große Fluktuation von Mitarbeitern. Wenn man Leute eingearbeitet hat und sich das Projekt verzögert, so haben die Leute innerhalb kürzester Zeit einen neuen Arbeitsplatz. Bei einem anspruchsvollen Projekt braucht es aber eher Monate als Wochen, bis sich ein neuer Mitarbeiter eingearbeitet hat. Durch den Weggang eines Mitarbeiters entstehen so erhebliche Kosten. Daher werden mindestens zweimal soviele Mitarbeiter bei einem indischen Projekt gebraucht, als es bei einer stabilen Belegschaft notwendig wäre. Damit schmilzt der Vorsprung bei den Lohnkosten zusammen.

Individualsoftware und Kommunikation

Bei der Erstellung von Individualsoftware wird die Software nach de Spezifikation des Kunden erstellt. Die Kunst der Softwareerstellung besteht aber darin, aus einer zunächst unpräzisen Beschreibung in natürlicher Sprache ein präzises, nach den Gesetzen der Logik ablaufendes Computerprogramm zu erstellen. Wenn man in der Lage wäre, vollständige, widerspruchsfreie und in sich abgeschlossene Beschreibungen zu erstellen, würde man danach keine weiteren Entwickler mehr benötigen, sondern könnte die Software daraus automatisch erstellen. Aus dieser Überlegung ergibt sich aber zwingend, daß der Softwareentwickler einen großen Teil des Tages damit verbringt, Unklarheiten aus den ihm vorliegenden Konzepten zu klären. Dies erfordert einen Dialog mit dem Kunden. Je schwieriger dieser Dialog ist, desto teurer wird die Softwareentwicklung und desto größer ist die Gefahr des Scheiterns des Projekts.

Die Kommunikation eines indischen Softwareentwicklers mit einem europäischen Kunden erfolgt aber meist nur indirekt über mehrere zwischengeschalteten Personen. Dazu kommen Probleme wie Zeitverschiebung und Sprache. Bei Sprache geht es nicht nur darum, daß die mündliche Ausdrucksfähigkeit der meisten Inder im Englischen eher beschränkt ist. Noch schwieriger ist es, die problemspezifische Sprache des Kunden zu dem Entwickler zu bringen. Jede Firma hat ihre eigene Art, sich auszudrücken, die außerhalb oft schwer verständlich ist. Wenn der Entwickler nie direkten Kontakt mit dem Kunden hat, wird es da immer zu Mißverständnissen kommen.

Wert des Wissens

Es ist bekannt, daß die Software auf den Unternehmenssystemen für heutige Firmen oft einen erheblichen Wert darstellt. Was sich die meisten Firmen nicht klar machen, ist, daß dieser Wert zu einem nicht unerheblichen Teil im Wissen der Leute besteht, die die Software entwickeln. Wenn die Softwareentwicklung ausgelagert wird, gehen damit Werte verloren, die meist nicht beziffert werden. Wenn dann der neue Anbieter ausfällt, so wird es noch teurer, da dann eine kontrollierte Übergabe nicht mehr realisierbar ist. Die Auswirkungen können für die betroffenen Firmen existenzbedrohend sein.

Die Geschäftssoftware bildet die Geschäftsprozesse des Unternehmens ab. Diese stellen aber die Grundlage eines Vorsprungs gegenüber der Konkurrenz dar. Wenn dieses Wissen aus dem Unternehmen ausgelagert wird, besteht die Gefahr, diesen Vorsprung zu verlieren.

Stärken der Entwicklung in Indien

Software, bei der eine Einbeziehung eines Kunden nicht notwendig ist, kann heute kaum noch zu konkurrenzfähigen Preisen in Westeuropa oder Nordamerika entwickelt werden. Es handelt sich hierbei um Software, die Dinge abbildet, die z.B. durch Standards definiert sind. Gleiches gilt für Softwareprodukte, deren Funktion allgemein bekannt ist, wie zum Beispiel Textverarbeitungsprogramme.

Auch Entwicklungswerkzeuge lassen sich nur noch in Ländern mit günstigen Löhnen produzieren, auch wenn hier Osteuropa führend ist. Dadurch, daß viele kostenlose Open-source-Programme zur Verfügung stehen, lassen sich keine Preise mehr realisieren, die eine Entwicklung woanders erlauben würde.

Auch hat die indische Softwareindustrie einen großen Vorteil auf dem asiatischen Markt, da sie eben da näher dran ist und besser mit dem Kunden kommunizieren kann.

Konsequenz

Firmen, die meinen, Geld einsparen zu können, indem sie die Softwareentwicklung nach Indien verlagern, sollten sich wesentlich besser der Risiken bewußt werden und die Einsparmöglichkeiten realistischer einschätzen. Geschieht das nicht, so ist leicht die Existenz der betroffenen Firmen in Frage gestellt.

Man muß sich die Frage stellen, ob die Versprechungen der großen indischen Softwarehäuser wirklich mehr Wert sind, als die der Lehman Bank für eine sichere Anlage und die der Madoff-Fonds für eine stabile Rendite.

Wenn Geld eingespart werden soll, so gibt es gewöhnlich enorme Einsparmöglichkeiten durch effizientere Entwicklung. So sind viele Projekte grotesk mit Mitarbeitern überbesetzt, die sich nur gegenseitig im Wege stehen. Hier liegen die größeren Chancen füer Einsparungen.

Der Schrecken am Ende

Bei der Entwicklung neuer Software wird gewöhnlich darauf geachtet, daß die Software am Ende fehlerfrei den Anforderungen entspricht. Was häufig nicht betrachtet wird, ist, daß sie nachher auch betrieben werden muss. Es gibt eine ganze Menge technische Aspekte zu beachten, aber heute will ich nicht darauf beschränken, zu überlegen, welche Leute dafür nötig sind, den Betrieb aufrechtzuerhalten. Es ist ja nicht so, dass die Software entwickelt wird, und dann an irgendein Rechenzentrum übergeben wird, wo sicheine Wartungsmannschaft darum kümmert, daß die Software auf den Rechner zur Verfügung steht. Vielmehr muß die Software auch gewartet werden. Wenn wir ein hübsches System ausgedacht haben mit allen möglichen interessanten Technologien, laufen wir da leicht in eine Falle. Während der Entwicklung hatten wir all die Leute, die auf die kompliziertesten Aspekte der Architektur verstanden haben und auch denjenigen, der mal schnell ein Regelsystem aufsetzen konnte, mit dem wir die Dinge, bei denen die Anforderung unklar waren, so schön flexibel realisieren konnten. Wenn jetzt im Betrieb aber ein Problem auftritt, sind all diese Leute dann noch vorhanden? Das erste Problem ist offensichtlich. Während des Betriebes steht häufig ein wesentlich kleineres Budget für Softwareentwicklung zur Verfügung, so daß wir all die Leute überhaupt nicht bezahlen können. Gleichzeitig wird aber Softwaresupport das ganze Jahr über angefordert. Wenn die Kenntnis einer bestimmten Technik aber nur bei einer oder weniger Personen, so ist mit einem Engpaß zu rechnen, da diese Personen auch krank werden können und Anspruch auf Urlaub haben. Ein anderer Aspekt wird gewöhnlich ignoriert. Die Leute, die während der Entwicklung die kreativsten Ideen haben, sind meistens nicht bereit, Wartung zu machen. Das ist nicht böser Wille, sondern die Aufgaben setzen unterschiedliche Persönlichkeiten voraus. Wer lange Zeit Softwarewartung macht, der bindet seinen beruflichen Wert an das von ihm gewartete System. Will man Leute für diesen Job haben, so muss man ihnen eine gewisse Sicherheit bieten. Leute, die freiwillig Softwarewartung machen, sind daher häufig auch solche, die genau so eine Sicherheit suchen. Die besten Ideen bei der Entwicklung eines neuen Systems kommen hingegen von Leuten, für die Sicherheit weniger wichtig ist, die in ihrer Arbeit vielmehr Selbstverwirklichung und Abenteuer suchen. Um ein wartbares System zu bekommen, ist es demnach auch wichtig, die verwendeten Technologien so auszuwählen, daß sie schließlich auch von der Verfügung stehenden Wartungsmannschaft betreut werden können. Auch wenn es noch so attraktiv scheint, daß irgendwelche Heinzelmännchen heimlich die kompliziertesten Probleme lösen, so muß doch darauf geachtet werden, daß genügend Leute diese Problemlösungen auch verstehen. Um Nischentechnologien mit einzusetzen, reicht es nicht, daß wir zufällig einen Experten dafür besitzen, sondern wir müssen auch einrechnen, daß wir weitere Leute in dieser Technologie ausbilden müssen.