Wie auf der Seite Konzept: Weiterentwicklung eines traditionellen Systems beschrieben, gehen wir von
zwei Dingen aus, wenn wir von traditionellen Systemen reden:
-
Das System ist groß und alt.
-
Die ursprüngliche Entwicklung des Systems wurde nicht mit RUP durchgeführt.
Dieser letzte Punkt bedeutet in der Regel, dass die Entwicklungsarbeitsergebnisse (sofern vorhanden) nicht die üblichen
RUP-Namen haben und nicht in der Form vorliegen, die wir in RUP erwarten. Sehr häufig fehlen sie einfach, sind veraltet
oder sind so alt, dass man nicht mehr darauf vertrauen kann, dass sie für das System noch relevant sind. Wir können
davon ausgehen, dass andere Techniken verwendet wurden: Das Design wurde nicht mit objektorientierter Technologie
erstellt, die Anforderungen verwenden keine Anwendungsfälle usw.
Wir gehen auch davon aus, dass das traditionelle System ein bedeutendes Asset darstellt, das wirklich wert ist, in ein
oder anderer Form wiederverwendet zu werden, und nicht vollkommen verworfen werden muss. Also muss der Wert des
aktuellen Assets bewertet werden: Liegt der Wert in dem Code? Dem Design? Den Anforderungen? Einigen Algorithmen oder
Daten? Oder nur dem Marktsegment, den das Produkt beherrscht? Je älter das System ist, desto schwieriger ist es leider,
die vorhandenen Assets zu erfassen und zu verwenden. Die Softwaredokumentation ist sehr häufig veraltet, und das Design
muss - manchmal aus dem Code selbst - rückentwickelt werden (d. h. es ist eine "Designwiederherstellung" erforderlich).
Sich mit einem traditionellen System beschäftigen zu müssen, wird häufig als negativ empfunden, aber die Existenz eines
"Vorgängersystems" als Vergleichspunkt und als Informationsquelle ist in der Tat sehr wertvoll. Die Definition und
Entwicklung vollkommen neuer Systeme sind schwieriger und mit mehr Risiken behaftet.
Mit Ihrem traditionellen System sind Sie in der Lage, insbesondere die folgenden Punkte einfacher zu ermitteln:
-
Anforderungen und Geschäftsregeln
-
Aus Architektursicht relevante Aspekte
-
Primäre Anwendungsfälle
-
Prioritäten, Wünsche und Verwalten von Benutzern
Die einzige Gefahr besteht darin, dass sich das traditionelle System als Bremse bei der Untersuchung und Erwägung
neuerer Ansätze erweist.
Nachdem Sie den Wert Ihres traditionellen Systems bewertet haben, können Sie einen Ansatz für seine Weiterentwicklung
definieren.
Es gibt einen weit gefassten Bereich von Änderungen, die wir im Rahmen der Weiterentwicklung durchführen können,
angefangen bei einfachen Funktionalitätserweiterungen über radikale Architekturänderungen bis hin zu einem kompletten
Neudesign und einer kompletten Neuimplementierung. Für jede Änderung werden unterschiedliche Lösungen und
unterschiedliche Ebenen von Prozessformalität angewendet. Im Folgenden finden Sie einige Beispiele für die
Weiterentwicklung von traditionellen Systemen:
Erweiterung
In einfachen Fällen müssen Sie lediglich bestimmte Funktionalität oder Features hinzufügen. Geänderte Bestimmungen,
neue Geschäftsanforderungen oder neue Features, die von Mitbewerbern auf den Markt gebracht werden, machen eine
Weiterentwicklung des vorhandenen Systems erforderlich. Je älter traditionelle Systeme sind, desto schwieriger werden
selbst einfache Zusätze. Über Jahre hinweg durchgeführte Erweiterungen beeinträchtigen die architektonische Integrität
des Systems und erschweren die Erweiterung des Systems.
Kosmetische Überarbeitung
Häufig müssen Sie nicht das gesamte System verwerfen, sondern ihm lediglich ein neues Aussehen geben und eine neue
Benutzerschnittstelle oder eine Schnittstellentechnologie verwenden, die das System mit anderen Systemen verbindet.
Eine Lösung, die darauf basiert, bestimmte Komponenten Ihres Systems zu packen und ihnen eine neue Schnittstelle zu
geben oder ihre Reimplementierung ermöglicht, kann zu einem akzeptablen Ergebnis mit minimalem Entwicklungsaufwand
führen. Dies gilt beispielsweise für viele Anwendungen, die schnell "webfähig" gemacht werden müssen.
Migration
Die Brauchbarkeitsdauer von Hardware, Betriebssystem oder Middleware des Systems ist möglicherweise überschritten. Das
System stützt sich auf Technologien, die entweder nicht mehr gepflegt werden oder nur mit hohen Kosten am Leben
gehalten werden können. Die Lösung ist hier, das traditionelle System auf eine neue Plattform (Hardware oder Software)
zu migrieren und einen Großteil der vorhandenen Software zu bewahren. Eine Anwendung, die beispielsweise für eine
DEC-VAX-VMS-Umgebung entwickelt wurde, muss schnellstens auf UNIX- oder Linux-basierte Plattformen eingesetzt werden.
Dies war beispielsweise der Fall, als wir Rational Environment (ein Produkt mit zwei Millionen Codezeilen) von unserer
proprietären Plattform auf UNIX-basierte Plattformen migriert haben, was zu dem Produkt geführt hat, das heute als
Rational Apex bekannt ist. Während Erweiterung bedeutet, neues domänenspezifisches Verhalten hinzuzufügen, bedeutet
Migration, das traditionelle System an eine andere Technologieplattform zu adaptieren. Migration hat einen weniger
erkennbaren domänenspezifischen Wert, aber die Migration nicht rechtzeitig und effizient durchzuführen, kann
schwerwiegende Konsequenzen haben.
Neuentwicklung
Wenn das traditionelle System ein geschäftskritisches System ist, deren Weiterentwicklung sich als extrem schwierig
erweist, das nicht skaliert werden kann und das sich auf veraltete Hardware- oder Softwaretechnologien stützt, müssen
Sie es möglicherweise neu entwickeln. Normalerweise gehen Sie hierbei schrittweise vor, da Sie es sich nicht erlauben
können, Ihren vorhandenen Kundenstamm zu verlieren. Dies war beispielsweise beim Canadian Automated Air Traffic System
der Fall, das auf einer sehr alten Hardware und einem Betriebssystem ausgeführt wurde, das älter war als 20 Jahre. Sie
können dagegen halten, dass diese Option nicht hierher gehört, aber selbst wenn Sie planen, ein ganz neues System zu
erstellen, sollten Sie Ihr traditionelles System nutzen, um die Schlüsselaspekte des neuen Systems zu verstehen. Es
birgt reichhaltige positive und negative Erfahrungen und Wissen in sich.
Integration
Da die Neuentwicklung eines traditionellen Systems für viele große Unternehmen aus finanzieller Perspektive nicht
durchführbar ist, bevorzugen sie es, neue Funktionen mit neuen Technologien zu entwickeln und diese neuen Anwendungen
in ihr traditionelles System zu integrieren. Dieser Ansatz, Integration von Unternehmensanwendungen (EAI, Enterprise
Application Integration) genannt, ermöglicht ihnen, auf neue Technologien umzustellen und gleichzeitig vorhandene
traditionelle Assets zu nutzen. Weitere Informationen zu diesem Ansatz finden Sie in Konzept: Integration von Unternehmensanwendungen und Technik: Traditionelle Anwendungen in moderne Architekturen integrieren.
"Alles"
Es gibt Situationen, in denen ein Unternehmen nacheinander eine Migration, eine kosmetische Überarbeitung und eine
Neuentwicklung oder Integration durchführen muss. Es muss ein traditionelles System schnellstens auf eine neue
Plattform umstellen, dem System ein brandneues Aussehen geben, das den Marktansprüchen genügt, und anschließend das
System neu entwerfen und sukzessive die alte Codebasis durch neue Technologie (Softwarekomponenten, neue Sprache und
Middleware) ersetzen, um mit den Entwicklungen auf dem Markt mithalten zu können. Dies ist der Ansatz, der die meisten
Herausforderungen und Risiken hat, aber er ist machbar.
Ein Unternehmen mit einer großen MIS-Anwendung, die mehrere Millionen Zeilen von RPG-Code (Report Program Generator)
enthält, der auf der Plattform IBM AS/400 entwickelt wurde, musste beispielsweise seinen Code nach Java konvertieren
und es im Web und auf einer breiten Palette von Windows- und UNIX-Systemen ausführen können. Dieses Unternehmen hat die
Anwendung in einem Zeitraum von zwei oder drei Jahren und mit nur geringfügiger Beeinträchtigung der Benutzer
erfolgreich in Java neu gestaltet und implementiert.
Die Vision muss einen Ansatz widerspiegeln, der aus geschäftlicher Perspektive sinnvoll ist. Sie betreiben keine
Weiterentwicklung eines traditionellen Systems einfach nur, weil es da ist. Im Allgemeinen ist es wirklich vernünftig,
traditionelle Systeme zu haben. Ihre Entwicklung oder ihr Erwerb ist gewöhnlich bereits abgeschrieben, und
wahrscheinlich gibt es keine geschäftliche Rechtfertigung, sie über Bord zu werfen. Ressourcen, die für die Pflege
eines traditionellen Systems aufwendet werden, könnte alternativ jedoch für neue Geschäftschancen eingesetzt werden.
Wenn Sie feststellen, dass Sie einfach nur "Denkmalschutz betreiben" und aus rein emotionalen oder historischen Gründen
und nicht aus sinnvollen geschäftlichen Gründen oder aus Mangel an Alternativen Ressourcen in ein System stecken, ist
es möglicherweise an der Zeit, die Kosten-Nutzen-Analyse zu untersuchen.
Eine taugliche Kosten-Nutzen-Analyse muss die kurz- und langfristigen Auswirkungen der verschiedenen Alternativen
berücksichtigen, angefangen bei einem unveränderten Betrieb des traditionellen Systems bis bin zu den verschiedenen
Optionen für die Weiterentwicklung. Die Empfehlungen der Kosten-Nutzen-Analyse müssen die kurzfristigen taktischen
Geschäftsziele und die langfristigen strategischen Zielsetzungen der Organisation gegeneinander abwägen.
|