Czytaj książkę: «Архитектура цифровых платформ. От настоящего к будущему»

© Андрей Николаевич Трушкин, 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 продукте (описан в «Архитектуре цифрового мира»). Уточним, что мы рассматриваем в примере финансовый продукт, который можно подразделить на следующие составляющие (для демонстрации применения нескольких «платформ»):

• Учетная составляющая, в рамках которой предполагается ведение синтетического учета данных о продукте.

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

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

• Фронтальная составляющая, формирующая пользовательское представление о продукте и операциях, проводимых с ним (включая как внешних, так и внутренних пользователей).

Что же происходит в организации, которая, приняв за руководство к действию следование платформенным подходам, попадает в ментальную ловушку «множества платформ» (как мы увидим ниже)?

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

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

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

Автоматизация бизнес-процессов предполагает возможность быстрого создания и изменения последних, а также обеспечение их мониторинга, расчета КПЭ и т. д. Продуктовые бизнес-процессы предполагают исключительно широкие возможности настройки, необходимость создания и исполнения кросс-продуктовых процессов (задействующих различные типы продуктов с генерацией совместной аналитической и синтетической учетной логики), потенциал создания большого количества точек интеграции, использование современных практик low-code и no-code для проектирования и исполнения процессов. Можно констатировать, что требования к удобству и гибкости настроек для данного слоя исключительно актуальны. Долгое время считалось, что вопросы производительности на уровне настройки и исполнения бизнес-процессов уходят на второй план по сравнению с гибкостью, но современный мир диктует необходимость изменения подобного подхода. В условиях повсеместного развития дистанционных каналов обслуживания невысокая производительность автоматизированных бизнес-процессов приведет к утрате конкурентоспособности организации, допустившей указанный недостаток. Например, низкая скорость обработки поступающих заявок на кредит исключает привлекательность для клиентов каналов, не требующих аутентификации (например, сайты компании или ее партнеров), обнуляя возможность лидогенерации, что недопустимо для организации, ставящей во главу угла интенсивное развитие. При этом вопросы выполнения групповых и пакетных операций (по аналогии с автоматизацией аналитического учета) практически неактуальны. Вопросы мониторинга исполняющихся процессов, напротив, крайне важны: специалисты, ответственные за развитие бизнес-процессов организации, должны иметь возможность моделирования и установки КПЭ процессов, клиенты и партнеры нуждаются в развитой статусной модели процессов, позволяющей получать информацию о состоянии интересующих их процессов и обрабатываемых в ходе их исполнения данных. При этом традиционной характеристикой автоматизации бизнес-процессов является высокое потребление вычислительных ресурсов при выполнении данной задачи. Соответственно, необходим мониторинг ресурсов, потребляемых теми или иными бизнес-процессами и их экземплярами, на основании данных которого оказывается возможным обеспечивать «здоровье» ИТ-ландшафта организации. В рассматриваемом случае речь идет о командах DevOps и/или сопровождения, являющихся пользователями мониторинга бизнес-процессов. То есть речь идет как о системном, так и о прикладном характере мониторинга. Пользователи же мониторинга являются как внутренними с точки зрения организации, так и внешними. Проанализировав все указанные аспекты, мы приходим к необходимости высоких требований к возможностям пользовательского интерфейса «платформы» автоматизации бизнес-процессов. При этом автоматизация бизнес-процессов в большинстве случаев не предполагает транзакционного характера исполняемых операций (в части того, что операции на уровне данной составляющей не являются типовыми и/или короткоживущими).

При автоматизации фронтальной составляющей продукта особое внимание уделяется упомянутым выше «клиентскому пути» и «дизайн-мышлению», а также аналогичным им аспектам. В противном случае конкурентоспособность продукта оказывается чрезвычайно низкой в современном цифровом мире, инвестирование средств в создание, развитие и продвижение такого продукта теряет всяческий смысл. При несомненной важности рассмотренных выше аспектов продуктовой автоматизации фронтальное представление является базовой составляющей формирования эффективного P&L (profit and loss analysis) продукта. Составляющей исключительной важности в случае фронтального представления является производительность этого самого автоматизируемого фронтального представления: в случае медленной отрисовки графики по продукту, длительного переключения экранов представления потенциальный (да и действующий) клиент потеряет интерес к продукту, обратит внимание на предложения конкурентов, и организация понесет убытки. Особенно актуален вопрос производительности в условиях дистанционных каналов, далеко не все из которых в процессе лидогенерации предъявляют требования к обязательности аутентификации или заполнению пространных анкет. В условиях резкого роста числа каналов продукты должны быть представлены если не в каждом из них, то в некоем значимом множестве. В противном случае можно неоправданно сократить воронку продаж. И организация приходит к необходимости поддержки концепции омниканальности, при которой все каналы коммуникации с пользователями (в их число могут входить не только клиенты организации, но и ее сотрудники и партнеры) объединяются в единую связанную экосистему, при этом коммуникация в рамках продуктового взаимодействия носит сквозной характер. Таким образом достигается целостное взаимодействие пользователей с автоматизируемым продуктом. Но как обеспечить рассматриваемую омниканальность? Зачастую организации добавляют в свой ландшафт очередную «платформу» – омниканальную, в задачи которой входит:

