Jak modernizować legacy - krok po kroku

Ostatnio miałem serię warsztatów dotyczących wychodzenia z firmy bagna Legacy. Chciałem następnie wysłać uczestnikom maila z podsumowaniem co zrobiliśmy. Ale zgodnie z artykułem Your words are wasted Hanselmana postanowiłem napisać blogposta. 😀

Poniższy artykuł jest artykułem wysokopoziomowym - znajdziecie tutaj listę kroków wraz z odnośnikami do dokładniejszych materiałów. W ramach rozwoju bloga postaram się linkować do własnych treści.

Widzę, że również Nick Tune zaczął pracować nad swoją książką odnośnie refaktoryzacji Architecture Modernization. Sama książka rozwija ten temat bardzo mocno, więc jeśli jesteście zainteresowani to polecam również.

Oki, to lecimy!

Stan początkowy

Stan początkowy to zwykle jest system, gdzie wszystko jest połączone ze wszystkim. Poszczególne funkcjonalności przechodzą przez cały system pobierając i zmieniając dane w sposób niepożądany. Baza danych jest otwarta na wszystko jak idzie. Mamy zerową widoczność jak przebiegają nasze procesy w kodzie. Rzeczy są łatane na ad-hoc.

Jeszcze gorzej jak do tego dodaliśmy mikroserwisy. 😬

Wtedy w naszym systemie pojawia sie rozproszony monolit. Wyświetlenie pojedynczej informacji klientowi to kilkadziesiąt / kilkaset dodatkowych żądań. Wszystko trwa niesamowicie długo. Gorzej jeszcze - potrafi się zerwać w trakcie, wtedy klient traci cały proces. Debugowanie procesu wymaga postawienia całego klastra aplikacji.

To wszystko ma ogromny wpływ na pracę i ogólne emocje osób w firmie. Ludzie nie wiedzą co i jak działa. Kłócą się dlaczego coś zostało zrealizowane w określony sposób. Planowanie pracy jest czasochłonne, estymaty są bardzo ogólne a jednocześnie i tak zwykle prace przeciągają się bardzo znacznie.

Co można tutaj zrobić?

Ok, to jak sobie poradzić z tą sytuacją? Jak przeprowadzić modernizację legacy?

Poniżej zbiór praktyk ode mnie - dostosowujcie je do swojej sytuacji 😊

Określenie celów

To jest krok kluczowy, aby nasza ogólna praca się powiodła. Pasuje mi tutaj cytat z Alicji z Krainy czarów:

“Czy nie mógłby pan mnie poinformować, którędy powinnam pójść?” – mówiła dalej.

“To zależy w dużej mierze od tego, dokąd pragnęłabyś zajść” – odparł Kot-Dziwak.

“Właściwie wszystko mi jedno.”

“W takim razie również wszystko jedno, którędy pójdziesz.”

Jeśli chcemy osiągnąć konkretny cel to trzeba najpierw ustalić cel. Na tej podstawie będziemy planować dalszą pracę. Pozwoli nam to również odcinać niepotrzebne zadania, kiedy widzimy że nie przybliżają nas do celu.

Cele, jakie możemy wziąć pod uwagę, są szerokie i zależne od skupienia na kwestiach technicznych, bądź biznesowych. Może to być np.

Uspójnienie procesów biznesowych w systemie.
Stopniowe przenoszenie się do chmury.
Zwiększenie wydajności dodawania nowych funkcji.
Poprawa doświadczenia użytkownika.

Można jeszcze określić KPI dla takich celów:

Co mierzymy
Jak mierzymy
Stan aktualny
Punkt docelowy

Kończymy z jasną wizją tego co chcemy osiągnąć.

Podział domeny biznesowej

Ten krok jest opcjonalny, zależny od wielkości systemu z którym się zmagamy.

W wielu przypadkach podział systemu pozwala nam lepiej zaplanować naszą pracę. Dodatkowo buduje wśród uczestników zrozumienie w którym momencie się znajdujemy i ile mamy jeszcze pracy przed sobą.

Widząc ogólny podział domeny możemy bardziej kompetentnie podejmować decyzję czy otwierać dany obszar, czy kończymy z eksploracją.

Zagłębienie się w Legacy

W tym momencie przechodzimy przez kolejne obszary biznesowe w sposób. Moją ulubioną techniką tutaj jest Event Storming. A konkretne Event Storming - Big Picture.

Prostszą techniką którą możemy tutaj wykorzystać jest również Domain Storytelling.

Niezależnie od techniki naszym celem tutaj jest szerokie rozpoznanie obecnego systemu. Musimy wspólnie (jako biznes i IT) rozumieć jego ograniczenia i problemy. Ważna jest szeroka wizualizacja. Tylko ona pozwala nam zebrać kluczowe informacje.

Spisujemy procesy, problemy, systemy zewnętrzne. Warto też pytać o usprawnienia - pozwala nam zebrać istotne informacje jak stworzyć lepsze rozwiązanie.

Tutaj możemy sobie dopasowywać strukturę warsztatu do naszych potrzeb. Możemy mieć zdarzenia z różnych poziomów (domenowe, infrastrukturalne, interfejsowe).

Synteza wiedzy

