Projektowanie systemów i architektura

Systemy rzadko zawodzą z powodu źle napisanej funkcji. Zawodzą przez decyzje podjęte miesiące wcześniej: gdzie przebiegają granice usług, które dane są przechowywane w którym systemie, co się dzieje, kiedy zależność ulegnie awarii. Na tablicy takie decyzje są tanie, na produkcji drogie, więc właśnie w nie inwestujemy czas projektowy.

Co projektujemy

• Architektury 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 naprawiania nas wynajmowano, sprowadza się do tego, że cena ma naraz dwóch właścicieli.
• Skalowalność i scenariusze awarii. Profile obciążenia pod kampanijne skoki, strategia cache, łagodna degradacja: kiedy silnik rekomendacji jest niedostępny, klient powinien zobaczyć nieco uboższą 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, kiedy dwaj dostawcy proponują niezgodne ze sobą kierunki rozwoju. 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ł.