Ландшафт Steve Trucking

🌐 Также доступно на 28 языках

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)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 6 из 6 главы Понимание корпоративных данных, глава 4 курса Data Architect. Каждый модуль самостоятелен. Назад: Стратегия org — это решение на уровне ландшафта · Далее: следующая глава, Качество данных и управление ими

Вопрос, на который отвечает этот модуль: что реальный ландшафт сообщает нам еще до того, как мы что-либо спроектируем?

Вся эта глава отодвигала камеру назад: Salesforce как одна система среди многих, виды данных, системы вокруг Salesforce, как нарисовать ландшафт и стратегия org. Теперь соберем все вместе на примере Steve Trucking. Но чинить пока ничего не будем. В этом и дисциплина: нарисуйте то, что есть, пройдите по каждой стрелке и посмотрите, что говорит ландшафт.

Начнем с того, что мы знаем

У Steve Trucking один org Salesforce (организация Salesforce), в США. Service Cloud обрабатывает обращения от получателей (Recipients) и розничных партнеров (Retail Partners); Field Service ведет встречи, бригады и мобильное приложение; Experience Cloud дает розничным партнерам портал, который сегодня используется только для претензий и отчетов; Sales Cloud отслеживает договоры с партнерами и заявки на новые распределительные центры (DC). Значит, Salesforce ставим в середину.

Слева люди: 45 координаторов диспетчерской службы, работающих внутри распределительных центров розничных партнеров, около 700 членов бригад на 330 грузовиках, 60 сотрудников службы поддержки клиентов, 40 сотрудников операционного отдела, финансов и продаж и около 300 пользователей у розничных партнеров. Это уже кое-что говорит: перед нами не CRM одного отдела. Это операционная платформа для большей части бизнеса. Но это все еще один прямоугольник. Теперь посмотрим, что его окружает.

Click to enlarge

Steve Trucking сегодня, до нормального внедрения. Каждый манифест попадает в RouteDesk; координаторы вручную перебивают маршруты в Salesforce, а выполненные остановки — обратно; у FleetLink нет подключения.

Отметьте, что не так

Это текущее состояние, до нормального внедрения, и я прямо пишу это на рисунке. А потом открываю палитру. На ландшафте готовой системы я не использую красный; на текущем состоянии использую. Красный отмечает плохой или неправильный процесс, штриховая линия — то, что делается вручную, а красные точки — недостающее подключение. Отсутствующая стрелка тоже о чем-то говорит. Ничто из этого не украшение: каждая красная линия — это требование, которое ждет, чтобы его записали.

Три партнера, три интеграции

Три розничных партнера присылают манифесты тремя разными способами, поэтому рисуйте каждого отдельно.

Keystone каждый день после обеда кладет CSV-манифест на SFTP-сервер, для доставки через два дня, и хочет каждую ночь получать обратно файл статусов. Две стрелки: манифест внутрь файлом, соединение открывает Keystone, и статус наружу файлом, соединение открывает RouteDesk. Асинхронно, с широким временным окном.

Redrock присылает манифесты через REST API и ждет обновлений статуса через webhook по мере того, как они происходят. Две стрелки, два механизма: Redrock вызывает нас с манифестами через API, а RouteDesk вызывает Redrock со статусом через webhook. Почти в реальном времени.

Brightwave присылает файлы EDI через стороннюю сеть и ждет в ответ статусных сообщений EDI. Другой формат, другой механизм.

Одни и те же бизнес-понятия (манифест, доставка, статус) — и три совершенно разные интеграции. Не упрощайте рисунок только потому, что вам хотелось бы, чтобы они были единообразными. Они не такие. Это и есть текущее состояние.

Потом пройдите по ним. Keystone: как аутентифицируется SFTP-соединение, куда попадает файл, что его забирает, как мы узнаем, что весь файл обработан, что происходит с ошибочной строкой и как Keystone узнает об изменении до сегодняшнего ночного файла? Redrock: как аутентифицируется API, что происходит, когда одна из сторон недоступна, что считается успешным webhook, а что, если один и тот же статус придет дважды? Brightwave: кто управляет сетью EDI, где происходит преобразование, какие подтверждения приходят обратно? Мы ничего не перепроектируем. Мы находим вопросы. Это и есть работа ландшафта.

RouteDesk никуда не делся

