W jaki sposób menedżer inny niż IT powinien zapewnić długoterminową konserwację i rozwój niezbędnego starszego oprogramowania?

13

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?

użytkownik105977
źródło
6
Auć! BASIC i COBOL?!? Spróbowałbym domu spokojnej starości. Czy myślałeś o „modernizacji” swojego oprogramowania?
BЈовић
2
Wystarczy dodać: produktywna, satysfakcjonująca kariera, częściowo w starym, nieseksualnym języku, takim jak BASIC. - PODSTAWOWA i produktywna, satysfakcjonująca kariera nie idzie w parze w jednym zdaniu
BЈовић
3
Istnieje wielu wykonawców i firm konsultingowych, które migrują oprogramowanie ze starszych systemów. Jednak kobol i podstawowe nie są dziedzictwem, są prehistoryczne. Chociaż to dziwne, prawdopodobnie dość łatwo jest kogoś zatrudnić, ponieważ prawdopodobnie są fajni w stylu hakerów hipster.
NimChimpsky
3
Zgadzam się z @ BЈовић w tej sprawie. Powinieneś rozważyć unowocześnienie swojego oprogramowania, zamiast próbować znaleźć wsparcie dla czegoś tak starożytnego jak BASIC i COBOL, przynajmniej ze względu na przyszłą weryfikację. Na razie możesz znaleźć starszych lub hipsterskich dzieciaków, które mogą dla ciebie kodować, ale wraz z upływem lat i zmianami paradygmatów te talenty staną się zagrożonymi gatunkami, co z kolei spowoduje powolną i stałą śmierć twojego systemu. Sam fakt, że ledwo można znaleźć programistów, powinien być czerwoną flagą, że nadszedł czas na zmianę.
Maru,
2
@ user105977 - Moja najlepsza rada to udokumentowanie obecnego systemu (jeśli nie jest jeszcze udokumentowany), aby twoi konsultanci czuli się komfortowo, gdyby zostali potrąceni przez autobus lub przejdą na emeryturę, ktoś może przyjść po nich i zarządzać projektem. Gdy masz już dokumentację projektu (specyfikacje, wymagania projektu itp.), Nie jesteś w tak złej sytuacji. Nie zgadzam się z większością komentarzy na temat tych języków, wciąż jest na nie popyt, a znajomość tych języków jest warta dużo pieniędzy. Młody programista powinien być w stanie szybko nauczyć się tych języków.
Ramhound,

Odpowiedzi:

11

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.

Marjan Venema
źródło
1
Chociaż twoja odpowiedź jest dobra, gdy się ją widzi, niestety tak naprawdę nie koncentruje się na pytaniu. Pytający jest menedżerem niezwiązanym z IT, który prawdopodobnie nie ma pojęcia, co masz na myśli, mówiąc o większości tego, co napisałeś. Potrzebuje porady w znalezieniu kogoś, kto to zrobi.
Philipp
1
@Philipp: Dobrze zauważony, chociaż powiedziałem, że nie odpowiadam na jego prawdziwe pytanie. Jestem pewien, że OP wie, jak korzystać z Google i w mojej odpowiedzi jest wystarczająca liczba wyszukiwanych haseł, aby OP mógł rozpocząć badania - lub jeszcze lepiej - aby to zrobili obecni programiści. Dodaj swoją odpowiedź dotyczącą PO, jeśli uważasz, że należy to zrobić. Heck, może nawet głosować, jeśli to zrobisz ...
Marjan Venema
Będzie potrzebował biznesowego konsultanta IT w procesie przejścia, który wcześniej pomagał w takich procesach. Konsultant nie powinien wykonywać pracy, ale powinien znaleźć ludzi wykonujących pracę, nadzorować ich i upewnić się, że program wykonuje to, co jest wymagane dla firmy. Tak, to jest drogie. Posiadanie własnego oprogramowania zawsze jest.
MSalters,
@MarjanVenema (nie wiem dokładnie, czego się spodziewałem, kiedy opublikowałem to pytanie, ale nie spodziewałem się, że prawie każdy komentarz będzie przemyślany i użyteczny - wielu myśli dla wszystkich.) Przeczytałem Twój zalecany „ jak przetrwać ”post Milsteina i post Spolskyego, na który odpowiadał, i nawet Milsteinowi nie podoba się pomysł przepisania kodu. W oparciu o nasze dotychczasowe doświadczenia komentarze Spolsky'ego na temat zagrożeń związanych z migracją danych i wartości działającego kodu są prawdziwe. Jestem zdecydowanie zmartwiony tym, że ulegam pobożnemu życzeniu, ale naprawdę chcę myśleć, że Ramhound ma rację.
user105977
1
@ user105977: Rozumiem. Tak, przepisywanie jest ryzykowne, ale nie zawsze jest możliwe do uniknięcia, a czasem najlepszym rozwiązaniem, mimo ryzyka. Dla mnie zachowanie starych systemów, polegających na zestawie umiejętności, który nawet teraz nie jest dokładnie dostępny, stanowi ryzyko biznesowe, które może być większe niż ryzyko przepisania i rośnie wraz z upływem czasu, gdy pula dostępnych programistów utrzymuje maleje. Ale nie jestem na twojej pozycji i nie mogę ocenić ich względnego ryzyka.
Marjan Venema
2

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.

Bill Leeper
źródło
1
FYI: 20 lat w świecie oprogramowania to 2 lub 3 pokolenia ludzi. To bardzo, bardzo długo. Z technologicznego punktu widzenia BASIC i COBOL są na tyle duże, że można je umieścić w muzeum ...
Radu Murzea,
Właściwie programuję od 20 lat, a COBOL trochę wyprzedza moje doświadczenie.
Bill Leeper
-2

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.

Znak wysokiej wydajności
źródło
1
Drugi akapit mówi, że już zrobili to, co sugerujesz: zidentyfikowali wszystkie trzy firmy, które zapewniają oprogramowanie do zarządzania świadczeniami. Żaden z nich się nie zakwalifikował.
MSalters,
Nie sugerowałem, żeby znaleźli firmę, która dostarczy oprogramowanie, a raczej systemową administrację świadczeniami .
High Performance Mark,