Wir sind ein kleines, sehr spezialisiertes Unternehmen für die Verwaltung von Sozialleistungen mit einer äußerst nützlichen und robusten Sammlung von Software, von denen einige in COBOL, die meisten jedoch in BASIC geschrieben sind. Zwei hauptberufliche Berater haben dieses System in mehr als 30 Jahren geschickt gewartet und verbessert. Unnötig zu erwähnen, dass sie bald in Rente gehen werden. (Eine von ihnen wollte schon seit einigen Jahren in Rente gehen, ist aber einem Fehler treu und bleibt so, obwohl ihr Mann darauf besteht, dass Golf Vorrang hat.)

Wir haben den Weg der Umstellung auf ein System beschritten, das von einer der drei Firmen des Landes entwickelt wurde, die die von uns verwendete Software anbieten. Wir sind jetzt der Meinung, dass diese Firma zwar theoretisch in der Lage ist, den Konvertierungsprozess abzuschließen, aber nicht über die Ressourcen verfügt, um dies rechtzeitig zu tun, und wir sind der Überzeugung, dass sie nicht in der Lage sein wird, die Art von Service anzubieten, die wir ausführen müssen unser Geschäft. (Es geht nichts über die Möglichkeit, eigene Prioritäten zu setzen und die Befugnis zu haben, die Ressourcen nach Belieben zuzuweisen.)

Hardware ist kein Problem - wir können sehr effektiv auf modernen Servern emulieren. Wenn COBOL und BASIC moderne Sprachen wären, wären wir bereit, das Risiko einzugehen, dass wir in Zukunft Ersatz für unsere derzeitigen Berater finden.

Es scheint, dass es ein Geschäftsmodell für ein IT-Support-Unternehmen geben sollte, das sich auf ältere Plattformen wie diese konzentriert und das Programmier- und Softwareentwicklungstalent bereitstellt, um ein System wie das unsrige zu unterstützen die Aufgabe, jüngere Programmierer davon zu überzeugen, dass sie eine produktive und lohnende Karriere haben können, zum Teil in einer alten, nicht sexy Sprache wie BASIC.

Kurz gesagt, wie können wir als Nicht-IT-Manager diesen Übergang am besten bewältigen?

Es mag den Anschein haben, dass "es ein Geschäftsmodell für ein IT-Support-Unternehmen geben sollte, das sich auf ältere Plattformen wie diese konzentriert", aber ich persönlich denke, dass dies nur Wunschdenken von Ihrer Seite ist, da es die Herausforderungen "lösen" würde, denen Sie sich in einem Unternehmen gegenübersehen fiel sturzflug.

In alten Umgebungen stecken zu bleiben, ist nicht der richtige Weg. Und ich für meinen Teil würde das Leben eines Unternehmens nicht darauf wetten, festzuhalten, indem ich eine Firma finde, die bereit wäre, das zu tun, was Sie anscheinend nicht können.

Also keine Antwort auf die eigentliche Frage, die Sie gestellt haben, sondern aufrichtige Ratschläge, wie Sie vorankommen und gleichzeitig die Risiken einer Migration auf ein Minimum beschränken können.

Lesen Sie "So überleben Sie eine grundsätzliche Umschreibung, ohne Ihren Verstand zu verlieren"

Machen Sie nicht den Fehler eines langen Migrationsprojekts, das lange Zeit keine wirklichen Ergebnisse liefert. Lesen Sie "So überleben Sie eine grundsätzliche Umschreibung, ohne Ihren Verstand zu verlieren"

Ich kann nicht genug betonen, wie der Rat in diesem Artikel mir geholfen hat, ähnliche Probleme anzugehen / anzugehen, nachdem ich mich verbrannt habe, solche Projekte auf die "alte" Weise zu machen.

Richten Sie automatisierte Tests ein

Wenn Sie es noch nicht installiert haben (warum auch immer nicht?), Lassen Sie Ihre aktuellen Programmierer ein automatisiertes Test-Harness für Ihre Anwendungen erstellen.

Die automatisierte Testsuite sollte alle Funktionsbereiche Ihrer Anwendungen abdecken. Es sollte die aktuellen Arbeitsspezifikationen in "when_X_then_Y" -Regeln der einzelnen Testfälle dokumentieren. Dies hilft sowohl dabei, Änderungen in Ihrem aktuellen Code daran zu hindern, vorhandene Funktionen zu beschädigen, als auch die Migration in eine neue Umgebung zu unterstützen.

