Это вторая статья из серии статей о стратегии платформ. Ознакомиться с первой статьей можно по этой ссылке.

Предыдущая статья была посвящена проблеме, которую стратегия платформы призвана решать, и преимуществам для вашей платформы от определения границ программного обеспечения, основываясь на бизнесе, для которого оно разрабатывается.

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

Бизнес-возможности

В целом есть две “отправные точки” для формирования стратегии платформы. Решение новой бизнес-задачи и декомпозиция существующего монолита. На самом деле, декомпозиция существующего монолита — это хорошее начало. Это может говорить о том, что команда, по всей видимости, уже достаточно хорошо понимает предметную область бизнеса благодаря усилиям, затраченным на создание и поддержку монолита. И возможно команда способна строить хорошие гипотезы о том, где именно проходят правильные границы.

С другой стороны, определение возможностей для новой бизнес-задачи означает, что у вас нет технического долга, который связан с существующим монолитом, но в этом случае, как и в случае с монолитом, мы должны признать, что наше программное обеспечение (сервисы), которое мы создаем, в значительной степени основаны на предположениях и абстракциях. Преимущество этих абстракций для наших клиентов и их компонуемость увеличиваются, когда они моделируются на основе бизнеса.

Карта пути клиента

Мой любимый подход к определению бизнес-возможностей — начать с того, что я называю “реальными вещами”. А они, как правило, принимают форму старых добрых путей клиента/пользователя (Customer/User journey). Я считаю их вполне реальными, потому что мы знаем, что эти пути отражают события реального мира. Путь клиента содержит в себе шаги, которые клиент предпринимает для достижения цели, которую он считает важной и за которую готов платить. Вот почему мы можем с уверенностью основывать нашу дискуссию о моделировании предметной области на таких артефактах. Все остальное, например, сервисы, модули, компоненты, развертывания и даже команды, является абстракцией, которую мы создаем и которая должна каким-то образом соответствовать реальным вещам, и в конечном итоге имеет значение только в том случае, если помогает нам создать программное обеспечение, которое поддерживает эти пути клиентов.

Я провожу свои тренинги по созданию карт путей пользователей всего для двух или трех участников (я стал замечать, что отдача уменьшается по мере увеличением числа участников), ведь по сути все, что нам нужно, это кто-то, кто знаком с бизнес-проблемой (клиент или бизнес-эксперт), и кто-то из команды разработчиков (например, инженер-программист).

После того, как вы наметили большее количество основных путей пользователей, начинают вырисовываться бизнес-возможности, необходимые для того, чтобы сделать эти пути пользователей осуществимыми. Следующий шаг, который я сделаю, — попытаюсь создать бизнес-возможности из каждого шага пути пользователя. Разобрав первые нескольких путей, вы начнете замечать повторение возможностей, и для меня это хороший показатель того, что ваши возможности можно повторно использовать как минимум для двух пользователей. Вот схема, разработанная мною специально для авиакомпании (одного из моих клиентов, о котором я рассказывал в прошлой части).

Используйте глаголы, а не существительные

Видео из первой статьи иллюстрирует хаос, который возникает из-за абстрактных названий для ваших бизнес-возможностей, но вопрос, как лучше назвать эти сервисы, все еще актуален? Подход, который я нашел эффективным, заключается в том, что вы задаете вопрос, что именно дает эта возможность, и с помощью интуитивного ответа на этот вопрос даете ей подходящее название. Поначалу это может показаться странным, особенно если вы в этом совсем новичок, но я обнаружил, что правильное название приносит дивиденды за счет упрощения коммуникации внутри и между командами, работающими над созданием этих возможностей, и пользователями, которые их используют.

Анти-паттерн, с которым я столкнулся, касается существительных, таких как “пассажирское сообщение” или “служба обеспечения перелетов” (passenger-service or flight-service). Я подозреваю, что это пережиток объектно-ориентированных методов проектирования. Передаю привет моему бывшему коллеге Джону Феминелле, который очень красноречиво описал еще более нерекомендуемый анти-паттерн с именованием возможностей/сервисов здесь. Для вас будет очень полезно ознакомиться с этой цепочкой твитов.

