Jesteśmy małą, bardzo wyspecjalizowaną firmą administrującą świadczeniami, dysponującą niezwykle użytecznym, solidnym zbiorem oprogramowania, niektóre napisane w języku COBOL, ale w większości w języku BASIC. Dwóch pełnoetatowych konsultantów sprawnie utrzymało i ulepszyło ten system przez ponad 30 lat. Nie trzeba dodawać, że wkrótce przejdą na emeryturę. (Jedna z nich desperacko pragnęła przejść na emeryturę od kilku lat, ale jest lojalna wobec winy i dlatego nadal utrzymuje się pomimo nalegań męża, że ​​golf powinien mieć pierwszeństwo.)

Rozpoczęliśmy ścieżkę przejścia na system opracowany przez jedną z zaledwie trzech firm w kraju, które oferują oprogramowanie, z którego korzystamy. Uważamy teraz, że chociaż ta firma teoretycznie jest w stanie ukończyć proces konwersji, nie ma na to środków na czas i doszliśmy do wniosku, że nie będą w stanie zaoferować usługi, którą potrzebujemy nasza sprawa. (Nie ma nic lepszego niż ustalanie własnych priorytetów i posiadanie uprawnień do przydzielania zasobów według własnego uznania).

Sprzęt nie stanowi problemu - jesteśmy w stanie bardzo skutecznie emulować na nowoczesnych serwerach. Gdyby COBOL i BASIC były nowoczesnymi językami, chętnie podejmowalibyśmy ryzyko, że w przyszłości będziemy mogli znaleźć zastępców dla naszych obecnych konsultantów.

Wydaje się, że powinien istnieć model biznesowy dla firmy wspierającej IT, która koncentruje się na starszych platformach takich jak ta i zapewnia talent programistyczny i programistyczny do obsługi systemu takiego jak nasz, usuwając z naszych pleców ryzyko znalezienia odpowiedniego talentu programistycznego i przekonanie młodszych programistów, że mogą prowadzić produktywną, satysfakcjonującą karierę, częściowo w starym, nieseksualnym języku, takim jak BASIC.

Krótko mówiąc, jako menedżerowie spoza branży IT, jak najlepiej zarządzać tym przejściem?

Może się wydawać, że „powinien istnieć model biznesowy dla firmy wsparcia IT, która koncentruje się na starszych platformach takich jak ta”, ale osobiście uważam, że jest to tylko pobożne życzenie z twojej strony, ponieważ „rozwiązałoby” wyzwania, przed którymi stoisz w jednym spadł.

Utknięcie w starym środowisku nie jest drogą do przodu. I na pewno nie postawiłbym życia żadnej firmy na próbę utknięcia, znajdując firmę, która na razie byłaby gotowa zrobić to, czego najwyraźniej nie możesz.

Więc nie jest to odpowiedź na pytanie, które zadałeś, ale szczera rada na temat tego, jak możesz iść naprzód, jednocześnie minimalizując ryzyko migracji.

Przeczytaj „Jak przetrwać od podstaw, przepisz bez utraty zdrowia psychicznego”

Nie popełniaj błędu długiego projektu migracji bez żadnych realnych rezultatów przez długi czas. Przeczytaj „Jak przetrwać od podstaw, przepisz bez utraty zdrowia psychicznego”

Nie mogę wystarczająco podkreślić, w jaki sposób porady zawarte w tym artykule pomogły mi w rozwiązaniu podobnych problemów po podejściu do podobnych projektów po „starym” sposobie.

Skonfiguruj testy automatyczne

Jeśli jeszcze go nie masz (dlaczego nie?), Poproś obecnych programistów o utworzenie automatycznego zestawu testowego dla twoich aplikacji.

Zautomatyzowany pakiet testowy powinien obejmować wszystkie obszary funkcjonalne aplikacji. Dokumentuje / dokumentuje bieżące specyfikacje robocze w regułach „when_X_then_Y” poszczególnych przypadków testowych. Pomoże to zarówno w powstrzymaniu zmian w bieżącym kodzie przed zerwaniem z istniejącą funkcjonalnością, jak i wesprze migrację do nowego środowiska.

Ponieważ masz do czynienia z COBOL i BASIC, pakiet testowy powinien prawdopodobnie znajdować się na poziomie testów integracyjnych: pracować nad „ustalonym” zestawem plików wejściowych / baz danych i sprawdzać pliki wyjściowe / zmienioną zawartość bazy danych określonych programów (COBOL) i / lub aplikacje. W przypadku PODSTAWOWYCH części twojego oprogramowania może to oznaczać dodanie parametrów wiersza poleceń, aby mogły wykonywać określone funkcje bez interwencji (G) UI lub uzyskania automatycznego narzędzia testowego opartego na (G) UI.

Izoluj obliczenia i inne algorytmy

Nawet Cobol obsługuje pojęcie podprogramów wywoływanych z programu głównego. Izoluj wszystkie obliczenia importu i inne algorytmy w osobnych programach lub modułach. Celem jest stworzenie biblioteki programów / modułów / czegokolwiek, co wykonuje pomruk, odizolowany od wszystkiego, co gromadzi dane wejściowe i tworzy dane wyjściowe.

Dostosuj uprząż testową, aby przetestować je zarówno w starych aplikacjach, jak iw izolacji. Zapewni to, że praca nad „starym” kodem w celu ułatwienia migracji do nowszego środowiska spowoduje jak najmniej błędów.

Uruchom nowy zestaw aplikacji w „bieżącym” środowisku

