Każda organizacja ma taki system: ten, którego nikt nie chce dotykać, od którego wszystko zależy i który kierownictwo co jakiś czas postanawia „wreszcie uporządkować". Rozmowa, która po tym następuje, zwykle przeskakuje od razu do najbardziej dramatycznej opcji — wymiany — i utyka, bo cena jest nie do pomyślenia, a ryzyko jeszcze gorsze.
Dlaczego „po prostu to wymieńmy" wciąż zawodzi
Tego utknięcia można uniknąć. Modernizacja, opakowanie i wymiana nie są konkurującymi ideologiami; to narzędzia z mierzalnymi kryteriami wyboru. Właściwa odpowiedź dla danego systemu wynika z pięciu czynników — a dla większości krytycznych środowisk jest kombinacją rozłożoną w czasie, nie pojedynczym werdyktem.
Duże programy przepisywania od zera zawodzą często przez powtarzalny zestaw ryzyk. Zakres definiuje się jako „wszystko, co robi stary system" — specyfikację, której tak naprawdę nikt nie posiada, bo dekady zachowań żyją w kodzie, obejściach i głowach operatorów. Stary system zmienia się dalej, podczas gdy powstaje nowy, więc cel się przesuwa. A business case zakładał datę przełączenia, więc każde opóźnienie jest widoczne i polityczne.
Nic z tego nie znaczy, że wymiana jest zawsze zła. Znaczy to, że wymiana jest problemem architektury migracji, nie decyzją zakupową — i że porażka zaczyna się w chwili, gdy pytanie pada jako „stary czy nowy?", zamiast „co musi się zmienić, przy jakim ryzyku, w jakiej kolejności?"
Pięć czynników, ocenianych na dowodach
Pięć właściwości systemu decyduje, które tryby są w ogóle dostępne:
- Krytyczność biznesowa — co się dzieje w godzinie, w której system zawodzi? Im wyższy koszt, tym bardziej odpowiedź musi chronić ciągłość produkcji.
- Częstotliwość zmian — jak często biznes potrzebuje, by ten system się zmieniał? System stabilny pod małą presją zmian zasługuje na inne traktowanie niż ten, który blokuje roadmapę.
- Powiązania — ile innych systemów w niego sięga i jak głęboko? Powiązania decydują, czy jakąkolwiek granicę da się wytyczyć bez projektu archeologicznego.
- Ryzyko operacyjne — jak dobrze jest rozumiany? Monitoring, testy, dokumentacja i to, czy ludzie, którzy go znają, wciąż są w firmie.
- Koszt migracji — uczciwa suma: inżynieria, migracja danych, praca równoległa, szkolenia i koszt alternatywny zespołu, który to pochłonie.
Te czynniki należy oceniać dowodami — mapowaniem zależności, logami zmian, historią incydentów — a nie wrażeniami. Samo ćwiczenie regularnie koryguje założenia sali: system, który „wszyscy" ciągle zmieniają, okazuje się zmieniany dwa razy w roku; ten „dobrze rozumiany" nie ma testów i ma jednego pozostałego eksperta.
Modernizować: ewolucja w miejscu
Modernizacja oznacza ulepszanie systemu tam, gdzie stoi: redukcję powiązań, dodanie testów i obserwowalności, modularyzację wnętrza, aktualizację platformy pod spodem. Pasuje do systemów wysoce krytycznych i głęboko powiązanych — gdzie każda granica jest droga — ale których funkcjonalność jest zasadniczo słuszna.
Jej zaletą jest to, że każdy krok jest bezpieczny dla produkcji i ma samodzielną wartość. Jej granicą — to, że nie zmieni tego, czym system zasadniczo jest; jeśli model danych albo fundamentalne założenia są złe dla biznesu, praca w miejscu poleruje niewłaściwą rzecz.
Opakować: ustabilizować granicę, kupić czas
Opakowanie to umieszczenie celowego interfejsu — warstwy API, strumienia zdarzeń, granicy antykorupcyjnej — między systemem legacy a całą resztą. Wnętrze odpoczywa; środowisko wokół dostaje czysty kontrakt, na którym może budować.
Opakowanie pasuje, gdy nowe możliwości są pilne, a rdzenia nie można jeszcze bezpiecznie dotykać. Jest też naturalnym pierwszym ruchem wymiany etapowej: gdy konsumenci rozmawiają z granicą, a nie z wnętrzem, to, co stoi za granicą, może się zmieniać niezauważenie. Jego niebezpieczeństwem jest trwałość — wrapper zainstalowany jako „etap pierwszy" ma zwyczaj stawać się architekturą. Decyzja o opakowaniu powinna nieść datę, w której zostanie zrewidowana.
Wymienić: uzasadnione — i sekwencjonowane
Wymiana jest uzasadniona, gdy pięć czynników się zbiega: funkcjonalność zasadniczo zła dla biznesu, wysoka presja zmian i koszt migracji, który — zsumowany w całości — wygrywa z latami walki ze starym systemem. Nawet wtedy wiarygodna wersja jest przyrostowa: wydzielać jedną zdolność naraz za granicą opakowania, kierować ruch do nowej implementacji, sprawdzić ją na produkcji, wycofać starą ścieżkę, powtórzyć. Wzorzec strangler to nie ostrożność dla samej ostrożności — zamienia jedno ryzyko nie do przeżycia w serię ryzyk do przeżycia, każde z możliwością wycofania.
Wersją do odrzucenia jest big bang: lata równoległej budowy, jeden heroiczny weekend przełączenia i zakres zdefiniowany jako parytet funkcji z systemem, którego nikt nie zna w całości.
Łączenie trybów w jednym środowisku
Rzeczywiste środowiska rzadko dostają jeden werdykt. Częsty kształt: opakować rdzeń teraz, żeby odblokować roadmapę; modernizować komponenty, które zostają (testy, obserwowalność, rozplątywanie powiązań); wymienić dwa moduły, w których model danych jest naprawdę zły — przez granicę, jeden po drugim. Decyzja zapada per zdolność, nie per system, a kolejność wybiera ryzyko i wpływ na biznes.
Macierz w działaniu
Dla każdej zdolności systemu: ocenić pięć czynników i zadać trzy pytania po kolei: czy funkcjonalność jest zasadniczo słuszna? Jeśli tak — modernizować w miejscu. Czy granicę da się wytyczyć akceptowalnym kosztem? Jeśli tak — opakować i ocenić ponownie zza granicy. Czy uczciwy koszt migracji wygrywa z kosztem utrzymania? Tylko jeśli tak — wymieniać, przyrostowo, za granicą opakowania.
Spisana macierz robi coś cennego poza samą decyzją: zamienia „powinniśmy wreszcie uporządkować system legacy" w sekwencjonowaną roadmapę inżynieryjną, która przetrwa rewizję budżetu — bo każdy krok uzasadnia się sam.
Test trzech pytań
- Czy funkcjonalność systemu jest zasadniczo słuszna dla biznesu?
- Czy granicę da się wytyczyć akceptowalnym kosztem?
- Czy uczciwie zsumowany koszt migracji wygrywa z kosztem dalszego utrzymania?