- Symfony
- Symfony
- ERP
- Architektura
- Poradnik
Dual-framework: 1.4 i 5.4 w jednym ERP
Nie jest to wzorzec z broszury. Jest to sposób, żeby biznes nie czekał na idealny rewrite.
Sygnał z produkcji
-
Problem
Dwa stacki w jednym produkcyjnym ERP i presja „zrób rewrite”.
-
Decyzja
Świadome granice kerneli zamiast dnia zero.
-
Efekt
Ciągłość operacji przy migracji major.
Kiedy dual-framework ma sens
Architektura dual-framework ma koszt: dwa stacki, dyscyplina granic, świadomość że „tymczasowe” zostaje na lata. Ma też zysk: zero dnia zero, w którym nic nie działa.
Nie warto wchodzić w ten wzorzec „bo tak robią inni”. Warto, gdy przestój ERP jest droższy niż utrzymanie dwóch kernelów przez rok albo dwa.
Granice, bez których nie startować
Warunki brzegowe: wspólny model tożsamości, jasny owner modułu, zakaz spaghetti między kernelami. Docker i Linux jako stałe tło - nie jako afterthought.
Nowe fakty i KSeF mogą iść na 5.4, a operacyjny magazynek zostaje na 1.4. Testy tam, gdzie koszt błędu jest najwyższy - nie coverage dla świętego spokoju.
Co mówić biznesowi
To nie jest oferta „przepiszę Wam wszystko w sprintach”. To oferta „zostawię Wam działający system po drodze”. Rewrite bez cut-over planu to hazard, nie odwaga.
Efekty wdrożenia
- Zero dnia, w którym nic nie działa.
- Jasny owner każdego modułu.
- Wspólny model tożsamości i uprawnień.
- Koszt dwóch stacków jest jawny, nie ukryty.
Masz podobny problem w swojej firmie?
Porozmawiajmy o możliwych rozwiązaniach. Przeanalizuję Twój system i zaproponuję najlepszą ścieżkę modernizacji.