Replikację można skonfigurować (a przynajmniej w MySQL-u). Np. może dotyczyć tylko nowych wpisów, albo tylko jednej tabeli. Główną jej zaletą byłby brak jakiejkolwiek ingerencji w logikę istniejącego oprogramowania Geparda. Replikacja to całkowicie autonomiczna funkcja - nie wpłynie na działanie systemu, nic nie popsuje, nie będzie wymagała grzebania w kodzie, analizy kodu Geparda, nie będzie też konieczności wprowadzania patcha po ewentualnej aktualizacji Geparda. O ile w ogóle udałoby się nadać takim zmianą formę patcha i o ile taki patch w ogóle działałby po aktualizacji Geparda.
To duże ryzyko i za bardzo wpływa na bezawaryjność oprogramowania w przyszłości. Nawet, gdybyśmy mieli robić to, co wcześniej nazwałem etapami 3 i 4, to jedyną racjonalną opcją jest wykonanie wszystkiego poza Gepardem. Z niego trzeba tylko wydostać dane, w sposób, który nie wpłynie na jego działanie, ani bieżące, ani przyszłe. Tak więc nawet taka appka do nadzorowania automatycznego trybu przeliczania i publikowania czasów, musiałaby działać niezależnie, w oddzielnym środowisku. Jedynym łącznikiem z Gepardem może być to, co na diagramie nazwałem
modułem pozyskiwania danych (
collector).
Pamiętajcie też, że cały system będzie używany jeszcze przez długi czas. Jeśli nie na MMC, to gdzieś indziej. Musi być w stanie działać bez wsparcia z naszej strony (mam na myśli programistów, którzy będą ogarniać to dodatkowe oprogramowanie). Jeśli
Mac Berger wygra w lotka i ucieknie wyjedzie na Kostarykę (daj Boże!), albo mnie nagle przejedzie Apollo Arrow (daj Boże!
), to nie dość, że (w przypadku komplikacji z naszym oprogramowaniem) Gepard może stać się bezużyteczny, to jeszcze nie będzie można go normalnie sprzedać.