FRAMINGHAM/MASSACHUSETTS - Anders als die "unabhängigen" weisen die bei Unternehmen angestellten Software-Entwickler den von ihnen geschaffenen Systemen keine Versionsnummern zu. Aus einem unerfindlichen Grund nehmen die firmeninternen Entwicklungsteams an, eine Anwendung werde einmal gesehrieben und dann einfach beibehalten. Dies aber ist ein Irrtum.
In den meisten traditionellen Unternehmen werden die Anwendungen so geschrieben, als hätten sie ewig Bestand - in genau der Form, in der sie geschaffen wurden. Demzufolge sind die IS-Abteilungen bemüht, ihre Systeme auf Langlebigkeit hin zu programmieren. Sie versuchen zu erahnen, wie die Anforderungen der Benutzer drei Jahre später aussehen werden .
Andererseits setzt sich langsam, aber sicher die Erkenntnis durch, daß das, was heute innovativ scheint, morgen schon überholt ist. Wie läßt sich dieses Problem lösen? Es gilt, Anwendungen in dem Bewußtsein zu erstellen, daß sie nur für beschränkte Zeit Gültigkeit haben. Diese Anwendungen werden sich nämlich zwangsläufig verändern, so wie sich auch die Organisation, für deren Automation sie entworfen wurden, verändert.
Die dem zugrundeliegende Philosophie nenne ich die "fortwährende Neuentwicklung". Es handelt sich dabei ebenso um eine Geisteshaltung wie auch um eine konkrete Methodik.
Wenn die IS-Manager beginnen, darüber nachzudenken, wie Anwendungen erstellt und benutzt werden, dann ändern sich almählich auch ihre Postulate und die Tools, die sie wählen. Hierzu zwei Beispiele: Wenn eine Anwendung sich möglicherweise drastisch wandeln wird, so baut man sie sinnvollerweise aus kleinen Modulen auf, anstatt sie als integriertes Programm zu realisieren. Für die Komponente einer Anwendung, die einer kleinen Schar von Benutzern bei der Lösung eines kritischen Problems helfen soll, ist ein schnelles Anwendungs-Generierungstool wohl die beste Wahl.
Warum wird plötzlich eine Umorientierung unserer Ansichten über die Anwendungsentwicklung nötig? Mit dem herannahenden Ende des Zeitalters der monolithischen Mainframes ist auch die Zeit für eine rigide Entwicklungsumgebung, die Teil dieser Welt war, passé. Die Komplexität der Mainframe-Umgebung diktierte viele der Programmier und Entwicklungspraktiken, die wir als notwendige Übel selbstverständlich hinnahmen.
Schon seit etwa zehn Jahren ist den Benutzern in den Abteilungen klar, daß die Dinge nicht so kompliziert und mühselig sein müssen, wie die Mainframe-Umgebung es gebietet. Doch lag die Macht in den Unternehmen bislang fest in den Händen der Mainframe-orientierten Manager.
Der Trend weg vom Mainframe hat jedoch zur Folge, daß die Anwendungen auf weniger teure Server wechseln. Je kleiner und billiger diese Systeme werden desto mehr Tools stehen zur Verfügung, die die Anwendungsentwicklung vereinfachen und beschleunigen. Da die mit dem Zutritt zum Nicht-Mainframe-Markt verbundenen Kosten relativ gering sind, finden Benutzer und IS-Manager ein immer breiteres Angebot an Tools vor, die dazu beitragen, den Traum von der fortwährenden Neuentwicklung Wirklichkeit werden zu lassen.
Bedeutet fortwährende Neuentwicklung, daß strukturierte Planungmethoden nunmehr ausgedient haben? Nein. Sie bedeutet vielmehr, daß die Anwendungen in Form kleinerer Teilkomponenten erstellt werden sollten, die sich miteinander verknüpfen lassen. Stellen Sie keine Mutmaßungen darüber an, wie die geschäftlichen Erfordernisse in zwei Jahren aussehen werden. Glauben Sie mir: Es werden auf jeden Fall andere sein.
Die einzige Annahme, von der Sie ausgehen sollten, ist die, daß die Dinge sich ändern werden. Wird bei der Entwicklung der Anwendungen die dafür notwendige Flexibilität zugrunde gelegt, so ist es viel einfacher, einer Anwendung in zwei Jahren weitere Module hinzuzufügen, ohne Teile zu zerstören, die durchaus noch brauchbar sind.
Befürworte ich folglich einen raschen Wechsel der Benutzer von herkömmlichen zu objektorientierten Anwendungs-Entwicklungsmethoden und -sprachen. Ja und nein. Für viele Benutzer die heute noch mit traditionellen Programmen, Programmierern und Systemen arbeiten, wäre ein solcher Sprung in unbekanntes Terrain zu groß.
Auf der anderen Seite müssen die Unternehmen damit anfangen, ihre Anwendungen so umzustrukturieren, daß sie rechtzeitig Teil einer fexiblen Systeminfrastruktur werden. Selbst ein traditioneller Cobol-Programmierer kann lernen, modulare, auf die Lösung von Einzelproblemen ausgerichtete Programme zu schreiben.
Daher lautet meine Empfehlung an die IS-Unternehmen, sich allmählich von der Vorstellung zu lösen, Software sei so stabil wie ein Atombunker. Zwar mag ein Bunker bei einer Katastrophe Schutz gewähren, aber im Hinblick auf sich verändernde Gegebenheiten fehlt ihm die nötige Flexibilität.
Die IS-Manager sollten sich mit den PC-Entwicklern in ihren Benutzerabteilungen zusammensetzen und sich anschauen, wie schnell diese ihre Anwendungen und Arbeitsweisen ändern, wenn sie eine neue Technik oder ein Programm entdecken, das ihnen die Arbeit erleichtert. Sie sollten ein neues Projekt auswählen und es so abwickeln, daß sie die fortwährende Neuentwicklung als Ziel vor Augen haben. Angesichts der Vielzahl neuer Tools ist die Zeit reif, um den Begriff der Anwendungsentwicklung neu zu dlefinieren.