Эта статья — первая в серии из трех частей о том, как можно формировать стратегию своей платформы. Но для начала несколько слов благодарности и дисклеймеров.
Я рассказываю об этом, потому что это тема, о которой меня спрашивают довольно часто. И вот я наконец решил поделиться своими мыслями и опытом для более широкой аудитории.
Я могу почти с полной уверенностью сказать, что в этой статье, как и во всех остальных моих работах, практически нет ничего оригинального. Я лишь делюсь тем, что узнал от окружающих меня людей. Я в значительной степени полагаюсь на DDD (предметно-ориентированное проектирование) и свой опыт работы в командах по стратегии цифровых платформ в ThoughtWorks. Было бы очень несправедливо, если бы я не упомянул Райана Мюррея (Ryan Murray) — его вдохновение и руководство легли в основу моих собственных взглядов на обширную тему стратегий платформ.
И наконец, стратегия без исполнения — всего лишь галлюцинация; если вы серьезно относитесь к реализации своего видения платформы, вам понадобится нечто большее, чем просто понимание того, чем я здесь делюсь. Вам понадобится практическая помощь людей с релевантными навыками и опытом. Я работал с многими такими людьми (со многими продолжаю работать до сих пор) и могу вас с ними познакомить. Просто свяжитесь со мной.
Давайте поговорим о проблеме
Проблема, которую цифровые платформы пытаются решить, формулировалась несколькими способами, но все они сводятся к трениям, стоящим на вашем пути к достижению большей скорости и масштаба для бизнеса, команды или организации. Мне кажется, эту мысль хорошо проиллюстрирует короткий “комедийный” скетч о микросервисах, потому что для большинства из нас… это совсем не комедийный скетч, это наша реальность.
Скетч про микросервисы от ютубера Krazam
Здесь можно сделать паузу и составить целый список того, в чем вы можете увидеть проблему. Но я сосредоточусь на том, что разработчик справедливо называет главной проблемой только через 10 секунд после начала видео.
“Это архитектура нашего бэкэнда”
Осенью 2015 года я начал работать с клиентом в сфере авиаперевозок. Это было началом моего путешествия в мир создания цифровых платформ. Клиент столкнулся с потребительской “запросом” мобильности, который был естественным результатом последствий революции смартфонов, захлестнувшей всю отрасль. Поэтому они решили расширить возможность бронирования, регистрации и изменения рейсов за пределы дестктопного веб-сайта и задействовать мобильные каналы.
Бэкенд был намного проще в разработке, когда их пользователям хватало десктопного веб-сайта. Теперь же их пользователи ожидали, что на своих смартфонах они смогут делать то же самое, что и на компьютере. Команда, к которой я присоединился, занималась разработкой первого мобильного канала на iOS, и ожидалось, что мы масштабируемся до большего количества команд для Android и мобильных веб-каналов. Мы испытывали проблемы роста, которые, как я позже узнал, проистекали из трех основных причин;
Отсутствие согласованной стратегии предоставления текущих бизнес-возможностей клиентам по нескольким каналам.
Требуется много очень много коммуникационных усилий, чтобы разобраться, с какими командами лучше взаимодействовать для предоставления клиентам новых возможностей.
Ключевые бизнес-возможности дублируются в нескольких сервисах и приложениях, что затрудняет их обслуживание, развитие и повторное использование.
На разработку правильного уровня абстракций сервисов для бэкенда было затрачено очень много усилий, но эти абстракции по-прежнему приводили к вызывающим всеобщую фрустрацию обсуждениям, подобным тем, что проиллюстрированы в скетче. Это связано с тем, что дизайн этих абстракций не был связан с бизнесом (и клиентами), для которых они предназначались. Такие сервисы, как Bingo, Papaya и Racoon, являются хорошими примерами проблемы из скетча выше.
Абстракции, основанные на бизнесе
Два года спустя я познакомился с предметно-ориентированным проектированием (DDD) и узнал о подходе, основанном на DDD, который может помочь определить границы в сложной растущей экосистеме программного обеспечения и бизнеса. Это был не тот подход, который я использовал в работе с тем авиаклиентом, но оказался именно тем подходом, который я применял в нескольких случаях, когда мне требовалось определить и развить стратегию платформы для моих последующих клиентов.
Я впервые услышал термин “абстракции, основанные на бизнесе” (business truthful abstractions), который использовал Райан Мюррей. И я думаю, что это подводит нас прямо к сути дела — как можно очертить границы программного обеспечения в своей “системе”, чтобы они были максимально помогали в поддержки бизнеса по мере его развития и масштабирования. Это по сути концепция цифровой платформы в двух словах. Это набор абстракций, раскрывающих бизнес-возможности через API и позволяющий комбинировать эти возможности для предоставления новых возможностей для постоянно меняющихся потребностей и желаний клиентов.
Проектирование, нейминг и развитие этих абстракций на основе бизнес-потребностей — это ваш секрет успеха, который упрощает обмен информацией о них для растущей организации.
Создание self-service API уменьшит трения между командами, необходимые для создания новых возможностей.
Разработка их таким образом, чтобы их можно было развертывать и выпускать независимо друг от друга в качестве самостоятельных продуктов, позволяет командам, которым они принадлежат, предоставлять их быстрее и надежнее.
Процесс определения этих возможностей является как интуицией (от людей с глубоким пониманием предметной области), так и наукой (из опыта тех, кто создавал программное обеспечение в больших масштабах), но целью является достижение связности (cohesion), самообслуживания (self-service) и компонуемости (compos-ability), необходимая для обслуживания клиентов.
Что вас ждет в будущем
Этот сайт не является блогом, это цифровой сад, поэтому вполне вероятно, что эта статья и другие, которые последуют за ней, будут получать значительные обновления, поскольку будут включать в себя отзывы, которые я получаю, и по мере того, как мое понимание того, чем я хочу поделиться здесь, будет эволюционировать. Увидимся в следующей части этой серии!
Приглашаем всех желающих на открытое занятие «Прошлое, настоящее и будущее роли архитектора предприятия». На этом вебинаре у нас будет возможность обсудить роль архитектора предприятия: кем были, кем стали и кем должны быть в обозримом будущем, и почему.
Поговорим о необходимых компетенциях агента изменений и базовых знаниях для позитивного влияния в организации. Увидим, где начинается архитектурный подход и куда нужно стремиться в профессиональном развитии. Регистрация по ссылке.