Architektura je umění kompromisů

🌐 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 4 ze 7 kapitoly Myslet jako datový architekt, první kapitoly kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Test vratnosti · Další: Stavějte pro dnešek. Plánujte pro zítřek. Plánujte pro selhání.

Otázka, na kterou tento modul odpovídá: Když by mohlo fungovat několik řešení, jak architekt vybírá a jak svou volbu vysvětluje?

Kdyby architektura byla jen o nalezení správné odpovědi, bylo by to mnohem snazší. Naučit se platformu, naučit se vzory, naučit se limity, vybrat ten správný, hotovo.

Skutečná architektura takhle nefunguje. Těžká rozhodnutí obvykle nejsou mezi zjevně dobrým a zjevně špatným řešením. Jsou mezi několika řešeními, která by mohla fungovat, každé s výhodami i nevýhodami, každé posouvá architekturu trochu jiným směrem. Právě tady si architekt zaslouží své místo u stolu.

Mnoho způsobů, jak problém vyřešit

Nějakou verzi tohoto příkladu jsem při výuce architektů použil mnohokrát.

V Salesforce může existovat mnoho způsobů, jak problém vyřešit. Někdy tomu dám číslo, třeba deset, ale je to přirovnání, ne počet. Mnohé z možností mají problémy od začátku: narazí na omezení platformy, minou kritický požadavek nebo vytvoří problém se zabezpečením či výkonem, který nemůžeme přijmout. Ty můžeme rychle odložit. Některé další fungují dnes, ale budou mít problémy, až data porostou. Technicky fungují, ale růst, o kterém už víme, že přijde, nevydrží.

Zbude malý počet možností, které dokážou vaše potřeby podporovat i do budoucna, a teď to začíná být zajímavé. Každá z nich by mohla fungovat, škálovat a splnit požadavky. Která je tedy správná? Možná všechny. Úkolem architekta je rozumět rozdílům.

I něco tak jednoduchého jako výběrový seznam (picklist) dnes funguje a může mít problémy, až data porostou. Výběrový seznam je pro uživatele snadný. Ale zeptejte se, odkud se hodnoty berou a kolik jich může být. Výběrové seznamy fungují nejlépe s méně než zhruba 20 hodnotami. Občas jdeme až na 50, jako u států USA, a vzácně přes 100, jako u zemí, a ty už jsou nepraktické. U každého výběrového seznamu proto znejte horní mez. A změna hodnot výběrového seznamu je změna metadat, ne změna dat.

Použijte místo toho lookup a uživatelské rozhraní bude o něco složitější. Seznam ale může dál růst bez horní meze a nové hodnoty mohou přicházet z integrace. To je kompromis s použitelností. To je ta rovnováha.

Kliknutím zvětšíte

Optimální neznamená dokonalé

Slovo optimální používám opatrně. Optimální architektura není taková, kde je každé jednotlivé rozhodnutí dokonalé; taková architektura pravděpodobně neexistuje. Je to taková, kde je celkové řešení vyvážené.

Dejme tomu, že řešení A má nejlepší výkon, ale je drahé a těžko se udržuje. Řešení B stojí méně a snáz se provozuje, ale za cenu části výkonu. Řešení C je flexibilnější do budoucna, ale dnes přidává složitost. Které je optimální? Jen z těchto faktů to říct nedokážu. Potřebuji znát byznys, požadavky a priority a vědět, která omezení jsou skutečná a která jsou jen preference. Architektura závisí na kontextu. Proto vzor, který byl správný pro jednoho zákazníka, může být pro dalšího úplně špatně.

A vaším úkolem jako datového architekta je tato rozhodnutí vyvažovat. Desítky z nich uděláte sami nebo se svým týmem. Vězte, která to jsou, a poznejte, kdy má rozhodnutí větší dopad na náklady, čas nebo funkčnost a musí jít výš, ke klíčovým rozhodovatelům.

Neoptimální rozhodnutí může být součástí optimální architektury

Tohle je jedna z nejdůležitějších myšlenek této kapitoly. Někdy vědomě udělám neoptimální rozhodnutí v jedné části architektury, protože to celé řešení zlepší.

Možná zduplikuji malé množství dat, protože odstranění duplicity by vytvořilo zbytečnou integrační složitost. Možná zvolím jednodušší datový model, protože ten teoreticky čistší by sestavy a každodenní používání hodně ztížil. Možná přijmu malou výkonovou ztrátu, protože alternativa přidává infrastrukturu, kterou organizace není připravená provozovat.