RouteDesk — это устаревший настольный инструмент диспетчеризации и построения маршрутов, которым координаторы в каждом распределительном центре превращают манифесты в маршруты. В нем восемь лет истории доставок, и его планируют вывести из эксплуатации. Все равно нарисуйте его. Частая ошибка — не рисовать систему, «от которой мы избавляемся». Когда? Допустим, ответ — через восемнадцать месяцев. Значит, как минимум восемнадцать месяцев она часть архитектуры, а ее восемь лет истории, около пяти миллионов доставок, не исчезнут вместе с приложением. И посмотрите, что открывает ландшафт: RouteDesk и Salesforce не связаны. Бригады отрабатывают свои остановки в приложении Field Service в Salesforce, но маршруты строятся в RouteDesk, поэтому координаторы каждый вечер вручную перебивают их в Salesforce, а потом перебивают выполненные остановки обратно в RouteDesk, чтобы он мог отправить статус партнерам. Около 3300 остановок в день, дважды, вручную. На рисунке это штриховая красная линия. Это же говорит вам, что webhook Redrock «по мере того, как происходит» на самом деле не так уж «по мере». Чем RouteDesk владеет сегодня? Что от него зависит? Какая история должна его пережить и где: в Salesforce, в хранилище, в архиве? Мы пока не отвечаем. Ландшафт просто открыл вопросы.

FleetLink — это остров

FleetLink, телематическая платформа, получает GPS от каждого грузовика: около 200 000 показаний в день, каждый грузовик, каждую минуту, пока он едет. И она ни к чему не подключена. Координаторы смотрят на нее на отдельном экране. Поэтому нарисуйте FleetLink без стрелок. Никакой волшебной линии интеграции только потому, что, по-нашему, она должна быть.

Потом посчитайте нули: 200 000 в день — это больше 70 млн в год. Это не «у нас есть данные GPS». Это потоковый источник с большим числом нулей, который находится за пределами Salesforce. Нужны ли Salesforce 70 млн показаний в год? Скорее всего, не все. Это вопрос проектирования на потом.

У финансов своя правда

Финансовая ERP выставляет каждому розничному партнеру счета за каждую доставку, установку и вывоз, а также выплачивает бригадам премии. А количество доставок попадает в нее через ежемесячную таблицу. Нарисуйте таблицу. Не заменяйте ее аккуратной стрелкой API только потому, что мы архитекторы и знаем, как лучше; она часть текущей архитектуры. А когда она нарисована, появляются вопросы: кто ее делает, из какой системы, кто ее проверяет, что, если доставка изменилась уже после отправки, и чье число побеждает? К ответам привязаны деньги.

Snowflake получает еженедельную выгрузку

В Snowflake живет аналитика операционного отдела и финансов, и наполняет его еженедельная выгрузка. Сам Snowflake этого сделать не может; это делает что-то посередине: задание экспорта по расписанию, работающее вне Salesforce, которое забирает данные через Bulk API и загружает их в Snowflake. Где живет аналитика, определяется тем, где живут данные, и Snowflake уже стал домом для аналитики. Но и частота кое-что говорит. «Что произошло в прошлом месяце?» Еженедельной загрузки достаточно. «Где эта доставка прямо сейчас?» Со Snowflake я бы начинать не стал. Одно и то же предприятие, другая нагрузка, другая свежесть, другой ответ.

Удостоверение доходит до всех по-разному

Корпоративный поставщик удостоверений (identity provider) располагается над Salesforce. Офисные сотрудники используют единый вход (single sign-on). Но координаторы и бригады входят с учетными данными Salesforce. Поэтому одна линия доверия от IdP к Salesforce скрыла бы половину истории. Настоящий вопрос — какие пользователи входят каким путем, и это место на ландшафте.

В опыте получателя есть пробел

Провайдер SMS и электронной почты отправляет получателям из RouteDesk общее сообщение «ваша доставка завтра». Ссылки для отслеживания нет. А между тем в год около 180 000 обращений, и около 60 % из них — «где моя доставка?»: примерно 108 000 обращений в год с одним и тем же вопросом. Теперь поставьте это рядом с FleetLink. Компания знает, где ее грузовики. Ее получатели продолжают звонить и спрашивать. И система, которая знает, не подключена к той, что отвечает. Мне пока не нужно проектировать решение. Ландшафт уже рассказывает историю.

Запишите нули в инвентаризацию

