Архитектура цифровых платформ. От настоящего к будущему
Андрей Николаевич Трушкин
В настоящей книге изложены основы построения современных и устремленных в будущее цифровых платформ, рассматриваются характерные элементы, обязательные для любой платформы. Поднимаемые в книге вопросы затрагивают все этапы жизненного цикла платформ и продуктов, создаваемых на их основе. Особое внимание уделено архитектуре платформ, рискам, возникающим при их создании и развитии, а также способам преодоления этих рисков. Книга будет полезна как ИТ-специалистам, так и руководителям организаций.
Архитектура цифровых платформ
От настоящего к будущему
Андрей Николаевич Трушкин
© Андрей Николаевич Трушкин, 2024
ISBN 978-5-0064-5813-0
Создано в интеллектуальной издательской системе Ridero
Введение
Данная книга является логическим продолжением предыдущего труда автора – «Архитектура цифрового мира». Бытует мнение, что каждая книга (или серия книг) должна быть логически завершенной, позволять осмыслить изложенное в ней в целом. Подобное мнение имеет право на существование. Однако жизнь не стоит на месте и дарит пищу для размышлений с учетом как прочитанного, так и ранее изложенного. А потому мы идем дальше и стараемся расширить и углубить те мысли, которые были представлены в предыдущей книге, на нее же будем регулярно ссылаться по ходу настоящего изложения.
Ранее мы достаточно подробно останавливались на вопросах цифровых платформ, им посвящен отдельный раздел в «Архитектуре цифрового мира». Вместе с тем роль цифровых платформ в современном цифровом же мире, их позиционирование, взаимовлияние исключительно важны: платформы (а в дальнейшем мы, в отсутствие дополнительных уточнений, будем подразумевать под платформами именно цифровые платформы) привлекают внимание не только ИТ-специалистов, но и ученых, философов, политиков, историков и многих других специалистов. Можно сказать, что платформы являются самостоятельным направлением развития цифрового мира. И потому крайне важно рассмотреть подобное направление, так как его значение с течением времени будет только возрастать. Именно указанному рассмотрению и посвящена настоящая книга.
Опираясь на базис, сформированный в предыдущем труде, мы принимаем за основу, что платформа является фреймворком создания и исполнения ИТ-решений организации. При этом платформы могут выходить за рамки конкретной организации, объединяя в структуре экосистемы целые отрасли человеческой деятельности. Примером может служить инструментальная реализация концепции banking-as-a-platform (BaaP), при которой различные организации схожих областей деятельности объединяются на одной платформе. Аналогичным образом сложные холдинговые структуры могут объединять собственные продукты и процессы на общих кросс-платформах. Также значимым фактором современной жизни являются социальные платформы, объединяющие людей в различных странах и на разных континентах. Кроме того, нельзя забывать те характеристики платформ, которые являются следствием потенциальных ментальных ловушек, связанных с платформенными проектированием и реализацией:
• Платформа не является информационной системой.
• Платформа не является обособленным программным комплексом.
• Платформа должна быть открытой, и изменения в нее могут вносить любые команды, которые должны брать на себя ответственность за вносимые изменения.
• Платформа не должна быть замкнутой.
Для полноты восприятия вкратце раскроем вышеперечисленные тезисы, напомнив их читателю.
Тот факт, что платформа не является информационной системой, обусловлен отсутствием самостоятельной ценности, создаваемой и привносимой пользователям и клиентам, со стороны платформы. Ценность создается продуктами, реализуемыми приложениями, которые в свою очередь создаются и исполняются при помощи платформы, то есть ценность платформы опосредованная. Таким образом, платформа не содержит смысла самостоятельного овеществления в ИТ-ландшафте организации.
Обособление (не путаем с овеществлением, характерным для информационных систем), предполагающее независимое технологическое позиционирование платформы, приводит к необходимости сложной синхронизации платформенных (содержащих технологические функции) и прикладных (содержащих функции, реализация которых несет непосредственную ценность клиентам) бэклогов, существенному усложнению релизных циклов и т. д. Кроме того, говоря о необходимости избегать обособления платформ в ИТ-ландшафте, мы подчеркивали необходимость обеспечения их встраиваемости в приложения, в рамках реализации которых и создается непосредственная пользовательская ценность.
Открытость платформ предполагает обеспечение их прозрачности для команд разработки, создающих ценность для клиентов и партнеров организации. Команды должны иметь возможность дополнять функциональность платформ, при этом дополнения становятся достоянием всех работающих с платформой команд, то есть платформы подчиняются принципам проектов с открытым исходным кодом (возможно, в ограниченном формате, при котором платформенное сообщество формируется в масштабах развития организации).
Отсутствие замкнутости платформ предполагает их постоянное развитие в технологическом плане, открытость новым технологическим трендам, изменениям лицензионных соглашений и т. д. По сути, требования к платформе быть открытой и не быть замкнутой являются взаимно дополняющими друг друга. Тем самым обеспечивается возможность интенсивного развития платформы, платформенных приложений и сервисов, самой организации, применяющей платформенный подход, достижение необходимого уровня архитектурного mindset.
Перечисленные свойства платформ не предполагают, что они (платформы) являются некими «черными дырами» ИТ-ландшафта, засасывающими финансовые, временны?е, трудовые и иные ресурсы организаций, но при этом не имеют четких границ и областей применения. Наоборот, платформы должны быть наиболее прозрачными (пусть и не обособленными) компонентами приложения усилий, ведь их опосредованное участие в создании ценности становится ценностным мультипликатором организаций, применяющих платформенный подход, обеспечивающим интенсивное развитие, препятствующим росту энтропии, риск которого является существенным при современных требованиях к цифровизации. Если мы говорим о том, что современная компания является ИТ-компанией, предоставляющей услуги самого широкого спектра деятельности (как основного профиля, так и смежных и вспомогательных), то скорость цифровизации, предполагающая кардинальное изменение мышления, переход к продуктовому подходу от классических проектного или процессного, вполне может способствовать росту энтропии. И сдержать его может помочь платформенный подход, о чем мы и поговорим в настоящей книге.
Разумеется, это не означает, что платформа, создающая опосредованную ценность, а также платформенные приложения «скованы одной цепью», то есть являются неразрывным целым с некой жестко определенной структурой. Возможно, побудительные мотивы выстраивания подобной структуры в организациях и могут возникать, но они являются очередной ментальной ловушкой, подстерегающей нас на пути следования интенсивному развитию. Такие структуры оказываются хрупкими, а потому либо являются недолговечными в быстро меняющемся цифровом мире и водовороте новых требований, либо приводят организации к застою и деградации, за которыми следует потеря конкурентоспособности. Платформы должны иметь распределенную сервисную структуру, предоставлять платформенные сервисы, а платформенные приложения должны бесшовным образом как исполняться на платформе, так и взаимодействовать между собой. Вопросы связи платформ, платформенных сервисов и платформенных приложений будут рассмотрены в соответствующей главе.
За время, прошедшее с написания предыдущей книги автора, подчеркнутые в ней ключевые тенденции развития архитектуры не только не угасли, но и дополнительно укрепились. Как архитектура в целом, так и платформы обязаны им следовать. Перечислим данные тенденции:
• Открытый код, на котором основываются ключевые технологические решения современности.
• Распределенность (при этом в данное понятие входит как технологическая, так и организационная составляющая).
• Бизнес-процессы, автоматизация которых несет конечную ценность для клиентов и пользователей.
• Данные, являющиеся основным богатством организаций, а потому принимаемые в качестве краеугольного камня цифровизации.
• Искусственный интеллект, проделавший существенный качественный рост (пусть негативно настроенные авторы и утверждают, что виной тому эффект низкой базы).
Успешные платформы современности (например, развиваемые технологическими гигантами) следуют вышеперечисленным тенденциям. Но следование им не является прерогативой только технологических гигантов – это веление времени, а потому любая организация, стремящаяся сохранить конкурентоспособность на рынке, должна учитывать их, творчески адаптировать, а также синхронизировать платформенный подход (обязательный к применению для обеспечения интенсивного развития) с указанным перечнем. Вопросы применения и адаптации приведенных ключевых тенденций развития архитектуры в сочетании с платформенным подходом, соответствия платформ данным тенденциям будут рассмотрены в соответствующей главе.
При этом автор не ставит своей целью описать единственное верное построение цифровой платформы, тем более что это и невозможно. Современное развитие технологий, связанное с ним изменение лицензионных соглашений, проработка новых топологий развертывания, формирование новых архитектурных подходов исключают не просто решение, но и саму постановку подобной задачи. При обосновании использования, проектировании, реализации и развитии платформ необходимо следовать ключевым тенденциям развития архитектуры, учитывать представленные ранее свойства платформ, а также принимать во внимание необходимость перманентного интенсивного развития организации, являющегося ключом к конкурентоспособности. Только такой mindset позволит обеспечить реализацию и использование и постоянное развитие платформ, обеспечивающих указанную конкурентоспособность. И только такой mindset приемлем для архитектора, являющегося лидером технологических изменений. Также мы не будем обсуждать вопросы сайзинга оборудования, применяемого для развертывания платформ и платформенных приложений.
Отметим, что и сейчас актуально утверждение, приведенное в «Архитектуре цифрового мира»: частные случаи и конкретные технологические решения будут упоминаться лишь в качестве примеров, иллюстрирующих комплексное рассмотрение.
Отдельно следует заметить, что автор сознательно избегает рассматривать в настоящем изложении вопросы архитектуры конкретных платформ. Любые совпадения с частными архитектурными, технологическими или организационными решениями существующих платформ случайны.
Проблематика современных цифровых платформ
Читатель, увидев заголовок настоящей главы, может задаться вопросом: «Какая же проблематика? Повсеместно можно услышать про необходимость создания или развития цифровых платформ, любая уважающая себя компания либо создает собственную, либо использует внешнюю/внешние. Нет здесь никаких проблем, за исключением, может быть, финансовых». Но в том-то и дело, что зачастую словесный вал лишь затушевывает суть: вместо создания и развития платформ во многих случаях происходит экстенсивное развитие унаследованного ИТ-ландшафта. Нередко отсутствует даже экстенсивное развитие, а организации уже выходят на тропу мысленной и технологической деградации. И финансовые проблемы играют здесь совсем не основную роль. Попробуем разобраться, в чем же истинная проблематика современных платформ.
В «Архитектуре цифрового мира» (в разделе «Архитектура и цифровые платформы») мы уже говорили о том, что термин «цифровая платформа» является многозначным в современном мире, приводили примеры такого использования данного термина, как «платформа Google», «омниканальная платформа», «платформа Java» и некоторые другие. К сожалению, и на сегодняшний день указанная многозначность не изжита, она присутствует и в специальной литературе, и в дискуссиях самого разного уровня, и в публичных выступлениях. Как результат, создаются все новые и новые «платформы», при этом крайне сложно выявить ценность их внедрения и использования. Продукты у компаний, внедряющих подобные «платформы», зачастую попросту отсутствуют, рассматриваются лишь классические процессные подходы и методологии, сами же внедряемые «платформы» являются потребителем финансовых ресурсов, последние безостановочно направляются на «развитие», реальным же «выхлопом» являются застой и деградация. Разумеется, далеко не все платформы являются таковыми, но автор вынужден констатировать, что попадание в ментальные ловушки, характерные как для цифровизации в целом, так и для работы с платформами, является нередким случаем в современном мире.
Другим полюсом, характеризующим совершенно иные результаты применения платформенных подходов, являются мировые технологические гиганты, которые (благодаря достижению высокого технического уровня) получают возможность реагировать на изменения в конъюнктуре, потребительских предпочтениях, экономических тенденциях на совершенно иной скорости, а также с недоступной еще относительно недавно адресностью. В начале 2024 года один из крупнейших мировых технологических гигантов представил результаты мониторинга, показавшие, что в среднем изменения в используемую им технологическую платформу и продукты, предоставляемые посредством платформенных приложений, вносятся каждые 11,6 секунды. Во-первых, подобная оперативность позволяет реагировать на современные вызовы с адекватной скоростью, сохраняя конкурентоспособность организации. Во-вторых, указанная скорость реакции позволяет задавать ориентир для конкурентов, усугубляя положение тех из них, кто не в состоянии реагировать на вызовы с сопоставимым уровнем оказания услуг. Таким образом, подобный технологический гигант не просто сохраняет адекватность требованиям рынка при предоставлении продуктов и услуг клиентам и партнерам, но и наращивает отрыв от конкурентов, повышая собственные шансы на монополизацию тех или иных сегментов рынка. И основой здесь является именно платформенный подход.
Предположим, что организация, ИТ-ландшафт которой реализован в классической парадигме сервис-ориентированной архитектуры (SOA), столкнется с необходимостью столь же быстрого внесения изменений, связанного, например, с быстро меняющейся рыночной конъюнктурой. Для примера предположим, что ИТ-ландшафт выстроен в формате, представленном на Рисунке 1. Организация стремится оставаться в рыночных трендах и поэтому перешла (хотя бы на декларативном уровне) к продуктовой методологии. Но «продукт», предоставляемый организацией, является результатом выполнения операций в нескольких (предположим, что в четырех) информационных системах, созданных с использованием различных технологий.
Рисунок 1. ИТ-ландшафт в парадигме SOA
Рассмотрим значимое изменение в «продукте», предоставляемом организацией, как результат работы указанных четырех информационных систем. Под значимым изменением в продукте будем понимать такое изменение, которое влияет на его функциональные (например, перерасчет ставки по кредиту с одновременным изменением рассматриваемого клиентского пула) и нефункциональные (например, требования к новым дистанционным каналам, предполагающие взрывной рост нагрузки) характеристики. Подобное значимое изменение в продукте в общем случае предполагает изменения во всех информационных системах, результатом проводимых операций в совокупности которых является продукт. Таким образом, команда доработки продукта должна включать в себя специалистов, компетентных в соответствующих системах (в рассматриваемом примере – четырех). Используемые в настоящее время информационные системы не являются монотехнологичными, а содержат развитый технологический базис построения. Подобная ситуация предполагает (в случае значимых изменений) привлечение специалистов различного технологического профиля, профессионализм которых позволяет производить масштабные изменения, затрагивающие весь перечень технологий, используемых в информационных системах. Уже привлечение трех-четырех специалистов по каждой информационной системе обеспечит превышение традиционной мощности команд гибких практик (если таковые применяются в организации). Учтем, что значимые изменения, как правило, не выполняются силами выделенных единичных специалистов, поскольку являются трудоемкими, требуют документирования, обмена опытом и т. д. Получается большой коллектив с заметным профессиональным и технологическим разнообразием, к тому же внимание отдельных специалистов резонно будет сфокусировано на доверенных им информационных системах, что дополняет проблематику внесения значимого изменения необходимостью синхронизации деятельности соответствующих специалистов, представляющих подкоманды разработки. Разумеется, ни о каких 11,6 секунды на изменение говорить уже не приходится. Учтем необходимость тестирования, выполнения релизной политики (зачастую также весьма громоздкой) – и получим совершенно неприемлемые с точки зрения современной конъюнктуры значения скорости внесения изменений. Как результат, организацию ожидают застой и деградация, за которыми следует утрата конкурентоспособности.
Приведенный выше пример может показаться надуманным. Но еще в середине 2010-х годов проводилось сравнение крупных российских организаций, осуществлявших цифровую трансформацию, с мировыми технологическими гигантами. Сравнение осуществлялось по показателю количества изменений, вносимых ими в ключевые приложения. Показатели российских организаций за квартал уступали аналогичным показателям технологических гигантов в день. Основными составляющими подобного преимущества назывались следование платформенному подходу (разумеется, каждый гигант формирует собственную платформу) и гибким практикам разработки. Как мы видим, мировые лидеры не сбавляют оборотов. Соответственно, следует не просто не игнорировать составляющие их успеха, но и внимательнейшим образом их изучать и адаптировать. И здесь речь идет не только и не столько о гибких практиках (пусть это и исключительно важный аспект обеспечения конкурентоспособности в современном мире), сколько о комплексном архитектурном mindset, а также о его воплощении в платформенном подходе.
Настало время поговорить о еще одном негативном аспекте, возникающем при обсуждении платформ. Одним из результатов такого обсуждения (собственно негативным аспектом) становится многообразие терминов: «омниканальная платформа», «учетная платформа» и т. д. Предположим, что организация, рассмотренная выше, рассчитывает встать на путь интенсивного развития, применив платформенный подход. В результате осмысления проблем, возникающих при развитии ИТ-ландшафта, характеризующегося многообразием информационных систем, организация начинает создавать платформы и обеспечивать путем их исполнения предоставление продуктов клиентам и партнерам. Пример «продукта», характерного для указанного изменения подходов, представлен на Рисунке 2.
Рисунок 2. «Продукт», формируемый множеством «платформ»
И предположим, что рассматриваемый «продукт» претерпевает значимое изменение. Для прозрачности рассмотрения укажем, что речь идет об end-to-end продукте (описан в «Архитектуре цифрового мира»). Уточним, что мы рассматриваем в примере финансовый продукт, который можно подразделить на следующие составляющие (для демонстрации применения нескольких «платформ»):
• Учетная составляющая, в рамках которой предполагается ведение синтетического учета данных о продукте.
• Частная учетная составляющая, на уровне которой обеспечивается связь синтетического и аналитического учета, формируется видение учета продукта для организации (в случае нашего примера – финансовой).
• Процессная составляющая, обеспечивающая автоматизацию операций по созданию, заведению, постановке на учет, сопровождению продукта, то есть весь комплекс сложных бизнес-процессов, поддерживающих жизненный цикл продукта.
• Фронтальная составляющая, формирующая пользовательское представление о продукте и операциях, проводимых с ним (включая как внешних, так и внутренних пользователей).
Что же происходит в организации, которая, приняв за руководство к действию следование платформенным подходам, попадает в ментальную ловушку «множества платформ» (как мы увидим ниже)?
В общем случае для каждого уровня продуктовой автоматизации, представленного выше, выбирается собственная платформа, обладающая ключевыми для обеспечения необходимого каждому уровню качества характеристиками.