Podívejte se na kterékoli z nich izolovaně a řeknete, že není optimální. Správně. Architektura ale není o optimalizaci každé komponenty zvlášť; je o optimalizaci systému. Lokálně neoptimální rozhodnutí může být součástí globálně optimální architektury, pokud rozumíme kompromisu, který děláme. Nebezpečné je dělat kompromis, aniž byste věděli, že ho děláte.

Vězte, čeho se vzdáváte

Kdykoli mi někdo řekne „tohle je nejlepší řešení“, moje další otázka zní „nejlepší v čem?“ Nejrychlejší? Nejlevnější? Nejjednodušší? Nejlépe škálovatelné, nejbezpečnější, nejflexibilnější? Nejsnáze provozovatelné, nejrychleji dodané, nejméně závislé na specializovaných dovednostech? Téměř vždy existuje další rozměr, kde odpověď nezní „nejlepší“. To je ten kompromis. Chci vědět, co získáváme, a chci také vědět, čeho se vzdáváme.

Vezměte dvě možnosti pro velkou sadu podnikových dat. Jedna data zkopíruje do Salesforce, což usnadní použití nativních schopností Salesforce, ale teď odpovídáme za jejich přesun, uložení, synchronizaci, zabezpečení další kopie a řešení latence. Druhá nechá data tam, kde jsou, a přistupuje k nim, když je potřeba. Odstranili jsme část duplicity, ale teď víc záleží na dostupnosti, výkonu dotazů, síťových závislostech a schopnostech vzdáleného systému. Žádný z těch popisů nám neřekne, kterou zvolit. Říká nám, jaké otázky položit.

Požadavky nejsou všechny stejné

Kompromisy nás také nutí vidět, že ne každý požadavek má stejnou váhu.

Někdo řekne: „Data musí být k dispozici okamžitě.“ Dobře, co znamená okamžitě? Jedna sekunda, deset sekund, minuta? A proč? Možná jde o odhalování podvodů, kde záleží na sekundách. Možná jen někdo nerad čeká na noční nahrávání. To jsou velmi odlišné požadavky a architekt se ptá tak dlouho, dokud nevíme, který z nich máme.

Mám rád požadavky, které obstojí v otázkách: kolik, jak moc, jak rychle, jak často, pro koho a co se stane, když ne? „Rychle“ není architektonický požadavek. „95 procent aktualizací zákazníků musí být servisnímu agentovi k dispozici do 30 sekund“ má k němu mnohem blíž. Teď můžeme hodnotit kompromisy.

Omezení mění odpověď

Někdy architekturu neomezuje technologie vůbec. Omezují ji peníze, lidé, čas, licence nebo zralost organizace.

Architektura, která je technicky vynikající, ale potřebuje provozní tým, který firma nemá, není dobrá architektura. Schopnost, která problém elegantně vyřeší, ale potřebuje licence, které zákazník nekoupí, také není řešení. A dokonalá tříletá transformace nepomůže firmě, která musí spustit za osm týdnů.

Nic z toho neznamená, že kvůli termínu opustíme dobrou architekturu. Znamená to, že rozumíme tomu, v čem děláme ústupky, proč a jaké důsledky přijímáme, a ideálně i tomu, jak se od dnešního kompromisu dostaneme k zítřejší architektuře.

Architekt potřebuje obraz „optimálního“

Je tu zajímavé napětí. Říkám vám, že často neexistuje jedna dokonalá odpověď, a zároveň chci, abyste si v hlavě nosili obraz toho, jak vypadá optimální řešení. To si neodporuje. Potřebujete referenční bod.

Když se dívám na datový model, chci vědět, co bych postavil, kdybych mohl optimalizovat pro požadavky bez zbytečných omezení. Když nás pak skutečná omezení od toho návrhu odtlačí (část modelu zploštíme, některá data zduplikujeme, integraci odložíme, přijmeme dočasný ruční proces), nedělám náhodné ústupky. Vím, kterým směrem se od optimálního vzdaluji a proč. To je umění architektury a ten instinkt chce praxi.

Nakreslete to

Jeden z nejlepších způsobů, jak porozumět kompromisu, je nakreslit ho. Architektonické diagramy nejsou ozdoby do prezentace; jsou to nástroje myšlení. Pokud volíme mezi dvěma přístupy, nakreslete oba. Kde data žijí a kam se přesouvají? Kdo je vlastní? Kde jsou hranice a kde se vynucuje zabezpečení? Co se stane, když něco selže, a co se změní, až poroste objem?

