Вопрос, на который отвечает этот модуль: как нарисовать ландшафт, который показывает, куда идут данные?
Дайте мне новый сценарий и чистую доску, и одно из первых, что я нарисую, — системный ландшафт. Не красивый, не со всеми 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 — рядом с ядром, управляется в ядре и размещается вне ядра (модуль 1). Одна линия обратно к Salesforce показывает, кто им управляет. То, где вы ставите прямоугольник, должно рассказывать историю о том, что он делает.
Ничто в этой геометрии не священно. Ценность соглашения в том, что я не изобретаю визуальный язык каждый раз заново, а любой, кто видел одну мою диаграмму, быстрее прочитает следующую.
Держите нотацию простой. Каждая система — это карточка: ее название, ее роль и маленький значок, который говорит, что это за вещь: ERP, база данных, поставщик удостоверений, группа людей. Области, которые я только что описал, рисуются как бледные подписанные зоны, чтобы сама схема была видна. Легенда внизу объясняет, что означает каждый значок и каждая линия.
Не кладите слишком много внутрь прямоугольника. Только на очень сложном ландшафте я раскрываю Salesforce на части (Sales Cloud и Service Cloud внутри org со стрелками между ними). И не изобретайте пятнадцать фигур, если каждая не сообщает читателю что-то. Я хочу, чтобы человек посмотрел на ландшафт тридцать секунд и начал понимать архитектуру. Вычурность не помогает. Помогает ясность.
Не ждите детального проектирования, чтобы подумать об объеме. Стрелка, по которой идут 500 продуктов за ночь, и стрелка с 200 000 показаний GPS в день на ландшафте могут выглядеть совершенно одинаково. Это не одна и та же задача. Поэтому, прежде чем нарисовать хоть одну стрелку, посчитайте, что движется. Начните инвентаризацию за рисунком с цифр: по строке на каждый важный набор данных, с его объемом. Нули могут так и не появиться на стрелках, но вам нужно знать, когда вы переходите к большим числам: тысячи или миллионы в час, сотни тысяч транзакций, даже от десятков до сотен транзакций в секунду.
Эти числа определяют механизм. Несколько сотен записей за ночь — это пакетная обработка. Вызов, которого кто-то ждет, может быть синхронным, если позволяет объем. Десяткам или сотням в секунду могут понадобиться события, например platform events, а не вызов на каждую запись. Стрелка будет выглядеть так же; что по ней пойдет, решает объем, поэтому записывайте его в инвентаризацию, где выбирается механизм.
Механизм может даже поменять направление стрелки. Отправляете пару записей в минуту — и Salesforce может просто сделать вызов (callout): стрелка начинается у Salesforce. Отправляете намного больше — и Salesforce может вместо этого публиковать события в шину событий; внешняя система подписывается и приходит за ними сама, так что теперь стрелка начинается с другого конца. Еще больше, скажем, ночная синхронизация миллионов записей, — и это пакетный процесс. Поэтому знайте свои цифры рано, когда начинаете проектировать механизмы, потому что цифры могут перерисовать стрелки.
Объем важен в двух местах по двум причинам. На модели данных он нужен мне, чтобы следить за большими объемами данных и планировать архивирование; часть 2 разбирает это глубоко. На системном ландшафте большие числа в инвентаризации определяют выбор шаблона интеграции и механизма. Модуль 6 ставит реальные нули на ландшафт Steve Trucking и его инвентаризацию. С цифрами на руках рисуйте стрелки.
Когда системы на месте, соедините их, и ландшафт становится архитектурой. Прямоугольник — это система; стрелка показывает, кто инициирует соединение. Она начинается у системы, которая открывает соединение, и указывает на ту, которую та вызывает: от клиента к серверу. Подпись говорит, что движется и в какую сторону.
Это правило — для системных ландшафтов, где системы говорят с системами. На диаграмме потоков данных стрелка, как и следует ожидать, следует за данными. Не переносите правило ландшафта на другие диаграммы; это только добавит путаницы.
Стрелки добавлены. Каждый прямоугольник там же, где был; каждая стрелка начинается у системы, которая открывает соединение, а ее подпись говорит, что движется и в какую сторону.
Итак, если слой интеграции отправляет продукты в Salesforce, стрелка идет от слоя интеграции к Salesforce с подписью продукты внутрь. Если Salesforce сам делает вызов, чтобы их забрать, стрелка начинается у Salesforce, и подпись по-прежнему продукты внутрь. Те же данные, другой разговор, и эта разница говорит мне, кому нужны учетные данные и кто должен обрабатывать сбой. Salesforce отправляет заказ через слой интеграции: заказы наружу. Исполнение из ERP возвращается: статус заказов внутрь. Теперь я вижу, кто начинает каждый разговор, где данные входят в Salesforce и где покидают его, какие потоки пересекают границы, где, вероятно, находится владение и где мне нужно спросить больше.
И помните модуль 1: когда я вижу только один поток, я начинаю беспокоиться. На верхнем уровне стрелка заказы наружу зависит от обратных потоков: клиенты внутрь, продукты внутрь, цены. Посмотрите еще глубже — и там обратный путь: принятие, отклонение, статус, номер счета, отмена. Стрелки дают мне что-то конкретное, к чему можно предъявить вопросы.
Вот где ландшафт перестает быть картинкой в PowerPoint. На review board любая стрелка может вызвать три вопроса, и я хочу, чтобы у вас были ответы:
Как проходит аутентификация? OAuth, сертификат, Named Credential, что-то еще?
Это синхронно или асинхронно? Ждет ли Salesforce ERP или публикует и продолжает работу? Как быстро бизнесу нужен результат?
Какой механизм? Вызов REST, событие, файл, очередь сообщений, через MuleSoft или напрямую?
А затем: что происходит, когда другая сторона недоступна? У каждой стрелки должен быть механизм. Если вы не можете его объяснить, линия — просто украшение.
И «отправил и забыл» — это не ответ. Обычно это значит «я не спроектировал, что происходит после отправки». Дошло ли? Приняли ли? Не сломалось ли? Будет ли повтор? Кто узнает, что все застряло? Что, если одно и то же сообщение придет дважды? Ничего из этого на ландшафт не попадает, иначе он станет нечитаемым. Но стрелка должна напоминать вам, что эти вопросы существуют.
Приблизьте любую стрелку — и там клиент и сервер, и каждый отвечает за свою половину. Клиент открывает соединение: ему нужны конечная точка и порт, сначала он получает токен у сервера аутентификации, вызывает протокол и контракт, которые определяет сервер, и выбирает, ждать ли ответа. Только клиент видит весь цикл запроса и ответа, поэтому только клиент может повторить попытку. Сервер слушает, определяет протокол, контракт и полезную нагрузку, проверяет то, что приходит, и видит только свою часть. Когда я рисую стрелку, я уже знаю, где какой конец, и это говорит мне, кто отвечает за каждый из этих вопросов.
Одна стрелка крупным планом: клиент обеспечивает, сервер определяет. Ничего из этого не попадает на ландшафт, но у каждой стрелки это есть.
Теперь разверните стрелку. Когда ERP вызывает Salesforce, Salesforce — сервер: он определяет API, запускает собственный сервер авторизации и через External Client App и интеграционного пользователя решает, что вызывающей стороне разрешено. Те же вопросы, другая сторона.
Вот где архитекторы портят хорошую диаграмму: они заставляют один артефакт отвечать на все. На ландшафте появляются имена API, полезные нагрузки, повторные попытки, очереди ошибок, преобразования, каждый обратный вызов, и скоро никто не может его прочитать. Не надо. Ландшафт — это общая картина: системы и важные потоки между ними.
Когда мне нужно объяснить взаимодействие, я рисую вторую диаграмму, но не для каждой интеграции. Если система 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, время, аутентификация и копировать, ссылаться или федерировать.
Ландшафт — это не то, что я рисую после того, как архитектура готова. Это то, как я нахожу архитектуру. И когда вам кажется, что он закончен, не любуйтесь им. Пройдите по нему. Каждая стрелка, которую вы пока не можете объяснить, показывает, где работа.
