Przeczytaj wersję webową.

System z jelitami na zewnątrz

Cześć !

Trafiłem już n-ty raz na sytuację, która zdarzyła się pewnie również u Ciebie. Wydaje się, że tworzy to pewien wzorzec. Wzorzec dość patologiczny - żyjącego frankenstaina 🧟

• Podejmujemy decyzję by wynieść część funkcjonalności do osobnego serwisu. Lub chcemy dodać nową funkcjonalność obok istniejącego serwisu.
• Nie wykonujemy dobrej analizy jakie konsekwencje ma współpraca pomiędzy nowym serwisem, a starym serwisem. Jakie dane musimy mieć w nowym serwisie. Jakie musimy komunikaty przesyłać do starego serwisu. Jak zbudować niezależne procesy.
• Z racji braku głębszej analizy pracy nie wydaje się jakoś szczególnie dużo. Interesariusze dają zgodę na zmiany, w ramach określonego terminu do dowiezienia.
• Rozpoczynamy wdrażanie nowej funkcjonalności. Zaczynamy zauważać, że w nowym serwisie potrzebujemy o wiele więcej danych niż na początku zakładaliśmy. Również musimy o wiele więcej komunikatów słać do starego systemu. Procesy nowego serwisu za każdym razem muszą się komunikować z starym serwisem.
• Ilość pracy drastycznie rośnie. Mamy presję czasową w postaci terminów, które daliśmy interesariuszom. Jednocześnie nie potrafimy dobrze uargumentować problemów, jakie rodzi kontynuacja wprowadzania zmian.
• Hakujemy więc i szyjemy dalej. Coraz więcej procesów integruje się z starym systemem by działać. Coraz więcej danych wycieka poza nowy system.

Kończymy z “systemem z jelitami na zewnątrz” 😀 Procesy nie działają autonomicznie. Dane latają w jedną i drugą stronę. Stan procesów wymaga kooperacji dwóch serwisów. Wydajność obu serwisów drastycznie spada. Rozwijanie całego systemu jest mocno utrudnione.

Co robić, jak żyć? 🤔 Są tutaj trzy kwestie do zaadresowania - analizę, argumentację i naprawę.

Jak i po co analizować 🔎

• Bez dobrej analizy nie da się za wczasu zauważyć jak wielki problem stworzymy uruchamiając nowy, zewnętrzny serwis.
• Jednocześnie ilość pracy jaką sobie robimy nie analizując jest kilka rzędów wartości wyższa.
• Wymaga to jednak czasu, który sobie na taką analizę zagwarantujemy. Musimy do tego przekonać interesariuszy, że analiza się zwróci.
• Pomagają tutaj określone techniki dookoła Event Storming Process Level czy Domain Message Flow Modelling, które pozwalają przeprowadzić sensownie taką analizę.

Jak argumentować 🗣️

• Analizę trzeba sprzedawać biznesowo. Kosztuje to czas, więc biznes musi czuć, że ten nakład pracy się zwróci.
• Problemy, które występują na początku, mają charakter głównie techniczny. Jednak docelowo wpływają bardzo mocno na biznes.
• Aby dotrzeć do interesariuszy należy wykorzystywać te argumenty, które bezpośrednio ich dotykają. To, że połowa danych wycieka, nie jest dla nich problemem. To, że dodanie nowej funkcjonalności może przez to potrwać 3 razy dłużej już będzie takim problemem.

Jak zszyć pacjenta z powrotem 😅 trzeba:

1. Przeprowadzić analizę stanu faktycznego. Pokazać w którym miejscu dane latają w jedną i drugą stronę. Wskazać wszystkie te miejsca.
2. Określić cele jakie sobie postawimy wobec MVP procesu docelowego. Jakie korzyści spełnimy, jakie problemy rozwiążemy. Czego nie spełnimy w pierwszej iteracji.
3. Zaprojektować MVP. Wybrać jeden z wymiarów, który wdrożony da nam wartość, a nie zajmie roku refaktoryzacji (np. kraj czy rodzaj klienta).
4. Zbudować plan przeniesienia V1 -> V2. Jakie dane musimy przenieść. Jakie procesy zmienić w starym serwisie. Jaką komunikację usunąć, bądź dodać.
5. Przenieść część procesów na V2. Zastosować mechanizmy typu Strangler Fig, czy Change Data Capture aby zapewnić równoległą pracę obu rozwiązań.
6. Pracować dalej, aż dojdziemy do stanu pożądanego.

Nie jest to prosta decyzja, ale jedynie by poradzić sobie z trudną sytuacją. Szerzej opisałem ten proces w moim webinarze “Jak zaplanować skuteczną przebudowę systemu legacy”

A jak U Ciebie? Pracowałeś(aś) kiedyś z takim systemem? 😉

📧 Prześlij dalej

Dzięki, że doczytałeś(aś) do końca. 😊

Wszystkie poprzednie wydania newslettera są dostępne tutaj.

Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję.

A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się.

Polecam się na przyszłość!
Radek Maziarka

P.S. Co myślisz o tym newsletterze? Odpisz :)