Diagram vytáhne nejasnosti na světlo a dá všem stejný obrázek, na který mohou ukázat.

Jak moc na tom záleží, jsem se naučil na projektu pro energetickou společnost. Revize za revizí jsem znovu vysvětloval stejné pojmy a vracel rozhovor k původnímu návrhu. Změnil jsem tedy způsob, jak jsem ty schůzky vedl: každá revize začínala datovým modelem na obrazovce. Ne tím podrobným se všemi poli. Souhrnným modelem: účet má kontakty, tento záznam má podřízené záznamy, tady visí práce. V místnosti sedělo hlavně vedení a trvalo to pár minut.

Protože se schůzku za schůzkou scházeli stejní lidé, stal se diagram naším společným jazykem. Lidé začali používat jeho názvy. Opakované otázky ustoupily a schůzky byly mnohem snazší. Říkám tomu ukotvení schůzky: jednoduchý diagram, ukázaný pokaždé, měl mnohem větší hodnotu, než kolik stálo ho vytvořit.

Cílem není umělecká dokonalost. Někdy je to podrobný diagram pro inženýry, někdy pět krabic a šest šipek pro vedení. Cílem je srozumitelnost.

Vysvětlete kompromis

Dobrý architekt to podá popořadě: tyhle možnosti jsme zvažovali, tohle nám každá dává, tohle nás každá stojí, tuhle možnost doporučuji a tady je proč.

Všimněte si, že doporučení přichází až po kompromisech. Nechci, aby se z architektury stalo „tohle už jsem dělal, věřte mi“. Zkušenost je nesmírně důležitá; pomáhá rychleji rozpoznávat vzory a dřív vidět problémy. Vaše zkušenost by ale měla vaše uvažování zlepšovat, ne nahrazovat. Naším úkolem není jen rozumět architektuře. Je to pomoct organizaci porozumět rozhodnutí, zvlášť když lidé, kteří dělají konečné rozhodnutí, nejsou architekti.

Think Correct. Think Fast.

Ne vždy budete mít tři týdny na analýzu každé možnosti. Někdy budete mít tři minuty. Na schůzce se změní požadavek, někdo zmíní omezení, o kterém jste nevěděli, nebo se někdo z vedení zeptá: „Co když to příští rok budeme potřebovat v Evropě?“

Používám heslo Think Correct. Think Fast. (Myslete správně. Myslete rychle.) Rychlost nevzniká přeskočením přemýšlení. Vzniká tím, že jste dost přemýšleli dřív, než ta chvíle přijde: naučili jste se vzory, znáte platformu, viděli jste selhání, víte, jaké otázky položit a která rozhodnutí se těžko vracejí. Proto v celém kurzu procházíme scénáře. Čím víc rozhodnutí rozeberete, tím rychleji poznáte tvar toho dalšího.

Měl jsem zákazníka, který potřeboval zadávání formulářů. Formulářů ale bylo mnoho a otázky se mohly časem měnit. Rychle jsem rozpoznal potřebu datového modelu pro průzkumy, vzoru, ke kterému se v kurzu později vrátíme. Protože jsem rozpoznal vzor i řešení, mohl jsem přinést úplnější datový model, takový, který zvládl i požadavky, které teprve přijdou, ne jen ty, které jsme měli před sebou.

Architektura je o rovnováze

Jak půjdeme do datové architektury hlouběji, narazíte na volby, u kterých vám odmítnu dát jednoduché pravidlo. Normalizovat, nebo zploštit? Data zkopírovat, nebo federovat? Synchronně, nebo asynchronně? Standardní objekt, nebo vlastní? Archivovat, nebo nechat online?

Existují principy, vzory a limity a někdy jasně špatné odpovědi. Často je ale úkolem architekta najít správnou rovnováhu pro tento systém, tento byznys a tuto chvíli.

Vězte, jak vypadá optimum. Pochopte omezení. Určete schůdné možnosti. Ukažte kompromisy. Pak rozhodněte.

To není nerozhodnost. To je architektura.

Co tady rozhoduje architekt

• Které možnosti jsou schůdné a které jsou špatně už teď nebo se za rok pokazí.
• Co každá schůdná možnost získává a čeho se vzdává, měřeno proti požadavkům, které obstojí v otázkách.
• Která omezení jsou skutečná a která jsou jen preference.
• Kterou možnost doporučit, až budou kompromisy na stole, a jak ji vysvětlit.