Stavějte pro dnešek. Plánujte pro zítřek. Plánujte pro selhání.

🌐 K dispozici také v 29 jazycích

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 5 ze 7 kapitoly Myslet jako datový architekt, první kapitoly kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Architektura je umění kompromisů · Další: Znejte své nástroje: devět otázek

Otázka, na kterou tento modul odpovídá: Jak navrhovat pro dnešní požadavky a zároveň plánovat pro růst a pro selhání?

Jednou z nejsnadnějších chyb v architektuře je navrhovat jen pro požadavky, které máte právě před sebou. Máme projekt, backlog a požadavky. Postavíme něco, co je splní. Funguje to a vyhlásíme vítězství. O šest měsíců později se byznys změní, nebo data narostou, nebo to chce používat jiná obchodní jednotka, nebo koupíme firmu, nebo se musí napojit nový systém, nebo selže něco, s čím nikdo nepočítal.

Nic z toho by architekta nemělo překvapit. Nedokážeme předpovědět všechno, co se stane, ale můžeme navrhovat s vědomím, že něco se stane. Proto se na architekturu dívám třemi čočkami:

Stavějte pro dnešek. Plánujte pro zítřek. Plánujte pro selhání.

Potřebujete všechny tři.

Kliknutím zvětšíte

Stavějte pro dnešek

Architektura začíná problémem, který doopravdy máme. Zní to samozřejmě, ale architekti mohou udělat opačnou chybu než krátkodobé myšlení: můžeme přearchitektovat. Co když koupíme dvanáct firem, budeme mít miliardu zákazníků, rozšíříme se do 40 zemí a každý systém bude potřebovat integraci v reálném čase? Možná. Ale jsou to skutečné možnosti, nebo si vymýšlíme problémy? Architektura není o tom postavit ten nejsofistikovanější systém, jaký si dokážeme představit. Je o tom postavit ten přiměřený.

Začněte tedy dneškem: co byznys potřebuje, skutečné objemy, uživatelé a transakce, jak často se data mění a jak rychle se musí přesouvat, kdo potřebuje přístup a odkud data přicházejí a kam odcházejí. A hlavně: proč? Tyto odpovědi nám dávají něco konkrétního k navrhování.

Hledejte implicitní požadavky

Požadavky, které dostanete, nemusí být všechny požadavky, které máte. Téměř vždy existují implicitní požadavky.

Byznys řekne: „Potřebujeme zákaznická data v Salesforce.“ Dobře. Pak ale někdo musí ta data vlastnit a rozhodnout, jak čerstvá musí být. Musíme vědět, co se stane, když zdrojový systém nejede, jak poznáme, že synchronizace selhala, a která strana vyhraje, když se Salesforce a zdroj neshodnou. Potřebujeme dobu uchovávání, model přístupu, rozhodnutí o citlivých polích a způsob, jak opravovat špatná data.

Nic z toho v uživatelském příběhu nebylo. A přesto je to všechno architektura. Velká část toho stát se architektem je naučit se rozpoznávat otázky, které ještě nikdo nepoložil.

Znejte svá čísla

Architekty neustále tlačím ke kvantifikaci. Neříkejte mi, že dat je hodně; řekněte mi kolik. Deset tisíc, deset milionů, sto milionů, miliarda? To jsou velmi odlišné architektury. Neříkejte mi, že integrace běží často: každou hodinu, každou minutu, tisíckrát za sekundu? Neříkejte mi, že rychle rosteme. Jak rychle?

Když nemám lepší číslo, mým výchozím bodem je 30procentní roční růst. Není to předpověď; je to nástroj, který k něčemu donutí. Když mi někdo řekne, že máme dnes 10 milionů záznamů, nechci, aby se diskuse u 10 milionů zastavila. Při 30 procentech ročně jsme příští rok zhruba na 13 milionech, rok nato na 17 milionech a další rok kolem 22 milionů. Teď si promluvme o návrhu. Pokud mi byznys řekne, že 30 procent je nesmysl, skvělé: dejte mi skutečné číslo. Jde o to, aby se růst stal součástí architektonické diskuse.