Nie konwertuj obecnego kodu. Konwersja jednego języka na inny oznacza nałożenie ograniczeń starego środowiska na nowy. Wynik jest często mniej niż pożądany (czytaj: wynik będzie okropny i będzie trudny do utrzymania). Migrować. Poświęć czas na skonfigurowanie aplikacji w nowym środowisku w sposób uważany za najlepszą praktykę dla tego środowiska.

Zdobądź do tego nowych programistów, dobrze zorientowanych w wybranym środowisku. Postaw od samego początku priorytetem jest izolowanie wszystkich ważnych obliczeń i algorytmów w osobnych klasach i / lub pakietach oraz ukrywanie ich za interfejsami. Użyj iniekcji zależności (zrobi to najtańszy rodzaj iniekcji zależności DIY), aby powiedzieć nowej aplikacji, które klasy należy utworzyć / użyć do wykonania obliczeń.

Jest to dobry sposób na zrobienie różnych rzeczy, a w twoim przypadku pozwoli Ci migrować te ważne części na podstawie poszczególnych przypadków. Ukryje także zawiłości wywoływania programów podstawowych i / lub cobolowych przed funkcjami wywoływania w nowym środowisku.

Nie przechodź dalej niż konfigurowanie aplikacji i być może konfigurowanie najważniejszej funkcji wejścia / wyjścia, która wykorzystuje obliczenia z twojej „biblioteki” COBOL / BASIC.

Zintegruj swoją „bibliotekę” COBOL / BASIC

Dowiedz się, jak wywołać „bibliotekę” języka COBOL / BASIC z nowego środowiska. Może to obejmować konfigurację plików parametrów lub tabel bazy danych, wykonanie programu COBOL / BASIC, który otacza wcześniej skonfigurowaną bibliotekę COBOL / BASIC. Jeśli masz szczęście, twoja wersja BASIC może pozwolić na tworzenie bibliotek DLL, które można wywoływać bezpośrednio.

Zaimplementuj klasę w nowym środowisku, które wywoła „bibliotekę” języka COBOL / BASIC i przetestuj, korzystając z tych samych testów, które są w wiązce testowej starego środowiska, ale teraz w formie testów jednostkowych w nowym środowisku .

Tak, oznacza to „powielenie” testów, ale jest to sieć bezpieczeństwa, bez której nie chcesz się obejść. Choćby dlatego, że te testy jednostkowe będą później służyć jako testy sprawdzające wdrożenie twoich obliczeń i algorytmów po migracji do nowego środowiska.

Ale znowu: nie idź dalej niż dodawanie testów jednostkowych do obliczeń zastosowanych przez jeden najważniejszy z poprzedniego kroku.

Dodaj nowe aplikacje w iteracjach

Wypełnij nowe aplikacje, powtarzając poprzednie dwa kroki dla wszystkich funkcji w starych aplikacjach. Dodawaj te testy jednostkowe, które sprawdzają obliczenia do wiązki testowej nowych aplikacji. Użyj pakietu testów integracyjnych, aby sprawdzić, czy migrowane funkcje działają tak samo, jak stare aplikacje.

Przeprowadź migrację podstawowej biblioteki w iteracjach

Na koniec dokonaj migracji obliczeń i algorytmów w „bibliotece” języka COBOL / BASIC, ponownie wdrażając je w nowym środowisku. Ponownie, zrób to iteracyjnie, używając testów (jednostkowych) jako sposobu na zachowanie rozsądku.

Wygląda na to, że ta aplikacja ma kluczowe znaczenie dla Twojej firmy. W przypadkach, w których system lub proces jest tym, czym JEST Twoja firma, istnieje potrzeba posiadania własnego, niestandardowego rozwiązania.

Nawiązałeś do tego. Niestety, biorąc pod uwagę długi czas, jaki upłynął od aktualizacji technologii, będzie to niezwykle trudne przedsięwzięcie.

Poleciłbym jedną z dwóch tras.

1. Zatrudnij grupę programistów / kierowników projektów / QE / operacji i stopniowo rozbudowuj swój system, jak zauważono w dość technicznej odpowiedzi powyżej. Będzie to jednak wyjątkowo kosztowne.
2. Zamiast zwykłego dostawcy, poszukaj wykwalifikowanego niestandardowego konsultanta programisty. Ta grupa zajmie się wszystkimi zasobami, aby zbudować nowy system, a następnie możesz go wprowadzić z niewielkim personelem niż opcja 1, aby kontynuować. Ta opcja wiąże się z innym zestawem zagrożeń, jednak wybranie dobrego dostawcy może być bardzo trudne dla osób nietechnicznych. Mogą być również bardzo wysokie ryzyko z przekroczeniem kosztów itp. Aby złagodzić tę trasę, użyj istniejącego personelu, aby określić bardzo szczegółowy zestaw wymagań (z perspektywy użytkownika) dla swojej oferty. Następnie poproś o oferty o stałej cenie.

Powodzenia, masz około 20 lat dziedzictwa do pokonania. To nie będzie tanie, łatwe ani czyste.

Zamiast szukać firmy, która utrzyma starsze oprogramowanie, lub firmy, która przepisuje starsze oprogramowanie, poszukaj firmy, która zapewni ciągłą obsługę systemu administrowania świadczeniami. Zlecić na zewnątrz problemy związane z podjęciem decyzji o przepisaniu oprogramowania, o tym, jaki harmonogram ustawić, jakiego języka lub narzędzi użyć.

Tak, oczywiste koszty takiego podejścia mogą przekraczać oczywiste koszty zatrudnienia nowych programistów, ale, jak sam przyznaje, jesteś menedżerem niezwiązanym z IT i łatwo przewidzieć scenariusze, w których podejmujesz decyzje, które ostatecznie kosztują Twoją firmę więcej niż oczywiste koszty outsourcingu.