Richtlinie: Vision für Weiterentwicklung eines traditionellen Systems definieren
Diese Richtlinie beschreibt, wie ein Visionsdokument für die Weiterentwicklung eines traditionellen Systems erstellt wird.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Wert eines traditionellen Systems bewerten

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.

Ansätze für die Weiterentwicklung eines traditionellen Systems

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.

Kosten-Nutzen-Analyse auswerten

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.