Теперь посчитайте, что движется. Как и в модуле 4, нули не пишутся на стрелках; они идут в инвентаризацию за картинкой, откуда при проектировании будут определять механизмы. Около миллиона доставок в год, около 3300 в день, рост 30 % в год; в среднем около 1,6 позиции на доставку; около восьми обновлений статуса на доставку, то есть сегодня восемь миллионов обновлений статуса в год; четыре-пять миллионов фотографий в год, сейчас на личных телефонах бригад; около 200 000 показаний GPS в день; около 180 000 обращений в год. Стрелка с подписью «статус доставки» — это не редкое сообщение. Прямоугольники говорят вам, что существует. Стрелки говорят, что движется. Нули говорят, переживут ли ваши допущения встречу с реальностью.

Click to enlarge

Инвентаризация за ландшафтом Steve Trucking: объем рядом с механизмом, который он будет определять.

Целевой архитектуры еще нет, а я уже вижу, где живут важные данные, какого они вида, как быстро движутся и как системы ими обмениваются.

За пределами экзамена: что меняет ИИ. Допустим, Steve Trucking создает агента, который отвечает получателю на вопрос «где моя доставка?». К какой системе он должен обращаться? Salesforce знает о встрече, FleetLink знает, где грузовик, манифест партнера определил доставку. Текущий ландшафт — это карта агента, и прежде чем агент сможет отвечать безопасно, архитектор должен знать, какая система авторитетна для каждого факта и насколько он актуален. Направьте агента на неправильный источник — и устаревшие данные станут уверенным ответом.

Прочитайте боль, но пока не лечите

Отойдите на шаг. Три партнера, три стиля интеграции. Устаревший инструмент диспетчеризации с восемью годами истории, и координаторы, которые перебивают 3300 остановок в день в Salesforce и обратно. Телематическая платформа с 200 000 показаний в день, ни к чему не подключенная. Финансы, которые считают доставки по ежемесячной таблице. Аналитика, отстающая на неделю. Единый вход для одних пользователей, но не для других. Нет ссылки для отслеживания, и 108 000 обращений в год с вопросом, где доставка. И все это растет на 30 % в год.

Это очень много архитектуры из одной картинки. Хочется сразу начать чинить. Не надо. Пока не надо. Я хочу, чтобы вам было спокойно оставлять диаграмму текущего состояния некрасивой, потому что иногда текущее состояние некрасивое. Смысл не в том, чтобы кого-то впечатлить аккуратным рисунком; смысл в общем понимании реальности. Перепроектируйте, пока документируете, — и вы потеряете исходную точку. Потом я хочу иметь возможность сказать: вот что было, вот какую проблему мы решили, вот что мы изменили и почему. В главе 6 мы начинаем принимать решения о владении и идентичности, а Контрольная точка 1 собирает Часть 1 воедино. Курс Integration Architect подробно проектирует потоки с партнерами.

Что здесь решает архитектор

На этом этапе архитектор не решает, какой будет целевая архитектура. Решение в том, достаточно ли хорошо понято текущее состояние, чтобы ее спроектировать:

• Какие системы, группы пользователей, хранилища данных и внешние партнеры реально существуют сегодня.
• Какие данные пересекают каждую важную границу, в каком направлении, как часто и каким механизмом.
• Где сейчас живут операционные, аналитические, потоковые, исторические и неструктурированные данные.
• Какие потоки несут наибольший объем и заслуживают внимания в первую очередь.
• Какие пробелы, ручные шаги, неподключенные системы, неясные полномочия и непоследовательные шаблоны становятся явными вопросами проектирования.

Эта глава началась с одной идеи: нарисуйте ландшафт, прежде чем проектировать org. Если бы я начал с модели данных Steve Trucking, я мог бы потратить часы на объекты и связи, пока FleetLink оставался бы снаружи с 200 000 показаний в день, RouteDesk хранил бы восемь лет истории, три партнера говорили бы на трех языках, финансы пользовались бы таблицей, а сто тысяч обращений в год спрашивали бы, где доставка. Это не вопросы объектной модели. Это вопросы корпоративных данных. Нарисуйте некрасивые интеграции, таблицу, систему, которую вы якобы выводите из эксплуатации. Запишите нули. Пройдите по каждой стрелке. Тогда вы готовы это менять.

Дополнительно

• Бриф Steve Trucking, разделы 2–4, и его диаграмма ландшафта.