Da es sich um COBOL und BASIC handelt, sollte sich die Testsuite wahrscheinlich auf der Ebene von Integrationstests befinden: Abarbeiten eines "festen" Satzes von Eingabedateien / Datenbanken und Überprüfen der Ausgabedateien / geänderten Datenbankinhalte bestimmter Programme (COBOL) und / oder anwendungen. Für die BASIC-Teile Ihrer Software kann dies bedeuten, dass Sie Befehlszeilenparameter hinzufügen, um bestimmte Funktionen ohne (G) UI-Eingriffe auszuführen, oder ein (G) UI-basiertes automatisiertes Testtool erwerben.

Isolieren Sie Berechnungen und andere Algorithmen

Selbst Cobol unterstützt die Vorstellung von Unterprogrammen, die von einem Hauptprogramm aus aufgerufen werden können. Isolieren Sie alle Importberechnungen und andere Algorithmen in separaten Programmen oder Modulen. Ziel ist es, eine Bibliothek von Programmen / Modulen / was auch immer zu erstellen, die die Grunzarbeit isoliert von allem, was Input sammelt und Output erzeugt.

Passen Sie das Testkabel an, um es sowohl in Ihren alten Anwendungen als auch isoliert zu testen. Dadurch wird sichergestellt, dass die Arbeit, die Sie am "alten" Code ausführen, um die Migration in eine neuere Umgebung zu erleichtern, so wenig Fehler wie möglich verursacht.

Starten Sie eine neue Reihe von Anwendungen in einer "aktuellen" Umgebung

Konvertieren Sie Ihren aktuellen Code nicht. Das Konvertieren einer Sprache in eine andere bedeutet, die Einschränkungen der alten Umgebung der neuen aufzuerlegen. Das Ergebnis ist oft weniger als wünschenswert (lesen Sie: Das Ergebnis wird schrecklich sein und ein Schmerz, den es zu erhalten gilt). Wandern. Nehmen Sie sich die Zeit, um Ihre Anwendungen in der neuen Umgebung so einzurichten, dass sie als Best Practice für diese Umgebung gelten.

Holen Sie sich dazu neue Programmierer, die sich in der von Ihnen gewählten Umgebung auskennen. Machen Sie es vom ersten Tag an zur Priorität, alle wichtigen Berechnungen und Algorithmen in separaten Klassen und / oder Paketen zu isolieren und hinter Schnittstellen zu verstecken. Verwenden Sie die Abhängigkeitsinjektion (die billigste Art der DIY-Abhängigkeitsinjektion), um Ihrer neuen Anwendung mitzuteilen, welche Klassen instanziiert / für die Berechnungen verwendet werden sollen.

Dies ist ohnehin eine gute Möglichkeit, Dinge zu tun, und in Ihrem Fall können Sie diese wichtigen Teile fallweise migrieren. Außerdem werden die Schwierigkeiten beim Aufrufen von Basis- und / oder Cobol-Programmen vor den aufrufenden Funktionen in der neuen Umgebung verborgen.

Gehen Sie nicht weiter als bis zur Einrichtung der Anwendungen und vielleicht bis zur Einrichtung der wichtigsten Ein- / Ausgabefunktion, die eine Berechnung aus Ihrer COBOL / BASIC- "Bibliothek" verwendet.

Integrieren Sie Ihre COBOL / BASIC "Bibliothek"

Finden Sie heraus, wie Sie Ihre COBOL / BASIC-Bibliothek in Ihrer neuen Umgebung aufrufen können. Dies kann das Einrichten von Parameterdateien oder Datenbanktabellen sowie das Ausführen eines COBOL / BASIC-Programms umfassen, das die zuvor eingerichtete COBOL / BASIC-Bibliothek umschließt. Wenn Sie Glück haben, können Sie mit Ihrer BASIC-Version möglicherweise DLLs erstellen, die direkt aufgerufen werden können.

Implementieren Sie die Klasse in Ihrer neuen Umgebung, die die COBOL / BASIC- "Bibliothek" aufruft, und testen Sie sie mit denselben Tests, die sich im Testgeschirr der alten Umgebung befinden, jetzt jedoch in Form von Komponententests in der neuen Umgebung .

