Ciągłość
Ci sami architekci przez wszystkie trzy etapy - decyzje pilnowane w kodzie, nie tylko w dokumencie.
Case study - Ryzyko systemu legacy
System, który działał, ale blokował wzrost.
Jeden z największych dystrybutorów biletów w Europie miał ugruntowaną pozycję, stałych klientów i działający system. Problem nie polegał na tym, że system przestał działać - polegał na tym, że przestał nadążać. Trzy etapy modernizacji, od migracji do chmury po jednolitą platformę urządzeń, i wzrost sprzedaży o 167%.
Rola i kontekst
Projekt prowadzili dwaj architekci - Sebastian Dąbkowski i Wojciech Kasa. Sebastian zaczął od nowego API do zamówień biletów, Wojtek prowadził modernizację części legacy, a w toku projektu zamienili się obszarami. Obaj pracowali w projekcie jako architekci rozwiązania przez wszystkie 2,5 roku i trzy etapy modernizacji. Projekt zrealizowany przed założeniem Arpeggia Studio, w ramach wcześniejszej firmy.
+167%wzrost sprzedaży
10nowych partnerów przy 66% mniejszym zespole
5miesięcy: terminal od koncepcji do sprzedaży
1baza kodu na wszystkie urządzenia
Sytuacja
System nie przestał działać. Przestał nadążać.
Klient dostarcza kompletne rozwiązania biletowe: druk biletów, sprzęt do kontroli dostępu i oprogramowanie do zarządzania sprzedażą oraz ruchem zwiedzających. Ugruntowana pozycja, stali klienci, działający system. A jednak każde nowe wymaganie rynkowe kosztowało nieproporcjonalnie dużo.
- Oprogramowanie stało na fizycznych serwerach, co oznaczało wysokie i sztywne koszty hostingu.
- Mały wewnętrzny zespół deweloperski był pod presją rosnących oczekiwań klientów.
- Skok sprzedaży online w czasie pandemii obciążył jednocześnie ludzi i architekturę.
- Każde nowe wymaganie rynkowe wymagało zmiany w monolicie, więc kosztowało nieproporcjonalnie dużo.
To klasyczna sytuacja legacy: system nie jest awarią, tylko hamulcem. Rachunek nie przychodzi w formie przestoju, tylko rosnącego kosztu każdej zmiany.
Rola architektów
Najdroższe błędy w legacy biorą się z braku ciągłości.
W projektach legacy najdroższe błędy nie biorą się z pojedynczej złej decyzji, tylko z braku ciągłości: ktoś projektuje, ktoś inny buduje, a po roku nikt nie pamięta, dlaczego coś wygląda tak, a nie inaczej. Dlatego obaj architekci zostali w projekcie przez wszystkie 2,5 roku - Sebastian i Wojtek zamienili się obszarami (nowe API do zamówień biletów i część legacy), ale odpowiedzialność za architekturę pozostała po tej samej stronie od początku do końca.
- ocena systemu legacy i nazwanie, które jego części realnie blokują biznes,
- wybór ścieżki modernizacji i obrona jej przed łatwiejszymi, ale droższymi alternatywami,
- decyzje o granicach modułów, modelu danych i integracjach,
- projekt architektury wieloplatformowej dla urządzeń sprzedażowych i bramek,
- prowadzenie zespołu deweloperskiego przez te decyzje i pilnowanie ich w kodzie, a nie tylko w dokumencie.
Decyzje, które ustawiły projekt
Cztery decyzje o tym, ile firma zapłaci za następne trzy lata.
To nie są decyzje techniczne - to decyzje o koszcie rozwoju na lata. Każdą trzeba było podjąć, obronić przed łatwiejszą alternatywą i utrzymać w czasie.
- Decyzja 01
Modularny monolit zamiast mikroserwisów na start
Najbardziej kusząca droga prowadziła prosto do mikroserwisów. Decyzja poszła w innym kierunku: najpierw przeprojektowanie systemu jako modularnego monolitu i migracja do chmury. Świadomy kompromis - szybsze wyjście na rynek, niższe koszty utrzymania, prostota operacyjna dla małego zespołu. Granice modułów wyznaczono tak, żeby późniejsze rozdzielenie było możliwe, ale nie wymuszone od pierwszego dnia.
Efekt
koniec serwerów fizycznych, niezależne skalowanie poszczególnych części systemu.
- Decyzja 02
Modułowa platforma zamiast jednego wydania
Portal biletowy stał się rdzeniem systemu. Podstawowy moduł obsługuje sprzedaż i zarządzanie ruchem zwiedzających, a kolejne funkcje - sklep online, bramki kontroli dostępu, dynamiczne ceny - dokłada się w miarę potrzeb klientów. Architektura zakładała, że każdy komponent rozwija się osobno, więc zmiana w jednym miejscu nie wymusza przebudowy całości.
Efekt
decyzja o koszcie następnych lat rozwoju, nie o wygodzie bieżącego sprintu.
- Decyzja 03
API partnerskie z synchronizacją stanu w czasie rzeczywistym
Sprzedaż przez wiele kanałów jednocześnie tworzy problem, którego nie da się rozwiązać po stronie interfejsu: dwóch partnerów sprzedających ten sam bilet. Rozwiązanie musiało siedzieć w modelu danych i w sposobie propagacji stanu. Do tego integracja z zewnętrznym marketplace'em biletowym.
Efekt
wielokanałowa sprzedaż bez podwójnych rezerwacji tego samego biletu.
- Decyzja 04
Jedna baza kodu na wszystkie urządzenia
Terminale stojące, urządzenia przenośne i EPOS z integracją do istniejących kas fiskalnych - zamiast trzech osobnych aplikacji powstała jedna, wieloplatformowa, oparta o Blazor i .NET MAUI. Ograniczenia były twarde: walidacja biletu i synchronizacja z chmurą musiały zdążyć, zanim odwiedzający dotrze do bramki, a urządzenie musiało działać przy utracie łącza. Praca offline i przetwarzanie w czasie rzeczywistym były wymaganiami architektonicznymi, nie funkcjami do dodania później.
Efekt
jedna aplikacja zamiast trzech, gotowa na pracę offline i w czasie rzeczywistym.
Rezultaty
Wzrost, którego stary system by nie udźwignął.
Migracja z serwerów fizycznych, modułowa platforma i jedna baza kodu na wszystkie urządzenia przełożyły się na wynik biznesowy, nie tylko na czystszą architekturę.
- 01
Wzrost sprzedaży o 167%
W toku całej transformacji.
- 02
10 nowych partnerów
Onboardowanych przy 66% mniejszym zespole deweloperskim.
- 03
Terminal bramkowy w 5 miesięcy
Od koncepcji do sprzedaży - o połowę szybciej, dzięki wspólnej bazie kodu.
- 04
Trwale niższe koszty
Hosting i utrzymanie po zejściu z serwerów fizycznych.
- 05
Platforma rozszerzalna
Nowe moduły bez przebudowy całego systemu.
Dlaczego to działa
Modernizacja rzadko zaczyna się od przepisania systemu.
Zaczyna się od decyzji, które części naprawdę blokują biznes i w jakiej kolejności je ruszyć, żeby każdy etap zwracał się sam.
Kolejność
Najpierw części, które realnie blokują biznes, potem reszta.
Świadomy kompromis
Modularny monolit zamiast mikroserwisów od razu. Prościej dziś, otwarte na jutro.
Koszt następnych lat
Każda decyzja mierzona kosztem rozwoju, nie wygodą sprintu.
Twój system
Twój system działa, ale blokuje zmianę, integrację albo rozwój produktu?
Zacznijmy od niezależnej oceny: co realnie hamuje, jakie są opcje i która ścieżka niesie najmniejsze ryzyko. Bez zatrzymywania działającego biznesu.
Umów rozmowę z architektem →Bezpłatne 30 minut. Poufność jest częścią procesu, NDA na życzenie.