Mając niskopoziomowe informacje możemy teraz wynieść te informacje wyżej i zbudować bardziej wysokopoziomową wiedzę:

Jak proces biznesowy przechodzi przez konkretne obszary?
Jakie systemy / moduły są zaangażowane w procesy biznesowe?
Jakie istnieją systemy zewnętrzne, z którymi się komunikujemy?
Czy i jakie mamy zależności pomiędzy obszarami technicznymi?
Jak dane są podzielone przez konkretne obszary?
Kto dane zapisuje, a kto odczytuje?
Kto kieruje procesem, kto się podporządkowuje?

Zwykle naszym celem jest również określenie subdomen, oraz ich kluczowych pytań:

To pokaże nam które obszary biznesowe są rozpostarte w naszym rozwiązaniu technicznym.

Wybór obszaru modernizacji

Ten krok możemy wykonać przed, bądź po planowaniu docelowego rozwiązania. To zależy, od tego czy:

chcemy pójść bardzo wąsko i rozwiązać konkretne problemy, lub
chcemy pójść szeroko i zobaczyć całość rozwiązania.

Systemy bardzo rzadko mają jednorodną strukturę. Zwykle mamy strukturę rozproszonego grafu:

W takiej sytuacji próba zmiany elementów w środku będzie skazana na porażkę. Musimy wybrać mniejszy obszar do zmiany, aby krok po kroku wprowadzać zmiany.

Na jakiej podstawie wybierać nasz obszar zmiany:

Wybranie czegoś na brzegu.
Risk vs value.
Osiągnięcie mierzalnego celu.
PoC.

Można też zastosować technikę Core Domain Charts, która wskaże w jaki sposób będą się zmieniac nasze obszary techniczne:

Ważne by wybrać skończony obszar zmiany, zamiast próbować zrobić wszystko naraz.

Wdrażanie modernizacji

To wszystko powyżej to jest dużo pracy. A jeszcze faktycznie nie zaczęliśmy faktycznie modernizować 😅

Kiedy mamy wszystko powyższe to swoją przed nami 3 kluczowe problemy:

Jak zmienić konkretny obszar techniczny.
Jak połączyć nowy obszar techniczny z istniejącym rozwiązaniem.
Jak do tego wszystkiego dopasować organizację.

A więc na to zerknijmy.

Planowanie nowego rozwiązania

Tutaj proponuję 2 metody, w zależności od skali nowego rozwiązania:

Event Modeling - dla mniejszych obszarów i konkretnych procesów.
Event Storming Process Level - gdy chcemy zaplanować większą współpracę komponentów.

Techniki te są uzupełniające - można je stosować równolegle i łączyć wyniki w większą całość.

Obie te techniki mają konkretną strukturę i wykorzystujemy ją podczas warsztatu. Taka struktura daje nam dużą wartość - pozwala przenosić wyniki pomiędzy grupami, porównywać je, wyciągać najlepsze rozwiązania. Jednak nie jest tak, że musimy się wobec niej zamykać.

Możemy pokazać pracę na różnych poziomach, zarówno na poziomie systemowym, jak i modułowym / komponentowym. Aby to zwizualizować możemy lekko nagiąć naszą notację np.

Chcemy wydzielić Cennik jako osobną, reużywalną strukturę.
Połączenia do niej będą jednak cały czas synchroniczne - pozostałe moduły będą robiły zwykłe wywołanie w kodzie.
Wykorzystujemy do tego osobny kolor kartki, albo wskaźnik w opisie kartki aby pokazać różnicę.

Faktyczne wdrażanie nowego modułu

Tutaj naszym celem jest stopniowa transformacja istniejącego rozwiązania do stanu docelowego. Wykonujemy tą pracę krokowo - nie próbując transformować całego rozwiązania naraz.

W tym obszarze istnieje wiele problemów technicznych, na których trzeba skupić uwagę. Warto wspomnieć tematy takie jak:

Tworzenie obszarów bezstanowych.
Tworzenie obszarów stanowych.
Dekompozycja i migracja danych.
Praca równoległa dwóch rozwiązań.
Spójność transakcji biznesowych.

Wzorce na które szczególnie warto zwrócić uwagę:

i cały post dotyczący wzorców projektowania systemów.

Więcej informacji można znaleźć w następujących książkach:

Dopasowanie organizacji

Organizacja ma bezpośredni wpływ na rozwój oprogramowania. Mówi o tym prawo Conway’a. Dobrze to oddaje grafika przygotowana przez Nicka Tune’a w swoim artykule The Relationship Between Software Architecture And Business Models:

Dlatego trzeba dopasowywać strukturę organizacyjną do naszego rozwiązania.

Szerzej ten temat poruszyłem w newletterze Projektowanie organizacji, dlatego nie będę tutaj się rozpisywać. 😉

Podsumowanie

Patrząc na ten temat szerzej to praca dzieli się na 2 silne kategorie:

Dobre zrozumienie stanu bieżącego i celów zmiany.
Stopniowe planowanie i wdrażanie stanu docelowego.

Robiąc wszystko naraz jest prawie pewne, że nam się nie uda. Stopniowo wydzielając kolejne części naszego systemu mamy szansę, aby migracja się powiodła 😊