Питання, на яке відповідає цей модуль: Як намалювати ландшафт, що показує, куди йдуть дані?
Дайте мені новий сценарій і чисту дошку, і одне з перших, що я намалюю, — системний ландшафт. Не гарний, не з кожним API, ще не модель даних. Я хочу бачити підприємство: хто користувачі, які системи залучені, де стоїть Salesforce, що його оточує, звідки дані приходять і куди йдуть. А потім я хочу пройти стрілками. Добрий ландшафт — не малюнок із прямокутниками. Це спосіб виявити архітектурні рішення.
Я змушую кандидатів у CTA це практикувати. Прочитайте сценарій, а потім починайте малювати. Не чекайте, доки все розв’яжете в голові; малювання допомагає розв’язати. Тому домашнє завдання після першого дня — почати ландшафт, перш ніж братися за модель даних. Намалюйте спершу модель даних — і ви вже припустили, що належить до Salesforce. Намалюйте спершу ландшафт — і ви бачите системи, що мають формувати це рішення.
Почніть високо, потім заглиблюйтеся: спершу все підприємство, потім деталі там, де вони важливі.
Є багато способів малювати системний ландшафт. Це просто мій спосіб, який я шліфував багато років, і я ділюся ним, щоб ви побачили, як швидко скласти ландшафт. Я використовую його для кожного ландшафту Salesforce, і він читається як речення: люди ліворуч дістаються до Salesforce посередині, якому довіряють через системи над ним, який обслуговує через канали під ним і який з’єднаний із бек-офісом праворуч.
Люди ліворуч, згори донизу: внутрішні користувачі, партнери, клієнти. Ще не кожна персона; достатньо, щоб відповісти хто намагається дістатися до цієї архітектури? Кожна група вказує туди, де вона входить: внутрішні користувачі — на Salesforce, партнери — на партнерську спільноту, клієнти — на клієнтську спільноту. Системи не існують самі по собі. Хтось чи щось намагається ними користуватися.
Крок 2 з 6: хто намагається дістатися до цієї архітектури?
Salesforce посередині. Один простий прямокутник. Не тому, що Salesforce — центр підприємства (ми щойно три модулі казали, що це не так), а тому, що це система, навколо якої я проєктую. Це якір.
Спільноти просто під ним, впритул. Партнерська й клієнтська спільноти — окремі точки входу, тож вони отримують власні прямокутники. Але вони стоять упритул до Salesforce, бо нічого не треба інтегрувати, щоб до них дістатися: вони працюють у тій самій org.
Крок 3 з 6: Salesforce посередині, спільноти просто під ним.
Ідентичність угорі. Постачальники ідентичності йдуть угору — ті, про яких забувають розробники: один для внутрішніх користувачів, можливо, ще один для партнерів. Пакети AppExchange теж ідуть туди, зсунуті праворуч, бо це можливості, принесені в org, а не системи бек-офісу, що обмінюються з нею даними. Публічні сайти стоять угорі ліворуч.
Крок 4 з 6: ідентичність угорі — прямокутник, про який забувають розробники.
Інтеграція, потім бек-офіс — праворуч. Інтеграційний шар, ESB чи iPaaS (або MuleSoft, коли його названо), — це висока смуга одразу праворуч від Salesforce. За нею стоять внутрішні системи: ERP, фінанси, керування замовленнями, застарілі системи, сховище даних. Тепер сторінка читається зліва направо: люди, Salesforce, інтеграція, бек-офіс.
Канали внизу. Усе, що має пряму лінію до клієнтів: email-to-case, web-to-lead, телефон, месенджери.
Дані на вході й виході — праворуч унизу. Зовнішні джерела даних, архіви, завантаження даних.
Data 360 — праворуч, під інтеграційним шаром. Користувачі ніколи з ним не з’єднуються, а його тенант з’єднується з багатьма бекенд-системами, тож він стоїть разом із «трубопроводом», де ці лінії лишаються короткими: поруч із внутрішніми системами, сховищем даних і даними праворуч унизу. Команди даних справді відкривають його екрани, але ці екрани — в org: Data 360 — поряд з ядром (near-core), керується в ядрі й розміщується поза ядром (модуль 1). Одна лінія назад до Salesforce показує, хто ним керує. Те, де ви ставите прямокутник, має розповідати історію того, що він робить.
Ніщо в цій геометрії не священне. Цінність конвенції в тому, що я не вигадую візуальну мову щоразу заново, а кожен, хто бачив одну з моїх діаграм, швидше прочитає наступну.
Тримайте нотацію простою. Кожна система — це картка: її назва, її роль і невелика іконка, яка каже, що це за річ: ERP, база даних, постачальник ідентичності, група людей. Області, які я щойно описав, малюються як бліді підписані зони, тож саме компонування видно. Легенда внизу пояснює, що означає кожна іконка й лінія.
Не кладіть забагато всередину прямокутника. Лише на дуже складному ландшафті я розкриваю Salesforce на частини (Sales Cloud і Service Cloud усередині org, зі стрілками між ними). І не вигадуйте п’ятнадцять форм, якщо кожна з них не каже читачеві щось. Я хочу, щоб людина подивилася на ландшафт тридцять секунд і почала розуміти архітектуру. Вишуканість не допомагає. Ясність — допомагає.
Не чекайте детального дизайну, щоб подумати про обсяг. Стрілка, що несе 500 продуктів за ніч, і стрілка, що несе 200 000 показань GPS на день, на ландшафті можуть виглядати однаково. Це не та сама проблема. Тож перш ніж намалювати хоч одну стрілку, порахуйте, що рухається. Почніть інвентар за малюнком із кількостей: один рядок на кожен важливий набір даних, з його обсягом. Нулі можуть ніколи не з’явитися на стрілках, але вам треба знати, коли ви переходите у великі числа: тисячі чи мільйони за годину, сотні тисяч транзакцій, навіть від десятків до сотень транзакцій на секунду.
Ці числа визначають механізм. Кілька сотень записів за ніч — це пакетна обробка. Виклик, на який хтось чекає, може бути синхронним, якщо обсяг дозволяє. Десятки чи сотні на секунду можуть потребувати подій, як-от platform events, а не виклику на кожен запис. Стрілка виглядатиме так само; обсяг вирішує, що її несе, тож запишіть його в інвентар, де обирають механізм.
Механізм може навіть змінити напрямок стрілки. Надсилайте кілька записів на хвилину — і Salesforce може просто викликати назовні: стрілка починається в Salesforce. Надсилайте набагато більше — і Salesforce може натомість публікувати події на шині подій; зовнішня система підписується й звертається по них сама, тож тепер стрілка починається на іншому кінці. Ще більше, скажімо нічна синхронізація мільйонів записів, — і це вже пакетний процес. Тож знайте свої кількості рано, коли починаєте проєктувати механізми, бо кількості можуть перемалювати стрілки.
Обсяг важливий у двох місцях, з двох причин. У моделі даних він потрібен мені, щоб стежити за великими обсягами даних і планувати архівування; Частина 2 розглядає це глибоко. На системному ландшафті великі числа в інвентарі визначають вибір шаблону інтеграції та механізму. Модуль 6 ставить справжні нулі на ландшафт Steve Trucking та в його інвентар. Маючи кількості, малюйте стрілки.
Коли системи на місцях, з’єднайте їх, і ландшафт стає архітектурою. Прямокутник — це система; стрілка показує, хто ініціює з’єднання. Вона починається в системі, яка відкриває з’єднання, і вказує на ту, яку викликає: від клієнта до сервера. Підпис каже, що рухається і в який бік.
Це правило — для системних ландшафтів, де системи розмовляють із системами. На діаграмі потоків даних стрілка йде за даними, як ви й очікуєте. Не переносьте правило ландшафту на інші діаграми; воно лише додає плутанини.
Стрілки додано. Кожен прямокутник там, де й був; кожна стрілка починається в системі, яка відкриває з’єднання, а її підпис каже, що рухається і в який бік.
Тож якщо інтеграційний шар проштовхує продукти в Salesforce, стрілка йде від інтеграційного шару до Salesforce з підписом продукти всередину. Якщо Salesforce сам звертається по них, стрілка починається в Salesforce, і підпис той самий — продукти всередину. Ті самі дані, інша розмова, і ця різниця каже мені, кому потрібні облікові дані і хто має обробляти збій. Salesforce надсилає замовлення через інтеграційний шар: замовлення назовні. Дані ERP про виконання повертаються: статус замовлення всередину. Тепер я бачу, хто починає кожну розмову, де дані входять у Salesforce і де виходять, які потоки перетинають межі, де, мабуть, лежить власність і де треба питати більше.
І пам’ятайте модуль 1: щоразу, бачачи лише один потік, я непокоюся. На високому рівні стрілка замовлення назовні залежить від зворотних потоків: клієнти всередину, продукти всередину, ціни. Подивіться ще глибше — і там зворотний шлях: прийняття, відхилення, статус, номер рахунку, скасування. Стрілки дають мені щось конкретне, що можна поставити під сумнів.
Тут ландшафт перестає бути мистецтвом PowerPoint. На рецензійній раді будь-яка стрілка може викликати три запитання, і я хочу, щоб у вас були відповіді:
Як вона автентифікується? OAuth, сертифікат, named credential, щось інше?
Синхронна вона чи асинхронна? Salesforce чекає на ERP чи публікує й іде далі? Як швидко бізнесу потрібен результат?
Який механізм? REST-виклик, подія, файл, черга повідомлень, через MuleSoft чи напряму?
А потім: що станеться, коли інша сторона впаде? Кожній стрілці потрібен механізм. Якщо ви не можете його пояснити, лінія — прикраса.
І «fire and forget» — не відповідь. Зазвичай це означає «я не спроєктував, що відбувається після пострілу». Воно дійшло? Його прийняли? Воно не вдалося? Чи буде повторна спроба? Хто знає, що воно застрягло? Що, як те саме повідомлення прийде двічі? Ніщо з цього не йде на ландшафт, бо він став би нечитабельним. Але стрілка має дати вам знати, що ці запитання існують.
Збільште будь-яку одну стрілку — і там є клієнт і сервер, і кожен відповідає за свою половину. Клієнт відкриває з’єднання: йому потрібні кінцева точка й порт, спершу він отримує токен від сервера автентифікації, викликає протокол і контракт, які визначає сервер, і вирішує, чи чекати. Лише клієнт бачить увесь шлях туди й назад, тож лише клієнт може повторити спробу. Сервер слухає, визначає протокол, контракт і payload, перевіряє те, що надходить, і бачить лише свою частину. Коли я малюю стрілку, я вже знаю, який кінець який, і це каже мені, хто відповідає за кожне з цих питань.
Одна стрілка зблизька: клієнт обробляє, сервер визначає. Нічого з цього не потрапляє на ландшафт, але це є в кожної стрілки.
Тепер розверніть стрілку. Коли ERP викликає Salesforce, сервер — Salesforce: він визначає API, запускає власний сервер авторизації і через External Client App та інтеграційного користувача вирішує, що може робити той, хто викликає. Ті самі питання, інший бік.
Ось де архітектори псують добру діаграму: змушують один артефакт відповідати на все. Ландшафт отримує імена API, payloads, повторні спроби, черги помилок, перетворення, кожен callback, і незабаром ніхто не може його прочитати. Не робіть так. Ландшафт — це загальна картина: системи і важливі потоки між ними.
Коли мені треба пояснити взаємодію, я малюю другу діаграму, але не для кожної інтеграції. Якщо система A щось надсилає B або навіть питає й отримує відповідь, підписаної стрілки достатньо. Мені потрібна доріжка (swim lane), коли процес стає розмовою: A викликає B, B звіряється з C, C відповідає, B щось створює і передзвонює A, людина погоджує, інша система продовжує. Моє емпіричне правило: більше одного-двох обмінів туди й назад — і послідовність отримує власну доріжку. Стрілки на ландшафті; розмова на доріжці.
І зауважте, що стрілка там означає інше. На ландшафті стрілка — це з’єднання: хто його відкриває і що рухається. На доріжці кожна стрілка — одне повідомлення в розмові, що читається по черзі: запит іде в один бік, відповідь повертається в інший, а далі наступний крок.
Коли ландшафт здається здебільшого готовим, пройдіть ним, стрілка за стрілкою. ERP у Salesforce: що рухається, хто ним володіє, як воно автентифікується, який механізм, синхронно чи асинхронно, наскільки актуальним воно має бути? Потім наступна стрілка, і наступна. Тут з’являються прогалини. «О, ми так і не з’ясували, як партнер насправді це надсилає». «Ми надсилаємо замовлення в ERP, але не спроєктували, як повертаються відхилені». Добре. Ви знайшли це на дошці, а не в продакшні.
Малюнок має лишатися читабельним, тож деталі йдуть в інвентар за ним. Ви почали його з кількостей; тепер завершіть — один рядок на кожен важливий набір даних чи потік:
Ось чому я люблю цей артефакт: він допомагає мені думати. «Як ми звітуватимемо по Salesforce і ERP?» Це запитання з модуля 3: яка з моїх діаграм розв’язує це найкраще? Ландшафт. Якщо все в ядрі — стандартні звіти. Якщо дані в ERP і сховищі даних, ви бачите це одразу. «Де має керуватися цей атрибут клієнта?» Подивіться, які системи ним користуються і яка вже володіє клієнтом. «Чи потрібне Salesforce кожне показання GPS?» Хто його створює, хто споживає, яке навантаження? Можливо, Salesforce потрібна поточна позиція, а історію зберігає інша платформа. Ландшафт не дає вам відповідь. Він дає правильний погляд на задачу.
Ще одна дисципліна. В наявному підприємстві малюйте те, що існує, а не те, що ви хотіли б. Таблицю, яку надсилають щоп’ятниці, — намалюйте. CSV партнера на SFTP-сервері — намалюйте. Інтеграцію, що з історичних причин обходить ESB, — намалюйте. Людей, що передруковують дані між двома системами, — покажіть. Не прибирайте реальність, поки її документуєте. Вам потрібен поточний ландшафт, перш ніж проєктувати цільовий, і саме це ми робимо для Steve Trucking у модулі 6.
За межами іспиту: що змінює ШІ. Ландшафт стає картою для агентів. Якщо агент відповідає на «де моя доставка?», ландшафт має казати, чи відповідь іде із Salesforce, системи партнера, телематики, ERP чи їх поєднання. Агенти не прибирають меж між системами; вони роблять ще важливішим знання того, яка система авторитетна і як безпечно до неї дістатися.
Які системи й групи користувачів належать до ландшафту і як їхнє розташування показує їхню роль.
Які потоки перетинають межі систем, у якому напрямку і що повертається.
Як автентифікується кожне з’єднання, який механізм його несе і чи воно синхронне, асинхронне, пакетне чи федероване.
Коли підписаної стрілки достатньо, а коли взаємодії потрібна власна доріжка.
Що фіксує інвентар за малюнком: власник, навантаження, обсяг, org, таймінг, автентифікація, і копіювати, посилатися чи федерувати.
Ландшафт — не те, що я малюю після того, як архітектуру завершено. Це те, як я архітектуру знаходжу. А коли вам здасться, що він готовий, не милуйтеся ним. Пройдіть ним. Кожна стрілка, яку ви ще не можете пояснити, показує, де робота.
