Zrozumiałe wymagania
Agent przepisze dokładnie to, co mu pokażecie, łącznie z obejściami sprzed lat. Najpierw ustalamy, czego biznes naprawdę potrzebuje.
Nie przepisujemy Twojego systemu. Uczymy Twoje zespoły go modernizować.
Tak, żeby nie stał się legacy po raz drugi. Działamy jako zespół wspierający modernizację architektury (AMET). Przez określony czas pracujemy obok Twoich zespołów: pomagamy wybrać strategię dla każdego obszaru systemu, dowieźć pierwszy wycinek w 3-6 miesięcy i zbudować sposób podejmowania decyzji, który działa bez nas.
3-6 miesięcydo pierwszego zmodernizowanego wycinka na produkcji
Każdy obszarz osobną strategią, bo nie wszystko trzeba przepisywać
Plan wyjściazostawiamy zespół, nie zależność od nas
Niezależnienie sprzedajemy wykonania ani konkretnej technologii
AI w modernizacji
AI zmienia koszt modernizacji. Nie zmienia tego, gdzie modernizacje się wykładają.
Agenty AI potrafią wykonać dużą część dobrze przygotowanej migracji: przenieść kod, dopisać testy, przeprowadzić powtarzalne refaktoryzacje. Nie wiedzą jednak, który obszar daje Wam przewagę, które obejście chroni krytyczny proces ani gdzie poprowadzić granice. Bez tych decyzji AI po prostu szybciej przepisze stary system na nowy stos. Zanim włączycie agenty, muszą być spełnione cztery warunki.
Narzędzia do analizy kodu
Mapa zależności, granice i kontrakty, które agent ma respektować. Bez nich szybciej powstaje rozproszony monolit.
Testy charakteryzujące
Testy, które utrwalają obecne zachowanie systemu, zanim ktokolwiek, człowiek czy agent, zacznie go zmieniać.
Kontrola jakości w CI
Fitness functions i przeglądy, które automatycznie zatrzymają zmianę łamiącą architekturę, zanim trafi na produkcję.
Zespoły, które chcą pracować z agentami na co dzień, przygotowujemy też na szkoleniach AI dla zespołów IT.
Dlaczego modernizacje stają
Większość modernizacji nie upada przez technologię. Upada, bo nie rusza, traci tempo albo odtwarza stary system.
Sześć wzorców porażki, które widzimy najczęściej. Jeśli rozpoznajesz u siebie dwa lub więcej, to jest dobry moment na rozmowę.
Nie startuje.
Historia brzmi jak „dług techniczny” i „refaktoryzacja”. Zarząd słyszy koszt bez wyniku, więc modernizacja co kwartał przegrywa z roadmapą produktu.
Traci tempo.
Bieżące zgłoszenia zawsze wygrywają. Model „trzy dni modernizacji, dwa dni legacy” w praktyce kończy się na pięciu dniach legacy.
Kopiuje stary system.
Przepisanie 1:1 przenosi martwe funkcje, obejścia i stary model domeny. Nowa technologia, stara logika: legacy od pierwszego dnia.
Big bang.
Wieloletnie przepisywanie z jednym wdrożeniem na końcu. Przez ten czas biznes nie dostaje nic, a stary system nadal trzeba rozwijać.
Rozproszony monolit.
Nowe usługi wciąż czytają i piszą do starej bazy, wdrażacie je razem i w ustalonej kolejności. Macie złożoność mikroserwisów bez żadnej z ich korzyści.
Wraca do starego, gdy konsultanci wychodzą.
Decyzje podejmował ktoś z zewnątrz, więc zespół nie umie ich bronić ani rozwijać. Po zakończeniu kontraktu architektura dryfuje z powrotem.
Test diagnostyczny
9 pytań i odpowiedzi, które powinny zapalić czerwoną lampkę.
Tymi pytaniami zaczynamy każdą diagnozę. Przejdźcie przez nie z tech leadem i osobą decyzyjną. Liczy się nie to, czy znacie odpowiedź, ale jaka ona jest.
0-2 czerwone flagi Możecie startować. Wybierzcie pierwszy wycinek.
3-5 Zacznijcie od diagnozy i uporządkowania decyzji, a nie od kodu.
6+ Modernizacja w obecnej formie najpewniej utknie. Najpierw cel, mandat i dane.
- 01Biznes
Jaki wynik biznesowy ma dać modernizacja i jak go zmierzycie?
Modernizacja bez mierzalnego celu przegrywa z roadmapą produktu przy pierwszym cięciu budżetu.
Czerwona flaga: „Nowa technologia”, „spłata długu”, „mikroserwisy”. To środki, a nie wynik.
- 02Biznes
Ile kosztuje Was to, że przez dwa lata nic się nie zmieni?
Bez kosztu zaniechania nie ma pilności, a bez pilności nie ma finansowania na dłużej niż kwartał.
Czerwona flaga: Nikt nie potrafi tego wycenić ani wskazać utraconych szans.
- 03Biznes
Które obszary systemu budują Waszą przewagę, a które można kupić albo wycofać?
Od tego zależy, gdzie wydajecie budżet. Przepisywanie obszarów generycznych to najdroższy sposób na brak efektu.
Czerwona flaga: „Wszystko jest tak samo ważne.” Wtedy plan sprowadza się do przepisania wszystkiego.
- 04System
Ile modułów zapisuje do tych samych kluczowych tabel?
Wspólne dane to najsilniejsze sprzężenie w systemie. Decydują o tym, co da się wydzielić i w jakiej kolejności.
Czerwona flaga: Więcej niż jeden zapisujący do tabel w rdzeniu domeny. Zacznijcie od mapy danych, nie od kodu.
- 05System
Ile trwa droga od zmiany jednej linii kodu do produkcji?
Jeśli wdrożenie jest wolne i ryzykowne, każdy wycinek modernizacji też taki będzie.
Czerwona flaga: Tygodnie, zamrożenia kodu, ręczne wdrożenia. Najpierw ścieżka wdrożenia, potem architektura.
- 06System
Czy macie testy, które opisują obecne zachowanie systemu?
Bez nich ani zespół, ani agenty AI nie zmienią systemu bezpiecznie. Nie wiecie, co zepsuliście.
Czerwona flaga: Testów brak albo są wyłączone. Pierwszym krokiem są testy charakteryzujące, nie refaktoryzacja.
- 07Organizacja
Czy granice zespołów pokrywają się z obszarami biznesowymi?
Architektura odtwarza strukturę komunikacji w firmie. Nowy system zbudowany przez stare zespoły dostanie stare granice.
Czerwona flaga: Zespoły podzielone na warstwy: frontend, backend, baza. Odtworzycie monolit, tylko rozproszony.
- 08Organizacja
Kto ma mandat do podejmowania decyzji architektonicznych i gdzie są zapisane?
Modernizacja to setki decyzji. Jeśli nie wiadomo, kto je podejmuje, każda trwa tygodnie.
Czerwona flaga: „Wszyscy” albo „komitet raz w miesiącu”. Decyzje zapadają w korytarzu i nikt ich nie pamięta.
- 09Organizacja
Czy zarząd zaakceptuje wolniejsze dostarczanie funkcji przez pierwszy kwartał?
Modernizacja robiona „przy okazji” zawsze przegrywa z bieżącą pracą.
Czerwona flaga: Nie. Wtedy modernizacja zostanie projektem pobocznym, który nie przeżyje pierwszego kryzysu.
Podejście
Zespół wspierający modernizację. Ani wykonawca, ani wieża z kości słoniowej.
AMET to enabling team w rozumieniu Team Topologies: nie przejmuje pracy zespołów produktowych, tylko pomaga im zdobyć kompetencje i podjąć decyzje, których same jeszcze nie podejmą. Koncept opisali Nick Tune i Eduardo da Silva. Stosujemy go w modernizacjach systemów, które utrzymują biznes.
| Outsourcing przepisania | Centralny zespół architektów | AMET z Arpeggią | |
|---|---|---|---|
| Kto pisze kod | Dostawca | Twoje zespoły, według cudzego projektu | Twoje zespoły |
| Kto podejmuje decyzje | Dostawca | Architekci centralni | Twoje zespoły, z naszą facylitacją i rekomendacją |
| Co zostaje po zakończeniu | Nowy system, którego nikt w firmie nie rozumie | Dokumenty i diagramy | Zespoły i sposób podejmowania decyzji, który działa bez nas |
| Interes w przedłużaniu współpracy | Duży, bo płacisz za godziny | Rola stała z definicji | Odwrotny: kryteria wyjścia ustalamy przed startem |
| Niezależność rekomendacji | Niska, bo sprzedaje wykonanie | Średnia, bo broni swojego projektu | Wysoka: nie sprzedajemy wykonania ani technologii |
Sześć zadań AMET
Każde wyzwanie ma swoje zadanie. Nie wszystkie występują u każdego.
Na diagnozie ustalamy, które z nich są u Was realne. Zakres AMET budujemy tylko z nich.
Uruchamiamy modernizację.
Rozmowy od zarządu po support, diagnoza systemu i warsztat startowy. Wychodzicie z wybranym pierwszym wycinkiem i uzasadnieniem, które rozumie biznes.
Utrzymujemy tempo.
Rytm decyzji, limity czasu na trudne wybory, usuwanie blokad między zespołami. Gdy coś utyka, eskalujemy do CTO, zanim minie kwartał.
Facylitujemy projektowanie.
EventStorming, mapowanie domen, decyzje o granicach i wzorcach migracji. Na Waszym kodzie, z Waszymi ludźmi, a nie na przykładach ze szkolenia.
Budujemy trwałą zmianę.
Proces doradczy przy decyzjach, ADR, zasady architektury, fitness functions w CI. Mechanizmy, które pilnują kierunku także wtedy, gdy nas nie ma.
Pomagamy komunikować postęp.
Przygotowujemy liderów do opowiadania o modernizacji językiem wyniku biznesowego. Mówią Wasi ludzie, nie konsultanci.
Rozpowszechniamy lekcje.
Playbooki migracyjne, przeglądy po każdym wycinku, społeczność praktyków. Kolejny zespół zaczyna tam, gdzie poprzedni skończył.
Framework 01 · Analiza przed zmianą
Najpierw biznes, potem technologia. Najpierw historia, potem cięcie.
Zanim wybierzemy strategię, patrzymy na system w trzech perspektywach. Bez historii możecie usunąć rozwiązanie, które wciąż chroni krytyczny proces. Bez wizji przyszłości ryzykujecie drogą wymianę technologii bez żadnej korzyści biznesowej.
Dlaczego system wygląda właśnie tak?
Odtwarzamy historię decyzji: skąd wzięły się funkcje, jakie były ograniczenia, co przesądziło o technologii. Dzisiejszy „błąd” mógł kiedyś być racjonalnym kompromisem, który wciąż chroni krytyczny proces.
Jak system działa dziś?
Architektura, kod, integracje, procesy, dług i koszt zmiany. Ustalamy, co działa dobrze, co jest problemem i które elementy naprawdę wymagają modernizacji.
Co chcecie osiągnąć?
Docelowe procesy, wymagania i priorytety. Plan dojścia, który uwzględnia ryzyko, koszt i ciągłość działania biznesu w trakcie zmiany.
Framework 02 · Portfel strategii
Nie każda część systemu zasługuje na przepisanie. Wydajcie pieniądze tam, gdzie zarabiacie.
Dzielimy system na obszary biznesowe i dla każdego osobno wybieramy strategię z rodziny 5R, uzupełnionej o świadome utrzymanie. Kryteria są dwa: jaką rolę obszar gra w biznesie (rdzeń przewagi, wsparcie, generyczny) i jak często musi się zmieniać. Jedna modernizacja to zwykle kilka strategii naraz.
| Strategia | Kiedy | Co zmieniamy | Koszt |
|---|---|---|---|
| RetireWycofanie | Funkcja jest rzadko używana albo duplikuje inną. | Usuwamy. Często 20-30% legacy to kod, którego nikt nie potrzebuje. | Najniższy |
| RetainŚwiadome utrzymanie | Obszar generyczny, stabilny, rzadko zmieniany. | Bezpieczeństwo i aktualizacje, ewentualnie stabilny kontrakt (API, zdarzenia) wokół starego kodu. Decyzja, a nie zaniedbanie. | Niski |
| RehostLift and shift | Problemem jest infrastruktura: serwery, centrum danych, koszty hostingu. | Nowe środowisko bez istotnych zmian w architekturze. Szybko, ale dług zostaje. | Niski-średni |
| ReplatformZmiana platformy | Platforma się kończy: wsparcie, licencje, kompetencje na rynku. | Nowa platforma technologiczna przy zachowaniu zasadniczej funkcjonalności. | Średni |
| RefactorPrzebudowa | Rdzeń biznesu, który często się zmienia i blokuje roadmapę. | Nowa struktura i granice, własne dane, wydzielanie kawałek po kawałku, np. wzorcem strangler fig. | Wysoki |
| ReplaceZastąpienie | Obszar nie daje przewagi, a rynek ma dojrzałe rozwiązania. Albo proces zmienia się od podstaw. | Gotowy produkt lub nowy system projektowany od procesu i użytkowników, a nie od starego kodu. | Zmienny |
Framework 03 · Pierwszy wycinek
Myśl szeroko, dowieź mały wycinek, potem skaluj.
Pierwszy wycinek buduje zaufanie w obie strony: zarząd widzi, że to nie zabawa technologią, a inżynierowie, że firma naprawdę inwestuje. Dlatego wybieramy go świadomie, a nie dlatego, że był najłatwiejszy albo najbardziej palący.
Wartość modernizacji ↑
Wysoka wartość · niska złożoność
Kandydaci na pierwszy wycinek
Widoczny efekt, mało zależności. Tu budujecie wiarygodność.
Wysoka wartość · wysoka złożoność
Duże zakłady
Po pierwszym wycinku, gdy macie już platformę, wzorzec i doświadczenie.
Niska wartość · niska złożoność
Przy okazji
Dobre na rozgrzewkę zespołu albo do zrobienia w ramach bieżącej pracy.
Niska wartość · wysoka złożoność
Złożoność modernizacji →Ostatnia pasta w tubce
Dużo wysiłku, mało zysku. Często najlepiej opakować i zostawić.
Kryteria oceny kandydatów
- Wartość biznesowaCzy efekt zobaczy klient albo zarząd? Pierwszy wycinek musi być argumentem dla kolejnych.
- Ryzyko dostarczeniaIle zewnętrznych zależności, zgód i zespołów stoi na drodze? Pierwszy wycinek nie może utknąć na firewallu.
- Wartość naukiCzy przetestuje platformę, ścieżkę wdrożenia i wzorzec migracji, które potem powtórzycie?
- Sprzężenie z resztąIle tabel, wywołań i współdzielonego kodu trzeba rozplątać? Mało, ale nie zero.
- Ludzie z wiedząCzy osoby, które znają ten obszar, będą dostępne przez cały wycinek?
- Brak twardego terminuWycinek przywiązany do daty biznesowej zamienia naukę w gaszenie pożaru.
Framework 04 · Dekompozycja
Nie ma powodu biznesowego, nie ma podziału.
Większość problemów rozproszonych systemów nie wynika z samego podziału, tylko ze złego rozmiaru usług. Dlatego każdą granicę ważymy dwiema grupami sił: tymi, które ciągną system na części, i tymi, które trzymają go razem. Patrzenie tylko na pierwszą grupę to najczęstszy błąd.
Siły podziału
- Zakres i spójność funkcji
- Zmienność kodu: jedna część zmienia się co tydzień, reszta raz na kwartał
- Skalowalność i przepustowość
- Odporność na awarie
- Wymagania bezpieczeństwa i dostępu
- Rozszerzalność, gdy wzrost jest pewny
vs
Siły scalania
- Transakcje bazodanowe (ACID)
- Przepływ pracy wymagający wielu kroków między usługami
- Współdzielony kod domenowy
- Relacje danych, których nie da się rozciąć bez utraty spójności
Gdy kod ma rozpoznawalną strukturę
Sześć kroków dekompozycji opartej na komponentach
A gdy struktury nie ma? Gdy system to wielka kula błota, zamiast wyciągać kod, sklonujcie całość dla każdej przyszłej usługi i usuwajcie to, co niepotrzebne. Kompilator i testy powiedzą, co da się bezpiecznie skasować.
- 01Zinwentaryzuj i zmierz komponenty.
Rozmiar w instrukcjach i procentach kodu. Komponent, który stanowi jedną trzecią systemu, sam jest kandydatem do podziału.
- 02Zbierz wspólną logikę domenową.
Ta sama logika powielona w kilku miejscach to przyszła współdzielona usługa albo biblioteka. Trzeba ją znaleźć przed cięciem.
- 03Spłaszcz strukturę.
Kod, który nie należy do żadnego komponentu, i wspólne katalogi „utils”. Jeśli współdzielony kod to blisko połowa systemu, rozproszenie będzie bolesne.
- 04Zmapuj zależności komponentów.
Na poziomie komponentów, nie klas. Ta mapa odpowiada na pytanie zarządu: czy to wykonalne, ile kosztuje, refaktoryzować czy przepisać.
- 05Pogrupuj w domeny.
Refaktoryzacja przestrzeni nazw tak, żeby kod odzwierciedlał obszary biznesowe. Wciąż jeden system, wciąż jedno wdrożenie.
- 06Wydziel usługi domenowe.
Dopiero gdy wszystkie domeny są wyrównane. Najczęściej kilka większych usług na wspólnej bazie, a nie od razu mikroserwisy.
Framework 05 · Dane
Dane to najtrudniejsza część. Wspólna baza to nadal jeden system.
Podział bazy jest dużo trudniejszy niż podział kodu, a dane przeżywają systemy. Najgorsze migracje, jakie widzimy, to nowe usługi podpięte do starego schematu i transakcje monolitu odtworzone przez sieć. Dlatego dane rozcinamy w pięciu krokach, z możliwością zatrzymania się po każdym.
- 01
Wyznacz domeny danych.
Grupy tabel używanych razem, z ich kluczami obcymi, widokami, triggerami i procedurami.
- 02
Przypisz tabele do domen.
Osobne schematy w tej samej bazie. Synonimy jako tymczasowy most.
- 03
Rozdziel połączenia.
Każda usługa sięga tylko do swojego schematu. Reszta idzie przez usługę-właściciela. To najtrudniejszy krok.
- 04
Przenieś schematy na osobne serwery.
Przez backup i odtworzenie albo replikację, zależnie od tego, ile przestoju możecie przyjąć.
- 05
Przełącz i dostrój.
Niezależne serwery, a dopiero teraz decyzja, czy któraś domena potrzebuje innego typu bazy.
Framework 06 · Wzorce migracji
Zero big bangów. Cztery wzorce, które dobieramy do obszaru.
Każdy wzorzec ma swój koszt i warunki brzegowe. Wybór zapisujemy w ADR razem z odrzuconymi wariantami.
Strangler fig
Ruch przechodzi przez warstwę, która stopniowo kieruje kolejne funkcje do nowego kodu. Stary system kurczy się, aż można go wyłączyć.
Kiedy: Gdy da się przechwycić wejście do systemu: HTTP, kolejka, UI.
Bubble context
Nowy model domeny w izolowanej „bańce”, z warstwą tłumaczącą do legacy. Uczycie się nowego modelu bez rozpruwania starego.
Kiedy: Gdy model domeny jest zły, a ruszenie legacy zbyt ryzykowne.
Legacy za zdarzeniami domenowymi
Legacy publikuje zdarzenia biznesowe, a nie zmiany w tabelach. Nowe usługi nie znają starego schematu.
Kiedy: Gdy wiele nowych usług potrzebuje danych z legacy.
Parallel run
Stary i nowy kod liczą to samo, porównujecie wyniki, przełączacie dopiero przy zgodności.
Kiedy: Gdy błąd kosztuje dużo: rozliczenia, ceny, uprawnienia.
Mity i rzeczywistość
Sześć przekonań, które wydłużają modernizację o lata.
MitModernizacja to przejście na mikroserwisy.
RzeczywistośćModularny monolit albo kilka większych usług często wystarczy. Zespoły zbyt często od razu tną za drobno.
MitZacznijmy od łatwych kawałków.
RzeczywistośćWycinanie kawałków bez całościowego obrazu kończy się rozproszoną kulą błota. Najpierw mapa, potem cięcie.
MitPodzielimy kod, dane pójdą za nim.
RzeczywistośćDane to najtrudniejsza część. Dopóki usługi dzielą bazę, z punktu widzenia architektury nadal macie jeden system.
MitPrzepiszmy 1:1, żeby nic nie zgubić.
RzeczywistośćPrzeniesiecie martwe funkcje i obejścia sprzed lat. Najpierw ustalamy z biznesem, co naprawdę jest potrzebne.
MitReorganizacja zespołów rozwiąże problem.
RzeczywistośćBez zmiany architektury nowa struktura odtworzy stare zależności. Granice zespołów i systemu projektujemy razem.
MitJest na to best practice.
RzeczywistośćJest zestaw kompromisów dla Waszego kontekstu. Każdą decyzję zapisujemy razem z tym, co tracicie.
Jak pracujemy
Cztery etapy. Po każdym decydujesz, co dalej.
Każdy etap ma stałą cenę i własny wynik. Etapy 2 i 3 często wystarczą, żeby zespół ruszył sam. Etap 4 proponujemy tylko wtedy, gdy diagnoza pokazuje, że bez wsparcia modernizacja utknie.
- Etap 1 · Bezpłatnie
Rozmowa o systemie
30 minut o tym, gdzie jesteście: przed startem, w trakcie czy w modernizacji, która utknęła. Mówimy wprost, czy zespół wspierający ma sens. Jeśli nie, też to usłyszysz.
Co otrzymujesz
- 1.ocena dopasowania,
- 2.wstępna hipoteza problemu,
- 3.oferta ze stałą ceną w ciągu 3 dni roboczych.
Etap kończy się
Twoją decyzją, czy idziemy dalej.
- Etap 2 · 2-3 tygodnie
Trasa rozmów i diagnoza systemu
Kilkanaście rozmów od zarządu po support i analiza systemu: zależności komponentów, sprzężenia przez dane, koszt zmiany. Łączymy to, co mówią ludzie, z tym, co pokazuje kod.
Co otrzymujesz
- 1.mapa obszarów systemu z wartością biznesową,
- 2.bóle zmapowane na konkretne drivery,
- 3.wstępna strategia dla każdego obszaru,
- 4.kandydaci na pierwszy wycinek.
Etap kończy się
Raportem diagnozy i omówieniem z CTO.
- Etap 3 · 3 dni
Warsztat startowy
Z zespołami, liderami i osobą decyzyjną. Dzień 1: wizja biznesu i mapa systemu. Dzień 2: EventStorming procesu i wybór pierwszego wycinka. Dzień 3: architektura wycinka i plan na sześć miesięcy, zamknięty przez CTO.
Co otrzymujesz
- 1.wybrany pierwszy wycinek z uzasadnieniem,
- 2.architektura i wzorzec migracji,
- 3.ADR dla kluczowych decyzji,
- 4.roadmapa i backlog pierwszych zadań.
Etap kończy się
Planem, który zespół zbudował sam, i decyzją, czy AMET jest potrzebny.
- Etap 4 · 3-6 miesięcy
AMET: pracujemy obok Twoich zespołów
Facylitujemy projektowanie, pilnujemy tempa, budujemy playbooki i model podejmowania decyzji. Od pierwszego dnia wskazujemy osobę po Waszej stronie, która przejmie naszą rolę. Nasz udział maleje z miesiąca na miesiąc.
Co otrzymujesz
- 1.pierwszy wycinek w produkcji,
- 2.proces doradczy, ADR, fitness functions w CI,
- 3.playbook do powtórzenia na kolejnych obszarach,
- 4.następca prowadzący rolę architektoniczną.
Etap kończy się
Spełnieniem kryteriów wyjścia ustalonych w ofercie.
Plan wyjścia
Nasz udział maleje. Wasza samodzielność rośnie.
Najpierw prowadzimy, potem facylitujemy, potem obserwujemy i coachujemy liderów. Wychodzimy, gdy spełnione są kryteria wpisane do oferty, a nie wtedy, gdy kończy się budżet.
Mies. 1Prowadzimy
Mies. 2Prowadzimy
Mies. 3Facylitujemy
Mies. 4Facylitujemy
Mies. 5Obserwujemy
Mies. 6Coaching 1:1
ArpeggiaWasz zespół
Kryteria wyjścia
- pierwszy wycinek działa na produkcji, a kolejny jest zaplanowany bez nas,
- zespół sam prowadzi EventStorming i zapisuje decyzje w ADR,
- działa proces doradczy i regularne forum architektoniczne,
- fitness functions w CI pilnują granic, które razem wyznaczyliśmy,
- wskazany następca prowadzi rolę architektoniczną.
Co zostaje u Ciebie
Artefakty, z którymi zespół pracuje dalej.
Wszystko w edytowalnej formie, w Waszych narzędziach: Confluence, Jira, Miro, repozytorium. Należą do Was i możecie je przekazać, komu chcecie.
- 01
Uzasadnienie biznesowe modernizacji
Bóle zmapowane na drivery (łatwość zmian, testowalność, wdrażalność, skalowalność, odporność), koszt zaniechania i język, który rozumie zarząd.
- 02
Mapa obszarów i strategia dla każdego
Które obszary to rdzeń, które wsparcie, a które generyczne. Dla każdego: wygasić, utrzymać, opakować czy przeprojektować.
- 03
Diagnoza sprzężeń
Zależności komponentów, wspólny kod, wspólne tabele i realny „rozmiar” migracji, zanim ktokolwiek zacznie ciąć.
- 04
Plan podziału danych
Domeny danych, właściciele tabel, punkty sprzężenia w bazie i kolejność ich rozcinania.
- 05
Architektura pierwszego wycinka
Granice, kontrakty, wzorzec migracji, ścieżka na produkcję. Zapisane w ADR razem z odrzuconymi wariantami.
- 06
Model podejmowania decyzji
Proces doradczy, zasady architektury, forum, fitness functions. To, co zostaje, kiedy nas już nie ma.
Modularny monolit zamiast mikroserwisów, modułowa platforma zamiast jednego wydania. Wzrost sprzedaży o 167%.
Case study · Modernizacja platformy biletowej jednego z największych dystrybutorów w Europie
Przeczytaj, jakie decyzje podjęliśmy i dlaczego →Dopasowanie
Kiedy jesteśmy potrzebni, a kiedy nie.
- macie własne zespoły (zwykle 15-200 developerów) i chcecie, żeby to one prowadziły modernizację,
- system jest krytyczny dla biznesu, a koszt każdej zmiany rośnie,
- modernizacja nie ruszyła, ruszyła i utknęła albo idzie w kierunku rozproszonego monolitu,
- potrzebujecie niezależnej rekomendacji, a nie oferty na wykonanie.
- zespoły mają silne kompetencje architektoniczne, a modernizacja ma tempo. Wtedy dodatkowy zespół może przeszkadzać,
- szukacie wykonawcy, który przepisze system za Was. Pomożemy go wybrać, ale nie będziemy nim,
- nie ma osoby decyzyjnej gotowej poświęcić czas na start i przeglądy.
Na czym się opieramy
Sprawdzone podejścia, zastosowane w Waszym kontekście.
Nie wymyślamy własnej metodyki. Łączymy to, co najlepiej opisane w literaturze o modernizacji i architekturze, z doświadczeniem z systemów, które sami modernizowaliśmy.
- Architecture ModernizationNick Tune, Jean-Georges Perrinkoncept AMET, strategia per obszar, pierwszy wycinek, trwała zmiana
- Software Architecture: The Hard PartsNeal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghanidekompozycja, siły podziału i scalania, rozcinanie danych, analiza kompromisów
- Team TopologiesMatthew Skelton, Manuel Paisenabling team, strumienie wartości, obciążenie poznawcze
- Learning Domain-Driven DesignVlad Khononovtypy subdomen, granice kontekstów, sprzężenie
Częste pytania
Krótko i wprost.
Czym różnicie się od software house'u, który przepisze system?
Nie sprzedajemy wykonania, więc nie mamy interesu w tym, żeby zakres był jak największy, ani w konkretnej technologii. Pracujemy z Waszymi zespołami i od pierwszego dnia planujemy wyjście. Software house zostawia system. My zostawiamy zespół, który umie go rozwijać.
Czy piszecie kod?
Nie wykonujemy pracy za zespół, ale pracujemy na kodzie: analizujemy zależności, robimy sesje mob i pair programmingu przy trudnych miejscach, przeglądamy rozwiązania i pomagamy zbudować szkielet ścieżki na produkcję. Decyzje i kod zostają w zespole, który będzie z nimi żył.
Czy musimy przechodzić na mikroserwisy?
Nie. Często lepszym celem jest modularny monolit albo kilka większych usług domenowych. Dzielimy tylko tam, gdzie jest powód biznesowy: niezależne wdrożenia, inna skala, izolacja awarii. Tak wyglądała też modernizacja platformy biletowej, którą prowadziliśmy.
Ile osób z Arpeggii pracuje w AMET?
Zwykle jeden lub dwóch architektów, z zaangażowaniem malejącym w czasie. Skład i liczbę dni w miesiącu ustalamy w ofercie na podstawie diagnozy. Od strony klienta potrzebujemy osoby, która przejmie rolę architektoniczną, i dostępu do zespołów.
Skąd wiecie, kiedy wyjść?
Kryteria wyjścia wpisujemy do oferty przed startem: pierwszy wycinek na produkcji, działający proces decyzyjny, zespół samodzielnie prowadzący warsztaty i ADR, wskazany następca. Gdy są spełnione, kończymy, niezależnie od tego, ile zostało budżetu.
Czy AI nie zrobi tego taniej?
Zrobi taniej część wykonawczą i chcemy to wykorzystać. Agenty dobrze radzą sobie z powtarzalną migracją kodu, jeśli mają jasne wymagania, granice, testy i automatyczną kontrolę jakości. Nie zdecydują jednak, co wygasić, co przebudować ani gdzie przebiegają granice. To jest nasza rola i rola Waszego zespołu.
Co, jeśli brakuje nam ludzi do realizacji?
Pomagamy zdefiniować potrzebne role, przygotować zapytanie i wybrać wykonawcę. Potem możemy towarzyszyć mu na kluczowych etapach, tak żeby pracował według decyzji Waszego zespołu, a nie własnych.
Czy biznes musi w tym uczestniczyć?
Tak. Osoba decyzyjna jest z nami na starcie, na zamknięciu warsztatu i na przeglądach. Modernizacja bez celu biznesowego to najczęstszy powód, dla którego projekty nie ruszają albo tracą finansowanie w połowie.
Co z raportowaniem, gdy dzielimy bazę?
Planujemy to od początku. Rozcięcie bazy operacyjnej psuje raporty i ETL, które czytały wszystko naraz. W planie podziału danych uwzględniamy, skąd po zmianie będą brały dane analityka i raportowanie.
Jak to się ma do oceny ryzyka systemu legacy?
Ocena ryzyka systemu legacy odpowiada na pytanie, czy modernizować, wymieniać czy jeszcze utrzymywać. Ta strona opisuje, jak przeprowadzić modernizację, gdy decyzja już zapadła. Jeśli jej jeszcze nie ma, zaczynamy od oceny.
Czy podpisujecie NDA?
Tak, na życzenie, przed pierwszą rozmową.
Pierwszy krok
Zacznij od 30-minutowej rozmowy o swoim systemie.
Powiedz, gdzie jesteś: przed startem, w trakcie czy w modernizacji, która utknęła. Powiemy wprost, czy i jak możemy pomóc. W ciągu 3 dni roboczych dostaniesz ofertę ze stałą ceną.
Umów bezpłatną konsultację →Jeśli nie jesteśmy potrzebni, też to usłyszysz.