Такие глаголы, как “сервис бронирования” (booking-service), намного лучше, потому что они точно описывают, что конкретно делает возможность. Мой товарищ по команде расширил этот принцип до объектных глаголов вместо обычных глаголов, что тоже хорошо. Такие названия, как “бронирование авиабилетов” (flight-booking) или “бронирование автомобилей” (car-reserving) еще более информативны.

Event Storming

Мне рассказали об еще одном подходе — Event Storming, который может быть полезен для определения этих возможностей. Я не использовал этот подход раньше, но мне кажется, что это очень энергозатратный процесс, так как он требует большого количества участников и серьезной координации групповой работы, чего, по моему опыту, обычно не хватает. Но если вы сможете найти нужных людей и сильного руководителя, я думаю, что результат такой работы будет отличным.

Технологические возможности

Если рассматривать такую ​​возможность платформы, как бронирование (возможность зарезервировать место на определенном маршруте в определенную дату), то легко представить ее как простое программное приложение, которое управляет процессом бронирования билетов для пользователя. Но когда это программное приложение работает не так, как ожидалось, и команде срочно нужно это исправить, вы быстро оцените, насколько инфраструктура для развертывания изменений для этого приложения является частью вашего продукта. Ваша способность отслеживать и предупреждать нужных членов команды, когда приложение не работает должным образом, является важной частью вашей предлагаемой ценности (value proposition).

Это те части любого программного продукта, которые не представляют собой что-то конкретное из сферы бизнеса (авиаперевозки), но необходимы команде для эффективной разработки этого самого программного продукта. Именно их я отношу к категории технологических возможностей (technology сapabilities). Я слышал, что эти возможности также называются инфраструктурой/экосистемой доставки или внутренними платформами разработчиков.

Различие между возможностями (такими как развертывание приложений) и инструментами (такими как jenkins), которые предоставляют эти возможности, помогает команде понять, что именно им нужно от каждого конкретного инструмента. Я уже подробно раскрывал это различие в одной из предыдущей статей. Как и в случае с бизнес-возможностями, я определяю предложенную ценность для каждой возможности, чтобы управлять ее картой пути. Такие возможности обычно не являются определяющими для бизнеса, поэтому я бы по умолчанию выбрал менее затратный вариант - их покупку (с небольшой настройкой), а не создание их по индивидуальному шаблону. Провайдеры общедоступных облачных сервисов — хорошая отправная точка, чтобы найти нужные вам возможности по вполне адекватным ценам.

Как и в случае с бизнес-возможностями, пользовательский путь по-прежнему остается лучшим подходом, который я нашел для определения технологических возможностей. Члены команды разработчиков в вашей организации являются вашими пользователями. Я понял, что проще определить, что им нужно для эффективного снабжения программным обеспечением, чем пути для внешних пользователей, благодаря тому, что они находятся ближе ко мне (как внутренние пользователи). Лично я предпочитаю подобные разговоры, поскольку они, как правило, не участие “посредников”, как в случае с бизнес-возможностями, а просто представляют из себя прямые наблюдения и дискуссии в реальном времени с реальными пользователями этих возможностей.

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

Дальнейшие шаги

В своей первой статье я упомянул, что стратегия без исполнения — это всего лишь галлюцинация, поэтому нам нужно поговорить о том, как воплотить эту стратегию платформы в жизнь. Организация команд для эффективной работы с возможностями платформы требует культурного сдвига в сторону применения продуктового мышления к тому, как они предоставляют и развивают эти возможности.

Я делюсь своими знаниями об этом и преимуществами, которые я увидел, в части 2: Продуктовое мышление.

Материал подготовлен в рамках курса "Enterprise Architect".