Říkám tomu Steveův „počet nul“ (Steve’s Number of Zeros). Jedna nula navíc může vaši architekturu úplně změnit. Deset tisíc, sto tisíc, milion, deset milionů, sto milionů: funkce se nezměnila a požadavek se možná nezměnil, ale architektura možná ano.

Vzpomínáte na schůzky z modulu 1? Dejme k nim skutečná čísla. Přes 1 200 poboček, 100 schůzek na pobočku denně, šest dní v týdnu, zhruba 305 dní v roce. To je přes 36 milionů schůzek v prvním roce. Každá návštěva vytvoří dva záznamy, takže přes 73 milionů záznamů. Teď si nechte pět let historie s růstem 30 procent ročně a máte přes 650 milionů záznamů. Stejná funkce, stejný požadavek. O pár nul víc a úplně jiná architektura.

Plánujte pro zítřek

Jakmile rozumím dnešku, dívám se dopředu: co se pravděpodobně změní? Objem je součástí, ale zítřek neznamená jen víc. Může znamenat i jinak: víc produktů, obchodních jednotek a zemí; jiné požadavky na ochranu soukromí; nové kanály a integrace; fúzi nebo akvizici; novou strategii kmenových dat nebo analytickou platformu; AI agenta, který spotřebovává informace navržené jen pro lidi.

Proto mi tolik záleží na tom, jestli architektura dokáže růst přidáváním, a ne neustálou změnou. Když byznys přidá produkt, pojme ho model? Když data potřebuje jiný systém, dokážeme je čistě zpřístupnit? Když objem vyskočí, máme kam jít? Když se změní struktura byznysu, budeme muset datový model rozebrat? Nesnažíme se budoucnost dokonale předpovědět. Snažíme se nezahnat se do kouta.

Nestavějte zítřek už dnes

Je tu potřeba rovnováha. Plánovat pro zítřek neznamená stavět zítřejší systém už dnes. Pokud máme 100 000 záznamů a za pět let jich můžeme mít 100 milionů, neznamená to, že teď postavíme architekturu pro 100 milionů záznamů. Ta může přinést náklady a složitost, které zatím nepotřebujeme.

Otázka, na kterou chci odpověď, zní: může se dnešní architektura vyvinout v tu zítřejší? Pokud můžeme začít jednoduše a s jasnou cestou dál, je to často lepší než platit cenu složitosti o roky dřív. Nebezpečí není v tom začít v malém. Nebezpečí je začít někde, odkud není kam jít.

Plánujte pro selhání

A teď část, o které nikdo nerad mluví: věci selhávají. Nikdy jsem nenavrhoval systém, kde by každá komponenta byla navždy dostupná, každá integrace uspěla, každý uživatel zadal dokonalá data a každý externí systém se choval přesně podle dokumentace. Takový systém tedy nenavrhujte.

Zeptejte se, co může selhat, a pak se zeptejte, co se stane, když to selže. Integrace vyprší. API odmítne požadavek. Noční nahrávání zpracuje 800 000 záznamů a u 200 000 selže. Zdrojový systém spadne. Uživatel zadá neplatná data. Externí identifikátor se objeví dvakrát. Nadřazený systém změní formát hodnoty, aniž by změnil název pole. Proces uspěje v jednom systému a selže v jiném. To nejsou neobvyklé okrajové případy. Takhle vypadá produkce.

Částečný úspěch je pořád selhání, kterému musíte rozumět

Částečná selhání jsou v datové architektuře obzvlášť nebezpečná. Představte si, že přesouváte milion záznamů a proces hlásí, že skončil. Výborně. Ale dorazil milion, nebo 999 997, a které tři chybějí? Možná 200 000 selhalo, některé vznikly dvakrát, nebo dorazilo všechno a u některých polí selhala transformace.

