Návrh systémů a architektura

Většina systémů neselže proto, že někdo napsal špatnou funkci, ale kvůli rozhodnutím starým několik měsíců: kudy vedou hranice mezi službami, kde která data žijí a co se stane, když vypadne závislost. Tato rozhodnutí se ve fázi návrhu mění levně a v produkci draze, proto právě do návrhu soustředíme čas.

Co navrhujeme

• Commerce architektury. Storefront, backend a systémy okolo: ERP, PIM, WMS, platby, vyhledávání. Které části koupit, které postavit a kudy mají vést švy.
• Integrační topologie: event-driven versus request-driven, fronty a dead-letter handling, idempotence a co „eventually consistent“ znamená pro objednávku, která musí zítra odjet.
• Tok dat a jejich vlastnictví. Každý údaj má mít jeden systém, který o něm rozhoduje. Většina integračních chyb, které opravujeme, vede zpět ke dvěma systémům, z nichž každý předpokládá, že cenu vlastní on.
• Škálovatelnost a scénáře selhání. Zátěžové profily pro špičky kampaní, cache strategie, graceful degradation: když vypadne doporučovací engine, zákazník má vidět o něco střídmější stránku, ne chybovou hlášku.
• Migrační cesty. Jak se z dnešní architektury dostat k cílové po krocích, z nichž každý doručí hodnotu, místo dvouletého přepisu, ze kterého není nic vidět až do samého konce.

Jak to dodáváme

Architektonická práce je součástí většiny našich zakázek a jde objednat i samostatně: jako design review architektury, ke které se chystáte zavázat, jako písemná cílová architektura s migračním plánem, nebo jako druhý názor ve chvíli, kdy dva dodavatelé navrhují řešení, která se vzájemně vylučují. Výstupem je vždy dokument, podle kterého se dá stavět i bez nás.

Pro co optimalizujeme

Standardně volíme nudnou technologii a nejmenší systém, který splní požadavky, a navrhujeme s tím, že systém bude udržovat menší tým, než jaký ho postavil.