Systemy, które się dogadują
Dane, uwierzytelnianie, płatności, kolejki. Rzeczy, których nie widać — dopóki nie przestaną działać w piątek po południu.
Nikt nie planuje bałaganu. On po prostu narasta.
Firma kupuje program magazynowy, bo potrzebuje magazynu. Potem sklep, bo trzeba sprzedawać online. Potem CRM, bo handlowcy gubią kontakty. Każda decyzja z osobna jest sensowna. Po trzech latach jest sześć systemów i jedna osoba, która przenosi między nimi dane w arkuszu.
Integracja to nie jest projekt na pół roku i nie musi obejmować wszystkiego. Prawie zawsze jest jedno połączenie, które usuwa więcej ręcznej pracy niż pozostałe razem wzięte — i od niego warto zacząć.
Co odróżnia integrację, która przeżyje trzy lata
-
Ponawianie
Systemy bywają niedostępne. Integracja musi spróbować ponownie za minutę i za dziesięć — a nie zgubić zamówienie i milczeć.
-
Idempotentność
Ta sama wiadomość przetworzona dwa razy nie może utworzyć dwóch faktur. To brzmi oczywisto i jest najczęstszym źródłem duplikatów.
-
Kolejka
Gdy docelowy system leży pół godziny, dane czekają w kolejce i wchodzą, gdy wstanie. Bez kolejki po prostu przepadają.
-
Monitoring
Ktoś musi się dowiedzieć o awarii dzisiaj, nie przy zamknięciu miesiąca. Alert idzie na telefon, nie do logu, którego nikt nie czyta.
-
Dziennik zdarzeń
Gdy klient twierdzi, że zamówienie nie doszło, musi dać się sprawdzić, co i o której poszło oraz co odpowiedział drugi system.
-
Środowisko testowe
Integracja płatności testowana na produkcji jest droga w bardzo konkretny i bardzo szybko odczuwalny sposób.
Gwiazda, nie pajęczyna
Przy trzech systemach można je połączyć każdy z każdym i to działa. Przy sześciu takich połączeń byłoby piętnaście, a każde trzeba osobno utrzymywać, testować i naprawiać po każdej aktualizacji dowolnego z nich.
Dlatego przy większej liczbie systemów układ gwiazdy — jeden punkt, przez który wszystko przechodzi — jest tańszy w utrzymaniu, mimo że na starcie wygląda na więcej pracy. Dochodzi też jedno miejsce, w którym widać wszystko, co się dzieje.
Pytania, na które trzeba odpowiedzieć przed pierwszą linijką kodu
- Który system jest źródłem prawdy dla każdej danej. Jeśli cena jest w dwóch miejscach, jedno z nich musi wygrywać.
- Co się dzieje przy konflikcie — gdy rekord zmienił się po obu stronach między synchronizacjami.
- Jak często dane mają się przenosić. Natychmiast jest droższe niż co piętnaście minut i rzadko naprawdę potrzebne.
- Co robić z rekordem, który nie przechodzi walidacji. Odrzucić, wstrzymać czy przepuścić z ostrzeżeniem.
- Kto dostaje alert i na jaki kanał.
- Jak wycofać zmianę, gdy okaże się, że przez godzinę szły złe dane.
Pytania
- Od którego połączenia zacząć?
- Od tego, przy którym ktoś przepisuje najwięcej danych ręcznie. Nie od najbardziej efektownego. Pierwszy projekt ma pokazać oszczędność, żeby sfinansować kolejny.
- Czy dane muszą przechodzić przez zewnętrzny serwer?
- Nie. Domyślnie integracja pracuje na Twojej infrastrukturze. Jeśli jakieś rozwiązanie wymaga inaczej, mówimy wprost, gdzie dane trafiają i na jak długo.
- Czy gotowe narzędzia typu Zapier wystarczą?
- Do prostych przepływów o małym wolumenie — często tak i jest to tańsze niż pisanie czegokolwiek. Przestają wystarczać przy większym ruchu, przy wymaganiach dotyczących miejsca przechowywania danych i wtedy, gdy potrzebna jest logika bardziej złożona niż „jeśli to, wtedy tamto”.
Wypisz systemy, których używacie.
Powiemy, które połączenie da największą oszczędność najmniejszym kosztem.
Napisz do nas