„Úloha dokončena“ neznamená totéž co data jsou správně. Datový architekt myslí na odsouhlasení: jak poznáme, co se mělo stát, co se skutečně stalo a jaký je rozdíl? A co s tím uděláme?

Tohle dělám, když se systémy zkomplikují. Záznamy jdou z A do B, zleva doprava. Pak B pošle něco zpátky: potvrzení za každý záznam, který přijal a uložil. Teď může A porovnat, co poslal, s tím, co bylo potvrzeno. Pokud má každý záznam své potvrzení, běh uspěl. Pokud nějaká potvrzení chybějí, neuspěl, ať říká stav úlohy cokoli, a my přesně víme, po kterých záznamech jít: zopakovat je, předat je člověku, nebo vyvolat výstrahu.

Kliknutím zvětšíte

Selhávejte elegantně

Když k selhání dojde, chci vědět, co systém udělá dál: zda to zkusí znovu, a jestli automaticky; co se stane, když se stejná transakce zpracuje dvakrát; kam jdou neúspěšné záznamy a zda dobré záznamy proudí dál kolem toho špatného; kdo dostane výstrahu, s jakými informacemi, a jak selhání přehraje znovu; a jak se uživatel dozví, že se něco pokazilo.

A hlavně: dokážeme se zotavit, aniž bychom problém zhoršili? Strategie opakování, která vytváří duplicitní data, není moc dobrá strategie obnovy. Dobrá architektura se selháním počítá a dává nám cestu zpět.

Monitorujte, na čem záleží

Plánovat pro selhání bez monitorování není doopravdy plánování. Pokud integrace selže ve 2:00 ráno a nikdo si toho nevšimne, dokud za tři dny nezavolá zákazník, neměli jsme provozní architekturu. Měli jsme naději.

Rozhodněte, co musí být pozorovatelné: proběhl proces, jak dlouho trval, kolik záznamů se zpracovalo, kolik uspělo a kolik selhalo? Liší se objemy najednou od normálu? Roste fronta, přibývá chyb? Architektura nekončí úspěšným nasazením. Někdo musí tento systém zítra provozovat, a i to je součást návrhu.

Myslete ve všech třech směrech

Používejte tři čočky po celý zbytek kurzu. Když navrhujeme datový model: funguje dnes, může zítra růst a co se stane, když jsou data špatná nebo neúplná? Integraci: přesune dnešní data, zvládne zítřejší objem a systémy a co se stane, když jedna strana nejede? Velké objemy dat: co máme dnes, kam čísla míří a jak se zotavíme, když velká operace uspěje jen zčásti?

Technologie se mění kapitolu od kapitoly. Otázky ne.

Architektura existuje v čase

Vývojář se někdy může podívat na požadavek a zeptat se: „Funguje to?“ Architekt se musí ptát na víc: funguje to dnes, bude to fungovat i zítra a co se stane, když to nebude fungovat vůbec? Tyto tři otázky nás vedou za implementaci, do života systému.

Nepředpovíte každý budoucí požadavek a nezabráníte každému selhání. To není cíl. Cílem je postavit něco přiměřeného tomu, co víme dnes, nechat si kam jít zítra a mít plán pro chvíli, kdy realita nespolupracuje.

Stavějte pro dnešek. Plánujte pro zítřek. Plánujte pro selhání. Tyto tři čočky použijeme znovu a znovu.

Co tady rozhoduje architekt

• Jaké jsou skutečné objemy a růst a která čísla by změnila návrh.
• Které implicitní požadavky byznys ještě nevyslovil.
• Jak se dnešní návrh může vyvinout v ten zítřejší, aniž bychom zítřejší systém stavěli už dnes.
• Co se stane, když něco selže: obnova, odsouhlasení a monitorování.