Pytanie, na które odpowiada ten moduł: jak narysować krajobraz, który pokazuje, dokąd idą dane?
Daj mi nowy scenariusz i pustą tablicę, a jedną z pierwszych rzeczy, które narysuję, będzie krajobraz systemów. Nie piękny, nie z każdym API, jeszcze bez modelu danych. Chcę zobaczyć przedsiębiorstwo: kim są użytkownicy, jakie systemy biorą udział, gdzie jest Salesforce, co go otacza, skąd przychodzą dane i dokąd idą. A potem chcę przejść po strzałkach. Dobry krajobraz to nie obrazek z prostokątami. To sposób na odsłonięcie decyzji architektonicznych.
Każę kandydatom na CTA to ćwiczyć. Przeczytaj scenariusz, potem zacznij rysować. Nie czekaj, aż rozwiążesz wszystko w głowie; rysunek pomaga to rozwiązać. Dlatego praca domowa po pierwszym dniu to rozpoczęcie krajobrazu, zanim spróbuje się modelu danych. Narysuj najpierw model danych, a z góry przesądzisz, co należy do Salesforce. Narysuj najpierw krajobraz, a zobaczysz systemy, które powinny kształtować tę decyzję.
Zacznij od ogółu, potem schodź w szczegóły: najpierw całe przedsiębiorstwo, potem detale tam, gdzie mają znaczenie.
Krajobraz systemów można rysować na wiele sposobów. To tylko mój sposób, dopracowywany przez wiele lat, i dzielę się nim, żeby pokazać, jak szybko taki krajobraz złożyć. Używam go dla każdego krajobrazu Salesforce, a czyta się go jak zdanie: ludzie po lewej docierają do Salesforce pośrodku, któremu ufa się przez systemy nad nim, który obsługuje się przez kanały pod nim i który łączy się z zapleczem po prawej.
Ludzie po lewej, od góry do dołu: użytkownicy wewnętrzni, partnerzy, klienci. Jeszcze nie każda persona; tyle, żeby odpowiedzieć na pytanie, kto próbuje dotrzeć do tej architektury? Każda grupa wskazuje miejsce, którędy wchodzi: użytkownicy wewnętrzni do Salesforce, partnerzy do społeczności partnerów, klienci do społeczności klientów. Systemy nie istnieją same dla siebie. Ktoś albo coś próbuje z nich korzystać.
Krok 2 z 6: kto próbuje dotrzeć do tej architektury?
Salesforce pośrodku. Jeden zwykły prostokąt. Nie dlatego, że Salesforce jest środkiem przedsiębiorstwa (właśnie przez trzy moduły mówiliśmy, że nie jest), ale dlatego, że to system, wokół którego projektuję. To kotwica.
Społeczności tuż pod nim, stykające się z nim. Społeczność partnerów i społeczność klientów to osobne punkty dostępu, więc dostają własne prostokąty. Ale przylegają do Salesforce, bo nic nie musi się integrować, żeby do nich dotrzeć: działają w tym samym orgu.
Krok 3 z 6: Salesforce pośrodku, społeczności tuż pod nim.
Tożsamość na górze. Dostawcy tożsamości idą na samą górę, ci, o których zapominają programiści: jeden dla użytkowników wewnętrznych, może drugi dla partnerów. Pakiety z AppExchange też idą na górę, przesunięte w prawo, bo to możliwości wnoszone do orgu, a nie systemy zaplecza wymieniające z nim dane. Publiczne strony internetowe stoją w lewym górnym rogu.
Krok 4 z 6: tożsamość na górze, prostokąt, o którym zapominają programiści.
Integracja, a potem zaplecze, po prawej. Warstwa integracyjna, ESB albo iPaaS (albo MuleSoft, gdy pada ta nazwa), to wysoki pasek tuż na prawo od Salesforce. Za nim stoją systemy wewnętrzne: ERP-y, finanse, zarządzanie zamówieniami, stare systemy, hurtownia. Teraz strona czyta się od lewej do prawej: ludzie, Salesforce, integracja, zaplecze.
Kanały na dole. Wszystko, co ma bezpośrednią linię do klientów: email-to-case, web-to-lead, telefon, komunikatory.
Dane do środka i na zewnątrz, w prawym dolnym rogu. Zewnętrzne źródła danych, archiwa, ładowania danych.
Data 360 po prawej, pod warstwą integracyjną. Użytkownicy nigdy się z nim nie łączą, a jego tenant łączy się z wieloma systemami zaplecza, więc stoi razem z hydrauliką danych, gdzie te linie zostają krótkie: obok systemów wewnętrznych, hurtowni i danych w prawym dolnym rogu. Zespoły danych owszem otwierają jego ekrany, ale te ekrany są w orgu: Data 360 jest near-core (blisko core), zarządzane w core i hostowane poza core (moduł 1). Jedna linia z powrotem do Salesforce pokazuje, kto nim zarządza. Miejsce, w którym umieścisz prostokąt, powinno opowiadać historię tego, co robi.
Żadna z tych geometrii nie jest święta. Wartość konwencji polega na tym, że nie wymyślam za każdym razem języka wizualnego od nowa, a każdy, kto widział jeden z moich diagramów, szybciej przeczyta następny.
Zachowaj prostą notację. Każdy system to karta: jego nazwa, jego rola i mała ikona, która mówi, czym jest: ERP, baza danych, dostawca tożsamości, grupa ludzi. Regiony, które właśnie opisałem, rysuję jako delikatnie zaznaczone, opisane strefy, żeby sam układ był widoczny. Legenda na dole mówi, co oznacza każda ikona i każda linia.
Nie wkładaj za dużo do prostokąta. Tylko na bardzo skomplikowanym krajobrazie rozkładam Salesforce na części (Sales Cloud i Service Cloud wewnątrz orgu, ze strzałkami między nimi). I nie wymyślaj piętnastu kształtów, chyba że każdy z nich coś czytelnikowi mówi. Chcę, żeby ktoś spojrzał na krajobraz przez trzydzieści sekund i zaczął rozumieć architekturę. Efektowność nie pomaga. Jasność tak.
Nie czekaj z myśleniem o wolumenie do szczegółowego projektu. Strzałka niosąca 500 produktów na noc i strzałka niosąca 200 000 odczytów GPS dziennie mogą na krajobrazie wyglądać dokładnie tak samo. To nie jest ten sam problem. Dlatego zanim narysujesz choćby jedną strzałkę, policz, co się przemieszcza. Zacznij inwentarz za obrazem od liczb: jeden wiersz na każdy ważny zbiór danych, z jego wolumenem. Zera mogą nigdy nie pojawić się na strzałkach, ale musisz wiedzieć, kiedy wchodzisz w duże liczby: tysiące albo miliony na godzinę, setki tysięcy transakcji, a nawet od dziesiątek do setek transakcji na sekundę.
Te liczby wyznaczają mechanizm. Kilkaset rekordów na noc to przetwarzanie wsadowe. Wywołanie, na które ktoś czeka, może być synchroniczne, jeśli wolumen na to pozwala. Od dziesiątek do setek na sekundę może wymagać zdarzeń, na przykład platform events, zamiast wywołania na każdy rekord. Strzałka będzie wyglądać tak samo; to wolumen decyduje, co ją niesie, więc zapisz go w inwentarzu, gdzie wybiera się mechanizm.
Mechanizm może nawet zmienić kierunek strzałki. Wysyłasz kilka rekordów na minutę, a Salesforce może po prostu wywołać system na zewnątrz: strzałka zaczyna się przy Salesforce. Wysyłasz znacznie więcej, a Salesforce może zamiast tego publikować zdarzenia na magistrali zdarzeń; system zewnętrzny je subskrybuje i sam po nie sięga, więc teraz strzałka zaczyna się po drugiej stronie. Jeszcze więcej, powiedzmy nocna synchronizacja milionów rekordów, i to już proces wsadowy. Dlatego poznaj swoje liczby wcześnie, gdy zaczynasz projektować mechanizmy, bo liczby potrafią przerysować strzałki.
Wolumen ma znaczenie w dwóch miejscach, z dwóch powodów. Na modelu danych potrzebuję go, żeby pilnować dużych wolumenów danych i planować archiwizację; część 2 wchodzi w to głęboko. Na krajobrazie systemów duże liczby w inwentarzu wyznaczają wybór wzorca integracji i mechanizmu. Moduł 6 wpisuje prawdziwe zera na krajobraz Steve Trucking i do jego inwentarza. Z liczbami w ręku narysuj strzałki.
Gdy systemy są na miejscu, połącz je, a krajobraz stanie się architekturą. Prostokąt to system; strzałka pokazuje, kto inicjuje połączenie. Zaczyna się przy systemie, który otwiera połączenie, i wskazuje ten, który wywołuje: od klienta do serwera. Etykieta mówi, co się przemieszcza i w którą stronę.
Ta reguła dotyczy krajobrazów systemów, na których systemy rozmawiają z systemami. Na diagramie przepływu danych strzałka idzie za danymi, jak można się spodziewać. Nie przenoś reguły krajobrazu na inne diagramy; dodaje tylko zamieszania.
Strzałki dodane. Każdy prostokąt jest tam, gdzie był; każda strzałka zaczyna się przy systemie, który otwiera połączenie, a jej etykieta mówi, co się przemieszcza i w którą stronę.
Jeśli więc warstwa integracyjna wypycha produkty do Salesforce, strzałka biegnie od warstwy integracyjnej do Salesforce, z etykietą produkty do środka. Jeśli to Salesforce wywołuje system na zewnątrz, żeby je pobrać, strzałka zaczyna się przy Salesforce, nadal z etykietą produkty do środka. Te same dane, inna rozmowa, a ta różnica mówi mi, kto potrzebuje poświadczeń i kto musi obsłużyć awarię. Salesforce wysyła zamówienie przez warstwę integracyjną: zamówienia na zewnątrz. Realizacja z ERP wraca: status zamówienia do środka. Teraz widzę, kto zaczyna każdą rozmowę, gdzie dane wchodzą do Salesforce i gdzie z niego wychodzą, które przepływy przekraczają granice, gdzie prawdopodobnie leży własność i gdzie muszę dopytać.
I pamiętaj moduł 1: zawsze, gdy widzę tylko jeden przepływ, zaczynam się niepokoić. Na wysokim poziomie strzałka zamówienia na zewnątrz zależy od przepływów zwrotnych: klienci do środka, produkty do środka, ceny. Spójrz jeszcze głębiej, a zobaczysz drogę powrotną: przyjęcie, odrzucenie, status, numer faktury, anulowanie. Strzałki dają mi coś konkretnego do podważenia.
Tu krajobraz przestaje być sztuką z PowerPointa. Przed komisją każda strzałka może wywołać trzy pytania, a chcę, żeby udało ci się na nie odpowiedzieć:
Jak się uwierzytelnia? OAuth, certyfikat, named credential, coś innego?
Czy jest synchroniczna, czy asynchroniczna? Czy Salesforce czeka na ERP, czy publikuje i działa dalej? Jak szybko biznes potrzebuje wyniku?
Jaki jest mechanizm? Wywołanie REST, zdarzenie, plik, kolejka komunikatów, przez MuleSoft czy bezpośrednio?
A potem: co się dzieje, gdy druga strona nie działa? Każda strzałka potrzebuje mechanizmu. Jeśli nie potrafisz go wyjaśnić, linia jest dekoracją.
A „fire and forget” (wyślij i zapomnij) to nie jest odpowiedź. Zwykle znaczy „nie zaprojektowałem tego, co się dzieje po wysłaniu”. Dotarło? Zostało przyjęte? Zawiodło? Zostanie ponowione? Kto wie, że utknęło? Co, jeśli ten sam komunikat przyjdzie dwa razy? Nic z tego nie trafia na krajobraz, który stałby się nieczytelny. Ale strzałka powinna sprawić, że wiesz, że te pytania istnieją.
Przybliż dowolną strzałkę, a zobaczysz klienta i serwer, i każdy odpowiada za swoją połowę. Klient otwiera połączenie: potrzebuje endpointu i portu, najpierw dostaje token od serwera uwierzytelniania, wywołuje protokół i kontrakt, które definiuje serwer, i wybiera, czy czekać. Tylko klient widzi całą drogę tam i z powrotem, więc tylko klient może ponowić próbę. Serwer nasłuchuje, definiuje protokół, kontrakt i ładunek, waliduje to, co przychodzi, i widzi tylko swoją część. Kiedy rysuję strzałkę, już wiem, który koniec jest którym, a to mówi mi, kto odpowiada za każde z tych pytań.
Jedna strzałka w przybliżeniu: klient obsługuje, serwer definiuje. Nic z tego nie trafia na krajobraz, ale każda strzałka to ma.
Teraz odwróć strzałkę. Gdy ERP wywołuje Salesforce, Salesforce jest serwerem: definiuje API, prowadzi własny serwer autoryzacji i przez External Client App oraz użytkownika integracyjnego decyduje, co wywołującemu wolno. Te same pytania, druga strona.
Oto gdzie architekci psują dobry diagram: każą jednemu artefaktowi odpowiadać na wszystko. Krajobraz dostaje nazwy API, ładunki, ponowienia, kolejki błędów, transformacje, każde wywołanie zwrotne, i wkrótce nikt nie potrafi go przeczytać. Nie rób tego. Krajobraz to szeroki obraz: systemy i ważne przepływy między nimi.
Kiedy muszę wyjaśnić interakcję, rysuję drugi diagram, ale nie dla każdej integracji. Jeśli system A coś wysyła do B albo nawet pyta i dostaje odpowiedź, wystarczy opisana strzałka. Diagramu torów (swim lane) chcę wtedy, gdy proces staje się rozmową: A wywołuje B, B sprawdza coś w C, C odpowiada, B coś tworzy i oddzwania do A, człowiek zatwierdza, inny system przejmuje. Moja reguła kciuka: więcej niż jedna czy dwie wymiany tam i z powrotem, a sekwencja dostaje własny diagram torów. Strzałki na krajobrazie; rozmowa na diagramie torów.
I zauważ, że strzałka znaczy tam coś innego. Na krajobrazie strzałka to połączenie: kto je otwiera i co się przemieszcza. Na diagramie torów każda strzałka to jeden komunikat w rozmowie, czytany po kolei: żądanie idzie w jedną stronę, odpowiedź wraca w drugą, a potem następuje kolejny krok.
Trzy strzałki na krajobrazie; sześć kroków na diagramie torów. Na krajobrazie strzałka to połączenie; na diagramie torów każda strzałka to jeden komunikat, po kolei.
Gdy krajobraz wygląda na prawie gotowy, przejdź po nim, strzałka po strzałce. Z ERP do Salesforce: co się przemieszcza, kto jest właścicielem, jak się uwierzytelnia, jaki jest mechanizm, synchronicznie czy asynchronicznie, jak aktualne muszą być dane? Potem następna strzałka i następna. Tu pojawiają się luki. „Aha, nigdy nie ustaliliśmy, jak partner właściwie to wysyła”. „Wysyłamy zamówienia do ERP, ale nie zaprojektowaliśmy, jak wracają odrzucone”. Dobrze. Wyszło to na tablicy, a nie na produkcji.
Obraz musi pozostać czytelny, więc szczegóły trafiają do inwentarza za nim. Zaczęło się od liczb; teraz go dokończ, jeden wiersz na każdy ważny zbiór danych albo przepływ:
Dlatego lubię ten artefakt: pomaga mi myśleć. „Jak będziemy raportować na danych z Salesforce i ERP?” To pytanie z modułu 3: który z moich diagramów pięknie to rozwiązuje? Krajobraz. Jeśli wszystko jest w core, standardowe raporty. Jeśli dane są w ERP i w hurtowni, widać to od razu. „Gdzie powinien być zarządzany ten atrybut klienta?” Spójrz, które systemy go używają, a który już jest właścicielem klienta. „Czy Salesforce potrzebuje każdego odczytu GPS?” Kto go wytwarza, kto z niego korzysta, jakie jest obciążenie? Może Salesforce potrzebuje bieżącej pozycji, a historię trzyma inna platforma. Krajobraz nie daje ci odpowiedzi. Daje ci właściwy widok problemu.
Jeszcze jedna dyscyplina. W istniejącym przedsiębiorstwie rysuj to, co istnieje, a nie to, co chcielibyśmy, żeby istniało. Arkusz wysyłany mailem w każdy piątek: narysuj go. CSV partnera na serwerze SFTP: narysuj. Integracja, która z historycznych powodów omija ESB: narysuj. Ludzie przepisujący dane ręcznie między dwoma systemami: pokaż to. Nie sprzątaj rzeczywistości, kiedy ją dokumentujesz. Potrzebujesz obecnego krajobrazu, zanim zaprojektujesz docelowy, i to właśnie robimy dla Steve Trucking w module 6.
Poza egzaminem: co zmienia AI. Krajobraz staje się mapą agentów. Jeśli agent odpowiada na pytanie „gdzie moja dostawa?”, krajobraz musi mówić, czy odpowiedź pochodzi z Salesforce, systemu partnera, telematyki, ERP czy z kilku z nich. Agenci nie usuwają granic między systemami; sprawiają, że wiedza o tym, który system jest nadrzędny i jak bezpiecznie do niego dotrzeć, jest jeszcze ważniejsza.
Jakie systemy i grupy użytkowników należą do krajobrazu i jak ich położenie pokazuje ich rolę.
Które przepływy przekraczają granice systemów, w którym kierunku i co wraca.
Jak uwierzytelnia się każde połączenie, jaki mechanizm je przenosi i czy jest synchroniczne, asynchroniczne, wsadowe czy sfederowane.
Kiedy wystarczy opisana strzałka, a kiedy interakcja potrzebuje własnego diagramu torów.
Co zapisuje inwentarz za obrazem: właściciela, obciążenie, wolumen, org, czas, uwierzytelnianie oraz kopiowanie, wskazywanie albo federację.
Krajobraz to nie coś, co rysuję, gdy architektura jest gotowa. To sposób, w jaki znajduję architekturę. A gdy uważasz, że jest skończony, nie podziwiaj go. Przejdź po nim. Każda strzałka, której jeszcze nie potrafisz wyjaśnić, pokazuje ci, gdzie jest praca.
