Integracja przejściowa bez decyzji o wyjściu

Przypadek zanonimizowany. Tekst opiera się na rzeczywistym dylemacie architektonicznym, ale usuwa identyfikowalne szczegóły. Opisuje ryzyko decyzji; nie przypisuje projektowi awarii ani skutków, których nie potwierdzono.

Sytuacja

Duży projekt wdraża nowy system zaplecza. Termin jest napięty, a integracje z dotychczasowymi systemami trzeba uruchomić szybko. Zespół wybiera znany mechanizm: jeden system przygotowuje plik, pośrednia warstwa go przetwarza, a drugi system importuje dane.

Architekci zostają włączeni do oceny po obraniu kierunku. Widzą korzyść krótkoterminową: można wykorzystać sprawdzony przepływ i ograniczyć zakres zmian na starcie. Widzą też koszt długoterminowy: nowy system dziedziczy ograniczenia starego kontraktu, a każde kolejne połączenie może utrwalać rozwiązanie przejściowe.

Gdzie powstaje antywzorzec

Plik i przetwarzanie wsadowe same w sobie nie są błędem. Antywzorzec powstaje, gdy wariant dobrany na uruchomienie zostaje opisany jako docelowy bez jawnej decyzji o opóźnieniu danych, obsłudze błędów, własności kontraktu i sposobie wyjścia z tego wariantu.

Samo zdanie „kiedyś to zmienimy” nie jest planem migracji. Gdy architektura wchodzi do projektu późno, łatwo pomylić ocenę ryzyka istniejącej decyzji z jej bezwarunkową rekomendacją.

Jak rozpoznać problem

• Nikt nie potrafi wskazać właściciela formatu i zasad wersjonowania danych.
• Nie ma uzgodnionego sposobu wykrycia brakującego pliku, ponowienia, duplikatu i niepełnego przetworzenia.
• Konsumenci zaczynają zależeć od wewnętrznej struktury eksportu zamiast od stabilnego kontraktu biznesowego.
• Wariant przejściowy nie ma kryterium zakończenia, właściciela migracji ani terminu ponownego przeglądu.

To pytania kontrolne, a nie twierdzenie, że każda z tych sytuacji wystąpiła w projekcie źródłowym.

Jak podjąć uczciwą decyzję

1. Nazwij wariant przejściowym, jeśli taką pełni rolę. Zapisz powód wyboru i koszt odstępstwa od kierunku docelowego.
2. Opisz kontrakt danych, częstotliwość, oczekiwane opóźnienie, kontrolę kompletności, ponowienia, idempotencję oraz odpowiedzialność za błędy.
3. Porównaj wariant z docelowym sposobem integracji według konkretnych potrzeb. API lub zdarzenia nie są lepsze automatycznie; znaczenie mają świeżość, skala, odporność i koszty zmiany.
4. Nadaj właściciela planowi migracji. Zapisz kryteria jej rozpoczęcia, backlog, testy zgodności i termin przeglądu decyzji.
5. Oddziel opinię architektury od decyzji projektu o terminie i ryzyku. Akceptacja wyjątku nie powinna po cichu zmieniać standardu architektonicznego.

Reguła do zapamiętania

Kompromis czasowy jest decyzją architektoniczną tylko wtedy, gdy ma granice, właściciela i warunki wyjścia. Bez nich rozwiązanie przejściowe łatwo staje się trwałym długiem.