• Отделение логики представления от процессной.

• Предоставление развитых инструментов создания интерфейсов.

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

• Обеспечение непрерывности коммуникации с пользователями.

• И многие другие…

Также отметим уже ставшее фактически стандартом де-факто требование, предъявляемое к технологиям создания фронтальных интерфейсов, заключающееся в легковесности последних. Фронтальные приложения и их компоненты выполняются на самых разных устройствах, обеспечивают различные каналы коммуникации, вынуждены учитывать проблемы сетевого взаимодействия и т. д. Создание тяжеловесных фронтальных компонентов пользовательского приложения фактически обнуляет конкурентоспособность продукта, а вместе с ним и организации, его предоставляющей. Соответствующее требование легковесности транслируется и в отношении омниканальной «платформы», отличая ее от предшествующих.

Изучив приведенное выше описание, читатель непременно задаст вопрос: «Так в чем же отличие этого платформенного подхода от классической SOA-архитектуры? В такой ситуации надо создавать микросервисы, которые обеспечат распределенность, а то по факту просто системы заменили платформами!» И принципиально внимательный читатель будет прав: фактически значимая доработка продукта, созданного в подобной архитектуре, будет весьма схожа с его доработкой при реализации принципов SOA. Действительно, столь разная организация автоматизации каждого уровня продукта, предоставляемого организацией клиентам и/или партнерам, потребует фактически выделенной продуктовой команды на каждом уровне. Да, в случае простого продукта можно составить продуктовую команду, отвечающую принципам гибких практик, но современные продукты (а особенно если речь идет о кросс-продуктах) крайне сложны, требуют привлечения специалистов разных компетенций. А потому даже на одном уровне автоматизации (при приведенном выше примере принципиально различных технологических и организационных требованиях к базису каждого) может оказаться весьма затруднительным собрать единую команду гибких практик, развивающую соответствующий продукт. После чего возникнет необходимость синхронизации работы команд для обеспечения качества создаваемого продукта, дабы последний не стал подобен лоскутному одеялу из слабо связанных между собой доработок, что в свою очередь может повлечь как рыночную слабость продукта, так и нарушение непрерывности его предоставления. При этом команда развития каждого уровня автоматизации продукта реализует требуемые доработки с разной скоростью, зависящей от функциональной и нефункциональной составляющей, например:

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

• Различный технологический базис уровней автоматизации приводит к разной скорости их развития в соответствии с нефункциональными требованиями.

Добавим сюда еще и возможное попадание в ментальную ловушку, рассмотренную в главе «Архитектуры цифрового мира», посвященной цифровым платформам, а именно создание выделенных команд разработки и развития платформ. В случае масштабирования указанной ошибки на рассматриваемую в примере организацию может оказаться вероятным, что продукт разрабатывается набором команд гибких практик разработки, при этом для каждой платформы в организации существует отдельная команда развития. Получается, что в общем случае (при условии высокой сложности автоматизируемого продукта) мы можем столкнуться с ситуацией, при которой в реализации значимой продуктовой доработки могут быть задействованы до восьми (!) команд разработки. Синхронизация их деятельности становится весьма нетривиальной задачей. И даже совмещение платформенных и продуктовых команд в отдельных случаях (например, это вполне возможно для случая автоматизации функций синтетического учета) не привносит принципиального упрощения ситуации. И стоит учесть, что в рассматриваемом примере мы сознательно учитывали относительно простую структуру как продукта, так и организации. Последняя может внедрять еще и «платформу CRM», и расширяющую «омниканальную платформу» «платформу» ДБО, к примеру, и «платформу MDM», и многие другие аналогичные «платформы».