Projektowanie systemów i architektura

Kosztowne awarie wynikają z decyzji podjętych miesiące wcześniej: gdzie przebiegają granice usług, które dane są przechowywane w którym systemie, co się dzieje, gdy zależność ulega awarii. Na tablicy takie decyzje są tanie, na produkcji drogie, więc to właśnie w nie inwestujemy czas projektowy.

Co projektujemy

• Architektury e-commerce. Storefront, backend i systemy towarzyszące: ERP, PIM, WMS, płatności, wyszukiwarka. Co kupić, co zbudować i gdzie powinny przebiegać granice między systemami.
• Topologie integracji: komunikacja zdarzeniowa kontra request-driven, kolejki i obsługa dead-letterów, idempotencja oraz to, co „eventually consistent” oznacza dla zamówienia, które musi zostać wysłane jutro.
• Przepływ i własność danych. Jedno źródło prawdy (system of record) na każdy fakt. Większość błędów integracyjnych, do których naprawy nas wynajmują, sprowadza się do dwóch systemów, z których każdy uważa, że to on jest właścicielem ceny.
• Skalowalność i scenariusze awarii. Profile obciążenia pod kampanijne skoki, strategia cache, łagodna degradacja: gdy silnik rekomendacji jest niedostępny, klient powinien zobaczyć nieco uproszczoną stronę, a nie błąd.
• Ścieżki migracji. Jak dojść od obecnej architektury do docelowej krokami, z których każdy przynosi wartość, zamiast dwuletniego przepisywania, z którego wartość pojawia się dopiero na samym końcu.

Jak to dostarczamy

Praca architektoniczna jest częścią większości naszych zleceń, ale wykonujemy ją też osobno: przegląd architektury, którą właśnie zamierzasz przyjąć, spisana architektura docelowa z planem migracji albo druga opinia, gdy dwaj dostawcy proponują niezgodne ze sobą architektury. Efektem jest zawsze dokument, który Twój zespół może zrealizować bez nas.

Na co optymalizujemy

Domyślnie wybieramy nudną technologię i najmniejszy system, który spełnia wymagania, i projektujemy z założeniem, że zespół utrzymujący system będzie mniejszy niż ten, który go zbudował.