Otázka, na kterou tento modul odpovídá: Jak nakreslit krajinu, která ukazuje, kam data jdou?
Dejte mi nový scénář a prázdnou tabuli a jedna z prvních věcí, které nakreslím, je systémová krajina. Ne krásná, ne každé API, zatím ne datový model. Chci vidět podnik: kdo jsou uživatelé, které systémy jsou zapojené, kde sedí Salesforce, co ho obklopuje, odkud data přicházejí a kam odcházejí. A pak chci projít šipky. Dobrá krajina není obrázek krabic. Je to způsob, jak odhalit architektonická rozhodnutí.
Kandidáty na CTA nechávám tohle trénovat. Přečtěte si scénář a pak začněte kreslit. Nečekejte, až to všechno vyřešíte v hlavě; kreslení vám to pomůže vyřešit. Proto je domácím úkolem po prvním dni začít krajinu dřív, než se pustíte do datového modelu. Nakreslete nejdřív datový model a už jste předpokládali, co patří do Salesforce. Nakreslete nejdřív krajinu a uvidíte systémy, které by to rozhodnutí měly ovlivnit.
Začněte vysoko a pak jděte do hloubky: nejdřív celý podnik, pak detail tam, kde na něm záleží.
Systémovou krajinu lze kreslit mnoha způsoby. Tohle je jen můj způsob, který jsem za mnoho let vyladil, a sdílím ho, abyste viděli, jak ji rychle sestavit. Používám ho pro každou krajinu Salesforce a čte se jako věta: lidé vlevo se dostávají k Salesforce uprostřed, důvěru mají přes systémy nad ním, obslouženi jsou přes kanály pod ním a s back office vpravo jsou propojení.
Lidé vlevo, shora dolů: interní uživatelé, partneři, zákazníci. Zatím ne každá persona; dost na to, abychom odpověděli, kdo se snaží k této architektuře dostat? Každá skupina ukazuje tam, kudy vstupuje: interní uživatelé do Salesforce, partneři do partnerské komunity, zákazníci do zákaznické komunity. Systémy neexistují samy o sobě. Někdo nebo něco se je snaží používat.
Krok 2 ze 6: kdo se snaží k této architektuře dostat?
Salesforce uprostřed. Jedna prostá krabice. Ne proto, že by byl Salesforce středem podniku (právě jsme tři moduly tvrdili, že není), ale proto, že je to systém, kolem kterého navrhuji. Je to kotva.
Komunity hned pod ním, dotýkají se ho. Partnerská a zákaznická komunita jsou samostatné koncové body, takže dostanou vlastní krabice. Sedí ale přimknuté k Salesforce, protože k nim se nic nemusí integrovat: běží ve stejném orgu.
Krok 3 ze 6: Salesforce uprostřed, komunity hned pod ním.
Identita nahoře. Poskytovatelé identity jdou nahoru, ti, na které vývojáři zapomínají: jeden pro interní uživatele, možná další pro partnery. Nahoru patří i balíčky z AppExchange, posunuté doprava, protože jsou to schopnosti přinesené do orgu, ne systémy back office, které si s ním vyměňují data. Veřejné weby sedí vlevo nahoře.
Krok 4 ze 6: identita nahoře, krabice, na kterou vývojáři zapomínají.
Integrace, pak back office, doprava. Integrační vrstva, ESB nebo iPaaS (nebo MuleSoft, když je jmenovaný), je vysoký pruh hned vpravo od Salesforce. Za ní sedí interní systémy: ERP, finance, správa objednávek, starší systémy, datový sklad. Teď se stránka čte zleva doprava: lidé, Salesforce, integrace, back office.
Kanály dole. Cokoli, co má přímou linku k zákazníkům: e-mail na případ, web na zájemce, telefon, zprávy.
Data dovnitř a ven, vpravo dole. Externí zdroje dat, archivy, nahrávání dat.
Data 360 vpravo, pod integrační vrstvou. Uživatelé se k němu nikdy nepřipojují a jeho tenant se připojuje k mnoha systémům back endu, takže sedí u potrubí, kde tyto čáry zůstanou krátké: vedle interních systémů, datového skladu a dat vpravo dole. Datové týmy jeho obrazovky otevírají, ale ty obrazovky jsou v orgu: Data 360 je blízko core, spravováno na core a hostováno mimo core (modul 1). Jedna čára zpět k Salesforce ukazuje, kdo ho spravuje. Kam krabici dáte, by mělo vyprávět příběh toho, co dělá.
Nic z této geometrie není posvátné. Hodnota konvence je v tom, že nevymýšlím vizuální jazyk pokaždé znovu, a kdo viděl jeden z mých diagramů, přečte ten další rychleji.
Udržujte notaci jednoduchou. Každý systém je karta: jeho název, role a malá ikona, která říká, o jaký druh věci jde: ERP, databáze, poskytovatel identity, skupina lidí. Oblasti, které jsem právě popsal, jsou nakreslené jako slabé popsané zóny, takže je vidět samotné rozvržení. Legenda dole říká, co znamená každá ikona a čára.
Nedávejte do krabice příliš mnoho. Jen u velmi složité krajiny otevřu Salesforce na jeho části (Sales Cloud a Service Cloud uvnitř orgu, se šipkami mezi nimi). A nevymýšlejte patnáct tvarů, pokud každý z nich čtenáři něco neříká. Chci, aby se někdo na krajinu třicet sekund podíval a začal architektuře rozumět. Nóbl nepomáhá. Srozumitelnost ano.
Nečekejte s přemýšlením o objemu na podrobný návrh. Šipka, která nese 500 produktů za noc, a šipka, která nese 200 000 údajů z GPS denně, mohou v krajině vypadat úplně stejně. Nejsou to stejné problémy. Než tedy nakreslíte jedinou šipku, spočítejte, co se přesouvá. Začněte inventuru za obrázkem počty: jeden řádek na každou důležitou sadu dat, s jejím objemem. Nuly se na šipkách nikdy objevit nemusí, ale potřebujete vědět, kdy přecházíte k vysokým číslům: tisíce nebo miliony za hodinu, statisíce transakcí, nebo i desítky až stovky transakcí za sekundu.
Tato čísla řídí mechanismus. Pár stovek záznamů za noc je dávka. Volání, na které někdo čeká, může být synchronní, pokud to objem dovolí. Desítky až stovky za sekundu mohou potřebovat události, třeba platform events, místo volání pro každý záznam. Šipka bude vypadat stejně; co ji nese, rozhoduje objem, takže ho zaznamenejte v inventuře, kde se mechanismus volí.
Mechanismus může dokonce změnit směr šipky. Posílejte pár záznamů za minutu a Salesforce může prostě volat ven: šipka začíná u Salesforce. Posílejte mnohem víc a Salesforce místo toho může zveřejňovat události na sběrnici událostí; externí systém je odebírá a volá si pro ně dovnitř, takže teď šipka začíná na druhém konci. Ještě víc, třeba noční synchronizace milionů záznamů, a je to dávkový proces. Znejte tedy své počty brzy, jakmile začnete navrhovat mechanismy, protože počty mohou šipky překreslit.
Objem je důležitý na dvou místech, ze dvou důvodů. U datového modelu ho potřebuji, abych hlídal velké objemy dat a plánoval archivaci; část 2 do toho jde hluboko. U systémové krajiny řídí velká čísla v inventuře volbu integračního vzoru a mechanismu. Modul 6 dává skutečné nuly do krajiny Steve Trucking a do její inventury. S počty v ruce nakreslete šipky.
Se systémy na místě je propojte a z krajiny se stane architektura. Krabice je systém; šipka ukazuje, kdo spojení iniciuje. Začíná u systému, který spojení otevírá, a ukazuje na ten, který volá: od klienta k serveru. Popisek říká, co se přesouvá a kterým směrem.
Toto pravidlo platí pro systémové krajiny, kde spolu mluví systémy. V diagramu datových toků šipka sleduje data, jak byste čekali. Nepřenášejte pravidlo krajiny do jiných diagramů; jen to přidá zmatek.
Šipky na místě. Každá krabice je tam, kde byla; každá šipka začíná u systému, který spojení otevírá, a její popisek říká, co se přesouvá a kterým směrem.
Pokud tedy integrační vrstva tlačí produkty do Salesforce, vede šipka od integrační vrstvy k Salesforce s popiskem produkty dovnitř. Pokud si je Salesforce volá ven, šipka začíná u Salesforce, pořád s popiskem produkty dovnitř. Stejná data, jiný rozhovor, a ten rozdíl mi říká, kdo potřebuje přihlašovací údaje a kdo musí řešit selhání. Salesforce pošle objednávku přes integrační vrstvu: objednávky ven. Vyřízení z ERP se vrací: stav objednávky dovnitř. Teď vidím, kdo každý rozhovor zahajuje, kde data vstupují do Salesforce a kde z něj odcházejí, které toky překračují hranice, kde nejspíš leží vlastnictví a kde se potřebuji ptát dál.
A vzpomeňte si na modul 1: kdykoli vidím jen jeden tok, mám obavy. Na vysoké úrovni závisí šipka objednávky ven na zpětných tocích: zákazníci dovnitř, produkty dovnitř, ceny. Podívejte se ještě hlouběji a je tu cesta zpátky: přijetí, odmítnutí, stav, číslo faktury, zrušení. Šipky mi dávají něco konkrétního ke zpochybnění.
Tady přestává být krajina obrázkem do PowerPointu. Na revizní komisi může jakákoli šipka vyvolat tři otázky a chci, abyste na ně měli odpovědi:
Jak se ověřuje? OAuth, certifikát, named credential, něco jiného?
Je synchronní, nebo asynchronní? Čeká Salesforce na ERP, nebo zveřejní a pokračuje? Jak rychle byznys potřebuje výsledek?
Jaký je mechanismus? Volání REST, událost, soubor, fronta zpráv, přes MuleSoft, nebo napřímo?
A pak: co se stane, když druhá strana nejede? Každá šipka potřebuje mechanismus. Pokud ho neumíte vysvětlit, je čára jen dekorace.
A „fire and forget“ (odeslat a zapomenout) není odpověď. Obvykle to znamená „nenavrhl jsem, co se stane po odeslání“. Dorazilo to? Bylo to přijato? Selhalo to? Zkusí se to znovu? Kdo ví, že to uvízlo? Co když stejná zpráva dorazí dvakrát? Nic z toho do krajiny nepatří, protože by se stala nečitelnou. Šipka by vám ale měla připomenout, že tyto otázky existují.
Přibližte jakoukoli šipku a uvidíte klienta a server a každý vlastní svou polovinu. Klient otevírá spojení: potřebuje koncový bod a port, nejdřív si vezme token od ověřovacího serveru, volá protokol a kontrakt, které definuje server, a volí, jestli bude čekat. Celou cestu tam a zpátky vidí jen klient, takže jen klient může opakovat. Server naslouchá, definuje protokol, kontrakt a payload, ověřuje, co přichází, a vidí jen svou část. Když kreslím šipku, už vím, který konec je který, a to mi říká, kdo vlastní kterou z těchto otázek.
Jedna šipka zblízka: klient řeší, server definuje. Nic z toho do krajiny nepatří, ale každá šipka to má.
Teď šipku otočte. Když ERP volá Salesforce, je Salesforce server: definuje API, provozuje vlastní autorizační server a přes External Client App a integračního uživatele rozhoduje, co volající smí dělat. Stejné otázky, druhá strana.
Tady architekti kazí dobrý diagram: nechají jeden artefakt odpovídat na všechno. Krajina dostane názvy API, payloady, opakování, chybové fronty, transformace, každé zpětné volání a brzy ji nikdo nepřečte. To nedělejte. Krajina je celkový obraz: systémy a důležité toky mezi nimi.
Když potřebuji vysvětlit interakci, nakreslím druhý diagram, ale ne pro každou integraci. Pokud systém A posílá něco do B, nebo se dokonce zeptá a dostane odpověď, stačí popsaná šipka. Plaveckou dráhu (swim lane) chci, když se z procesu stane rozhovor: A volá B, B si to ověří u C, C odpoví, B něco vytvoří a zavolá zpět A, člověk schválí, další systém pokračuje. Moje orientační pravidlo: víc než jedna nebo dvě výměny tam a zpátky a sekvence dostane vlastní plaveckou dráhu. Šipky v krajině; rozhovor v plavecké dráze.
A všimněte si, že šipka tam znamená něco jiného. V krajině je šipka spojení: kdo ho otevírá a co se přesouvá. V plavecké dráze je každá šipka jedna zpráva v rozhovoru, čtená popořadě: požadavek jde jedním směrem, odpověď se vrací druhým a následuje další krok.
Když krajina vypadá skoro hotová, projděte ji, šipku po šipce. Z ERP do Salesforce: co se přesouvá, kdo to vlastní, jak se ověřuje, jaký je mechanismus, synchronně, nebo asynchronně, jak aktuální to musí být? Pak další šipka a další. Tady se objevují mezery. „Aha, nikdy jsme nevyřešili, jak to partner vlastně posílá.“ „Objednávky posíláme do ERP, ale nenavrhli jsme, jak se vracejí ty odmítnuté.“ Dobře. Našli jste to na tabuli, a ne v produkci.
Obrázek musí zůstat čitelný, takže podrobnosti jdou do inventury za ním. Začali jste ji počty; teď ji dokončete, jeden řádek na každou důležitou sadu dat nebo tok:
Proto mám tento artefakt rád: pomáhá mi přemýšlet. „Jak budeme dělat sestavy napříč Salesforce a ERP?“ Je to otázka z modulu 3: který z mých diagramů tohle krásně řeší? Krajina. Pokud je všechno na core, standardní sestavy. Pokud jsou data v ERP a v datovém skladu, uvidíte to okamžitě. „Kde by měl být tento atribut zákazníka spravovaný jako kmenový?“ Podívejte se, které systémy ho používají a který už zákazníka vlastní. „Potřebuje Salesforce každý údaj z GPS?“ Kdo ho vytváří, kdo ho spotřebovává, jaká je zátěž? Možná Salesforce potřebuje aktuální polohu a historii si drží jiná platforma. Krajina vám odpověď nedá. Dá vám správný pohled na problém.
Ještě jedna disciplína. V existujícím podniku kreslete to, co existuje, ne to, co byste si přáli. Tabulka posílaná e-mailem každý pátek: nakreslete ji. Partnerovo CSV na serveru SFTP: nakreslete ho. Integrace, která z historických důvodů obchází ESB: nakreslete ji. Lidé, kteří přepisují data mezi dvěma systémy: ukažte to. Nečistěte realitu, když ji dokumentujete. Současnou krajinu potřebujete dřív, než navrhnete cílovou, a přesně to pro Steve Trucking děláme v modulu 6.
Nad rámec zkoušky: co mění AI. Z krajiny se stává mapa agentů. Pokud agent odpovídá na otázku „kde je moje doručení?“, musí krajina říct, jestli odpověď přichází ze Salesforce, ze systému partnera, z telematiky, z ERP, nebo z kombinace. Agenti hranice systémů neodstraňují; díky nim je ještě důležitější vědět, který systém je autoritativní a jak se k němu bezpečně dostat.
Které systémy a skupiny uživatelů do krajiny patří a jak jejich umístění ukazuje jejich roli.
Které toky překračují hranice systémů, kterým směrem a co se vrací.
Jak se každé spojení ověřuje, jaký mechanismus ho nese a zda je synchronní, asynchronní, dávkové, nebo federované.
Kdy stačí popsaná šipka a kdy interakce potřebuje vlastní plaveckou dráhu.
Co zaznamenává inventura za obrázkem: vlastník, zátěž, objem, org, načasování, ověřování a zkopírovat, odkazovat, nebo federovat.
Krajinu nekreslím až potom, co je architektura hotová. Je to způsob, jak architekturu najdu. A když si myslíte, že je hotová, neobdivujte ji. Projděte ji. Každá šipka, kterou zatím neumíte vysvětlit, vám ukazuje, kde je práce.
