Myslet jako architekt
Konten ini belum tersedia dalam bahasa Anda.
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)
Modul 1 ze 7 kapitoly Myslet jako datový architekt, první kapitoly kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: přehled kapitoly · Další: Datový model je kostra
Otázka, na kterou tento modul odpovídá: Jaký je rozdíl mezi stavěním a architekturou a co architekt doopravdy dělá?
Většinu své kariéry jsem byl stavitel.
Začínal jsem jako vývojář. Než jsem přešel k Salesforce, pracoval jsem v Javě a .NET, a strávil jsem roky navrhováním systémů, psaním kódu, integrací platforem, výukou architektů a revizemi architektur.
Jedna z nejdůležitějších lekcí, které jsem se cestou naučil, ale zní: být skvělý stavitel a být skvělý architekt není vždycky totéž.
Stavitel se ptá:
Jak to postavím?
Architekt si musí klást jinou sadu otázek:
Máme to vůbec stavět?
Proč to stavíme právě takhle?
Jaké jsou alternativy?
Co se stane, až to bude větší?
Co se stane, až to selže?
A jaké rozhodnutí dnes děláme, u kterého si za tři roky budeme přát, abychom o něm přemýšleli důkladněji?
Vzpomínám si na projekt pro maloobchodní firmu, která pracovala s rezervacemi schůzek. Zeptal jsem se: kolik schůzek denně na jednu prodejnu? Pak: kolik máte prodejen? A kolik dní v týdnu máte otevřeno? Rychle mi došlo, že jen za první rok budeme mít miliony schůzek. Přesně tyhle otázky klade architekt na začátku projektu.
A právě o téhle změně myšlení tento kurz doopravdy je.
Člověk, který drží plán
Section titled “Člověk, který drží plán ”Tuhle analogii jsem při výuce architektů použil mnohokrát.
Představte si staveniště. Jsou tam lidé, kteří lijí beton, tahají elektřinu, instalují vodu, staví stěny a dělají desítky dalších specializovaných prací. Musí být ve své práci velmi dobří.
Ale někdo také musí držet plán.
Ten člověk musí chápat, jak do sebe všechny ty kusy zapadají. Musí si všimnout, když něco, co se děje v jedné části projektu, vytváří problém někde jinde.
To je architektura.
V technologiích se někdy mylně domníváme, že architekt je prostě ten, kdo toho ví nejvíc. Tak to ale úplně není. Znalost platformy je důležitá. Potřebujete technickou hloubku. Architektura ale není vědomostní soutěž.
Úkolem architekta je dělat dobrá rozhodnutí, někdy s neúplnými informacemi a protichůdnými požadavky, a rozumět důsledkům těchto rozhodnutí.
To je úplně jiná dovednost.
Nepřebírejte požadavek jen tak
Section titled “Nepřebírejte požadavek jen tak ”Jeden z prvních návyků, který chci, aby si architekti osvojili, je jednoduchý:
Ptejte se proč.
Někdo vám řekne:
Potřebujeme další objekt.
Proč?
Potřebujeme tohle pole zkopírovat na účet (Account).
Proč?
Potřebujeme mít všechna tahle data uložená v Salesforce.
Proč?
Neznamená to dělat potíže. Znamená to pochopit skutečný obchodní požadavek, místo abyste hned implementovali navržené řešení.
Požadavek často přichází převlečený za návrh.
„Potřebujeme nový vlastní objekt“ nemusí být požadavek. Skutečný požadavek může znít „potřebujeme tyto informace sledovat zvlášť“. To nejsou stejné věci.
Jakmile pochopíte skutečný požadavek, můžete začít zkoumat alternativy. Možná je nový objekt přesně ta správná odpověď. Možná ty informace patří někam, co už existuje. Možná by Salesforce ta data neměl vlastnit vůbec.
Architekt musí oddělit to, co byznys potřebuje, od jednoho navrženého způsobu, jak to dodat.
Pracovali jsme na prodejní aplikaci a zákazník měl několik schválení, každé se schvalovatelem a datem. Jejich první požadavek byl přidat na příležitost (Opportunity) pole Schvalovatel 2 a Schvalovatel 3, každé s datem. Když jsme šli do hloubky, zjistili jsme, že schválení může být víc než dvě nebo tři. Přesunuli jsme tedy schválení do podřízeného objektu. Žádost zněla na další pole; požadavek byl sledovat každé schválení, ať jich nakonec bude kolik chce.
Myslet za hranici požadavku
Section titled “Myslet za hranici požadavku ”Z otázky proč vyplývají dva návyky a každý z nich dostane později v této kapitole vlastní modul.
Obvykle existuje víc než jedna odpověď. Salesforce nám dává spoustu způsobů, jak problém vyřešit, a některé z nich jsou špatně téměř okamžitě. Vybírat mezi těmi, které fungují, je umění kompromisů (modul 4).
A požadavky, které dostanete, nejsou všechny požadavky, které máte. Nikdo neřekne „ujistěte se, že to bude fungovat, i když noční nahrávání proběhne jen napůl“, a přesto je to požadavek. Na každý návrh se dívám třemi čočkami: stavějte pro dnešek, plánujte pro zítřek, plánujte pro selhání (modul 5).
Vezměte si někoho, kdo si najme architekta, aby mu navrhl budovu. Nežádá o požární hlásič ani o sprinklery, ani o to, aby budova vydržela zemětřesení. Očekává to jako součást práce, aniž by o to žádal. Náš svět funguje stejně. Nikdo nežádá o elegantní ošetření chyb, o logy ani o způsob, jak se zotavit, když něco selže. Je na architektovi, aby věděl, které z těchto systémů do návrhu patří, a aby je tam dal.
Udělejte své uvažování viditelným
Section titled “Udělejte své uvažování viditelným ”Architekt by neměl jen vejít do místnosti a oznámit: „Uděláme to takhle.“
Vaším úkolem je také vysvětlit proč. Chci, aby zúčastnění rozuměli alternativám, které jsme zvažovali, a kompromisům, o které jde. Neznamená to dát manažerovi čtyřicetistránkový návrhový dokument. Znamená to umět vysvětlit stejnou architekturu vývojáři, byznysu i vedení: různé rozhovory o stejném rozhodnutí.
A způsob, jak to udělat, jsou jasné plány a pokyny, jako u člověka, který drží plán na staveništi. Pro datového architekta je jedním z nejdůležitějších takových plánů datový model.
Pokud nikdo nechápe, proč bylo rozhodnutí přijato, je velká šance, že ho jednou někdo zruší. A může k tomu mít naprosto rozumné důvody, protože původní rozhodnutí nikdy nikdo nevysvětlil.
Architekt nemusí stavět všechno
Section titled “Architekt nemusí stavět všechno ”Je tu ještě jeden přechod, který může být těžký, zvlášť pro lidi, kteří přicházejí k architektuře z vývoje.
Nemusíte všechno stavět osobně.
Pořád rád rozumím tomu, jak věci fungují na velmi technické úrovni, a tento základ je důležitý. Jako architekt ale máte odpovědnost větší než za vlastní implementaci. Nemusíte stavět všechno; musíte vědět, jak dát těm, kdo to staví, správný směr a správné parametry. To znamená rozumět dost na to, abyste jejich práci vedli, poznali, kdy navržená implementace vytváří architektonický problém, a pohybovali se mezi detaily a celkovým obrazem.
Někdy to znamená jít hluboko do dotazu, API nebo datového modelu.
Někdy to znamená udělat krok zpět a zeptat se, jestli bychom vůbec něco z toho měli dělat.
A čím dál častěji to, co staví, nejsou jen lidé. S AI může architekt pracovat přímo s nástrojem, který generuje objekty, kód a obrazovky. Směr, parametry a pravidla pak dostává AI a dávat je dobře je čím dál víc odpovědností architekta. K tomu se vrátíme v modulu 7.
I to je součást cesty od stavitele k architektovi.
Vaším úkolem je rozhodovat
Section titled “Vaším úkolem je rozhodovat ”Architektura je nakonec o rozhodnutích.
Některá rozhodnutí se dají snadno změnit. Jiná ne.
Rozvržení stránky se dá změnit. Popisek se dá přejmenovat.
Ale zvolte špatný základní datový model, zveřejněte identifikátory, na kterých začnou záviset desítky systémů, nebo dejte hlavní kopii kritických dat na špatné místo, a změna názoru se stane mnohem dražší.
To jsou architektonická rozhodnutí. A přesně na takové rozhodnutí se tento kurz soustředí.
Jako datový architekt budete rozhodovat o tom, jak jsou informace strukturované, kde žijí, jak rostou, jak se přesouvají, kdo k nim má přístup a jak jim rozumí zbytek podniku.
Na technologii záleží.
Cílem ale není znát každou funkci Salesforce.
Cílem je vypěstovat si úsudek, abyste věděli, který nástroj použít, kdy ho použít, čeho se tím vzdáváte a co bude následovat.
To je myšlení architekta.
A teď můžeme začít myslet jako datový architekt.
Co tady rozhoduje architekt
Section titled “Co tady rozhoduje architekt ”- Zda je žádost skutečným požadavkem, nebo jedním navrženým řešením pro něj.
- Které otázky položit dřív, než se cokoli postaví: máme to dělat, proč takhle, co jiného bychom mohli udělat, co se stane, až to poroste nebo selže.
- Která rozhodnutí patří architektovi a která lidem, kteří staví; a jaký směr a parametry dát stavitelům, ať jsou to lidé, nebo AI.
- Jak vysvětlit rozhodnutí tak, aby mu porozuměl vývojář, byznys i vedení.