Ja, dies bedeutet, die Tests zu "duplizieren", aber es ist ein Sicherheitsnetz, auf das Sie nicht verzichten möchten. Schon allein deshalb, weil diese Komponententests später als Tests dienen, um die Implementierung Ihrer Berechnungen und Algorithmen zu überprüfen, wenn sie in Ihre neue Umgebung migriert werden.

Aber noch einmal: Gehen Sie nicht weiter, als die Einheitentests für die Berechnung (en) hinzuzufügen, die von der Einzelnen verwendet werden, die aus dem vorherigen Schritt am wichtigsten ist.

Erarbeiten Sie die neuen Anwendungen in Iterationen

Entwickeln Sie die neuen Anwendungen, indem Sie die vorherigen beiden Schritte für alle Funktionen in Ihren alten Anwendungen wiederholen. Fügen Sie immer wieder die Komponententests hinzu, mit denen die Berechnungen im Testkabel Ihrer neuen Anwendung überprüft werden. Verwenden Sie die Integrationstestsuite, um zu überprüfen, ob die migrierten Funktionen mit Ihren alten Anwendungen identisch sind.

Migrieren Sie die Kernbibliothek in Iterationen

Und schließlich migrieren Sie die Berechnungen und Algorithmen in Ihrer COBOL / BASIC- "Bibliothek" und implementieren Sie sie erneut in Ihrer neuen Umgebung. Wiederholen Sie dies iterativ, indem Sie die (Einheiten-) Tests verwenden, um Ihre geistige Gesundheit zu erhalten.

Es hört sich so an, als wäre diese Anwendung der "Kern" Ihres Unternehmens. In Fällen, in denen ein System oder ein Prozess das ist, was Ihr Unternehmen ist, ist dies ein Fall, in dem Sie Ihre eigene benutzerdefinierte Lösung haben.

Du hast darauf angespielt. Leider ist dies angesichts der langen Zeit, die Sie seit der Aktualisierung Ihrer Technologien vergangen sind, ein äußerst schwieriges Unterfangen.

Ich würde eine von zwei Routen empfehlen.

1. Stellen Sie eine IT-Gruppe aus Entwicklern / Projektmanagern / QE / Operations zusammen und bauen Sie Ihr System schrittweise aus, wie in der eher technischen Antwort oben angegeben. Dies wird jedoch außerordentlich teuer sein.
2. Suchen Sie nach einem qualifizierten Berater für kundenspezifische Entwickler, anstatt nach einem Standardanbieter. Diese Gruppe kümmert sich um alle Ressourcen, um Ihr neues System aufzubauen, und Sie können es dann mit weniger Personal als Option 1 nach Hause bringen, um fortzufahren. Diese Option birgt unterschiedliche Risiken. Die Auswahl eines guten Anbieters kann jedoch für Nicht-Techniker sehr schwierig sein. Sie können auch ein sehr hohes Risiko mit Kostenüberschreitungen usw. darstellen. Um diese Route zu verringern, erstellen Sie mit Ihrem vorhandenen Personal einen sehr detaillierten Satz von Anforderungen (aus Sicht des Nutzers) für Ihr Gebot. Dann fordern Sie auch Festpreisangebote an.

Viel Glück, Sie haben etwa 20 Jahre Erbe zu überwinden. Es wird nicht billig, einfach oder sauber sein.

Suchen Sie nicht nach einer Firma, die Ihre Legacy-Software wartet, oder nach einer Firma, die Ihre Legacy-Software neu schreibt, sondern nach einer Firma, die einen kontinuierlichen Service für das Verwaltungssystem bietet. Auslagern der Probleme bei der Entscheidung, ob die Software neu geschrieben werden soll, welcher Zeitplan festgelegt werden soll, welche Sprache (n) oder welche Tools verwendet werden sollen.

Ja, die offensichtlichen Kosten dieses Ansatzes könnten die offensichtlichen Kosten für die Einstellung neuer Programmierer übersteigen. Nach Ihrer eigenen Einschätzung sind Sie jedoch kein IT-Manager und es ist leicht vorhersehbar, in welchen Szenarien Sie Entscheidungen treffen, die Ihr Unternehmen letztendlich mehr kosten als die offensichtliche Kosten für das Outsourcing.