Андрей Трушкин
Цифровой продукт XXI века.
Концепция и архитектура

«Издательские решения»

Трушкин А. Н.
Цифровой продукт XXI века. Концепция и архитектура /
А. Н. Трушкин — «Издательские решения»,

ISBN 978-5-00-683471-2
В настоящей книге подробно изложены технологические основы построения
современных цифровых продуктов, рассматриваются характерные
особенности, обязательные для архитектуры конкурентоспособного продукта.
Обсуждаемые в книге вопросы затрагивают все этапы жизненного цикла
цифровых продуктов. Особое внимание уделено тенденциям развития
архитектуры цифровых продуктов и применению цифровых платформ при
их создании и развитии. Книга будет полезна как ИТ-специалистам, так и
руководителям организаций.

ISBN 978-5-00-683471-2

© Трушкин А. Н.
© Издательские решения

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Содержание
Введение
Общий подход к архитектуре цифровых продуктов
Цифровые продукты и ключевые тренды развития архитектуры
Ключевые тренды развития архитектуры в концепции цифровых
продуктов
Цифровые продукты и открытый код
Цифровые продукты и распределенность
Цифровые продукты и бизнес-процессы
Цифровые продукты и данные
Цифровые продукты и искусственный интеллект
Цифровые продукты и связанные тренды развития архитектуры
Цифровые продукты и процессы
Цифровые платформы и цифровые продукты
Применение цифровых платформ в создании цифровых
продуктов
Открытость цифровых платформ в продуктовой методологии
Цифровые продукты и платформенные сервисы
Цифровые продукты как платформенные приложения
Будущее цифровых продуктов
Благодарности

6
11
39
39
44
62
86
110
176
190
214
232
232
241
251
267
277
280

4

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровой продукт XXI века
Концепция и архитектура
Андрей Николаевич Трушкин

Корректор Лилиана Голава

© Андрей Николаевич Трушкин, 2025
ISBN 978-5-0068-3471-2
Создано в интеллектуальной издательской системе Ridero

5

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Введение
Настоящая книга является логическим продолжением трудов автора «Архитектура цифрового мира» и «Архитектура цифровых платформ. От настоящего к будущему». Мы уже отмечали во введении ко второму из них, что каждая из указанных книг и серия книг в целом
должны быть логически завершенными, а потому стремимся достичь упомянутой завершенности, развивая тематики, поднятые в ранних трудах. Разумеется, мы стремимся развивать
те аспекты изложения, которые отмечались в предыдущих работах, но, в силу их важности
и актуальности, заслуживают отдельного и более пристального внимания.
Исключительно важным таким аспектом являются цифровые продукты. В открытых
источниках содержится огромное количество информации самого различного характера о них,
тем не менее зачастую отсутствует четкое понимание того, что же именно является цифровым
продуктом. Цифровым продуктом называют программное обеспечение, онлайн-сервисы, программные приложения и т. д., при этом указанные понятия зачастую смешиваются и подменяют друг друга. Мы уже останавливались на тематике цифровых продуктов, посвятив соответствующий раздел в «Архитектуре цифрового мира» непосредственно их архитектурным
аспектам, а в «Архитектуре цифровых платформ» в течение всего изложения проводили грань
между собственно цифровыми платформами и цифровыми продуктами. В данной книге мы
планируем подробно рассмотреть проблематику цифровых продуктов в контексте архитектуры, так как именно последняя является связующим звеном бизнес-процессов, данных, гибких методологий, цифровых платформ, цифровых продуктов и т. д. Как мы уже говорили
ранее, архитектура является сквозным артефактом создания ценности. А именно ценность
(самостоятельная ценность) характеризует цифровой продукт. Просто программное обеспечение либо сервис, доступный в сети Интернет, сами по себе не могут считаться цифровыми
продуктами. Они становятся цифровыми продуктами только после того, как на их основе
возникает ценность для клиентов или партнеров организации, предоставляющей упомянутые
программное обеспечение или сервис. Мы уже обсудили в предыдущих книгах современные
архитектурные тенденции и практики, архитектуру цифровых платформ, теперь настало время
цифровых продуктов.
Сразу отметим, что в дальнейшем под продуктами мы будем понимать именно цифровые продукты, под платформами – цифровые платформы. Говоря об архитектуре, мы будем
подразумевать ИТ-архитектуру.
Рассматривая вопросы концепции и архитектуры продуктов, создаваемых организациями в рамках интенсивного развития, мы будем опираться на материал, разобранный по ходу
предыдущих книг, упомянутых ранее. Мы уже отмечали (см. «Архитектура цифрового мира»),
что в современных реалиях актуален продукт, предоставляющий комплексную, законченную
и самостоятельную ценность для клиентов и/или партнеров организации, – продукт, который
мы именуем end-to-end продуктом. Указанный продукт с архитектурной точки зрения должен
включать в себя все основные аспекты автоматизации, такие как:
• Канальная логика представления, при этом число каналов должно бесшовно расширяться без оказания влияния на непосредственно продуктовую логику (за исключением тех
случаев, когда продуктовая логика является канало-специфичной).
• Собственно продуктовые процессы, описывающие полный жизненный цикл продукта.
• Работа с данными, имеющими отношение к продукту («продукт данных», рассмотрению которого будет посвящен соответствующий раздел в настоящей книге).
• И т. д.
6

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

При этом на различных этапах жизненного цикла ИТ-решения (не путаем с продуктом)
подходы к автоматизации различных продуктовых составляющих могут принципиально отличаться, чему также будет посвящено соответствующее обсуждение в ходе настоящей книги.
В процессе изложения, посвященного платформенному подходу (см. «Архитектура цифровых платформ. От настоящего к будущему»), мы неоднократно отмечали, что платформа
не предоставляет самостоятельной ценности, но предоставляет ценность опосредованную, позволяя эффективно создавать продукты в формате платформенных приложений. Автор этих
строк, объясняя далеким от ИТ людям ценность современной платформы, прибег к следующей аналогии: «Представим, что мы строим коттеджный поселок. Мы можем строить каждый
дом независимо, независимо обеспечивать его электроэнергией, канализацией, водой, газом
и т. д. Стоимость каждого дома окажется исключительно высокой, различия между ними
колоссальными, обеспечение современной согласованной эксплуатации подобного поселка
практически невозможным, что также принципиально увеличивает общие затраты на текущую эксплуатацию. Возможно создание одинаковых домов, связанных между собой галереями. В таком случае мы снижаем затраты на создание и эксплуатацию каждого дома в поселке,
но одновременно сужаем потребительский рынок и оказываемся вынуждены искать покупателей, готовых делить подобные дома друг с другом, а также восприимчивых к соответствующему архитектурному стилю. И наконец, мы можем обеспечить поселок унифицированными
магистральными газом, водой, электроэнергией, канализацией. При этом дома будут разные,
но создаваться по набору типовых проектов и легко подключаться к уже существующей инфраструктуре. Первый вариант представляет собой развитие без платформы, второй предполагает
смешение платформы и продуктов на ее основе, третий – современная цифровая платформа».
Поэтому рассмотрение архитектуры продуктов в книге пойдет в контексте третьего пути, так
как именно он обеспечивает и скорость развития, и унификацию, и гибкость собственно продуктовой логики. А поскольку рассмотрение продуктов будет проводиться с учетом платформенных тенденций, то мы также будем принимать во внимание и ключевые свойства современных платформ, подробно описанные в предыдущих трудах автора. Для полноты изложения
кратко напомним их читателю:
• Платформа не является информационной системой.
• Платформа не является обособленным программным комплексом.
• Платформа должна быть открытой, и изменения в нее могут вносить любые команды,
которые должны брать на себя ответственность за вносимые изменения.
• Платформа не должна быть замкнутой.
Если в целом охарактеризовать влияние указанных свойств платформ на продукты, предлагаемые современной организацией, то можно отметить следующее.
Платформа не предоставляет продукты сама по себе, продукты создаются при помощи
платформенных механизмов, которые в свою очередь упрощают и удешевляют создание непосредственной ценности – продуктов. При этом продукты не обособляются от платформы в технологическом плане, что приводит к формированию платформенно-продуктовой экосистемы,
в рамках которой нет необходимости в сложной синхронизации платформенных и продуктовых бэклогов. Одновременно с этим развитие платформы осуществляется открытым образом: при отсутствии той или иной платформенной функциональности, необходимой для развития продукта, продуктовая команда разрабатывает ее и дополняет платформу. Существующие
на сегодня принципы развития решений с открытым исходным кодом предоставляют для этого
широкие и удобные возможности. Одновременно с этим предполагающее постоянное развитие отсутствие замкнутости позволяет поддерживать высокую технологическую зрелость продуктов, без которой невозможно сохранение ценностного предложения. Подводя краткий итог
7

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

вышесказанному, подчеркнем, что рассмотрение современных продуктов и тенденций их разработки будет осуществляться в рамках настоящей книги в увязке с платформенным подходом.
В течение всей предыдущей книги («Архитектура цифровых платформ. От настоящего
к будущему») мы выводили понятия платформенных сервисов и платформенных приложений, проводили разграничение между ними. Поскольку в текущем изложении мы переходим
от ценности опосредованной, предоставляемой платформами, к ценности непосредственной,
заключающейся в продуктах, то в соответствующей главе мы рассмотрим взаимосвязи между
платформенными сервисами, платформенными приложениями и продуктами, которые организация создает и развивает в ходе своей деятельности.
В первой книге автора были рассмотрены ключевые тенденции развития архитектуры.
Данные тенденции не потеряли своего значения, они только набирают силу, поэтому во второй
книге они были рассмотрены в контексте платформенного подхода. И поскольку все тенденции
сохраняют свою актуальность, то в настоящем изложении они будут рассмотрены в соответствующей главе в контексте подхода продуктового. Перечислим рассматриваемые тенденции:
• Открытый код, на котором явно или неявно основываются ключевые технологические
решения современности.
• Распределенность. Здесь будет нелишним напомнить читателю, что в данное понятие
входит как технологическая, так и организационная составляющая.
• Бизнес-процессы, комплексная и сквозная автоматизация которых несет конечную ценность для клиентов и пользователей.
• Данные, являющиеся основным богатством организаций, а потому принимаемые
в качестве краеугольного камня цифровизации.
• Искусственный интеллект, пусть его зачастую и пытаются свести исключительно к экспертным системам. Современная цифровизация, создание и развитие продуктов уже немыслимы без всеобъемлющего применения технологий и практик искусственного интеллекта.
Организация, устремленная в будущее, обязана учитывать вышеперечисленные тенденции в своем развитии. И продукты свои планировать, создавать и развивать соответствующим
образом. Использование указанных ключевых тенденций в продуктовом развитии, их влияние
на продуктовое мышление будут рассмотрены далее в соответствующей главе. Там же мы рассмотрим и связанные с основными тенденции развития архитектуры в контексте их влияния
на продукт XXI века, которому и посвящена данная книга.
Исключительно важной составляющей создания и развития продуктов является процессная составляющая. И мы сейчас говорим не о продуктовых бизнес-процессах, а о процессной модели организации, ставящей себе целью предоставление продуктов (или услуг в формате продуктов). Мы уже подчеркивали в предыдущих книгах, что «проектное» мышление,
предполагающее четкие фазы развития, активную работу в ходе самого проекта, последующее
постпроектное сопровождение, может не позволить обеспечивать перманентное интенсивное
развитие, учитывающее необходимость создания полноценных end-to-end продуктов. И мышление в организациях должно меняться, приобретать продуктовый характер. А также вместе
с мышлением должна меняться процессная модель организации, она обязательно должна приобретать упомянутый продуктовый характер. Указанному изменению будет посвящена отдельная глава настоящей книги.
В данном контексте нельзя не коснуться закона S-кривой, который мы обсуждали и в двух
предыдущих книгах. Мы рассматривали его применение для области информационных технологий, для платформенного подхода, для искусственного интеллекта, но необходимо рассмотреть и для продуктов. При этом сопоставить с платформенным развитием и изменением мышления в компаниях. На Рисунке 1 схематично и очень условно приведено это сопоставление.

8

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 1. S-кривая продуктового и платформенного подхода, а также мышления
Условность приведенного сравнения определяется тем фактом, что мы сводим на один
рисунок, казалось бы, принципиально разные явления: изменение мышления, применение
платформенного и продуктового подхода, между которыми лишь несколькими строками выше
проводили водораздел. На самом деле никакого противоречия нет: именно применение платформенных подходов позволяет кардинально повысить эффективность перехода к продуктовому мышлению, которое в свою очередь обеспечивает качественное создание и развитие продуктов организации, меняющей мышление и внедряющей платформы. Таким образом, мы
наблюдаем спиралеобразный характер развития организации и рынка в целом, включающий
мышление, платформы и продукты. Внимательный читатель незамедлительно поинтересуется
тем фактом, почему же продукты находятся на S-кривой выше платформ (тем более, платформ
технологических гигантов), а платформы выше мышления. Нет ли тут ошибки с нашей стороны? Мы же ответим, что никакой ошибки нет, и вот почему.
Мы уже ссылались в первой книге на исследование уважаемой консалтинговой компании, показавшее на рубеже веков, что внедрение информационных технологий не привело
к повышению производительности труда в компаниях, осуществлявших указанное внедрение, большему, нежели в среднем по экономике. Исключение составили лишь те организации,
где информационные технологии были средством производства. Указанное исследование грамотно подчеркнуло те вызовы, которые стояли перед отраслью информационных технологий.
Одним из ответов на обозначенные вызовы стало сперва точечное и ограниченное стартапами,
а затем все более массовое применение гибких методологий и их адаптаций. Это в свою очередь привело к ориентации на ценность для конечного заказчика при автоматизации его деятельности, то есть созданию продуктов. И лишь затем появилось понимание платформенного
подхода, а также тех преимуществ, которые он предоставляет продуктовой разработке. Более
того, мы сознательно указываем на Рисунке 1 платформы именно технологических гигантов,
так как многие организации до сих пор находятся в ментальном плену заблуждений, каса9

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ющихся платформ. Детализация данных заблуждений приведена в «Архитектуре цифровых
платформ» в главе «Проблематика современных цифровых платформ». И поэтому путь по Sкривой платформами пройден меньший, нежели продуктами.
Ситуация с мышлением во многом аналогичная. Начав на словах переходить к продуктовой методологии, к продуктовой разработке, многие компании продолжали оперировать категориями «проектного» мышления, что приводило к тому, что жизненный цикл продукта в их
понимании соответствовал жизненному циклу проекта. Говорить об интенсивном развитии
в таком случае не приходится, ведь продукт должен перманентно развиваться в соответствии
с P&L (Profit&Loss Analysis – анализ прибылей и убытков), в то время как на фазе постпроекта
его развитие будет в лучшем случае экстенсивным. И работа с мышлением далеко не завершена, можно сказать, что по-настоящему она только начинается. Поэтому проблематике организационных процессов, их месту в развитии продуктов будет посвящена отдельная глава.
Вопросы гибких методологий уже набили оскомину. Не первое десятилетие на крупных
совещаниях, конференциях, презентациях звучит «Agile, agile, agile». Увы, одного звучания
мало для достижения подлинной эффективности. Многие воспринимают гибкие методологии
в формате карго-культа. И крупные компании вынуждены адаптировать их, в противном случае вместо гибкости они получают «Waterfall со стендапами», а вместо современных продуктов
лоскутное одеяло автоматизированных систем или «множества платформ», на базе которых
невозможно управлять эффективностью цифровизации. Ситуация на самом деле гораздо более
серьезная, чем может показаться на первый взгляд. Уровень прохождения S-кривой продуктового подхода, как мы показали на Рисунке 1, выше, чем у платформенного, и, тем более, выше,
нежели у продуктового мышления. Емкость мирового рынка конечна, а потому область насыщения для цифровых продуктов не является чем-то недостижимым. Указанное явление может
привести к застою, а затем и деградации всего рынка информационных технологий. Потому
крайне важно перейти к подлинно интенсивному продуктовому развитию. И в этом продуктовому подходу помогут подход платформенный, изменение мышления и грамотная адаптация
гибких методологий, чему будет посвящена отдельная глава.
В настоящем Введении необходимо повторить несколько тезисов, на которые мы обращали внимание в предыдущих книгах. Мы не рассматриваем вопросы составления сетевых
схем или управления инфраструктурой при обеспечении создания и развития продуктов. Данный круг вопросов исключительно важен, но остается вне нашего рассмотрения ввиду их частного характера. Частные случаи и технические решения мы упоминаем лишь в качестве иллюстративных примеров.
Также повторим утверждение из предыдущей книги, что автор сознательно избегает рассматривать в настоящем изложении вопросы архитектуры конкретных продуктов. Любые совпадения с частными архитектурными, технологическими или организационными решениями
существующих продуктов случайны.

10

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Общий подход к архитектуре цифровых продуктов
«Замечательно! Изучим данную главу, дальше можно не читать, ведь все уже сказано про
архитектуру!» – воскликнет нетерпеливый читатель, увидев название настоящей главы. И будет
в корне неправ, ведь разговор об архитектуре мы сейчас только начнем и наметим основные штрихи для дальнейшего обсуждения. Но базовый задел закладывается именно в данный
момент.
Все современные методологии управления архитектурой учат нас, что при проектировании ИТ-решений необходимо крайне внимательно учитывать требования к создаваемому
или развиваемому программному комплексу. Конечно, необходимо учитывать и нефункциональную составляющую требований, но решение, не удовлетворяющее запросам пользователей, то есть требованиям функциональным, не имеет практического смысла. Развивая данную
мысль, мы обязаны сказать, что архитектура продукта должна опираться на ценность, предоставляемую им клиентам и/или партнерам организации, создающей и развивающей продукт.
То есть основой архитектуры продукта является его ценность. Приведенное умозаключение
на самом деле гораздо масштабнее, нежели может показаться на первый взгляд. Далее мы поясним почему.
По ходу предыдущих книг мы неоднократно отмечали в корне неверное позиционирование продукта во многих современных организациях. Во Введении настоящей книги мы
также отметили указанный факт на Рисунке 1, поместив в S-кривой продуктовое мышление
на гораздо менее зрелой (ранней) стадии, нежели платформенный и продуктовый подходы сами
по себе. Действительно, зачастую управление продуктом включает в основной фокус внимания исключительно его запуск на рынке, при этом не учитывает весь жизненный цикл, значимые этапы которого отдаются на откуп исключительно техническим специалистам. В подобных
примерах говорить о комплексном end-to-end продукте невозможно. Но мы при разборе имеющихся заблуждений пойдем дальше. А что же в принципе можно считать продуктом и предоставляемой им ценностью?
Мы уже отмечали в «Архитектуре цифрового мира», что многие организации, позиционирующие себя в качестве успешных участников процесса цифровой трансформации, сводят понятие продукта к его визуальному представлению. Однако в указанной логике продуктом финансовой организации, например, является не кредит, а форма заполнения заявки
на него. Но есть ли ценность для клиента от формы заявки на кредит? Безусловно, наличие такой формы, особенно в дистанционном канале обслуживания, гораздо лучше, нежели
ее отсутствие. Но потребности клиента при получении и обслуживании кредитного продукта
(мы специально подчеркиваем продуктовый характер деятельности современной финансовой
организации) не исчерпываются заполнением формы на его получение. Клиент заинтересован в прозрачном процессе анализа и одобрения его кредитной заявки, понятном начислении процентов, актуальном списании средств, актуальном графике платежей, учитывающем
все аспекты его деятельности, а также во многом другом. Без учета всех необходимых клиенту характеристик кредитного продукта не возникнет требуемой ценности. Есть и другие
участники процесса кредитования. Например, это собственно финансовая организация, предоставляющая кредиты. Она должна ставить выданный продукт на баланс, осуществлять его
эффективное сопровождение, включающее множество операций, например, контроль целевого использования кредитных средств, ведение и актуализация графика погашения задолженности, возникновение форс-мажорных обстоятельств, а также многое другое. И ценность для
организации, также являющейся участником предоставления продукта, заключается в эффективном проведении указанных операций. Существуют внешние участники процесса, например, кредитные бюро, которые осуществляют проверки клиентов и контрагентов. И для них
11

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ценность продукта формируется отдельным образом. Мы видим, что реальная ценность продукта исключительно комплексная. И, соответственно, комплексной должна быть его архитектура. Она не может сводиться исключительно к канальной логике, как в случае с подменой
продукта его визуальным представлением. Пример концептуальной архитектуры современного
продукта представлен на Рисунке 2.
На данном рисунке представлена именно концептуальная архитектура современного
продукта. Мы пока не рассматриваем примеры использования конкретных технологий реализации, специфические функциональные аспекты и т. д. К указанной детализации мы будем
неоднократно обращаться по ходу настоящей книги. Но на основании предыдущих рассуждений мы можем сформировать именно концептуальную архитектуру:
• Визуальное представление продукта никуда не пропадает. Мы лишь подчеркиваем
необходимость не ограничиваться им, не ставя под сомнение его значимость. Клиентский путь
(Client Journey) начинается именно с указанного визуального представления, поэтому и в концептуальной архитектуре оно незамедлительно занимает свое законное место. Естественно,
в современном мире множества каналов визуальное представление должно быть реализовано
с использованием необходимого объема канальной логики в формате фронтального и канального представления. Отметим, что визуальное представление продуктов может быть доступно
не только клиентам и/или партнерам, но и сотрудникам организации. Структура же конкретных представлений определяется ролевой моделью и конкретными требованиями, предъявляемыми к функциональности ролей в разрезе продукта (например, полномочиями пользователя, оператора, администратора дистанционных каналов обслуживания и т. д.).

12

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 2. Пример концептуальной архитектуры продукта

13

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Зачастую в каждом продукте присутствуют элементы логики, зависящие от канала коммуникации с клиентом или партнером. Например, логика расчета процентов по кредиту может
определяться в том числе видом канала заказа продукта (интернет-клиент, мобильный клиент,
отделение и т. д.). Такую логику мы именуем канало-специфичной и также включаем в концептуальную архитектуру продукта. Отметим, что принципиально данный архитектурный слой
продуктовой логики не является обязательным: продукт может не иметь зависимости от конкретного канала, например, условия кредита могут не зависеть от канала оформления кредитного продукта. Также он может быть совмещен с общей продуктовой логикой – канальные
условия могут учитываться в продуктовых бизнес-процессах. Но мы настаиваем на его выделении, поскольку в данном случае мы получаем возможность изменять логику, зависящую
от канала, независимо от общей продуктовой логики и тем самым сокращать потенциальные
объемы регрессионного тестирования при развитии продукта. Кроме того, данный подход позволяет бесшовно изменять количество каналов обслуживания, в которых доступен продукт,
что принципиально важно в условиях повсеместного распространения дистанционных каналов.
• В ходе работы с современным продуктом обрабатывается большое количество данных,
в результате чего при его проектировании должен определяться продукт данных, ассоциированный с конкретным продуктом организации. Мы рассматривали проблематику продукта
данных в предыдущих книгах, в настоящем изложении мы также уделим ей внимание в соответствующем разделе. Данные не являются статичными, они оказывают определяющее влияние на P&L продукта, принимаемые решения по развитию его жизненного цикла, а потому
должны иметь явно выраженную продуктовую направленность, входить в состав продукта,
соответственно, и в его архитектуру. Обратим внимание читателя на то, что поскольку современные архитектурные подходы определяют данные как продукт, то указанный продукт данных может иметь жизненный цикл, отличный от общего жизненного цикла продукта организации, в состав которого он входит. Корректная синхронизация жизненных циклов продукта
и продукта данных является ответственностью как продуктовой команды, так и архитектора.
• Исключительно важным компонентом продукта является непосредственно продуктовая логика, занимающая заслуженное центральное место в концептуальной архитектуре продукта. Здесь мы говорим о продуктовой логике, не зависящей от конкретного канала обслуживания, то есть не являющейся канало-специфичной. Продуктовая логика описывает весь
жизненный цикл продукта, а потому является краеугольным камнем влияния на P&L продукта, что и делает ее обязательным элементом архитектуры любого продукта. При этом
зачастую продуктовая логика носит сложный многогранный характер, а потому нуждается
в развитых механизмах управления, которые позволят наглядно описать бизнес-процессы,
ассоциированные с жизненным циклом продукта. Именно поэтому на Рисунке 2 мы указали
в составе концептуальной архитектуры продукта не только продуктовую логику, но и логику
управления процессами ее автоматизации. Отметим, что данный подход не может считаться
применимым для канало-специфичной логики, так как последняя является традиционно
легковесной и крайне требовательной к производительности, вследствие чего использование сложных инструментов управления бизнес-процессами может привести к неприемлемой
деградации производительности. Также подчеркнем, что продуктовая логика может предъявлять самые различные требования к масштабированию, производительности и надежности,
в том числе в части управления процессами, поэтому на уровне концептуальной архитектуры
продукта предусмотрена возможность как оркестровки, так и хореографии бизнес-процессов, связанных с продуктовой логикой. Одновременно с этим управление бизнес-процессами
может отсутствовать, в связи с чем на Рисунке 2 и сделана соответствующая оговорка.
• Мы уже отмечали ранее по ходу настоящей главы, что участниками процесса предоставления ценности могут быть на первый взгляд внешние по отношению к продукту эле14

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

менты. В качестве примера можно привести кредитный продукт и внешние по отношению
к финансовой организации банки кредитных историй. Но данные, собираемые в ходе взаимодействия с указанными внешними субъектами, являются исключительно важными с точки
зрения продуктовой логики. Поэтому для концептуальной архитектуры продукта также предусматривается отдельный уровень интеграции, который мы обозначаем архитектурно значимым, а потому и отражаем на Рисунке 2.
• Как было отмечено выше, в ходе исполнения жизненного цикла каждого продукта
обрабатываются колоссальные объемы данных, в связи с чем выделяется сущность «продукт
данных», а продуктовые данные и связанная с ними логика, реализующие данную сущность,
включаются в концептуальную архитектуру продукта. Вместе с тем нельзя не учитывать, что
хранение и обработка больших объемов данных требуют вложения серьезных трудовых, временных, инфраструктурных и в конечном итоге финансовых ресурсов. Работа в режиме оперативного доступа со всеми данными, ассоциированными с конкретным продуктом, может оказаться избыточным финансовым бременем для организации. Особенно если вспомнить, что
современная компания предоставляет своим клиентам и/или партнерам множество продуктов. Для эффективного ответа на указанный вызов следует предусматривать для продуктов
решения по архивному хранению данных. Архивное хранение не означает удаление данных.
Но подразумевает технологии работы с ними, допускающие определенную экономию, не оказывающую негативного влияния с точки зрения жизненного цикла продукта и его P&L. Вопрос
адекватного сопоставления уровней оперативного и архивного хранения данных должен быть
решен архитектором. Также отметим необязательность рассматриваемого уровня концептуальной архитектуры продукта – не для каждого продукта архивное хранение может оказаться
востребованным.
На данном этапе мы рассмотрели концептуальную архитектуру продукта, максимально
близкую к его бизнес-архитектуре. Именно поэтому мы не разделяли на Рисунке 2 уровни
архитектуры на составляющие. Мы лишь отметили условными обозначениями основные
задачи каждого уровня: обработка логики или работа с данными. Но при дальнейшей детализации архитектуры вопросы структуризации каждого уровня выходят на первый план. Остановимся на них подробнее.
Поскольку мы рассматриваем не конкретный продукт и абстрагируемся от частных архитектурных и технологических решений, то дальнейшие рассуждения касаются характеристик
автоматизации современных продуктов, ставших на сегодня стандартом де-факто. Примем для
определенности положение, что при разработке каждого уровня продуктовой автоматизации
используется парадигма микросервисной архитектуры. И для наглядности и удобочитаемости
разобьем соответствующее развитие концептуальной архитектуры продукта на две составляющие, схематично представленные на Рисунках 3 и 4.
На Рисунке 3 представлена детализация архитектуры условно фронтальных слоев продукта, отвечающих за его визуальное представление клиенту/партнеру и обработку связанной
с представлением продуктовой логики. Также на этом Рисунке представлен технологический
подход к продуктовой автоматизации соответствующего уровня.
Собственно канальная логика реализуется с использованием языков разработки, специфичных для конкретных каналов представления, что и отражено на Рисунке 3. При этом количество реализаций может варьироваться в зависимости от сложности канального представления конкретного продукта. Но исключительно канальной логикой рассматриваемый уровень
продуктовой автоматизации не исчерпывается. Мы уже отмечали ранее и в «Архитектуре цифрового мира», и в «Архитектуре цифровых платформ», что современные фронтальные решения должны следовать распределенной архитектуре, например, в формате микрофронтендов,
выводили соответствующую архитектурную тенденцию в качестве одной из основных связанных тенденций развития архитектуры. Если продолжить рассматривать архитектуру продукта
15

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

сквозь призму данной тенденции, то на уровне канального представления необходимо определить компоненты, отвечающие за прием и базовую обработку запросов от компонентов фронтального слоя (микрофронтендов), которые мы на Рисунке 3 определяем микросервисами
фронтальной логики. Также нельзя забывать, что кроме обработки клиентских запросов каждый продукт может предоставлять API для разработки партнерских приложений на основе
решений организации, создающей и развивающей продукт. Предоставление API в нашем примере осуществляется также в микросервисной парадигме и обозначается на Рисунке 3 микросервисами предоставления API. Отметим, что микросервисы могут в общем случае реализовываться с использованием любого языка разработки, мы в настоящем примере ограничиваем
перечень лишь языками программирования высокого уровня.
Но не только наличие распределенных компонентов фронтальной логики характеризует
архитектуру фронтального и канального представления современного продукта. Актуальные
на сегодня требования к поставляемым на рынок продуктам заключаются в том числе в исключительно высокой нагрузочной способности – продукт должен обеспечивать корректную обработку громадного количества запросов, поступающих по дистанционным каналам обслуживания. И это также отражено на Рисунке 3.
Как правило, обеспечение быстрого доступа к данным, обрабатываемым на уровне фронтального представления продукта, осуществляется с использованием механизма кэширования
информации, например в оперативной памяти. Именно с этой целью на Рисунке 3 размещен
компонент кэширования, содержащий данные фронтального представления. Одновременно
с этим необходимо обеспечивать наполнение кэш актуальными данными / переносить новые
данные из кэширующих компонентов в долговременные хранилища на смежных уровнях автоматизации. Для решения подобной задачи нередко используются технологии поддержки событийного обмена с целью обеспечения минимальной взаимозависимости между компонентами,
составляющими продукт. На Рисунке 3 рассматриваемая задача решается журналами «прогрева» кэш, реализуемыми с использованием событийных механизмов.

16

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 3. Архитектура продукта (часть 1)
17

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Канало-специфичная продуктовая логика, необходимость выноса которой на уровне концептуальной архитектуры продукта мы отмечали ранее, реализуется, как правило, с использованием языков программирования высокого уровня. При этом, учитывая микросервисную
архитектурную парадигму, рассматриваемую нами в контексте продуктовой автоматизации,
конкретный язык реализации может отличаться как от ранее рассмотренных компонентов, так
и между непосредственно различными компонентами канало-специфичной логики. В соответствии же с лучшими архитектурными практиками, рассмотренными в предыдущих книгах,
информационный обмен между компонентами как данного слоя продуктовой автоматизации,
так и с компонентами иных слоев, мы в настоящем примере полагаем основанным на событийном обмене. Необходимо подчеркнуть, что событийное взаимодействие компонентов продуктовой логики может принципиально отличаться от событийного прогрева кэш: событие
не является отложенной командой на исполнение, а представляет изменение состояния ИТрешения. Изменения же состояния принципиально отличаются в различных вариантах использования.
Непосредственное хранение продуктовых данных может осуществляться как в долговременном, так и в «быстром» хранилище, предполагающем высокоскоростную обработку информации и ее предоставление, но при этом не являющемся долговременным в классическом
понимании этого слова. Поэтому для соответствующего уровня продуктовой автоматизации
на Рисунке 3 в качестве примера указано надежное долговременное хранилище информации, реализованное методами СУБД, а также высокоскоростное хранилище с использованием
кэширующих механизмов. Приведенные в примере хранилища должны синхронизироваться
между собой, а также с иными уровнями автоматизации, предоставляя им данные, а также
потребляя их. На Рисунке 3 указанные операции реализуются при помощи решений событийного обмена. Еще раз отметим, что при концептуальной схожести решений, используемых
на разных уровнях продуктовой автоматизации, их техническая реализация может оказаться
принципиально различной ввиду отличий в вариантах использования. Например, на фронтальном уровне от кэширующих решений, как правило, требуется хранение данных в режиме
оперативного доступа, при проведении же продуктовых операций зачастую более насущным
является асинхронное выполнение долговременных операций в оперативной памяти. Подобные разительные отличия предъявляют и принципиально различные требования к архитектуре
соответствующих решений.
Вторая часть примера детализации архитектуры продукта схематично представлена
на Рисунке 4.

18

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

19

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 4. Архитектура продукта (часть 2)
Как было отмечено по ходу настоящей главы, при рассмотрении примера концептуальной архитектуры продукта и ее последующей детализации мы полагаем, что используется
микросервисная архитектура. Как было показано в предыдущих книгах, прикладная логика
автоматизации жизненного цикла продукта (продуктовая логика) в таком случае реализуется
не только в формате микросервисов, отвечающих за исполнение конкретных бизнес-действий,
входящих в ее состав, но и процессных компонентов, отвечающих непосредственно за управление бизнес-процессами, ассоциированными с конкретным продуктом. Процессные компоненты реализуются в виде микросервисов, содержащих либо логику взаимодействия с BPMдвижком, либо собственно встроенный BPM-движок.
Рассмотрение вопросов организации бизнес-процессов в современной архитектуре представлено в книге «Архитектура цифрового мира», их место в платформенной архитектуре –
в книге «Архитектура цифровых платформ. От настоящего к будущему». Место бизнес-процессов в продуктовой архитектуре будет рассмотрено в соответствующем разделе настоящей
книги. В рамках же текущей главы отметим, что сложная продуктовая логика априори предполагает и развитый функционал процессного управления, допускающий в ходе реализации
применение шаблонов как оркестровки, так и хореографии, для чего необходим развитый движок управления бизнес-процессами – BPM-движок. Использование указанного инструмента
позволяет в том числе оперативно вносить изменения в продуктовые бизнес-процессы, минимизируя непосредственное «кодирование» с привлечением высокооплачиваемых разработчиков, что положительно сказывается на P&L продукта.
При этом оперативные данные прикладной логики нуждаются в долговременном хранении. Это касается как контекста процесса (бизнес-данных, ассоциированных с конкретным
экземпляром процесса), так и управляющих данных, характеризующих экземпляр процесса
в контексте BPM-движка. По умолчанию для решения указанной задачи, как правило, используется СУБД, что и представлено на Рисунке 4. Но нельзя не отметить, что для высокой оперативности доступа к данным нередко применяются кэширующие элементы, не представленные на Рисунке 4 для сохранения удобочитаемости. Контекст процесса и управляющие данные
обычно разделяются в ходе хранения.
Для обеспечения эффективного сохранения данных процессов, взаимодействия экземпляров процессов и их составляющих нередко используются событийные механизмы, что
также представлено на Рисунке 4 в составе продуктовой логики. Примером использования
событийных механизмов может служить поддержка реализации шаблона хореографии, когда
взаимодействие составляющих процесса осуществляется путем генерации событий, характеризующих изменение состояния продукта по итогам исполнения упомянутых составляющих.
Мы уже отмечали по ходу настоящей главы, что участниками создания ценности могут
быть и внешние по отношению к продукту элементы. Например, в кредитном продукте,
предоставляемом финансовой организацией, немаловажную роль играет информация, получаемая о клиенте, созаемщиках, поручителях из внешних банков кредитных историй. Данная
информация получается в рамках интеграционного взаимодействия продуктового решения
с внешними информационными системами, зачастую находящимися за пределами организации, создающей и развивающей конкретный продукт. В такой ситуации и организация в целом,
и конкретная продуктовая команда не могут влиять на уровень предоставления внешнего
сервиса. Безусловно, существуют контракты на обслуживание, но ценность, предоставляемая
клиентам и партнерам, не опирается на контракты, заключаемые организацией, пусть они
и однозначно влияют на P&L. В эпоху дистанционных каналов обслуживания любая задержка
в получении данных и предоставлении на их основании информации клиенту может оказаться
фатальной с точки зрения конкурентоспособности всей организации. Поэтому при детали20

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

зации слоя интеграции необходимо указать в контексте архитектуры не только интеграционную логику, ответственную за получение данных из внешних источников и отправку в них
требуемой информации, но и механизмы, обеспечивающие производительность и надежность
детализируемого слоя. В нашем примере, схематично показанном на Рисунке 4, в качестве
указанного механизма используется кэширование. При этом для наполнения кэш и обеспечения максимально слабой связности продукта с внешними решениями используется механизм
событийного обмена. Подчеркнем, что мы рассматриваем здесь случай внешнего по отношению к организации интеграционного взаимодействия, но приведенные рассуждения справедливы и для интеграций внутренних, когда взаимодействие, например, может осуществляться
между несколькими продуктовыми решениями. Принципиальное отличие будет в таком случае заключаться лишь в большей степени влияния на уровень доступности взаимодействующих решений.
И по ходу предшествующих книг, и в рамках настоящей мы отмечали необходимость
архивного хранения данных, ассоциированных с продуктом: ввиду огромных массивов накапливаемой на сегодня информации обеспечение оперативного доступа ко всем продуктовым
данным зачастую становится исключительно дорогостоящим. Механизмы архивного хранения
требуют иных архитектурных и технологических решений для своего обеспечения, нежели
хранение оперативное. Например, использование распределенной файловой системы, как
показано на Рисунке 4.
И вот здесь мы вновь должны вернуться к тому, что основой архитектуры продукта
является его ценность. Вышеприведенное описание концептуальной архитектуры продукта
с ее минимальной детализацией показывает, что все рассмотренные архитектурные слои, их
наличие и требования к функциям определяются перспективной ценностью создаваемого или
развиваемого продукта. В случае, если ценность продукта требует тех или иных характеристик продуктового ИТ-решения, они должны поддерживаться архитектурой. Также архитектура должна предусматривать потенциальное развитие продукта, обеспечивать дополнение его
структуры, что в свою очередь позволит предоставлять потребителям ценность, адекватную
требованиям рынка. Если же при изменениях рыночных требований архитектура продукта
не позволит обеспечить его адекватное развитие, то это будет однозначно указывать на принципиальный недостаток архитектуры. То есть, принимая тот факт, что ценность продукта является комплексной (вновь и вновь обращаем внимание читателя на то, что, например, визуальное представление продукта не несет ценности само по себе), мы делаем однозначный вывод,
что и архитектура продукта также должна быть комплексной, предоставлять адекватное обеспечение всех продуктовых составляющих и всех вариантов использования, характерных для
продукта. Что же означает данный вывод с точки зрения применения современных архитектурных подходов?
По ходу изложения, представленного в книге «Архитектура цифровых платформ.
От настоящего к будущему», мы описывали различия между архитектурным подходом времен
SOA, подходом «множества платформ» и современной платформенной автоматизацией. Рассмотрим приведенный выше пример архитектуры продукта в приложении к трем указанным
подходам. И начнем с «седой старины» – сервис-ориентированной архитектуры, SOA. Иллюстративно данный подход отображен на Рисунке 5, при этом за основу взят немного измененный Рисунок 2 из книги «Архитектура цифровых платформ. От настоящего к будущему».
Для наглядности предположим, что автоматизация продукта осуществляется при
помощи четырех автоматизированных систем (возможно, каждая из них реализована в микросервисной парадигме), при этом интеграция между ними осуществляется посредством корпоративной сервисной шины (ESB), в соответствии с практиками SOA. В этом случае каждая
21

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

Рисунок 5. Продуктовая автоматизация при использовании концепции SOA
На основании детализации концептуальной архитектуры продукта, схематически приведенной на Рисунках 3 и 4, мы можем отметить, что технологические задачи, решаемые системами 1—4, во многом схожи между собой и связаны друг с другом, например, для каждой
системы необходимо решать вопросы хранения данных, масштабирования указанного хранения, проблематику высокопроизводительных вычислений и т. д. При этом если следовать парадигме SOA, то все системы могут быть реализованы с использованием собственного технологического базиса, решать схожие задачи различным образом, что существенно усложняет как
внесение значимых изменений в продукт, затрагивающих несколько архитектурных уровней
автоматизации, так и организацию поддержки развития продукта. Рассмотрим указанные проблемы более подробно.
Мы уже неоднократно отмечали, что ценность продукта является комплексной, а потому
запросы заинтересованных лиц, связанные с изменениями, например рыночной конъюнктуры,
приводят к столь же комплексным изменениям продуктовой автоматизации: новые требования к автоматизации могут затрагивать и фронтальное представление продукта, и структуру
22

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

автоматизируемой продуктовой логики, например, добавляя новые процессы в структуру жизненного цикла продукта, и требовать дополнения продукта новыми внешними данными. Хранение продуктовых данных также в таком случае может требовать обновления. Если каждая
из отвечающих за продуктовую автоматизацию информационных систем реализована в собственной архитектурной и технологической парадигме, то и развивает каждую из систем своя
команда, состоящая из различных специалистов с самыми разными компетенциями. В таком
случае каждое значимое изменение, вносимое в продукт, будет требовать синхронизации деятельности упомянутых команд развития, что является далеко не самым простым процессом,
требующим серьезных затрат временных, трудовых и финансовых ресурсов. Очевидно, что
в этом случае говорить о лучших рыночных значениях показателя time-to-market не приходится. И P&L продукта в таком случае претерпевает самое драматическое изменение.
Вопросы поддержки также не уходят на второй план в продуктовом развитии. В рассматриваемом нами примере следует особо обратить внимание на третью линию поддержки.
Если первая и вторая линии поддержки, предполагающие прием пользовательских запросов,
настройку и администрирование продуктовых решений, еще могут быть централизованы, то
третья линия поддержки, в задачи которой входит доработка продукта, для каждой из систем
окажется сугубо специфичной. Она не может быть централизована вследствие указанного
выше многообразия архитектурных и технологических решений, что приводит к избыточным
затратам организации и негативно влияет на P&L продуктов, предоставляемых ею клиентам
и партнерам.
Также следует помнить, что современные организации, как правило, предоставляют
своим клиентам и партнерам множество продуктов, при этом характеристики каждого из продуктов могут быть самыми разными. И при архитектуре продуктовой автоматизации, представленной на Рисунке 5, каждая из информационных систем решает свое подмножество задач
в контексте каждого продукта. При подобной постановке вопроса любое значимое изменение
нуждается в тщательном и длительном процессе анализа, что исключает оперативную реакцию компании и лишь приводит к нарастанию энтропии в ее ИТ-ландшафте. Каждый элемент автоматизации становится специфичным и одновременно с этим несамостоятельным (что
в принципе характерно для сервисов в концепции SOA). И мы можем сделать закономерный
вывод о том, что создание современных продуктов в принципах SOA попросту невозможно.
Мы делаем здесь упор на слове «современных», поскольку предыдущие годы автоматизации
были весьма успешными для значительного количества компаний. Но современные условия
диктуют и новые архитектурные подходы. Условия триасового периода, плейстоцена и голоцена предъявляли самые различные требования к живым существам, а потому и доминантный
вид каждого из периодов был различным.
В книге «Архитектура цифровых платформ. От настоящего к будущему» мы также
описывали подход к автоматизации, который характеризовали как «множество платформ».
Данный подход характеризуется тем, что применяющие его организации создают отдельные
программные платформы для того или иного уровня автоматизации. Иногда платформы выделяют по архитектурным уровням, иногда по бизнес-задачам. Так и появляются «омниканальные платформы», «учетные платформы», «платформы CRM», зачастую слабо связанные друг
с другом. Рассмотрим применение данного подхода к автоматизации продукта и его концептуальной архитектуре, описанным выше. Схематично оно приведено на Рисунках 6 и 7. Мы вновь
разделяем детализацию концептуальной архитектуры продукта на две иллюстрации, чтобы
обеспечить наглядность последних.
За основу рассмотрения примера мы берем уже ранее приведенную детализацию концептуальной архитектуры, схематично представленную на Рисунках 3 и 4, при этом дополняем
пример использованием набора платформ, созданных организацией, развивающей продукт.
Конкретный набор платформ приведен в качестве примера – различные организации могут
23

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

24

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

25

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 6. Архитектура продукта при «множестве платформ» (часть 1)

26

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

27

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 7. Архитектура продукта при «множестве платформ» (часть 2)
Омниканальная платформа используется для обеспечения применения платформенного
подхода при реализации логики представления, продуктовая платформа – для реализации
непосредственно продуктовой и процессной логики, учетная платформа гарантирует применение платформенного подхода при хранении данных, интеграционная отвечает за наполнение продуктового ИТ-решения данными из внешних источников, а также за передачу данных во внешние информационные системы и продуктовые решения. Мы сознательно вводим
в нашем примере наименование «продуктовой» платформы, а не «процессной», чтобы показать недостатки подхода «множества платформ» – для продуктовой автоматизации оказывается недостаточно собственно «продуктовой» платформы, требуются еще три: омниканальная,
интеграционная и учетная.
Таким образом, для поддержки автоматизации канальной и канало-специфичной логики
применяется омниканальная платформа, для поддержки автоматизации продуктовой логики,
управления оркестровкой и хореографией – продуктовая, оперативного и архивного хранения
продуктовых данных – учетная, наполнения внешними данными – интеграционная.
Отметим тот факт, что платформы используются не сами по себе. Продуктовые команды
используют платформенные сервисы в своей непосредственной деятельности. Основываясь
на платформенных принципах, подробно раскрытых в предыдущей книге, обсудим, какие сервисы могут использоваться в рассматриваемом примере.
Как уже указывалось выше, омниканальная платформа используется для автоматизации
канало-специфичной и канальной логики. Как представлено на Рисунке 6, в состав данного
архитектурного уровня входят микросервисы, отвечающие за непосредственную реализацию
логики, микросервисы предоставления API (например, для партнерской экосистемы), компоненты кэширования, обеспечивающие высокое быстродействие фронтального представления
продукта, журнальные компоненты событийного обмена, отвечающие за прогрев кэш и взаимодействие компонентов и микросервисов в парадигме событийно-ориентированной архитектуры EDA. Как правило, использование кэширующих компонентов нередко предполагает
наличие и долговременного хранилища информации, поэтому при дальнейшей детализации
архитектуры в составе рассматриваемого архитектурного слоя будут присутствовать соответствующие компоненты, например, в виде реляционных баз данных, что также предъявляет
требования по их поддержке со стороны используемой платформы – в нашем случае омниканальной. Основываясь на приведенном описании, мы можем составить примерный список
платформенных сервисов, используемых при автоматизации канальной и канало-специфичной
логики:
• Сервис управления открытыми API.
• Интеграционный сервис, который реализуется сервисом взаимодействия с потоковым
программным обеспечением в журнальном исполнении (концепция реализации платформенных сервисов и компонентов подробно рассмотрена в книге «Архитектура цифровых платформ. От настоящего к будущему»).
• Сервис хранения информации, для которого используются две реализации: реализация
хранения в кэш и в реляционных СУБД.
Необходимо подчеркнуть, что в рамках настоящего архитектурного примера мы рассматриваем общее представление платформенных сервисов без избыточной детализации. В реальных примерах могут присутствовать и реляционные, и нереляционные СУБД, различные реализации кратковременного хранения информации и т. д. Также для упрощения примера мы
28

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

не рассматриваем такие служебные и вспомогательные задачи, как аутентификация, авторизация, управление секретами, логирование, трассировка и т. д.
Учетная платформа (см. Рисунки 6 и 7) отвечает за поддержку выполнения задач хранения продуктовых данных, а также архивного хранения. При этом присутствует надежное
долговременное хранение данных в реляционной СУБД, хранение в режиме быстрого доступа
с использованием кэширующих элементов, а для архивного хранения еще и использование элементов дешевого хранения в виде распределенной файловой системы, как показано на Рисунке
7. Кроме того, для обеспечения интеграционных взаимодействий и прогрева кэш используются журнальные компоненты, допускающие функционирование в соответствии с принципами событийно-ориентированной архитектуры. По аналогии с омниканальной платформой
мы можем составить список платформенных сервисов, предоставляемых учетной платформой
своим потребителям:
• Сервис хранения информации, для которого используются три реализации: реализация
хранения в кэш, в реляционных СУБД и в распределенной файловой системе.
• Интеграционный сервис, который реализуется сервисом взаимодействия с потоковым
программным обеспечением в журнальном исполнении.
Интеграционная платформа отвечает за наполнение продуктового ИТ-решения данными, мастер-системы для которых находятся вне контура автоматизации продукта, возможно,
вне контура организации, рассматриваемый продукт создающей и развивающей. Для реализации указанной задачи интеграционная платформа должна обеспечивать собственно взаимодействие с упомянутыми мастер-системами. В представленном примере для этого используются журнальные компоненты, обеспечивающие событийное взаимодействие. Получаемые
данные для оперативности помещаются в хранилище быстрого доступа, реализуемое с использованием кэширующих компонентов. Для обеспечения надежности последних могут применяться компоненты долговременного хранения информации (на Рисунке 7 не показаны с целью
не загромождать иллюстрацию). В целях разнообразия предположим, что для долговременного
хранения передаваемой информации используется нереляционная СУБД. В связи с вышеизложенным интеграционная платформа предоставляет своим потребителям набор платформенных сервисов, состоящий из:
• Сервис хранения информации, для которого используются две реализации: реализация
хранения в кэш и в нереляционных СУБД.
• Интеграционный сервис, который реализуется сервисом взаимодействия с потоковым
программным обеспечением в журнальном исполнении.
Продуктовая платформа отвечает за управление бизнес-процессами жизненного цикла
продукта. В связи с этим она обеспечивает оркестровку и/или хореографию составляющих
процесса, их событийное взаимодействие как между собой, так и со связанными компонентами исполнения продуктовой логики. Также необходимо решение комплекса задач по хранению данных как контекста процесса, так и собственно управленческих данных бизнес-процессов. Для наглядности предположим, что для хранения используется реляционная СУБД.
Таким образом, продуктовая платформа предоставляет потребителям следующий набор платформенных сервисов:
• Сервис хранения информации, для которого используется реализация хранения в реляционной СУБД.
29

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Интеграционный сервис, который реализуется сервисом взаимодействия с потоковым
программным обеспечением в журнальном исполнении.
• Сервис управления бизнес-процессами, для которого представлены две реализации:
оркестровка и хореография.
Приведенный объемный пример убедительно свидетельствует: на разных уровнях продуктовой автоматизации используются схожие по применимости платформенные сервисы.
Но в случае подхода «множества платформ» они предоставляются разными платформами.
Соответственно, их способ реализации и варианты использования могут принципиально отличаться. Но в таком случае члены продуктовой команды должны владеть методиками использования каждой платформы, понимать различия, например, сервисов хранения данных в реляционных СУБД на уровне каждой из набора платформ. И внесение значимого изменения
в продукт оказывается не менее, а зачастую и более сложным, нежели в парадигме SOA.
Поэтому говорить о применимости подхода «множества платформ» в современной продуктовой автоматизации принципиально неверно.
Действительно, в случае значимого изменения, вносимого в продукт, продуктовые
команды сталкиваются с необходимостью вносить изменения в использование платформенных сервисов, предоставляемых четырьмя платформами. Предположим, что следствием требуемого изменения становится вопрос развития продукта с точки зрения значимого повышения производительности. Подобное повышение может оказаться связанным с использованием
кэширующих компонентов. Реализации платформенных сервисов, использующие кэширующие компоненты, предоставляются тремя платформами: омниканальной, интеграционной
и учетной. Соответствующие сервисы могут быть реализованы каждой платформой с использованием различных технологических решений (например, Apache Ignite, Infinispan, Redis,
Hazelcast и т. д.), для них могут применяться различные топологии развертывания, потребителям могут быть доступны отличные друг от друга и жестко специфицированные конкретной
платформой варианты использования. Таким образом, существенное изменение в продукте,
связанное с повышением производительности, потребует погружения продуктовой команды
в три принципиально различные реализации сервиса хранения информации в кэш. Аналогичная ситуация будет наблюдаться в случаях хранения информации в реляционных базах данных, использования событийного взаимодействия и т. д. Продуктовые команды будут тратить
временные, трудовые и финансовые ресурсы на корректный выбор конкретного платформенного сервиса, а не на реализацию собственно продуктовой логики, что крайне негативно скажется на P&L продукта.
Именно поэтому, как и отмечалось ранее, проблематика современных продуктов, их
планирования, проектирования, создания и развития рассматривается в настоящей книге
в контексте современного платформенного подхода, которому посвящена книга «Архитектура
цифровых платформ. От настоящего к будущему». Рассмотрим применение указанного современного платформенного подхода в нашем примере архитектурной детализации продукта.
С этой целью возьмем за основу перечень платформенных сервисов, представленный для подхода «множества платформ», и составим на его основе сводный перечень платформенных сервисов единой, современной, цифровой платформы, в случае если именно к использованию
последней придет организация, создающая и развивающая продукт. На Рисунке 8 схематично
представлен набор платформенных сервисов, который используется платформенным приложением, реализующим продукт из рассматриваемого нами примера.
Уточним еще раз: продукт реализуется платформенным приложением, использующим
платформенные сервисы. При этом платформа предоставляет сервисы с набором топологий,
применимых для различных вариантов использования в соответствии с задачами конкретных архитектурных слоев, представленных ранее по ходу изложения для рассматриваемого
30

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

31

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Учитывая приведенную ранее детализацию архитектуры продукта, мы можем сформулировать использование платформенных сервисов платформенным приложением, реализующим
продукт (см. Рисунок 8):
• Продукт использует сервис работы с данными (Сервис 1 на Рисунке 8), содержащий
четыре реализации:
○ Сервис работы с реляционными данными (1.1). В качестве основы технологической
реализации сервис использует СУБД PostgreSQL.
○ Сервис работы с нереляционными данными (1.2). В качестве основы технологической
реализации сервис использует СУБД Apache Cassandra.
○ Сервис работы с распределенной файловой системой (1.3). В качестве основы технологической реализации сервис использует программное обеспечение Apache Hadoop.
○ Сервис работы с кэш (1.4). В качестве основы технологической реализации сервис
использует программное обеспечение Apache Ignite.
• Продукт использует сервис потоковой передачи данных (Сервис 2 на Рисунке 8), содержащий две реализации (количество реализаций сознательно увеличено для демонстрации гибкости платформенного подхода):
○ Сервис потоковой передачи информации в журнальной парадигме (2.1). В качестве
основы технологической реализации сервис использует программное обеспечение Apache
Kafka.
○ Сервис потоковой передачи информации (2.2). В качестве основы технологической
реализации сервис использует программное обеспечение Apache Pulsar.
○ Продукт использует сервис управления открытыми API (Сервис 3 на Рисунке 8). Предположим, что сервис содержит единственную реализацию на основе программного обеспечения WSO2.
• Продукт использует сервис управления бизнес-процессами (Сервис 4 на Рисунке 8),
содержащий две реализации (при этом обе реализации основаны на идентичном программном
обеспечении BPM Camunda):
○ Сервис оркестровки бизнес-процессов (4.1).
○ Сервис хореографии бизнес-процессов (4.2).
При этом сервис потоковой передачи данных использует (неявно для продуктового решения) сервис работы с данными для своего функционирования.
Конкретные технологические решения и их сочетания приведены исключительно для
примера, одновременно с этим взаимосвязи сервисов и используемого при их реализации программного обеспечения показывают, что принципиально платформенная парадигма не ограничивает ни количество самих сервисов, ни число их технических реализаций. Особо подчеркнем, что каждая реализация может содержать произвольное количество топологий и вариантов
использования.
Далее рассмотрим исключительно важный вопрос: каким же образом продукт может
использовать платформенные сервисы в своей архитектуре? Схематично логика этого использования представлена на Рисунках 9 и 10, которые иллюстрируют развитие реализации продукта от подхода «множества платформ» к применению современной цифровой платформы.
Нумерация используемых платформенных сервисов соответствует Рисунку 8.

32

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

33

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 9. Использование платформенных сервисов
в архитектуре продукта (часть 1)

34

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

35

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 10. Использование платформенных сервисов
в архитектуре продукта (часть 2)
На уровне фронтального и канального представления используются платформенные сервисы хранения данных в реляционной СУБД (1.1) и кэш (1.4), журнальной передачи информации (2.1) и управления открытыми API (3). При хранении продуктовых данных используются
платформенные сервисы хранения данных в реляционной СУБД (1.1) и кэш (1.4) и журнальной передачи информации (2.1) (см. Рисунок 9).
На уровне продуктовой логики используются платформенные сервисы хранения данных
в реляционной СУБД (1.1), журнальной передачи информации (2.1), управления бизнес-процессами в парадигме оркестровки (4.1) и хореографии (4.2). На уровне интеграции и наполнения данными используются платформенные сервисы хранения данных в нереляционной СУБД
(1.2) и кэш (1.4), журнальной передачи информации (2.1). На уровне архивного хранения
используется платформенный сервис хранения данных в распределенной файловой системе
(1.3) (см. Рисунок 10).
Подчеркнем, что перечислено использование сервисов единой платформы, а не схожих
по названию сервисов разных платформ из множества, как было в предыдущем примере. Это
является принципиальным отличительным свойством: продуктовая команда владеет экспертными знаниями в одной платформе, в одном множестве платформенных сервисов и их реализаций, грамотно выбирает те, которые наилучшим образом удовлетворяют требованиям,
предъявляемым к конкретному продукту. Указанный подход приводит к технологической
и топологической унификации продуктовых решений, снижает трудозатраты на их создание,
развитие и сопровождение, положительно сказывается на P&L, качестве продукта, его адаптируемости к постоянно меняющимся рыночным условиям.
Разумеется, каждый продукт нуждается в адаптируемости: требования рынка меняются
постоянно, при этом P&L продукта зависит от способности реагировать на вновь возникающие вызовы. Проекция каждого вызова на тот или иной архитектурный уровень будет различной. Поэтому не только сам продукт, но и платформенные сервисы должны обеспечивать необходимую гибкость – не может сервис кэширования единственным образом функционировать
для задач канального отображения продукта и его интеграционных зависимостей. Платформенный сервис должен содержать набор топологий и вариантов использования, позволяющих
адекватно применять его на всех уровнях продуктовой автоматизации. Выбор же конкретных условий использования сервиса осуществляет продуктовая команда, владеющая необходимыми компетенциями в части платформы.
Подводя промежуточный итог рассмотрения вопросов применения платформенного подхода для продуктовой автоматизации, можем отметить, что последняя невозможна на сегодняшний день без полноценного применения платформенного подхода, без использования
современной цифровой платформы. Даже проведя очень предварительную детализацию архитектуры продукта (именно поэтому настоящая глава называется «Общий подход к архитектуре…»), мы видим широкие возможности применения платформ в продуктовой автоматизации, а также потенциальные преимущества указанного подхода. Детально вопросы взаимного
влияния платформ и продуктов будут рассмотрены в соответствующей главе.
Хочется надеяться, что читатель получил исчерпывающее обоснование нашего возражения на его восклицание, озвученное в начале настоящей главы. Вопросы архитектуры современного продукта только ею не исчерпываются, они будут рассматриваться и далее в книге.
Но сейчас, изучив базовые аспекты архитектуры продукта, читатель готов задать новый вопрос:
«Так что, неужели необходимо осуществить реализацию всех уровней архитектуры продукта,
чтобы начать предоставлять ценность клиентам и партнерам, ведь это так дорого и долго?»
36

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Мы поспешим успокоить читателя. Мы не для того обсуждаем необходимость предоставления самостоятельной ценности клиентам в качестве обязательной характеристики продукта,
не для того говорим о гибких методах разработки, не для того подчеркиваем необходимость
трансформации мышления организации, предоставляющей продукт, чтобы в завершение предложить годами ожидать создание этой самой ценности. Разумеется, в запущенной ситуации,
например, если организация длительное время вкладывалась исключительно в «лоскутную»
автоматизацию, временные и финансовые ресурсы, требуемые для осуществления истинной
цифровой трансформации, могут оказаться значительными. К сожалению, так происходит всегда: как заноза, вовремя не извлеченная, может привести к необходимости сложной операции
и долговременного восстановления, так и пренебрежение тенденциями развития цифрового
мира требует серьезных инвестиций в преодоление закономерно возникающего отставания
от лидеров. Но при этом необходимо принимать во внимание и тот факт, что вновь создаваемые решения, предполагающие продуктовую направленность, должны учитывать рыночные
тенденции, изменение клиентских потребностей, сами формировать лучший пользовательский
опыт и т. д. И для этого необходимо обеспечивать скорейший вывод продуктов на рынок,
лучшие показатели time-to-market, что зачастую противоречит полноценной готовности всех
архитектурных слоев, разбиравшихся для абстрактного продукта по ходу настоящей главы.
Как же совместить скорейший вывод продукта на рынок и его качественную проработку,
учитывающую необходимость корректной архитектуры? Ответ на этот вопрос уже содержится
в методиках гибких практик и их адаптациях к применению в крупных компаниях. Продуктовые команды должны создавать MVP (minimum viable product, минимально жизнеспособные версии продуктов), позволяющие оценить реакцию рынка на продукт, скорректировать
его в соответствии с пользовательскими предпочтениями и рыночными тенденциями. Но здесь
важно не забывать о том, что MVP непременно должен быть верифицируемым. Например, если
MVP запускается на некой выделенной группе пользователей, то результат его отработки должен быть применимым и для рынка в целом, не может считаться удовлетворительной ограниченная группа, которая выбрана таким образом, что не отражает последующее рыночное применение полноценной версии продукта. Но, кроме этого, верификация должна осуществляться
и в части технической готовности: если MVP показывает себя удачно, но для полноценного
запуска необходимо пересмотреть всю архитектуру продукта, с нуля вести его разработку, то
такой MVP не может считаться верифицируемым: он не несет ценности для клиентов, а лишь
потребляет значимые временные, трудовые и в конечном итоге финансовые ресурсы организации. Как же определить верифицируемость MVP?
С точки зрения рыночной верификации продукта основной вопрос должен задаваться
владельцам продукта, ведь именно они отвечают за P&L. В архитектурном и технологическом плане решение должен принимать архитектор, который, разумеется, с привлечением всей
продуктовой команды, создает как целевую архитектуру продукта, так и набор промежуточных, основываясь на унаследованном ИТ-ландшафте организации, жизненном цикле продукта,
бизнес-показателях и требованиях всех заинтересованных лиц. Например, основой для определения промежуточных архитектур продукта может стать унаследованный ИТ-ландшафт.
Продукты организации могли автоматизироваться в парадигме классической сервис-ориентированной архитектуры. Да, мы понимаем, что такие продукты не могут считаться современными, тем не менее организация функционирует не в чистом поле и вынуждена считаться с тем
базисом автоматизации, который наличествует в ней. В этом случае архитектор может принять
решение о необходимости поэтапной реализации продукта по архитектурным слоям. Схематично данный подход представлен на Рисунке 11.
На этом рисунке одновременно сосуществуют классическая автоматизация в парадигме
SOA и современная продуктовая автоматизация. При этом формирование продукта осуществляется итеративно, учитывая потребности рынка, требования клиентов и заказчиков.
37

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 11. Поэтапная реализация продукта
Для обеспечения эффективного сосуществования классической и продуктовой автоматизации вводится слой экранирования, использующий интеграционные методологические
и технологические решения. Элементы продуктовой автоматизации, реализованные в разных
парадигмах, взаимодействуют между собой посредством указанного слоя. Перспективная автоматизация создается по слоям (с возможными техническими упрощениями на промежуточных
этапах реализации), количество которых варьируется в зависимости от требований к продукту.
По мере реализации новых архитектурных слоев соответствующие компоненты автоматизации
в классической SOA-архитектуре исключаются. Исключение может быть как окончательным,
так и частичным, в масштабах конкретного продукта. В дальнейшем, в главе, посвященной
гибким практикам продуктовой разработки, мы остановимся на данном круге вопросов более
подробно. Отметим, что использование платформенных сервисов также определяется характеристиками переходных архитектур и может наращиваться итеративно.
На этом мы завершаем вводную часть детализации архитектуры современных и устремленных в будущее цифровых продуктов. В следующей главе мы рассмотрим ключевые тенденции развития архитектуры в контексте продуктовой автоматизации.

38

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровые продукты и ключевые
тренды развития архитектуры
Ключевые тренды развития архитектуры
в концепции цифровых продуктов
«Опять эти ключевые тенденции развития архитектуры, да сколько можно уже?» – воскликнет читатель, ознакомившийся с двумя нашими предыдущими книгами. Казалось бы, мы
в обоих предшествующих трудах столь подробно рассматривали ключевые тенденции развития
архитектуры, обосновывали их выбор, разбирали каждую тенденцию, что вновь возвращаться
к ним кажется избыточным. Тем не менее это необходимо сделать. В «Архитектуре цифрового мира» мы рассмотрели основные современные тренды развития архитектуры в целом,
в «Архитектуре цифровых платформ» говорили о них в контексте платформенного подхода.
Теперь же мы говорим о подходе продуктовом, об архитектуре современного продукта, предполагающей интенсивное развитие последнего. И возвращаемся мы к архитектурным трендам
уже в контексте именно продуктового подхода, говорим об архитектуре продукта, о том, каким
образом она должна учитывать специфику рассматриваемых трендов. Поэтому мы, отвечая
на реплику читателя, утверждаем, что соответствующее рассмотрение необходимо.
Напомним основные тренды развития архитектуры:
• Открытый код.
• Распределенность.
• Бизнес-процессы.
• Данные.
• Искусственный интеллект.
Каждой из указанных тенденций будет посвящен отдельный раздел в настоящей главе,
сейчас же мы кратко рассмотрим значимость приведенных выше тенденций в контексте продукта XXI века. Концепции и архитектуре последнего посвящена книга, которую читатель держит в руках или открыл на экране своего электронного устройства.
Использование решений с открытым исходным кодом позволило существенно повысить
производительность труда в сфере информационных технологий. Поскольку же данная сфера
настолько пронизывает современный мир, что мы с первой нашей книги говорим о современном мире как о цифровом, то можно сделать вывод, что использование решений с открытым исходным кодом привело к общему повышению производительности труда во всем мире,
во всех сферах человеческой деятельности. Суть указанного повышения производительности
труда заключается в том, что в создание, развитие и внедрение технологий с открытым исходным кодом вовлечено на порядки (и это не фигура речи) больше специалистов, нежели в закрытые (vendor-lock) решения. Данное вовлечение позволяет формировать существенное большее разделение труда и более длинные технологические цепочки, нежели при использовании
закрытых решений, что и приводит к повышению эффективности в соответствии с классическими экономическими теориями. На сегодняшний день в среде экономистов, философов,
политологов ведутся споры об эффективности роста производительности труда в XX—XXI
веках, имеющих ключевое значение для эпохи цифровизации. Мы не будем в настоящем труде
обсуждать масштабы этого роста, оставляя данный вопрос специалистам. Мы принимаем сам
39

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

факт роста за данность, а поскольку современный мир стал цифровым миром, роль информационных технологий в котором огромна, то констатируем, что значимая часть упомянутого
роста производительности (каким бы он ни был) обусловлена применением именно программного обеспечения с открытым исходным кодом.
Ранее в книге «Архитектура цифровых платформ. От настоящего к будущему» мы
неоднократно подчеркивали, что платформа не предоставляет самостоятельной ценности,
но предоставляет ценность опосредованную. Ценность платформы, представляющей собой
среду создания и исполнения приложений, заключается в том, что она позволяет намного более
эффективно создавать и развивать продукты, которые уже предоставляют непосредственную
ценность клиентам и/или партнерам организации. То есть платформа позволяет повысить производительность труда при создании продуктов в компании, применяющей платформенный
подход. При этом не забываем, что лучшие современные решения с открытым исходным кодом
также стремятся к платформенному подходу, формируют экосистемы программных продуктов
(та же экосистема Apache Hadoop). То есть и платформы, и открытое программное обеспечение, дополняют друг друга и одновременно создают синергию роста производительности труда.
А результатом данной синергии является повышение эффективности создаваемых продуктов.
Очевидно, что актуальность тенденции развития архитектуры, заключающейся в применении программного обеспечения с открытым исходным кодом при создании ИТ-решений,
а также необходимость применения платформенного подхода для повышения эффективности
создания продуктов неумолимо приводят к тому, что и в рамках продуктового подхода открытый код становится ключевой архитектурной тенденцией. Если открытый код позволяет повышать эффективность цифровизации, если современные платформы позволяют эффективно
создавать продукты, то было бы непростительно отказываться от открытых решений – это
привело бы к падению эффективности, застою и деградации. В конечном итоге организация,
принявшая столь недальновидное решение, утратила бы собственную конкурентоспособность.
Мы же говорим о необходимости не просто учитывать P&L, мы говорим о том, что P&L является основой продуктового подхода. А поэтому мы должны принимать во внимание необходимость использования открытых решений для поддержки позитивных тенденций в P&L.
Нельзя не отметить также тот факт, что активное использование решений с открытым исходным кодом меняет психологию организации, формирует совершенно иной mindset.
В конечном итоге это приводит и к опережающему достижению истинно продуктового мышления, на нехватку которого мы уже сетовали по ходу настоящего изложения.
Современные организации делают ставку на развитие дистанционных каналов обслуживания: данный подход позволяет кратно снизить издержки, обеспечить массовость привлечения клиентов, быстро отрабатывать ключевые рыночные тенденции и сигналы рынка, учитывать конкурирующие предложения и многое другое. Исходя из этого, продукты изначально
планируются, проектируются и создаются с учетом их доступности в дистанционных каналах,
число которых может варьироваться, а нагрузка оказывается непредсказуемой. В этой ситуации
современные ИТ-решения, предоставляемые клиентам в формате продуктов, должны поддерживать концепцию распределенного исполнения, в противном случае такие продукты не будут
востребованы рынком: продукт, не следующий рыночным тенденциям, не выдерживающий
колебаний нагрузки, не представленный в актуальных дистанционных каналах, не может считаться конкурентоспособным. Можем ли мы представить себе, чтобы на рынке были популярны продукты финансовой организации, если они не представлены, например, в мобильном
банке? Таким образом, современные ИТ-решения должны поддерживать режим распределенного исполнения, соответственно, и современный цифровой продукт априори является распределенным.
В предыдущих книгах распределенность рассматривалась нами в двух смысловых плоскостях: технологической и организационной. Выше была представлена необходимость для
40

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

современного продукта поддерживать технологическую распределенность. Но распределенность организационная является не менее важной в продуктовом подходе, нежели технологическая. Современные продукты являются исключительно сложными как с точки зрения реализуемых ими бизнес-требований, так и в технологическом плане. Создание и развитие такие
продуктов классическими командами гибких практик (не более 8—10 человек, работающих
в одной комнате в итеративном и инкрементном режиме), конечно, возможно. Но подобное
развитие оказывается исключительно долговременным и совершенно неадекватным рыночным тенденциям, ориентированным на максимальную скорость. Поэтому применение гибких
методологий в крупных организациях, а таковыми зачастую стали и многие современные стартапы, требует адаптации. Над продуктами работают десятки, а иногда и сотни команд. Члены
одной и той же команды могут находиться в самых разных точках земного шара, тем более
могут быть распределены по поверхности нашей планеты различные команды. И современный
продукт уже на уровне концепции, тем более на этапе архитектурного проектирования, должен
учитывать еще и эту распределенность, которую мы именуем организационной. Необходимо
иметь возможность создавать и развивать продукты распределенными командами. Поэтому
распределенность и в контексте продуктов остается ключевой тенденцией развития архитектуры.
Уже неоднократно по ходу настоящего изложения мы отмечали высокую сложность
создаваемых на сегодня цифровых продуктов. Эта сложность проявляется в том числе и в их
жизненном цикле. Действительно, если бы жизненный цикл продукта был прост, не понадобилось бы для его перевода в цифру распределенных команд. А сложный жизненный цикл продукта, зачастую имеющий пересечение и с другими продуктами организации либо продуктами
партнеров, описывается набором бизнес-процессов. Таким образом, мы логично приходим
к тому, что обязательным архитектурным элементом продукта является логика бизнес-процессов, непосредственно описывающая продуктовый жизненный цикл. Мы уже отмечали ранее
по ходу настоящей книги, что продуктовая логика является ключевым архитектурным уровнем
в структуре продукта. И продуктовая логика описывается бизнес-процессами. Таким образом,
бизнес-процессы как ключевая тенденция развития архитектуры являются исключительно значимыми при создании и развитии продуктов. Также мы уже отмечали важность применения
платформенного подхода при разработке продуктов, а современная платформа, кроме того,
должна поддерживать бизнес-процессы, в том числе их исполнение в распределенном режиме.
Поэтому продуктовое ИТ-решение использует платформенные механизмы (в формате платформенных сервисов, как показано в книге «Архитектура цифровых платформ. От настоящего
к будущему») для описания, реализации, исполнения и отслеживания связанных с жизненным
циклом продукта бизнес-процессов.
Необходимо подчеркнуть, что многие бизнес-процессы организации являются комплексными, их нельзя локализовать рамками только одного продукта. Поэтому архитектура продуктового решения должна предусматривать возможность того, что при автоматизации жизненного цикла продукта будут задействованы подобные комплексные сквозные процессы.
Например, продуктовые процессы по депозитам задействуют данные кредитных продуктов при
их наличии у клиента, что также может потребовать исполнения бизнес-процессов, связанных с кредитами. Возможна и обратная ситуация. Поэтому продуктовая автоматизация должна
предельно корректно относиться к работе с бизнес-процессами, чему будет посвящен отдельный раздел настоящей главы.
Сложно переоценить значимость данных при создании и развитии продуктов. С данными работают клиенты, партнеры и сотрудники организаций, данные обрабатываются в ходе
исполнения бизнес-процессов, описывающих жизненный цикл продуктов, на основании данных формируются аналитические показатели и принимаются управленческие решения, касающиеся как конкретных продуктов, так и всей организационной деятельности. При этом мас41

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

сивы данных, обрабатываемые организациями, постоянно растут. Увеличиваются потребности
в эффективном хранении и обработке данных. При этом меняется сама концепция хранения,
которую можно в современных реалиях именовать эффективной. Например, понятие оперативного хранения информации претерпевает значимые изменения едва ли не каждый год.
Необходимо отметить, что продукты зачастую используют не просто данные, а большие
данные (Big Data). Под последними понимаются данные, которые характеризуются не только
значительными объемами, но наличием как структурированной, так и неструктурированной
информации, а также высокой скоростью поступления новых объемов информации, которые в свою очередь также могут быть весьма значительными. Использование больших данных предъявляет специфические требования как к хранению информации в продуктовом ИТрешении, так и к проведению операций над ними, что в свою очередь формирует и требования к архитектуре продукта. Поэтому данные являются одним из ключевых трендов развития
не только архитектуры в целом, но и продуктовой архитектуры в частности. Им будет посвящен специальный раздел в настоящей главе.
В контексте работы с данными подчеркнем еще два важных аспекта. Первый. Поскольку
каждый продукт использует и продуцирует огромные массивы данных, то как на уровне концепции, так и на уровне архитектурного проектирования продукты должны обеспечивать поддержку концепции управления данными, принятой в организации. Последняя носит в значительной степени методологический характер, а потому может изменяться вне зависимости
от жизненного цикла конкретного продукта. Таким образом, архитектура современного продукта должна быть адаптивной: позволять использовать продуктовое ИТ-решение в различных концепциях управления данными и накладывать минимальные ограничения (а в идеале не накладывать их вовсе) на организацию при развитии концепции управления данными
последней. Второй. Поскольку современные архитектурные концепции предполагают выделение продукта данных, входящего в состав продукта организации, но обладающего собственным
жизненным циклом, архитектура продуктового ИТ-решения должна позволять гармонизировать жизненные циклы продукта организации и связанного с ним продукта данных. В противном случае могут пострадать самые разные характеристики продукта: время вывода на рынок
(time-to-market), производительность и надежность продуктового решения, сложность сопровождения и т. д.
Развитие искусственного интеллекта переживает на сегодня взрывной рост – способствование ускорению работ в данном направлении становится государственной задачей в самых
разных странах, мощнейших экономиках современности. И данный факт не оставляет нам
выбора – искусственный интеллект является одной из ключевых тенденций развития архитектуры, что должна учитывать в своем продуктовом развитии каждая организация, желающая
сохранить собственную конкурентоспособность. В настоящее время невозможно представить
себе продукт, не использующий технологии искусственного интеллекта. Даже эффективный анализ тенденций рынка и их влияния на P&L предполагает наличие соответствующих
интеллектуальных помощников. Применение искусственного интеллекта позволяет обеспечить дополнительную прозрачность жизненного цикла продукта и принятие необходимых
управленческих решений по развитию последнего с немыслимыми ранее точностью и скоростью. При этом нельзя не учитывать высокую ресурсоемкость технологий искусственного
интеллекта, что может привести к негативному влиянию на P&L продукта, при создании и развитии которого используются данные технологии. Обеспечение сочетания интеллектуализации
продуктов и невысокого ресурсного потребления – один из важнейших вызовов современности.
В настоящей главе каждой из вышеперечисленных ключевых тенденций развития архитектуры и ее месту в концепции и архитектуре цифровых продуктов будет посвящен соответствующий раздел. Пока же отметим, что продукт, пренебрегающий какой-либо из тенденций,
42

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

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

43

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровые продукты и открытый код
В наших предыдущих книгах («Архитектура цифрового мира» и «Архитектура цифровых платформ. От настоящего к будущему») мы указывали две исключительно важные даты
для всего цифрового мира: 17 сентября 1991 года и 28 октября 2018 года. Обе приведенные
даты имеют непосредственное отношение к открытому коду. В 1991 году Линус Торвальдс
опубликовал исходный код ядра операционной системы Linux. И мы вновь и вновь повторяем, что это событие стало эпохальным, а дата 17.09.1991 – отсчетом новой эры программных продуктов. Не только программных продуктов с открытым исходным кодом, но вообще
любых, поскольку незамедлительно возникла синергия открытых и «закрытых» (vendor-lock)
программных продуктов, которая в дальнейшем лишь набирала силу. Фактически сегодня мы
с уверенностью можем сказать, что любой программный продукт так или иначе использует
открытый код.
Но это было лишь началом большого пути. Вторая из вышеприведенных дат знаменательна тем, что именно в этот день свершилась одна из наиболее значимых сделок в истории
открытого кода. Корпорация, ставшая, казалось бы, синонимом масштабных, тяжеловесных,
исключительно дорогостоящих решений, вложила огромные денежные средства в приобретение экспертизы в открытом коде. Да, формально сделка по покупке компанией IBM ведущего
разработчика решений с открытым исходным кодом RedHat была просто очередным корпоративным мероприятием, каковых было множество на тернистом пути «голубого гиганта».
Но подобные формальности можно считать сугубо вторичными. Главным же стало другое –
рассматриваемая сделка ознаменовала собой ключевое изменение философии в цифровом
мире в целом. Да, в программные решения вкладывается огромные труд, интеллектуальные ресурсы специалистов и исследователей со всего мира, но безусловным приоритетом
на сегодня стала эффективность, эффективность создания новых решений, скорейшее предоставление ценности клиентам и партнерам. И открытый код стал тем решением, которое безусловно позволяет повысить указанную эффективность. По факту 28.10.2018 навсегда изменилось мировоззрение цифрового мира. На смену дорогостоящим тяжеловесным решениям
(например, тем же масштабным серверам приложений) пришли легковесные программные
компоненты, использовать которые могут команды по всему миру. Но не только использовать,
но и развивать, расширять и улучшать.
В качестве примера дрейфа даже, казалось бы, апологетов vendor-lock решений в сторону открытости можно привести такой популярнейший фреймворк разработки и исполнения приложений, как. NET. Выпущенный из недр корпорации Microsoft, всегда считавшейся
в ИТ среде едва ли не главным сторонником закрытости, популярный фреймворк также стал
открытым. Сперва в 2014 году появилась открытая сборка. NET Core, впоследствии и весь.
NET ушел от «темной стороны силы», если цитировать знаменитую киносагу. И не просто
ушел в сторону открытого кода, но и полностью поддержал исполнение в Linux среде, теперь
фреймворк развивается и такими компаниями, как упомянутая выше RedHat. То есть на наших
глазах происходит синергия решений, которые самыми разными путями неумолимо движутся
в сторону открытости. Кто-то исходно придерживался данной философии, кто-то переходил
к ней в тяжелые корпоративные моменты, кто-то же, наоборот, на волне успеха. Но главное
случилось – шаг в сторону приоритета открытого кода сделан. И это, если использовать метафору из еще одной исключительно популярной серии фильмов, та «красная таблетка», после
которой невозможно смотреть на мир, как прежде.
Но в чем же заключается упомянутое повышение эффективности, которое дает открытый
код? Что побуждает таких в прошлом апологетов закрытости, как IBM и Microsoft, выбирать
44

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

этот путь? В книге «Архитектура цифрового мира» мы уже подробно разбирали ответы на эти
вопросы. Вкратце напомним их читателю.
Современная экономическая теория, восходящая еще к итальянским натурфилософам,
таким как Антонио Серра, выводит повышение эффективности из увеличения разделения
труда – длинные экономические цепочки, предполагающие задействование большего числа
участников, позволяют резко повышать общую эффективность. Серьезнейший вклад в развитие данной теории и ее систематизацию внес Адам Смит и его последователи. Есть представители и отечественной школы, внесшие свою лепту в развитие указанного научного направления, такие как М. Л. Хазин. Целью настоящей книги не является повторение всех их
логических умопостроений, мы принимаем их выводы: увеличение разделения труда ведет
к повышению производительности. И для области информационных технологий данный факт
исключительно важен. Открытые решения позволяют вовлечь в их развитие такое количество
специалистов со всего мира, которое невозможно ни для одного закрытого программного обеспечения, сколь бы крупная корпорация его ни развивала. И это принципиальный момент –
открытые решения обеспечивают уровень производительности труда, недоступный для закрытых решений. Именно подобный уровень производительности труда и привел крупнейших
игроков ИТ-рынка в стан сторонников открытого кода.
Что же все вышесказанное означает для цифровых продуктов? Мы и по ходу предыдущих книг, и в течение настоящего изложения неоднократно говорили о ценности, которую
несет продукт клиентам и партнерам организации, создающей и развивающей продукт. Отмечали мы и P&L продукта в качестве его обязательной характеристики. То есть мы подчеркиваем тот факт, что ценность необходимо создавать как можно быстрее и эффективнее. Рассуждая же о преимуществах открытого кода, мы во главу угла ставим производительность труда,
характеризующую развитие и использование открытых решений. Таким образом, применение
открытых технологий становится ценностным мультипликатором, позволяющим существенно
повысить производительность труда при создании и развитии современных продуктов. Это
означает, что если ставится цель создавать конкурентоспособные продукты (а это в свою очередь означает, что должны выискиваться все варианты повышения производительности их
разработки), то организация, имеющая указанную цель, обязана использовать открытое программное обеспечение.
Как и в случае с цифровыми платформами, продукт для своего эффективного развития должен использовать лучшие практики открытого кода. Платформа же, как мы неоднократно отмечали в книге «Архитектура цифровых платформ. От настоящего к будущему»,
предоставляет опосредованную ценность, позволяя разгрузить продуктовые команды от рутинной деятельности, что также приводит к росту производительности продуктовой разработки.
То есть платформа также является ценностным мультипликатором. Мы приходим к логичному выводу: платформа должна использовать практики открытого кода, продукты же должны
использовать практики открытого кода и разрабатываться на платформе. Сочетание указанных
ценностных мультипликаторов позволяет многократно повысить производительность труда –
мы уже ссылались в нашем предыдущем труде на исследование, показавшее, что технологические гиганты оказываются в состоянии вносить изменения, дополнения и в конечном счете
улучшения в свои решения, находящиеся в постоянной эксплуатации, практически каждые
десять секунд. Это и есть движение к достижению эффективности XXI века. Но только начало
этого движения. Необходимо не просто не останавливаться на достигнутом, но и постоянно
искать новые пути повышения производительности труда.
Неоднократно по ходу своей профессиональной деятельности автор этих строк сталкивается с вопросом: «Можно ли построить продукт вообще без какого-либо использования
открытого кода?» Иногда этот вопрос ставится несколько по-другому: «Объектом уточнения
становятся платформы, возможно ли создание последних без применения открытого кода?»
45

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

И краткий ответ на подобные вопросы всегда один: «Можно». Читатель может удивиться:
«Как же так, мне пришлось прочитать столько хвалебных од в адрес открытого кода, а теперь
автор так просто признается, что сложнейшие программные комплексы можно создать и без
него! Меня вводят в заблуждение!» На самом деле ввод читателя в заблуждение – это последнее, чего бы хотел добиться автор. Поэтому вслед за кратким ответом о принципиальной возможности создания продуктов без применения практик открытого кода необходимо дать более
развернутое объяснение.
И поскольку настоящая книга, как и две предыдущие, посвящена архитектуре, то и объяснение, даваемое автором, также будет базироваться именно на архитектуре.
Для начала вернемся к детализации концептуальной архитектуры продукта, приведенной
на Рисунках 9 и 10 и описанной в предыдущей главе. В соответствии с описанием в архитектуре
задействованы такие программные компоненты и фреймворки, как:
• Языки программирования высокого уровня (в том числе позволяющие разрабатывать
легковесные фронтальные решения).
• Реляционные СУБД.
• Нереляционные СУБД.
• Потоковое программное обеспечение.
• Кэширующие компоненты.
• BPM движки.
• Программное обеспечение для управления открытыми API.
• Распределенная файловая система.
• И т. д.
Для всех указанных пунктов существует свободно распространяемое программное обеспечение с открытым исходным кодом, позволяющее решать задачи по автоматизации продуктов. Пример такого сочетания технологий приведен на Рисунке 13. В очередной раз
оговоримся, что мы приводим иллюстративный пример, а не разбираем конкретные случаи продуктовой разработки. Взаимодействие, показанное для технологий реализации, также
является иллюстративным и может отличаться при конкретной продуктовой автоматизации.
По сравнению с ранее приведенным примером мы на Рисунке 13 заменили BPM Camunda
на BPM Kogito, чтобы следовать принципу выбора максимально открытой лицензии, тем более
в главе, посвященной открытому коду.

46

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 13. Пример перечня технологий с открытым исходным
кодом для продуктовой автоматизации
Возможно ли заменить каждую из представленных технологий ее проприетарным аналогом? Безусловно, да, именно поэтому мы и дали положительный ответ на принципиальный
вопрос о возможности реализации продуктов без применения открытого кода. Но дальше начинаются архитектурные нюансы.
Любое современное программное обеспечение, решающее задачи повышенной сложности, например в части управления базами данных, является огромным программным комплексом, содержащим множество компонентов. И даже в случае предоставления подобной СУБД
в формате vendor-lock оно будет использовать значительное число внешних библиотек, требовать для своего исполнения определенного программного окружения. Это касается и программных библиотек в реализации, и компиляторов, и интерпретаторов, и многих других
аспектов. И во всех этих компонентах содержится свободное программное обеспечение. В противном случае компания, предоставляющая соответствующее ИТ-решение, должна разработать его полностью самостоятельно, вплоть до компилятора. Подобная реализация, конечно,
достижима, но оценить ее стоимость и сроки не представляется возможным. Мировые технологические гиганты идут другим путем и включают в предоставляемые ими решения компоненты
с открытым исходным кодом, а зачастую и базируются на них. Ведь именно таким образом
оказывается возможным выстроить максимально длинную цепочку разделения труда и снизить
стоимость итогового ИТ-решения. Тем самым улучшается и P&L конечного продукта.
Резюмируя вышесказанное, подчеркнем, что технически создать современный цифровой
продукт без использования открытого кода возможно, но таковой продукт будет создаваться
долгое время, а себестоимость создания и последующего развития окажется исключительно
высокой. Поэтому подобный подход автор считает бесперспективным и нецелесообразным.
В ходе своей профессиональной деятельности (и особенно после выхода предыдущих
книг) автору приходилось сталкиваться и с обратным вопросом: «Возможно ли построить
современный цифровой продукт только с использованием открытых решений?» Зачастую
собеседники автора высказывали сомнения в реализуемости подобной парадигмы.
47

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Мы понимаем, что каждая компания действует в собственных финансовых, экономических, технологических и иных условиях. И поэтому однозначного рецепта по созданию продуктов дать не можем. Начнем свой ответ с совмещения Рисунков 9, 10, на которых представлена детализация концептуальной архитектуры продукта, и Рисунка 13, демонстрирующего
пример сочетания ряда технологий с открытым исходным кодом, используемых в ходе продуктовой разработки. Проиллюстрируем указанное совмещение на Рисунках 14 и 15 (мы продолжаем разбивать детализацию архитектуры на два рисунка для удобочитаемости).

48

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 14. Детализация архитектуры продукта с использованием открытого программного обеспечения (часть 1)

49

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

50

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 15. Детализация архитектуры продукта с использованием открытого программного обеспечения (часть 2)
На Рисунках 14 и 15 представлен пример реализации архитектурных уровней продуктовой логики с использованием открытого программного обеспечения. Еще раз подчеркнем –
это именно упрощенный пример. Мы не включаем в него вопросы сбора логов, трассировки,
аудит, аутентификацию, авторизацию, управление секретами, события клиентских приложений и т. д. Но мы видим, что открытые решения в состоянии покрыть полную реализацию
архитектуры end-to-end продукта. Разумеется, в таком подходе существуют и свои собственные
ограничения – пока в цифровом мире не создана «цифровая серебряная пуля».
В свое время в русскоязычном сегменте сети Интернет пользовался популярностью юмористический рассказ, сравнивавший программное обеспечение с самолетами. Проприетарное
программное обеспечение было ассоциировано с продукцией уважаемых мировых авиаконцернов, свободное же программное обеспечение было уподоблено «кукурузнику», который
собирался под конкретный полет, причем метод сборки был весьма оригинальным. Например, такой воздухоплавательный аппарат мог одновременно перевозить пассажиров и опылять поля, при этом перевозка пассажиров без опылителя была невозможна. В приведенном
юмористическом примере была доля горькой правды: за корректное использование открытого
программного обеспечения надо платить. И в первую очередь платить за экспертизу по его
использованию. Отметим, что экспертиза может быть как внешней, так и внутренней. Например, возможным является привлечение внешних консалтинговых услуг, включая архитектурный анализ использования тех или иных технологий. Учитывая же, что технологии являются
свободными, то и рынок консалтинга и архитектуры существенно шире, нежели в случае
применения «закрытых» (vendor-lock) технологий. Альтернативным вариантом привлечения
экспертизы является использование проприетарных решений, основанных на открытом коде,
решений, в которых свободное программное обеспечение является своеобразным «ядром».
В настоящее время существует немало рыночных игроков, ведущих свою деятельность подобным образом. Например, они используют то или иное программное обеспечение с открытым
исходным кодом, расширяя его возможности. В таком случае именно дополнительные возможности являются интеллектуальной собственностью конкретного рыночного игрока, то есть
обеспечивается синергия длинных технологических цепочек создания и развития решения
с открытым кодом и экспертизы компании, производящей его адаптацию к конкретным применениям в индустрии. Использование подобных решений обеспечивает заказчикам экономию
на внутренней экспертизе. Разумеется, требования к поставщику подобного решения в таком
случае должны включать по-настоящему развитые компетенции в открытом решении. В противном случае заказчик будет поставлен перед необходимостью отдельно оплачивать экспертизу в открытом решении и тех дополнениях, что внес поставщик. Поставщик должен обеспечивать совместимость дополнений (как технологическую, так и методологическую) с открытым
решением, сам обладать компетенциями по внесению дополнений (commit’ов) в открытый код,
им используемый.
Если же компания, создающая цифровые продукты, минимизирует привлечение внешней экспертизы, например, для снижения зависимости от внешних поставщиков, то это также
не препятствует полноценному использованию открытого кода. Никто не запрещает компаниям создавать внутренние центры экспертизы. Более того, наличие подобных центров
(внутренних или внешних) является необходимым для полноценного использования решений
с открытым исходным кодом. Ведь открытый код предлагает философию, кардинальным образом отличающуюся от использования проприетарных решений. И эта философия заключается
все в том же разделении труда, о котором мы говорим и по ходу наших предыдущих книг,
и по ходу настоящего изложения. Огромное преимущество длинной цепочки разделения труда
51

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

центров компетенций не имеет сейчас принципиального значения – оно определяется организациями в рамках собственной стратегии развития. В настоящем изложении мы говорим
о принципах. Мы уходим от эфемерных инвестиций в лицензии к инвестициям в экспертизу.
Увы, до сих пор иногда приходится слышать на рынке выражения из серии «внедрить лицензии». Но рынок ждет от компаний не внедренных лицензий, пусть и уважаемых поставщиков,
а продуктов, представляющих ценность для клиентов и партнеров. И здесь надо инвестировать
в экспертизу создания этой ценности. Главный капитал XXI века – человеческий. И открытый
код стимулирует инвестиции непосредственно в человеческий капитал. Именно поэтому он
и является одной из ключевых тенденций развития архитектуры, поэтому он так важен для
создания современных цифровых продуктов.
Отдельно отметим еще одно направление инвестиций в экспертизу. Используя открытые
решения при создании продуктов, компании формируют для них новые варианты использования, которые приводят к расширению возможностей открытого ПО. Нередко подобное расширение возможностей материализуется в виде доработок, вносимых в решения с открытым
исходным кодом. И крайне важно в таком случае следовать рекомендациям от сообществ, разрабатывающих решения с открытым исходным кодом, по внесению изменений и их последующей публикации. Указанный подход позволит обеспечить совместимость используемых версий открытого ПО с вновь появляющимися, не сделает код, содержащийся в репозиториях
компании, тупиковой ветвью эволюции. Благодаря этому продукты компании смогут использовать актуальные версии свободного ПО, поддерживать прозрачность собственных релизных
моделей. И это отдельное направление экспертизы, о котором нельзя забывать в том числе при
формировании финансовой модели продуктовой разработки.
Внимательный читатель наверняка задаст нам и еще один каверзный вопрос: «Вы
все время говорите о ценности, предоставляемой продуктом, о P&L продукта, но в то же
время называете продуктом свободно распространяемое программное обеспечение с открытым исходным кодом – какой же это продукт?» Мы незамедлительно дадим ответ, что открытый код безусловно является продуктом, и ниже объясним почему.
Создание и развитие программного обеспечения с открытым исходным кодом не является бесплатным, ведь в данный процесс привлекается значительная экспертиза. И, как показывает практика, вложения в открытое ПО осуществляют технологические гиганты, лидеры
рынка ИТ. Зачем же они это делают? Основой их мотивации является все та же теория разделения труда. Лидеры рынка создают длинные технологические цепочки, обеспечивают высокую производительность труда при создании открытого программного обеспечения, гарантируют эффективность развития последнего. При этом они, развивая интересующее их ПО,
обладают высокими компетенциями по части его использования и создания на его основе продуктов заказчиками. И таким образом осуществляется возврат инвестиций – путем включения
открытого ПО в проприетарные продукты, оказание консалтинговых услуг, услуг по внедрению и адаптации программных продуктов, монетизации соответствующей экспертизы. Участниками процесса развития являются и заказчики, которые могут как добавлять новые варианты использования открытого программного обеспечения, так и включать новые дополнения
в его состав. Просто цикл создания ценности стал длиннее и обширнее, нежели это выглядело
в случае проприетарного программного обеспечения. И поэтому открытое программное обеспечение безусловно является продуктом. Ценность же оно предоставляет заказчикам, позволяя им создавать гибкие, надежные и современные цифровые продукты.
Внимательный читатель может прервать наши рассуждения злободневным саркастическим вопросом: «Неужели мы просто так разворачиваем открытое программное обеспечение,
например, представленное на рисунках выше, и получаем современные цифровые продукты?»
Мы понимаем и принимаем сарказм, выраженный в данном вопросе. Разумеется, и само программное обеспечение корректно развернуть и подготовить к использованию зачастую совсем
53

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

непросто, особенно если речь идет о сложном корпоративном ИТ-ландшафте, содержащем как
унаследованные, так и устремленные в будущее компоненты. Но и просто набор программного обеспечения не составит продукта для компании, осуществившей развертывание выбранного технологического стека на собственной или арендованной ИТ-инфраструктуре. Отвечая
на вопрос читателя, мы вернемся к книге «Архитектура цифровых платформ. От настоящего
к будущему». Аналогичный вопрос читатель задавал относительно платформы. Мы же указывали, что при создании и развитии платформы, во-первых, осуществляется технологическая унификация, во-вторых, формируются варианты использования технологий. И это требует серьезного интеллектуального ноу-хау, серьезных инвестиций от компании, создающей
платформу. С продуктами ситуация во многом аналогичная. Цифровой продукт представляет
собой независимую ценность для клиентов и/или партнеров компании, создающей и развивающей продукт. И для обеспечения этой ценности осуществляется автоматизация деятельности компании. Формат автоматизации определяется процессами компании. Программное
обеспечение в данном случае используется в качестве инструмента. Мы аргументируем выбор
в пользу программного обеспечения с открытым исходным кодом на основании той гибкости,
которую оно несет продуктам. Высокая скорость внесения изменений, множество топологий
развертывания, большое число вариантов использования позволяют создавать максимально
адекватные требованиям рынка продукты, более того, создавать продукты, меняющие рынок.
Например, Uber изменил рынок пассажирских перевозок. И основывался при этом на открытом коде.
Как правило, компания предлагает своим клиентам и партнерам множество продуктов. И если допустить их независимое развитие, то многообразие программного обеспечения
с открытым исходным кодом может сыграть против компании. Если каждый продукт будет
использовать собственный технологический стек, то это приведет к «зоопарку» технологий,
увеличению трудозатрат на создание и сопровождение продуктовых ИТ-решений. Самый элементарный пример подобных затруднений представлен на Рисунках 16 и 17.
Мы специально доводим наши примеры до абсурда: при выборе технологической реализации двух продуктов мы сохраняем общей технологией только реляционные СУБД, указав
для них одну из наиболее популярных на сегодняшний день технологий с открытым кодом
PostgreSQL. Для автоматизации всех остальных продуктовых задач мы используем различные
технологии, при этом все они представляют программное обеспечение с открытым исходным
кодом. В качестве фреймворков языков высокого уровня представлены Java и. NET, управления API WSO2 и Gravitee, фреймворков фронтальной разработки Angular и React, технологий кэширования Infinispan и Ignite, потоковой передачи данных Apache Kafka и Apache
Pulsar, нереляционных СУБД Apache Cassandra и ScyllaDB, управления бизнес-процессами –
Camunda и Kogito, архивного хранения – S3 и Apache Hadoop (здесь и далее мы не приводим
конкретные продукты реализации S3 с целью избежать избыточного загромождения иллюстраций).

54

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 16. Пример технологического «разнообразия»
продуктовой автоматизации при использовании ПО
с открытым исходным кодом (часть 1)
55

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

56

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

57

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 17. Пример технологического «разнообразия»
продуктовой автоматизации при использовании
ПО с открытым исходным кодом (часть 2)
Повторим еще раз, весь перечисленный технологический стек состоит из программных
продуктов с открытым исходным кодом. Но использовать подобный подход для современной
продуктовой автоматизации зачастую нецелесообразно по финансовым соображениям: необходимы вложения в экспертизу в части каждого из используемых программных продуктов. Поэтому при автоматизации продуктовой деятельности мы выбираем технологический
стек, закрепляем его на уровне платформы, которая в свою очередь определяет рекомендуемые
топологии программного обеспечения и его варианты использования в зависимости от архитектурного уровня, на котором оно применяется, и тех функциональных требований, которые
предъявляются к продукту. Как мы отмечали в предыдущих книгах, платформа представляет
собой среду создания и исполнения приложений, а продуктовые решения реализуются в виде
платформенных приложений. Платформа, как и открытый код, является ценностным мультипликатором, а потому и используются указанные мультипликаторы совместно. Платформа
использует открытый код и предоставляет его возможности для создания продуктов максимально эффективным образом. Подробнее аспекты сочетания платформенной и продуктовой
автоматизации будут рассмотрены в дальнейшем в соответствующей главе.
Нельзя обойти вниманием и еще один исключительно важный аспект использования
решений с открытым исходным кодом – аспект безопасности. Часто можно услышать голоса,
предостерегающие от использования открытого программного обеспечения. Нам пытаются
доказать, что использование открытого кода таит в себе нешуточную опасность, мол, включить в него недокументированные возможности может каждый. Любой из коммитов, включенных в основную ветку программного продукта, потенциально является вредоносным. Это, безусловно, так. Но давайте подумаем о том, исключаем ли мы указанный риск при использовании
закрытого проприетарного ПО. Ранее мы уже отмечали, что любое современное программное обеспечение основано на открытом коде. Даже при локализации всех пакетов в собственных репозиториях ни одна компания в мире не может себе позволить развивать все пакеты
самостоятельно. И заимствование кода осуществляется на перманентной основе. И компания, внедряющая внешние решения в качестве основы продуктовой автоматизации, в любом
случае должна полностью проверять все дистрибутивы программного обеспечения, получаемые извне. Это касается как открытых, так и проприетарных решений. И логичным следствием будет обязательный процесс сборки решений на инфраструктуре компании-заказчика.
Мы отдаем себе отчет в том, что это непростой, трудоемкий и финансово обременительный
процесс. Да, можно заключать с поставщиками контракты жизненного цикла и выставлять
штрафные санкции в случае обнаружения уязвимостей и недокументированных возможностей
в процессе жизненного цикла уже продуктовых решений. Но зачастую последствия подобного отложенного обнаружения окажутся для компании катастрофическими. Здесь тот случай,
когда известная поговорка, что «скупой платит дважды», может оказаться избыточно мягкой.
И мы приходим к логичному выводу, что в любом случае, какое бы программное обеспечение (открытое или проприетарное) ни использовалось, необходимо осуществлять максимально
полный анализ его состава, структуры и возможностей с точки зрения информационной безопасности. И здесь как раз открытый код с его понятной и логичной структурой оказывается
предпочтительным – его исследования осуществляются по всему миру с публикацией результатов, что и подтверждено масштабами внедрения успешных решений.
Отдельно подчеркнем, что мы ни в коем случае не рекомендуем напрямую устанавливать в среду постоянной эксплуатации решения с открытым исходным кодом, взятые из открытых репозиториев. Разумеется, подобное было бы откровенно авантюрным поведением с зако58

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

номерным итогом. Компании должны разворачивать собственные репозитории программного
обеспечения с открытым исходным кодом, заимствовать информацию из открытых репозиториев, проверять полученные программные пакеты и поддерживать высокий уровень защищенности. Установка программного обеспечения в среды опытной или постоянной эксплуатации
может осуществляться только из доверенных источников.
Мы уже отмечали, что по ходу настоящей книги мы будем неоднократно рассматривать
мировоззренческие вопросы продуктовой разработки ввиду их особой важности в части повышения эффективности создания цифровых продуктов. В настоящем разделе коснемся некоторых моментов мировоззрения компаний, на которые напрямую влияет использование решений
с открытым исходным кодом. Здесь, как и в наших предыдущих книгах, мы возьмем за основу
тезисы Джима Уайтхерста (James M. «Jim» Whitehurst), изложенные им в книге «Открытая
организация: Страсть, приносящая плоды» (2015, ISBN 978-5-9693-0405-5): мотивация, меритократия, прозрачность принятых решений, развитие новых направлений. Рассмотрим данные
тезисы в контексте продуктового подхода.
• Мотивация. Данный тезис исключительно важен в контексте современной продуктовой
разработки: эффективность работы коллектива резко возрастает, когда каждый член команды
видит результаты своего труда и их место в общекомандном результате. Отметим также, что
общекомандный результат в таком случае получается большим, нежели просто сумма частных результатов каждого участника рабочего процесса, то есть проявляется синергетический
эффект. В книге «Архитектура цифрового мира» мы отмечали, что само по себе развитие
решений с открытым исходным кодом является наглядным примером высокоэффективной
совместной работы огромного количества замотивированных специалистов со всего мира,
а результаты говорят сами за себя. В книге «Архитектура цифровых платформ. От настоящего
к будущему» мы рассматривали развитие данного тезиса в применении к современным платформам: команды работают совместно как над платформой, так и над платформенными приложениями, публикуют изменения как в платформу (ввиду свойства открытости платформ), так
и непосредственно в открытое программное обеспечение, развиваемое международными сообществами, создают новые топологии и варианты использования платформенных решений, что
кардинально повышает производительность общей работы. А в случае продуктовой разработки
мы идем дальше: команды совместно работают над продуктами, используя платформенный
подход и опыт друг друга. При этом, создавая продукты, команды добавляют новые варианты
использования для платформ и платформенных сервисов, публикуют дополнения общедоступными в рамках платформенной экосистемы, расширяя тем самым возможности не только
самой платформы, но и смежных команд, работающих над другими продуктами. Со временем,
как мы отмечали при рассмотрении платформенных подходов, должна стираться грань между
платформенными и продуктовыми командами – развитие платформы начинает определяться
потребностями продуктов, что повышает прозрачность деятельности и улучшает мотивацию
всех членов команд продуктовой разработки. Необходимо подчеркнуть, что рассматриваемое
повышение мотивации продуктивно сказывается и на экономической деятельности компаний,
создающих и развивающих продукты. Если ключевым направлением финансирования, как мы
отмечали выше, становится экспертиза, то мотивация носителей этой экспертизы, в том числе
нематериальными стимулами, к которым относится использование решений с открытым кодом
и следование философии открытого кода, является исключительно положительным моментом.
И это становится важным мировоззренческим аспектом современного цифрового мира.
• Меритократия. Задачи меритократии в рассматриваемом контексте тесно связаны
с предыдущим тезисом – мотивацией. Суть меритократии заключается в том, что полномочия
при принятии решений каждого конкретного члена команды соразмерны его вкладу в общекомандное дело. И наша задача – обеспечить максимальную вовлеченность ответственных и ком59

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

петентных членов команды. И вовлеченность их напрямую зависит от их мотивации. В контексте использования решений с открытым исходным кодом вклад каждого участника рабочего
процесса является максимально прозрачным. И если мы выстраиваем платформы и продукты
на их основе также с использованием практик открытого кода, то мы можем перенести указанную прозрачность и в корпоративную деятельность. А уже на основе прозрачности определять
вклад каждого участника и, следовательно, степень его полномочий в рамках меритократии.
В рамках совместной деятельности может быть выстроена не только меритократия отдельных
членов команд, но и команд в целом. Мы уже говорили о том, что продуктовое развитие организации должно быть унифицированным технологически – этому способствует платформенный подход. И продуктовые команды, дополняя и развивая платформу организации, повышают
и свой вес с точки зрения меритократии. Разумеется, когда мы говорим о продуктовой разработке, то меритократия не может исчерпываться исключительно дополнениями в платформу,
необходимо учитывать скорость развития продуктов, их качество, их P&L и т. д. Из всех этих
факторов складывается объем полномочий команд и их членов при развитии цифровизации
в масштабах всей компании. А основу данной философии в ИТ дает открытый код. Архитектор же со своей стороны может проводить независимую оценку тех дополнений, которые вносятся членами продуктовых команд и командами в целом в платформу или общие используемые компоненты.
• Прозрачность принятых решений. Основываясь на принципах меритократии и обеспечив высокую мотивацию всех вовлеченных в процесс создания и развития продуктов специалистов, становится возможным достигнуть прозрачности при принятии решений в ходе
продуктовой разработки, ведь последняя непосредственно влияет на развитие всей компании.
Таким образом, обеспечивается прозрачность не только принятия решений, но и влияния всех
членов команд разработки на общекорпоративное развитие в целом. Указанная прозрачность
повышает вовлеченность и производительность труда всех специалистов, становясь дополнительным фактором повышения эффективности деятельности организации, увеличивая ее конкурентоспособность. Направление развития продукта непосредственно связано таким образом с развитием компании, развитие платформы прозрачно для продуктовых команд и также
прозрачно для всех участников процесса создания ценности. Таким образом, все изменения,
выполняемые в ходе рабочего процесса, становятся прозрачными, понятным оказывается их
влияние как на текущее развитие, так и на более долговременные перспективы. Становится
возможной грамотная оценка каждого изменения, учет его последствий, возникающих в ходе
производственной деятельности рисков, в конечном итоге – предсказуемость развития платформы, продукта, компании в целом. И это также позволяет кардинально повысить производительность труда в компании, принявшей для себя mindset открытого кода, mindset открытой
организации.
• Развитие новых направлений. Логичным продолжением предыдущих тезисов становится четвертый тезис, а именно постоянное развитие новых направлений, выступающее драйвером прогресса всей компании. Продуктовые команды должны максимально быстро проверять гипотезы, рассматривать новые предложения по повышению эффективности и P&L
продуктов, внедрять изменения в используемую платформу. Продуктовое развитие не просто
осуществляется на основе развития технологического, но и со своей стороны выступает драйвером последнего. Новые направления могут проявляться в новых вариантах использования
технологий для удовлетворения продуктовых потребностей, в поиске новых технологий и их
топологий, в общей синергии технологий. И все это проверяется продуктовыми командами
на предмет применимости в процессе создания ценности для клиентов и/или партнеров организации. А следствием открытости (компании, команды, платформы, продукта) становится
прозрачность нового направления для всех команд, создающих и развивающих продукты.
60

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

61

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровые продукты и распределенность
В наших предыдущих трудах («Архитектура цифрового мира» и «Архитектура цифровых платформ. От настоящего к будущему») мы выделяли распределенность в качестве одной
из ключевых тенденций развития архитектуры. Распределенность является одной из ключевых тенденций развития цифрового мира в целом, распределенность актуальна и для цифровых платформ. Логично рассмотреть вопрос о значимости распределенности для цифровых
продуктов. Как и ранее, мы будем рассматривать распределенность в двух смысловых плоскостях: организационной и технологической. Первая смысловая плоскость акцентирует наше
внимание на том, что в работе над продуктом (тем более над экосистемой продуктов) организации может принимать участие распределенная команда специалистов самого разного профиля. Вторая смысловая плоскость подразумевает, что создаваемое и развиваемое продуктовое ИТ-решение должно поддерживать распределенный характер исполнения.
Рассмотрение проблематики распределенности в контексте продуктового подхода начнем с распределенности организационной. Мы уже неоднократно отмечали как по ходу текущего изложения, так и предыдущих книг, что в настоящее время стандартом де-факто стали
гибкие практики разработки, ставящие продукт во главу угла. «Вот и замечательно, в соответствии с гибкими практиками сразу создается ценность для клиента. И нет никаких проблем!» –
воскликнет нетерпеливый читатель. И будет неправ. К сожалению, проблемы только начинаются.
Адам Смит на научной основе доказал, и его тезисы пока не опровергнуты ни для
одной сферы деятельности, что увеличение разделения труда повышает общую производительность труда. Чем более длинными являются цепочки разделения труда, тем они более эффективны. Но великий шотландец также показал, что при этом растут риски каждого отдельного
участника указанной цепочки разделения труда. Каждый участник становится зависимым как
от поставщиков, так и от потребителей. Чем больше и тех и других, тем выше риски участника
цепочки разделения труда. Покажем это на примере отрасли информационных технологий,
взяв за основу базовую детализацию концептуальной архитектуры продукта, которую мы приводили ранее по ходу настоящей книги (Рисунки 9 и 10). И добавим на эти рисунки командное распределение. Предположим, что каждый уровень архитектуры реализуется собственной
командой разработки. При этом мы продолжаем рассмотрение с учетом того, что, как и ранее,
при создании и развитии продукта используется платформенный подход. Иллюстративно наше
представление приведено на Рисунках 18 и 19.
Мы предполагаем, что при разработке продукта используется платформенный подход, поэтому указали на Рисунках 18 и 19 номера используемых платформенных сервисов
в соответствии с ранее разобранными примерами (см. Рисунки 8—10). Также мы добавили
на Рисунки 18 и 19 команды разработки продукта, специализирующиеся на разных его составляющих, соответствующих ранее выделенным архитектурным уровням.

62

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 18. Реализация архитектуры продукта
командами разработки (часть 1)
63

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

64

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 19. Реализация архитектуры продукта
командами разработки (часть 2)
Фронтальное и канальное представление продукта, а также канало-специфичную логику
реализует команда фронтальной разработки, специализирующаяся на создании легковесных
приложений, соответствующих требуемым для продукта каналам обслуживания, а также
на предоставлении внешних API. Такая команда должна содержать дизайнеров, специалистов по пользовательскому интерфейсу, разработчиков фронтальной логики (со знанием таких
фреймворков разработки, как, например, Angular), разработчиков связанной с фронтальными
компонентами прикладной логики, например, с использованием Java или. NET, специалистов DevOps и т. д. Также, учитывая специфику детализируемой архитектуры, члены команды
должны обладать знаниями в кэширующих компонентах, потоковом программном обеспечении, управлении API и т. д.
Оперативное и архивное хранение продуктовых данных (оперативное представлено
на Рисунке 18, архивное – на Рисунке 19) реализуется силами команды логики хранения. Такая
команда должна содержать в своем составе разработчиков, владеющих языками программирования высокого уровня, такими как Java или C#, специалистов DevOps, специалистов со знанием различных технологий долговременного хранения, кэширующих компонентов, потокового программного обеспечения и т. д.
Продуктовая логика, в том числе логика управления бизнес-процессами, реализуется
командой продуктовой логики. Последняя должна обеспечивать вовлечение в рабочий процесс
разработчиков, профессионально использующих языки программирования высокого уровня.
При этом члены команды должны владеть знаниями о практиках оркестровки и хореографии
бизнес-процессов, соответствующем программном обеспечении, используемом при автоматизации процессной деятельности. Также в соответствии с архитектурой команде требуются
компетенции в части баз данных и потокового программного обеспечения. Нельзя забывать
и о специалистах DevOps, обеспечивающих гибкость и скорость процесса разработки и развертывания приложений.
При всей схожести интеграционного уровня с уровнем, например, продуктовой логики,
его реализация представлена отдельной командой специалистов, в фокусе внимания которых
находятся именно интеграционные аспекты – производительность и надежность взаимодействия, эффективное получение и выдача данных, что зачастую несет в себе ярко выраженную
специфику.
Итогом подобного разделения становится четко определенная граница работ каждой
из команд. Наличие же платформы (используемые платформенные сервисы представлены
на Рисунках 18 и 19 в соответствии с нумерацией, приведенной на Рисунке 8) обеспечивает технологическую и методологическую унификацию работы команд. Казалось бы, осталось совсем немного – реализовать ценность, требуемую пользователям. И тут мы подходим
к самому главному – приведенная конфигурация оказывается неработоспособной или в лучшем случае крайне неэффективной в современном цифровом мире.
Ни одна из приведенных выше команд не создает самостоятельной ценности: ценность
предоставляет продукт, а не его отдельный слой. Мы уже разбирали данный факт ранее на примере кредитного продукта. Ценность для клиента заключается в самом продукте (кредите),
а не может исчерпываться визуальным представлением заявки на кредит и даже самой заявкой. Заявка на кредит может представлять собой один из этапов жизненного цикла продукта
(по опыту автора, далеко не самый трудоемкий), но лишь один из. И отсюда следует непреложный вывод – все указанные на Рисунках 18 и 19 команды являются частями целого – продуктовой команды разработки. Здесь мы и приходим к организационной распределенности. Забегая
65

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

вперед, отметим, что Рисунки 18 и 19 демонстрируют и технологическую распределенность,
но последнюю детально мы рассмотрим несколько позже.
Таким образом, мы пришли к выводу, что все составные части продукта (с точки зрения архитектурных слоев) реализуются единой продуктовой командой. Но результат автоматизации современного продукта представляет собой масштабный программно-технологический комплекс, при этом указанная автоматизация должна осуществляться достаточно быстро,
чтобы обеспечивать лучшие показатели времени вывода продукта на рынок (time-to-market).
Не забываем также утверждение, сформулированное нами в книге «Архитектура цифровых
платформ. От настоящего к будущему»: по ходу цифровой трансформации стирается грань
между платформенными и продуктовыми командами, по мере повышения цифровой зрелости
организации выделенные платформенные команды исчезают, а развитие платформы должно
осуществляться продуктовыми командами. В силу свойства открытости платформы продуктовые команды, выявив недостаточность платформенного функционала, дополняют последний
и публикуют сделанные ими дополнения таким образом, чтобы они стали доступными для
всех команд, использующих платформу. Из всего сказанного следует логичный вывод: продуктовая команда оказывается весьма многочисленной. В современной крупной организации
невозможным становится обеспечить развитие продукта силами классической команды гибких практик, насчитывающей 8—10 человек. Конечно, если быть до конца дотошными, то развивать и современный продукт можно указанной командой, но подобное развитие окажется
исключительно долговременным и вряд ли может заслуживать наименование интенсивного.
Скорее оно будет экстенсивным, но, вполне возможно, станет застоем и деградацией соответствующего продуктового направления.
Таким образом, компания сталкивается с ситуацией, в которой продукт реализуется
по факту несколькими командами гибких практик, если исходить из общей численности. Мы
не рассматриваем в настоящей книге вопросы адаптации гибких практик к реалиям крупных
компаний – этому посвящены специализированные труды. В настоящем изложении мы констатируем, что современные продуктовые команды насчитывают десятки, а иногда и сотни специалистов самых разных направлений работы. При этом, естественно, команда может содержать
вложенные группы специалистов, концентрирующих свои усилия на реализации тех или иных
архитектурных уровней продукта, например, на канальной логике. И зачастую специалисты,
составляющие продуктовую команду, географически распределены. Это распределение может
быть связано с производственными, финансовыми, технологическими аспектами, но главное
заключается в том, что оно представляет собой реальность для большинства крупных компаний. А если предположить привлечение различных компаний к созданию продукта, например,
организация привлекает подрядчиков к реализации цифровых продуктов и их составляющих,
то организационная распределенность носит и характер корпоративный. Не забываем, что KPI
у сотрудников разных компаний различный и не всегда привязан к продуктам идентичным
образом.
Что же это означает с точки зрения концепции и архитектуры продукта, которым посвящена настоящая книга? Архитектура продукта должна поддерживать согласованную работу
распределенной команды. Данное утверждение означает, что на уровне архитектуры должны
определяться компоненты, которые могут выделенно реализовываться членами команды,
а затем составлять итоговый готовый продукт. При этом компоненты, определяемые в составе
архитектуры продукта, должны допускать реализацию с прозрачным планом по спринтам
в соответствии с гибкими методологиями разработки. То есть уже по итогам одного-двух
спринтов работы над компонентом исполнитель должен предоставлять хотя бы первичные
работоспособные результаты, например, в формате MVP. При этом компоненты должны быть
максимально независимы друг от друга, чтобы обеспечивалась независимая работа членов
66

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

команды и сокращался объем синхронизирующего их «микроменеджмента». Проиллюстрируем это на примере (схематично представлен на Рисунке 20).

Рисунок 20. Пример компонентной структуры продукта
На Рисунке 20 показан пример компонентов продукта – электронной банковской гарантии. Банковская гарантия содержит структуру и описание самого объекта, представляющего
гарантию, заявку на предоставление продукта, формируемую клиентом, объекты и действия,
связанные с процедурой оценки и выставления рейтинга заявке (скоринг). Кроме того, с гарантией должен быть ассоциирован клиент, а также файловые вложения, содержащие, например,
копии документов, необходимых для обеспечения исполнения процессов жизненного цикла
продукта. Сразу оговоримся, что подобное разбиение продукта по составляющим компонентам не является единственно верным, а представлено в настоящей главе исключительно для
примера.
Внимательный читатель незамедлительно поинтересуется структурой каждого компонента, а также самим смыслом разделения продукта на подобные компоненты. Отметим,
что разделение на компоненты имеет своей целью архитектурное разграничение участков
работ над продуктом, позволяющее поддержать согласованную деятельность многочисленных
команд развития. Если же говорить о структуре компонентов, то в общем случае она отвечает структуре всего продукта, но при этом отдельные архитектурные уровни могут быть
не представлены в том или ином компоненте. Наличие или отсутствие архитектурных уровней,
а также их наполнение логикой определяются функциональными требованиями к продукту.
А наполнение уровней с технологической точки зрения в составе компонентов определяется
нефункциональными требованиями к продукту (например, требованиями к производительности и надежности). Ориентируясь на детализацию концептуальной архитектуры продукта,
представленную на Рисунках 18 и 19, мы отмечаем, что в общем случае компоненты продукта
должны содержать уровни канальной и канало-специфичной логики, продуктовой логики
и логики управления бизнес-процессами, интеграционной логики, оперативного и архивного
хранения продуктовых данных.
Если проецировать приведенные выше утверждения на компонентную структуру продукта «Электронная банковская гарантия», схематично представленную на Рисунке 20, то
можно сделать некоторые выводы о ключевых архитектурных требованиях к компонентам:

67

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Компонент «Заявка на банковскую гарантию» должен обладать развитой фронтальной
логикой, а также поддержкой открытых API, поскольку внешние площадки являются ключевым каналом поступления информации.
• Компонент «Скоринг заявки» должен обладать развитой продуктовой логикой и логикой управления бизнес-процессами, при этом для данного компонента исключительно важен
уровень интеграционной логики – зачастую при проведении процесса оценки привлекается
внешняя по отношению к организации информация.
• Для компонента «Вложения к заявке» исключительно важны задачи оперативного
и особенно архивного хранения – как правило, файловые вложения являются весьма объемными и дорогостоящими с точки зрения хранения.
• Компонент «Банковская гарантия» должен обеспечивать исполнение процессов жизненного цикла продукта, а потому важнейшим архитектурным слоем для него является управление бизнес-процессами вкупе с прикладной продуктовой логикой.
• Компонент «Клиент» должен учитывать получение данных клиентов из соответствующих мастер-систем (интеграционная логика) и работу с данными (продуктовая логика и оперативное хранение). Слой архивного хранения не столь критичен, поскольку ИТ-решение
по предоставлению банковских гарантий в общем случае не может считаться мастер-системой
по клиентским данным.
Необходимо подчеркнуть, что вышеприведенный список показывает, какие архитектурные слои находятся в фокусе внимания компонентов, но ни в коем случае не отменяет наличие
остальных архитектурных слоев априори.
Также отметим, что в примере рассматривается продукт именно «электронная»,
а не «цифровая» банковская гарантия, поскольку для последней архитектурное представление
будет во многом отличаться.
Важно указать, что при создании и развитии продукта применяется платформенный подход (на Рисунках 18 и 19 представлены примеры использования платформенных сервисов,
нумерация которых приведена на Рисунке 8). То есть специалисты, реализующие компоненты,
должны обладать знаниями и навыками в части применения платформенных сервисов. И здесь
мы опять приходим к понятию организационной распределенности. Если использование платформы будет технологически сложным, то обеспечить применение платформенного подхода
многочисленной командой продуктовой разработки может оказаться экономически нецелесообразным, так как в этом случае:
• Либо большинство членов команды должны оказаться специалистами высокой квалификации, которые будут в состоянии поддерживать сложное и трудоемкое использование платформы.
• Либо же процесс реализации продукта окажется весьма долговременным с периодами ожидания, пока специалисты, умеющие осуществлять внедрение платформенных вызовов в продуктовую логику, отработают по всем компонентам продукта.
Разумеется, компания не может позволить себе подобные издержки, поэтому обязательным требованием, предъявляемым к современной платформе, оказывается простота ее использования. Мы и в «Архитектуре цифрового мира», и в «Архитектуре цифровых платформ.
От настоящего к будущему» отмечали эту необходимость, которая, в частности, проявляется
во встраивании платформы. Платформенный SDK должен встраиваться в прикладной код
подобно любому стандартному SDK. Платформенные библиотеки не должны принципиально
отличаться в этом плане, например, от Spring Framework, ведь платформа, как мы неоднократно отмечали, является средой создания и исполнения приложений, представляет собой
68

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

фреймворк. Просто данный фреймворк более акцентирован на потребностях конкретной компании, нежели стандартные фреймворки средств разработки.
Касательно использования платформы добавим, что платформенные сервисы должны
предоставлять развитые варианты использования, поддерживать различные топологии развертывания технологий. В идеале желательно такое развитие платформы, чтобы и технологический стек реализации каждого сервиса был представлен не в единственном числе. В противном
случае на продуктовое развитие могут быть наложены необоснованные ограничения. Покажем
это на примере.
Рассмотрим реализацию двух продуктов в организации. Условно, в нашем примере организация представляет финансовую сферу, предоставляет она в качестве продуктов кредитные
продукты и электронные банковские гарантии. Мы в данном случае для упрощения рассматриваем все кредиты и все гарантии в качестве одного продукта, реальные ситуации гораздо
сложнее, зачастую происходит более мелкая грануляция продуктов. И каждый продукт реализуется выделенной продуктовой командой (как уже отмечалось, команды рассматриваются
многочисленные и распределенные). Могут ли в этой ситуации команды использовать принципиально различный технологический стек, как было представлено на Рисунках 16 и 17?
Безусловно, могут. В наш век применения программного обеспечения с открытым исходным
кодом, когда сообщество открытого ПО представляет собой одну из самых больших экосистем в сфере информационных технологий, это более чем возможно. Мы, конечно, критиковали подобный подход с точки зрения финансовой составляющей. Но технологически ничего
невозможного в этом нет. Специалисты команд развития владеют самой разной квалификацией, стоимость указанных квалификаций постоянно меняется в рыночных условиях, поэтому
вполне вероятно, что разные команды сформировались столь непохожим между собой образом в технологическом плане. И внимательный читатель снова готовит очередной провокационный вопрос: «Возможно ли обеспечить подобную ситуацию платформенным подходом,
например, таким, какой был ранее схематично изображен на Рисунке 8?» Мы считаем, что
не только ничего невозможного в этом нет, но и предлагаем читателю разобрать пример, который на самом деле является очевидным для тех, кто внимательно изучил предыдущие труды
автора, а также настоящее изложение.
Итак, мы расширим пример представления платформенных сервисов. Схематично расширенный пример изображен на Рисунке 21. Структура реализаций платформенных сервисов выбрана таким образом, чтобы соответствовать технологическому многообразию, проиллюстрированному ранее на Рисунках 16 и 17.

69

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

В данном примере мы вводим общий платформенный сервис – на Рисунке 21 он так
и обозначен «Платформенный сервис». Задача этого сервиса заключается в экранировании
платформенного приложения, реализующего цифровой продукт, от особенностей реализации
платформы. Почему же возникла необходимость в появлении данного сервиса? Технологическое многообразие, отмечавшееся нами ранее и схематически изображенное на рисунках
16 и 17, во многом является следствием организационной распределенности и многочисленности команд продуктовой разработки. Одним из следствий указанного технологического
70

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

многообразия, представленного ранее в примерах, является возможность использовать различные фреймворки разработки. Мы пойдем дальше и укажем, что при создании продуктов
могут использоваться различные экосистемы разработки. Отметим, что подобное утверждение укладывается в парадигму микросервисной архитектуры – классики данного архитектурного подхода (Мартин Фаулер, Крис Ричардсон и другие) указывали, что поскольку каждый
микросервис в общем случае является независимой единицей развертывания, то может реализовываться на том языке программирования, который наиболее применим для его скорейшей реализации конкретным членом команды, ответственным за данный микросервис. То есть
в предельном случае каждый микросервис может быть реализован на собственном языке программирования. В нашем примере представлены две экосистемы разработки – Java и. NET, два
языка программирования – Java и С#. Отметим, что этими двумя языками программирования
приведенные экосистемы разработки не покрываются полностью, возможны и иные варианты,
но мы рассматриваем пример, а потому выбираем два указанных языка программирования
для упрощения.
Наиболее существенным в нашем примере в контексте экосистем разработки является их
значимое отличие: различные виртуальные машины, используемые библиотеки, разная детализация сборки приложений (при внешнем сходстве) и т. д. И в подобных условиях платформенный подход должен поддерживать весь использующийся инструментарий. Для упрощения же
использования платформы предлагается применять «фасадные» компоненты (мы берем название от шаблона проектирования «Фасад», подробно рассмотренного в книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования», авторы Эрих Гамма,
Ричард Хельм, Ральф Джонсон, Джон Влиссидес), экранирующие пользователей, в качестве
которых выступают в данном случае платформенные приложения, от деталей реализации.
Именно в этой экранизации и состоит важность платформенного сервиса. Он обозначен
на Рисунке 21 как 0. Отметим, что мы рассматриваем концептуальную архитектуру, при дальнейшей же архитектурной детализации и в рамках постановки задач на разработку «Платформенный сервис» совершенно не обязательно будет представлен единой сущностью. Например,
в рамках детализации компонентной архитектуры он может состоять из набора логических сущностей, зачастую имеющих прямое отношение к разрабатываемым физическим сущностям.
На Рисунке 21 он для упрощения показан единой концептуальной сущностью, предоставляющей два типа платформенного SDK клиентам. Предвосхищая потенциальное саркастичное
замечание внимательного читателя о переизбытке сущностей различных типов, отметим, что
здесь все упомянутые сущности являются необходимыми и полностью соответствуют «бритве
Оккама». Подчеркнем, что мы не вводим дополнительно к платформенному SDK платформенный API для упрощения примера.
Конкретные платформенные сервисы в нашем примере, схематично проиллюстрированном Рисунком 21, существенно детализированы и расширены по сравнению с примером, приведенным на Рисунке 8. Детализация основана на компетенциях команд, задействованных при
реализации продуктов (рисунки 16 и 17). Рассмотрим эту детализацию подробнее.
• Первым из платформенных сервисов на Рисунке 21 представлен сервис работы с данными (сервис 1), посредством которого унифицируются операции с данными. Он содержит
четыре реализации:
○ Сервис работы с реляционными данными (1.1), используемый для работы с данными,
хранящимися в реляционных СУБД, представленный единственной технологической реализацией 1.1.1 – на основе СУБД PostgreSQL.
○ Сервис работы с нереляционными данными (1.2), используемый для работы с данными, которые, например, ввиду требований к обеспечению эластичного масштабирования,
71

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

хранятся в нереляционных СУБД. Данный сервис содержит две технологические реализации –
на основе СУБД Apache Cassandra (1.2.1) и ScyllaDB (1.2.2).
○ Сервис работы с данными, хранящимися в распределенной файловой системе (1.3).
Данный сервис может быть востребован, в частности, при реализации технологий архивного
хранения либо распределенного хранения документов. Он представлен двумя технологическими реализациями – на основе Apache Hadoop (1.3.1) и S3, например, Ceph или MinIO
(1.3.2).
○ Сервис работы с кэширующими технологиями (1.4), обеспечивающий высокопроизводительные операции с данными в оперативной памяти. Он представлен двумя технологическими реализациями – на основе Apache Ignite (1.4.1) и Infinispan (1.4.2).
• Для обеспечения взаимодействия компонентов ИТ-решения между собой в парадигме событийно-ориентированной архитектуры используется платформенный сервис потоковой передачи данных (2). Данный сервис в своей работе задействует возможности платформенного сервиса работы с данными (1). При этом использование сервиса 1 происходит неявно
для пользователя – платформенного приложения. Сервис 2 содержит две реализации:
○ Сервис работы с журнальной потоковой передачей информации (2.1), представленный
в примере единственной технологической реализацией – на основе программного обеспечения
Apache Kafka (2.1.1).
○ Сервис работы с потоковой передачей информации (2.2), представленный в примере
единственной технологической реализацией – на основе программного обеспечения Apache
Pulsar (2.2.1).
• Для предоставления открытых API, например, в целях создания на основе продукта
организации партнерских приложений, продуктовыми командами используется платформенный сервис 3 – сервис управления открытыми API. Данный сервис содержит две технические
реализации на основании популярных программных продуктов с открытым исходным кодом:
○ Реализация на основе программного продукта WSO2 (3.1).
○ Реализация на основе программного продукта Gravitee (3.2).
• Продуктовая логика предполагает управление процессами жизненного цикла продукта,
а потому нуждается в развитых методиках управления. Помогает в этом продуктовым командам платформенный сервис управления бизнес-процессами (4), содержащий две реализации:
○ Сервис централизованного управления бизнес-процессами в соответствии с шаблоном оркестровки (4.1), представленный двумя технологическими реализациями – на базе программного обеспечения Camunda (4.1.1) и Kogito (4.1.2).
○ Сервис децентрализованного управления бизнес-процессами в соответствии с шаблоном хореографии (4.2), представленный двумя технологическими реализациями – на базе
программного обеспечения Camunda (4.2.1) и Kogito (4.2.2).
Подчеркнем, что конкретные технологии приведены исключительно для примера. Указание этих технологий вовсе не означает, что платформенный сервис представляет собой либо
просто развернутую технологию, либо всего лишь проксирует ее API. В реальности платформенный сервис, как мы уже неоднократно отмечали, представляет собой сложную сущность,
содержащую не только технологии, но и топологии их развертывания, варианты использования, методики масштабирования, надежности и многое другое.
Вышеприведенное описание платформенных сервисов позволяет наглядно проиллюстрировать их применение в рассматриваемом нами примере создания двух цифровых финансовых продуктов, реализуемых командами с различными компетенциями. Схематично применение платформенного подхода и конкретных платформенных сервисов представлено
на Рисунках 22 и 23. Данные рисунки в значительной степени основываются на Рисунках
16 и 17, а также на детализации платформенных сервисов, приведенной на Рисунке 21.
72

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Для удобства восприятия использование платформенного сервиса 0 не показано, при этом
в реальности он задействован при предоставлении всех остальных платформенных сервисов потребителям. Для обозначения продукта электронной банковской гарантии на Рисунках
22 и 23 используется сокращение-аббревиатура ЭБГ.

Рисунок 22. Пример применения платформенного подхода при реализации двух продуктов (часть 1)

73

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 23. Пример применения платформенного подхода
при реализации двух продуктов (часть 2)
На Рисунках 22 и 23 представлено соответствие между продуктами (кредитный продукт
и электронная банковская гарантия), используемыми продуктовыми командами технологиями
(обозначены собственными логотипами) и платформенными сервисами (идентифицированы
двойной нумерацией – номер применяемого платформенного сервиса и номер конкретной
технологической реализации). Как можно видеть из рисунка, платформенный подход в данном примере обеспечивает гибкость, позволяя использовать унифицированные платформенные сервисы с различной реализацией, максимально удовлетворяющей потребностям команд.
В свою очередь потребности определяются, как мы отмечали выше, наличием в продуктовых
командах соответствующих компетенций. Основываясь на приведенной в примере структуре
платформенных сервисов и командных компетенциях, можно сделать следующие заключения:
• На уровне фронтальной и канальной логики обоими продуктами используются платформенные сервисы работы с данными в части реляционных СУБД и кэширующих компонен74

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

тов, при этом команда кредитного продукта использует реализации 1.1.1 и 1.4.2, а команда
электронных банковских гарантий – 1.1.1 и 1.4.1. Обе продуктовые команды применяют
на данном уровне платформенный сервис потоковой передачи данных 2: команда кредитного
продукта использует реализацию 2.2.1, команда электронных банковских гарантий – 2.1.1.
Кроме этого, продуктовыми командами используется сервис управления открытыми API 3 –
3.1 и 3.2 в части технологических реализаций соответственно.
• На архитектурном уровне канало-специфичной логики продуктовыми командами
используется платформенный сервис потоковой передачи данных 2: командой кредитного продукта 2.2.1, а командой электронных банковских гарантий 2.1.1 в части технологической реализации.
• На уровне хранения продуктовых данных командами применяются платформенные
сервисы работы с данными в части поддержки реляционных СУБД и кэширующих компонентов, а также сервисы потоковой передачи данных. Технологические реализации соответствуют
указанным для слоя фронтальной и канальной логики, при этом топологии и варианты использования сервисов могут быть отличными от применяемых на рассмотренном в предыдущем
пункте архитектурном уровне.
• На уровне продуктовой логики команды используют платформенный сервис работы
с данными только лишь в части поддержки реляционных СУБД (технологическая реализация
1.1.1), платформенный сервис потоковой передачи данных с технологическими реализациями
2.2.1 для кредитного продукта и 2.1.1 для электронных банковских гарантий, а также платформенный сервис управления бизнес-процессами. Обе продуктовые команды используют шаблоны как оркестровки, так и хореографии, поэтому для кредитного продукта применяются
технологические реализации 4.1.1 и 4.2.1, для электронных банковских гарантий 4.1.2 и 4.2.2.
• На уровне интеграционной логики для автоматизации представленных в нашем примере продуктов используются платформенные сервисы работы с данными в части управления
нереляционным хранением информации: для кредитного продукта применяется технологическая реализация 1.2.2, для электронной банковской гарантии 1.2.1. Для поддержки высокоэффективной работы с данными в оперативной памяти используются реализации сервиса работы
с кэш 1.4.2 и 1.4.1 соответственно. В части применения платформенного сервиса потоковой
передачи данных задействованы реализации, аналогичные представленным выше для рассматриваемых цифровых продуктов.
• Для эффективной имплементации архитектурного уровня архивного хранения продуктовых данных используется платформенный сервис работы с данными в реализации работы
с распределенной файловой системой. Команда развития кредитного продукта применяет технологическую реализацию 1.3.2, команда развития электронных банковских гарантий – 1.3.1.
Отметим, что наличие общих платформенных сервисов, поддерживающих наборы технологических реализаций, позволяет заложить на уровне платформы общие варианты использования и/или стандартизированные компоненты для всех поддерживаемых реализаций либо
их подмножества.
Из представленного выше рассмотрения следует, что продукты и продуктовые команды
являются источниками требований к платформе, например, в части расширения поддержки
технологических реализаций платформенных сервисов. Важно отметить, что каждый из платформенных сервисов может быть расширен набором реализаций на каждом из представленных на Рисунке 21 уровней иерархии. Разумеется, платформенные сервисы предоставляют
потребителям не просто технологические реализации, но и варианты их использования.
При этом компонентная структура продукта (см. Рисунок 20) позволяет членам продуктовых команд при необходимости использовать платформенные сервисы в каждом компоненте
75

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

цифрового продукта. Проиллюстрируем это примером для продукта электронных банковских
гарантий. Схематично пример приведен на Рисунке 24.

Рисунок 24. Использование платформенных сервисов
продуктовыми компонентами
На Рисунке 24 представлены ранее выделенные для примера компоненты продукта, им
сопоставлено использование платформенных сервисов в соответствии с ключевыми характеристиками, приводившимися для компонентов продукта выше. Разумеется, это не исключает
потенциально более широкого применения платформенного подхода при создании и развитии
компонентов, но здесь мы ограничиваем его ранее выделенными ключевыми характеристиками с целью избежать избыточного усложнения. Рассмотрим их подробнее:
• Компонент «Заявка на банковскую гарантию» обладает развитой фронтальной логикой,
а также предоставляет открытые API партнерам компании для создания экосистемы на базе
продукта. Поэтому при реализации данного компонента используются платформенные сервисы работы с данными в части поддержки реляционных СУБД и кэширования, сервис потоковой передачи данных, а также сервис управления открытыми API. Конкретные технологические реализации сервисов соответствуют ранее приведенным для продукта «Электронные
банковские гарантии».
• Компонент «Скоринг заявки» обладает развитой продуктовой логикой, а также поддерживает управление бизнес-процессами. Одновременно с этим на уровне компонента поддерживается реализация архитектурного уровня интеграционной логики, потому что, как рассматривалось ранее, для имплементации задач компонента может потребоваться информация,
мастер-системы по которой являются внешними по отношению к продуктовому ИТ-решению.
Таким образом, компонент использует платформенный сервис работы с данными, поддерживая реляционное, нереляционное хранение данных, а также работу с кэширующими компонентами. Кроме того, применяется платформенный сервис потоковой передачи данных. Для
управления бизнес-процессами используется платформенный сервис управления бизнес-процессами с поддержкой реализации шаблонов как оркестровки, так и хореографии.
• В рамках реализации компонента «Вложения к заявке» ввиду исключительной важности задач оперативного и архивного хранения используются платформенные сервисы работы
с данными в части поддержки хранения данных в реляционных СУБД, распределенной файловой системе и в кэш. Также применяется платформенный сервис потоковой передачи данных.
• Компонент «Банковская гарантия» обеспечивает исполнение процессов жизненного
цикла продукта, а потому важнейшим архитектурным слоем для него является управление биз76

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

нес-процессами вместе с прикладной продуктовой логикой. Ввиду всего вышеперечисленного
при реализации компонента используются платформенный сервис работы с данными в части
поддержки реляционных СУБД, сервис потоковой передачи данных, сервис управления бизнес-процессами с поддержкой оркестровки и хореографии.
• Компонент «Клиент» в своей реализации учитывает получение данных клиентов
из соответствующих мастер-систем (интеграционная логика) и работу с данными (продуктовая логика и оперативное хранение). Поэтому для реализации рассматриваемого компонента
используются платформенные сервисы работы с данными (технологические имплементации
поддержки реляционных и нереляционных СУБД, а также кэш) и сервис потоковой передачи
данных. Технологическая реализация сервиса работы с данными в части поддержки распределенной файловой системы в компоненте не используется, поскольку, как отмечалось ранее
по ходу настоящего раздела, слой архивного хранения не столь критичен для работы с клиентскими данными.
Отметим, что при имплементации каждого компонента могут использоваться различные топологии платформенных сервисов (даже при применении одних и тех же сервисов и их
реализаций), также могут быть существенные отличия в их вариантах использования. Как
следствие, платформа должна обладать гибкостью для поддержки всех требований компонентов, входящих в состав продукта. Представленный нами пример наглядно демонстрирует, что
продукты являются источниками развития платформы, предъявляя требования по наличию
платформенных сервисов, их технологических реализаций, а также по вариантам использования. В случае отсутствия в составе платформы требуемой функциональности продуктовая
команда может ее разработать и по прозрачным правилам добавить в платформу, сделав свои
дополнения доступными к использованию всеми потребителями платформы. В роли последних выступают продуктовые команды. Таким образом свойство открытости современной платформы позволяет продуктовым командам не ограничиваться жестко очерченным платформенным функционалом.
Внимательный читатель уже подготовил каверзный вопрос: «Представленный пример
продуктовой разработки на базе платформы выглядит избыточно тяжеловесным: платформу
необходимо реализовывать долгое время, поддерживать множество реализаций сервисов, все
это стоит больших денег. Ранее уважаемый автор постоянно говорил о технологической и топологической унификации. Нет ли здесь противоречий с предыдущими книгами и есть ли вообще
смысл в такой платформе и подобном подходе?» Мы со своей стороны поблагодарим читателя
за своевременный злободневный вопрос и постараемся развеять его опасения.
В книге «Архитектура цифровых платформ. От настоящего к будущему» мы отмечали,
что совершенно необязательно ожидать реализации всей платформы целиком для начала продуктовой разработки. Необходимо определить (и архитектор, являясь лидером технологических изменений, должен играть в этом определении ключевую роль) то ядро платформы,
которое позволит запустить продуктовую разработку и впоследствии распараллелить развитие
платформы и продуктов на ее основе. По мере повышения зрелости платформы в дело вступает такое свойство современных цифровых платформ, как открытость: продуктовые команды
вносят требуемые им изменения в платформу, при этом публикуют их таким образом, чтобы
они были доступны всем остальным командам. То есть у платформы есть собственный жизненный цикл, она является постоянно развивающимся живым организмом. В представленном выше примере необязательно создавать все сервисы и их технологические реализации
заранее. Например, платформа может содержать технологическую реализацию сервиса работы
с нереляционными СУБД на базе программного обеспечения Apache Cassandra, и эта реализация будет использоваться продуктом электронных банковских гарантий. При проектировании кредитного продукта и формировании команды его реализации принимается решение
77

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

использовать на соответствующем архитектурном слое распределенную СУБД ScyllaDB. Соответствующее расширение профильного платформенного сервиса может осуществить платформенная команда, если в организации еще не стерлась грань между платформенными и продуктовыми командами, а может и продуктовая. Как мы отмечали в предыдущих трудах, платформе
должен быть сопоставлен набор методик не только по ее использованию, но и по ее развитию. Продуктовая команда реализует расширение соответствующего платформенного сервиса
на предмет поддержки требуемой технологической реализации и публикует данное расширение в общую платформенную структуру. В последующем другие продуктовые команды могут
выбирать из двух реализаций сервиса либо добавлять собственный. Основания для выбора
могут быть самые различные: наличие компетенций, требования по масштабируемости, имеющиеся наработки и т. д. С технологической точки зрения важно лишь то, чтобы архитектура платформы поддерживала соответствующее расширение, а процесс публикации дополнений был выстроен прозрачным образом, снижающим до минимума возникновение ошибок
при дополнении платформенного функционала (полностью исключить возникновение ошибок
принципиально невозможно).
Таким образом, указанный подход обеспечивает технологическую унификацию: использование платформенных сервисов является унифицированным, платформа предоставляет развернутые описания вариантов использования платформенных сервисов, технологии, ассоциированные с сервисами, являются закрепленными на каждом конкретном этапе развития как
платформы, так и платформенных приложений, расширение технологического базиса диктуется требованиями, возникающими у продуктовых команд, а зачастую ими и реализуется.
Но вопрос читателя содержал и финансовую сторону, которая также является немаловажной.
Представленная на Рисунке 21 архитектура платформы (в данном случае имеет смысл
говорить о концептуальной архитектуре) является достаточно разнообразной технологически, а создание и поддержка большого количества технологий, топологий их развертывания,
наборов вариантов использования в свою очередь требуют серьезных временных, трудовых
и финансовых ресурсов. И если выше мы описали потенциальное распределение привлечения трудовых ресурсов на реализацию компонентов платформы во времени, то финансовая
сторона нами пока не освещена. А детально ее прояснить мы и не сможем, поскольку не разбираем в настоящем изложении примеры конкретных компаний и их платформ и продуктов.
Но можем обрисовать общие направляющие формирования финансовой оценки технологического разнообразия на уровне платформы:
• Чем большее число технологических реализаций сервисов поддерживается на уровне
платформы, тем более гибкой оказывается поддержка продуктовых ИТ-решений со стороны
платформы. При создании и развитии цифрового продукта становится возможным выбирать те
технологические реализации платформенных сервисов и компонентов, которые оказываются
выгоднее в том числе с финансовой точки зрения.
• Следует понимать, что одновременно с этим расширение множества технологических
реализаций платформенных сервисов повышает стоимость платформы, причем в части как
создания, так и развития и сопровождения.
• Размывание границ между платформенными и продуктовыми командами позволяет
переложить часть финансовых затрат по развитию платформы на продуктовые команды и учитывать в P&L продуктов (для продуктов с благоприятными рыночными перспективами подобный подход может оказаться вполне приемлемым).
• Публикация дополнений в платформу, осуществляемых продуктовыми командами,
позволяет переиспользовать удачные наработки, сокращая общую стоимость владения платформой в организации и повышая эффективность создания и развития новых продуктов
с использованием платформенного подхода.
78

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Множество поддерживаемых платформой технологических реализаций позволяет формировать продуктовые команды таким образом, чтобы снижать стоимость указанных команд
как в части снижения требований к компетенциям их членов (ввиду реализации трудоемких
инфраструктурных задач на уровне платформы), так и в части набора специалистов с более
дешевым техническим бэкграундом, если последний поддерживается на уровне платформы.
Данный подход также положительно влияет на P&L продукта.
Современная компания, ориентирующаяся на создание ценности для клиентов и партнеров, должна учитывать эти факторы при формировании финансовой модели и планировании
развития платформы и продуктов на ее основе. Конкретные примеры расчета соответствующих финансовых моделей выходят за рамки настоящей книги.
Таким образом, современная архитектура продуктов, подкрепленная платформенным
подходом, позволяет эффективно поддерживать работу распределенных команд. Притом поддерживается как работа распределенных команд над одним продуктом, так и распределенная
работа множества команд над множеством продуктов, что характерно для современной организации, ставящей себе целью интенсивное развитие в окружающем нас цифровом мире.
На этом мы завершаем рассмотрение организационной распределенности как одного
из ключевых трендов развития архитектуры и переходим к распределенности технологической.
Современные технологии изменяют мир таким образом, что получение доступа к цифровым продуктам становится возможным в любой точке земного шара, причем практически мгновенно. Современный цифровой мир является миром дистанционных каналов, что
в огромном количестве случаев стирает различия между крупными и мелкими компаниями
в части доступности их продуктов и услуг для клиентов и партнеров. Например, если 15 лет
назад исключительно принципиальным при выборе финансовой организации для обслуживания было количество точек присутствия (отделений, банкоматов и т. д.) даже на уровне конкретного региона, то на сегодня данный параметр не является столь существенным в части
доступности для клиентов и уступил свое место в списке приоритетов качеству предоставляемых организацией продуктов и их удобству с точки зрения конкретного клиента.
Однако у каждой медали есть обратная сторона. Современный продукт должен быть доступен
посредством дистанционных каналов в режиме 24х7, обеспечивать соответствующий уровень
непрерывности, производительности и надежности. И это предъявляет серьезные требования
к архитектуре продукта. Архитектура продукта должна быть распределенной – поддерживать
распределенное предоставление и исполнение продукта.
Поскольку мы рассматриваем архитектуру обобщенного продукта без свойственной различным организациям конкретики, то для примера возьмем уже обсуждавшийся выше продукт – электронную банковскую гарантию. Детализация концептуальной архитектуры данного
продукта представлена на Рисунках 25 и 26.

79

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 25. Детализация концептуальной архитектуры продукта «Электронная банковская гарантия» (часть 1)

80

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 26. Детализация концептуальной архитектуры
продукта «Электронная банковская гарантия» (часть 2)
81

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

На Рисунках 25 и 26 изображена архитектура продукта с указанием используемых при
его создании и развитии платформенных сервисов и их технологических реализаций. Мы уже
неоднократно отмечали, что архитектура продукта состоит из набора слоев (в настоящем изложении с целью упрощения показано их подмножество). И все архитектурные слои в ходе своей
реализации должны обеспечивать поддержку технологической распределенности. Последовательно по слоям рассмотрим, каким образом это может быть достигнуто:
• Уровень фронтального и канального представления должен обеспечивать высокую
производительность фронтального слоя цифрового продукта во всех поддерживаемых каналах, надежность предоставления продукта посредством каналов, а также бесшовное расширение числа каналов обслуживания при развитии продукта. Отдельно отметим, что бесшовное
выполнение операций во всех поддерживаемых каналах достигается посредством омниканальности, что будет рассмотрено в соответствующем разделе настоящей главы, посвященном связанным тенденциям развития архитектуры. Исходя из вышесказанного, фронтальная логика
должна реализовываться с использованием легковесных фреймворков (на Рисунке 25 для
примера представлен Angular), при этом должна обеспечиваться модульность создаваемого
визуального представления. Одним из вариантов последнего может служить архитектура микрофронтендов, следование которой также будет рассмотрено в настоящей главе в разделе,
посвященном связанным тенденциям развития архитектуры. Синхронизированная с логикой представления прикладная логика фронтального уровня должна реализовываться в распределенной парадигме, например, в микросервисной архитектуре, как показано на Рисунке
25. В этом случае становится возможным гибко обеспечивать масштабирование компонентов логики под требования производительности, предъявляемые дистанционными каналами
обслуживания, а также поддерживать достаточное количество экземпляров инстанциируемых
компонентов для обеспечения требуемого уровня надежности. Но недостаточно просто обеспечивать исполнение логики. Современные архитектурные принципы диктуют, что компоненты реализации логики не должны сохранять своего состояния (быть stateless). В таком
случае по ходу собственного исполнения они вынуждены осуществлять огромное количество операций запросов к данным, что оказывает крайне негативное влияние на производительность всего продуктового ИТ-решения. Для ускорения выполнения подобных операций
в нашем примере используется компонент кэширования, для которого приведен пример технологии, лежащей в его основе, – Apache Ignite. Для обеспечения поддержки распределенности
цифрового продукта применяемая технология и ее топология должны поддерживать распределенное исполнение и эластичное масштабирование. Аналогичные требования предъявляются и к программному обеспечению событийного обмена, использующемуся в нашем примере для обеспечения взаимодействия компонентов уровня фронтальной и канальной логики
с компонентами, принадлежащими к смежным архитектурным слоям. Для примера на Рисунках 25 и 26 приводится программное обеспечение Apache Kafka.
• Уровень канало-специфичной логики должен обеспечивать реализацию прикладной
логики, применимой лишь для конкретного канала обслуживания. Например, для рассматриваемого продукта электронной банковской гарантии размер обеспечения может зависеть
от площадки поступления заявки на гарантию. Естественно, в наш век дистанционных каналов данная логика также должна обеспечивать свое эффективное выполнение в самых разных вариантах использования цифрового продукта, в том числе при пиковых возрастаниях
нагрузки. В нашем примере она реализуется в парадигме микросервисной архитектуры,
в результате чего возможно обеспечение эластичного масштабирования соответствующих компонентов при изменениях нагрузки. Разумеется, для поддержки масштабирования необходимы также комплексные средства управления инфраструктурой, однако их рассмотрение
82

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

выходит за рамки настоящего изложения. Также отметим, что в рассматриваемом примере
для обеспечения взаимодействия решений данного архитектурного слоя со смежными слоями
используется программное обеспечение событийного обмена. К указанному программному
обеспечению также предъявляются перечисленные выше требования по поддержке распределенности. В нашем примере используется ПО Apache Kafka, удовлетворяющее данным требованиям.
• Уровень хранения продуктовых данных исключительно важен с точки зрения поддержки продуктом технологической распределенности: скорость и объемы поступающих данных постоянно возрастают в условиях доступности продукта в режиме 24х7, при этом работа
с продуктовыми данными оказывает определяющее влияние на непрерывность функционирования продуктового ИТ-решения. В связи с этим элементы хранения должны поддерживать
свойство распределенности как в части долговременного хранения (в рассматриваемом примере используется реляционная СУБД), так и в части высокоскоростного хранения и проведения операций (в примере используются компоненты кэширования). Также на данном слое
используются компоненты логики, обычно реализуемые на языках программирования высокого уровня. Мы не отображаем указанные компоненты на Рисунке 25 для сохранения удобства восприятия. Компоненты логики работы с данными, долговременного и быстрого хранения должны обеспечивать поддержку распределенности независимо друг от друга, при этом
их работа в одном продуктовом решении должна быть согласованной. При реализации современных продуктов это достигается применением платформенного подхода и использованием
платформенных сервисов и их технологических реализаций, которые адекватны требованиям,
предъявляемым к конкретному продукту (в нашем случае – электронной банковской гарантии). В примере на Рисунке 25 в качестве технологических реализаций приведены СУБД
PostgreSQL и IMDB/IMDG решение Apache Ignite для долговременного хранения и операций
в оперативной памяти соответственно. Как и на предшествующих архитектурных слоях, реализация взаимодействия компонентов осуществляется с помощью программного обеспечения
событийного обмена, в качестве примера которого приведено ПО Apache Kafka, удовлетворяющее требованиям по технологической распределенности.
• Продуктовая логика на соответствующем архитектурном слое реализуется с использованием технологий, обеспечивающих поддержку распределенности – в примере, приведенном
на Рисунке 26, используется язык программирования Java (как и для смежных архитектурных
уровней) с реализацией компонентов логики в парадигме микросервисной архитектуры. Данный подход позволяет обеспечить масштабирование компонентов при изменениях нагрузки,
а также их резервирование, в том числе географически распределенное. Однако для эффективной реализации развитой продуктовой логики этого оказывается недостаточно, потому
что бизнес-процессы изменяются очень часто ввиду требований бизнеса, регуляторных изменений, появления новых клиентских потребностей, привлекать же для каждого изменения
дорогостоящих разработчиков оказывается экономически неоправданно. Поэтому большинство современных компаний, ведущих интенсивное развитие своих продуктов, используют
движки управления бизнес-процессами – BPM-движки. Последние предоставляют широкие
возможности минимизации разработки программного кода при изменении бизнес-процессов
благодаря наличию в них развитых инструментов графического моделирования. На Рисунке
26 в качестве примера технологической реализации (как мы помним, управление бизнес-процессами также представляет собой платформенный сервис), используемой при имплементации соответствующего архитектурного слоя, указан BPM Kogito. И требования к использованию BPM-движка на сегодня также содержат необходимость поддержки распределенности,
включая репликацию состояния между экземплярами движка, репликацию состояния экземпляров бизнес-процессов, а также эффективную реализацию шаблонов оркестровки и хореографии. Последнее особенно важно, поскольку в распределенной среде и в условиях серьез83

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ных колебаний нагрузки на продуктовое ИТ-решение нередко децентрализованное управление
продуктовыми процессами оказывается единственно приемлемым. При этом необходимо обеспечивать хранение как контекста процесса, так и управляющих данных экземпляров бизнес-процессов, для чего в примере, схематически представленном на Рисунке 26, приведено
использование сервиса работы с данными в технологической реализации реляционной СУБД.
Последняя также должна поддерживать распределенность. По аналогии с остальными архитектурными слоями в примере на Рисунке 26 приведено использование программного обеспечения событийного обмена с применением платформенного сервиса и технологической реализации на базе ПО Apache Kafka.
• При реализации слоя интеграционной логики возникает необходимость распределенного хранения данных, задействованных в интеграционных обменах, с использованием соответствующих технологий. На примере, приведенном на Рисунке 26, для решения указанной
задачи применяется платформенный сервис работы с данными с поддержкой нереляционных
СУБД и технологической реализацией с использованием СУБД Apache Cassandra.
• Архивное хранение исключительно важно в условиях поддержки распределенности.
Зачастую хранение архивных данных изначально отделено от остальных уровней реализации продуктового ИТ-решения и осуществляется распределенно по отношению к остальным
архитектурным слоям. При этом выполняется его независимое масштабирование, а иногда
и использование: например, логика работы с архивными данными может быть принципиально
отлична от логики работы с данными оперативными при исполнении общей продуктовой
логики. Примером подобного подхода может служить отработка финансовыми организациями
запросов контролирующих или правоохранительных органов, касающихся архивной информации. Поэтому рассматриваемый архитектурный уровень также должен поддерживать распределенность. На примере, приведенном на Рисунке 26, для этого используется платформенный
сервис работы с данными, хранящимися с применением распределенной файловой системы,
в технологической реализации на основе программного обеспечения Apache Hadoop.
Важно отметить, что только использованием общего программного обеспечения поддержка технологической распределенности не достигается. На разных слоях к продуктам
предъявляются разные требования, соответственно, и к платформенным сервисам и их технологическим реализациям также могут предъявляться различные требования. Исходя из этого,
на уровне архитектуры должны быть предусмотрены наборы вариантов использования для
сервисов и технологий их реализации. Аналогичным образом различные требования могут
предъявляться и в контексте различных продуктов. Например, требования к платформенным
сервисам, предъявляемые кредитными и гарантийными продуктами, могут принципиально
отличаться. Отличия могут основываться на каналах предоставления продуктов, жизненных
циклах цифровых продуктов и их проекции на бизнес-процессы, регуляторных ограничениях
и т. д.
Необходимо подчеркнуть, что технологическая распределенность должна поддерживаться и на уровне платформы, что подробно рассмотрено в предыдущей книге автора «Архитектура цифровых платформ. От настоящего к будущему».
Отдельно следует остановиться на дополнительном рассмотрении вопроса поддержки
технологической распределенности в условиях применения платформенного подхода при реализации цифровых продуктов. И по ходу предыдущих книг, и по ходу настоящего изложения
мы не раз отмечали, что просто развертывание программного обеспечения, поддерживающего
распределенность (например, Apache Ignite или Apache Kafka), не гарантирует распределенность создаваемых нами программных комплексов. Это утверждение касается как платформы,
так и продуктов, разрабатываемых с использованием платформы. Логичным следствием данного факта является то, что при реализации платформы необходимо обеспечивать поддержку
84

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

85

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровые продукты и бизнес-процессы
Увидев название настоящего раздела, внимательный читатель, ранее изучивший предыдущие труды автора («Архитектура цифрового мира» и «Архитектура цифровых платформ.
От настоящего к будущему»), воскликнет с удивлением: «Вот прочитал я две книги, по ходу
настоящего изложения также неоднократно повторялось, что необходимо изменять мышление как на уровне отдельных сотрудников, так и целых организаций, уходить от процессного
мышления к продуктовому. А тут опять какие-то бизнес-процессы, зачем это?» Мы понимаем вполне законные вопросы, возникшие у читателя, а потому постараемся как можно скорее обосновать связь между бизнес-процессами и продуктовым подходом. Также не останется
нераскрытым применение платформенного подхода. Но начнем с небольшого введения, в котором еще раз напомним читателю важность бизнес-процессов как ключевого тренда развития
архитектуры.
В настоящее время на рынке можно наблюдать самые разные компании: часть из них
являются стартапами, часть только проходят трансформацию из начинающей организации
в развитую корпоративную структуру, кто-то уже присутствует на рынке значительный промежуток времени. Но всех их объединяет несколько факторов, важных для нас с точки зрения
проблематики, рассматриваемой в текущем разделе: все компании безусловно заинтересованы
в собственной конкурентоспособности, конкурентоспособность, в свою очередь, невозможна
без присутствия компании и ее продуктов (а ведь именно они несут ценность для клиентов
и партнеров) в режиме онлайн. В то же время обеспечение режима онлайн предполагает наличие развитого ИТ-ландшафта в организации. А развитость ИТ-ландшафта диктуется необходимостью поддерживать его функционирование в режиме 24х7, обязательное в современном
цифровом мире. Чем же характеризуется развитый ИТ-ландшафт с точки зрения современной
архитектуры?
ИТ-ландшафт становится развитым после прохождения продуктовой трансформации:
перехода от монолитных систем, возможно, объединенных с использованием практик SOA,
к продуктовым ИТ-решениям. Если мы говорим о стартапах, то они могут, учитывая накопленный сферой информационных технологий опыт, сразу с момента начала своей деятельности создавать продуктовые ИТ-решения. Корпорации с длительной историей, как правило,
осуществляют не одну трансформацию по ходу своего развития. Результатом продолжительного развития становится в том числе набор бизнес-процессов, описывающих деятельность
компании. И, в зависимости от того, осуществила ли компания продуктовую трансформацию,
бизнес-процессы в большей или меньшей степени ориентированы на конкретные продукты.
В общем случае возможны различные ситуации с описанием и автоматизацией бизнес-процессов в организации:
• В компании может существовать описание бизнес-процессов в виде методологического
документа, при этом автоматизация в минимальной степени учитывает указанное описание.
• Бизнес-процессы могут быть как описаны в формате методологических документов, так
и автоматизированы с использованием возможностей информационных систем, содержащихся
в ИТ-ландшафте организации, при этом подобные информационные системы могут принадлежать к различным архитектурным и технологическим поколениям, а потому не учитывать
специфику современной продуктовой разработки.
• Автоматизация бизнес-процессов может осуществляться с использованием выделенного движка управления бизнес-процессами (BPM-движка), при этом учет специфики продуктовой разработки может как присутствовать, так и отсутствовать.
86

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Что же представляет собой неоднократно упомянутая выше специфика продуктовой разработки, столь важная с точки зрения автоматизации бизнес-процессов? По ходу предыдущих
книг мы уже отмечали один важный аспект, позволяющий утверждать, что организация ушла
от ограничений, накладываемых унаследованным ИТ-ландшафтом, и перешла к созданию продуктовых ИТ-решений. Данный аспект заключается в том, что организация на уровне своего
мировоззрения признает тот факт, что термин «информационная система» устарел. В организации, осуществившей продуктовую трансформацию, приведенный термин может использоваться только для унаследованных программных комплексов либо вследствие каких-либо
внешних ограничений, например, регуляторных. Рассмотрим, каковы же фундаментальные
причины отказа от данного термина.
Классическое назначение информационных систем, например периода SOA, заключалось в исполнении однотипных функций. Примером такого унифицированного исполнения
операций могут служить учетные системы. В финансовом секторе за ними закрепилось наименование автоматизированных банковских систем (АБС). При этом термин АБС традиционно
относился к автоматизации функций главной бухгалтерской книги. Данное уточнение широко
используемого термина мы обязаны привести, поскольку в общем случае любая система, задействованная в автоматизации банковского сектора, по сути является автоматизированной банковской системой. В различных организациях АБС зачастую нагружались несвойственным
им функционалом, при этом задачи синтетического учета всегда оставались в их составе.
Все финансовые продукты предоставляли информацию по проводимым операциям для осуществления и регистрации синтетических проводок, связанных с ними. Продукты ставились
на баланс, над ними проводились групповые операции и т. д. Но ключевым элементом функционирования АБС была проводка, а не конкретный продукт. В АБС велись депозиты, кредиты,
накопительные счета и все другие продукты финансовой организации. С АБС осуществлялось
множество интеграций, в которых были задействованы другие корпоративные системы. Однако
современная архитектура размещает в центре внимания продукты, а не конкретные подмножества действий над ними (важен результат, а не процесс). И синтетический учет должен быть
привязан к создаваемым и развиваемым продуктам. Рынок предъявляет жесточайшие требования в части показателя времени вывода продуктов на рынок (time-to-market), и продуктовое
ИТ-решение не может ожидать длительные периоды релизных циклов унаследованных систем,
таких как АБС (особенно если последние перегружены еще и несвойственным им функционалом, например, частных бухгалтерских книг или рассматриваемых нами в настоящем разделе
бизнес-процессов).
В сложившейся ситуации мы с необходимостью приходим к тому, что end-to-end продукт должен содержать в своем составе все связанные с ним операции, при этом продуктовое ИТ-решение в структуре реализации своих архитектурных слоев должно минимальным
образом зависеть (а лучше вообще не зависеть) от внешних по отношению к нему решений.
Что же это означает для информационных систем, таких как АБС? Информационные системы
могут характеризовать те или иные уровни автоматизации, но они обязательно должны быть
сегментированы в соответствии с продуктами. Их архитектура должна быть принципиально
пересмотрена и перестроена в соответствии с продуктовой логикой организации. В противном
случае полноценная продуктовая трансформация попросту невозможна. Добавим также, что
на всех архитектурных уровнях должен применяться современный платформенный подход,
поскольку он позволяет принципиально сократить издержки на создание, развитие и сопровождение продуктовых ИТ-решений.
Приведенные выше требования, выдвигаемые продуктовой трансформацией, оказывают
значительное влияние и на автоматизацию бизнес-процессов в организации. Современная
автоматизация бизнес-процессов также должна быть акцентирована на продуктах компании,
87

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

Рисунок 27. Корпоративный ИТ-ландшафт по итогам
продуктовой трансформации
Рисунок 27 иллюстрирует результат перехода корпоративного ИТ-ландшафта компании
к продуктовой организации. На этом рисунке каждый продукт представлен в виде набора
архитектурных уровней, при этом для упрощения восприятия количество уровней сокращено
по сравнению с предыдущими примерами. Подчеркнем, что в настоящем примере показана
унифицированная продуктовая архитектура, в реальной ситуации реализация всех архитектурных уровней в каждом продукте может не быть востребованной ввиду отсутствия потребностей того или иного продукта в соответствующем архитектурном слое. В данном примере
продукты содержат фронтальную логику, отвечающую за их отображение в каналах обслуживания и проведение фронтальных операций, продуктовую логику, ответственную за выполнение жизненного цикла продуктов, процессную логику, определяющую бизнес-процессы жизненного цикла продуктов, а также логику работы с данными. Последняя в настоящем примере
отвечает за оперативное хранение, архивное хранение, кэширование и т. д. Указанные задачи
сгруппированы для упрощения иллюстрации. При этом компания может с целью упрощения, например, функций сопровождения и/или инфраструктурного обеспечения группиро88

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

вать реализацию одних и тех же архитектурных уровней и даже называть подобные группы
информационными системами. Но подобная терминология будет сохранять преемственность
с предыдущими архитектурными поколениями лишь в части наименования. Сутевая составляющая, скрывающаяся под общим термином, в корне отличается – как мы уже отмечали выше,
новые «информационные системы» сегментированы на основе продуктовой логики организации и представляют собой набор продуктовых реализаций одного и того же архитектурного уровня. При этом каждый архитектурный уровень любого продукта развивается в первую
очередь в соответствии с его бэклогом и лишь во вторую – в соответствии с задачами всей
«информационной системы», предполагающими влияние на все продукты, для которых актуален выбранный архитектурный слой. Новые задачи «информационной системы» могут формироваться, например, вследствие появления новых регуляторных требований, а впоследствии
реализовываться либо кросс-продуктовой командой, либо попадать в бэклог каждого продукта, для которого актуальна вновь возникшая задача. Тем не менее, появившись по отношению к тому или иному архитектурному уровню, соответствующие задачи все равно будут попадать в продуктовые бэклоги, учитываться и реализовываться в соответствии с ними, поскольку,
хоть и являются общими для всех сегментов «информационной системы», влияют на P&L
каждого конкретного продукта.
Мы не обсуждаем сейчас детали продуктовой трансформации ИТ-ландшафта, в контексте текущего раздела интерес представляет уровень процессной и отчасти продуктовой логики.
Именно на этих уровнях аккумулируются задачи автоматизации бизнес-процессов. На уровне
процессной логики – управления бизнес-процессами, на уровне продуктовой – выполнения
отдельных действий в рамках бизнес-процессов. Далее мы покажем, что остальные архитектурные уровни также задействованы, но их влияние на бизнес-процессы, связанные с продуктом, существенно слабее.
Внимательный читатель непременно попытается поставить нас в тупик вопросом: «Ранее
Вы говорили о сложности бизнес-процессов в современных организациях, сейчас же процессы
показаны выделенно и фактически локально на уровне каждого продукта, они не пронизывают деятельность организации в целом? Нет ли здесь противоречия?» Мы же ответим, что
никакого противоречия нет. Действительно, современная компания, создавая и развивая свои
цифровые продукты, непременно должна помнить о необходимости поддержки сквозных процессов. Что же такие процессы из себя представляют? В случае сложной структуры компании,
например, если она представляет собой крупный холдинг, необходимо предоставление головной организацией холдинга типовых бизнес-процессов своим дочерним организациям. Например, процессы закупочной деятельности, кредитные процессы, регламенты работы комитетов
и т. д., как правило, определяются на уровне головной организации, разумеется, с возможностью уточнения или корректировки на уровне организаций дочерних. При этом наличие
стандартизированных и унифицированных процессов верхнего уровня позволяет осуществлять прозрачный контроль корпоративной деятельности в рамках холдинга, а также обеспечивать методологическую и процессную унификацию деятельности, снижая тем самым издержки
и повышая конкурентоспособность всей структуры. Одновременно с этим на уровне конкретной организации бизнес-процессы могут быть связаны между собой. Ранее по ходу настоящей
книги мы уже приводили примеры связи бизнес-процессов, ассоциированных с кредитными
и депозитными продуктами.
Такие связанные процессы выполняются для некоторого подмножества из нескольких продуктов, но в любом случае должен существовать мастер-продукт, задачей которого
и является инициирование кросс-продуктового процессного взаимодействия. Соответствующий сложный процесс должен быть ассоциирован именно с мастер-продуктом, пусть и задействуя внешнюю по отношению к нему продуктовую логику в рамках своего исполнения.
Отметим также, что в ряде случаев возможно дублирование продуктовой логики на уровне
89

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

различных продуктов, поскольку тем самым снижается взаимозависимость конкретных продуктов. Принятие решений о корректном выборе реализации подобных кросс-продуктовых
бизнес-процессов должен осуществлять архитектор, являющийся лидером технологических
изменений.
Отдельным вариантом сложных кросс-продуктовых процессов могут служить общесистемные процессы, автоматизирующиеся в организации. Примером такого процесса может
служить начисление процентов по депозитам в случае, если в ИТ-ландшафте предусмотрено несколько депозитных цифровых продуктов. Подобные процессы имеет смысл выносить
в отдельное продуктовое ИТ-решение, также связанное с депозитами. На соответствующем
архитектурном уровне подобного продуктового решения будет предусмотрен набор актуальных кросс-продуктовых бизнес-процессов. Способ же их реализации (кросс-продуктовое взаимодействие или дублирование логики) должен быть определен архитектором.
Завершая ответ на вопрос читателя, добавим, что немало процессов после их продуктового и технического рефакторинга оказываются локализованными в рамках одного продукта, что обеспечивает их исполнение в полном соответствии с вариантом, приведенным
на Рисунке 27.
Читатель сразу ухватится за фразу из последнего абзаца: «Продуктовый и технический
рефакторинг! О продуктовом Вы ранее не говорили, нельзя ли поведать о нем подробнее? Технический в предыдущей книге рассматривался в рамках платформенного подхода, хотелось бы
услышать о нем в контексте подхода продуктового!» Мы, конечно же, постараемся удовлетворить интерес читателя в полной мере. И начнем с рефакторинга продуктового.
Как мы уже отмечали по ходу настоящего раздела, в организации, как правило, имеются
в наличии бизнес-процессы, характеризующие ее деятельность. Зачастую бизнес-процессы
описаны с различной степенью детализации, на сегодняшний день их автоматизация обычно
осуществляется с использованием выделенного BPM-движка, который может быть достаточно
развитым. Но традиционно описание бизнес-процессов осуществлялось в контексте принимающих участие в данных процессах ролей. Последние могли быть внутренними с точки зрения организации или внешними, но они ассоциировались со многими бизнес-процессами –
как правило, связи «роль – бизнес-процесс» реализовывались в парадигме «многие ко многим». Описание бизнес-процессов формировалось на основе действий, выполняемых представителями соответствующих ролей. При этом бизнес-процессы не имели строго продуктовой
направленности – они покрывали группы продуктов, зачастую принципиально отличавшихся
в части жизненного цикла. Например, финансовая организация описывала единой группой все
бизнес-процессы, связанные с кредитами. При последующей автоматизации выяснялась специфика кредитов в зависимости от целей – та самая продуктовая специфика, которая и составляет ключевую ценность продукта. На всем протяжении настоящей книги мы говорим о ценности для клиента. Ценность для клиента представляют не роли, не действия, выполняемые
ими, а продукты. Поэтому бизнес-процессы организации должны пересматриваться. В центре
каждого процесса должен быть продукт. То есть не ассоциированный с продуктом объект, а сам
продукт. Для примера не «заявка на кредит» должна быть центральным объектом бизнес-процесса, а сам кредитный продукт. Подобный подход предъявляет новые, совершенно другие
требования к структуризации бизнес-процессов.
Фактически под продуктовым рефакторингом мы понимаем описание бизнес-процессов
не на основе ролей, должностей и иных организационных атрибутов, не несущих непосредственной ценности клиентам и партнерам, а на основе жизненного цикла цифрового продукта.
Именно процессы жизненного цикла продукта должны стать бизнес-процессами верхнего
уровня в компании, а затем детализироваться. Указанный подход позволит изначально сегментировать бизнес-процессы в соответствии с продуктами, создаваемыми и развиваемыми
в компании, учитывать специфику продуктовой логики и в конечном итоге выделять продукты
90

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

с самостоятельной ценностью. В приведенном выше примере заявка на кредит становится
частным объектом одного из процессов жизненного цикла кредитного продукта. Более того,
поскольку компания может предлагать множество принципиально отличных кредитных продуктов, то, соответственно, и заявок на эти продукты может быть множество. И, говоря уже
сугубо техническим языком, использоваться данные различные объекты будут в различных
(сегментированных в соответствии с продуктовыми предложениями компании) шаблонах бизнес-процессов.
При изложенном выше подходе существенно меняется и концепция ролей в компании.
Если ранее роли были стандартными участниками бизнес-процессов, описывавших устоявшуюся деятельность компании, то по результатам продуктового рефакторинга требования
к ролям будут складываться из общих требований, предъявляемых процессами жизненного
цикла цифровых продуктов компании, преобразуемыми в бизнес-процессы и автоматизируемыми. Фактически требования к роли становятся суперпозицией требований, предъявляемых
бизнес-процессами. Аналогично роли требования к любому организационному субъекту формируются на основе продуктовых бизнес-процессов. При таком продуктовом рефакторинге
продукты становятся центром и фундаментом конкурентоспособной компании в современном
цифровом мире. Но нельзя забывать о том, что полноценное проведение подобного продуктового рефакторинга требует в первую очередь изменения мышления в компании, формирования продуктового mindset.
Концепция технического рефакторинга бизнес-процесса принципиально не изменяется
при рассмотрении в контексте продуктового подхода по сравнению с подходом платформенным. Несколько изменяется лишь фокус рассмотрения данного вопроса. Мы уже отмечали
в предыдущих книгах («Архитектура цифрового мира» и «Архитектура цифровых платформ.
От настоящего к будущему»), что технический рефакторинг позволяет корректно перенести бизнес-процесс из его текстового и графического описания в исполняемый с применением современных инструментов автоматизации вариант. Развитая поддержка большинством
современных BPM-движков нотации BPMN не просто предоставляет широкие возможности,
но и содержит в себе определенные скрытые риски. Как правило, современные компании
для описания собственных бизнес-процессов используют нотацию BPMN с элементами DMN.
В том числе указанная нотация используется и при описании бизнес-процессов, сформированных в ходе продуктовой трансформации. И у компании возникает соблазн напрямую перенести такое описание бизнес-процессов в BPM-движок. Действительно, BPM-движок предоставляет в составе комплекса моделирующее средство, поддерживающее нотацию. Казалось бы,
что может быть проще, чем перенести уже готовое описание в данной нотации и запустить
исполнение процессов. Что же в этом случае может пойти не так?
Реальность, увы, весьма сурова. Подобный перенос бизнес-процессов на уровень инструмента исполнения с высокой вероятностью может принести низкую производительность,
ошибки при масштабировании компонентов, значимые временные задержки при выполнении
отдельных этапов и т. д. Причина всего этого заключается в отсутствии технического рефакторинга перед осуществлением переноса описания бизнес-процесса на уровень технических
средств. Как мы уже отмечали в предыдущих книгах, технический рефакторинг бизнес-процесса предполагает формирование технической карты бизнес-процесса, в состав которой войдут как пользовательские истории, так и технические задачи, выполнение которых необходимо
в рамках реализации автоматизируемой продуктовой логики. Именно отсутствие технических
задач в описании бизнес-процесса становится краеугольным камнем затруднений при переносе его на уровень непосредственной автоматизации. В рамках технического рефакторинга
также определяется глобальный контекст процесса и его разделение на составляющие локальные контексты, формируются границы транзакций – как локальных, так и глобальных.
91

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Последнее носит исключительно важный характер. Напомним читателю понятие локальных и глобальных транзакций в бизнес-процессах. Бизнес-процесс отвечает за выполнение
процесса жизненного цикла продукта, за значимый перевод экземпляра продукта из одного
состояния в другое. Таким образом, подобный бизнес-процесс становится бизнес-транзакцией. Как по классическому определению согласованности транзакций транзакция переводит
систему из одного согласованного состояния в другое согласованное состояние, так и бизнес-транзакция переводит продукт из одного состояния в другое. Согласованность же состояний продукта определяется корректностью описания процессов его жизненного цикла. Такая
транзакция является глобальной, в ней задействовано множество объектов, ассоциированных
с процессом жизненного цикла цифрового продукта, она характеризуется глобальным контекстом. Под глобальным контекстом понимается совокупное состояние всех объектов, характеризующих экземпляр бизнес-процесса, а также необходимой вспомогательной информации.
Глобальная транзакция не может быть отменена – она содержит множество действий, результаты которых зафиксированы. Например, отправка уведомления клиенту о графике платежей по кредитному продукту. Подобное уведомление, как правило, не может быть просто
отменено – в случае ошибочности его отправки необходимо направить корректирующее уведомление. Но глобальная транзакция состоит из множества частных действий – локальных
транзакций. Локальная транзакция не обязательно переводит продукт из одного состояния
в другое, она лишь содержит и выполняет действие в рамках транзакции глобальной. Локальная транзакция в ряде случаев может быть отменена. При этом она характеризуется собственным контекстом – локальным. Совокупность локальных контекстов и переходов между
ними определяет глобальный контекст. А глобальный контекст в свою очередь определяет
состояние продукта, его наполнение данными и состояние проводимых продуктовых операций. Соответствие между глобальными и локальными транзакциями схематично представлено
на Рисунке 28.

Рисунок 28. Соответствие между локальными
и глобальными транзакциями
Принципы разграничения локальных транзакций в составе глобальной определяются
разграничением контекста: локальный контекст должен быть сохранен по итогам выполнения
соответствующей ему локальной транзакции. Примером такого сохранения (разрыва глобаль92

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ного контекста) может быть выполнение пользовательской задачи, ассоциированной с той или
иной ролью в ходе исполнения бизнес-процесса, либо вызов внешнего по отношению к продуктовому ИТ-решению программного комплекса, как внутреннего с точки зрения компании,
так и внешнего, и многое другое. Собственно, полученная структура локального и глобального
контекста и является результатом проведения технического рефакторинга бизнес-процесса.
А основой его проведения служит продуктовая логика.
В ходе технического рефакторинга бизнес-процессов необходимо также определить корректное применение шаблонов оркестровки и хореографии при управлении бизнес-процессами. Мы уже отмечали по ходу настоящего раздела, что бизнес-процессы в современной
архитектуре принимают совершенно новый вид, они ассоциируются с продуктами, предоставляемыми организациями своим клиентам и партнерам. Но указанное преобразование
бизнес-процессов вовсе не делает их проще. Структура, безусловно, меняется, но остается
весьма сложной, поскольку основывается на процессах жизненного цикла цифровых продуктов. В связи с этим управление столь сложными процессами является важным аспектом с точки
зрения обеспечения как непрерывности бизнеса, так и достижения лучших показателей времени вывода продукта на рынок (time-to-market). Что же в данном аспекте важно учитывать?
Вкратце напомним читателю базовые основы оркестровки и хореографии при управлении бизнес-процессами. Оркестровка предполагает централизованное управление бизнес-процессом, осуществляемое из одной точки. В противоположность данному шаблону хореография
не предполагает наличие единой точки управления исполнением бизнес-процесса. При хореографии компоненты автоматизации процесса, которые должны действовать согласованно,
публикуют события в соответствии с практиками событийно-ориентированной архитектуры
(EDA), при этом все компоненты осуществляют прослушивание публикуемых событий, реагируя на них в соответствии с требованиями и настройками процесса. Шаблон оркестровки
относительно прост, в свою очередь шаблон хореографии существенно сложнее с точки зрения
проектирования и реализации, но при этом он предоставляет значительно большие возможности масштабирования. Последнее особенно важно в условиях повсеместного распространения дистанционных каналов обслуживания и соответствующего роста требований к нагрузочной способности автоматизируемых бизнес-процессов. Одновременно с этим оркестровка
бизнес-процессов чрезвычайно чувствительна к надежности управляющего узла. Технический
рефакторинг бизнес-процессов, выполняемый архитектором совместно с членами продуктовой команды, предполагает в том числе определение возможностей применения рассматриваемых шаблонов управления в бизнес-процессах. В основе выбора и применения шаблонов
должны лежать фактическая сложность процессов жизненного цикла конкретных цифровых
продуктов, требования к производительности и отказоустойчивости автоматизируемых процессов, разумеется, и финансовые соображения – хореография, как правило, обходится в реализации несколько дороже. Современная архитектура обязана использовать оба указанных
шаблона, вопросы их комбинации и корректного применения относятся к компетенции архитектора.
Подчеркнем еще раз, что современное продуктовое ИТ-решение должно поддерживать оба шаблона управления бизнес-процессами, в противном случае на развитие бизнеса
будут наложены необоснованные ограничения: при появлении новых требований к автоматизации (созданию новых бизнес-процессов) или же уточнении действующих, для их реализации может банально не оказаться подходящего инструмента. В таком случае придется либо
дополнять имеющееся решение поддержкой нового инструментария, либо решать вновь поступающие задачи обходным путем с использованием нецелевых средств поддержки. Примером
некорректного использования средств автоматизации может служить ручное кодирование продуктовой командой «масштабируемого» бизнес-процесса в случае отсутствия в продуктовом
ИТ-решении поддержки шаблона хореографии. А поскольку реализация продуктового реше93

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ния, как мы неоднократно подчеркивали по ходу настоящей книги, должна осуществляться
с использованием платформенного подхода, то платформа должна обеспечивать поддержку
обоих шаблонов управления бизнес-процессами. В зависимости от предъявляемых в компании требований к скорости запуска новых цифровых продуктов возможен старт создания продуктовых ИТ-решений в момент готовности поддержки только одного из шаблонов на уровне
платформенного решения. При этом поддержка всего инструментария управления процессами
непременно должна быть обеспечена в ходе жизненного цикла платформы. Согласно свойству открытости платформ (подробно описано в книге «Архитектура цифровых платформ.
От настоящего к будущему») данная поддержка может быть реализована в том числе продуктовой командой. Главное здесь заключается в том, чтобы все реализации и расширения платформы публиковались в соответствии с унифицированными правилами и были доступными
для всех продуктовых команд.
Исходя из вышеизложенного, продуктовые ИТ-решения предъявляют требования к платформе организации в части охвата функционала управления бизнес-процессами. Схематично
эти требования изображены на Рисунке 29, представляющем собой тематический элемент
Рисунка 21.
На Рисунке 29 представлено платформенное приложение, реализующее цифровой продукт организации. Посредством платформенного SDK приложение взаимодействует с платформой, используя в ходе взаимодействия базовый платформенный сервис. Последний инкапсулирует особенности SDK. В текущем примере (в отличие от представленного на Рисунке
21) не принципиален язык реализации соответствующего платформенного SDK. В то же
время для целей управления бизнес-процессами посредством базового платформенного сервиса используется платформенный сервис управления бизнес-процессами, который, в свою
очередь, содержит две унифицированные на уровне платформы реализации: одна с использованием шаблона оркестровки, другая – шаблона хореографии. Как и в ранее рассматривавшихся примерах каждый сервис (оркестровки и хореографии) содержит две технологические
реализации с использованием современных BPM-движков: Camunda и Kogito. Наличие двух
технологических реализаций каждого сервиса позволяет поддерживать организационную распределенность, но лишний раз обратим внимание читателя, что подобное технологическое
многообразие приводит к росту затрат организации на создание, развитие и поддержку платформы.

94

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 29. Управление бизнес-процессами на уровне платформы, предоставляемое
продуктовым командам
Важно подчеркнуть, что представленный на Рисунке 29 (а ранее и на Рисунке 21) пример обеспечивает унификацию на уровне платформы управления бизнес-процессами с применением шаблонов оркестровки и хореографии. Это является важным элементом упрощения создания продуктовых ИТ-решений (в форме платформенных приложений), поскольку
даже ведущие мировые BPM-движки, как правило, не предлагают подобной унификации сами
по себе (как принято говорить, «из коробки»), зачастую многие из них даже не поддерживают
по умолчанию шаблон хореографии ввиду его сложности.
Мы видим из приведенного примера, что одним из важнейших требований к платформе
со стороны платформенных приложений, а следовательно и цифровых продуктов, является
унификация оркестрируемых и хореографируемых бизнес-процессов. Данный пункт является
во многом ключевым с точки зрения определения пользы, которую приносит платформа для
создаваемых и развиваемых организацией продуктов. С технической точки зрения реализация
указанных шаблонов, как мы уже неоднократно отмечали, существенно различается. И продуктовые команды не должны тратить избыточные ресурсы на реализацию и поддержку подобных различий во всех продуктовых процессах (а ИТ-ландшафт крупной современной организации может содержать тысячи и десятки тысяч шаблонов бизнес-процессов), потому что это
оказывает крайне негативное влияние на P&L. Поддержка двух ключевых шаблонов управления бизнес-процессами на уровне платформы, предоставление потребителям, в роли которых
выступают платформенные приложения, унифицированного платформенного SDK для работы
с бизнес-процессами, является значимым аспектом повышения производительности труда при
95

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

создании и развитии цифровых продуктов, а значит, лишний раз обосновывает необходимость
применения платформенного подхода.
Важным аспектом, который должна поддерживать платформа для платформенного приложения (цифрового продукта) в части управления бизнес-процессами, является управление локальными и глобальными транзакциями. Как было ранее показано на Рисунке 28,
бизнес-процесс представляет собой глобальную транзакцию, которая состоит из множества
локальных. Определение границ локальных транзакций осуществляется адресно для каждого
процесса с учетом его специфики и общих правил, предполагающих ограничение локальной
транзакции разрывом контекста и обязательностью его сохранения. Примерами подобных разрывов, как мы уже отмечали выше, являются встречающиеся в процессе неавтоматизируемые
задачи, вызовы внешних ИТ-решений, долговременные операции. Если каждая продуктовая
команда будет самостоятельно принимать решения о принципах управления транзакционным контекстом, то возможны ошибки, отсутствие унификации при исполнении процессов,
что угрожает непрерывности бизнеса, усложняет мониторинг исполнения экземпляров бизнес-процессов, расчет их КПЭ и т. д. То есть управление транзакциями, их границами, работу
с контекстом на границах транзакций необходимо переносить на уровень платформенных сервисов. А продуктовые команды должны стать источником требований к платформе в данной
части. При этом, используя свойство открытости платформы, они сами должны иметь возможность реализовать указанные требования и опубликовать их в составе платформы доступными
для всех задействованных в продуктовой разработке с использованием данной платформы
команд.
Теперь необходимо рассмотреть вопрос эффективной реализации автоматизированных
бизнес-процессов в современной продуктовой разработке с использованием платформенного
подхода. Для этого вновь рассмотрим детализацию концептуальной архитектуры продукта
на примере продукта электронной банковской гарантии, представленного ранее по ходу настоящей книги. Его архитектура, организация архитектурных слоев, стек используемых технологий, применяемые платформенные сервисы были представлены на Рисунках 25 и 26.
Нумерация используемых платформенных сервисов соответствовала индексам, приведенным
на Рисунке 21. На Рисунке 30 для удобства изложения и представления показана часть Рисунка
26, касающаяся архитектурного слоя продуктовой логики и управления бизнес-процессами.

96

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 30. Детализация концептуальной архитектуры продукта «Электронная банковская гарантия» в части слоя продуктовой логики и управления бизнес-процессами
Мы уже не раз обращали внимание читателя на тот факт, что приведенная детализация
является первичной и очень предварительной. Разберем подробнее приведенную детализацию
именно с точки зрения управления бизнес-процессами, тех аспектов работы с последними,
которые мы привели ранее по ходу настоящего раздела. Кроме того, обсудим перспективные
пути развития данного архитектурного слоя, которые позволят не просто управлять ассоциированными с цифровым продуктом бизнес-процессами, но и максимально эффективно их
развивать.
Еще в нашем первом труде «Архитектура цифрового мира» мы определяли базовые
направляющие по разделению прикладной и процессной логики в составе продукта при условии реализации последнего в парадигме микросервисной архитектуры. Процессная логика
отвечает за управление бизнес-процессом, но не отвечает за выполнение конкретных действий
в его составе. Непосредственные действия в составе бизнес-процесса реализуются микросервисами, ответственными за выполнение продуктовой логики. Указанный подход позволяет
независимо изменять логику управления процессом и логику выполнения конкретных действий, независимо масштабировать их, переиспользовать конкретные прикладные микросервисы, реализующие продуктовую логику, в различных процессах.
Наряду с этим сложный процесс может содержать в своем составе одновременно реализацию шаблонов и оркестровки, и хореографии. Для чего же подобный подход может понадобиться? Мы уже неоднократно обращали внимание читателя на сложность современных
продуктовых процессов, как следствие этого, сложными являются бизнес-процессы, основывающиеся на процессах жизненного цикла цифровых продуктов. Процессы, представляю97

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

щие собой глобальные транзакции, могут состоять из набора вложенных процессов, каждый
из которых может представлять собой как локальную, так и глобальную транзакцию. Каждый
из указанных бизнес-процессов ассоциируется с собственным процессом жизненного цикла
продукта. То есть каждый из подобных процессов может развиваться и масштабироваться независимо от других. Таким образом, логично управлять процессами, характеризуемыми глобальным транзакционным контекстом в соответствии с шаблоном хореографии. Если же процесс
ограничивается масштабами локальной транзакции, это означает высокую связность составляющих его элементов. Как следствие, для упрощения структуризации ИТ-ландшафта имеет
смысл осуществлять управление в рамках такого процесса в соответствии с шаблоном оркестровки. В качестве примера приведем соответствующее представление процесса «Заведение
электронной банковской гарантии» для продукта ЭБГ. Схематично данный пример представлен на Рисунке 31. При создании последнего использовался Рисунок 17 из книги «Архитектура цифрового мира».

98

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 31. Пример продуктового бизнес-процесса
На иллюстрации показан пример одного бизнес-процесса, ассоциированного с гарантийным продуктом. Также приведены компоненты продуктовой логики, использующиеся при
автоматизации бизнес-процесса. Отметим, что элементы хранения, представленные ранее для
реализации соответствующего архитектурного уровня на Рисунке 30, не показаны на Рисунке
31 с целью упрощения восприятия последнего. Кроме того, при работе с контекстом элементы хранения выполняют пассивную роль, а потому не несут определяющей смысловой
нагрузки с точки зрения выявления границ контекста. Также обратим внимание читателя, что
99

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

на Рисунке 31 не показано использование платформенных сервисов компонентами продуктовой и процессной логики с целью исключения излишнего загромождения иллюстрации.
На Рисунке 31 приведен пример бизнес-процесса, в рамках автоматизации которого
переводится в цифровой вид прием заявки на продукт ЭБГ. Данный процесс представляет
собой глобальную транзакцию с распределенным контекстом. Связанные между собой задачи
группируются в локальных бизнес-процессах:
• Процесс формирования заявки включает в себя создание заявки на продукт, ее первичную верификацию и обогащение данными, проверку цифровой подписи, первичный скоринг,
а также проверку комплектности приложенных к заявке документов.
• Процесс обработки заявки сотрудником банка (напомним, что мы рассматриваем продукт финансовой организации) включает в себя первичный анализ и обработку заявки уполномоченным сотрудником, возможные уточняющие запросы на торговую площадку, вызов
процесса оценки рисков. Отметим, что привлечение дополнительной роли и осуществление
запросов на внешнюю торговую площадку (а на сегодняшний день площадки являются основным каналом поступления заявок на гарантийные продукты) автоматически предполагает
выделение данного процесса в отдельный локальный контекст в составе глобального. При этом
связь оценки сотрудником поступивших данных с внешними уточняющими запросами допускает объединение элементов бизнес-процесса в одну транзакцию: выполняются успешно либо
все действия, либо процесс возвращает негативный результат.
• Оценка рисков включает обработку заявки уполномоченными сотрудниками, голосование на комитете, формирование протокола коллегиального органа.
• Процесс согласования заявки на банковскую гарантию предполагает обработку заявки
в рамках ролевой модели, ассоциированной с продуктом, создание формы гарантии, расчет
тарифов, проверку оплаты в соответствии с тарифом, верификацию, а также учет карточки
гарантии на соответствующем архитектурном уровне (с точки зрения классического подхода –
отражение карточки в учетных системах банка). Длительность данного процесса не отменяет
главного – все действия либо выполняются успешно, либо же процесс возвращает негативный
результат.
• Завершающим глобальную транзакцию процессом является непосредственно выпуск
банковской гарантии, включающий ее подписание, отправку оригинала клиенту, а также размещение гарантии в реестре банковских гарантий. Указанные действия также связаны между
собой общим транзакционным контекстом.
Каждый из перечисленных выше локальных процессов централизованно управляется
в соответствии с шаблоном оркестровки. При этом управление глобальным процессом, состоящим из приведенных на Рисунке 31 локальных процессов, осуществляется в соответствии
с шаблоном хореографии. Для имплементации указанного шаблона используется парадигма
событийно-ориентированной архитектуры (Event-Driven Architecture, EDA), поддерживаемой
потоковым программным обеспечением в части технологической реализации. Приведенный
подход позволяет независимо масштабировать экземпляры локальных процессов и не допускать узких мест с точки зрения производительности, а также повышать надежность и избегать
единых точек отказа в ходе исполнения экземпляра глобального бизнес-процесса.
Конкретные бизнес-действия осуществляются микросервисами, составляющими продуктовую логику гарантийного продукта – они также приведены на Рисунке 31. Данные микросервисы взаимодействуют между собой и с процессными микросервисами в соответствии
с практиками EDA с использованием потокового программного обеспечения.

100

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Указанное на Рисунке 31 программное обеспечение соответствует ранее приведенному
на Рисунке 30 технологическому стеку и представляет собой свободно распространяемое
ПО с открытым исходным кодом.
Дополнительно подчеркнем, что мы рассматриваем иллюстративные примеры, а не конкретные предложения финансовых организаций.
Наш пример был бы далеко не полным, если бы мы не упомянули понятие компенсации.
Для глобальной транзакции принципиально неверно говорить о понятии «отката»: результаты
выполнения локальных транзакций зафиксированы, мы не можем их откатить в соответствии
с принципами ACID (атомарности, согласованности, изолированности, долговременности)
транзакций. Например, если для глобального процесса, представленного на Рисунке 31, выполнены четыре из пяти составляющих его локальных процессов, а сбой произошел при выполнении пятого («Выпуск банковской гарантии»), то мы не можем просто отменить результаты
выполнения первых четырех процессов. Их локальный контекст уже выполнен. Если, например, гарантия по каким-то причинам не может быть размещена в реестре банковских гарантий,
это не приводит и не может привести к автоматическому удалению создания карточки гарантии на уровне учетной логики продуктового ИТ-решения. Необходимо выполнение компенсирующих действий: в зависимости от алгоритма, принятого в организации, возможны повторные обращения к реестру либо внесение соответствующих пометок в карточку гарантии. Такой
алгоритм именуется компенсацией. И все глобальные процессы должны предусматривать алгоритмы компенсации, которые также должны быть основаны на продуктовой логике. Отметим,
что это означает и соответствующие требования со стороны продуктовых ИТ-решений к платформенным сервисам – платформенные сервисы должны реализовывать поддержку компенсационных алгоритмов.
Но для полноценного рассмотрения вопросов транзакционной логики в продуктовом
бизнес-процессе необходимо обратить внимание на компоненты всех архитектурных слоев
цифрового продукта и их место в бизнес-процессах. Мы уже говорили о том, что современный продуктовый подход основывается на понятии end-to-end продукта. Как визуальное представление не может подменять собой весь продукт, предоставляемый организацией, так и бизнес-процесс не может ограничиваться только реализацией того или иного шаблона управления,
каким бы сложным он ни был.
На Рисунке 31 мы привели детализацию архитектурного уровня продуктовой логики
и логики оркестрируемых/хореографируемых процессов. Но в состав глобальной транзакции также входят и задачи, выполняемые компонентами других архитектурных уровней.
Например, продукт электронной банковской гарантии предполагает получение информации
по заявке на продукт с использованием внешней партнерской площадки. Данный факт предполагает, что в процессе получения и обработки заявок (с учетом того, что на площадку могут
направляться и уточняющие запросы) используются компоненты управления открытыми API,
относящиеся к уровню фронтального и канального представления цифрового продукта. Взаимодействие с реестром гарантий также может осуществляться с использованием указанных
компонентов. Участие сотрудников в бизнес-процессе, предполагающее работу с данными
заявки, объективно подразумевает создание автоматизированных рабочих мест (АРМ) для
уполномоченных ролей. Указанные АРМ также относятся к уровню фронтального и канального представления, при этом они задействованы в ходе исполнения экземпляров бизнес-процесса.
Резюмируя вышесказанное, мы должны подчеркнуть, что глобальный бизнес-процесс
и глобальная транзакция управляются на уровне продуктовой логики и логики оркестровки/хореографии, но при этом процессы включают исполнение компонентов и других архитектурных уровней. Что же это означает с точки зрения продуктовой архитектуры?
101

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Фактически мы должны понимать, что автоматизация продуктового процесса касается
всего продукта, при этом задействованы платформенные сервисы, актуальные с точки зрения продуктовой архитектуры. То есть при планировании архитектуры платформы, на базе
которой будут создавать цифровые продукты в формате платформенных приложений, необходимо учитывать, что в бизнес-процессах будут задействованы не только платформенные сервисы уровня продуктовой и процессной логики (индексы платформенных сервисов 1.1.1, 2.1.1,
4.1.2, 4.2.2, представленные на Рисунке 30), а все платформенные сервисы (в нашем примере
продукта ЭБГ они приведены на Рисунках 25 и 26). Это означает, что требования, предъявляемые продуктами к платформе в части поддержки бизнес-процессов, актуальны для всего
множества платформенных сервисов, используемых продуктовым ИТ-решением, и не ограничены каким-то одним конкретным архитектурным слоем. Это приводит к тому, что, например, требования по поддержке компенсационных алгоритмов должны обеспечиваться всеми
сервисами, задействованными в работе бизнес-процесса. Разумеется, реализация компенсационных алгоритмов зависит от специфики сервиса и, что еще важнее, от варианта его использования. Например, проведение операций в оперативной памяти и кэширование в ней элементов компенсируются/отменяются принципиально различным образом, пусть и могут быть
реализованы в рамках одного платформенного сервиса. Очевидно, что при реализации требований должны учитываться и технологические реализации платформенных сервисов. Именно
здесь и возникает потребность в унификации технологий на уровне платформы. Технологическое разнообразие, поддерживаемое платформенным решением, должно учитывать необходимость поддерживать развитие всех платформенных сервисов и их реализаций в соответствии
с потребностями цифровых продуктов.
Подчеркнем тот факт, что для каждого компонента каждого архитектурного слоя следует
учитывать необходимость его потенциального участия в бизнес-процессе, причем в составе
глобальной транзакции. Результатом этого учета становится набор нефункциональных требований к компоненту: его отказоустойчивости, нагрузочной способности, использованию платформенных сервисов, а также собственно требования к платформенным сервисам. Таким
образом, заказчики платформ – платформенные приложения – формируют требования к платформе, а опосредованным образом и к программному обеспечению, входящему в ее состав.
И если платформа и платформенные приложения строятся на основе программного обеспечения с открытым исходным кодом, то и развивать упомянутое ПО можно с высокой эффективностью на основании требований потребителей. А потребителями в данном случае выступают
цифровые продукты.
В рамках данной концепции высокая грануляция компонентов при использовании практик микросервисной архитектуры позволяет независимо рассматривать требования к каждому
компоненту продуктового ИТ-решения и аналогичным образом независимо проецировать их
на использующееся программное окружение: платформенное решение, прикладное и инфраструктурное программное обеспечение. При этом независимость требований, предъявляемых
к каждому компоненту, позволяет формировать их общий реестр, включать его в бэклог продукта и определять приоритеты реализации в соответствии с потребностями бизнеса и с учетом нефункциональных требований.
Важным аспектом при новом понимании бизнес-процесса, включающего все компоненты
цифрового продукта, является анализ вопросов мониторинга и определения КПЭ процесса.
Если классический способ мониторинга бизнес-процессов предполагал, что снимаются метрики, определяемые на уровне BPM-движка, то на сегодняшний день такой подход будет явно
недостаточным. Распределенные бизнес-процессы могут использовать множество экземпляров BPM-движков (конкретная архитектура зависит от организации платформы, платформенных сервисов и их технологических реализаций). И в таком случае на уровне платформенного
решения необходимо обеспечивать сквозной мониторинг бизнес-процессов, унифицирован102

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ный сбор метрик со всех компонентов платформенных приложений. При этом должна обеспечиваться интроспекция последних – вне зависимости от сложности автоматизируемого
цифрового продукта платформенные механизмы должны раскрывать набор его компонентов,
собирать метрики их исполнения и учитывать совместно, определяя здоровье бизнес-процесса
и его экземпляров, его узкие места, возможности по дальнейшему развитию. Корректность
интроспекции платформенных приложений достигается не только технологической, но и архитектурной их унификацией. Таким образом, при корректной организации платформенных
приложений становится возможным обеспечить унифицированный мониторинг всех процессов жизненного цикла для всех цифровых продуктов, создаваемых и развиваемых компанией.
А на основании указанного мониторинга компания сможет эффективно проводить оценку
P&L, обеспечивать предоставление максимальной ценности клиентам и партнерам.
В рамках настоящего раздела необходимо также рассмотреть вопросы развития архитектурного уровня продуктовой логики и логики оркестровки/хореографии бизнес-процессов
в условиях современных рыночных тенденций.
Если вернуться к Рисункам 30 и 31, то можно отметить, что продуктовая логика реализуется в соответствии с микросервисной архитектурой c использованием языков разработки высокого уровня (в нашем примере Java). Взаимодействие компонентов подчиняется
событийно-ориентированной парадигме, обеспечивающей минимальное взаимовлияние компонентов друг на друга. Подобное минимальное взаимовлияние и следующая из него слабая
связность позволяют независимо развивать входящие в состав решения компоненты, независимо обеспечивать их масштабирование, в том числе эластичное. Для поддержки событийно-ориентированного взаимодействия используется потоковое программное обеспечение
Apache Kafka. Указанное программное обеспечение поддерживает не только парадигму журнального обмена событиями, но и предоставляет возможности эластичного масштабирования.
Управление бизнес-процессами спроектировано и разработано в соответствии с принципами
микросервисной архитектуры с реализацией шаблонов оркестровки и хореографии. Подобная реализация позволяет максимально независимо развивать локальные процессы, входящие в состав бизнес-процесса глобального, независимо их масштабировать с использованием
практик эластичного масштабирования. Хранение контекста процесса и служебной информации осуществляется с использованием технологий реляционных СУБД (в нашем примере
PostgreSQL). Аналогично реляционные СУБД позволяют обеспечивать хранение данных микросервисных компонентов прикладной продуктовой логики, поскольку сами микросервисы
представляют собой компоненты без сохранения состояния (stateless). Эластичное масштабирование реляционных СУБД имеет определенные ограничения по сравнению с потоковым
программным обеспечением или микросервисными компонентами, но также допустимо в ряде
случаев. При этом хранение данных отделяется от логики их обработки, что позволяет независимо масштабировать компоненты хранения и исполнения логики и обеспечивать производительность и надежность выполнения указанных задач. Отметим также, что для хранения
данных продуктовая логика может использовать и технологии уровня хранения продуктовых
данных – как оперативного, так и архивного, которые относятся к смежным архитектурным
уровням продукта.
После проведения данного краткого экскурса необходимо обсудить, каким образом может развиваться рассматриваемый архитектурный уровень продукта, ответственный
за исполнение продуктовой и процессной логики, при появлении новых требований к цифровому продукту. Здесь имеет смысл говорить не только о новых функциональных требованиях, но и о требованиях нефункциональных, являющихся следствием изменения рыночных
тенденций. Например, появление новых каналов лидогенерации приводит к изменению требо103

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ваний по нагрузочной способности продукта. Итак, какие же изменения могут быть внесены
на основании вновь появляющихся требований в архитектуру?
Примером изменений может быть трансформация способа хранения контекста процесса.
Да, по умолчанию большинство BPM-движков используют для решения указанной задачи
реляционные СУБД. По аналогичному пути решают задачи хранения элементов контекста,
обрабатываемых компонентами прикладной логики, продуктовые команды – используют для
хранения реляционные СУБД и соответствующие платформенные сервисы в рамках применения платформенного подхода. Но мы уже отмечали потенциальные сложности в масштабировании данного класса технологических решений. В ряде случаев может оказаться необходимой полноценная поддержка эластичного масштабирования со стороны всех технологических
решений, задействованных в реализации бизнес-процессов. При таком варианте развития
событий возможны разные решения: сохранение данных контекста в формате событийного
обмена в СУБД посредством потокового программного обеспечения, переход к использованию нереляционных СУБД, обеспечивающих полноценное эластичное масштабирование, либо
дополнение хранения информации кэширующими компонентами. Последние также поддерживают эластичное масштабирование в большем объеме, нежели реляционные СУБД, повышая тем самым нагрузочную способность компонентов, реализующих логику в рамках бизнес-процессов, а также положительно влияя на общую надежность продуктового ИТ-решения.
Возможны доработки, при которых служебная информация BPM-движка может храниться
в кэш или в эластично масштабируемых нереляционных СУБД. Отметим, что ряд процессов
может требовать в рамках собственного исполнения использования архивных данных. Примером может служить исполнение бизнес-процесса по требованию контролирующих органов,
при этом данные, интересующие запрашивающие организации, уже перемещены в архивное
хранилище. В таком случае на рассматриваемом архитектурном уровне потребуется использовать технологии, принятые для долговременного дешевого хранения, а также соответствующие
им платформенные сервисы. Важным элементом развития рассматриваемого архитектурного
уровня является кэширование схем бизнес-процессов для максимально оперативного доступа
к реестру соответствующих артефактов. Многие современные BPM-движки не поддерживают
указанное архитектурное решение, а потому оно может потребовать доработок со стороны
компании, реализующей цифровой продукт. Подчеркнем, что подобные изменения должны
публиковаться и использоваться как минимум на уровне всех продуктовых команд организации для обеспечения технологической и методологической унификации.
На Рисунке 32 показан пример развития архитектурного слоя продуктовой логики
и управления процессами с точки зрения использования платформенных сервисов
На представленном рисунке в состав архитектурного уровня в рамках детализации и перспективного развития добавлены задачи по кэшированию данных бизнес-процессов, а также
их архивному хранению (с указанием номеров соответствующих платформенных сервисов –
см. Рисунок 21). Отметим, что доработки продуктового ИТ-решения на предмет таких значимых изменений, как кэширование схем данных, использование архивных данных и т. д., могут
привести и к развитию платформенных сервисов. Соответствующие компоненты имеет смысл
развивать, дабы их служебные функции были скрыты от продуктовых команд и не требовали
отдельной реализации в рамках каждого продуктового ИТ-решения. Пример такого развития
показан на Рисунке 33.

104

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 32. Пример развития архитектурного слоя продуктовой логики и управления
процессами

105

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

На этой иллюстрации представлена связь двух реализаций сервиса работы с данными:
сервис работы с кэш 1.4 использует сервис работы с реляционными СУБД 1.1 для обеспечения сохранения кэшируемых данных в долговременное хранилище. Разумеется, приведенную
связь должны поддерживать все технологические реализации сервиса 1.4. Аналогичным образом сервис управления бизнес-процессами 4 использует сервис работы с данными 1 для хранения информации о бизнес-процессах в кэш: данный механизм расширяет возможности BPMдвижков, использующихся в технологических реализациях сервиса 4, а потому требует допол106

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

нительной связи (и соответствующей ей реализации) на уровне платформы и платформенных
сервисов. Связи, добавленные на Рисунке 33 по сравнению с Рисунком 21 (выделены жирным), являются неявными с точки зрения платформенного SDK, что снижает нагрузку на продуктовые команды при использовании платформенного подхода в рамках своей работы. При
этом надежность и производительность создаваемых таким образом продуктовых ИТ-решений
повышаются, что положительно влияет на P&L цифрового продукта. Тем самым повышается
и опосредованная ценность платформы, предоставляемая использующим ее платформенным
приложениям – продуктовым ИТ-решениям.
Внимательный читатель в этот момент наверняка прервет наши рассуждения вопросом:
«Не увеличивает ли подобное развитие связность компонентов платформы?» Мы со своей стороны согласимся с читателем, но уточним, что указанное увеличение связности не противоречит ни одному из наших предшествующих утверждений. Это касается как утверждений, приведенных в настоящей книге, так и тезисов, рассмотренных в предыдущих трудах. В частности,
в книге «Архитектура цифровых платформ. От настоящего к будущему» мы явным образом
утверждали, что платформа совершенно необязательно должна быть микросервисной – ряд
компонентов могут обладать сильной связностью, обусловленной требованиями к платформе
и ее сервисам. А пример подобных требований мы как раз и разобрали чуть выше. При этом
увеличение связности повышает требования к архитектору – даже при высокой связности тех
или иных платформенных компонентов само платформенное решение должно безусловно следовать тенденции распределенности, поддерживать ее в части как архитектуры, так и последующей реализации.
Таким образом, рассматривая вопросы эффективной автоматизации бизнес-процессов
в продуктовых ИТ-решениях, мы вновь обращаем внимание читателя на необходимость поддержки двух рассмотренных ранее ключевых трендов развития архитектуры: открытого кода
и распределенности. Использование решений с открытым исходным кодом при реализации
платформенных сервисов и создаваемых с их применением цифровых продуктов позволяет
обеспечить максимальную гибкость продуктовых решений. При необходимости обеспечения развития, не поддерживаемого текущими основными версиями программных продуктов с открытым кодом, возможно развитие последних, поддержанное публикацией изменений
как минимум в рамках компании с целью обеспечения доступности публикуемого изменения
для всех продуктовых команд. Желательной в этом случае является публикация и в рамках
сообщества, развивающего соответствующее программное обеспечение с открытым исходным
кодом. Публикация уровня сообщества позволит обеспечить преемственность версий и дополнений, осуществляемых компанией. Также открытое программное обеспечение предоставляет
гораздо больше вариантов использования технологии по сравнению с закрытыми решениями,
что позволяет переносить подобную гибкость и на уровень платформенных сервисов и компонентов.
Одновременно с этим мы рассмотрели архитектурную поддержку автоматизации продуктовых бизнес-процессов в контексте обеспечения надежности и производительности последних. Мы уже отмечали выше, что каждый архитектурный уровень может масштабироваться
независимо от других, более того, компоненты одного архитектурного уровня также могут масштабироваться независимо друг от друга. Таким образом, компоненты продуктового ИТ-решения являются распределенными и минимальным образом связаны друг с другом. Кроме того,
их реализация в соответствии с платформенным подходом, а также использованием технологий, поддерживающих распределенность на уровне технологических реализаций платформенных сервисов и продуктовых компонентов, позволяет обеспечивать распределенность самих
программных компонентов. Причем речь здесь идет о распределенности как технологической,
так и организационной. Ведь столь слабо зависимые компоненты могут разрабатывать и раз107

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

личные продуктовые команды (ранее мы говорили о том, что над современными цифровыми
продуктами ввиду их сложности одновременно работает множество продуктовых команд).
Внимательный читатель вновь спешит озадачить нас вопросом и упрекнуть в непоследовательности: «Я изучил уже две Ваших книги, теперь читаю третью. Вы ранее регулярно
говорили о необходимости обеспечить встраиваемость BPM-движка, а тут не сказали про это
ни слова – вы дезавуируете рассуждения предыдущих трудов?» Мы со своей стороны спешим заверить читателя в том, что рассуждения наши последовательны и непротиворечивы,
мы их лишь несколько уточняем в зависимости от контекста рассмотрения. В предыдущей
книге «Архитектура цифровых платформ. От настоящего к будущему» мы говорили о BPMдвижке в составе современной платформы, в настоящей работе рассматриваем автоматизацию
бизнес-процессов с использованием соответствующего развитого инструмента уже в продуктовом контексте. И здесь мы должны вновь вернуться к ключевому вопросу любой ответственной работы, касающейся проблематики цифровых продуктов, – что же является главным отличительным свойством современного цифрового продукта? Мы уже отвечали на этот вопрос
в данной книге: главное свойство продукта – ценность, которую продукт несет клиентам
и партнерам компании, создающей и развивающей рассматриваемый продукт. Посмотрим
на проблематику BPM-движка с точки зрения ценности. И под этим углом зрения не имеет
никакого значения, какой конкретно BPM-движок используется. Подобное умозаключение
лишь на первый взгляд кажется неожиданным. Но зададим себе вопрос – в чем ценность BPMдвижка? Сам по себе он позволяет удобно автоматизировать, исполнять, моделировать бизнес-процессы. Но продуктовый и технический рефакторинг, платформенный подход и иные
аспекты автоматизации вносят не меньший вклад в процесс создания конечной ценности,
нежели сам движок. BPM-движок – один из инструментов, используемых в составе платформы. При этом платформа может использовать несколько различных движков управления
бизнес-процессами в качестве основы технологической реализации соответствующих платформенных сервисов. В нашем примере, представленном выше на Рисунке 33, используются
два BPM-движка (Camunda и Kogito), при этом для каждого из них предусмотрены различные платформенные сервисы реализации шаблонов оркестровки и хореографии. Открытость
и отсутствие замкнутости – важные свойства современных платформ, которые позволяют при
необходимости добавить третий, четвертый и последующие движки в качестве основы технологической реализации платформенных сервисов. Мы уже рассуждали ранее о проблематике
выбора множественных технологий и критериях принятия решения о добавлении новых технологий в состав платформенных и продуктовых ИТ-решений, не будем утомлять читателя
повтором всех уже приведенных в книге размышлений. В контексте его последнего вопроса
важнее другое: BPM-движок используется в составе платформы, которая в свою очередь служит средой создания и исполнения платформенных приложений, представляющих собой реализацию цифровых продуктов. И еще одно ключевое свойство платформы – встраиваемость.
Встраиваемость платформенного SDK в состав сервисов и компонентов платформенных приложений позволяет существенно упростить как создание, так и релизные циклы последних.
Таким образом, платформенный сервис управления бизнес-процессами (сервис 4 на Рисунке
33) как раз и является встраиваемым в состав приложения вне зависимости от конкретной
топологии BPM-движка. То есть с точки зрения потребителя (платформенного приложения) –
управление бизнес-процессом встраивается в его структуру. Надеемся, что мы успокоили читателя относительно согласованности идей, изложенных ранее в наших книгах.
Резюмируя вышеизложенное, подчеркнем, что процессные микросервисы в приведенных
выше примерах имеют принципиальное отличие от всех остальных компонентов, входящих
в состав цифрового продукта, заключающееся в том, что в их состав в обязательном порядке
включены библиотеки, обеспечивающие поддержку использования сервиса управления бизнес-процессами из состава платформенного SDK.
108

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Важный вопрос, который наверняка волнует читателей, касается того, насколько при
автоматизации продуктовых бизнес-процессов актуально использовать средства low-code и nocode, о которых так много говорят в последнее время. Мы уже подробно рассматривали ответ
на данный вопрос в книге «Архитектура цифровых платформ. От настоящего к будущему»,
поэтому в настоящем изложении зафиксируем тот факт, что все аргументы, приведенные
в предыдущем труде, остались актуальными, и добавим несколько новых тезисов, важных
с точки зрения продуктовой разработки:
• Для ускорения и упрощения продуктовой разработки необходимо использовать дизайнеры бизнес-процессов, которые присутствуют в современных средствах их автоматизации.
• Поскольку BPM-движок входит в состав платформы, то и соответствующие дизайнеры должны быть включены в ее состав. Им должны быть сопоставлены наборы рекомендуемых топологий и вариантов использования. Платформенные приложения должны стандартизированным и унифицированным образом использовать максимум возможностей включенных
в состав платформы инструментов, в том числе low-code и no-code при их наличии.
• Бизнес-процессы создаются не в вакууме, а в составе общего продуктового ИТ-решения, при этом используется платформенный подход. Low-code и no-code технологии позволяют
быстро создавать и моделировать MVP процесса, но необходимо предусматривать адаптацию
создаваемых подобным образом процессных автоматизаций к общей продуктовой архитектуре. Эта задача возлагается и на платформу, и на продуктовое ИТ-решение. То есть быстро
создаваемый автоматизированный процесс все равно нуждается в адаптации, которую необходимо учесть при проектировании архитектуры.
Таким образом, можно резюмировать, что low-code и no-code решения могут использоваться, но только в рамках платформенного подхода, и не могут считаться панацеей для быстрой автоматизации продуктовых бизнес-процессов сами по себе.
Важно отметить, что архитектор в современном цифровом мире ни в коем случае не должен пренебрегать вопросами бизнес-процессов. Он не может отдавать их на откуп бизнес-аналитикам или владельцам продуктов. Архитектор должен принимать участие в продуктовом
и техническом рефакторинге, определять наиболее подходящие с точки зрения использования в организации BPM-движки, формировать позицию по технологическому многообразию
применяемой цифровой платформы, предусматривать развитие создаваемой архитектуры уже
на начальных этапах ее жизненного цикла и многое другое. В противном случае могут быть
упущены из виду важнейшие как функциональные, так и нефункциональные аспекты создания
и развития цифровых продуктов, и компания понесет существенный урон.
По ходу настоящего раздела мы рассмотрели бизнес-процессы как одну из ключевых
тенденций развития архитектуры. И это рассмотрение мы провели в контексте продуктового
подхода: уделили внимание месту бизнес-процессов в архитектуре современных цифровых
продуктов, провели грань между локальными и глобальными транзакциями в продуктовых
бизнес-процессах, отметили важность продуктового и технического рефакторинга бизнес-процессов при их автоматизации. Особое внимание мы уделили месту платформенного подхода и требуемой структуре современной цифровой платформы, необходимым для создания
и исполнения действительно конкурентоспособных цифровых продуктов. Также рассмотрели
варианты развития архитектуры бизнес-процессов в рамках следования рыночным требованиям и ограничениям. Подчеркнули связь бизнес-процессов с такими тенденциями развития
архитектуры, как открытый код и распределенность. В следующем разделе мы рассмотрим
не менее важный тренд развития архитектуры – данные.

109

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровые продукты и данные
Абсолютное большинство информационных источников (профессиональная ИТ-литература, Интернет и т. д.) утверждают, что данные являются одним из ключевых активов организации, стремящейся не просто сохранять, но и наращивать собственную конкурентоспособность
на рынке. Ведь именно данные составляют основу принятия компанией решений, напрямую
влияющих на указанную конкурентоспособность. Современные компании генерируют огромные массивы данных в ходе своей ежедневной деятельности, оперируют же гораздо большими
объемами. Данные могут получаться из открытых источников, могут формироваться непосредственно в результате исполнения бизнес-процессов, формироваться в рамках партнерских взаимодействий, предоставляться государственными структурами, носить транзакционный характер. Но все они характеризуются и объединяются на основе той значимости, которую
несут для организации. Поэтому, безусловно, данные являются одной из ключевых тенденций
развития архитектуры. В «Архитектуре цифрового мира» мы рассматривали место и значимость данных для всего современного цифрового мира в целом, в «Архитектуре цифровых
платформ. От настоящего к будущему» мы концентрировали внимание читателя на использовании данных в рамках платформенного подхода. В настоящей же книге мы рассматриваем
подход продуктовый, поэтому и данные будем обсуждать в соответствующем контексте.
Как и в предыдущих книгах, начиная разговор о данных, мы должны сначала затронуть
и осветить методологический вопрос. Современные компании объединяют и аккумулируют
ключевые вопросы методологии работы с данными в так называемой концепции управления
данными. Последняя носит не столько технический, сколько именно методологический характер и отвечает на ряд важных для организации вопросов:
• Правила определения собственных и внешних по отношению к организации данных.
• Определение мастер-систем (мастер-продуктов) для различных категорий данных.
• Определение критериев качества данных, на основании которых можно утверждать, что
те или иные данные, содержащиеся в информационных системах (или в условиях современной
ИТ-архитектуры продуктовых ИТ-решениях) организации, являются достоверными, полными,
непротиворечивыми, иными словами, «качественными».
• Определение ответственных за данные ролей. Роли могут определять как сотрудников
организации, так и внешние по отношению к компании сущности.
• Правила разрешения конфликтов по данным, неизбежно возникающих в ходе деятельности организации и исполнения ее продуктовых бизнес-процессов.
• Правила очистки данных. В современных условиях скорость поступления новых данных огромна. Вновь поступающие порции данных могут быть как противоречивыми с точки
зрения критериев, установленных в организации, так и продуцировать конфликты с уже содержащимися в компании данными. В этих условиях организация, стремящаяся поддерживать
качество данных, обязана определить набор критериев, по которым вновь поступающие данные будут верифицироваться, очищаться и проверяться на предмет конфликтов с уже имеющимися данными.
• Целый ряд вспомогательных методологических вопросов.
Как мы отмечали в предыдущих книгах, концепция управления данными носит методологический характер (на то она и концепция) и отделена от цифровых инструментов поддержки ее реализации, но она принципиально не может быть отделенной от продуктов компании. В противном случае она будет носить исключительно абстрактный характер и останется
лишь набором страниц текста или слайдов в презентации. Современная организация, жела110

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ющая сохранять конкурентоспособность в постоянно меняющихся условиях рынка, обязана
четко увязывать концепцию управления данными с той ценностью, которую компания несет
в виде цифровых продуктов клиентам и/или партнерам. Поэтому концепция управления данными с необходимостью должна обладать рядом свойств, которые мы отмечали в книге «Архитектура цифровых платформ. От настоящего к будущему». Вкратце напомним их читателю:
• Конкретность. Концепция управления данными не может только цитировать учебники
по соответствующей дисциплине, пусть и весьма авторитетные. Она должна отвечать на конкретные вопросы, которые ставятся перед организацией, учитывать специфику деятельности
последней, адаптироваться к рыночным реалиям.
• Ориентированность на продукты. Мы уже отмечали и в «Архитектуре цифрового
мира», и в «Архитектуре цифровых платформ. От настоящего к будущему» необходимость
корректной сегментации современных систем управления данными, в том числе хранилищ
данных в соответствии с принципами продуктов данных, поддержку шаблона «Сетки данных» (Data Mesh). Концепция управления данными должна отвечать на вопросы, какие же
продукты она предлагает, место этих продуктов данных среди конечных продуктов организации, обеспечивающих ценность для клиентов и/или партнеров. Кроме того, в условиях, когда
по всему миру набирает популярность шаблон организации больших объемов данных Data
LakeHouse, современная концепция управления данными должна обеспечивать его всестороннюю поддержку. Безусловно, как мы отмечали выше, методологическая составляющая работы
с данными отделена от инструментального обеспечения, но игнорировать деятельность компании она не может.
• Гибкость. Процитируем наш предыдущий труд «Архитектура цифровых платформ.
От настоящего к будущему»: «Любая компания, вынужденная сохранять конкурентоспособность в современном цифровом мире, обязана адекватно развивать свои продукты и поддерживающие их цифровизацию инструментальные средства (в том числе в части обеспечения
работы с данными). И концепция управления данными должна поддерживать указанное развитие, а не быть барьером для него». Продукты организации постоянно развиваются, компании вкладывают значительные средства в достижение лучших рыночных показателей time-tomarket. Если в такой ситуации концепция управления данными по каким-то причинам оказывается барьером на пути достижения целей, то она должна быть в корне пересмотрена.
При обсуждении взаимовлияния и соотношения между концепцией управления данными и платформенным подходом (в книге, посвященной последнему) мы утверждали, что
платформа должна поддерживать различные концепции управления данными, в свою очередь
концепция должна учитывать те возможности, которые предоставляются платформами. В случае рассмотрения цифровых продуктов мы обязаны подчеркнуть, что каждый продукт оперирует собственной моделью данных, и никакая современная концепция не может диктовать продуктам компании единую модель данных. Покажем это на примере. Предположим, что у нас
есть три продукта финансовой организации для сегмента малого и среднего бизнеса: кредит,
электронная банковская гарантия и просроченная задолженность (да-да, это тоже продукт,
обладающий самостоятельной ценностью). Все три приведенных продукта обладают сущностью «Клиент». Но требования к клиенту и клиентским данным, а также к операциям над ними
продукты предъявляют принципиально разные. Клиент, в отношении которого ведется работа
в части просроченной задолженности, характеризуется зачастую большим объемом ассоциированной с ним информации, нежели клиент, обращающийся за кредитом или электронной
банковской гарантией. В такой ситуации связывать три продукта общей моделью клиентских
данных оказывается не просто бессмысленно, но и крайне вредно для развития ИТ-ландшафта
компании – продукты оказываются сильно связанными с точки зрения данных, что противоре111

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

чит всем современным архитектурным требованиям, в том числе распределенности. Причем
в рассматриваемом случае речь идет и об организационной, и о технологической распределенности. Сильная связность по данным продуктов обеспечит сильную связность продуктовых
команд и поставит их в зависимость друг от друга. С технологической точки зрения сильная
связность по данным не позволит независимо масштабировать продуктовые решения. В случае кредитного продукта и электронной банковской гарантии при их внешней схожести бизнес-процессы обработки заявок и последующего учета продуктов, а также скоринговые модели
принципиально отличны друг от друга. В этой ситуации сильная связность по данным двух
указанных цифровых продуктов приведет к сильной связности продуктовых бизнес-процессов,
которые ассоциированы с различными процессами жизненного цикла финансовых продуктов. Обеспечение лучших рыночных показателей time-to-market, независимое масштабирование, отсутствие конфликтов при выпуске релизов в этом случае оказываются недостижимыми.
Так что же дает цифровым продуктам концепция управления данными?
Когда мы рассматриваем преимущества применения платформенного подхода в продуктовой разработке, то регулярно демонстрируем те возможности, которые предоставляет
платформенным приложениям (непосредственно и автоматизирующим продукты организации) технологическая и методологическая унификация, обеспечиваемые современной платформой. Продуктовые команды концентрируют свои усилия на создании прикладной логики
жизненного цикла продуктов, в то время как инфраструктурные задачи берет на себя платформенное решение. Последнее также предоставляет наборы стандартизированных архитектурных конфигураций. Концепция управления данными в современной компании должна принимать на себя аналогичную роль в части методологии работы с данными. Актуальный рыночный
цифровой продукт является как поставщиком, так и потребителем данных, причем во многих
случаях речь идет о больших данных (Big Data). Если каждый продукт будет «творить» свой
собственный подход к работе с информацией, то методологический «зоопарк» может похоронить под собой любые перспективы интенсивного развития организации. Полностью самостоятельное создание моделей данных каждого сервиса и компонента продуктового решения приведет к необходимости синхронизации огромного количества API, что в свою очередь может
стать причиной возникновения существенных объемов регрессионного тестирования при внесении даже минимально значимых изменений. О лучших практиках time-to-market при подобном развитии событий можно просто забыть.
В этой ситуации задачей концепции управления данными становится помощь продуктовым командам в части выработки общих принципов работы с данными. Не диктат конкретных моделей, а именно методологическая помощь при их создании, развитии и эксплуатации.
Попытка создания унифицированной модели данных объекта «Клиент» из представленного
выше примера приведет лишь к организационной путанице: команда, ответственная за концепцию управления данными, будет вынуждена изучить три предметные области, после чего
совместить их в унифицированной модели. При этом изменения, вносимые в результате требований, возникающих в одном из рассматриваемых в примере продуктов, будут оказывать влияние на два остальных. В условиях современного цифрового мира, ориентированного на максимальную эффективность, подобное взаимовлияние оказывается неприемлемым. Концепция
управления данными должна формулировать общие правила, применимые при формировании
локальных (ограниченных пределами конкретного продукта) моделей данных, обеспечивающие их гармонизацию, а также эффективное кросс-продуктовое взаимодействие. При наличии
в компании подобных правил управления данными каждая продуктовая команда сможет формировать собственные модели данных, прозрачные для смежных команд, но при этом избегая
избыточного взаимовлияния.

112

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Детальное обсуждение принципов формирования концепций управления данными выходит за рамки настоящей книги. В дальнейшем мы будем рассматривать данные в контексте
архитектуры современного цифрового продукта, которой и посвящено настоящее изложение.
Внимательный читатель прервет нашу попытку перехода непосредственно к продуктовым аспектам интересующим его важным вопросом: «Не очень понятно – раньше Вы говорили, что шаблон канонической модели данных в современном цифровом мире неприменим,
сейчас же отмечаете возможность создания моделей данных по продуктам. А как организации
описать свои продукты с точки зрения данных, если нет общей модели?» Вопрос читателя правомерный и исключительно злободневный, а потому мы приведем развернутый ответ на него.
Разумеется, общая модель данных (каноническая), разработанная в формате, понятном бизнес-пользователям, является мечтой многих руководителей, так как позволяет наглядно представить саму деятельность организации применительно к реалиям рынка, на котором она
работает. При этом подобная модель теоретически может сразу явно продемонстрировать тот
факт, что деятельность компании распространяется сразу на несколько рыночных сегментов.
Но именно здесь сразу же выявляется ряд противоречий, которые не позволяют напрямую
проецировать указанное благое намерение в мир цифровизации.
Во-первых, как мы уже отмечали в предыдущих книгах («Архитектура цифрового мира»
и «Архитектура цифровых платформ. От настоящего к будущему»), в том, каким образом
шаблон канонической модели данных (КМД) позиционировался ранее и позиционируется
в настоящее время на рынке, уже содержится серьезная ошибка. В чем же она заключается?
Бизнес-пользователи, как правило, оперируют предметной областью, описывающей их профессиональную деятельность. Это проявляется как в наборе объектов указанной области, так и в их
структуре – она жестко привязана к бизнес-деятельности конкретных ролей. Но подобная
модель данных далеко не всегда может быть эффективно положена в основу автоматизации:
она нуждается в уточнениях, введении дополнительных служебных объектов данных, дополнении бизнес-объектов техническими параметрами, изменениями связей объектов с целью повышения эффективности их обработки современными средствами информационных технологий
и т. д. Результатом становится то, что даже эффективно описанная и приближенная к реалиям
бизнеса КМД неприменима в цифровых решениях, а КМД, созданная с учетом потребностей
ИТ, непонятна бизнес-пользователям. Фактически в этом случае в организации будут сосуществовать две КМД – референтная, используемая в коммуникациях с бизнесом, и исполняемая,
являющаяся вотчиной «цифры». И развиваться обе модели будут пусть и в общем направлении, но принципиально отлично друг от друга с точки зрения деталей.
Во-вторых, сразу возникал вопрос, каким образом, на какой основе выстраивать КМД.
Учитывая тот факт, что цифровизация в любой компании ведется итеративно, она должна
показывать результаты, например в рамках той или иной продуктовой области. Если использовать шаблон КМД, то возникает соблазн сформировать каноническую модель на основе тех
продуктов, которые попадают в первую очередь цифровизации. Но, учитывая реалии современного рынка, необходимо принимать во внимание, что продукты оперируют принципиально
разными с точки зрения наполнения данными. Выше мы уже приводили пример того, как объект «Клиент» может быть реализован совершенно по-разному в зависимости от той предметной области, в которой он применяется. И если мы выстраиваем модель данных на основе
одной из продуктовых областей, затем подстраивая ее под все последующие, то с высокой вероятностью мы можем получить «лоскутное одеяло» из объектов, составляющих общее представление в модели данных, но реально неприменимых в конкретной деятельности той или иной
продуктовой области. Основной причиной неприменимости станет то, что изначально объект ограничивался пилотной зоной цифровизации. Альтернативой подобному ограничению
структуры объекта становится развитая иерархическая структура объектов, похожая на дерево
классов в представлении объектно-ориентированного программирования. Но такая структура
113

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

уже содержит сильную связность по данным между схожими объектами различных продуктовых областей. Результатом подобной связности, как мы уже отмечали выше, становится существенное ухудшение показателя time-to-market и снижение конкурентоспособности компании.
Таким образом, мы видим, что оба сформулированных подхода к построению КМД не соответствуют современным архитектурным и технологическим практикам, а потому не могут применяться в компании, ставящей своей целью интенсивное развитие на актуальном цифровом
рынке.
Какой же из этой ситуации выход? Концепция управления данными должна содержать
общие методологические рекомендации по созданию моделей данных, которым обязаны следовать продуктовые команды. В рамках создания цифрового продукта каждый продукт будет
определять собственную модель данных. При этом на уровне структуры событий при использовании парадигмы событийно-ориентированной архитектуры, а также на уровне общекорпоративных задач, требующих объединения данных (мы ниже рассмотрим подобные задачи), концепция управления данными должна определять правила эффективного слияния продуктовых
моделей. Одновременно с этим развитие каждой продуктовой модели осуществляется самостоятельно, обеспечивая максимальную независимость жизненного цикла каждого цифрового
продукта в части как развития, так и сопровождения. Таким образом в области работы с данными обеспечивается достижение лучших показателей time-to-market, а также максимально
эффективное положительное влияние на P&L продукта. Надеемся, что мы ответили на вопрос
читателя.
Когда мы говорим о данных в контексте продуктов, мы обязаны незамедлительно поднять вопрос их корректной передачи в условиях поддержки распределенности. Почему именно
указанный вопрос столь важен? Действительно, если в условиях традиционных монолитных
систем с минимумом интеграционных взаимодействий (еще каких-то 10—12 лет назад 250
—300 интеграционных взаимодействий считались огромным количеством даже для очень
крупных организаций) отмеченный аспект работы с данными был не слишком критичен, то
на сегодня он уверенно выходит на первый план. Современный ИТ-ландшафт становится
распределенным. Более того, мы уже отмечали по ходу настоящей книги, что само понятие информационной системы с технической точки зрения безвозвратно уходит в прошлое.
Сейчас мы оперируем продуктовыми ИТ-решениями, которые являются распределенными
как с точки зрения ИТ-ландшафта организации (они распределены по различным инфраструктурным узлам), так и сами по себе: их архитектура представлена значительным количеством распределенных компонентов, а исполнение последних осуществляется в распределенном режиме. В этой ситуации количество удаленных вызовов между компонентами ИТландшафта переживает стремительный рост. И если переносить характерную для монолитных систем сильную связность компонентов в современную распределенную архитектуру, то
затраты на обеспечение эффективности гигантского количества удаленных вызовов окажутся
непосильными даже для самых экономически стабильных и успешных компаний.
Когда мы говорим о современном ИТ-ландшафте, то в первую очередь мы имеем в виду
наличие значительного количества продуктовых ИТ-решений, взаимодействующих между
собой. При этом каждый продукт организации должен обладать собственным жизненным циклом и в минимальной степени зависеть от других цифровых продуктов, предоставляемых компанией. Указанный подход можно напрямую спроецировать на обмен данными: при минимизации взаимодействий между продуктовыми ИТ-решениями количество удаленных вызовов,
требующих значительных ресурсных затрат, также будет минимизировано. Но каждый цифровой продукт в свою очередь обладает распределенной структурой, которую мы уже неоднократно рассматривали по ходу настоящей книги. Вызовы между указанными компонентами
также являются удаленными, вследствие чего могут привести к значительным затратам ресурсов на свое обеспечение. При большом же количестве удаленных вызовов «залить железом»
114

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

их выполнение уже не получится. Мы просим прощения у читателей за использование подобного устоявшегося жаргона, но именно он, к сожалению, наилучшим образом отражает то,
каким образом нередко пытаются решить проблемы недостаточно проработанной архитектуры. Отметим, что подобный способ не является решением проблем, он лишь «заметает их
под ковер» и фактически усугубляет. Как же мы должны поступить в случае компонентов
одного цифрового продукта, потенциально допускающих сильную связность?
Исключительно важно подчеркнуть то обстоятельство, что факт включения компонентов в архитектуру одного продукта автоматически вовсе не означает их сильной связности.
В примерах продуктов, рассмотренных по ходу нашего текущего изложения, мы обосновывали использование микросервисной архитектуры в качестве ключевой архитектурной парадигмы при проектировании продуктового ИТ-решения. Следование указанному архитектурному стилю предполагает, что компоненты, реализованные в соответствии с ним, представляют
собой независимые единицы развертывания с минимальным взаимовлиянием. Мы не строим
«распределенные монолиты» (еще один, к сожалению, устоявшийся жаргонный термин, обязанный своим появлением простому переносу принципов организации традиционных ИТсистем в распределенную архитектуру), мы говорим о компонентах, обладающих собственным
жизненным циклом и разрабатывающихся отдельными членами команды. Необходимо минимизировать их связность даже в рамках одного продуктового ИТ-решения. Проще всего сделать это, основываясь на границах транзакционных контекстов, которые мы подробно рассмотрели в предыдущем разделе. Не стоит пытаться решить проблемы распределенных транзакций,
особенно если последние в условиях высокой нагрузки не могут гарантировать исполнение
двухфазного подтверждения (коммита). Следует по возможности максимально ограничивать
разрыв транзакционного контекста между микросервисами. Удачно подходит для решения
указанной задачи парадигма событийно-ориентированной архитектуры. Напомним читателю,
что событие не является отложенной командой на исполнение, а фиксирует значимое для
системы в целом изменение состояния. Микросервисы в таком случае в соответствии со своим
жизненными циклом реагируют на изменения состояния системы (продуктового ИТ-решения). Обмен данными в рамках каждой отдельно взятой локальной транзакции ограничен компонентом. А изменение состояния системы, требующее генерации события в соответствии
с практиками EDA, фиксируется в элементах хранения, в роли которых могут выступать базы
данных, потоковое программное обеспечение или кэширующие элементы. Модель данных для
событий должна учитывать требования концепции управления данными, принятой в организации. Кроме того, в условиях распределенной архитектуры необходимо проектировать обмен
данными таким образом, чтобы он был минимизирован при взаимодействии распределенных
компонентов. Конкретные рекомендации по проектированию должны учитывать тот технологический стек, который принят в организации, а также варианты использования платформенных сервисов.
При этом взаимодействие различных цифровых продуктов организации между собой
также осуществляется в событийно-ориентированной парадигме, но оно минимизировано
по сравнению с объемами взаимодействия, характерными для межкомпонентного взаимодействия в рамках одного продукта.
Схематично пример взаимодействия компонентов в распределенной архитектуре с минимизацией объемов передаваемых данных приведен на Рисунке 34. Рисунок 34 основан
на Рисунке 10 из книги «Архитектура цифровых платформ. От настоящего к будущему»

115

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 34. Обмен данными в распределенной
продуктовой архитектуре
На иллюстрации показаны два продукта – кредит и электронная банковская гарантия,
а также их компонентный состав. Подчеркнем, что в реальных примерах выделение компонентов в структуре продукта может отличаться от представленного на рисунке. Компоненты
генерируют события, характеризующие изменения состояния продуктового решения, например, по итогам выполнения транзакций, ассоциированных с соответствующими компонентами. Обмен информацией между компонентами осуществляется как напрямую (в случае, если
компоненты относятся к одному и тому же продукту), так и в событийно-ориентированной
парадигме. Второй вариант обмена информацией возможен при взаимодействии компонентов
одного продуктового ИТ-решения наряду с прямой интеграцией, а в случае же взаимодействия
компонентов различных цифровых продуктов именно такой способ информационного обмена
является рекомендуемым. При этом обеспечение поддержки событийного обмена осуществляется с использованием специализированного программного обеспечения, взаимодействие
с которым основывается на платформенном подходе. Компоненты продуктовых ИТ-решений
используют платформенный SDK для унификации работы с потоковым программным обеспечением, на основе которого осуществляется событийный обмен.
Внимательный читатель и здесь не оставит нас без своего злободневного вопроса:
«Ранее мы рассматривали вариант поддержки технологического разнообразия при продуктовой автоматизации. Что, если два продукта будут использовать платформенные сервисы потоковой передачи информации с различными технологическими реализациями – каким образом в таком случае обеспечить обмен данными между компонентами разных продуктов?»
Вопрос читателя актуален и абсолютно закономерен. Можно предложить два варианта ответа
на него. Первый из них заключается в том, что все продуктовые ИТ-решения используют все
технологические реализации платформенных сервисов и поддерживают все технологическое
разнообразие, имеющееся в продуктовом ИТ-ландшафте. Но такой способ реализации цифровых продуктов является исключительно трудоемким и дорогостоящим, а потому не может
быть принят во внимание организацией, стремящейся не просто сохранять, но и наращивать
116

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

свою конкурентоспособность на рынке. Поэтому мы сразу перейдем к рассмотрению второго
варианта ответа на вопрос читателя. Платформенная архитектура и последующая реализация должны предусматривать возможность использования всех технологических реализаций
платформенных сервисов платформенными приложениями неявным для себя образом. Например, реализация на уровне платформы прослушивающих процессов, обеспечивающих реакцию компонентов цифровых продуктов на события, должна обеспечивать прослушивание всех
технологических реализаций. Отметим, что в таком случае при появлении новых технологических реализаций библиотеки, ответственные за прослушивание событий на уровне платформы,
должны быть обновлены, что в свою очередь приведет к усложнению релизных циклов как
для платформы, так и для потребителей библиотек – платформенных приложений. Указанное
усложнение является одним их тех факторов, влияющих на P&L цифровых продуктов, о чем
мы говорили ранее по ходу настоящего изложения. Технологическое разнообразие на уровне
платформы гарантирует гибкость при создании продуктовых решений, но требует значительных трудовых, временных и финансовых ресурсов на собственные развитие и поддержку.
Рассмотрев столь важный аспект как передачу данных в рамках продуктовых решений,
настало время перейти к сущности, о которой мы уже неоднократно упоминали как по ходу
наших предыдущих книг, так и в рамках настоящего изложения, – к продукту данных.
Основное содержание данной книги напрямую или опосредованно посвящено продуктам
и той ценности, которую они несут своим потребителям. Современный мир стал продуктовым.
Но при этом нельзя забывать, что в своем развитии и в части захвата рынка продукты проделали более длительный путь, нежели платформы и современное мышление. Мы уже обсуждали
это по ходу книги и схематично отображали на универсальной S-кривой (см. Рисунок 1). И,
говоря о данных, также нельзя забывать и оставлять в стороне тот факт, что мышление, о котором мы столь подробно и обстоятельно рассуждаем, должно безусловно применяться и к работе
с информацией. Почему это столь важно? Для более полного и глубокого понимания вначале
проведем наглядную аналогию. В книге «Архитектура цифровых платформ. От настоящего
к будущему» мы неоднократно подчеркивали, что платформа не предоставляет прямой ценности клиентам, но предоставляет ценность опосредованную, позволяя быстрее и эффективнее создавать цифровые продукты в формате платформенных приложений, затрачивая на это
меньшие трудовые, временные и финансовые ресурсы. То есть платформа не является продуктом с точки зрения клиента и/или партнера компании, но может (с некоторыми допущениями) считаться продуктом с точки зрения платформенных приложений. С данными ситуация
во многом аналогична. Современный продукт продуцирует и потребляет огромное количество
информации, и ценность продукта во многом базируется на эффективности сбора, хранения,
обработки и предоставления потребителям указанной информации. Таким образом, данные
несут опосредованную ценность для клиента по аналогии с платформой. Сами по себе данные
(как продуцируемые продуктовым ИТ-решением, так и получаемые им из внешних с точки
зрения продукта программных комплексов) не имеют ценности для клиента, но ценность продукта, предоставляемого клиенту (например, кредит), во многом определяется работой с данными. То есть имеет смысл поднять и подробно обсудить вопрос о данных как о продукте.
В значительной степени этому способствует потребность работы с большими данными
(Big Data). Большие данные обладают несколькими специфическими характеристиками:
• Они имеют в своем составе не только структурированную, но и неструктурированную
информацию. Примерами последней могут выступать документы, такие как файловые вложения, или медиаконтент.
• Они характеризуются значительными объемами. Зачастую именно по причинам объемов в качестве технологий хранения и обработки информации используются распределенные
нереляционные СУБД с полноценной поддержкой эластичного масштабирования.
117

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Скорость роста массивов данных также значительная. Нередко даже дневной инкремент
данных представляет собой весьма существенный объем с точки зрения предыдущих архитектурных поколений. Например, если объемы данных традиционных АБС составляли несколько
десятков терабайт, то на сегодня никого уже не удивляет аналогичный объем данных в качестве дневного инкремента.
Большие данные, как правило, соответствуют всем трем вышеперечисленным характеристикам. При этом современный цифровой продукт должен обеспечивать эффективную работу
именно с большими данными, в противном случае высок риск утраты продуктом конкурентоспособности на рынке. Можно сказать, что современный цифровой мир одновременно является и миром продуктов, и миром больших данных.
Классический подход к работе с большими данными заключался в создании так называемого «озера данных» (Data Lake), представляющего собой набор сырых данных организации.
Все данные, тем или иным образом использовавшиеся в деятельности компании, в том числе
при предоставлении продуктов, загружались в подобное хранилище и в дальнейшем содержались там. Такие технологические решения, как экосистема Apache Hadoop или реализации
S3 хранилища/протокола, обеспечивали высокую эффективность подобного хранения. В дальнейшем инструментами машинного обучения (Machine Learning) собранные данные использовались для отработки гипотез, создания и развития новых моделей машинного обучения.
Также на них формировались различные аналитические отчеты.
Указанный подход обладал рядом недостатков, первый из которых внимательный читатель назовет с ходу. И заключается этот недостаток в отсутствии заточенности подобного хранения данных на конкретные продукты. С одной стороны, мы говорим о том, что весь фокус
внимания современной организации должен быть сосредоточен на предоставлении ценности
клиентам и партнерам посредством цифровых продуктов, с другой – данные, которые необходимы продуктам, просто «сваливаются в помойку», разбор которой вынуждает компанию
тратить существенные ресурсы. Кроме этого, отработка гипотез и обучение моделей не могут
считаться непосредственной ценностью для продукта – и это второй недостаток с точки зрения современных архитектурных подходов. Даже построение аналитических отчетов и их
последующая визуализация (нередко весьма наглядная) не могут компенсировать указанные
недостатки. Современные цифровые продукты нуждаются в аналитике реального времени для
эффективного исполнения процессов жизненного цикла, а потому и архитектура работы с данными должна подобные аналитические возможности обеспечивать. К третьему недостатку
традиционной архитектуры работы с данными следует отнести трудности при монетизации
последних. Данные и выборки из них могут (и должны) обладать собственным P&L. Современные технологические гиганты обеспечивают монетизацию не только самих сервисов, но и данных, особенно размеченных наборов. А для этого данные должны быть корректно сегментированы, причем сегментация должна отвечать потребностям рынка.
Мы уже отмечали в наших предыдущих книгах («Архитектура цифрового мира»
и «Архитектура цифровых платформ. От настоящего к будущему»), что ответом на вызовы
традиционной архитектуры работы с большими данными стал шаблон «сетки данных» (Data
Mesh). Вкратце напомним его основные особенности читателю:
• Централизованное монолитное озеро данных (Data Lake), как и традиционное хранилище данных, отсутствует. На базе технологий, обеспечивающих эффективный сбор и хранение больших данных, создаются отдельные домены данных, развитие которых осуществляется
независимо друг от друга. При этом домены данных обеспечивают в части работы с данными
118

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

следование такой ключевой тенденции развития архитектуры, как распределенность, поддерживая и технологическую и организационную ее составляющие.
• Развитие доменов данных осуществляется командами гибких практик, ответственными
за разработку тех или иных продуктов, предоставляемых организацией клиентам и/или партнерам, а также сопоставляемых им продуктовых областей. В соответствии с продуктовой логикой формируется потребность команд разработки в данных соответствующего домена.
• Сегментация доменов производится на основе продуктовой специфики, позволяющей
синхронизировать домены и автоматизируемые продукты организации между собой.
• Домены в рамках использования шаблона проектирования Data Mesh рассматриваются
как источники продуктов данных – самостоятельных компонентов продукта компании, предоставляемого клиентам и/или партнерам в соответствии с API или публикуемыми событиями
(при применении практик EDA).
Отметим, что реализовать еще один современный подход к организации аналитических
хранилищ «Озеро-хранилище данных» (Data LakeHouse) становится гораздо проще, если организация использует «сетку сервисов».
Для наглядности концепция «сетки сервисов» (Data Mesh) проиллюстрирована Рисунком 35. За основу иллюстрации принят Рисунок 13 из книги «Архитектура цифровых платформ. От настоящего к будущему».

Рисунок 35. Концепция шаблона «сетка сервисов»

119

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

В соответствии с представленным на Рисунке 35 шаблоном данные становятся продуктом. То есть с каждым продуктом компании ассоциирован свой продукт данных (в общем
случае связь может быть более сложной, нежели «один к одному»). Рассмотрим архитектуру
продукта данных для той продуктовой структуры, которую мы уже неоднократно обсуждали
в настоящей книге. Архитектурные уровни цифрового продукта, отвечающие за формирование продукта данных, аккумулируют задачи работы с продуктовыми данными, поддержки оперативного и архивного хранения, работы с контекстом процесса и т. д. Схематично концептуальная архитектура продукта данных представлена на Рисунке 36 (базируется на архитектуре
цифрового продукта, представленной на Рисунках 25 и 26).

120

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

121

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 36. Концептуальная архитектура продукта данных
На Рисунке 36 мы аккумулировали те наборы данных, которыми оперирует продукт
в соответствии с Рисунками 25 и 26. Почему же мы поступили именно таким образом? Мы
уже отмечали, что продукт предоставляет самостоятельную ценность, что только фронтальное
представление продукта не может считаться продуктом, аналогично заявка на предоставление
продукта также не может подменять собой продукт в целом. Ситуация с продуктом данных
полностью аналогична. Отдельная выборка данных не является продуктом данных, ассоциированным с продуктом компании. Продукт данных предоставляет ценность для продукта компании, а потому аккумулирует в своем составе все данные, необходимые продукту компании
для предоставления ценности клиентам и партнерам организации:
• Кэшируемые фронтальные данные, используемые компонентами фронтальной логики
цифрового продукта при предоставлении последнего посредством актуальных для него каналов обслуживания. Реализация указанного компонента продукта данных предполагает использование кэширующих компонентов.
• Оперативные данные продукта, требующие обработки в ходе исполнения продуктовой логики. При этом указанный класс данных делится на данные долговременного хранения
и данные, операции с которыми проводятся в высокоскоростном режиме (в нашем примере –
в оперативной памяти с использованием кэширующих компонентов).
• Данные бизнес-процессов, включающие в нашем примере как управляющие данные
применяемого BPM-движка, так и контекст процесса. В соответствии с вариантами развития
управления бизнес-процессами, представленными в предыдущем разделе настоящей главы,
рассматриваемый класс данных делится на данные оперативной обработки, предполагающие
долговременное хранение с применением реляционной СУБД, и быстрые данные, хранение
и обработка которых осуществляются в оперативной памяти с использованием кэширующих
компонентов.
• Интеграционные данные. Указанный класс данных особенно важен, поскольку, как бы
мы ни следовали современным архитектурным тенденциям, предполагающим минимальную
связность продуктовых ИТ-решений, обмен данными необходим как внутри организации, так
и при взаимодействии корпоративного ИТ-ландшафта с внешними системами. Этот класс данных в нашем примере предполагает кэширование и использование распределенного типа долговременного хранения с применением нереляционной СУБД для реализации в составе цифрового продукта.
• Данные архивного хранения. Для поддержки реализации указанного класса данных
в составе как продукта данных, так и ассоциированного с ним цифрового продукта используются технологии распределенной файловой системы.
Важно подчеркнуть, что в состав продукта данных входит не только хранение информации, но и логика ее обработки. Компоненты логики обработки не показаны на Рисунке
36 с целью избежать его загромождения.
При этом для реализации архитектурных уровней работы с данными мы указываем те же
технологические подходы (реляционная СУБД, кэш, распределенная файловая система), что
и для примера продукта (см. Рисунки 25 и 26 и уточнение по потенциальному развитию реализации управления бизнес-процессами на Рисунке 32).
Внимательный читатель может задать очередной злободневный вопрос: «Вот мы рассмотрели техническую организацию продукта данных. А что же он представляет собой с точки
зрения бизнеса?» Мы должны поблагодарить читателя, поскольку действительно, уделив немалое время непосредственно архитектуре, пока недостаточно раскрыли ту ценность, которую
122

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

продукт данных несет ассоциированному с ним продукту компании, а следовательно, ту опосредованную ценность, которую получает клиент. Рассмотрим данный вопрос более детально
на примере финансовой организации и финансового продукта соответственно.
Финансовый продукт (та же самая электронная банковская гарантия) предполагает оперирование огромными массивами данных в ходе процессов собственного жизненного цикла:
• Получение данных в формате заявок на продукт.
• Предоставление продукта в различных каналах обслуживания для внутренних и внешних клиентов.
• Выполнение бизнес-процессов, ассоциированных с процессами жизненного цикла продукта.
• Ведение аналитического учета по продукту (например, в формате частной бухгалтерской книги).
• Ведение синтетического учета по продукту в формате главной бухгалтерской книги.
• И т. д.
Каждый из указанных типов процессов имеет дело с данными. И если последние оказываются разрозненными, то вполне возможны как бизнес-ошибки, так и банальная техническая
перегрузка хранением избыточных с точки зрения конкретного цифрового продукта данных
(а это серьезные финансовые затраты), а также логикой сверки избыточных данных на предмет
выявления и устранения потенциальных конфликтов.
Продукт данных, сформированный на основе информации, накапливаемой и обрабатываемой для продукта организации, позволяет в значительной степени сократить ресурсные
затраты на цифровизацию жизненного цикла последнего, а также свести к минимуму потенциальные ошибки бизнес-логики. Разметка данных в составе продукта данных позволяет предоставить для каждой конкретной операции и каждого конкретного процесса жизненного цикла
продукта и его этапа собственную выборку данных, корректность которых будет обеспечена
на уровне продукта данных. Таким образом, мы приходим к выводу, что продукт данных может
и должен иметь свой собственный жизненный цикл (в общем случае отличающийся от жизненного цикла ассоциированного с ним продукта компании), при этом на каждом этапе указанного жизненного цикла продукт данных предоставляет выборку данных, применимую в общем
цифровом продукте. Пример подобной связи схематично приведен на Рисунке 37 (основан
на Рисунке 14 из книги «Архитектура цифровых платформ. От настоящего к будущему»).

123

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Оккама» в данном случае отсутствует. Во-вторых, формально одинаковое название тех или
иных этапов жизненного цикла в примере вовсе не означает путаницы при реализации конкретного продуктового ИТ-решения. В нашем примере мы рассматриваем концептуальную
архитектуру продукта и концепцию его жизненного цикла. Естественно, при реализации конкретного цифрового продукта необходимо провести соответствующую детализацию и архитектурных уровней продукта, и процессов его жизненного цикла, и ассоциированного с ним
продукта данных, и соответствующих решений при работе с данными. В настоящем примере
мы даем общие направляющие такой работы. В-третьих, задача корректной синхронизации
жизненного цикла продукта организации и продукта данных крайне важна и в обязательном
порядке должна быть решена продуктовой командой еще на этапе проектирования продуктового ИТ-решения. Архитектор, являющийся лидером технологических изменений, должен
играть в решении указанной задачи ключевую роль.
Внимательный читатель отметит факт кажущейся рассинхронизации приводимых нами
примеров: «Вы показали концептуальную архитектуру работы с данными, концептуальную
архитектуру цифрового продукта. А вот в примере компонентной структуры продукта ЭБГ Вы
указали файловые вложения, для которых архитектурного слоя в концептуальной архитектуре
продукта не приведено, в продукте данных они также не отражены». Мы со своей стороны
отметим, что неточности нами допущено не было. И в качестве ответа на замечание читателя
рассмотрим работу с таким важным элементом данных, как контент.
Под контентом (и работой с ним) мы понимаем обработку большого количества неструктурированной информации, в состав которой могут входить файлы изображений, видеофайлы,
отсканированные документы и т. д. Обработка подобной информации занимает важное место
в бизнес-процессах современной организации, то есть, как мы понимаем, изучив вопросы продуктового рефакторинга, в осуществлении автоматизации процессов жизненного цикла цифровых продуктов.
Представим себе гипотетический вариант, при котором в ходе цифровизации жизненного цикла продукта не автоматизируется работа с контентом. В таком случае клиент при взаимодействии с организацией должен предоставлять всю информацию, содержащуюся в составе
контента и ассоциированную с продуктом, непосредственно в отделения организации. Например, если речь идет об упомянутом выше продукте «Электронная банковская гарантия»,
то клиент должен непосредственно предоставить все документы, необходимые для выдачи
гарантии в отделение финансовой организации. Фактически, как может отметить читатель,
в таком случае стирается грань между бумажной и электронной банковскими гарантиями.
При любом развитии событий отсутствие автоматизированной обработки контента приводит
к необходимости непосредственного взаимодействия клиента и финансовой организации, что
значительно увеличивает издержки последней, ухудшает и клиентский опыт, и P&L продукта,
в конечном итоге резко снижая конкурентоспособность организации на рынке.
«Как же так! А мы не рассматривали элементы жизненного цикла продукта, предусматривающие работу с контентом!» – может поставить нам на вид внимательный читатель. Мы
со своей стороны отметим, что читатель в данном случае несколько торопится. Для ответа
на его замечание обратимся к платформенным сервисам, использующимся для работы с данными. Иллюстративно приведем их на Рисунке 38 (данная иллюстрация является подмножеством Рисунка 33).

125

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 38. Платформенные сервисы работы с данными
Для удобства изложения и восприятия мы сохранили на приведенной визуализации
нумерацию платформенных сервисов Рисунка 33, при этом связь сервиса работы с кэш с сервисом работы с реляционными СУБД не столь акцентирована, как на Рисунке 33, поскольку
в текущем рассуждении она не является принципиальной. Также мы не приводим конкретную
реализацию S3 (платформенный сервис 1.3.2), поскольку с точки зрения архитектурной детализации она также не может считаться принципиальной (для хранения больших данных или
неструктурированного контента можно использовать Ceph, MinIO или любую иную соответствующую требованиям конкретной компании реализацию).
Сервис 1.3 представляет собой реализацию на уровне платформенного решения работы
с распределенной файловой системой. Ввиду специфики работы с контентом последний, как
правило, также хранится в распределенной файловой системе. Благодаря указанному способу
хранения оказывается возможным обеспечить быстрое добавление контента в соответствии
с требованиями платформенного приложения (цифрового продукта), его извлечение, проведение над ним необходимых операций, таких как дедупликация, подписание, проверки на наличие вредоносного содержимого и т. д. Таким образом, с концептуальной точки зрения Рисунок
38 (а соответственно, и Рисунок 33) включает задачи работы с контентом. Требования обеспечения работы с контентом должны быть заложены в реализацию платформенного сервиса
1.3 и его технологические имплементации 1.3.1 и 1.3.2. Разумеется, функционально-информационная архитектура соответствующих сервисов должна учитывать как требования работы
с большими данными, так и требования работы с контентом. Аналогично при детализации
на уровне компонентной архитектуры должны быть предусмотрены все необходимые компоненты для полноценного решения вышеперечисленных задач. Напомним также, что архитектура в большинстве случаев не является исполняемым артефактом сама по себе, а потому при
реализации указанных платформенных сервисов все архитектурные артефакты должны быть
разработаны, протестированы и введены в эксплуатацию. Таким образом, мы можем расширить описание платформенных сервисов, приведенных на Рисунке 38, на предмет поддержки
работы с контентом. Указанное расширение продемонстрировано на Рисунке 39.

126

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 39. Расширение платформенных сервисов работы
с данными в части обработки контента
Подчеркнем, что платформенный сервис 1.3 предоставляет унифицированную реализацию алгоритмов работы с контентом, а необходимость применения последних диктуется требованиями конкретного цифрового продукта и закладывается в алгоритм соответствующего
платформенного приложения.
Внимательный читатель наверняка заинтересуется детализацией платформенного сервиса на уровне упомянутых нами артефактов: функционально-информационной и компонентной архитектур. Пока мы оставим его интерес в подвешенном состоянии, поскольку целью
настоящего раздела, как и настоящей книги, является рассмотрение архитектурных вопросов и концепции цифровых продуктов, а не проектирование платформенного сервиса работы
с контентом. Тем не менее, понимая закономерность интереса к дальнейшей архитектурной детализации, мы рассмотрим вопрос детализации платформенного сервиса в соответствии с требованиями, предъявляемыми продуктом, несколько позднее – в главе, посвященной
платформенному подходу при создании и развитии продуктов. Пока же попросим читателя
набраться терпения.
«Тем не менее Вы ответите на другой мой вопрос! Ранее Вы регулярно утверждали
необходимость слабой связности компонентов в современной архитектуре, напрямую увязывали слабую связность с поддержкой распределенности. А теперь свели в один платформенный сервис работу с контентом и большими данными. Неужели Вы сами не видите противоречия?» – воскликнет читатель. В данном случае мы можем как вступить с читателем в полемику,
так и согласиться с ним. В книге «Архитектура цифровых платформ. От настоящего к будущему» мы говорили о том, что совершенно необязательно создавать все компоненты современной платформы в виде микросервисов. Зачастую компоненты платформы могут иметь
общий релизный цикл и оказаться связанными друг с другом. Такая связь возможна при работе
с большими данными и контентом. Тем более что связь, показанная выше на Рисунке 39,
является связью уровня интерфейсов и может быть декомпозирована при дальнейшей архитектурной детализации. Но и вариант согласия с читателем также возможен. Мы можем уже
при проектировании верхнего концептуального уровня разделить задачи работы с контентом
и большими данными, предполагая, что требования, предъявляемые различными продуктами
организации к указанным направлениям работ, могут оказаться принципиально различными.
При следовании свойству открытости платформы продуктовые команды сами развивают плат127

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

Рисунок 40. Платформенные сервисы работы с данными, отдельно учитывающие задачи
работы с контентом
На приведенном выше рисунке добавлены две реализации сервиса работы с распределенной файловой системой 1.3 – 1.3.3 и 1.3.4 (выделены окантовкой). Поскольку, как мы отмечали, для хранения контента, как правило, используются технологии распределенной файловой системы, мы сохраняем абстракцию верхнего уровня (платформенный сервис 1.3) общей
для задач работы с большими данными и контентом, добавляя ей две реализации, специфицирующие именно работу с контентом. Технологические реализации сервисов 1.3.3 и 1.3.4 аналогичны сервисам 1.3.1 и 1.3.2 в части выбора программного обеспечения, выступающего
основой имплементации, но безусловно отличаются в части платформенной логики, применения технологий, выбора топологий их развертывания, формирования предоставляемых потребителям – платформенным приложениям – вариантов использования сервисов. Приведенный вариант позволяет независимо развивать, например, реализации платформенных сервисов
1.3.2 и 1.3.4, ответственных за работу с большими данными и контентом соответственно,
и обеспечивать максимальную гибкость для цифровых продуктов компании. Отметим, что при
наличии целесообразности для сервисов 1.3.2 и 1.3.4 можно использовать в том числе различные реализации S3 хранилища.
Рассматривая реализацию на уровне продуктовой логики работы с контентом, нельзя
забывать о работе с метаданными. Метаданные – это данные о данных. И они крайне важны
для корректной работы с неструктурированной информацией. Причем касается это не только
контента, но и больших данных. Структуризация неструктурированного массива информации,
содержащегося и в контенте, и в больших данных, эффективная разметка позволяют кратно,
а в иных случаях и на порядки повысить качество работы с данными. При этом сами метаданные носят структурированный характер. А на основе метаданных определяются правила
работы с собственно неструктурированной информацией – большими данными и контентом.
Если метаданные являются структурированными, то и работу с ними цифровой продукт (платформенное приложение) осуществляет с использованием сервисов работы со структурированной информацией. Для примера предположим, что продукт использует реляционную СУБД
для хранения метаданных. В таком случае платформенный сервис работы с распределенной
128

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

файловой системой должен быть связан с сервисом работы с реляционными данными. Иллюстративно это показано на Рисунке 41.

Рисунок 41. Связь сервисов работы с контентом и большими данными с сервисом работы
с реляционными данными
Как мы уже неоднократно отмечали, платформа берет на себя выполнение задач инфраструктурного характера. Примером подобной задачи может быть в том числе корректная связь
неструктурированных данных, хранящихся в распределенной файловой системе или объектном хранилище (больших данных и контента), с их метаданными и инкапсуляция соответствующей связи. Рассматриваемая связь показана на Рисунке 41 утолщенной линией между
сервисами 1.3 и 1.1. Рассмотрим пример прикладного использования данной связи. Например, при анализе заявки на электронную банковскую гарантию финансовой организации необходимо осуществить сверку данных клиентских документов. Предположим, что речь идет
о документах физического лица, указанного в гарантии, например, в качестве представителя
или уполномоченного лица компании. В таком случае в массиве контента необходимо найти
соответствующие документы и их фотокопии. Непосредственный поиск по контенту весьма
затратен с ресурсной точки зрения. В таком случае платформенное приложение может осуществить поисковый запрос по метаданным (например, серии и номеру паспорта), но непосредственно используя сервис работы с контентом 1.3. Указанный сервис, получив метаданные,
проверяет их наличие, находит дополнительные метаданные, ассоциированные с соответствующим объектом, например, идентификатор бакета в S3 хранилище, используя сервис 1.1, затем
осуществляет извлечение контента, используя технологическую реализацию сервиса 1.3.4,
и возвращает результаты платформенному приложению. В отсутствие рассматриваемой связи
разработчики платформенного приложения должны самостоятельно перегружать последнее
описанной инфраструктурной логикой, причем повторять ее в большом количестве различных
кейсов. Более того, подобная логика будет дублироваться между платформенными приложениями. В нашем примере цифровой продукт реализуется в формате платформенного приложения с применением платформенного подхода и передает служебный функционал на уровень
платформы, концентрируя свое внимание на прикладной логике – в данном случае непосредственно на процессе сверки клиентских данных, информация о которых получается им из хранилища контента.
Внимательный читатель, получив ответ на свой вопрос о работе с контентом, запасливо
приготовил для нас еще один: «Ну вот мы провели грануляцию задач, распределили продуктовую логику работы с данными по платформенным сервисам. Но как быть с задачами,
которые являются общекорпоративными? Например, с управлением мастер-данными, нормативно-справочной информацией, осуществлением аналитических расчетов?» Действительно,
129

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

приведенная читателем подборка задач носит общий характер для всей компании, они не могут
быть ассоциированы с каким-то конкретным продуктом. Но здесь и кроется главная характеристика решения вышеприведенного списка задач. Мы уже неоднократно подчеркивали тот
факт, что современная организация, стремящаяся сохранять конкурентоспособность в цифровом мире, должна пройти через продуктовую трансформацию. И по ее итогам и управление мастер-данными, и управление нормативно-справочной информацией, и аналитические
витрины должны стать продуктами с собственным жизненным циклом, с собственным P&L.
Таким образом, в современном ИТ-ландшафте общекорпоративная задача сама также является цифровым продуктом!
На первый взгляд, приведенное утверждение может показаться исключительно спорным:
традиционно подобные задачи работы с данными носили во многом инфраструктурный характер, проекты по созданию информационных систем класса MDM (master data management,
управление мастер-данными), RDM (reference data management, управление нормативно-справочной информацией), DWH (Data WareHouse, хранилище данных, отвечающее за выполнение
аналитических задач) зачастую характеризовались качественными КПЭ либо минимальным
привлечением количественных бизнес-показателей. Но в том и суть продуктовой трансформации, что лица, принимающие решения в организации, могут быть снабжены четкими и непротиворечивыми количественными показателями, позволяющими оценить выполнение столь
масштабных задач работы с данными. Более того, одной из задач работы с данными, которая должна решаться в том числе и на методологическом уровне – в концепции управления
данными, – является обеспечение монетизации данных. А основой монетизации становится
ценность продукта данных. У продукта данных есть свои потребители. Последние могут быть
внутренними и представлять продукты организации, заинтересованные в соответствующих
данных, и внешними, когда данные и их наборы предоставляются клиентам и партнерам организации. Таким образом, и при работе с данными на смену классическими информационным
системам приходят продуктовые ИТ-решения – MDM, RDM, DWH. Рассмотрим указанный
процесс подробнее.
Рассуждая о мастер-данных, тезисно напомним читателю суть сформулированного
вопроса. С этой целью повторим часть изложения, приведенного нами в книге «Архитектура
цифрового мира». Под мастер-данными понимаются такие данные, которые содержат ключевую для организации информацию (о клиентах, продуктах, услугах, персонале, складах, транспортных средствах и т. д.). Они не являются транзакционными. При этом управление подобными данными является исключительно важным для организации, поскольку ошибка в мастерданных может привести к неверной оценке рисков, некорректному взаимодействию с клиентом
и иным дорогостоящим последствиям. ИТ-решения, отвечающие за автоматизацию работы
с мастер-данными, традиционно именуются MDM (master data management).
К задачам MDM можно отнести:
• Сбор первичных данных, относящихся к категории мастер-данных. Необходимый перечень данных должен определяться концепцией управления данными, в свою очередь все
продуктовые ИТ-решения и использующиеся информационные системы предыдущих архитектурных и технологических поколений, оперирующие соответствующей категорией (или
подкатегорией) данных, должны публиковать события, относящиеся к компетенции MDM.
• Накопление мастер-данных и систематизация событий их жизненного цикла, позволяющая создать историю развития мастер-данных.
• Очистка данных, позволяющая получить лишь ключевые элементы данных, необходимые для составления «золотых» карточек клиентов и продуктов (не все данные подлежат включению в состав мастер-данных) – правила очистки также должны быть определены в концепции управления данными.
130

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Сопоставление данных – одни и те же данные могут поступать из разных продуктовых областей, имея при этом разную структуру и дополняющее или исключающее друг друга
наполнение. В этом случае MDM должен иметь возможность провести сопоставление данных,
обеспечив их корректность и непротиворечивость.
• Консолидация данных по итогам сопоставления позволяет создать эталонные, так называемые «золотые» карточки клиентов и продуктов, данные из которых могут направляться
в продуктовые области и в партнерскую экосистему.
• Распространение данных, имеющее крайне важное значение – большие объемы данных
должны распространяться таким образом, чтобы минимизировать нагрузку на другие информационные системы и архитектурные слои, а также инфраструктурную составляющую ИТландшафта организации.
Современная архитектура должна обеспечивать проектирование и реализацию MDM
с учетом необходимости решения всех указанных выше задач. При этом, как мы уже не раз
подчеркивали, должна учитываться продуктовая структура ИТ-ландшафта компании. Отметим также, что сформированные при помощи MDM «золотые карточки» являются объектами
с высоким потенциалом монетизации, а потому их корректное создание и предоставление клиентам значительно улучшают P&L продукта. Рассмотрим архитектурные вопросы реализации
продуктового MDM решения.
Для начала уточним, что в данном случае мы говорим о продуктовом MDM не в контексте «информационной системы», хранящей мастер-данные о продуктах организации
(в современных архитектурах ценность подобного решения видится несколько сомнительной),
а об MDM как цифровом продукте. Рассмотрение MDM как продукта проведем в соответствии
с архитектурными слоями, разбиравшимися ранее. При этом будем разделять рассмотрение
слоев и сопровождать их отдельными иллюстрациями, поскольку указанный подход обеспечивает наглядность и удобство восприятия. Уровень фронтального и канального представления,
а также канало-специфичной продуктовой логики в детализации для MDM продукта представлен на Рисунке 42. Подчеркнем, что речь в настоящем примере идет о концептуальной архитектуре продукта.

131

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

132

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

в число которых могут входить и специалисты поддержки продуктового ИТ-решения, внешние клиенты-потребители данных, а также партнеры организации, среди которых осуществляется, например, монетизация данных организации, отнесенных к мастер-данным и ведущихся
в соответствующем продуктовом ИТ-решении. Если потребности внутренних пользователей в мастер-данных достаточно очевидны, то что же является ценностью для клиентов
и партнеров? В случае MDM ценность представляют наборы мастер-данных, при этом правила формирования самих наборов диктуются потребностями рынка. В соответствии со сферой деятельности организации ее партнеры, например, могут использовать классификаторы
(в частности, банковские) при создании собственных приложений в рамках партнерской экосистемы. В таком случае наборы мастер-данных несут партнерам непосредственную ценность,
так как позволяют обеспечить бесшовность процессов в рамках экосистемы: те или иные процессы могут затрагивать как системы партнеров, так и самой организации, при использовании
общих наборов мастер-данных гарантируется бесшовность исполнения подобных процессов
на уровне данных. Кроме того, таким образом упрощаются релизные циклы приложений компании и ее партнеров, снижается потребность в регрессионном тестировании. Реализация взаимодействия с внутренними и внешними пользователями осуществляется посредством webинтерфейсов, а с партнерами – посредством API.
Web-интерфейсы для внутренних сотрудников и клиентов создаются с использованием
подходов микрофронтендов (microfrontends) для поддержки распределенности и модульности
фронтальных интерфейсов. Предоставление API подчиняется лучшим практикам OpenAPI.
Последние предполагают наличие слоя логики предоставления программных интерфейсов,
который мы реализуем в микросервисной парадигме – ранее мы уже отмечали, что в наших
примерах следуем указанной архитектурной концепции. Благодаря этому реализуемая логика
следует практике распределенности: отдельные компоненты могут реализовываться выделенными командами или их членами, а также независимо развертываться и масштабироваться.
Для обеспечения связи фронтальных компонентов, имплементируемых с использованием подхода микрофронтендов, с компонентами прикладной логики проектируются и создаются специальные проксирующие компоненты в соответствии с шаблоном BFF (Backend-For-Frontend).
Последние также представляют собой микросервисы. Указанным образом обеспечивается унификация контракта для клиента, а также достигается независимость развертывания и масштабирования компонентов, ответственных за различные уровни реализации логики.
Фронтальная логика продукта проектируется и создается в парадигме микросервисной
архитектуры и отвечает за формирование представления продуктов MDM. Как уже отмечалось
выше, таковыми являются выборки данных, представляющие ценность для клиентов и партнеров компании. Фронтальная логика реализуется без использования BPM-движка с целью обеспечения максимальной производительности исполнения. Аналогичным образом реализуется
канало-специфичная продуктовая логика, отвечающая за выполнение действий, зависящих
от канала коммуникации с клиентами и партнерами. Данная логика зачастую привязана к конкретному каналу обслуживания, использование BPM-движка при реализации столь точечных
компонентов логики может привести к избыточным ресурсным затратам.
Поскольку любое фронтальное решение в наш век дистанционных каналов обслуживания должно обладать исключительно высокими показателями производительности и надежности, то для обеспечения высокоэффективного доступа к данным во фронтальном слое предусмотрен механизм кэширования. Кэширующие компоненты могут использоваться не только
для обеспечения высокоскоростного доступа к данным, но и для проведения в оперативной
памяти операций, которые критичны с точки зрения быстродействия. Одновременно с этим
кэш предполагает дополнительный уровень резервирования с использованием механизмов
долговременного хранения – в нашем примере используется реляционная СУБД. Подчеркнем,
133

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

что наличие механизма долговременного хранения не отменяет необходимость поддержки
резервирования кэширующих компонентов самих по себе, а дополняет их.
Взаимодействие компонентов, представленных в концептуальной архитектуре (см. Рисунок 42), как между собой, так и с компонентами смежных архитектурных уровней, может осуществляться как напрямую, так и с использованием событийно-ориентированной парадигмы.
Для поддержки последней применяется потоковое программное обеспечение, обозначенное
на Рисунке 42 как «журналы событийного обмена и накопления данных». Ввиду того, что
мы неоднократно обращали внимание читателя на необходимость следовать принципам минимальной связности компонентов в продуктовой архитектуре, предпочтительным является способ их взаимодействия посредством событий. События могут храниться в указанных выше
журналах. Кроме того, журналы служат инструментом накопления данных и могут использоваться при передаче порций данных (наборов данных) микросервисам предоставления API.
Также они могут использоваться в сценариях прогрева кэш, обеспечивая пакетное наполнение последнего актуальными данными, либо выбирая из кэш актуализированные порции данных и гарантируя их передачу на смежные архитектурные слои, иным компонентам, входящим
в продуктовое ИТ-решение, либо смежным цифровым продуктам или внешним по отношению
к организации системам.
Не во всех случаях оптимальным с точки зрения выполнения функциональных и нефункциональных требований к цифровому продукту является использование механизма событийного обмена – может потребоваться и прямое взаимодействие компонентов. Такое взаимодействие также показано на Рисунке 42: компоненты (микросервисы) фронтальной логики
взаимодействуют с компонентами BFF и микросервисами предоставления API, дабы формировать уровень представления продукта, а также предоставлять результаты работы фронтальных
операций партнерам посредством API. В соответствии с предыдущим изложением компоненты
фронтальной логики непосредственно используют механизмы кэширования для оперативного
доступа к данным и проведения операций в оперативной памяти.
Мы сознательно не детализировали компоненты фронтальной или канало-специфичной
логики – как правило, они исключительно специфичны для продуктов конкретных организаций, мы же не стремимся раскрывать конкретику реальных продуктов, а изучаем общие закономерности, характерные для современных цифровых продуктов.
Отметим, что поскольку при создании и развитии цифровых продуктов мы применяем
платформенный подход, то многие действия инфраструктурного и вспомогательного характера, представленные на Рисунке 42, берет на себя цифровая платформа. Мы не показываем
на иллюстрации использование платформенных сервисов, чтобы не загромождать рисунок
и не затруднять его восприятие читателем. Отметим, что взаимодействие компонентов логики,
таких как компоненты фронтальной прикладной логики либо микросервисы предоставления
API с инфраструктурными компонентами, примерами которых выступают кэширующие компоненты, реляционные базы данных, журналы событийного обмена, осуществляется с применением платформенных сервисов (сервисы приведены в описании к Рисунку 33). Также
платформа берет на себя и скрывает от пользователей (разработчиков платформенных приложений) решение таких инфраструктурных задач, как прогрев кэш, резервирование кэшируемых данных и результатов выполнения операций в оперативной памяти в реляционной базе
данных и т. д. Прямое взаимодействие прикладных компонентов также может использовать
платформенные механизмы. Например, если принято решение применять шаблон сетки сервисов (Service Mesh) при интеграции компонентов, то реализацию данного шаблона также может
предоставлять платформа.
Детализация последующих архитектурных уровней цифрового продукта MDM приведена на Рисунке 43.
134

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

Рисунок 43. Уровень оперативного хранения, продуктовой и процессной логики для продукта MDM

135

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Микросервис, обеспечивающий обогащение данных при выполнении продуктовой
логики на основании информации, содержащейся в объектах хранения, таких как кэш или база
данных.
• Микросервис, описывающий модель справочных данных и логику работы с ними. Приведенный пласт логики имеет важное значение для всех прикладных компонентов.
• Микросервис, предоставляющий модели мониторинга для цифрового продукта. В том
числе может использоваться в рамках интроспекции компонентов цифрового продукта в случае применения сквозного автоматизированного продуктового мониторинга в компании.
• Микросервис, описывающий логику дедупликации данных, исключительно критичную
в MDM продукте.
• Микросервис, формирующий производственный календарь для исключения ошибок
при обработке мастер-данных, а также для учета при формировании бизнес-правил.
• Микросервис поиска контрагентов для клиентов на основании мастер-данных и построения цепочек контрагентов.
• Микросервис триггеров и механизма генерации тех или иных событий в ходе жизненного цикла продукта. Правила генерации с использованием подобного механизма могут задавать прикладные микросервисы или иные компоненты продукта.
• И т. д.
Дополнительно обратим внимание читателя на то, что в настоящем примере мы рассматриваем концептуальную архитектуру MDM продукта. Соответственно, и микросервисы в примере представлены концептуальные. При дальнейшей детализации архитектуры они могут как
объединяться между собой, так и дробиться на группы компонентов и технологических артефактов.
Взаимодействие продуктовых и обеспечивающих микросервисов между собой и другими
компонентами как рассматриваемого, так и смежных архитектурных слоев возможно в настоящем примере двумя способами: напрямую и с использованием механизмов событийного
обмена. С целью обеспечения слабой связности между компонентами продуктового ИТ-ландшафта и максимальной поддержки практик распределенности рекомендуемым является второй вариант. Для реализации парадигмы событийно-ориентированной архитектуры в нашем
примере используется потоковое программное обеспечение, предлагающее потребителям журналы событийного обмена.
Для управления бизнес-процессами в соответствии с теми принципами, которые мы описывали ранее в настоящей книге, предусмотрены отдельные компоненты, представляющие
собой микросервисы, инкапсулирующие логику управляющих действий в рамках автоматизируемых процессов жизненного цикла цифрового продукта, в данном случае MDM. Такие
микросервисы мы именуем процессными и предполагаем активное использование ими BPMдвижка, что и показано на Рисунке 43. В настоящем примере мы выделяем потенциальные процессы жизненного цикла продукта, требующие гибкого управления с задействованием BPMдвижка:
• Создание золотой карточки клиента – физического лица. При управлении мастерданными осуществляется формирование эталонного представления данных клиента – физического лица. Указанное представление может в дальнейшем монетизироваться, например,
в рамках экосистемы, составляя важную часть P&L цифрового продукта. При этом процесс
сбора, анализа и вычистки данных для формирования указанного объекта может быть достаточно сложным и регулярно изменяться в соответствии как с требованиями бизнеса, так
и с нормативными предписаниями. Ввиду подобной высокой вероятности изменений имеет
137

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

смысл предоставить инструментарий low-code для создания и редактирования бизнес-процесса.
• Создание золотой карточки клиента – юридического лица. Важность данного бизнес-процесса для обеспечения ценности цифрового MDM продукта во многом сходна с предшествующим бизнес-процессом создания золотой карточки клиента – физического лица.
В рамках процесса осуществляется сбор, анализ и вычистка данных для формирования
эталонного представления клиентской информации. Аналогично процессу для клиентов –
физических лиц эталонное представление информации по клиентам – юридическим лицам
может монетизироваться и улучшать P&L продукта. Также рассматриваемый пример процессного микросервиса задействует BPM-движок для повышения эффективности проектирования,
создания, моделирования и исполнения бизнес-процесса.
• Создание золотой карточки продукта. Аналогично представлению клиентских данных
в рамках жизненного цикла цифрового MDM продукта осуществляется сбор, анализ, вычистка
данных для формирования эталонного представления продуктов организации. То есть один
продукт (MDM) обеспечивает формирование наборов данных для представления других продуктов организации и передачи их смежным цифровым решениям в ИТ-ландшафте компании
либо в рамках экосистемы. Подобный способ организации ИТ-ландшафта позволяет придать
продуктовый характер на первый взгляд техническим общесистемным задачам, обеспечить
монетизацию данных, а также позитивно влиять на P&L всех цифровых продуктов компании.
Рассматриваемый процесс также является достаточно сложным, поэтому при его автоматизации применяется BPM-движок.
• Формирование предодобренного предложения и его шаблонизация. Мы уже отмечали
выше, что в рамках экосистемы возможна лидогенерация при помощи партнерской экосистемы. Партнерские приложения в таком случае являются потребителями как самих предодобренных предложений, так и их шаблонов. Соответственно, в рамках обеспечения ценности для
партнеров организации необходимо максимально эффективным образом автоматизировать
процесс формирования таких предложений и их шаблонов с последующим предоставлением
партнерам посредством, например, механизмов открытых API. Поэтому в нашем примере мы
выводим рассматриваемый бизнес-процесс в формате отдельного процессного микросервиса
с использованием BPM-движка.
• Отслеживание изменений и формирование триггеров. Мастер-данные должны быть
в постоянно актуальном состоянии. При этом они распространяются как внутри ИТ-ландшафта организации, так и среди партнеров компании, с которыми оформлены соответствующие договоренности. Кроме того, в современном цифровом мире постоянно могут возникать
события, требующие актуализации мастер-данных и их последующего обновления для потребителей. Вопросы обновления относятся к архитектурному уровню интеграционной логики
продукта, который будет рассмотрен ниже. Но на уровне продуктовой логики MDM продукт
должен постоянно отслеживать изменения в мастер-данных и формировать события их обновления для потребителей. Триггеры обновления могут быть самыми разными, также они могут
изменяться по ходу жизненного цикла продукта. Ввиду этого процесс отслеживания изменений и формирования триггеров целесообразно оформить в виде полноценного бизнес-процесса, то есть, с технической точки зрения, в формате процессного микросервиса с применением BPM-движка.
При реализации MDM продукта в конкретной организации список процессов может
заметно отличаться от приведенного выше – мы описываем бизнес-процессы продукта для
примера.
Указанные выше процессы могут реализовываться с применением шаблонов как оркестровки, так и хореографии. Окончательный выбор должна осуществлять продуктовая команда
138

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

вместе с архитектором, который в процессе выбора должен играть лидирующую роль. При
выборе оркестровки соответствующий процессный микросервис играет центральную роль
в бизнес-процессе. В случае следования шаблону хореографии процесс децентрализован
с точки зрения исполнения, а взаимодействие составляющих частей осуществляется в событийно-ориентированной парадигме, для чего используется соответствующее программное
обеспечение, предоставляющее реализацию журналов для хранения событий.
Взаимодействие процессных микросервисов между собой, с продуктовыми и обеспечивающими микросервисами может осуществляться напрямую или с использованием механизмов событийного обмена. С целью обеспечения слабой связности компонентов и поддержки
распределенности, как и в случае взаимодействия между собой продуктовых и обеспечивающих микросервисов, рекомендуемым является второй вариант.
Для эффективного выполнения бизнес-процессов необходима поддержка управления
контекстом, а также хранение оперативных данных исполняющихся экземпляров процессов.
Решение указанных задач осуществляется с использованием базы данных на основе реляционной СУБД, показанной на Рисунке 43. На иллюстрации она экранируется журналом событийного обмена для сокращения числа точечных прямых взаимодействий микросервисных
компонентов с базами данных. Описанный подход позволяет обеспечить независимое масштабирование компонентов процессной и прикладной логики и объектов хранения. Отметим,
что для масштабирования столь разных с точки зрения реализации и топологии компонентов
обычно применяются различные методики и различное вспомогательное инфраструктурное
программное обеспечение, вследствие чего их разграничение является оправданным.
Собственно хранение мастер-данных является в случае MDM продукта весьма важным
вопросом. Как правило, мастер-данные характеризуются исключительно большими объемами,
а также разнородностью ввиду покрытия самых разных критичных для компании предметных областей. Последнее означает, что варианты использования для тех или иных элементов
и наборов данных могут оказаться принципиально различными. То есть с функциональной
точки зрения в рамках создания и развития продукта к ним предъявляются различные требования. Как следствие, нефункциональные требования, например, в части производительности и надежности также могут отличаться в зависимости от того или иного набора данных.
Классические реляционные СУБД в таком случае не являются лучшим решением для управления хранением подобным образом организованных данных, а потому мы используем для
решения указанной задачи нереляционную СУБД, как и показано на Рисунке 43. Напомним,
что ранее мы уже вводили данный тип программного обеспечения. Тогда мы использовали
его на уровне интеграционной логики цифрового продукта как раз таки ввиду разнородности
используемых данных. В качестве примеров технологических реализаций платформенных сервисов работы с нереляционными СУБД мы приводили такое программное обеспечение, как
Apache Cassandra и ScyllaDB.
Для обеспечения эффективной работы с данными используются кэширующие компоненты. Как и для слоя фронтальной и прикладной логики они могут применяться для кэширования часто используемых данных (исключительно важный аспект в случае обработки мастерданных ввиду их значительных объемов), а также для проведения ресурсоемких операций
в оперативной памяти. Для обеспечения высокой надежности и резервирования кэш кэширующие компоненты могут взаимодействовать с нереляционной базой данных, сохраняя снимки
состояния, а также используя их при восстановлении. Данное взаимодействие на Рисунке
43 показано как прямое.
В состав мастер-данных может также входить и контент, например, ассоциированный
с теми или иными наборами мастер-данных. Он также представлен на Рисунке 43. Конкретные технологические реализации работы с контентом, как и в случае иных инфраструктурных
139

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

компонентов, определяются технологическим стеком продуктового ИТ-решения и применяемой в компании платформы.
Как и при описании примера архитектурного уровня фронтальной и прикладной логики
цифрового MDM продукта, мы должны подчеркнуть, что при реализации продуктового ИТрешения используется платформенный подход, а потому имплементацию инфраструктурных
и общих задач берет на себя цифровая платформа. Микросервисы должны включать встраиваемые библиотеки, содержащие платформенный SDK, и использовать последний при реализации служебных операций – внимание продуктовой команды необходимо концентрировать непосредственно на продуктовой логике. То есть для работы с потоковым программным
обеспечением, кэширующими компонентами, базами данных необходимо использовать платформенные сервисы. Последние не показаны на Рисунке 43, чтобы не загромождать его
и не ухудшать восприятие. При этом различные компоненты логики продуктового решения
могут применять различные варианты использования, предоставляемые платформенными сервисами.
Выше мы уже отмечали, что в настоящем примере мы рассматриваем концептуальную
архитектуру цифрового продукта. Это означает, что единичное отображение тех или иных компонентов на Рисунке 43 (например, нереляционной СУБД) вовсе не означает их единичное
наличие в структуре продукта. Мы отображаем принципиальный подход к архитектуре продуктового ИТ-решения и его последующей реализации. Но дальнейшая архитектурная детализация может привести нас (и скорее всего приведет) к декомпозиции подобных инфраструктурных элементов. Например, та или иная группа продуктовых микросервисов может работать
с собственным кластером распределенной базы данных и применять актуальные для нее варианты использования платформенного сервиса.
На Рисунке 44 приведена детализация архитектурных уровней интеграционной логики
и архивного хранения рассматриваемого нами примера цифрового MDM продукта.

140

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 44. Уровень интеграции и архивного хранения
MDM продукта
Для проектирования и реализации интеграционной логики используется парадигма микросервисной архитектуры, как и в случае реализации продуктовой логики на смежных архитектурных слоях, рассмотренных ранее. На Рисунке 44 показаны два типа микросервисов, относящихся к интеграционному уровню:
• Микросервисы интеграционной логики, определяющие общие принципы функционирования продуктового ИТ-решения. Указанный набор микросервисов определяет реализацию
базовых принципов обмена данными, обеспечивая максимальную унификацию интеграционных взаимодействий со смежными продуктовыми ИТ-решениями, унаследованным ИТ-ландшафтом (в случае, если процесс продуктовой трансформации не завершен, либо по каким-то
причинам переработка части унаследованных информационных систем предыдущих архитектурных и технологических поколений признана нецелесообразной), внешними с точки зрения
организации ИТ-решениями, например, банками кредитных историй.
• Микросервисы – интеграционные адаптеры. Данные микросервисы являются фасадами
непосредственного взаимодействия MDM продукта со смежными продуктовыми ИТ-реше141

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ниями, унаследованными системами, внешними решениями. Они принимают стандартизированным образом сформированные порции данных от микросервисов интеграционной логики
и передают их контрагентам. Аналогично они принимают данные от контрагентов и передают
их для дальнейшей обработки в микросервисы интеграционной логики. Естественно, сами
адаптеры также могут осуществлять те или иные преобразования над передаваемыми данными, но эти преобразования носят сугубо технический характер и учитывают особенности
конкретного решения, интегрируемого с рассматриваемым в настоящем примере продуктом.
Они инкапсулируют точечные характеристики взаимодействия от общей продуктовой логики,
включая интеграционную. Таким образом, становится возможным независимо изменять каждую интеграцию и обеспечивать минимальное влияние подобного изменения на цифровой
продукт. Указанной архитектурной организацией достигается независимость жизненных циклов цифровых продуктов компании друг от друга посредством слабой связности продуктовых
ИТ-решений и иных компонентов ИТ-ландшафта.
Микросервисы интеграционной логики представляют собой реализацию общих принципов интеграции продукта с внешними по отношению к нему системами, из которых продукт
получает данные либо которые заинтересованы в продуктовых данных. Поскольку в настоящем примере мы рассматриваем продукт, ценность которого основывается на мастер-данных,
то интересантов во взаимодействии с ним достаточно много – фактически все продуктовые
ИТ-решения компании так или иначе являются его клиентами, то есть, как добавил бы внимательный читатель, для них он представляет ценность. В таком случае имеет смысл выделить
следующие (еще раз напомним, концептуальные) микросервисы рассматриваемого класса:
• Микросервис правил расчета инкремента. Как правило, при взаимодействии с MDM
потребитель осуществляет первичную загрузку мастер-данных, а впоследствии получает
инкременты, определяющие, какие данные и каким образом изменились, были добавлены или
удалены. Отметим, что в самих мастер-данных удалений, как правило, не происходит – данные помечаются как удаленные и/или неактуальные, в дальнейшем их использование в организации в большинстве случаев табуировано (за исключением, вызванным регуляторными
потребностями либо исполнением экземпляров бизнес-процессов, использующих старые данные ввиду особенностей бизнес-логики). Задачей MDM является регистрация потребителей
и расчет требуемых им инкрементов, для чего может использоваться самостоятельный объект
логики, в случае нашего архитектурного подхода реализуемый в виде микросервиса. Еще раз
подчеркнем, что данный микросервис концептуальный, а потому может быть декомпозирован
при дальнейшей детализации архитектуры.
• Микросервис правил распространения инкремента. Каждое интеграционное взаимодействие уникально, но существуют общие правила работы с инкрементами, основывающиеся
на частоте их распространения, объеме передаваемой информации, требованиях по скорости
передачи и т. д. Обработка указанных правил осуществляется выделенным микросервисом.
• Микросервис списка получателей обеспечивает регистрацию интересантов мастер-данных и правила взаимодействия с ними. Отметим, что в соответствии с принятой в организации концепцией управления данными внешние системы, унаследованные компоненты ИТландшафта и смежные продуктовые ИТ-решения могут выступать источниками обновления
мастер-данных. Поэтому рассматриваемый микросервис может также управлять правилами
получения новых данных, на основании которых вносятся изменения в мастер-данные организации, то есть, выражаясь «архитектурным языком», в продукт данных, ассоциированный
с цифровым MDM продуктом.
• Микросервис правил структуризации данных определяет логику, в соответствии с которой мастер-данные, их наборы и инкременты структурируются для обеспечения интеграцион142

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ных взаимодействий. Структуризация может предполагать изменение и оптимизацию форматов передачи, разбиение в случае больших объемов, накопление для пакетной передачи и т. д.
Микросервисы, представляющие собой интеграционные адаптеры, в нашем примере
показывают взаимодействие со смежными продуктовыми ИТ-решениями и внешними с точки
зрения компании системами. В нашем примере предполагаем, что организация уже успешно
осуществила продуктовую трансформацию, поэтому интеграция MDM продукта с унаследованным ИТ-ландшафтом не требуется. В примере показаны адаптеры к таким продуктам, как
депозиты, кредиты, электронные банковские гарантии, аккредитивы (часто они объединяются
с гарантиями, но мы предполагаем, что компания в нашем случае с целью максимальной грануляции продуктов разделила аккредитивы и гарантии на два разных цифровых продукта).
Адаптеры к внешним системам показаны обезличенно.
Взаимодействие микросервисов между собой, как и в случае уровня прикладной продуктовой логики, может осуществляться как напрямую, так и посредством обмена событиями, для
чего предусмотрена поддержка в виде журнальной архитектуры. Отметим, что журналы интеграционного обмена могут использоваться также и в качестве технической реализации обмена
данными со смежными продуктовыми ИТ-решениями или внешними системами, а потому
программное обеспечение, реализующее концепцию журналов, должно поддерживать сегментацию. Повторим, что мы рассматриваем концептуальную архитектуру, а потому единственный экземпляр программного обеспечения уровня концептуальной архитектуры может
декомпозироваться и детализироваться при проектировании компонентной и технологической
архитектуры. Добавим также, что рекомендуемым является взаимодействие микросервисов
между собой посредством событийного обмена. Данная парадигма особенно важна для цифрового MDM продукта, поскольку во взаимодействии с ним заинтересована преимущественная
часть ИТ-ландшафта, а нагрузочные показатели указанного взаимодействия нередко оказываются максимальными или одними из максимальных среди всех в ИТ-архитектуре организации.
Ранее при рассмотрении примеров концептуальной архитектуры цифровых продуктов
мы отмечали, что интеграционные данные имеет смысл хранить в распределенной базе данных на основе СУБД NoSQL типа ввиду разнородности передаваемых данных и необходимости их эластичного и независимого с точки зрения отдельных наборов данных масштабирования. В ходе предшествующего изложения для хранения продуктовых данных мы выбрали
аналогичный тип хранения ввиду масштабности и разнородности мастер-данных. Разумеется,
в таком случае для хранения интеграционных данных с целью унификации мы также используем распределенную NoSQL базу данных. Кроме того, необходимо обеспечивать производительность и надежность в случае работы с интеграционными данными: данные об операциях,
подлежащие передаче в смежные решения, должны быть отправлены по назначению, полученные данные – быть сохранены вне зависимости от доступности тех или иных компонентов или
смежных решений. Для этого используется механизм кэширования. Для резервирования кэш
применяется хранилище интеграционных данных, сегментированное необходимым образом.
Подчеркнем, что взаимодействие с инфраструктурными компонентами (кэш, базы данных, журнальное программное обеспечение событийного обмена) осуществляется посредством платформенных сервисов. Топологии развертывания технологий и варианты использования сервисов могут отличаться в зависимости от требований потребителей.
Уровень архивного хранения на Рисунке 44 детализирован в значительно более краткой степени по сравнению с другими архитектурными уровнями. Логика передачи данных
на архивное хранение из хранения оперативного реализуется в парадигме микросервисной
архитектуры. Проектируемые и создаваемые микросервисы определяют те бизнес-правила,
на основании которых информация может быть признана архивной. В случае продукта MDM
это особенно важно, поскольку, как мы отмечали выше, хорошим тоном считается не удалять
143

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

мастер-данные, а помечать их неактуальными и поддерживать историчность наборов данных.
Исходя из этого, объемы сохраняемой информации оказываются попросту огромными, обеспечение хранения весьма дорогостоящим, а извлечение данных крайне ресурсоемким процессом. На уровне бизнес-правил определяются критерии архивации данных, а логика, реализуемая в микросервисной парадигме, отвечает за сам процесс архивации. Для архивного хранения
используются технологии распределенной файловой системы. Архивация контента в примере
не показана отдельно, поскольку для его хранения исходно используется распределенная файловая система. Не забываем, что взаимодействие с инфраструктурными компонентами осуществляется при помощи платформенных сервисов.
Отвечая на ранее заданные вопросы читателя, мы показали, что в современном продуктовом ИТ-ландшафте становится возможным реализовать такой сложный программный комплекс, как MDM, в виде цифрового продукта. Данный продукт обеспечивает ценность как для
внутренних потребителей, так и для клиентов и партнеров организации. Мы подробно рассмотрели пример концептуальной архитектуры такого продукта. Покажем также, что она полностью вписывается в тот пример продуктовой архитектуры, который мы приводили для кредитного продукта и электронной банковской гарантии. Проиллюстрируем архитектуру цифрового
MDM продукта Рисунками 45 и 46, основываясь на Рисунках 25 и 26 для продуктовой архитектуры, Рисунках 42—44, описанных выше, Рисунке 33, описывающем архитектуру сервисов
платформы, а также Рисунке 41 с приведенными на нем уточнениями платформенных сервисов в части работы с данными.

144

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 45. Концептуальная архитектура продукта MDM (часть 1)
На Рисунке 45 показана концептуальная архитектура продукта в части архитектурных
слоев фронтального и канального представления, канало-специфичной продуктовой логики,
а также оперативного хранения продуктовых данных. Представлен перечень используемых
145

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

цифровым продуктом на указанных архитектурных уровнях платформенных сервисов, а также
технологии, лежащие в основе реализации последних. Мы специально выбрали технологический стек, отличный от представленных ранее по ходу настоящего изложения примеров цифровых продуктов, чтобы показать гибкость современной продуктовой архитектуры и платформенных подходов – при создании и развитии разных цифровых продуктов компании могут
использоваться различные технологические реализации платформенных сервисов, поддерживаемые цифровой платформой организации. Примеры критериев выбора мы уже описывали
ранее.
На уровне фронтальной и канальной логики используется язык разработки Java – один
из наиболее популярных на сегодняшний день фреймворков разработки. Забегая вперед, отметим, что он применяется на уровне всего продукта, хотя, это, в общем случае, и не является обязательным. Для создания пользовательских представлений применяется фреймворк
Angular, поддерживающий шаблон микрофронтендов. Предоставление API осуществляется
посредством инструментария Gravitee и платформенного сервиса 3.2 (здесь и далее нумерация
платформенных сервисов соответствует Рисунку 33). В качестве программного обеспечения,
поддерживающего событийный обмен (и журнальную парадигму), используется программное
обеспечение Apache Kafka и платформенный сервис 2.1.1. Для кэширования применяется
программное обеспечение Infinispan и платформенный сервис 1.4.2. В качестве реляционной
СУБД используется PostgreSQL. Отметим, что применение платформенного сервиса в этом
случае на Рисунке 45 не показано. Как мы отмечали ранее (и проиллюстрировали Рисунком
42), прямое взаимодействие продуктовых компонентов осуществляется с кэширующим компонентом и журнальным программным обеспечением событийного обмена. Уже посредством
них используется реляционная СУБД. При этом данное взаимодействие является неявным для
платформенного приложения и осуществляется в результате взаимодействия платформенных
сервисов и их реализаций. Сервис 2 взаимодействует с сервисом 1, а сервис 1.4 взаимодействует с сервисом 1.1 (см. Рисунок 33).
На уровне канало-специфичной продуктовой логики используется язык разработки Java
и программное обеспечение событийного обмена в журнальной парадигме Apache Kafka. Применяется платформенный сервис 2.1.1.
На уровне оперативного хранения продуктовых данных используется язык разработки
Java, программное обеспечение событийного обмена Apache Kafka, нереляционная СУБД
Apache Cassandra для непосредственного хранения мастер-данных, Infinispan для кэширования, технологии реализации S3 хранилища для хранения неструктурированного контента.
Применяются платформенные сервисы 1.2.1, 1.3.4, 1.4.2, 2.1.1. Требования, предъявляемые
продуктом в части хранения данных, предполагают, как мы отмечали ранее, резервирвирование кэшируемой информации в нереляционной базе данных, в результате чего платформенное
решение претерпевает развитие: платформенный сервис 1.4 должен использовать для решения
указанной задачи не только сервис 1.1, как показано на Рисунке 33, но и сервис 1.2. Данное
уточнение мы проиллюстрируем чуть позже по ходу настоящего раздела.
Концептуальная архитектура остальных архитектурных уровней MDM продукта представлена на Рисунке 46.
На Рисунке 46 показана концептуальная архитектура уровней продуктовой логики, интеграции и архивного хранения с применением технологического стека цифрового продукта
MDM и соответствующих платформенных сервисов.

146

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 46. Концептуальная архитектура продукта
147

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

MDM (часть 2)
Для реализации архитектурного уровня продуктовой логики и управления бизнес-процессами используется язык разработки Java, движок управления бизнес-процессами BPM
Camunda, сохраняющий состояние и контекст процесса в базе данных на основе СУБД
PostgreSQL, программное обеспечение событийного обмена Apache Kafka, Infinispan для
кэширования, технологии реализации S3 хранилища для хранения неструктурированного контента. Отметим, что именно на рассматриваемом архитектурном уровне не применяется распределенная СУБД Apache Cassandra – данная технология используется при реализации смежного уровня хранения продуктовых данных и не относится напрямую к уровню продуктовой
логики и управления бизнес-процессами. Применяются платформенные сервисы 1.1.1, 1.3.4,
1.4.2 (вновь используем нумерацию сервисов, соответствующую Рисунку 33) в части работы
с данными, 2.1.1 для обеспечения потоковой передачи данных с поддержкой событийного
обмена, 4.1.1 и 4.2.1 для управления бизнес-процессами в соответствии с шаблонами оркестровки и хореографии. Напомним читателю, что платформенное решение предоставляет унифицированный сервис управления бизнес-процессами 4, позволяющий скрыть от платформенного приложения подробности реализации указанных шаблонов.
На архитектурном уровне интеграционной логики и наполнения данными используется
язык разработки Java, программное обеспечение событийного обмена Apache Kafka, Infinispan
для кэширования, распределенная NoSQL СУБД Apache Cassandra для хранения наборов
данных в рамках интеграционных взаимодействий. Применяются платформенные сервисы
1.2.1 и 1.4.2 для работы с данными и 2.1.1 для обеспечения потоковой передачи данных с поддержкой событийного обмена.
На архитектурном уровне архивного хранения используется язык разработки Java, распределенная NoSQL СУБД Apache Cassandra, выступающая в качестве источника оперативных данных цифрового продукта, и технологии реализации S3 хранилища для хранения
архивных продуктовых данных. На основании детализации концептуальной архитектуры рассматриваемого архитектурного уровня, представленной ранее на Рисунке 44, применяются
платформенные сервисы 1.2.1 и 1.3.2 для работы с технологиями оперативного и архивного
хранения соответственно.
Резюмируя вышеизложенное, мы можем отметить, что в рамках продуктовой трансформации ИТ-ландшафта возможно представление ИТ-решения класса MDM в формате цифрового продукта, обладающего ценностью для внутренних и внешних клиентов и партнеров. При
этом архитектура указанного продукта вписывается в то архитектурное представление, которое актуально и для традиционных продуктов, не вызывающих отторжения у читателя, таких
как кредиты или электронные банковские гарантии. То есть современная компания должна
стремиться к тому, чтобы в ее ИТ-ландшафте была не информационная система MDM, а цифровой продукт MDM.
Решения по работе с нормативно-справочной информацией (RDM) во многом схожи
в части архитектуры с решениями класса MDM. Отличия заключаются в конкретных данных,
хранимых и обрабатываемых ими. Нередко данные решения совмещаются в одном программном комплексе. Поэтому мы не будем проводить детализацию архитектуры RDM, а примем,
основываясь на разборе продуктового ИТ-решения MDM, что RDM также представим в формате цифрового продукта. Сейчас же мы рассмотрим важный вопрос, также поднятый ранее
читателем, возможна ли продуктовая организация хранилища данных, то есть представление
хранилища как цифрового продукта.
Когда мы говорим о хранилище данных, об аналитических отчетах и т. д., то возникает
впечатление огромного, как бы нависающего над компанией и даже выходящего за ее пределы
программного комплекса. И последний на первый взгляд вроде бы не соответствует представ148

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

лениям о гибкой и сегментированной продуктовой архитектуре. Необходимо сразу отметить,
что описанное выше представление соответствует действительности только в одном пункте:
современное хранилище не только может, но и должно выходить далеко за пределы компании.
Но и современный цифровой продукт также ни в коем случае не может быть ограничен организационными рамками – он может использоваться в рамках партнерской экосистемы, которую для поддержки собственной конкурентоспособности обязана развивать каждая компания.
Все остальные представления о хранилище данных, возникающие из подсознания, являются
устаревшими и не могут быть приняты во внимание. Поскольку вопрос построения подобных
программных комплексов предельно тесно связан с тематикой настоящего раздела, а читатель
задал вопрос об организации хранилища в формате продукта, уместно далее рассмотреть базовые принципы построения подобных ИТ-решений в соответствии с продуктовым и платформенным подходом.
Классические подходы к организации хранилищ предполагали длительный и ресурсоемкий сбор данных из источников, число которых было жестко определено, дальнейшее накопление информации в «сыром виде», вычистку данных и построение масштабных аналитических витрин. Мы не будем разбирать в настоящей книге разницу между классическими OLTP
и OLAP базами данных – данная тема интересна скорее историкам развития отрасли информационных технологий. Современная архитектура не должна проводить жесткой границы между
транзакционной и аналитической работой, более того, долговременное построение аналитических витрин, ставшее в свое время притчей во языцех, не отвечает задачам обеспечения конкурентоспособности компаний. Аналитика должна рассчитываться в режиме реального времени.
Более того, результаты аналитических расчетов должны использоваться в бизнес-процессах,
из чего непреложно следует тот факт, что класс критичности ИТ-решения и конкретного бизнес-процесса должен распространяться и на аналитическую составляющую. Времена, когда
хранилища соответствовали классу критичности Business Operational (при времени восстановления вплоть до нескольких рабочих дней), безвозвратно канули в Лету.
Аналогично построение классических «озер данных» (Data Lake), предполагавших
накопление всех сырых данных организации в решениях по работе с большими данными,
например, Apache Hadoop, с последующей отработкой моделей машинного обучения (Machine
Learning), также не может считаться приемлемым в современном цифровом мире. Аналитика
реального времени должна строиться на больших данных, собираемых из множества источников, количество которых может динамически изменяться. При этом именно большие данные
должны быть основой для расчетов. И расчетов адресных – не выдавать общие закономерности,
а предоставлять четкие и конкретные результаты, позволяющие принимать решения как руководителям, использующим графические представления, так и бизнес-процессам, в автоматическом режиме взаимодействующим с хранилищем. Фактически уже по приведенному краткому описанию можно понять, что требования к хранилищу уже предъявляются продуктовые.
Прежде чем перейти к примеру продуктовой архитектуры современного хранилища,
сформулируем базовые требования к рассматриваемому цифровому продукту. Как обычно,
в случае продукта следует начать разговор с той ценности, которую он несет клиентам и партнерам. Отметим, что ценность может быть и опосредованной, предоставляемой внутренним
клиентам. Потребителями, то есть получателями ценности продукта, выступают:
• Должностные лица компании, получающие наглядную аналитику на основе данных.
• Продуктовые бизнес-процессы, требующие в рамках своего исполнения результатов
аналитических расчетов, например, для предоставления таргетированных предложений клиентам.
• Собственно клиенты, получающие таргетированные предложения.
149

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Аналитики данных, исследующие модели и закономерности методами машинного обучения.
• Партнеры компании, создающие экосистемные приложения на основе данных, их подмножеств и результатов расчетов.
Приведенный список является обобщенным и безусловно должен быть уточнен и детализирован в случае построения конкретного хранилища. Для нашего общего примера он является достаточным.
Следующий шаг при рассмотрении примера – базовый обзор возможных источников данных. Сразу отметим, что число источников может изменяться динамически и не является фиксированным. Поэтому аналитический продукт (мы можем называть современное хранилище
именно так) Data Warehouse (DWH) должен определять общие правила работы с источниками
данных, дабы обеспечить соответствующую гибкость работы. К типам источников можно отнести следующие:
• Унаследованные хранилища организации, созданные в соответствии с архитектурными
и технологическими подходами предыдущих поколений. Как правило, при интеграции с ними
возможны выгрузки в форматах, определяемых использовавшимися в их составе СУБД.
• Унаследованные компоненты ИТ-ландшафта. До завершения продуктовой трансформации с ними требуется интеграция, отметим также, что те или иные системы предыдущих поколений могут сохраниться, в результате чего с ними следует поддерживать возможности интеграции. Взаимодействие может осуществляться с использованием API, файловой
выгрузки, репликации баз данных и т. д. Конкретный механизм зависит от унаследованной
системы.
• Перспективные продуктовые ИТ-решения. В случае, если они выстраиваются в рассматриваемой нами в настоящей книге современной архитектурной парадигме с использованием
платформенного подхода, то такая интеграция может осуществляться в бесшовном режиме.
• Информационные системы, выполняющие важные специфические функции. Такие
системы не могут быть отнесены к продуктовым ИТ-решениям, но вместе с тем их некорректно считать унаследованными. Многие ERP, MES, SCADA системы являются важными
поставщиками данных, при этом в настоящий момент не могут быть преобразованы в цифровые продукты по независящим от организации обстоятельствам. В таком случае необходимо использовать поддерживаемые ими протоколы интеграции, разумным образом добиваясь
технологической унификации. Одновременно с этим поставщики подобных решений также
должны планировать их трансформацию в современный продуктовый формат. Отметим, что
лидеры мирового рынка идут именно таким путем.
• Партнерские приложения. Организация, планируя и контролируя развитие собственной экосистемы, должна формировать такие требования к партнерам, чтобы взаимодействие
с их приложениями, в том числе в части интеграции с аналитическим продуктом DWH, было
с технической точки зрения максимально близко к взаимодействию с перспективными продуктовыми ИТ-решениями, представленными выше.
• Внешние системы, являющиеся источниками данных, необходимых для формирования ценности аналитического продукта. Примерами таких систем могут выступать социальные
сети или системы телекоммуникационных операторов. Разумеется, юридическая плоскость
таких интеграций должна быть корректно оформлена. С технической точки зрения интеграция
решается путем использования внешних API.
• И т. д.

150

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Необходимо обратить внимание читателя на то, что объемы передаваемых данных являются весьма значительными. В этой ситуации при проектировании и реализации цифрового аналитического продукта DWH необходимо предусматривать такие механизмы, которые
позволят обеспечивать максимально эффективную передачу подобных объемов данных, их
накопление, обработку ошибочных ситуаций и т. д. Если мы говорим о том, что требования к классу критичности хранилища резко возросли, характеризуясь показателями Mission
Critical (99,99 или 99,999), то исполнение интеграционных взаимодействий должно осуществляться таким образом, чтобы обеспечить соответствие заявленному классу критичности.
К слову, практики событийно-ориентированной архитектуры EDA при таких требованиях
к обмену данными являются незаменимым подспорьем.
Продуктовая логика должна реализовываться таким образом, чтобы обеспечить максимально быстрое исполнение. Для соответствия подобному требованию невозможно работать
с большими данными как с большой помойкой классических «озер данных». Данные необходимо сегментировать и определять локальные продукты данных, которые будут связаны между
собой по принципу Data Mesh. Выполнение аналитических расчетов следует осуществлять
при помощи технологий аналитических СУБД реального времени, примерами которых могут
выступать ClickHouse, Tarantool или Apache Druid. Некоторые из перечисленных продуктов
именуют себя OLAP, сохраняя терминологическую преемственность с аналитическими решениями предыдущих поколений, однако здесь ситуация во многом аналогична нашим рассуждениям об информационных системах, на смену которым пришли продуктовые ИТ-решения.
Приведенные выше примеры технологий позволяют осуществлять исключительно высокопроизводительные расчеты, предоставляя клиентам витрины с результатами расчетов (Data Marts).
При этом указанные решения зачастую нуждаются во внешних механизмах резервирования
для поддержки заявленных ранее классов критичности.
На Рисунке 47 схематично представлена концептуальная архитектура слоя фронтального и канального представления, а также канало-специфичной продуктовой логики аналитического продукта DWH.

151

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 47. Концептуальная архитектура слоя фронтального и канального представления и канало-специфичной продуктовой логики аналитического продукта
Концептуальная архитектура, схематично проиллюстрированная на Рисунке 47, визуально близка к концептуальной архитектуре фронтального слоя MDM продукта, представленной ранее на Рисунке 42. Но в ней присутствуют важные отличия, которые не позволяют утверждать, что данные архитектуры являются идентичными.
Архитектурный уровень фронтального и канального представления является основным
средством предоставления ценности клиентам. Клиентами аналитического продукта DWH
в нашем примере выступают внутренние сотрудники, к числу которых в случае аналитического продукта могут быть отнесены и высшие должностные лица организации, а кроме того,
внешние клиенты и партнерские приложения, например, в рамках экосистемы. В примере
на Рисунке 47, как и в случае Рисунка 42, показаны Web-интерфейсы внутренних сотрудников и внешних клиентов. Разумеется, могут присутствовать и другие каналы взаимодействия,
но все их множество на рисунках не показано с целью обеспечения удобства восприятия. Фронтальные интерфейсы реализуются в соответствии с шаблоном микрофронтендов для обеспечения модульности и гибкости уровня представления. Как правило, эффективная работа
152

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

с представлением аналитических данных является весьма трудоемкой и требует развитых возможностей кастомизации в соответствии с потребностями пользователей. Поэтому реализовывать ее «с чистого листа», полагаясь исключительно на возможности продуктовой команды
разработки, выглядит избыточно оптимистичным и нерациональным. Для решения указанной
задачи имеет смысл добавить в архитектуру BI-инструмент, требованием к которому выступят широкие возможности кастомизации, встраивания в архитектуру и эффективного оперирования данными, а также развитый потенциал интеграции с различными хранилищами.
Примерами таких технологий могут выступать Apache Superset или Pentaho BI. Существует
и большое количество коммерческих решений. На Рисунке 47 решение данного класса показано как «Инструмент визуализации». При этом связь инструмента визуализации с аналитической СУБД не отображена с целью исключения загромождения иллюстрации, поскольку аналитика будет осуществляться на смежном архитектурном слое. В настоящем примере инструмент
визуализации получает и при необходимости предоставляет данные из компонентов фронтальной логики, микросервисов BFF, а также кэша фронтальной логики.
Важным аспектом, который не рассматривался в контексте MDM продукта, но имеет
исключительную значимость для аналитического продукта, а потому также представлен
на Рисунке 47, является наполнение данными партнерской экосистемы. В случае аналитического продукта рассматриваемый аспект имеет важное значение для монетизации данных: осуществление сбора данных на уровне хранилища позволяет формировать фактически любые
наборы данных на основании информации, представленной в организации, предоставлять их
партнерам, монетизируя как сбор и хранение, так и обработку данных. Последнее также актуально – в качестве наборов данных для наполнения экосистемы могут выступать не только
и не столько «сырые» данные компании, сколько результаты аналитических расчетов, получаемые в ходе исполнения процессов жизненного цикла продукта. Отметим тот факт, что
объемы подобной выдачи данных являются весьма значительными (зачастую даже отдельная выдача данных для экосистемы может соответствовать определению больших данных),
при этом частота выдачи потенциально варьируется. Поэтому ограничиваться только принципами открытых API для аналитического продукта может оказаться недостаточным для
эффективного взаимодействия с партнерскими приложениями. С целью устранения указанных ограничений в архитектуре, представленной на Рисунке 47, предусмотрена выдача данных
партнерским приложениям путем использования механизмов журнального взаимодействия
в парадигме событийного обмена. Для обеспечения реализации предложенного взаимодействия применяется соответствующее программное обеспечение, гарантирующее полноценную
поддержку требуемой архитектуры. В общем случае указанное ПО может отличаться в части
выбора технологий от аналогичного ПО, обеспечивающего интеграцию смежных архитектурных уровней, но необходимость технологической унификации диктует нам выбор общего программного обеспечения для решения перечисленных задач на уровне одного продукта. При
этом топологически и с точки зрения вариантов использования при решении задач обмена
данными с партнерскими приложениями и при интеграциях со смежными архитектурными
уровнями априори должны использоваться различные инсталляции рассматриваемого программного обеспечения, поэтому уже в структуре концептуальной архитектуры они показаны
отдельно. Задачи информационной безопасности также требуют подобного разграничения –
обмен данными внутри контура организации и вне его характеризуется различными уровнями
защищенности и требованиями в части проверок передаваемых данных и осуществляемых
взаимодействий. Наполнение журналов событийного обмена с партнерскими приложениями
осуществляется путем ряда взаимодействий, также схематично представленных на Рисунке 47.
Журналы взаимодействия с экосистемой могут наполняться как на основе действий, реализуемых в рамках фронтальной логики (микросервисами фронтальной логики), так и на основании оперативных данных фронтального уровня, находящихся в кэш. Отметим, что архитек153

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

тура предусматривает и обратные взаимодействия – фронтальная логика может основываться
на данных, содержащихся в журналах обмена с партнерскими приложениями, кроме того, указанные данные могут помещаться в кэш. Также данные могут использоваться микросервисами
предоставления открытых API, инструментом визуализации, интерфейсами клиентов (двунаправленные взаимодействия).
В остальных аспектах проектирования и реализации уровень фронтального и канального
представления, а также канало-специфичной продуктовой логики аналитического цифрового
продукта не имеет принципиальных отличий от продукта MDM. Фронтальные интерфейсы
клиентов и внутренних пользователей реализуются с использованием легковесных фреймворков разработки и в соответствии с шаблоном микрофронтендов. Последнее предполагает наличие компонентов BFF, реализуемых в нашем примере в соответствии с принципами
микросервисной архитектуры. Указанные компоненты взаимодействуют с рассмотренным
выше инструментом визуализации, что также уже отмечалось нами ранее при обосновании
необходимости включения данного инструмента в архитектуру. Микросервисы фронтальной
логики взаимодействуют с микросервисами BFF, инструментом визуализации, микросервисами канало-специфичной логики, микросервисами открытых API, а также с инфраструктурными компонентами, такими как кэш и программное обеспечение событийного обмена. Для
кэширующего компонента предполагается его резервирование не только собственными механизмами, но и при помощи реляционной базы данных.
Детализация архитектурных уровней оперативного хранения продуктовых данных, продуктовой логики и логики управления процессами схематично представлена на Рисунке 48.
Рисунок 48 иллюстрирует концептуальную архитектуру уровней оперативного хранения
данных, продуктовой логики и логики управления бизнес-процессами аналитического продукта DWH. Здесь справедливо утверждение, примененное нами к детализации аналогичного
архитектурного уровня продукта MDM: для снижения числа отображаемых интеграционных
взаимодействий и сохранения удобства восприятия показаны общие шины взаимодействий.
Данные шины носят концептуальный характер. При детализации архитектуры от концептуального к компонентному представлению они могут быть раскрыты (в зависимости от требований к продукту) в формате журналов событийного обмена, прямых коммуникаций, включения
шаблона сетки сервисов и т. д.
Аналитический продукт строится вокруг данных организации, поэтому описание архитектуры, изображенной на Рисунке 48, мы начнем именно с вопросов хранения данных и разбора тех объектов, которые представлены на схеме.

154

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 48. Уровень оперативного хранения, продуктовой и процессной логики для аналитического продукта DWH
Когда мы говорим о хранилище данных и в традиционном классическом понимании,
и в современном продуктовом контексте, мы всегда подчеркиваем тот факт, что речь идет
о больших данных (Big Data). Действительно, позиционирование хранилища в компании поз155

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

воляет утверждать, что в отношении сохраняемых и обрабатываемых данных выполняются все
признаки их классификации как больших данных:
• Значительные объемы хранения, предполагающие в том числе использование специальных технологических решений, снижающих стоимость хранения и позволяющих эффективно
обрабатывать столь значимые массивы информации.
• Наличие как структурированного, так и неструктурированного содержания. Данное
утверждение можно разбить на две части. Во-первых, массивы структурированных данных
(те же данные о клиентах и их документах) настолько велики с точки зрения объема и настолько
разнородны с точки зрения осуществляемых аналитических расчетов, что эффективным в контексте последующей обработки является обеспечение их распределенного хранения в слабо
структурированном виде. Последнее предполагает, что отдельные массивы связанных данных хранятся структурированно, при этом различные структурированные массивы не связаны
между собой в плане хранения и возможной обработки. Во-вторых, в состав сохраняемых
и обрабатываемых в рамках жизненного цикла аналитического продукта данных входят и такие
данные, которые априори не могут считаться структурированными: контент, медиаинформация, файловые данные и т. д.
• Вновь поступающие инкременты данных являются значительными с точки зрения объема и могут содержать как структурированные, так и неструктурированные составляющие.
В связи с вышеизложенным задачи хранения данных в аналитическом продукте требуют
их распределенного хранения, для чего применяются технологические инструменты распределенной файловой системы, представленные на Рисунке 48. Указанный подход позволяет обеспечить высокую скорость добавления новых порций данных, что исключительно важно при
отмеченном ранее их значительном объеме. Кроме этого, механизмы распределенной файловой системы позволяют снизить затраты на хранение информации по сравнению со структурированными хранилищами. Сегментация данных позволяет повысить скорость их извлечения (в общем случае скорость чтения из распределенного хранилища может быть достаточно
низкой), но для этого в составе продуктовой логики должны быть реализованы компоненты,
учитывающие специфику сохраняемых и обрабатываемых данных. Указанная логика представлена в составе продуктовых микросервисов на Рисунке 48. Отметим, что «сырые» данные
загружаются в распределенную файловую систему с использованием потокового программного
обеспечения, также изображенного на Рисунке 48.
Одной из составляющих сохраняемых и обрабатываемых данных в аналитическом продукте является контент, правила обработки которого во многом специфичны по сравнению
с другими категориями данных. В связи с этим контент также размещается в распределенной
файловой системе, но даже на уровне концептуальной архитектуры мы показываем его хранилище отдельным по сравнению с описанными выше «сырыми» данными ввиду указанной специфики. При этом соответствующие хранилища могут взаимодействовать между собой, к ним
может применяться в том числе общая логика сегментации.
Аналитический продукт несет ценность внутренним и внешним клиентам, а также партнерам организации. Указанная ценность выражается в том числе в оперативном предоставлении данных и выполнении сложных аналитических расчетов. Ранее мы уже отмечали,
что в современной архитектуре позиционирование хранилища принципиально изменилось –
теперь это не отдельно развиваемый и эксплуатируемый программный комплекс, а полноценное продуктовое ИТ-решение, характеризуемое классом критичности Mission Critical
(MC) или Business Critical (BC). Соответствие приведенным классам критичности предъявляет исключительно высокие требования не только к надежности, но и к производительности продуктового ИТ-решения. Уместно напомнить читателю, что в современных архитектур156

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ных и технологических практиках надежность и производительность уже не отделяются друг
от друга: параметры производительности стали неотъемлемой частью при расчете надежности
программных комплексов, в то время как производительность рассчитывается с учетом допустимых простоев на основе заявленного уровня надежности. При этом обеспечение наивысших
параметров производительности при работе с большими данными является нетривиальной
задачей. Для ее решения в архитектуре аналитического продукта предусмотрены кэширующие элементы, которые отвечают за кэширование обрабатываемых и предоставляемых данных с извлечением последних из распределенной файловой системы, а также за выполнение
ресурсоемких операций в оперативной памяти. Взаимодействие кэширующих компонентов
с компонентами распределенной файловой системы используется для извлечения требуемых
данных в быстрое хранилище, записи актуальных данных и их версий в долговременное хранилище, фиксации результатов выполнения операций в долговременном хранилище информации. Также возможно резервирование кэшируемых данных в распределенной файловой
системе, хотя это и не является единственным механизмом резервирования.
Выполнение сложных аналитических расчетов в режиме реального времени требует
использования соответствующего класса программного обеспечения. Таким в архитектуре,
представленной на Рисунке 48, выступает аналитическая СУБД. Мы уже приводили ранее примеры технологий, обеспечивающих реализацию указанной задачи. Подобная СУБД позволяет
проводить аналитические расчеты с использованием технологий больших данных и предоставлять их результаты в виде витрин данных (Data Marts). Соответствующие программные
комплексы пришли на смену аналитическим СУБД, специализировавшимся на сложных долговременных расчетах, результатов которых приходилось ждать до суток и более. На сегодняшний день подобная продолжительность выполнения аналитики недопустима. Например, клиент
финансовой организации подает заявку на кредит. Эта заявка нуждается в высокоскоростной обработке с последующим предоставлением результата клиенту. Обработка может потребовать подключения значительных объемов данных для выдачи обоснованного результата.
Одновременно с этим финансовая организация может быть заинтересована в выдаче платежеспособному клиенту пакетов предложений. При формировании пакета должны учитываться
уже имеющиеся у него продукты, параметры выдаваемого кредита, а также множественные
характеристики клиента. Последние могут формироваться на основе его пристрастий, цифрового следа клиента, информации из социальных сетей, от телекоммуникационных операторов
и т. д. Именно обработка столь характеризующей клиента информации необходима для выдачи
ему таргетированного предложения, которое действительно может его заинтересовать. В современном цифровом мире универсальные «уникальные» предложения не вызывают отклика клиента. Все это представляет собой значительный объем информации, нередко подходящий под
определение больших данных. Но для выдачи результатов расчетов и соответствующих им
предложений клиенту «есть только миг между прошлым и будущим», если цитировать песню
из замечательного фильма. Клиент не будет ждать сутки или неделю предложения – он воспользуется услугами конкурирующей организации. Поэтому в аналитическом продукте необходимо использовать СУБД, позволяющие осуществлять аналитические расчеты на основе
больших данных в режиме реального времени, что и представлено на Рисунке 48.
Для ускорения выполнения аналитических расчетов СУБД реального времени необходимо сегментировать, дабы расчеты производились над максимально связанными данными,
что позволит повысить производительность и конкретного технологического решения, и аналитического продукта в целом. Правила сегментации могут меняться. Современные технологические реализации позволяют размещать указанные правила в распределенной файловой системе, дабы в последующем можно было их гибко изменять с использованием практик
машинного обучения (Machine Learning). Связь аналитической СУБД, выполняющей расчеты
в режиме реального времени, с распределенной файловой системой осуществляется не только
157

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

в части получения данных для расчетов или сохранения результатов последних, но и для получения управляющей информации о правилах сегментирования СУБД и их корректировке.
Аналитические СУБД обладают собственными механизмами обеспечения надежности,
но их, как правило, недостаточно для соответствия заявленным высоким классам критичности MC и BC. Поэтому для резервирования данных в архитектуре аналитического продукта
используется распределенная NoSQL СУБД. Также указанный программный комплекс используется для резервирования кэшируемых данных.
Инструмент визуализации (BI-инструмент), рассмотренный ранее для уровня фронтальной и канальной логики, представлен в архитектуре аналитического продукта также на уровне
прикладной продуктовой логики и логики управления бизнес-процессами. Необходимость
его присутствия диктуется развитой обработкой данных, осуществляющейся на указанных
уровнях. При этом ценность аналитического продукта во многом определяется возможностью наглядного отображения как непосредственно обрабатываемых данных, так и результатов
аналитических расчетов, а также отслеживаемых ключевых показателей цифрового продукта
пользователями ИТ-решения. Реализация отмеченных задач значительно упрощается при
использовании инструмента визуализации, функции которого во многом аналогичны представленным ранее при описании уровня фронтальной логики. При этом наполнение данными
для последующего отображения осуществляется на основе «сырых» данных и контента, хранящихся в распределенной файловой системе, данных аналитической СУБД (особый интерес
для отображения представляют результаты аналитических расчетов и их представление в виде
витрин данных). Важно отметить, что наличие в концептуальной архитектуре инструмента
визуализации не предполагает простого развертывания в контуре продуктового ИТ-решения
некоего инструмента наподобие Apache Superset. Безусловно, подобный инструмент может
и должен использоваться, но он дополняется компонентами логики обработки данных. Подобная логика выходит за рамки нашего примера и должна детализироваться на этапе проектирования компонентной архитектуры. Последняя обычно имеет ярко выраженную специфику,
связывающую ее с конкретными продуктами, предлагаемыми организациями. Мы же в нашем
изложении придерживаемся принципа приведения максимально общих и полных примеров,
характерных для цифровых продуктов в целом.
Также в составе концептуальной архитектуры продукта, схематично изображенной
на Рисунке 48, показано хранилище оперативных данных бизнес-процессов. Указанное хранилище используется для хранения контекстов процессов и управляющей информации. Принципиально его назначение не отличается от аналогичного объекта в составе архитектуры продукта MDM, рассматривавшегося ранее. Для реализации указанного компонента применяются
технологии реляционных СУБД.
В составе слоя прикладной продуктовой логики нами выделены продуктовые и обеспечивающиеся микросервисы, поскольку мы, как и ранее, следуем парадигме микросервисной
архитектуры при проектировании и реализации цифрового продукта. Аналогично разобранным ранее примерам продуктовые микросервисы отвечают за выполнение логики, непосредственно связанной с функциональными требованиями, предъявляемыми к аналитическому
продукту. Необходимо напомнить читателю, что мы рассматриваем концептуальную архитектуру продукта, а потому говорим о концептуальных микросервисах. При дальнейшей архитектурной детализации они также должны быть детализированы. Например, при проектировании
компонентной архитектуры продукта может выясниться, что тот или иной концептуальный
микросервис может представлять собой группу логических микросервисов и связанных с ними
инфраструктурных компонентов. Примерами продуктовых микросервисов являются:
• Микросервис правил сегментации данных. Современные требования в части производительности исключительно высоки, поскольку современный цифровой мир является миром
158

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

дистанционных каналов обслуживания. Вопросы монетизации данных также требуют предоставления наборов данных, их выгрузок и результатов аналитических расчетов в режиме
онлайн. Обеспечение выполнения подобных требований при работе с большими данными
является нетривиальной задачей. Одним из способов ее решения является гибкая сегментация
данных для ускорения осуществления выборок и проведения расчетов. Правила сегментации
могут основываться в том числе на концепции управления данными, принятой в организации,
расширяя и дополняя ее в частных случаях. Реализация правил сегментации может и должна
осуществляться на уровне прикладной продуктовой логики аналитического продукта.
• Микросервис правил нормализации данных сегмента. Отдельный сегмент данных
также может содержать огромные массивы информации, поэтому необходимо предпринимать
все меры для повышения производительности ее обработки. Подобные меры должны предприниматься всеми членами команды разработки, но особую ответственность несет архитектор.
Одним из вариантов повышения производительности при выполнении аналитических расчетов является обеспечение интеграции на уровне данных при обработке информации, содержащейся в одном сегменте. Мы не говорим в данном случае о канонической модели данных
(КМД), но снижение числа преобразований связанных между собой данных на уровне общего
сегмента позволит кардинально повысить производительность всего продуктового ИТ-решения. Для этого возможно осуществление локальной (уровня сегмента) нормализации данных,
правилами которой управляет соответствующий компонент продуктовой логики.
• Микросервис разрешения конфликтов. При обработке больших массивов данных возникновение конфликтов на их уровне не просто весьма вероятно, а фактически неизбежно.
Например, данные по клиентам – физическим лицам поступают из самых разных цифровых
продуктов. Зачастую они могут конфликтовать между собой. На уровне аналитического продукта необходимо устранение соответствующих конфликтов, для чего в качестве методологического инструмента может использоваться, например, утвержденная в компании концепция
управления данными. А инструментарий разрешения конфликтов реализуется на уровне компонентов прикладной продуктовой логики. В нашем примере за это отвечает соответствующий
концептуальный продуктовый микросервис.
• Микросервис управления сегментами аналитики. Как мы отмечали выше, при выполнении аналитических расчетов аналитическая база данных, осуществляющая их в режиме реального времени, сегментируется. Указанное сегментирование в общем случае не соответствует
сегментации «сырых» данных, за правила которой отвечает описанный ранее концептуальный микросервис. Правила сегментации аналитической базы данных, как мы описывали выше,
могут храниться в распределенной файловой системе. А для гибкого управления ими в концептуальной архитектуре предусмотрен соответствующий микросервисный компонент.
• Микросервис управления метаданными контента. Контент, представляя собой неструктурированные данные, хранится в распределенной файловой системе. При этом к задачам
управления им в составе аналитического продукта предъявляются все те же исключительно
высокие требования в части производительности. Для обеспечения реализации указанных
требований необходима поддержка эффективной работы с метаданными, ассоциированными
с контентом. Метаданные, представляя собой «данные о данных», как правило, структурированы, но логика управления ими должна быть отделена от самих данных и эффективно масштабироваться и развиваться. В нашем примере она представлена в виде отдельного концептуального прикладного микросервиса.
• Микросервис правил формирования витрин данных. Витрины данных (Data Marts)
формируются аналитической базой данных, выполняющей расчеты на основе больших данных
в режиме реального времени. Но правила формирования витрин носят динамический характер. И поэтому для реализации управления указанными правилами предусмотрен соответствующий компонент прикладной логики, реализуемый в микросервисной парадигме. Данный
159

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

компонент позволит обеспечить гибкое управление правилами проведения расчетов. Добавление новых правил или корректировка имеющихся, осуществляемые «на лету», позволят адаптировать продукт под потребности клиентов и партнеров, предоставляя им истинную ценность.
• Микросервис классификации операций. Различные операции, выполняемые в аналитическом продукте, требуют разного подхода к реализации: использования различных технологий и применения адресных подходов к их исполнению. Например, какие-то операции
могут осуществляться аналитической базой данных, какие-то – с использованием кэширующих элементов. Правила, применяемые к исполнению операций, зависят от конкретного
аналитического продукта и его вариантов использования. Но для обеспечения корректного
выбора способа исполнения операции требуются правила классификации, причем указанные
правила могут динамически изменяться. Для управления правилами классификации в архитектуре цифрового продукта предусмотрен специальный продуктовый компонент. Отметим,
что в целях гибкости при дальнейшей детализации архитектуры он может содержать и вложенные процессные компоненты, реализуемые, например, с использованием нотации DMN,
если последнее будет признано допустимым с точки зрения производительности и надежности
продуктового ИТ-решения.
• Микросервис управления продуктами данных. При сегментации «сырых» данных и/
или аналитической базы данных для проведения расчетов формируются продукты данных,
описание которых уже было приведено ранее в настоящей книге. Кроме того, в результате
интеграций со смежными продуктовыми решениями на уровне аналитического продукта DWH
формируются реплики, соответствующие продуктам данных, ассоциированным с цифровыми
продуктами организации. Каждый из указанных продуктов данных имеет собственный жизненный цикл, при этом обработка событий жизненных циклов продуктов данных осуществляется в рамках жизненного цикла аналитического продукта. В связи с этим в составе прикладной продуктовой логики аналитического цифрового продукта предусмотрены компоненты,
отвечающие за обработку событий жизненного цикла продуктов данных (фактически последние составляют продукт данных, ассоциированный с аналитическим продуктом). В настоящем
примере на уровне концептуальной архитектуры предусмотрен соответствующий концептуальный микросервис.
• Микросервис управления и применения мастер-данных. В рамках жизненного цикла
аналитического продукта последнему приходится использовать мастер-данные при формировании наборов данных, их сегментации и проведении аналитических расчетов. Мастер-данные импортируются из соответствующего продуктового решения – цифрового MDM продукта,
пример которого был рассмотрен нами ранее по ходу настоящего раздела. Жизненный цикл
мастер-данных отличается от жизненного цикла продуктов данных (в том числе от жизненного
цикла продукта данных, входящего в состав аналитического продукта DWH) и должен быть
определен в концепции управления данными. На уровне продуктовых ИТ-решений он может
детализироваться. Поэтому в составе аналитического продукта предусмотрен представленный
на Рисунке 48 концептуальный микросервис, ответственный за обработку событий, связанных
с мастер-данными, обеспечение их корректного слияния с продуктом данных в составе аналитического продукта и корректное применение в процессах жизненного цикла последнего.
• Микросервис управления расчетами. Правила выполнения аналитических и вспомогательных расчетов могут варьироваться ввиду постоянной корректировки требований со стороны клиентов и партнеров, изменения рыночных тенденций, а также с учетом динамики
P&L цифровых продуктов организации, имеющих потребность в проведении расчетов. Ввиду
этого в составе прикладной продуктовой логики аналитического продукта DWH предусмотрен концептуальный микросервис, отвечающий за управление расчетами. В задачи данного
микросервиса входит прием и обработка новых требований, поступающих к расчетам, а также
их применение на этапе непосредственного проведения расчетов и первичной интерпретации
160

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

результатов. Окончательная интерпретация результатов аналитических расчетов, представляемых как адресно, так и в формате витрин данных, является задачей их потребителей.
• Микросервис управления регуляторными правилами. Значение цифрового продукта
DWH с точки зрения выполнения задач регуляторного характера трудно переоценить. Аналитический продукт как выполняет непосредственно задачи соответствующего класса, результаты которых могут предоставляться глобальному регулятору, так и учитывает требования
локальных отраслевых регуляторов при проведении операций над данными. Регуляторные правила при этом также постоянно актуализируются аналогично требованиям клиентов и партнеров или рыночным тенденциям. Поэтому необходимо обеспечить возможность как оценки
и моделирования применения соответствующих требований, так и управление их применением при выполнении расчетов. Последние обязаны учитывать все актуальные требования
регулирующих инстанций, а транслируют их компонентам, ответственным за расчеты, компоненты прикладной продуктовой логики.
• Микросервис управления моделями машинного обучения. Важной задачей при работе
с большими данными является отработка моделей машинного обучения и проверка концепций. Как правило, для решения этой задачи на уровне больших данных организуется так
называемая «песочница» (sandbox), в рамках которой и осуществляется проверка концепций,
минимальным образом или вообще не влияя на «сырые» данные и проводимые аналитические расчеты. Отметим, что длительное время работа с большими данными сводилась практически исключительно к организации подобной «песочницы». Как мы видим, на сегодняшний день задачи современного аналитического продукта значительно расширились, но при
этом проверка концепций и моделей машинного обучения осталась в их составе. Управление
логикой проверок осуществляется на архитектурном уровне прикладной продуктовой логики.
При этом указанный концептуальный микросервис при своей дальнейшей детализации может
использовать множество фреймворков и компонентов работы с большими данными, а потому
его компонентная архитектура может оказаться весьма масштабной.
Необходимо подчеркнуть, что описанная выше сегментация данных должна осуществляться в парадигме поддержки принципов продуктов данных. При этом сегменты данных,
составляющие продукт данных, ассоциированный с аналитическим цифровым продуктом
DWH, существуют не обособленно, а активно взаимодействуют между собой. Интеграция
указанных продуктов данных осуществляется в парадигме реализации шаблона «сетка данных» (Data Mesh). Таким образом на уровне архитектуры аналитического продукта реализуется поддержка в том числе современного шаблона организации хранилищ данных Data
LakeHouse, набирающего популярность в настоящее время.
Взаимодействие микросервисных компонентов может осуществляться как напрямую, так
и посредством генерации и прослушивания событий в парадигме событийно-ориентированной
архитектуры (EDA) с использованием соответствующего программного обеспечения. Рекомендуемым является второй способ, поскольку он позволяет обеспечивать слабую связность
компонентов. На Рисунке 48 показано использование потокового программного обеспечения
для поддержки реализации событийно-ориентированной архитектуры. При этом при прямом
взаимодействии могут использоваться современные шаблоны обеспечения эффективной интеграции, например, «сетка сервисов» (Service Mesh).
Как и в рассмотренном ранее примере цифрового MDM продукта, обеспечивающие микросервисы, примеры которых приведены на Рисунке 48, отвечают за выполнение вспомогательных задач, необходимых для корректного исполнения задач непосредственно продуктовой
логики аналитического продукта DWH. В формат обеспечивающих микросервисов выводятся
задачи, носящие общий характер с точки зрения продуктовой логики. Здесь необходимо сделать небольшое отступление. Когда речь заходит о микросервисах, то зачастую упор делается
161

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

на приставке «микро». Подобное акцентирование внимания на том, что компоненты являются
небольшими, может привести к негативным последствиям с точки зрения как ИТ-решения,
реализуемого в микросервисной парадигме, так и всей организации. Примером такого негативного последствия может стать возникновение огромного количества сильно связанных компонентов, спроектированных и реализованных по принципу небольшой трудоемкости, требуемой для их создания. Количество удаленных вызовов в таком случае приведет к значительным
временных затратам при исполнении даже простейшей операции. В итоге организация понесет
убытки. Необходимо учитывать, что микросервисы (даже когда речь, как в нашем примере,
идет о концептуальных микросервисах) выполняют законченные действия, что недопустим
разрыв транзакционного контекста между границами микросервисов. При этом, безусловно,
необходимо принимать во внимание традиционные определения микросервиса, характеризующие в том числе трудоемкость его создания и развития. Что же приведенные рассуждения
означают для рассматриваемого нами примера концептуальной архитектуры цифрового продукта? Нет никакого смысла выделять каждое служебное действие, выполняемое в составе
продуктового микросервиса, в виде микросервиса обеспечивающего. Но общие для многих
операций служебные действия вполне целесообразно оформить в виде обеспечивающих микросервисов. Примерами последних в случае аналитического продукта могут служить:
• Микросервис индексации задач бизнес-процессов и их ассоциации с конкретными
действиями прикладной продуктовой логики. Данный обеспечивающий микросервис аналогичен обеспечивающему микросервису, представленному в примере цифрового MDM продукта. Указанная задача является исключительно важной для повышения скорости отработки
экземпляров бизнес-процессов с задействованием BPM-движков в аналитическом продукте.
Вопрос масштаба применения BPM-движка в аналитическом продукте является дискуссионным, но в любом случае необходимость наличия соответствующего инструмента в архитектуре
продукта не может подвергаться сомнению.
• Микросервис планирования загрузки. Вопросы обеспечения эффективной загрузки
данных в хранилище поднимаются при построении каждого конкретного хранилища, и ответы
на них являются адресными, поскольку однозначного решения подобная задача не имеет
вследствие сложности и многогранности самих данных, которые должны быть загружены и корректно обработаны. В случае разбираемого нами примера мы учитываем тот факт, что как
«сырые» данные, так и структура аналитической базы данных сегментируются. Загрузка данных с целью оптимизации может осуществляться по сегментам в соответствии с задачами,
которые определяет продуктовая логика. Например, обеспечение загрузки всех сегментов,
по которым планируется проводить аналитические расчеты в соответствии с расписанием,
формируемым на уровне прикладной продуктовой логики. Планирование загрузки в таком
случае осуществляется самостоятельными компонентами продукта, оформленными в нашем
примере в виде обеспечивающего микросервиса на уровне концептуальной архитектуры с возможной детализацией на других архитектурных представлениях, например в компонентной
архитектуре.
• Микросервис управления триггерами. В случае цифрового аналитического продукта
возможно срабатывание огромного количества триггеров по данным. Необходимость осуществления расчетов и перерасчетов по вновь изменившимся исходным данным, предоставление результатов расчетов или наборов данных по запросу, поступление новой управляющей
информации, влияющей на логику проведения расчетов, выгрузка данных смежным продуктовым ИТ-решениям и т. д. Как мы видим даже из столь краткого описания, логика работы
с триггерами оказывается весьма сложной. Необходимо учитывать, что число и характеристики
самих триггеров также могут динамически изменяться. Поэтому в концептуальной архитек162

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

туре аналитического продукта предусмотрен специальный микросервис для управления триггерами, включая их добавление, изменение, формирование правил реакции на события и т. д.
• Микросервис управления справочными данными. Работа со справочными данными
в случае аналитического продукта исключительно масштабна: необходимо их применение
к каждому сегменту данных, к каждому расчету и выдаче результатов. При этом, вследствие масштабности работы с данными, используется фактически вся нормативно-справочная
информация, наличествующая в организации. Логика работы с ней: загрузки, выгрузки инкремента в случае изменений, сегментирование для повышения оперативности работы, ассоциация с различными сегментами данных и т. д. осуществляются выделенным компонентом
логики, представленном в примере в виде обеспечивающего микросервиса.
• Микросервис управления пакетными операциями. Многие операции в аналитическом
продукте носят типовой характер, выполняются над множеством объектов данных, а потому
имеют все признаки пакетных (batch processing). Корректное оформление пакетных операций и их согласованное исполнение позволяют существенно повысить производительность
и надежность цифрового продукта, что дает основания выделить логику управления соответствующим типом операций в отдельный микросервис.
• И т. д.
Поскольку мы приводим лишь пример концептуальной архитектуры цифрового продукта, то мы ориентируем читателя на самостоятельное исследование конкретных кейсов продуктовой архитектуры и не пытаемся покрыть все возможные случаи построения хранилищ
данных.
Масштабы применения процессных микросервисов в аналитическом продукте носят
дискуссионный характер. С одной стороны, многие операции, выполняемые в рамках автоматизации процессов жизненного цикла продукта, требуют развитого управления, которое носит
динамический характер, подразумевающий возможность оперативного изменения, а также
требуют вовлечения большого количества ролей, таких как аналитики и архитекторы данных, офицеры данных и т. д. Управление подобными операциями имеет смысл выстраивать
в соответствии с правилами управления бизнес-процессами, рассматривавшимися в соответствующем разделе. При этом в автоматизацию включается уже неоднократно рассматривавшийся нами и включенный в состав платформы инструмент – BPM-движок. Одновременно
с этим подобная логика управления негативно влияет на общую производительность продуктового ИТ-решения. Приведенный факт имеет исключительно важное значение в условиях
того, что, как мы рассматривали ранее, данные являются главным богатством организации,
из чего следует высокая востребованность аналитического продукта DWH. В такой ситуации
даже малейшее уменьшение производительности может существенно снизить конкурентоспособность организации, ухудшая P&L всех связанных цифровых продуктов, а также формируя
негативный клиентский опыт и снижая возможности монетизации данных. Архитектор при
анализе возможностей внедрения практик управления бизнес-процессами в аналитический
цифровой продукт должен, образно говоря, пройти между Сциллой и Харибдой. Как гласит
древнегреческий миф, Сцилла убила шестерых спутников Одиссея – это стало платой за то, что
его корабль избежал попадания в Харибду, где погиб бы весь экипаж вместе с героем. В случае
аналитического продукта архитектор должен включить использование BPM-движка в продуктовое ИТ-решение, но прибегать к нему адресно лишь в исключительных случаях. При этом
предпочтение должно отдаваться шаблону хореографии, поскольку по сравнению с оркестровкой он обеспечивает большие возможности в части производительности и масштабирования.
Вследствие вышеизложенного в нашем примере, схематично представленном на Рисунке
48, изображены общие процессы, где действительно может потребоваться развитое управление
бизнес-процессами: создание сегментов данных и отображение результатов расчетов. Список
163

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

автоматизируемых с применением BPM-движка процессов может быть расширен, при этом
необходимо учитывать, что непосредственно в расчетные процессы вовлекать непроизводительные инструменты нецелесообразно.
На Рисунке 49 представлена детализация концептуальной архитектуры уровня интеграционной логики цифрового аналитического продукта DWH.

Рисунок 49. Концептуальная архитектура уровня интеграционной логики аналитического продукта
Для проектирования и реализации интеграционной логики используется парадигма микросервисной архитектуры, как и в случае реализации продуктовой логики на смежных архитектурных слоях, рассмотренных ранее. На Рисунке 49 показаны два типа микросервисов,
относящихся к интеграционному уровню, – микросервисы интеграционной логики и микросервисы – интеграционные адаптеры. Отметим, что в данном аспекте архитектура аналитического продукта соответствует архитектуре продукта MDM, поэтому мы не будем утомлять
читателя повтором описания задач, выполняемых каждым типом компонентов.
В состав микросервисов интеграционной логики включены следующие:
• Микросервис правил интеграции с потоковыми данными. Значительная часть данных
поступает в хранилище в виде потоковой информации, поэтому мы вводим в пример отдельный компонент логики, определяющий правила первичной обработки указанного типа данных.
• Микросервис правил распространения инкремента. В ходе выполнения аналитических
операций компонентами логики аналитического продукта могут осуществляться изменения
в данных смежных продуктовых ИТ-решений. Подобные изменения должны распространяться
мастер-продуктам по соответствующим наборам данных аналогично распространению инкремента продуктом MDM. Обработка правил распространения инкремента, зачастую носящих
адресный характер, осуществляется выделенным микросервисом.
164

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Микросервис правил работы с файлами. Кроме потоковых данных многие данные могут
получаться из файлов, что также требует специфической логики обработки, поэтому мы вводим в пример дополнительный микросервис интеграционной логики, ответственный за управление правилами обработки файловых данных.
• Микросервис правил структуризации данных. В случае современного хранилища мы
говорим о работе с большими данными, предусматриваем компоненты хранения «сырых» данных. Тем не менее эффективная обработка данных при выполнении аналитических расчетов
требует знания структуры данных и категоризации последних в соответствии со структурой.
Мы вводим специальный компонент интеграционной логики, который фиксирует особенности
структуры загружаемых данных, формирует эффективные правила их обработки в соответствии со структурой. Впоследствии результаты работы данного микросервиса могут использоваться компонентами прикладной продуктовой логики и непосредственно при выполнении
расчетов.
Еще раз напомним, что приводятся концептуальные микросервисы, поскольку мы рассматриваем пример концептуальной архитектуры.
Микросервисы – интеграционные адаптеры обеспечивают корректное взаимодействие
со смежными продуктовыми ИТ-решениями, унаследованными информационными системами
и внешними с точки зрения контура организации программными комплексами. Адаптеры
показаны на Рисунке 49 обезличенно, характеризуя классы взаимодействия, предусмотренные
в аналитическом продукте:
• Адаптер к продуктовым ИТ-решениям. Как и ранее, мы предполагаем, что организация осуществляет продуктовую трансформацию, поэтому ее перспективный ИТ-ландшафт
представляет собой набор продуктовых ИТ-решений, обеспечивающих перевод в цифровой
вид тех продуктов, которые организация предоставляет своим клиентам и партнерам. При
этом используется общий архитектурный подход к организации продуктовых ИТ-решений,
дополненный подходом платформенным. В таком случае загрузка данных в состав хранилища
осуществляется посредством стандартизированных технологий, например, путем потоковой
передачи информации в журнальной парадигме. Последнюю мы указывали общей в наших
архитектурных примерах, приведенных в настоящей книге. Такая интеграция оказывается бесшовной. Правила управления ею и параметры передачи определяются соответствующим микросервисом интеграционной логики и адаптером.
• Адаптер к файловым данным. Многие системы, особенно это характерно для унаследованных информационных систем, реализация которых проводилась в соответствии с предыдущими архитектурными и технологическими поколениями, осуществляют обмен большими
объемами данных, например логов, которые также требуют обработки аналитическим цифровым продуктом в виде файлов. Передача файловых данных также возможна в потоковом формате, но для этого требуются специальные инструменты и, соответственно, специализированные адаптеры. Соответствующий инструмент также представлен на Рисунке 49. Примерами
его реализации могут выступать Apache NiFi, Apache Flume, StreamSets Data Collector.
• Адаптер к базам данных. В ряде случаев возможен прямой импорт данных из баз данных, используемых смежными решениями. Для реализации подобного взаимодействия используется отдельный набор адаптеров. Отметим, что мы учитываем необходимость расширения,
например, используемого в наших примерах Apache Kafka такими компонентами, как Kafka
Streams и Kafka Connect для поддержки всех указанных взаимодействий. Но подобная детализация имеет отношение к компонентной, а не к концептуальной архитектуре, поэтому в нашем
примере мы ее не приводим.
165

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Адаптер к внешним источникам. Внешние источники данных, такие как партнерские
приложения или социальные платформы, могут также предоставлять данные для загрузки
в хранилище и последующего проведения аналитических расчетов на их основе. Количество
и техническая реализация адаптеров к подобным внешним источникам определяются конкретным ИТ-ландшафтом организации. Отметим, что в современном цифровом мире такие данные, как пользовательские предпочтения, зачастую берутся из социальных платформ и служат
важным источником информации при принятии решений в автоматизируемых бизнес-процессах.
Взаимодействие микросервисов между собой может осуществляться как напрямую, так
и посредством событийного обмена с использованием потокового программного обеспечения,
также представленного на Рисунке 49. Второй способ коммуникации в общем случае является
рекомендуемым.
На Рисунке 49 в отличие от продукта MDM не показан архитектурный уровень архивного
хранения. Зачастую все данные, попадающие в аналитический продукт, используются впоследствии при проведении аналитических расчетов (с учетом сегментации, о которой говорилось
выше). Поэтому дополнительно архивировать сохраняемые данные, которые и так хранятся
с использованием механизмов распределенной файловой системы, в нашем примере не требуется. В крайнем случае возможна сегментация с исключением неактуальных исторических
данных из проведения расчетов.
Подчеркнем, что исполнение технических задач и взаимодействие прикладных компонентов с инфраструктурными осуществляется с использованием платформенных механизмов,
поскольку мы при проектировании и реализации примера следуем платформенному подходу.
Внимательный читатель немедленно отметит: «Вы говорите о платформенном подходе,
но в данном примере Вы вышли далеко за рамки того набора платформенных технологий,
который рассматривался ранее. Как это понимать?» Мы похвалим читателя за внимательность
и ответим, что действительно – требования продукта MDM и особенно аналитического продукта DWH не укладываются в структуру платформенных сервисов и технологических реализаций, представленных ранее. Но именно так и должно быть! Мы и по ходу предыдущей книги,
(«Архитектура цифровых платформ. От настоящего к будущему»), и в ходе настоящего изложения отмечали следующие ключевые факты, относящиеся к применению платформенного
подхода:
• Нет никакого смысла (более того, это крайне нежелательно) ожидать полной реализации всей платформы организации, прежде чем приступать к созданию цифровых продуктов
на ее основе. Необходимо создание ключевого функционального платформенного ядра, масштабы которого должны определяться из планов по реализации продуктов в виде платформенных приложений. В дальнейшем платформа и платформенные приложения могут развиваться
параллельно.
• Цифровые продукты выступают в качестве одного из ключевых источников требований
к платформе, на основе которой осуществляется их автоматизация. То есть при параллельном
развитии продуктов и платформы появление новых требований к последней со стороны автоматизируемых продуктов приводит к развитию платформенного функционала.
• Свойство открытости является ключевым для современных цифровых платформ. Продуктовые команды могут как ожидать развития платформенного функционала платформенными командами (при их наличии), так и реализовать дополнения самостоятельно, опубликовав их в составе платформы по утвержденным правилам публикации таким образом, чтобы
выполненные дополнения стали доступными для всех команд, использующих платформу.
166

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Таким образом, тот факт, что архитектура цифровых продуктов MDM и DWH расширяет стек используемых в ходе продуктовой автоматизации технологий по сравнению с ранее
представленным в составе платформенного решения, не является сюрпризом. Это нормальное
развитие платформы в ходе автоматизации продуктов на ее основе. Рассмотрим, какие дополнения необходимо внести в состав платформы.
В процессе рассмотрения примера автоматизации цифрового MDM продукта мы отметили, что на архитектурных уровнях, связанных с продуктовой логикой и оперативным хранением продуктовых данных, кэширующие компоненты используют в качестве технологии
резервирования нереляционную СУБД (в приведенном примере Apache Cassandra). Это требует архитектурного развития платформы: платформенный сервис работы с кэш 1.4 должен
использовать платформенный сервис работы с нереляционными данными 1.2. Подчеркнем,
что имплементация указанного механизма резервирования должна быть предусмотрена для
всех технологических реализаций платформенных сервисов в целях обеспечения архитектурной, методологической и технологической унификации.
В состав платформенных сервисов работы с данными (реализующих сервис 1.1) необходимо включить такие сервисы, как работа с данными при проведении аналитических расчетов с технологическими реализациями, использующими основные аналитические СУБД,
востребованные организацией. Как мы уже отмечали в ходе рассмотрения примера аналитического продукта DWH, аналитические СУБД должны резервироваться в надежном хранилище, в качестве которого, как правило, выступает нереляционная СУБД (и, соответственно,
распределенная база данных). Сказанное означает, что платформенный сервис работы с аналитическими СУБД должен использовать платформенный сервис 1.2 для целей резервирования. Также данный сервис должен взаимодействовать с платформенным сервисом работы
с распределенной файловой системой 1.3: получение данных для проведения расчетов, а также
информации о сегментации носит во многом технический характер, а потому должно быть
перенесено на уровень платформенного решения. В состав реализаций сервиса работы с данными следует включить работу с инструментами визуализации. Мы не выносим данный аспект
в отдельное множество платформенных сервисов вследствие того, что в нашем примере он
касается исключительно вопросов управления данными. В реальных случаях автоматизации
аналитической деятельности организации возможна более сложная структура платформенных
сервисов.
Количество реализаций платформенного сервиса обеспечения потоковой передачи данных в условиях рассматриваемого нами примера продуктовой автоматизации необходимо расширить потоковой передачей файловых данных с соответствующим набором технологических
реализаций.
Схематично набор платформенных сервисов, сформированный в ходе развития цифровой платформы при осуществлении продуктовой автоматизации, представлен на Рисунке 50.
Рисунок 50 иллюстрирует такое развитие платформенного решения, драйвером которого
выступают платформенные приложения, то есть цифровые продукты. Мы видим взаимовлияние платформы и продуктов, создающихся на ее основе. Платформа является средой создания
и исполнения приложений, а продукты – источником требований к развитию платформы.

167

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Что же изменилось в составе платформенных сервисов, их реализаций, в том числе
технологических, и их связей между собой при учете продуктовых требований? Как уже
отмечалось выше, добавлена связь (выделена жирным на Рисунке 50) между платформенным сервисом работы с кэширующими компонентами 1.4 и платформенным сервисом работы
с нереляционными данными 1.2. Добавлен новый платформенный сервис работы с аналитическими СУБД 1.5, представляющий собой одну из реализаций платформенного сервиса работы
с данными 1. Указанному сервису сопоставлено три технологические реализации: на основе
168

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

использования программного обеспечения ClickHouse, Apache Druid и Apache Pinot. Повторим важный тезис, уже излагавшийся ранее в настоящей книге: указание конкретного программного обеспечения приводится лишь для примера, при этом использование его в качестве
технологической реализации не означает, что платформенный сервис просто отвечает за развертывание соответствующего ПО либо проксирование его API потребителям. Платформенный сервис использует то или иное программное обеспечение, максимально полно отвечающее
требованиям, предъявляемым потребителями – платформенными приложениями, формирует
рекомендуемые топологии, варианты использования, развивает его. Указанная конфигурация
требует создания значительного количества компонентов командой разработки платформы
или цифрового продукта, если продуктовая команда берется за платформенное развитие.
Номера технологических реализаций сервиса 1.5 – 1.5.1, 1.5.2 и 1.5.3 соответственно. Платформенный сервис 1.5 взаимодействует с сервисами работы с нереляционными данными и распределенной файловой системой 1.2 и 1.3 соответственно (взаимосвязи отмечены жирным
на Рисунке 50). Назначение интеграций уже описывалось выше. В состав имплементаций платформенного сервиса работы с данными введен сервис работы с инструментами визуализации
1.6, который содержит две технологические реализации 1.6.1 и 1.6.2 – на основе программных продуктов Apache Superset и Pentaho BI соответственно. Сервис 1.6 может использовать
в качестве источника данных любой тип хранилища, поддерживаемый сервисом 1, поэтому их
связи не показаны на Рисунке 50 для удобства восприятия.
В состав реализаций сервиса обеспечения потоковой передачи данных 2 добавлен платформенный сервис работы с потоковой передачей файловой информации 2.3. Ему сопоставлены две технологические реализации 2.3.1 и 2.3.2 – на базе программного обеспечения
Apache NiFi и StreamSets Data Collector (на Рисунке 50 обозначен как SDC) соответственно.
Остальные платформенные сервисы остались без изменений по сравнению с предыдущим рассмотрением. Базовый платформенный сервис 0, как и ранее, предоставляет два типа
платформенного SDK – с использованием языков разработки высокого уровня Java и C#.
Отвечая на ранее озвученный вопрос читателя, мы наглядно проиллюстрировали, каким
образом продуктовая трансформация компании является источником требований и драйвером
развития платформы. При этом архитектура платформы должна обеспечивать соответствующее гибкое развитие.
Но вернемся к рассматриваемому примеру аналитического продукта DWH – его обсуждение еще не завершено.
Ранее мы обсудили архитектуру отдельных продуктовых уровней в соответствии с общим
представлением концептуальной архитектуры цифрового продукта, пример которой мы рассматриваем по ходу настоящей книги. Мы уточнили перечень используемых архитектурно-технологических подходов и расширили в соответствии с ним список применяемых в примере
платформенных сервисов и их технологических реализаций. Настало время рассмотреть концептуальную архитектуру аналитического продукта DWH аналогично тому, как была представлена ранее концептуальная архитектура цифровых продуктов кредита, ЭБГ, MDM. Схематично данная концептуальная архитектура представлена на Рисунках 51 и 52. Мы вновь
разбиваем архитектуру цифрового продукта на две иллюстрации, чтобы сохранить наглядность ее визуализации. Нумерация используемых при реализации продукта платформенных
сервисов соответствует Рисунку 50.
На Рисунках 51 и 52 показана концептуальная архитектура аналитического цифрового
продукта DWH, разбитая по архитектурным уровням, приведены технологии, используемые
при реализации данной архитектуры, а также применяемые платформенные сервисы. Для разнообразия платформенные сервисы и их технологические реализации несколько скорректированы по сравнению с предыдущими примерами цифровых продуктов. Разберем подробнее
представленные артефакты.
169

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

170

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

171

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 51. Концептуальная архитектура аналитического
продукта DWH (часть 1)

Рисунок 52. Концептуальная архитектура аналитического
продукта DWH (часть 2)
На уровне фронтальной и канальной логики осуществляется предоставление API в соответствии со стандартами Open API, для чего используется инструмент Gravitee посредством
применения платформенного сервиса 3.2. Для поддержки высокого быстродействия фронтального слоя применяются технологии кэширования. Для обеспечения работы с кэширующими компонентами используется платформенный сервис 1.4.1, предполагающий в качестве
основы технологической реализации применение программного обеспечения Apache Ignite.
172

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Для резервирования кэшируемой информации задействована реляционная база данных СУБД
PostgreSQL. При этом резервирование осуществляется неявно для платформенного приложения, вследствие чего использование платформенного сервиса 1.1.1 на Рисунке 51 в части
уровня фронтальной и канальной логики не представлено: программные компоненты, создаваемые продуктовыми командами данный сервис не задействуют – они используют платформенный сервис работы с кэш. Событийный обмен с поддержкой журнальной парадигмы осуществляется с использованием программного обеспечения Apache Kafka, при этом продуктовые
команды применяют платформенный сервис 2.1.1 с соответствующей технологической реализацией. Отметим, что мы включаем в архитектуру два принципиально разных варианта использования указанного платформенного сервиса: один обеспечивает поддержку событийного
обмена, второй отвечает за наполнение данными партнерской экосистемы. Отсюда вытекает
требование к применяемой в организации цифровой платформе: сервис работы с потоковым
программным обеспечением должен поддерживать оба заявленных варианта использования.
Кроме того, для поддержки высокоэффективного отображения больших объемов аналитических данных и результатов расчетов применяется платформенный сервис 1.6.1, предполагающий технологическую реализацию с использованием программного обеспечения Apache
Superset.
Архитектурный уровень канало-специфичной продуктовой логики реализуется на языке
программирования Java, поддержка событийного обмена осуществляется посредством платформенного сервиса 2.1.1 с технологической реализацией на основе программного обеспечения Apache Kafka.
На архитектурном уровне хранения продуктовых данных (см. Рисунок 51) для реализации прикладных компонентов используется язык программирования Java. Непосредственно само хранение продуктовых данных (здесь принципиально речь не идет о «сырых»
данных, поскольку они не имеют непосредственно продуктового характера) осуществляется
в распределенной базе данных посредством платформенного сервиса 1.2.1 с технологической реализацией на основе нереляционной СУБД Apache Cassandra. Для обеспечения высокоэффективного доступа к данным применяется механизм кэширования с использованием
платформенного сервиса 1.4.1, предполагающего технологическую реализацию на основе программного обеспечения Apache Ignite. Резервирование кэшируемой информации также осуществляется в распределенной базе данных, для чего, как мы уже отмечали ранее, была дополнена платформенная реализация сервиса кэширования 1.4. Контент, составляющий важную
часть оперативных продуктовых данных, обрабатывается посредством платформенного сервиса 1.3.3 с технологической реализацией Apache Hadoop. Поддержка событийного обмена
осуществляется посредством платформенного сервиса 2.1.1 с технологической реализацией
на основе программного обеспечения Apache Kafka.
Архитектурный уровень продуктовой логики и логики управления бизнес-процессами
(см. Рисунок 52) реализуется в парадигме микросервисной архитектуры с использованием
языка программирования Java. В качестве BPM-движка применяется инструмент управления
бизнес-процессами Kogito, для чего продуктовые команды используют платформенные сервисы 4.1.2 и 4.2.2. Как мы уже отмечали ранее, на уровне платформенного сервиса 4 должна
быть обеспечена унификация работы с шаблонами оркестровки и хореографии с целью снижения нагрузки с продуктовых команд в части реализации инфраструктурных задач. Поэтому
последние должны использовать в своем коде максимально общий платформенный сервис.
На иллюстрации же мы показываем обе реализации явно с целью обеспечения максимальной прозрачности примера. Напомним читателю, что сложность цифрового аналитического
продукта и исключительно высокие требования к его производительности диктуют безусловный приоритет шаблона хореографии при автоматизации управления бизнес-процессами. Контекст процессов и связанная служебная информация хранятся в реляционной базе данных
173

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

СУБД PostgreSQL, для чего в архитектуре указан платформенный сервис 1.1.1 с соответствующей технологической реализацией. Выполнение аналитических расчетов осуществляется
средствами аналитической СУБД реального времени, в качестве которой в рассматриваемом
примере выступает программное обеспечение Apache Druid. Для поддержки выполнения аналитических расчетов продуктовые команды применяют платформенный сервис 1.5.2. Резервирование данных аналитических расчетов и их результатов осуществляется (кроме стандартных
средств, предоставляемых Apache Druid и развиваемых на уровне платформенного решения)
при помощи СУБД Apache Cassandra. Указанное резервирование осуществляется неявно, для
чего предусмотрена связь платформенных сервисов, показанная на Рисунке 50. Тем не менее
прикладные продуктовые сервисы могут и напрямую работать с продуктовыми данными, хранящимися в соответствующей распределенной базе данных, с этой целью на рассматриваемом архитектурном уровне задействован платформенный сервис 1.2.1. «Сырые» данные и контент хранятся в распределенной файловой системе, вследствие чего продуктовые команды
используют платформенные сервисы 1.3.1 и 1.3.3. Отметим, что использование двух реализаций платформенного сервиса 1.3 необходимо ввиду разных принципов работы с большими
данными и контентом. При этом продуктовые команды должны максимально задействовать
возможности общего платформенного сервиса 1.3. Для закачки данных при проведении аналитических расчетов и сегментации аналитической СУБД неявно применяются зависимости
соответствующих платформенных сервисов. Кэширование часто используемой информации
и проведение операций в оперативной памяти осуществляются путем применения платформенного сервиса 1.4.1 с технологической реализацией на основе программного обеспечения
Apache Ignite. Наполнение инструмента визуализации данных также является важной задачей,
решаемой на рассматриваемом архитектурном уровне, с этой целью используется платформенный сервис 1.6.1 с технологической реализацией на основе программного обеспечения Apache
Superset. Поддержка событийного обмена осуществляется посредством платформенного сервиса 2.1.1 с технологической реализацией на основе программного обеспечения Apache Kafka.
Имплементация архитектурного уровня интеграции (см. Рисунок 52) осуществляется,
как и остальных архитектурных уровней аналитического цифрового продукта, с использованием языка программирования Java. При этом сами интеграционные данные хранятся в распределенной базе данных, для чего продуктовые команды используют платформенный сервис
1.2.1 с технологической реализацией на основе программного обеспечения Apache Cassandra.
Для высокоэффективной обработки данных используется механизм кэширования с применением платформенного сервиса 1.4.1, где в качестве базы технологической реализации выступает Apache Ignite. Поддержка событийного обмена осуществляется посредством платформенного сервиса 2.1.1 с технологической реализацией на основе программного обеспечения
Apache Kafka. При этом на данном архитектурном уровне предусмотрена потоковая загрузка
файловых данных, где инструментом для продуктовых команд выступает платформенный сервис 2.3.1, а технологической реализацией – программное обеспечение Apache NiFi.
Уровень архивного хранения в рассматриваемом примере не предусмотрен, а потому он
отсутствует на Рисунке 52.
Подчеркнем, что при реализации продуктов вполне возможным является использование
и проприетарного программного обеспечения, но последнее не является столь гибким, сколь
свободно распространяемое ПО с открытым исходным кодом. Кроме того, настоящая книга
не является рекламой какого-то конкретного производителя, а потому акцентирует внимание
на поддержке такой ключевой тенденции развития архитектуры, каковой является использование открытого ПО.
Резюмируя вышеизложенное, мы должны отметить, что столь объемное рассмотрение
вопроса построения современного аналитического хранилища показывает – хранилище представимо в формате цифрового продукта. И оно обязательно должно выступать именно в таком
174

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

175

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

176

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 53. Искусственный интеллект и закон S-кривой
Мы взяли за основу Рисунок 15 из предыдущего труда («Архитектура цифровых платформ. От настоящего к будущему») и подвинули положение тенденции на S-кривой ближе
к стадии интенсивного роста. Напомним читателю, что закон S-кривой носит качественный
характер. Читатель же может нам возразить: «Все только и говорят об искусственном интеллекте, он становится едва ли не обязательным требованием при трудоустройстве в любой
отрасли экономики – это ли не является свидетельством интенсивного роста?» Мы же ответим
читателю, что хайп нетрудно спутать с интенсивным ростом. Кроме того, интенсивный рост
использования технологии характеризуется не просто ее обсуждением или даже внедрением,
но активным использованием в деятельности и получением отдачи. И далеко не во всех сферах человеческой деятельности на данный момент выполняются все перечисленные условия.
Рассмотрим существующие ограничения подробнее.
Рассуждая о технологиях ИИ, нельзя не повторить то, о чем мы говорили в предыдущих
книгах, – внедрение и использование соответствующих технологий по-прежнему достаточно
дорого. Например, многие современные направления ИИ основаны на больших языковых
моделях (Large Language Model, LLM), обучение которых и адаптация к реалиям деятельности конкретной организации требуют значительных финансовых затрат на инфраструктурное и программное обеспечение. Заочные соревнования кластеров видеокарт, используемых
для обеспечения эффективной деятельности LLM, поражают воображение. Безусловно, существуют LLM, заявляющие сочетание высокой точности работы и относительно низкой стоимости в части инфраструктурного обеспечения, но вследствие не слишком длительной истории
развития данного вопроса не только по меркам человечества, но и даже по меркам отрасли
информационных технологий, независимые исследования пока проведены в весьма ограниченном объеме. В продолжение данной темы многие графовые СУБД, применяемые для реше177

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ния задач работы LLM, используют принципиально отличные механизмы реализации и языки
запросов, что приводит к сложностям технологической унификации.
Важным фактором, сдерживающим интенсивный рост внедрения технологий ИИ в различных отраслях экономики, является унаследованный ИТ-ландшафт, использование ИТрешений, принадлежащих различным архитектурным и технологическим поколениям, «зоопарк» систем и технологий, нередко присутствующий в организациях. Отметим, что подобная
ситуация особенно характерна для крупных компаний ввиду того, что они ведут свою деятельность на рынке длительное время, в результате чего их ИТ-ландшафт объективно наполняется все новыми и новыми элементами, принадлежащими, не побоимся этого слова, к разным технологическим эпохам. При этом именно крупные компании обладают потенциалом
для массового внедрения технологий ИИ – они, как правило, характеризуются соответствующими финансовыми возможностями, кроме того, ИИ потенциально дает им существенный
рост в производительности труда, дополнительно усиленный ввиду масштаба организаций.
Складывается ситуация, соответствующая циклам Кондратьева: унаследованные фонды могут
оказывать не только положительное (например, в виде снижения издержек), но и отрицательное влияние, выражающееся в необходимости масштабной модернизации. Последняя требует
вложения значительных трудовых, временных и финансовых ресурсов. Возникает во многом
парадоксальная ситуация: стартапы могут позволить себе ограниченное внедрение ИИ ввиду
незначительных финансовых ресурсов, имеющихся в их распоряжении, крупные же компании
вынуждены не просто вкладывать ресурсы в ИИ, но и преодолевать отрицательное влияние
унаследованных фондов, ухудшая тем самым P&L своих цифровых продуктов.
Подчеркнем, что технологический «зоопарк» в ИТ-ландшафте компании сам по себе становится серьезным препятствием при внедрении ИИ. Зачастую в подобном системном окружении ИИ становится красивой игрушкой, которая тешит самолюбие многих ответственных лиц
в организации, но не приносит реальной пользы в бизнес-процессах. Действительно, ИИ нуждается в множестве входных данных для корректного обучения и функционирования. Если эти
данные будут принципиально неполными, например, вследствие отсутствия возможности их
корректной автоматической выгрузки средствами унаследованного ИТ-ландшафта либо вноситься в решения ИИ вручную (к сожалению, подобные случаи также имеют место), то эффективность внедрения соответствующего технологического направления будет крайне низкой.
Аналогично, если результаты работы ИИ не будут востребованы перспективными ИТ-решениями в автоматическом режиме, то ценность таких результатов невелика. Исключением можно
признать первичную апробацию применения ИИ и соответствующий поиск вариантов использования рассматриваемого набора технологий.
В сложившейся ситуации использование платформенного подхода выступает важным
и едва ли не ключевым драйвером эффективного внедрения ИИ. Использование современной
цифровой платформы и создание на ее основе архитектурно и технологически унифицированных платформенных приложений, автоматизирующих продукты организации, позволяют
эффективно наполнять информацией ИИ, включать его в бизнес-процессы, немедленно учитывать результаты его работы в деятельности компании. Технологии поддержки ИИ в таком
случае должны быть включены в состав платформы на уровень платформенных сервисов и их
технологических реализаций. При этом использование ИИ должно быть как явным для платформенных приложений, так и скрытым от них. Приведем пример развития платформенных
сервисов работы с данными в части применения технологий ИИ. Иллюстративно он представлен на Рисунке 54.
На Рисунке 54 показано расширение платформенного сервиса работы с данными 1 дополнительной реализацией в части поддержки работы с графовыми СУБД 1.7. Сервис 1.7 содержит две технологические реализации – на основе ArangoDB и Neo4j, пронумерованных
в нашей классификации платформенных сервисов 1.7.1 и 1.7.2 соответственно. Подчеркнем,
178

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

что мы не рассматриваем примеры внедрения технологий поддержки графовых СУБД конкретными организациями, а приводим общие примеры на протяжении всей книги.

Внимательный читатель сделает нам резонное замечание: «Графовые СУБД принципиально отличаются друг от друга. Разная архитектура, разные языки запросов, разные принципы организации данных. Создавать над подобным разнообразием общие абстракции весьма
непросто». И в этом читатель, безусловно, прав. Выше мы уже отмечали сложность унифи179

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

кации в данном аспекте. Но мы никогда не утверждали, что создание полноценной цифровой платформы является элементарной задачей. Уже в третьей нашей книге мы акцентируем
внимание читателя на различных аспектах решения указанной задачи. И поэтому, расширяя
состав платформенных сервисов поддержкой работы с графовыми СУБД, и архитектор, и продуктовая команда, и платформенная команда (если таковая присутствует в компании) должны
отдавать себе отчет в масштабности вопроса, в необходимости корректной проработки соответствующих сервисов и компонентов.
Но довольно о сложностях внедрения ИИ, необходимо обсудить те возможности и перспективы, которые сулит нам ИИ в продуктовом контексте. И начать следует с архитектуры
цифрового продукта в том виде, в каком мы ее уже неоднократно рассматривали по ходу настоящей книги, – в виде распределения по различным архитектурным уровням. Это распределение в общем виде представлено на Рисунках 55 и 56. Мы вновь разбиваем концептуальную
архитектуру продукта на две иллюстрации, чтобы сохранить наглядность восприятия.
На Рисунках 55 и 56 мы привели обобщенную концептуальную архитектуру продукта.
Далее мы предлагаем рассмотреть потенциальное место технологий искусственного интеллекта на каждом архитектурном уровне продукта.

180

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

181

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 55. Концептуальная архитектура продукта (часть 1)

182

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

183

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 56. Концептуальная архитектура продукта (часть 2)
Отдельно отметим, что непосредственно написание программного кода при помощи
интеллектуальных помощников является важным аспектом внедрения ИИ в продуктовую
архитектуру, но в настоящее время данный аспект не может считаться однозначно подтвержденным с точки зрения качества. Мы рассматриваем ИИ при написании реального,
а не демонстрационного кода в качестве помощника, а не замены специалистов. В то же время
указанная помощь уже позволяет существенно повысить производительность труда в компании, применяющей подобный подход.
На уровне фронтального и канального представления технологии искусственного интеллекта при их корректном применении могут позволить эффективно формировать интерфейсы
пользователей из микрофронтендов и учитывать клиентский опыт, принимать активнейшее
участие в разборе событий клиентских приложений. На сегодняшний день важное значение
имеет использование утилит, осуществляющих сбор событий клиентских приложений с упором на возникающие ошибки. В этой ситуации разбор генерируемых событий при помощи
технологий ИИ сможет существенно ускорить развитие приложений. Интеллектуальные алгоритмы позволят эффективно определять порядок кэширования данных, сегментацию данных
в части потребностей в оперативном хранении, а также сформировать порядок «выживания»
объектов в оперативной памяти при ее очистке и/или перезаписи. Порядок эластичного масштабирования, алгоритмы автоматического добавления и удаления узлов также могут учитывать рекомендации нейросетей. Особенно это актуально уже в процессе эксплуатации, позволяющем обучить нейросеть на множестве реальных примеров работы.
На уровне канало-специфичной логики технологии ИИ позволят обеспечить корректную
адаптацию логики под конкретный канал обслуживания, кроме того, благодаря ИИ становится
возможным обрабатывать значительно большее количество канальных событий, относящихся
к клиентскому опыту. Результатом указанной обработки могут стать рекомендации по развитию продукта в части специфики, характерной для тех или иных каналов обслуживания.
Например, какая-то логика может быть признана не канало-специфичной, в ее части может
быть выявлен смысл масштабирования и на иные каналы обслуживания клиентов и партнеров
организации.
Хранение оперативных данных, связанных с продуктовой логикой, представляет собой
благодатную почву для работы ИИ – на основании указанных данных возможно обучение моделей, предоставление рекомендаций, коррекция алгоритмов функционирования продуктовой логики. Также интеллектуальные алгоритмы могут внести коррективы в исполнение таких служебных задач, как эффективное масштабирование компонентов, отвечающих
за работу с данными. Кроме того, учитывая тот факт, что нередко для хранения продуктовых
данных используются распределенные базы данных, ИИ может сформировать качественные
алгоритмы управления кластерами соответствующих баз данных. В общем случае это является весьма нетривиальной задачей. Также ИИ помогает оптимизировать ресурсоемкие алгоритмы резервирования, что актуально, например, при обеспечении дополнительной надежности кэширующих компонентов.
На уровне продуктовой логики и логики управления бизнес-процессами ИИ буквально
незаменим. Особенно это утверждение актуально для бизнес-процессов. Как мы уже неоднократно подчеркивали ранее, бизнес-процессы должны соответствовать процессам жизненного цикла продуктов, предоставляемых организацией клиентам и партнерам. В этой ситуации
ИИ в состоянии осуществлять комплексное моделирование указанных процессов на громадном количестве кейсов. Результаты этого моделирования могут использоваться при переработке и рефакторинге процессов. Причем речь в данном случае идет как о продуктовом, так
и о техническом рефакторинге. Первый позволяет оптимизировать привязку бизнес-процес184

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

сов к процессам жизненного цикла продукта, более того – учитывать при этом рыночные тенденции с небывалой ранее эффективностью. Второй – оптимизировать собственно исполнение
процесса, что приводит к увеличению их эффективности (и прибыльности), а также к снижению инфраструктурных затрат на их обеспечение. Например, изменение границ локальных
контекстов может привести к минимизации объемов информации, сохраняемой в ходе исполнения глобального бизнес-процесса, что снижает затраты на его исполнение. Учитывая, что
в организации могут одновременно исполняться сотни и тысячи экземпляров бизнес-процессов, экономия может оказаться весьма существенной. А ключом к этой экономии становится
использование ИИ для оценки и моделирования процессов. Решение вопросов эластичного
масштабирования прикладной и процессной логики также может быть оптимизировано путем
применения интеллектуальных алгоритмов и их обучения на реальных примерах.
Интеграционная логика может задействовать ИИ при обеспечении эффективного масштабирования, что исключительно важно на данном архитектурном уровне. В современном
ИТ-ландшафте нагрузка на интеграционные взаимодействия существенно изменяется во времени, возможны как значительные пиковые нагрузки, так и долговременное падение интенсивности взаимодействий. В этой ситуации интеллектуализация масштабирования ответственных
за интеграцию компонентов может привести к заметному повышению эффективности продуктового ИТ-решения в части эксплуатации.
Уровень архивации данных продукта имеет важное значение в контексте применения
ИИ. Во-первых, логика перевода продуктовых данных из оперативных в архивные может изменяться во времени и должна учитывать специфику работы продуктового ИТ-решения. То есть
указанная логика должна «интеллектуализироваться» во времени, что позволит существенно
сократить инфраструктурные затраты на исполнение цифрового продукта. Кроме того, архивные массивы информации зачастую представляют собой значительные объемы данных, пользу
которых для обучения моделей ИИ трудно переоценить. Обученные на основе столь масштабных объемов данных модели могут монетизироваться, в том числе на внешнем с точки зрения
организации рынке. Тем самым опосредованно улучшается P&L продукта.
Резюмируя вышеизложенное, отметим, что ИИ применим на каждом архитектурном
уровне современного цифрового продукта. Внедрение соответствующих технологий в продуктовую автоматизацию – требование времени. Масштабы внедрения должен определять архитектор. При этом необходимо учитывать, что снижение затрат на создание и исполнение продуктовых решений позволяет окупать высокую стоимость самих технологий искусственного
интеллекта.
Но только рассмотрением пользы внедрения технологий ИИ в архитектуру продукта мы
в нашем изложении ограничиться не можем. Настоящая книга, как следует из ее названия,
посвящена не только архитектуре, но и концепции современного и устремленного в будущее
цифрового продукта. А концепция продукта основана на той ценности, которую он несет клиентам и партнерам организации. Ценность же, в свою очередь, оцифровывается в P&L. И в данном аспекте ИИ также может существенно помочь компании.
На сегодняшний день многие организации разрабатывают весьма сложные модели расчета P&L. Но рядом соседствует иная ситуация, при которой P&L рассчитывается едва ли
не кустарно, как принято говорить, «на коленке». Оба способа работы со столь важным показателем содержат серьезные изъяны. При наличии сложных моделей расчета нередко становится
весьма затруднительным выявить ошибки или несоответствия внешним условиям, ввиду сложности и перегруженности моделей возможно непроизвольное игнорирование тех или иных
рыночных тенденций, что приводит к некорректному расчету P&L, избыточным или недостаточным вложениям в развитие соответствующего продукта, как следствие, к убыткам организации и снижению ее конкурентоспособности. Расчет P&L «на коленке» зачастую в принципе
игнорирует рыночные тенденции, в результате чего развитие продукта осуществляется по наи185

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

тию, что в свою очередь также приводит к убыткам компании. В этой ситуации подключить
ИИ к разработке и актуализации моделей расчета P&L, анализу рыночных тенденций, учету
результатов анализа в упомянутых моделях оказывается весьма своевременным шагом. ИИ
бесстрастен и учитывает все тенденции развития продуктового рынка, на которых обучалась
соответствующая модель. Нередко рекомендации ИИ оказываются исключительно свежими
(как удивительным с точки зрения теории игры Го оказался алгоритм, по которому ИИ обыграл
чемпиона мира) и позволяют вдохнуть новую жизнь в развитие цифровых продуктов организации. Оценка и анализ P&L являются важным направлением внедрения ИИ, которым компании, стремящиеся обеспечить собственную конкурентоспособность в современном цифровом
мире, не могут пренебрегать.
Искусственный интеллект не просто анализирует рыночные тенденции. В нашем предыдущем труде («Архитектура цифровых платформ. От настоящего к будущему») мы уже поднимали вопрос создания цифровых слепков личности. При помощи ИИ возможно создание
цифровых слепков личности самых разных специалистов. В настоящее время в публичной
плоскости акцент делается на слепки личности сотрудников, работающих в компании и выполняющих определенные роли. Это, безусловно, крайне важно. Например, создавая цифровые
слепки личности архитекторов и программистов и продавая их заказчикам, возможно кратно
повысить общую производительность труда. Но в контексте продуктов важен и иной аспект.
При помощи ИИ можно создать цифровой слепок клиента, которому продукт предоставляет
ценность. А также цифровой слепок партнера, который, используя продукт, создает дополнительную ценность. И на основании указанных слепков, их поведения и развития осуществлять
моделирование цифрового продукта, вносить коррективы в его развитие и максимально адаптировать к рыночным ожиданиям. Такие продукты окажутся максимально конкурентоспособными на рынке.
Внимательный читатель воскликнет: «Вы перечислили так много преимуществ от внедрения искусственного интеллекта в создание и развитие продуктов, может показаться, что
лишь недалекие люди будут против данного технологического направления! Между тем кроме
энтузиастов есть и немало скептиков, не ждущих от ИИ ничего хорошего. С чем это связано?»
Мы согласимся с читателем, что значительный скептицизм на рынке присутствует. И связан
он с несколькими аспектами. Рассмотрим их подробнее.
Во-первых, немалое количество участников рынка испытывает опасения, что ИИ заменит их и лишит возможности трудоустройства. Тем более что многие броские заголовки, проскальзывающие в прессе, способствуют указанным опасениям. Сюда же отнесем страх перед
«восстанием машин», вызванный рядом художественных произведений. Целью нашей книги
не является разбор достоинств и недостатков книг и фильмов об искусственном интеллекте,
мы лишь предлагаем читателю не принимать на веру обязательную для всякого продукта массовой культуры гиперболу. Что же касается замены человека искусственным интеллектом, то,
как нам кажется, указанные страхи нескольку преувеличены. В свое время луддиты разбивали
станки, считая, что они отберут работу у людей, но массовое внедрение станочного парка,
наоборот, привело к массовому производству и массовой занятости. Аналогично ИИ должен
стать помощником человеку. Надо не бояться новых технологий, а учиться использовать их
себе во благо.
Во-вторых, скептицизм в отношении ИИ основан на уже упоминавшейся нами ранее значительной стоимости соответствующих технологий. На сегодняшний день интеллектуальные
технологии не прошли точку перелома, еще не начат устойчивый интенсивный рост их внедрения в различных областях экономики, что мы схематично показали на Рисунке 53. Читатель
может не согласиться с нами, указав на активнейшее внедрение ИИ, осуществляемое самыми
разными компаниями. Безусловно, такое внедрение осуществляется. Но спецификой закона
S-кривой является то, что она показывает переход технологий от условно исследовательской
186

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

фазы именно к интенсивному росту, сопровождающемуся резким ростом отдачи (результата
внедрения технологии) при снижении их стоимости. Условно говоря, переход к интенсивному
росту технологии характеризуется тем, что последняя приобретает инфраструктурный характер. Например, мобильная связь поначалу была уделом немногих, характеризовалась нешироким распространением и высокой стоимостью. Но в какой-то момент, по мере развития
технологий, базовые станции начали возникать повсеместно – технология приобрела инфраструктурный характер и начала использоваться практически всеми. Подобный переход для ИИ
нельзя считать свершившимся фактом. Продолжение внедрения технологий по-прежнему требует весьма значительных затрат трудовых, временных и финансовых ресурсов. В случае кризисных явлений в мировой экономике может существенно замедлиться или вообще прекратиться внедрение ИИ. Во избежание подобных негативных ситуаций искусственный интеллект
провозглашается стратегической целью развития крупнейших экономик нашей планеты. Будем
надеяться, что рассматриваемое нами технологическое направление пройдет точку невозврата
и уже не будет нуждаться в столь масштабной поддержке.
В-третьих, на многих направлениях результаты внедрения ИИ пока являются весьма
скромными и не поражают воображение. В отдельных случаях ИИ выдает явно ангажированные результаты, обусловленные спецификой обучения моделей, иногда результаты его работы
носят очень общий характер, неприменимый в реальной деятельности компаний, иногда же он
сам продуцирует ошибки. Это связано с относительной молодостью интеллектуальных технологий и необходимостью повышения их зрелости. При этом ожидания от ИИ во многом завышенные. 2022 год стал годом публикации ряда инструментов, перевернувших представление
о современных возможностях ИИ. К таковым инструментам можно отнести ChatGPT. Но завышенные ожидания могут сыграть злую шутку как с инструментом, так и с теми, кто его использует. Ожидая чуда, можно впасть в отчаяние при его отсутствии, ведь чудеса редки даже в цифровом мире. Хорошо характеризуют подобное разочарование такие исследования, как «цикл
хайпа» от аналитического агентства Gartner, а также эффект Даннинга – Крюгера. Отметим,
что их визуализации весьма близки. Остановимся на эффекте Даннинга – Крюгера, тем более
что в книге «Архитектура цифрового мира» при разборе ментальных ошибок современности
мы посвятили ему специальный раздел. Схематично оценка ИИ в соответствии с эффектом
Даннинга – Крюгера приведена на Рисунке 57.

Рисунок 57. ИИ и эффект Даннинга – Крюгера
187

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Мы приведем описание метакогнитивного искажения, схематично представленного
на Рисунке 57, на основе цитаты из книги «Архитектура цифрового мира»:
«Если кратко описывать зависимость уверенности в своих силах от опыта и знаний, то
на начальном периоде накопления опыта и приобретения квалификации уверенность (в данном случае более правильно говорить о самоуверенности) растет исключительно быстрыми
темпами, за которыми «не успевают» компетенции. Подобный резкий рост самоуверенности
может привести к серьезным ошибкам в профессиональной деятельности, следствием чего
могут оказаться убытки организаций. В какой-то момент наступает так называемый «пик тупости», когда у человека создается впечатление, не основанное на его компетенциях, о том,
что он в состоянии решить любую проблему, в том числе очень сложную. Но жизнь не стоит
на месте. По мере погружения во все более сложные проблемы (вкупе с ростом компетенций
в соответствующей области либо с изменением условий решения задач) приходит понимание
того, что имеющийся уровень компетенции недостаточен для достижения успеха. Подобное
«открытие» зачастую оказывается весьма болезненным и приводит к резкому падению самооценки. Как правило, падение самооценки сопровождается отсутствием веры в собственные
силы и профпригодность. Падение самооценки получило название «обрыв осознания», низшая точка падения обычно растянута во времени, а потому называется «ущелье отчаяния».
Но повышение компетенции и приобретение дополнительного опыта, как правило, делают свое
дело. Начинается новый рост самооценки и уверенности в собственных силах. Он более плавный, нежели на начальном этапе, но учитывает ошибки предшествующих периодов и последовавшее за ними разочарование. В какой-то момент наступает стадия насыщения: данная стадия
характеризуется равновесным состоянием уверенности в собственных силах и уровня компетенции. Данная стадия получила название «плато силы» или «плато стабильности». Стадия же
выхода из «ущелья отчаяния» на «плато стабильности» традиционно именуется «тропой просветления».
Искусственный интеллект также проходит в общественном восприятии через описанные выше стадии. Как экспертное, так и широкое сообщество верили в стремительное решение значительного количества проблем в различных отраслях экономики при помощи ИИ.
Но сейчас (не без помощи скептиков) на рынке наблюдается определенное разочарование. Да,
есть энтузиасты как среди отдельных экспертов, так и среди крупных компаний, но нередко
можно услышать альтернативные мнения, которые даже отказывают искусственному интеллекту в наличии собственно интеллекта. Скептики апеллируют к отсутствию у него интуиции,
упрекают в принятии обобщенных решений, основывающихся на статистических тенденциях,
упрекают в частных ошибках, проецируя их на общие закономерности. Указанный скептицизм
и определяется обрывом сознания, вызванным тем, что «долог путь из Ада к Свету», как писал
Джон Мильтон в поэме «Потерянный рай». Отсутствие быстрых успехов, ожидавшихся раззадоренной первыми достижениями публикой, привело к разочарованию и обрыву сознания.
Рискнем предположить, что «ущелье отчаяния» еще впереди. Искусственный интеллект еще
не сворачивает горы, и общественная психология диктует будущее нарастание разочарования.
Но в нашем мире, пусть и цифровом, отсутствует магия. Единственным способом преодолеть
разочарования является долгая и упорная работа. Мы уже упоминали, что на уровне крупнейших экономик ИИ провозглашается стратегическим приоритетом. И только таким образом
можно будет выйти на «тропу просветления», а затем и на «плато стабильности». Крайне важно
не остановиться и не свернуть с этого пути.
В настоящем разделе мы рассмотрели искусственный интеллект в качестве одной из ключевых тенденций развития архитектуры. Уделили внимание как скепсису, высказываемому
в отношении данного технологического направления, так и тем преимуществам, которые
ИИ несет цифровым продуктам. Завершая раздел, подчеркнем, что искусственный интеллект
является краеугольным камнем значимого повышения эффективности при создании и разви188

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

189

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровые продукты и связанные
тренды развития архитектуры
В предыдущих разделах настоящей главы мы рассмотрели такие ключевые тренды развития архитектуры, как открытый код, распределенность, бизнес-процессы, данные и искусственный интеллект. Все указанные тенденции мы рассматривали в контексте проектирования
и реализации конкурентоспособных цифровых продуктов, поскольку в предыдущих книгах
(«Архитектура цифрового мира» и «Архитектура цифровых платформ. От настоящего к будущему») уже давали их развернутое описание и рассматривали вопросы применения при создании современных цифровых платформ. В то же время мы неоднократно затрагивали вопросы
ряда трендов, которым непременно должна следовать современная архитектура. Не выделяя
данные тренды столь рельефно, как рассмотренные ранее, мы тем не менее обязаны раскрыть их читателю – без указанного рассмотрения глава, посвященная развитию архитектуры,
окажется неполной. Мы, как и в предыдущей книге, именуем такие тенденции связанными,
поскольку они играют важную роль при проектировании конкурентоспособной архитектуры,
но при этом связаны с рассмотренными ранее ключевыми трендами. Напомним читателю,
какие тенденции являются связанными:
• Эластичное масштабирование.
• Применение облачных технологий и создание бессерверных (serverless) архитектур.
• Омниканальность.
• Микрофронтенды.
Как и ключевые тренды развития архитектуры, связанные тенденции мы будем рассматривать в разрезе их применения при создании цифровых продуктов.
По ходу настоящей книги мы уже неоднократно затрагивали вопросы эластичного масштабирования, подчеркивали при рассмотрении различных аспектов проектирования цифровых продуктов необходимость обеспечения такого масштабирования. Настало время рассмотреть непосредственно данную тенденцию, уделить внимание ее значимости в современной
архитектуре, а также дать некоторые направляющие по учету указанной тенденции в продуктовой разработке.
Как мы уже неоднократно подчеркивали, современный цифровой мир является миром
дистанционных каналов обслуживания. Пытаясь исключить либо не учитывать в своем развитии подобные способы взаимодействия с клиентами и/или партнерами, организация сознательно снижает собственную конкурентоспособность. Продукт, не имеющий вариантов предоставления потребителям посредством дистанционных каналов, обладает априори худшим
P&L, нежели его конкуренты, не пренебрегающие такими возможностями. Обратной стороной
доступности продукта являются принципиально возросшие требования к производительности
и надежности продуктового ИТ-решения, отвечающего за автоматизацию соответствующего
продукта. Перечислим требования, которые возникают к продуктовому ИТ-решению, обеспечивающему предоставление продукта клиентам и партнерам компании посредством дистанционных каналов:
• Высокая доступность. Конкурентный продукт должен быть всегда доступен на рынке.
Надежность такого цифрового решения измеряется минимум четырьмя (99,99%), а зачастую
и пятью девятками (99,999%).
• Высокие показатели производительности. Пользователь не будет ждать долгого отклика
интерфейсов фронтального представления продукта.
190

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Поддержка продуктовым ИТ-решением пиковых нагрузок. В условиях дистанционных
каналов нагрузка на цифровой продукт может изменяться непредсказуемо, при этом доступность продуктового ИТ-решения не должна пострадать.
• Поддержка самых различных дистанционных каналов. Многообразие вариантов получения ценности улучшает клиентский опыт и обеспечивает улучшение P&L. Обратной стороной многообразия является необходимость обеспечивать лучшие рыночные показатели производительности и надежности для всех поддерживаемых каналов обслуживания.
Выполнение вышеперечисленных требований является крайне непростым для современных ИТ-решений. Но возможным. В условиях предыдущих архитектурных и технологических поколений обеспечение столь высоких показателей надежности и производительности,
какие диктует современный рынок, было зачастую недостижимой целью. Особенно это касалось работы при пиковых нагрузках. Почему же так происходило?
Представим себе, к примеру, монолитную ИТ-систему, соответствующую архитектурным подходам пятнадцатилетней давности. Подобная система (а их в ИТ-ландшафте организации могло присутствовать несколько десятков, объединенных в парадигме SOA) состояла
из набора сильно связанных подсистем, принимавших различное участие в автоматизации бизнес-процессов компании. Те или иные подсистемы задействовались в разном объеме различными бизнес-процессами. И если бизнес-процесс выводился в дистанционные каналы обслуживания, то задачи масштабирования возникали в отношении всех программных комплексов
целиком: оказывалось невозможным масштабировать какой-то один элемент логики в составе
системы. При этом развертывание системы не является бесплатным. Вне зависимости от варианта хостинга система либо использовала внутренние мощности организации, либо арендуемые внешние вычислительные ресурсы. Технологии предыдущих поколений также требовали
значительных усилий при осуществлении масштабирования. Особенно критичным было масштабирование работы с данными. Результатом оказывались значительные затруднения при
обеспечении доступа к подобным информационным системам посредством дистанционных
каналов: либо масштабирование оказывалось исключительно трудоемким, либо поддержание
доступности систем, учитывавшее пиковые нагрузки, превышало все разумные финансовые
пределы и оказывалось доступным лишь самым финансово успешным организациям.
Распределенные архитектуры кардинальным образом изменили подход к масштабированию. Представим себе ИТ-решение, спроектированное и реализованное в парадигме микросервисной архитектуры. Напомним, что мы не рассматриваем варианты некачественного
проектирования систем в указанном архитектурном направлении, так называемые «распределенные монолиты». При независимости различных составляющих элементов оказывается
возможным в ходе проведения нагрузочного тестирования сформировать правила масштабирования, применимые к каждому конкретному элементу. Исполнение данных правил обеспечит работоспособность системы в целом. Одновременно с этим, создавая легковесные компоненты (а именно такой вариант проектирования и реализации нам диктует микросервисная
архитектура), мы можем минимизировать инфраструктурные затраты на каждый компонент,
а соответственно, и на группу компонентов при осуществлении их масштабирования. Таким
образом, распределенность обеспечивает совершенно иной подход к достижению требуемых
рынком показателей производительности и надежности.
Но просто возможность масштабирования сама по себе дает лишь очень ограниченные
преимущества. Мы можем, используя парадигму микросервисной архитектуры и возможности
оркестратора контейнеров, например Kubernetes, увеличивать число объектов, ответственных
за исполнение логики решения. Любой администратор, адекватно оценивающий трудозатраты
на выполнение подобной работы, сразу скажет, что ручное управление кластером Kubernetes,
да еще и обеспечение его надежности на уровне четырех или пяти девяток, является весьма
191

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

непростой задачей. Архитектор добавит к словам администратора еще и напоминание о том,
что далеко не всякое решение сохраняет работоспособность, включая корректность обработки
данных и сохранение состояния, при масштабировании «из коробки». Возможно, они оба
(администратор и архитектор) добавят немало крепких слов относительно реальных рабочих
кейсов. Так в чем же дело, почему просто масштабирование само по себе содержит немало
вызовов, которые должны быть обязательно решены, если мы говорим о современном продуктовом ИТ-решении?
Во-первых, мы уже упоминали, что инфраструктурные мощности, обеспечивающие
исполнение современных цифровых решений («информационных систем» нового поколения,
если кому-то из читателей привычно использовать устоявшуюся терминологию), являются
совсем небесплатными для компании, создающей и развивающей цифровые продукты. Указанные мощности либо закупаются для развертывания on-premise решений (возможно, в формате
частного облака), либо арендуются у внешнего поставщика услуг. Коэффициент переподписки
также ограничивает возможности параллельного распределения мощностей для исполняемых
решений. И если мы будем просто масштабировать каждое решение, пусть даже и точечно, учитывая их распределенность, это все равно приведет к значительным финансовым затратам. Мы
уже упоминали, что нагрузки, которые должны выдерживать современные продуктовые ИТрешения, носят непредсказуемый характер. Как правило, рассуждая о динамике нагрузки, особое внимание уделяют их пиковым значениям. Это закономерно – цифровой продукт должен
быть доступен вне зависимости от того, какая нагрузка оказывается на него в каждый конкретный момент времени. Но нагрузка может не только резко возрастать, но и стремительно уменьшаться, а в таком случае использование инфраструктурных мощностей, рассчитанных под
максимальные нагрузочные параметры, приведет лишь к избыточным финансовым затратам
компании. И отсюда следует первый вывод: масштабирование должно осуществляться по требованию. То есть при росте нагрузки должны добавляться новые вычислительные узлы, при
снижении количество последних также должно снижаться, минимизируя финансовые затраты
на исполнение продуктового ИТ-решения. Отметим, что затраты на вычислительные мощности напрямую влияют на P&L продукта.
Во-вторых, мы должны вновь обратиться к комментарию, данному выше системным
администратором относительно управления масштабированием. Добавим сюда, что автоматическое масштабирование априори исключает ручную работу специалистов по обслуживанию –
они просто не справятся с подобным режимом работы. Кроме того, подобный подход (привлечение администраторов для ручного управления масштабированием) напрямую ведет к резкому росту числа специалистов, вовлеченных в сопровождение продуктового ИТ-решения. Мы
уже неоднократно указывали в предыдущих книгах («Архитектура цифрового мира» и «Архитектура цифровых платформ. От настоящего к будущему») на разницу в мышлении между
продуктологом и владельцем продукта. Мы отмечали, что нередко организации, осуществляющие продуктовую трансформацию, предполагают развитие сотрудников, традиционно выполнявших роль продуктологов, в полноценных владельцев продуктов, подчеркивали необходимость изменения мышления специалистов в ходе подобного развития. Одним из ключевых
аспектов нового продуктового мышления является то, что жизненный цикл продукта затрагивает не только его запуск на рынке. Жизненный цикл продукта гораздо больше, в том числе
он включает операции по сопровождению продуктового ИТ-решения. Рост числа системных
администраторов, занятых в процессах сопровождения, окажет крайне негативное влияние
на P&L цифрового продукта. Отсюда мы можем сделать вывод, что масштабирование в современных условиях непременно должно осуществляться в автоматическом режиме с минимальным вовлечением ручного труда. А практики «инфраструктура как код» (infrastructure as code,
IaC) приходят в этом случае нам на помощь.
192

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Резюмируя два вышеприведенных пункта, мы можем заключить, что современное эластичное масштабирование должно осуществляться по требованию в автоматическом режиме.
При этом практики эластичного масштабирования работают не только на увеличение,
но и на уменьшение используемых цифровым продуктом инфраструктурных мощностей.
Таким образом, эластичное масштабирование является значимым аспектом влияния на P&L
продукта, а потому представляет собой важную тенденцию развития архитектуры. Одновременно с этим мы неоднократно подчеркивали сложность архитектуры современного цифрового продукта. И если мы говорим о требованиях к масштабированию, выраженных в приведенных выше двух пунктах, то мы должны обязательно добавить и третий, он же главный – при
осуществлении масштабирования продуктовое ИТ-решение должно сохранять работоспособность. Что же под этим подразумевается, мы рассмотрим на примере продуктовой архитектуры, которая приведена на Рисунках 58 и 59. Мы вновь разбиваем представление продуктовой архитектуры на две иллюстрации для обеспечения наглядности.
На Рисунках 58 и 59 мы скорректировали некоторые технологии реализации компонентов по сравнению с предыдущими примерами, акцентируя внимание на их большей масштабируемости. Рассмотрим это более детально.

193

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

194

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 58. Концептуальная архитектура масштабируемого
продукта (часть 1)

195

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

196

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 59. Концептуальная архитектура
масштабируемого продукта (часть 2)
Каждый архитектурный уровень должен масштабироваться как индивидуально сам
по себе, так и в составе продуктового ИТ-решения в целом. Поэтому мы последовательно
осветим вопросы масштабирования компонентов и уровней, схематично представленных выше
на иллюстрациях.
Уровень фронтального и канального представления особенно критичен с точки зрения
клиентского опыта. Поэтому гарантированное исполнение требований в части производительности и надежности для данного архитектурного уровня особенно существенно по сравнению со смежными. Приведенное утверждение может показаться спорным, но лишь на первый
взгляд. Фронтальное и канальное представление осуществляет прием всех клиентских и партнерских запросов, выдачу необходимой заинтересованным участникам взаимодействия с продуктовым ИТ-решением информации. При этом трансляция полученных вызовов на смежные архитектурные уровни осуществляется не в соотношении «один к одному», а чаще всего
«один ко многим». Например, асинхронное кэширование данных позволяет резко минимизировать число синхронных запросов от фронтальных компонентов к компонентам оперативного
хранения информации. Безусловно, обеспечение корректной синхронной работы фронтальных компонентов может потребовать и значительного количества заранее проведенных операций на смежных архитектурных уровнях, но при их осуществлении в асинхронном режиме
оказывается возможным снизить общую нагрузку на продуктовое ИТ-решение по сравнению
с синхронными вызовами. В общем случае, разумеется, в ходе проектирования цифрового
продукта (и, конечно, платформенного решения, применяемого в компании) необходимо осуществлять потенциальную трассировку вызовов и рассчитывать требуемые нагрузочные параметры в разрезе различных типов вызовов для всех архитектурных уровней и компонентов
самостоятельно.
Компоненты фронтальной логики в нашем примере (см. Рисунок 58) проектируются
и реализуются в парадигме микросервисной архитектуры с использованием языков программирования высокого уровня. Для упрощения управления ими может использоваться технология контейнерной виртуализации с применением оркестратора контейнеров, в частности,
упомянутого выше Kubernetes. В этом случае количество компонентов может автоматически
увеличиваться при росте нагрузки и снижаться при ее уменьшении. Также возможно применение сложных непрямых алгоритмов масштабирования, в том числе основанных на практиках машинного обучения. С учетом всего вышеизложенного, масштабирование должно осуществляться автоматически, а используемые для этого алгоритмы положены в кодовую базу
и включены в состав продуктового ИТ-решения. В том числе необходим учет указанных алгоритмов в рамках релизной модели продукта. Отметим также, что алгоритмы масштабирования должны быть реализованы таким образом, чтобы минимизировать (а в идеале исключить)
вмешательство специалистов.
Сервисы предоставления API в примере, схематически изображенном на Рисунке 58,
также реализуются в микросервисной парадигме. Их масштабирование может осуществляться
аналогично компонентам фронтальной логики.
Здесь важно обратить внимание читателя на тот факт, что, создавая компоненты логики
(и это касается всех архитектурных уровней примера), мы следует лучшим практикам микросервисной архитектуры, которые определяют необходимость реализации микросервисов
в формате stateless компонентов без сохранения состояния. Это крайне важный момент, который позволяет существенно облегчить масштабирование, в том числе эластичное. Еще одной
практикой, позволяющей обеспечить работоспособность цифрового решения при его масштабировании, является управление транзакционным контекстом. Если, как мы уже неоднократно
197

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

отмечали по ходу настоящей книги, транзакции ограничены одним вызовом микросервиса,
не происходит разрыва контекста между вызовами, то при масштабировании компонентов
нет необходимости отдельно прорабатывать такие вопросы, как, например, «докат» транзакции, либо вызов конкретного экземпляра (последнее зачастую попросту недостижимо в современной архитектуре), либо репликация состояния конкретного сервиса. Вопрос репликации
компонентов с сохранением состояния будет раскрыт чуть ниже. В нашем примере сервисы
не сохраняют состояние между вызовами, а локальные транзакции ограничены конкретными
вызовами. Вследствие этого эластичное масштабирование может осуществляться автоматически с использованием современных средств управления инфраструктурой.
Гораздо сложнее обстоит дело с масштабированием компонентов, которые (в соответствии с архитектурой) должны обеспечивать сохранение состояния. Это касается кэширующих компонентов, распределенных СУБД, потокового программного обеспечения. В целях
наиболее рельефного отображения поддержки эластичного масштабирования мы заменили
по сравнению с предыдущими примерами тип СУБД на архитектурном уровне фронтального
и канального представления: перешли от реляционных к распределенным NoSQL СУБД ввиду
лучшей масштабируемости последних.
В чем же сложность масштабирования компонентов, сохраняющих информацию?
В общем случае создание новых вычислительных узлов, обеспечивающих исполнение соответствующих технологических элементов (или сокращение их количества) предполагает не только
обеспечение доступности и отработку базовых запросов, например, чтения или записи,
но и сохранение той информации, которая уже содержалась в решениях, обеспечение ее
эффективного распределения по узлам, а также корректное выполнение всех операций, запущенных в ходе работы ИТ-решения. Примерами требований, решаемых при масштабировании
компонентов с сохранением состояния, могут выступать:
• Добавление новых узлов в кэш не должно приводить к тому, что микросервисные
компоненты, запрашивая в них информацию, получают пустой ответ ввиду того, что данные
не были реплицированы между узлами.
• Добавление новых узлов в кэш или в распределенную СУБД не должно приводить
к ситуации увеличения запросов между узлами геораспределенного ЦОД, поскольку рост
числа подобных запросов приведет к серьезным задержкам ввиду сетевой латентности.
• Масштабирование должно учитывать характеристики используемых технологических
решений. Не должно создаваться количество узлов развертывания, которое не обеспечит корректность функционирования, например, вследствие отсутствия кворума.
• Корректность работы кластерных конфигураций и репликация состояния между кластерными узлами должны поддерживаться при выполнении любых алгоритмов масштабирования.
• И т. д.
При этом необходимо отметить, что алгоритмы масштабирования показанных в архитектуре компонентов с сохранением состояния должны учитывать их согласованное исполнение.
Например, использование механизмов распределенной СУБД для резервирования кэшируемых данных предполагает, что при масштабировании кэш осуществляется адекватное масштабирование и базы данных: оно совершенно необязательно должно осуществляться «один
к одному», но оно должно обеспечивать эффективное резервирование (как и восстановление
из резерва) масштабируемой топологии. Для данного примера актуально утверждение, приведенное выше, – не должно увеличиваться количество вызовов между ЦОД. Одновременно
с этим накопление данных, планируемых для использования микросервисными компонентами фронтальной логики или предоставления API, должно осуществляться таким образом,
198

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

чтобы избежать увеличения числа вызовов к компонентам смежных архитектурных уровней
или к удаленным ЦОД ввиду некорректности репликации состояния при масштабировании.
Для распределенных компонентов, сохраняющих состояние, должна быть предусмотрена сегментация с независимым масштабированием сегментов, чтобы исключить пересинхронизацию
всего кластера при добавлении в него новых узлов – при большом количестве узлов временные
задержки на выполнение подобной процедуры могут оказаться весьма значительными.
Таким образом, мы видим, что эластичное масштабирование обеспечивается не только
использованием технологий, поддерживающих распределенность, но и корректными алгоритмами их масштабирования по требованию. Указанные алгоритмы должны учитывать технологические особенности компонентов, их топологии, варианты использования.
Уровень канало-специфичной логики, схематично представленный на Рисунке 58, должен следовать описанным выше алгоритмам для уровня фронтальной и канальной логики:
масштабирование микросервисных компонентов, реализующих непосредственно канало-специфичную логику, должно осуществляться автоматически, масштабирование компонентов
событийного обмена должно учитывать необходимость сохранения состояния, а также обеспечивать корректное и согласованное состояние кластера при изменении числа узлов (в том
числе в условиях георезервирования).
При обеспечении эластичного масштабирования архитектурного уровня оперативного
хранения продуктовых данных рекомендуется придерживаться следующих правил:
• Микросервисные компоненты логики управления оперативным хранением данных
могут эластично масштабироваться таким образом, чтобы обработка запросов выполнялась
с минимальными временными задержками.
• Масштабирование кэширующих компонентов и распределенных баз данных должно
осуществляться таким образом, чтобы вопросы резервирования данных и восстановления
из резерва решались максимально оперативно, при этом доступность данных была на уровне,
соответствующем требованиям современного цифрового мира. При этом в условиях георезервирования вызовы, направляемые от компонентов логики хранения к компонентам с сохранением состояния, осуществлялись в рамках одного ЦОД с получением всей необходимой
информации. Выполнение операций в оперативной памяти не должно некорректно завершаться в результате осуществления эластичного масштабирования. Пересинхронизация кластеров при изменении числа узлов не должна снижать доступность и приводить к заметным
временным задержкам.
• При масштабировании потокового программного обеспечения, ответственного за событийный обмен, не должно создаваться пространства для заметных временных задержек,
информация должна реплицироваться между узлами таким образом, чтобы не пострадала
надежность выполнения операций. Должно поддерживаться георезервирование.
Уровень управления бизнес-процессами, схематично представленный на Рисунке 59,
расширен по сравнению с ранее рассмотренными примерами и учитывает варианты развития технологий управления бизнес-процессами, описанные в соответствующем разделе ранее.
Прикладные и процессные микросервисы используют для сохранения данных, включая контекст процесса, кэширующие компоненты. Для резервирования последних применяется распределенная база данных на основе NoSQL СУБД. Для поддержки алгоритмов прогрева кэш,
а также событийно-ориентированного взаимодействия, а том числе в рамках реализации шаблона хореографии, используется потоковое программное обеспечение.
Требования к масштабированию компонентов рассматриваемого архитектурного уровня
во многом аналогичны описанным выше. При этом нужно учитывать, что в ходе исполнения
бизнес-процессов сохраняется контекст процесса, включая контекст глобальной транзакции.
199

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Компоненты, использующиеся для хранения указанных данных, должны масштабироваться
таким образом, чтобы обеспечивать репликацию контекстов между вычислительными узлами.
Компоненты прикладной логики должны корректно отрабатывать в составе бизнес-процессов, учитывая состояние шаблонов последних. Указанное состояние должно сохраняться в кэш
и реплицироваться между вычислительными узлами. Отметим, что кэширующие компоненты
могут поддерживать как полную репликацию, так и частичную с учетом сегментов, поэтому
алгоритмы эластичного масштабирования должны гарантировать, что при увеличении числа
тех или иных узлов репликация должна осуществляться таким образом, чтобы взаимодействующие с ними компоненты прикладной и процессной логики оперировали актуальными данными.
Компоненты, отвечающие за событийный обмен, должны масштабироваться таким образом, чтобы:
• Поддерживать корректность информационного обмена между компонентами логики,
принадлежащими как к рассматриваемому, так и к смежным архитектурным уровням. Данное масштабирование осуществляется аналогично масштабированию компонентов потокового
программного обеспечения, описанному выше.
• Обеспечивать корректное функционирование хореографии бизнес-процессов. То есть
при масштабировании должен вестись учет событий, сгенерированных и прочитанных компонентами. Недопустимо дублирование событий таким образом, чтобы элементы бизнес-процессов выполнялись несколько раз. Аналогичным образом недопустима утеря событий – особенно
внимательно надо продумывать алгоритмы эластичного масштабирования при уменьшении
числа узлов, дабы не потерять значимую информацию, содержащуюся в бизнес-данных событий.
Масштабирование слоя интеграционной логики должно осуществляться таким образом, чтобы масштабировались как компоненты, реализующие логику данного уровня, так
и компоненты, обеспечивающие сохранение состояния. Если говорить о компонентах логики,
то их масштабирование осуществляется аналогично тому, как проводилось масштабирование stateless компонентов на иных архитектурных уровнях. Компоненты хранения состояния
должны масштабироваться таким образом, чтобы обеспечить корректное выполнение интеграционных алгоритмов. Например, в случае точечных взаимодействий сообщение, для которого обеспечивается гарантированная доставка, не должно быть потеряно или доставлено
повторно вследствие изменения количества инфраструктурных узлов. Аналогично рассмотренным ранее вопросам масштабирование кэширующих компонентов и компонентов долговременного хранения (в случае рассматриваемого примера – распределенных баз данных
на основе NoSQL СУБД) должно осуществляться таким образом, чтобы согласованное выполнение элементов программного комплекса не было нарушено.
В случае уровня архивного хранения вопросы эластичного масштабирования не столь
актуальны – хранение потому и именуется архивным, что данные, которые подлежат архивированию, не требуют частых запросов к ним. В случае же если масштабирование оказывается
востребованным, необходимо перепроверить актуальность алгоритмов перемещения данных
из оперативного в архивное хранение – возможно, на уровень архивного хранения попадают
данные, которые являются актуальными с точки зрения продуктовой логики.
Резюмируя вышеизложенное и с учетом приведенного примера продуктовой архитектуры, можно отметить следующее:
• Эластичное масштабирование осуществляется автоматически с использованием заранее сформированных алгоритмов, учитывающих особенности продуктового ИТ-решения.
200

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Указанные автоматизированные алгоритмы входят в состав цифрового продукта и развиваются в ходе его жизненного цикла.
• Для поддержки эластичного масштабирования необходимо использовать максимально
подходящий для него технологический стек.
• Само по себе использование масштабируемых технологий не гарантирует поддержку
эластичного масштабирования продуктовым ИТ-решением. Необходимо разрабатывать алгоритмы масштабирования в соответствии с требованиями продукта.
• Эластичное масштабирование обеспечивает не только увеличение количества вычислительных узлов для выполнения той или иной задачи, но и его сокращение. Выбор технологий
для реализации цифрового продукта должен учитывать поддержку эластичного масштабирования при обоих озвученных алгоритмах.
• Прикладной программный код, который разрабатывается в ходе создания и развития
цифровых продуктов, должен учитывать необходимость поддержки эластичного масштабирования.
• Различные компоненты, входящие в состав архитектуры цифрового продукта, должны
масштабироваться независимо друг от друга, но алгоритмы эластичного масштабирования,
входящие в состав продуктового ИТ-решения, должны гарантировать корректность функционирования последнего при осуществлении масштабирования.
При этом, как мы уже неоднократно отмечали, при создании продуктовых ИТ-решений
используется платформенный подход. То есть значительную часть задач инфраструктурного
характера продукты делегируют на уровень применяемой в компании цифровой платформы, ее
сервисов и компонентов. Это означает, что все платформенные сервисы должны поддерживать
концепцию эластичного масштабирования. То есть платформенные сервисы должны использовать в качестве реализаций программное обеспечение либо поддерживающее эластичное масштабирование само по себе, либо быть реализованными таким образом, чтобы в зависимости
от продуктовых требований эластичное масштабирование было гарантировано. Но это далеко
не все требования, которые предъявляются к платформе в части обеспечения производительности и надежности. Платформенные сервисы должны предоставлять базовые алгоритмы эластичного масштабирования для потребителей – платформенных приложений, которые и представляют собой продуктовые ИТ-решения. Указанные алгоритмы входят в состав платформы.
Эластичное масштабирование платформы должно учитывать требования продуктов, то есть
продукты являются источником развития платформы не только в части набора сервисов и их
технологических реализаций, связи сервисов между собой, требований к обеспечению отказоустойчивости, что мы отмечали ранее по ходу настоящей книги, но и в аспектах эластичного
масштабирования. Если платформа не обеспечивает поддержку последнего, то она становится
не инструментом эффективного создания цифровых продуктов, а исключительно тормозом,
даже, не побоимся этого слова, препятствием.
Рассмотрев эластичное масштабирование в качестве одного из связанных трендов развития архитектуры, перейдем к следующему тренду, уже отмечавшемуся в нашей предыдущей
книге («Архитектура цифровых платформ. От настоящего к будущему»), – облачным технологиям. Как и ранее, уделяя внимание архитектурной тенденции, мы фокусируемся на продуктовом контексте ее применения.
Когда мы говорим об облачных технологиях, то в качестве ценности их применения
мы обычно подразумеваем возможность получения практически любого вычислительного или
программного ресурса удаленно и по требованию. В качестве такого ресурса могут выступать
серверы, сетевая инфраструктура, конкретные программные комплексы. Результатами внедрения облачного управления инфраструктурой становятся:
201

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Экономия финансовых ресурсов вследствие гибкого управления ресурсами вычислительными.
• Обеспечение возможностей масштабирования потребляемых ресурсов в соответствии
с потребностями того или иного заказчика. Отметим, что в качестве заказчика может выступать
непосредственно продуктовое ИТ-решение.
• Эффективный биллинг, предполагающий учет потребления ресурсов и их автоматическую тарификацию, в разрезе каждого потребителя. Например, в условиях, когда потребителями ресурсов являются цифровые продукты, то затраты на инфраструктурное обеспечение
каждого продукта могут включаться в его P&L для полноценного продуктового учета в организации. В случае эластичного масштабирования, описанного выше, добавление или сокращение вычислительных узлов приводит к перерасчету стоимости инфраструктуры для продукта и автоматически учитывается. На основании подобного учета становится возможным
оперативно вносить коррективы в алгоритмы эластичного масштабирования с целью улучшения P&L.
Мы видим, что концепция гранулированного ИТ-ландшафта компании, представляющего собой набор слабо связанных (а в идеале вообще не связанных) продуктовых решений,
имеет прямое соответствие с концепцией облака. При этом необходимо учитывать, что конфигурация развертывания облака может быть различной:
• Публичное облако (public cloud) предполагает развертывание ресурсов на мощностях
поставщика облака, находящихся вне контура организации. То есть мощности фактически
сдаются в аренду компании-потребителю. Данный подход, как правило, позволяет обеспечить
существенную экономию потребителю, но вызывает обоснованные нарекания с точки зрения
информационной безопасности.
• Приватное облако (private cloud) представляет собой механизм развертывания облака
непосредственно на мощностях компании-заказчика в ее контуре. Данный подход считается
наиболее безопасным в части угроз, но, как правило, является заметно более дорогим, нежели
применение публичного облака.
• Гибридное облако (hybrid cloud), являющее сочетанием двух первых подходов. Облако
сегментируется на приватный и публичный сегменты, при этом чувствительные данные и конфигурации размещаются на мощностях компании-заказчика, элементы ландшафта, для которых это возможно, выносятся в публичный сегмент.
Выбор варианта внедрения облачных технологий из представленных выше определяется
спецификой деятельности организации, регуляторными требованиями, в том числе законодательством конкретной страны, требованиями информационной безопасности, финансовыми
соображениями и т. д. В настоящей книге бессмысленно рассматривать конкретный пример,
поскольку, во-первых, в случае каждой организации сочетание указанных факторов может
быть совершенно индивидуальным, во-вторых, это не несет определяющего практического
различия в контексте цифрового продукта. В общем случае эффективное сочетание показывает вариант гибридного облака, в котором в публичный сегмент могут быть вынесены обезличенные среды разработки и тестирования. Данный подход позволяет как обеспечить безопасность реальных данных, циркулирующих в среде постоянной эксплуатации, так и снизить
совокупные затраты на ИТ-ландшафт. Во-первых, экономия достигается за счет использования публичного сегмента и снижения цены соответствующих вычислительных ресурсов. Вовторых, в случае привлечения внешних команд разработки существенно упрощается предоставление им доступа к стендам, причем стендам заказчика, расположенным в публичном сегменте. От исполнителя не требуется в этой ситуации создавать собственные стенды разработки
202

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

и тестирования и, соответственно закладывать их стоимость в общую цену своих услуг. Заказчику же не требуется обеспечивать доступ специалистов исполнителя в закрытый сегмент, что
зачастую сопряжено со значительными финансовыми вложениями. Указанная экономия положительно влияет на P&L создаваемых и развиваемых цифровых продуктов.
Мы уже отмечали в книге «Архитектура цифровых платформ. От настоящего к будущему», что концепции цифровой платформы и облака пересекаются, подчеркивали, что наиболее приближенной к современной платформе облачной концепцией является XaaS, поскольку
каждый компонент и сервис платформы может быть представлен в виде сервиса. Развивая
указанный подход в продуктовом ключе, мы приходим к тому, что каждый цифровой продукт является облачным сервисом. То есть создаваемые платформенные приложения, отвечающие за цифровизацию продуктов организации, должны быть cloud-native. Каждое приложение
должно автоматически исполняться в облачной среде, что диктует определенные требования
как к платформе, так и к самому приложению. И организация, желающая сохранять конкурентоспособность, обязана следовать данному тренду.
Говоря об облачном исполнении, о cloud-native приложениях, мы обязаны сказать
несколько слов об операторах. Последние могут использоваться и для высокоэффективного развертывания технологий в среде управления контейнерами. В состав архитектуры как
платформы, так и платформенных приложений должны включаться операторы. Разумеется,
поскольку операторы несут во многом инфраструктурный характер, то предпочтительным
является их использование на уровне платформы. Продукты (то есть платформенные приложения) в свою очередь, диктуя требования к платформе, определяют и набор операторов.
Безусловно, продукты не являются единственным источником требований к операторам, как
не являются единственным источником требований к платформе, но их требования являются
важной составляющей при планировании использования операторов, проектировании архитектуры и ее последующей реализации.
На основании вышеизложенного становится очевидным, что современная архитектура
предполагает, что цифровые продукты являются распределенными, эластично масштабируемыми и развертываются в облачной среде. Фактически, как мы уже отмечали выше, каждый
продукт является облачным сервисом. Но последнее утверждение не может считаться окончательным. Безусловно, end-to-end продукт предоставляет ценность клиентам и партнерам организации, саму концепцию end-to-end мы вводим именно для того, чтобы показать необходимость рассматривать продукт целиком. Но у каждой медали есть обратная сторона. Если
довести идею end-to-end до абсурда, то можно предположить, что подобный продукт представляет собой монолитное ИТ-решение. Как видно из всего предшествующего изложения, это
совсем не так. Технологически продукт является распределенным, а концептуально с точки
зрения ценности – единым. Мы можем провести определенную аналогию с платформой. Концептуально платформа едина для компании, она в целом предоставляет опосредованную ценность клиентам и партнерам вследствие того, что существенно удешевляет создание продуктов. Но технологически платформа является распределенной, каждый ее сервис и компонент
являются распределенными. Ситуация с продуктами аналогична. При общей ценности для
клиентов, предоставляемой продуктом в целом, различные варианты использования предполагают вовлечение различных компонентов продукта. Каждый из указанных компонентов является распределенным. Компоненты логики могут использоваться в сотнях и тысячах различных сценариев, при этом набор сценариев для каждого компонента уникален. Мы приходим
к логичному выводу, что в условиях современных архитектур каждый продуктовый компонент, каждая продуктовая функция сами становятся сервисом. То есть современный продукт
должен реализовываться в парадигме Function as a Service (FaaS), поддерживать концепцию
бессерверной архитектуры (serverless).
203

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Указанная концепция является логическим следствием развития и активного использования принципов эластичного масштабирования и облачных технологий. На всякий случай
уточним, что бессерверность означает не отсутствие серверов в принципе, а отсутствие необходимости прямого управления ими. Поставщик облачного решения динамически распределяет ресурсы для обработки событий, требующей выполнения функций приложений. То есть
каждый end-to-end продукт в парадигме serverless представляет собой набор функций, выполняющихся по требованию. В рамках облачного решения осуществляется динамическое распределение ресурсов на поддержку исполнения каждой функции с применением эластичного
масштабирования. При этом функция может как выполняться в рамках одного архитектурного уровня, если оперировать приведенными по ходу книги примерами, так и быть сквозной – все зависит от функционального дизайна цифрового продукта. Указанный подход позволяет обеспечить дополнительную экономию ресурсов – биллинг осуществляется на уровне
не продукта, а функции. Стоимость же продуктовой инфраструктуры, закладываемая в P&L
цифрового продукта, является суперпозицией стоимости отдельных функций. С учетом того,
что масштабирование и исполнение функций ведется адресно, обеспечивается дополнительная экономия и улучшение P&L.
Проблема serverless архитектуры остается той же самой, которую мы отмечали в книге
«Архитектура цифровых платформ. От настоящего к будущему». Сама концепция бессерверной архитектуры предполагает возможность сокращения ресурсов, потребляемых функцией,
до нуля. Можно сказать, что это является предельным случаем экономии. Но мы уже неоднократно подчеркивали, что оказываемая на продуктовые ИТ-решения нагрузка в современном
мире является непредсказуемой, а потому вполне вероятным становится вариант, что одномоментно может поступить серия запросов к функции, ресурсы исполнения которой обнулены. В этом случае развертывание и предоставление ресурсов может занять дополнительное
время, ухудшая клиентский опыт и, соответственно, P&L продукта. То есть переход к serverless
архитектуре предъявляет повышенные требования к поставщику облачного решения – он должен обеспечивать решение проблемы подобного «холодного» запуска, предоставляя ресурсы
исполняемым компонентам. Ведущие мировые поставщики облачных технологий с определенными ограничениями решают указанную проблему, но в целом она представляет собой серьезную зону роста.
Невзирая на проблему «холодного» запуска, мы должны отметить, что необходимость
масштабирования и экономии средств неумолимо требуют от современных продуктовых архитектур поддерживать движение в сторону serverless архитектур, поэтому последние безусловно
являются одной из очень важных тенденций развития архитектуры в целом. В связи с этим
архитектору необходимо обеспечивать такую грануляцию платформенных приложений, чтобы
последние могли предоставлять исполнение каждой функции в формате сервиса. А поскольку
мы рассматриваем создание цифровых продуктов с применением платформенного подхода, то
и платформа должна поддерживать serverless архитектуру.
Автору этих строк в ходе одного из профессиональных обсуждений был задан прямой
вопрос, граничивший с замечанием: «Неужели возможно создать полноценную современную
систему, например, автоматизирующую главную бухгалтерскую книгу, используя архитектурный подход serverless?» Вопрос закономерный, но в прямой трактовке бессмысленный. Почему
мы применяем столь резкую характеристику? Безусловно, если взять за основу архитектуру
классических АБС (мы уже вводили границы данного термина), основанную на выполнении
тяжеловесных операций в формате хранимых процедур реляционных баз данных, то перенести данное решение на serverless архитектуру практически невозможно. Мы говорим «практически», потому что оставляем лазейку для чудесного сценария. Реальная ситуация же требует совершенно иного подхода к проектированию. Мы уже отмечали, что современный ИТландшафт, прошедший продуктовую трансформацию, представляет собой набор продуктовых
204

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ИТ-решений. Каждое из них содержит типовой набор архитектурных уровней и компонентов,
наполнение которых может варьироваться в зависимости от требований, предъявляемых к конкретному продукту. И проектирование главной бухгалтерской книги также необходимо вести
в соответствии с продуктовым подходом. И тогда (в новой архитектуре) найдется место и для
serverless. Мы же не призываем абсолютизировать любой подход, в том числе и serverless. Каждый инструмент хорош для своих целей. Молоток подходит для забивания гвоздей и болезненных ударов по пальцам, микроскоп – для получения увеличенных изображений предметов,
невидимых невооруженным глазом. Так и serverless архитектуры должны применяться в архитектурных подходах и реализациях с учетом их особенностей. Без полноценной продуктовой трансформации ИТ-ландшафта использование бессерверных реализаций лишь усложнит
общую архитектуру. Но в условиях грамотного применения позволит существенно повысить
производительность создаваемых и развиваемых продуктовых ИТ-решений, а также снизить
затраты на инфраструктуру.
По ходу настоящей книги мы неоднократно подчеркивали тот факт, что ценность для
клиента представляет именно продукт в целом, а не какой-то его выделенный компонент. Особенно мы выделяли данный факт в контексте визуального представления продукта: пользователю предоставляет ценность конкретный продукт, а не, например, форма заявки на его
получение. Тем не менее именно качественное фронтальное представление продукта вносит
значимый вклад в позитивный клиентский опыт, а потому является важной составляющей
P&L. Проработка визуальных форм, относящихся к продукту, становится источником притяжения значительных трудовых, временных и финансовых ресурсов организации, желающей
сохранить конкурентоспособность. И здесь необходимо отметь исключительно важный аспект,
на котором следует концентрировать внимание при проектировании и реализации цифрового
продукта – на омниканальности. Безусловно, мы ни в коем случае не отрицаем важность грамотного графического дизайна, но темой нашей книги являются концепция и архитектура
цифрового продукта, а потому мы и рассматриваем здесь омниканальность, относя ее к числу
важных тенденций развития архитектуры.
Необходимо сразу отметить, что мы говорим не о мультиканальности, а об омниканальности. Если мультиканальность предполагает наличие множества каналов представления продукта, то под омниканальностью понимается объединение всех каналов обслуживания, доступных для продукта, в общую систему. В рамках указанной системы взаимодействие с клиентом
осуществляется бесшовно, обслуживание его не прерывается при смене канала, состояние клиентской сессии и цифрового продукта сохраняется между каналами обслуживания. Традиционным примером омниканальности, который и мы упоминали в предыдущих книгах, является
заполнение заявки на кредитный продукт, осуществляемое клиентом попеременно: в интернет-банке и мобильном приложении. При этом состояние процесса при обеспечении омниканальности не теряется при смене канала коммуникации. Отметим, что просто при мультиканальности состояние процесса будет потеряно при смене канала и попеременное заполнение
заявки на продукт с использованием нескольких каналов окажется невозможным.
Мы должны напомнить читателю, уже ознакомившемуся с нашими предшествующими
книгами («Архитектура цифрового мира» и «Архитектура цифровых платформ. От настоящего к будущему»), что ключевой задачей омниканальности является отнюдь не унификация пользовательских интерфейсов. Безусловно, указанная унификация улучшает клиентский
опыт, она является крайне важной составляющей при создании цифрового продукта. Но омниканальность можно назвать проекцией непрерывности деятельности компании на фронтальное
и канальное представление цифровых продуктов данной компании. Мы говорим о непрерывности деятельности не в финансовом или бухгалтерском, а в технологическом смысле. Деятельность современной компании осуществляется в режиме 24х7, в противном случае она утратит
конкурентоспособность. В аналогичном режиме доступны и продукты компании. В современ205

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

206

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 60. Архитектура цифрового продукта в рамках
обеспечения омниканальности
На Рисунке 60 схематично показана концептуальная архитектура слоя фронтального
и канального представления цифрового продукта. Высокоуровнево отображены компоненты
канало-специфичной продуктовой логики, продуктовой логики, интеграционной логики,
управления бизнес-процессами, оперативного хранения продуктовых данных и хранения инте207

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

грационных данных. Отметим, что поскольку мы рассматриваем архитектурное обеспечение
омниканальности, то в настоящем примере не акцентируем внимание на продуктовой конкретике. В качестве продукта может выступать кредит, депозит или любой другой продукт, если
речь идет о финансовой организации.
Архитектурный уровень фронтальной и канальной логики сформирован из нескольких
составляющих:
• Интерфейсы внутренних пользователей и клиентов. Мы сознательно разделяем две
указанные категории, чтобы показать тот факт, что омниканальность принципиально не ограничивается только клиентами организации. Отметим, однако, что компания может принять
решение о поддержке омниканальности только для выделенных категорий пользователей.
Но с технической точки зрения омниканальность потенциально доступна для каждой роли,
ассоциированной с цифровым продуктом, исключение ролей из омниканальности является
организационным решением. Интерфейсы сотрудников и клиентов реализуются для дистанционных каналов обслуживания посредством Web-интерфейсов и мобильных кабинетов. Непрерывность деятельности для указанных типов каналов и будет показана в настоящем примере.
Добавим, что с целью поддержки распределенности интерфейсы реализуются с применением
шаблона микрофронтендов. Особенности применения микрофронтендов в мобильных приложениях не являются критичными для нашего примера.
• Микросервисы, реализующие шаблон BFF. В задачу данных компонентов входит экранирование пользовательских представлений от фронтальной логики, унификация контрактов
клиентов, поддержка независимого масштабирования различных компонентов, составляющих
слой фронтальной и канальной логики.
• Микросервисы предоставления API. Как и для любого современного цифрового продукта, для нашего примера предусмотрена возможность организации экосистемы партнерских
приложений. Например, если мы рассматриваем кредитный продукт, то партнерские приложения могут обеспечивать лидогенерацию. Архитектура сервисов открытых API реализована
в микросервисной парадигме, как и остальная прикладная и обеспечивающая логика в примерах, приводимых в настоящей книге.
• Микросервисы фронтальной логики, в задачу которых входит формирование данных
для клиентских представлений, прием событий клиентских интерфейсов и реакция на них,
корректная обработка данных, передаваемых на смежные архитектурные уровни и принимаемых с них, и т. д. Указанные компоненты не являются канальным представлением и предназначены для унифицированной обработки логики. Более того, используя работу каналоспецифичных компонентов, они могут унифицированным образом генерировать каркас пользовательского представления. Взаимодействуя с микросервисами BFF, они могут адресно реагировать на события каждого микрофронтенда, задействованного в реализации цифрового
продукта.
• Канало-специфичная продуктовая логика учитывает необходимость выполнения тех
или иных действий, актуальных лишь для конкретных каналов обслуживания. Поскольку бизнес-процессы, автоматизируемые в составе продуктового ИТ-решения, описывают процессы
жизненного цикла продукта, то канало-специфичная логика отделена от них, гарантируя унифицированное исполнение процессов для различных каналов. Требуемая специфика реализуется в настоящих компонентах и может быть изменена независимо от процессов жизненного
цикла и связанной с ними продуктовой логики.
• Кэш фронтального слоя. Требования к производительности фронтальной логики традиционно самые высокие. Для обеспечения выполнения подобных требований применяется
механизм кэширования используемых данных. Также кэш может использоваться для эффективного выполнения тех или иных действий в оперативной памяти. Сочетание столь разных
208

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

возможностей достигается благодаря тому, что современное программное обеспечение поддерживает одновременно концепции IMDG (In-memory Data Grid) и IMDB (In-Memory Data
Base). Данные, к которым требуется оперативный доступ, помещаются в кэш. Наполнение
кэш осуществляется асинхронно в режиме так называемого «прогрева». Измененные данные
также помещаются в кэш, дабы асинхронно передаваться на смежные архитектурные уровни.
Данными из кэш оперируют микросервисы фронтальной логики, микросервисы BFF, микросервисы предоставления API. Для резервирования кэш используются как собственные механизмы, так и реляционная база данных, также представленная на Рисунке 60.
• Журналы событийного обмена и накопления данных. Взаимодействие компонентов как
между собой, так и с компонентами смежных архитектурных уровней может осуществляться
напрямую или посредством событийного обмена. Для обеспечения последнего и используются
приведенные на Рисунке 60 журналы. Журналы реализуются с применением потокового программного обеспечения. С использованием журналов осуществляется событийное взаимодействие компонентов, прогрев кэш, наполнение данными сервисов открытых API.
Каким же образом обеспечивается омниканальность в приведенном выше примере? Ее
основой является архитектурная грануляция компонентов: компоненты собственно фронтальной логики отделены от канальной реализации и могут использоваться самыми различными
каналами обслуживания. При добавлении новых каналов обслуживания фронтальная логика
может вызываться ими. Микросервисы BFF позволяют экранировать контракт клиента от компонента фронтальной логики. Аналогичным образом отделены от канальных компонентов
данные фронтального слоя, находящиеся в кэш или в реляционной базе данных. Предположим, что клиент оформляет заявку на продукт, используя мобильное приложение. При этом
по каким-то причинам мобильное устройство становится недоступным (и, возможно, даже
не подает признаков жизни). Но клиенту необходим продукт, и он переключается на использование традиционного Web-интерфейса. Что же происходит в этом случае?
Когда клиент работал с продуктом, то актуальные данные были загружены в кэш и стали
доступны для обработки компонентами фронтальной логики с последующим предоставлением в канал обслуживания (исходно – мобильный). Операции, проведенные клиентом, и их
результаты, а также введенные клиентом данные обрабатывались компонентами фронтальной
логики, сохранялись в кэш и при необходимости направлялись компонентам смежных архитектурных слоев посредством журналов событийного обмена. При смене канала обслуживания
посредством микросервисов BFF и компонентов фронтальной логики (в соответствии с традиционными практиками микросервисной архитектуры являющимися stateless) из кэш извлекается клиентская сессия и ассоциированные с ней бизнес-данные. Ввиду указанного выше отделения хранения данных от канала обслуживания нарушение взаимодействия по мобильному
каналу не повлияло на уже сохраненное состояние процесса. При этом компоненты фронтальной логики, не сохраняя состояние, продолжают обрабатывать приходящие запросы вне зависимости от того, какой канал обслуживания используется клиентом.
Смежные архитектурные уровни продукта экранированы от уровня фронтальной
и канальной логики журналами событийного обмена и выполняют заложенные в них действия
вне зависимости от того, посредством какого канала эти действия инициируются. Бизнес-процессы и прикладная продуктовая логика отделены от логики представления и осуществляют
свое исполнение унифицированно для всех каналов обслуживания. Если же потребуется
добавление нового канала, то (в зависимости от его специфики) будут добавлены новые микросервисы BFF и компоненты канало-специфичной логики. То есть изменения будут ограничены уровнями фронтального и канального представления и канало-специфичной продуктовой логики, не затрагивая остальные архитектурные уровни.
209

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Как мы наглядно показали выше, разграничение архитектурных уровней цифрового продукта и составляющих их компонентов обеспечивает поддержку омниканальности. Мы призываем читателя следовать принципам унификации назначения компонентов между каналами,
дабы обеспечивать рассматриваемую тенденцию развития архитектуры. Вместе с тем необходимо уделить внимание двум ментальным ошибкам, зачастую связанным с понятием омниканальности.
Первая из них заключается в достаточно часто встречающемся на рынке убеждении, что
для обеспечения омниканальности необходимо на уровне как минимум фронтальной логики
(а зачастую данное заблуждение продлевают и на уровень продуктовой логики) создавать полноценное канальное представление, включая структуру объектов представления, графических
элементов интерфейса и т. д. Затем создаваемые подобным образом объекты транслируются
в каналы для полноценного отображения на уровне пользовательских интерфейсов. Встречаются даже решения, содержащие кодогенераторы фреймворков фронтальной разработки
на иных уровнях абстракции. Генерируемые компоненты должны использоваться каналами,
играющими лишь роль оболочки. Мы не будем отказывать представленному подходу в потенциальном праве на жизнь, но обязаны отметить, что пересекается с омниканальностью он лишь
по принципу кругов Эйлера:
• Безусловно, унифицированные генераторы компонентов (большей или меньшей степени детализации и погружения в специфику фреймворков разработки пользовательских
представлений) снижают трудозатраты на разработку непосредственно канальной логики.
И в этой части создание унифицированных пользовательских представлений оказывается
проще, нежели при их разработке с нуля. С другой стороны, омниканальность означает непрерывность процессов фронтального обслуживания, которая в общем случае вовсе не гарантируется подобной генерацией компонентов.
• Представленная выше генерация фронтальных компонентов должна учитывать специфику каналов и фреймворков реализации канальной логики. При добавлении новых каналов
либо при изменении специфики фреймворков (в том числе это возможно при выходе новых
версий, что является непредсказуемым процессом) необходима доработка либо фронтальной,
либо иной логики, в задачи которой вменена соответствующая генерация. Указанный подход
приводит к сильной связности компонентов и ухудшает распределенность решения.
• Универсальные генераторы зачастую создают шаблонные интерфейсы, не учитывающие
лучшие современные практики клиентского опыта и дизайн-мышления.
• Дополнительная генерация логики на стороне серверных компонентов увеличивает
(подчас значительно) нагрузку на последние.
Резюмируя вышеизложенное, отметим, что для поддержки омниканальности указанная
генерация канального представления не является необходимой. При этом она может упростить
создание унифицированных интерфейсов при условии, что команде удастся избежать недостатков, указанных выше. Например, она может экранировать генераторы канальной логики
от унифицированных компонентов логики фронтальной. Возможно отдельное обеспечение
распределенности и масштабируемости работы генераторов. Возможно введение дополнительных трансляторов для исключения привязки генераторов к фреймворкам фронтальной разработки. При этом совершенно не исключена омниканальность при адресной разработке каждого
канального представления цифрового продукта. Сводить же омниканальность к генерации
унифицированных интерфейсов попросту некорректно.
Вторая ментальная ошибка тесно связана с первой. Мы уже неоднократно отмечали, что
платформенный подход активно применяется лидерами рынка. Используем и мы платформенный подход при описании примеров. Нередко можно столкнуться с утверждением, что созда210

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ется некая омниканальная платформа. Мы уже рассматривали в предыдущей книге («Архитектура цифровых платформ. От настоящего к будущему») опасность применения подхода,
названного нами «множеством платформ». При подобном подходе на смену информационным
системам предыдущих архитектурных и технологических поколений приходят разрозненные
платформы, что только ухудшает конкурентоспособность организаций в современном цифровом мире. Мы уже неоднократно подчеркивали необходимость создания в организациях комплексных сквозных цифровых платформ. В этом случае нет смысла в выделении какой-то специфической «омниканальной платформы». Тем не менее омниканальность является важной
тенденцией развития архитектуры, в связи с чем при создании платформ их именуют омниканальными либо требуют обеспечивать соответствующую непрерывность фронтального обслуживания. Разберемся, как это сделать и какая же ментальная ошибка подстерегает в этом случае и архитектора, и продуктовую команду.
Ментальная ошибка может заключаться в том, что к платформе могут быть предъявлены
требования по генерации омниканальных представлений. Здесь ситуация во многом аналогична созданию генераторов канальной логики и представления на уровне фронтальной или
продуктовой логики. Все те недостатки реализации, которые мы отмечали выше, будут перенесены на уровень платформы. Результатом станет рост стоимости создания, развития и сопровождения платформенного решения. При этом скорость внесения доработок в платформу
снизится, последняя станет тормозом продуктового развития и начнет оказывать негативное
влияние на P&L цифровых продуктов организации. Отметим, что омниканальность в этом
случае может и не быть достигнута – генерация канального представления сама по себе может
не подразумевать непрерывности фронтальных процессов.
Тем не менее платформа и платформенные сервисы принимают самое активное участие в обеспечении омниканальности. Если вернуться к Рисунку 60, то мы увидим наличие
на нем большого количества инфраструктурных компонентов. Логично предположить, что
и компоненты логики, представленные на иллюстрации, выполняют немало общих унифицированных задач. И вот выполнение таких задач, а также корректное использование инфраструктурных компонентов могут быть отнесены на уровень платформенного решения. То есть
эффективная организация сервисов, хранение и обработка данных, позволяющие отделить
процесс фронтального обслуживания от собственно канальной логики, обеспечивая омниканальность, осуществляются с непосредственным вовлечением платформенных механизмов.
Варианты использования, предоставляемые платформенными сервисами, обязаны учитывать
необходимость разработки омниканальной логики с использованием платформенного решения. Можно с уверенностью сказать, что современная цифровая платформа напрямую задействована в обеспечении омниканальности. Но это вовсе не означает, что она сама является
омниканальной. Мы призываем читателя учитывать указанную смысловую разницу.
Одновременно с этим было бы неверным утверждать, что платформа обеспечивает
только инфраструктурную поддержку омниканальности путем работы с инфраструктурными
компонентами. Подобное утверждение стало бы значительным сужением области применения
платформенного подхода. При создании визуальных интерфейсов используются библиотеки
стандартизированных компонентов. И поддержка указанных компонентов также может быть
вынесена на уровень платформы, в ответственность которой будет входить в том числе обновление компонентов, содержащихся в библиотеке, при выходе обновлений фреймворков фронтальной разработки. Библиотека должна быть в актуальном состоянии и быть наполнена в том
числе шаблонами микрофронтендов для последующей разработки канальной логики.
Мы уже регулярно упоминали микрофронтенды в качестве шаблона и соответствующей
технологической реализации, применяемой при создании фронтальных интерфейсов. Ввиду
их значимости и перспектив применения мы также обозначаем их одной из важных тенденций
развития архитектуры, которой необходимо уделить внимание в настоящем разделе.
211

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Мы достаточно много рассуждали о распределенности, уделили ей специальный раздел
в настоящей главе, рассматривали вопросы грануляции микросервисных компонентов с точки
зрения распределенного создания и исполнения. Необходимо сказать несколько слов и о фронтальном и канальном представлении цифрового продукта в данном ключе. К сожалению,
нередкими на сегодняшний день являются случаи, когда компании, вложив значительные силы
и средства в разработку платформенных решений, в создание высокоэффективной распределенной продуктовой логики, сохраняют монолитные фронтальные представления. В результате
распределенные команды разработки продуктовой логики, бизнес-процессов, логики хранения оказываются заложниками, например, единой команды создания пользовательских интерфейсов, которая формирует бэклог на основании запросов перечисленных команд. Организационная и технологическая распределенность в таком случае оказываются как бы не у дел –
в рабочем процессе обнаруживается узкое место, в архитектуре же – монолитный компонент.
Микрофронтенды позволяют создавать фронтальные составляющие независимо и формировать на их основе общее представление как одного продукта, так и набора цифровых
продуктов организации. Сборка фронтальных составляющих осуществляется в рамках общего
каркаса – так называемой оболочки (Shell). Загрузка отдельных составляющих осуществляется независимо друг от друга, что позволяет существенно увеличить производительность
фронтальных интерфейсов и улучшить их восприятие клиентами. Клиент может начать взаимодействие с интересующим его продуктовым решением вне зависимости от загрузки фронтальных представлений остальных цифровых продуктов. Подобный подход исключительно
важен при организации общих страниц интерфейса, предполагающих обширное и разнородное наполнение. На уровне одного продукта подобная распределенность и независимость микрофронтендов также очень важна, поскольку обеспечивает возможность параллельной разработки продукта несколькими командами. В этой ситуации нет никакой необходимости ожидать
выполнения своей задачи выделенной командой фронтальной разработки или пытаться повысить ей приоритет в бэклоге указанной команды – в состав каждой команды, работающей над
продуктом, входят специалисты, которые могут реализовать соответствующий микрофронтенд
и передать его на исполнение. Таким образом, команда, работающая над end-to-end продуктом, сама является «end-to-end командой», которая может независимо от смежников создавать
полноценные продуктовые компоненты и, используя механизмы CI/CD конвейера, передавать
их в эксплуатацию – в идеале даже в постоянную.
Экранирование микрофронтендов от компонентов фронтальной логики обеспечивается
микросервисами BFF, позволяющими унифицировать клиентский контракт и гарантировать
независимость масштабирования компонентов. Место микросервисов BFF в архитектуре мы
уже неоднократно демонстрировали по ходу настоящей книги. Отметим, что применение платформенного подхода позволяет унифицировать создание микросервисов BFF, а также компоненты пользовательского интерфейса, используемые различными микрофронтендами.
Ввиду высокой значимости поддержки распределенности на всех архитектурных уровнях
мы определяем микрофронтенды важной тенденцией развития архитектуры, которую обязана
учитывать каждая организация, стремящаяся сохранять собственную конкурентоспособность.
По ходу настоящего раздела мы рассмотрели ряд тенденций развития архитектуры, которые объективно не могут быть отнесены к разряду ключевых, но тем не менее играют важную роль в обеспечении процесса создания ценности. Тем самым они напрямую влияют
на P&L продукта, что мы и продемонстрировали на примерах. Возможно, внимательный читатель захочет добавить и иные тенденции. Мы не против, мы лишь приветствуем расширение
перечня архитектурных тенденций, находящихся в фокусе внимания.
Подводя итоги настоящей главы, необходимо отметить, что мы рассмотрели ключевые
и связанные тенденции развития архитектуры в контексте создания и развития цифровых продуктов. Мы подчеркнули важность каждой из указанных тенденций, а также продемонстри212

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

213

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровые продукты и процессы
«Снова какие-то процессы! Как будто мы мало рассуждали о всяких бизнес-процессах!» – воскликнет нетерпеливый читатель. Но мы поспешим его успокоить, отметив, что речь
идет не об автоматизации бизнес-процессов, которой мы в соответствии с его справедливым
замечанием уделили полноценный раздел в настоящей книге, а о процессах организационных. Именно такие процессы оказывают заметное, зачастую критическое, влияние на создание и развитие цифровых продуктов. Читатель может сразу задать вопрос, почему мы говорим
о процессах, а не, например, о мышлении. И тут он попадает в самую суть, ведь именно продуктовое мышление должно быть выстроено в современной организации. Но в том-то и дело,
что организации существуют не на пустом месте, а уже имеют некоторую, подчас длительную,
историю. В свою очередь цифровые продукты не возникают из ничего, при их создании приходится иметь дело с унаследованным ИТ-ландшафтом. Организационные процессы в компании
зачастую отражают инерцию мышления. И в рамках продуктовой трансформации необходимо
выявить проблемы, имеющиеся в организационных процессах, на их основе понять ментальные проблемы, присутствующие в компании, а затем их эффективно устранить.
На Рисунке 1 мы приводили пример S-кривой, с помощью которой показали (на качественном уровне), что создание продуктов и понимание их важности прошло значительно
больший путь, нежели создание цифровых платформ. При этом и продукты, и платформы прошли существенно больший путь, нежели само продуктовое мышление в организациях. Мышление еще не прошло точку перелома в плане перехода к интенсивному развитию, в отличие
от платформ. «Продукты», в свою очередь, находятся на стадии интенсивного развития уже
достаточно долгое время. Но это интенсивное развитие привело к тому, что на рынке присутствует значительное количество «продуктов», которые лишь именуются таковыми, но на самом
деле могут считаться приносящими ценность клиентам и партнерам компаний лишь номинально. Данная ситуация гораздо опаснее, нежели может показаться на первый взгляд. Емкость
любого рынка отнюдь не беспредельна. И если полностью исчерпать ее, наполняя продуктами
невысокого качества, то создание действительно эффективных и представляющих ценность
для клиентов продуктов может оказаться не обеспечено необходимыми ресурсами. Напомним
читателю, что комплексный end-to-end продукт сложен, в его создание и развитие должны вкладываться значительные трудовые, временные и финансовые ресурсы. Но если подобные вложения не будут обладать потенциалом окупаемости, в том числе вследствие исчерпания рынка,
то и создание полноценных цифровых продуктов окажется невозможным. Безусловно, можно
сформировать механизм перераспределения ресурсов под создание продуктов, предоставляющих клиентам истинную ценность, но подобный внеэкономический механизм, как правило,
эффективен на крайне непродолжительных временных отрезках, в течение которых необходимо сформировать новые рынки, обеспечивающие окупаемость продуктов. Поэтому нельзя
терять времени – надо немедленно переходить к массовой реализации полноценных end-toend продуктов с опорой на ценность, актуальную для клиентов и партнеров современных компаний. А для этого нужно изменять мышление организаций и организационные процессы.
Нередко процессы создания цифровых продуктов являются в компаниях несколько
обособленными от общей производственной деятельности. Бытует мнение, что создание или
развитие продукта представляет собой проект с ИТ-составляющей, в то время как основная
деятельность компании связана с финансами, промышленностью, топливно-энергетическим
комплексом и т. д. Это опасное заблуждение. Современный мир стал цифровым миром. И организация, ставящая себе целью сохранение и упрочение конкурентоспособности, не может
считать цифровизацию вспомогательным направлением деятельности. Безусловно, многие
компании сводят цифровизацию к внедрению решений видео-конференц-связи, корпоратив214

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ных мессенджеров, порталов внутреннего обучения, систем электронного документооборота
и т. д. Решение указанных задач, конечно, важно. Но если компании ограничиваются только
ими, то они априори неконкурентоспособны. Если они не формируют ценность для клиентов
и партнеров, не переводят ее в цифровое представление, то есть не создают цифровой продукт, то можно констатировать, что с точки зрения мышления они остались в лучшем случае в прошлом веке. Компания должна проводить продуктовую трансформацию, формировать
продукты на основе ценности для клиентов и/или партнеров, переводить продукты в цифровой
вид, рассчитывать P&L и на основании данного показателя планировать собственное развитие.
Подобный подход вовсе не требует забыть про основные фонды, они обязательно должны быть
оцифрованы и учитываться в оценке показателей цифровых продуктов. Только таким образом
становится возможным стереть грань между «основной» и «поддерживающей» деятельностью
компании, перевести организацию в цифровой вид и хотя бы попытаться сохранить ее конкурентоспособность. Упрочение положения на рынке без указанных базисных действий попросту невозможно.
То есть мы можем с уверенностью утверждать, что создание цифровых продуктов вовсе
не является некими проектами с ИТ-составляющей. На самом деле оно даже не является проектами. Далее мы рассмотрим, почему так происходит. Проектная деятельность является наглядным примером процессов, заимствованных из предыдущих поколений. И она должна быть
полностью пересмотрена в ходе продуктовой трансформации.
В открытых источниках существует множество определений проекта, которые не только
дополняют, но и нередко противоречат друг другу. Но если рассматривать общую суть проекта, то он определяет набор целей, которые необходимо достигнуть по итогам его выполнения,
сроки и бюджет. Фактически проект содержит три типа артефактов, которые считаются фиксированными на момент старта процесса проектной деятельности. Разумеется, в компании может
быть положение о проектной деятельности, оно может быть более или менее сложным, но значимость приведенных выше артефактов, как правило, не отрицается никаким положением
об управлении проектами. Результатом организации работ в соответствии с проектной методологией становится нередко слепое следование достижению целей, соблюдению сроков и бюджетов. Сразу отметим, что здесь уже присутствует некая концептуальная завершенность: проект заканчивается, при достижении целей проектная команда получает положенные бонусы,
в противном случае принимаются различные малоприятные для участников проекта решения.
При этом результат проекта носит фиксированный характер, и считается, что в дальнейшем он
просто используется организацией. Но насколько корректен подобный подход в современных
условиях?
Оговоримся сразу, что в ряде случаев регуляторные требования вынуждают следовать
подобной методологии. Мы в настоящей книге ни в коем случае не выступаем против нормативного регулирования – в ряде отраслей экономики подобное регулирование является
жизненно необходимым. Вместе с тем даже в рамках нормативного регулирования возможен
потенциал роста, если компания заинтересована в обеспечении собственной конкурентоспособности на постоянно меняющемся рынке.
Так в чем же заключаются проблемы подобного проектного подхода к созданию цифровых продуктов? Обратимся к сути продуктовой трансформации и продуктового рефакторинга,
описанным ранее в настоящей книге. По итогам продуктовой трансформации ИТ-ландшафт
компании представляет собой набор продуктовых ИТ-решений. Мы по ходу книги регулярно
рассматриваем возможный набор архитектурных слоев каждого продукта. При этом, как мы
уже отмечали меняется сам подход к термину «информационная система» – сейчас под ним
следует понимать скорее совокупность тех или иных архитектурных уровней продуктовых ИТрешений, объединенных технологической общностью. При этом бизнес-процессы организации
подлежат рефакторингу в соответствии с процессами жизненного цикла продуктов, создавае215

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

мых и развиваемых в компании. И здесь классическая проектная методология входит в противоречие с продуктовой.
Мы не ставим себе целью в настоящем изложении рассмотреть все вопросы, касающиеся
создания и структурирования проектных методологий, поэтому пройдем по ним тезисно. Проект, как правило, фиксирует четкие и измеримые КПЭ, которые предполагается достигнуть
по итогам его выполнения. Также фиксируются срок и бюджет проекта. В ходе реализации
проекта предполагается выполнение ряда стадий, набор и наполнение которых определяются
принятой в компании проектной методологией. Осуществляется контроль выполнения проекта по определенным заранее контрольным точкам, например, методом набегающей волны
(если читатель заинтересуется деталями подобного метода, то мы рекомендуем ему ознакомиться с литературой по проектному управлению). В зависимости от значимости проекта для
компании создаются различные коллегиальные органы, в задачи которых входит осуществление надзора за исполнением проекта. Осуществляется много иных управленческих действий.
Не без сарказма отметим, что нередко за таким количеством коллегиальных управленческих
органов теряется собственно выполнение работ по проекту.
Необходимо подчеркнуть, что жесткая фиксация сроков и бюджета проекта существенно
ограничивает возможности работы по гибким методологиям. Если в ходе спринтов выясняется необходимость корректировки целей, это может привести к сдвигу сроков или изменению бюджета. Разумеется, автор этих строк в курсе адаптаций гибких методологий к реалиям
большой организации. Но одновременно с этим нельзя упускать из виду тот факт, что зачастую при подобной «адаптации» и проект получается с размытыми целями, которые потом
можно подстроить под гибкие методологии, и бюджет со сроками закладываются завышенные.
Подстраивание целей под специфику гибких методологий нередко правильнее называть подгоном, потому что подобный подход становится удобной почвой для недобросовестной деятельности, когда достигнутый результат объявляется искомым по принципу «вот чего добились,
того и добивались». Завышение сроков и бюджетов приводит к тому, что инвестиции в развитие ввиду потенциальной масштабности сокращаются и перенаправляются на другие виды
деятельности компании. Таким образом, подобный подход нуждается в пересмотре. Важным
первым шагом, но не гарантирующим успешность проекта, является ввод в деятельность организации понятия предпроекта. Предпроект позволяет в сжатые сроки и с низкой стоимостью
уточнить цели, временные параметры и бюджет полноценного проекта. Добавим, что в случае
регуляторных ограничений ввод указанного понятия становится необходимым: если регуляторные требования жестко ограничивают проектную деятельность, то предпроект позволяет
внести в нее уточнения, дающие основу для детального временного и стоимостного планирования.
Но для полноценной продуктовой трансформации только предпроекта мало. Он является важным первым шагом, но всего лишь одним из этапов перехода к продуктовому развитию компании. Нельзя забывать о том, что сам факт проектной деятельности предполагает
фазу интенсивного развития в ходе реализации проекта и фазу так называемого пост-проекта, на которой предполагается уже развитие экстенсивное – результат проектной деятельности передается на сопровождение. При этом обычно доступ к среде постоянной эксплуатации
имеет команда сопровождения, в то время как команда развития осуществляет точечные доработки и передает их для внесения изменений в контуре постоянной эксплуатации ИТ-решения.
Ознакомившись с нашим предыдущим изложением (как и с книгами «Архитектура цифрового мира» и «Архитектура цифровых платформ. От настоящего к будущему»), читатель уже
может сделать закономерный вывод, что в современных реалиях указанный проектный подход не может обеспечивать конкурентоспособность компании. Конкурентоспособность базируется на фундаменте перманентного интенсивного развития. При этом продуктовые ИТ-решения указанное развитие приостановить или заменить на экстенсивное (что, в общем-то, одно
216

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

и то же) не могут, иначе P&L цифрового продукта немедленно просядет, а сам продукт утратит
конкурентоспособность на динамичном рынке. Если же продукты организации утратят конкурентоспособность, то аналогичная участь постигнет и саму компанию. То есть мы приходим
к выводу, что продуктовое развитие должно быть перманентным и носить интенсивный характер. Каким же образом этого достичь?
Подготавливая осуществление продуктовой трансформации, компания должна выделить
те продукты, на основании которых она планирует организацию перспективного ИТ-ландшафта. Как мы понимаем, речь в данном случае идет об end-to-end продуктах: именно они
несут ценность клиентам и партнерам. Каждый продукт характеризуется собственным P&L.
Основываясь на данном показателе (и в более широком смысле – финансовой модели каждого
конкретного продукта) организация бюджетирует продуктовые направления. В рамках последних создаются и развиваются цифровые продукты. В зависимости от динамики и перспектив
P&L меняются и инвестиции в каждый продукт. Разумеется, у продуктов также могут быть
КПЭ, но они в корне отличаются от проектных целевых показателей. Продукты ориентированы
на монетизацию той ценности, которую они несут клиентам, а данный процесс может быть,
например, растянут во времени. Старт монетизации ценности отсчитывается уже с момента
MVP, которым начинают пользоваться клиенты. Но этот факт не приводит к сокращению инвестиций в развитие продуктового ИТ-решения (в случае с проектной методологией ситуация
иная) – ресурсы не просто продолжают вкладываться в развитие продукта, но объемы инвестиций могут и возрасти. Их отдача обеспечивается монетизацией ценности и, как уже было
отмечено, является растянутым во времени и непрерывным процессом. Здесь мы видим принципиальное отличие от проектной методологии, в которой предполагалось создание информационных систем, передача их в эксплуатацию с последующей отдачей инвестиций. Как можно
рассчитывать на отдачу инвестиций, если создана система, потенциально не востребованная
рынком? А отсутствие востребованности как раз и возникает из-за того, что проект заранее
жестко определяет цели, сроки и бюджет как ключевые артефакты. Продукт же может претерпевать самые разительные изменения, сроки которых заранее не определены, при этом бюджет
также может варьироваться. Но вследствие вывода продукта на рынок инвестиции начинают
окупаться, более того, постоянное развитие продукта обеспечивает его соответствие рыночным
тенденциям, гарантируя окупаемость. Подчеркнем, что постоянное развитие является необходимым условием окупаемости.
Внимательный читатель сразу же отметит, что мы фактически описываем основы гибких
методологий. И окажется совершенно прав. Ведь гибкие методологии основываются на концепции продукта, на ценности, которую последний несет клиентам и партнерам компании. И мы
со своей стороны настаиваем на том, что истинно конкурентоспособные продукты возможно
создать именно с применением гибких методологий, которые, разумеется, нуждаются в адаптации под реалии компании, специфику ее продуктов, нормативное регулирование и т. д. Конкретные вопросы и детали подобной адаптации выходят за рамки настоящей книги.
Внимательный читатель может отметить: «Гибкие методологии гораздо дороже проектных – они подходят далеко не всем компаниям». Но подобная постановка вопроса попросту
некорректна. Мы не можем сравнивать условно линейную проектную деятельность с управляемым хаосом продуктового развития. Да, на некоем выделенном временном отрезке затраты
на проектную деятельность могут действительно оказаться меньше, нежели на развитие цифровых продуктов. Но что станет результатом подобного временного отрезка? Лишь некий этап,
зачастую промежуточный. Мы же должны смотреть в комплексе. Да, за гибкость требуется
платить. Но подобная плата с лихвой компенсируется соответствием рыночным тенденциям
и запросам пользователей, возможностью оперативно включать в состав продукта технологические и бизнес-новшества. Оценивать методологии управления лишь по затратам, понесенным
217

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

в некий временной промежуток, попросту некорректно. Мы рекомендуем читателям не поступать таким образом.
Отметим, что самая главная революция при переходе к продуктовой методологии и продуктовым процессам происходит в мышлении. Уже невозможно рассчитывать на то, что
созданный продукт обеспечит компании процветание на века. Это опасное заблуждение. И его
обязаны преодолеть владельцы продуктов, которые зачастую ранее (в проектной методологии) были продуктологами. Если для продуктолога, как правило, ключевым КПЭ является
факт вывода продукта на рынок (и чем скорее, тем лучше), то владелец продукта обязан учитывать гораздо большее количество факторов. Например, скорый вывод неготового продукта
на рынок может вызвать негативную реакцию клиентов. Последующее преодоление негативного эмоционального фона может привести к значительным расходам, существенно превышающим затраты на более глубокую проработку продукта перед выводом на рынок. «Как же так,
а MVP?» – воскликнет внимательный читатель. Безусловно, MVP может и должен содержать
ограничения и допущения, благодаря которым он и выводится на рынок в относительно сжатые
сроки. Но здесь и проявляется искусство владельца продукта и продуктовой команды, которые должны быть готовы сделать ограниченную версию продукта, подобрать для нее целевую
аудиторию, обеспечить запуск на рынке и избежать негативной реакции, вызванной ограничениями. Основу успеха на этом пути составляет новое мышление, новый mindset. И mindset
этот – продуктовый.
Подобное изменение процессов создания и развития продуктов влияет на многие другие
процессы, принятые в организации. Должны изменяться процессы управления архитектурой,
разработкой, сопровождением, инфраструктурой и т. д. Рассмотрим эти изменения подробнее.
Указанные процессы традиционно строились на основе стандартного производственного процесса в области информационных технологий, который, в свою очередь, был основан
на стандартном порядке управления проектами, ограничения которого в современном мире мы
рассмотрели ранее. Стандартный производственный процесс представлен на Рисунке 61 (основан на Рисунке 24 из книги «Архитектура цифрового мира»).

218

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 61. Стандартный производственный процесс в ИТ
Подчеркнем, что «стандартность», указанная нами, заключается в традиционном восприятии реализации информационных систем в рамках проектной деятельности. В условиях
современного цифрового мира указанная «стандартность» должна быть пересмотрена и заменена принципиально новыми подходами.
Реализация «проекта с ИТ-составляющей» (если использовать унаследованную терминологию) предполагала наличие следующих стадий:
• Формирование требований к автоматизации.
• Бизнес-анализ предъявленных требований, предусматривавший их структуризацию
и систематизацию. Зачастую предполагалось, что в ходе бизнес-анализа осуществлялся переход от ситуации, когда «клиент слабо представляет себе облик результата», к тому, что «клиент согласился, что то, что написано и/или представлено в виде макетов интерфейсов, соответствует его пожеланиям».
• На основании бизнес-анализа, представлявшего собой набор бизнес-требований,
а также сопоставленных им нефункциональных требований, выполнялось архитектурное проектирование. Последнее позволяло создать высокоуровневый взгляд на систему, объединявший функциональную и нефункциональную составляющие требований, предъявляемых
к автоматизации. Формат архитектурного проектирования определялся выбранным архитектурным фреймворком, например, TOGAF.
• По итогам архитектурного проектирования проводился системный анализ, результатом
которого становились детальные постановки задач разработчикам, например, в формате функционально-технических требований.
• На основании функционально-технических требований или иных артефактов, принятых в организации в качестве результатов этапа системного анализа, осуществлялась разработка автоматизированных функций.
• По итогам разработки созданный программный код передавался на тестирование.
В дальнейшем, в зависимости от результатов тестирования, код мог возвращаться разработчикам либо передаваться на этап предварительных или комплексных испытаний информационной системы.
На Рисунке 61 показано последовательное выполнение стадий автоматизации. В реальности возможны и обратные переходы, ввод в рабочий процесс определенной итеративности.
Но ввиду тяжеловесности и масштабности создававшихся информационных систем чаще всего
исполнение проекта осуществлялось в режиме строгой последовательности приведенных стадий.
Для архитектурного сопровождения подобного процесса автоматизации обычно создавался процесс управления архитектурой. В рамках данного процесса определялись хорошо
зарекомендовавшие себя конфигурации программного и аппаратного обеспечения, а также
основные архитектурные практики их применения. В ходе создания архитектурного решения
собирался набор указанных практик, позволявший обеспечить производительное и надежное
исполнение сформированных ранее бизнес-требований с учетом требований нефункциональных. Ввиду последовательного выполнения приведенных на Рисунке 61 стадий проектирование занимало длительный промежуток времени. При этом архитектурный репозиторий, содержавший наборы указанных выше архитектурных конфигураций, обновлялся медленно – лишь
после всестороннего изучения новых технологий и принятия решений о возможности использования их в архитектуре организации. При этом набор конфигураций был общим для абсолютного большинства архитектурных решений.
219

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Приводила ли указанная общность к технологической унификации? Как правило, ответ
на этот вопрос был отрицательным. Тяжеловесный процесс управления архитектурой приводил к тому, что команды разработки буквально искали любой шанс на то, чтобы избежать
необходимости следования длительным алгоритмам. Появление и развитие новых технологий
происходят постоянно. Ожидать их включения в архитектурный репозиторий означает допускать критическое снижение скорости разработки и развития компании в целом. Но в случае
традиционного проектного управления длительные архитектурные циклы еще были допустимыми. В условиях продуктовой трансформации требования к процессу управления архитектурой непременно должны были измениться.
Необходимо сразу отметить, что продуктовая трансформация вовсе не отменяет те этапы
рабочего процесса, которые схематично отображены на Рисунке 61. При переходе от проектной
методологии к развитию продуктов в любом случае необходимо осуществлять сбор и анализ
требований, архитектурное проектирование, да и без разработки цифровой продукт создать
не получится. Но мы уже говорили о том, что бизнес-процессы организации в результате продуктовой трансформации становятся основанными на процессах жизненного цикла продуктов. А это означает, что нельзя просто единично выполнить каждую стадию рабочего процесса
и считать, что продукт создан и не нуждается в дальнейшем развитии. Работа над продуктом
должна вестись итеративно. И каждая итерация включает в себя все стадии работы над продуктовым ИТ-решением. При этом масштабность того или иного этапа рабочего процесса на каждой итерации определяется индивидуально. При планировании продукта большее внимание
должно уделяться формированию его бэклога и аналитической проработке пользовательских
историй. Разработка на данных итерациях может заключаться в прототипировании и проверке
гипотез. В дальнейшем при развитии продукта масштаб переработки пользовательских историй может снижаться, в то время как объемы разработки и тестирования значительно возрастают. А что же при этом происходит с архитектурой?
В свое время автору этих строк приходилось сталкиваться с утверждением, что при
использовании гибких практик в процессе создания ценности значимость архитектуры
и архитекторов существенно снижается. Якобы самоорганизованные команды самостоятельно
создают лучшие архитектурные решения, реализуют их и запускают в постоянную эксплуатацию. Автор не возражает, если таким образом будут творить собственные продукты компании,
конкурирующие с теми, где осуществляет свою трудовую деятельность он сам. Ведь результатом становится технологический хаос, для выявления закономерностей в котором даже не всегда достаточно изучить работы одного из авторов теории хаоса Эдварда Лоренца. При этом
важным следствием указанного хаоса становится большое количество MVP, развитие и масштабирование которых до полноценных промышленных решений оказывается невозможным.
На самом деле, если вернуться к серьезному тону, большинство апологетов самоорганизации
вернулись к необходимости архитектурного контроля, более того, количество различных архитектурных ролей и задействованных на них специалистов существенно возросло по сравнению
с временами «до гибких практик».
Но архитектура – это далеко не только контроль. Архитектор должен помогать продуктовым командам создавать ценность для клиентов и партнеров компании. А для этого и архитектура должна создаваться в итеративном (и скоростном) режиме. Времена, когда можно
было создавать первичную концептуальную архитектуру в течение нескольких месяцев, безвозвратно канули в Лету. Концептуальная архитектура должна создаваться в сжатые сроки
уже на основании первичных пользовательских историй и технических задач, предусматривать переходные архитектуры для MVP, учитывать как имеющийся, так и перспективный технологический базис. Архитектор не может ограничиваться только концептуальной архитектурой, отдавая дальнейшую проработку на откуп команде разработки. К сожалению, подобное
часто встречалось при осуществлении автоматизации в классической проектной методоло220

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

гии. На основании концептуальной архитектуры и имеющихся наработок должны создаваться
и детализированные артефакты, например:
• Функционально-информационная архитектура, описывающая основные функциональные области проектируемого решения, являющаяся фактически проекцией бизнес-требований
на технологический базис. Кроме того, функционально-информационная архитектура описывает ключевые бизнес-процессы решения и обрабатываемые в них бизнес-объекты (мы избегаем на данном уровне использовать термин «данные»).
• Компонентная архитектура, описывающая логические компоненты продуктового ИТрешения. Указанные компоненты напрямую проецируются на уровень разработки, в отличие
от компонентов концептуальной архитектуры, и должны быть уточнены аналитиками в последующем. На данном этапе фиксируются технологии, исполняемые компоненты, базовые топологии и т. д.
• Интеграционная архитектура, детально описывающая внешние и внутренние взаимосвязи компонентов цифрового продукта.
• Технологическая архитектура, определяющая полный стек используемых технологий
(не только основные, но и вспомогательные технологии, например, операторы для облачного
исполнения), их топологии, включая все варианты использования, решения по обеспечению
масштабируемости, надежности, информационной безопасности и т. д.
Приведенный перечень артефактов выглядит достаточно громоздким, но он может создаваться итеративно и уточняться в ходе жизненного цикла цифрового продукта. Кроме того,
в создании и актуализации артефактов архитектору должна оказывать помощь продуктовая
команда, а сам он обязан представлять на ее суд результаты своей работы.
При этом продуктовые команды могут и должны экспериментировать в ходе своей
работы. Это означает, что, даже имея в своем распоряжении архитектурный репозиторий
и наборы проверенных конфигураций (необходимость указанных объектов мы ни в коем
случае не подвергаем сомнению), следует постоянно осуществлять технологический поиск
и внедрять в свою деятельность технологические новшества. Только таким образом возможно
обеспечивать перманентное интенсивное развитие. Для этого архитектурные артефакты, представленные выше, должны иметь как собственный жизненный цикл для каждого артефакта, так
и общий жизненный цикл архитектуры продуктового ИТ-решения. А жизненный цикл архитектуры должен быть согласован с процессами жизненного цикла продуктов. То есть архитектура существует не в вакууме, а развивается совместно с продуктами, предоставляемыми организацией клиентам и партнерам.
При проектировании архитектурных решений обязательным этапом должен стать этап
проверки технологической готовности решения. При создании архитектуры на основании требований к продукту архитектор должен анализировать технологический рынок. При этом
он не должен замыкаться в наборе заранее утвержденных архитектурных конфигураций.
При выявлении возможных улучшений, технологических новшеств, возникающих вариантов
использования технологий он должен включать их в потенциальное использование в архитектурных решениях. Аналогично продуктовая команда может и должна предлагать ему варианты технологического развития. Но при этом необходимо избегать потенциального хаоса,
о котором говорилось выше. Каждая технология, ранее не использовавшаяся в организации,
каждое новшество должны быть опробованы и пропилотированы. Хотя бы на уровне MVP.
На основании результатов пилотирования и выявленных в ходе него проблем, недочетов и подводных камней можно будет говорить о применимости технологии, вырабатывать топологии
и варианты ее использования. А применяя свойство открытости платформы, включать в состав
221

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

изменения, архитекторы создают в том числе и архитектуру ИТ-решения, команда разработки
обязана работать с ними в тесном контакте. Тем самым обеспечивается тесная связь всех архитектурных артефактов как между собой, так и, собственно, с исполняемыми артефактами,
создаваемыми разработчиками. То есть можно утверждать, что разработка реально осуществляется на основе архитектуры.
Отметим, что и сам процесс управления разработкой в сложившейся ситуации претерпевает изменения. Безусловно, продуктовые команды следуют гибким практикам в той их реализации, которая наиболее отвечает специфике компании и адаптирована под ее особенности.
Но при этом нельзя утверждать, что именно самоорганизующаяся команда непосредственно
и создает «лучшую архитектуру». Нельзя утверждать и обратное – команда получает готовую архитектуру и осуществляет разработку строго в соответствии с ней. Разработка ведется
в тесном рабочем контакте с архитектурой. Оценка технологической готовности тех или иных
решений, которые необходимо внедрять в рамках создания цифрового продукта, осуществляется на основе архитектуры. При этом все выявленные особенности технологий немедленно
фиксируются в архитектурных артефактах, отражаются в архитектурном репозитории, становятся доступными для смежных команд разработки. Данный процесс носит итеративный и двунаправленный характер. При выполнении разработки все выявленные проблемы (например,
в ходе прототипирования или оценки технологической готовности) немедленно передаются
архитектору для уточнения архитектурных решений и внесения в них необходимых корректив, при этом архитектор помогает командам разработки, постоянно консультируя их по тем
или иным архитектурным аспектам. Бэклог продукта развивается совместно: владелец продукта, команда разработки, архитектор наполняют его и пользовательскими историями и техническими задачами, чтобы связать процессы управления архитектурой и разработкой. Но при
этом важно помнить, что связь указанных процессов является не самоцелью, а инструментом
создания подлинной ценности.
Управление инфраструктурой также претерпевает значительные изменения при осуществлении продуктовой трансформации. Инфраструктура также приобретает продуктовый
характер. Казалось бы, где цифровой продукт, а где серверы, сети, операционные системы?
Но связь, как всегда, может быть выведена и оцифрована. Ключом же к данной связи является именно трансформация ИТ-ландшафта компании. Если ранее инфраструктура обеспечивала размещение информационных систем, а продуктовое разграничение выглядело весьма
эфемерным, то в условиях сегментации ИТ-ландшафта в соответствии с продуктовой логикой ситуация в корне изменяется. Если мы уходим от традиционных информационных систем
к гранулированным продуктовым ИТ-решениям, то и инфраструктура, выделенная для исполнения каждого ИТ-решения, оказывается гранулированной. Разумеется, необходимо учитывать современные технологии виртуализации в рамках грануляции. Таким образом, становится
возможным независимо оцифровать стоимость инфраструктуры, использующейся для исполнения каждого цифрового продукта. «А в чем же смысл подобной оцифровки?» – не удержится от вопроса внимательный читатель. Мы со своей стороны не удержимся от некоторого
сарказма в ответе и скажем, что смысл находится на поверхности. Ведь при создании и развитии продукта мы ориентируемся на ценность, которую он несет клиентам и партнерам, а также
на P&L. И важной составляющей последнего показателя является стоимость инфраструктуры,
используемой продуктом. Цифровой продукт, к сожалению, не парит в воздухе, а исполняется
на вполне осязаемых, даже в случае облачного решения, реальных мощностях. А современные
технологии управления инфраструктурой позволяют осуществлять динамический биллинг,
учитывающий, например, эластичное масштабирование продуктового ИТ-решения. Результатом становятся конкретные числа, характеризующие инфраструктурные затраты продукта
и позволяющие осуществлять точный и адресный расчет P&L продуктов организации. Современный процесс управления инфраструктурой должен учитывать:
223

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

тами.

• Сегментацию предоставляемых продуктовым ИТ-решениям мощностей.
• Динамическое использование мощностей цифровыми продуктами.
• Максимальную независимость исполнения продуктовых ИТ-решений.
• Необходимость точечных расчетов стоимости инфраструктуры, используемой продук-

То есть процесс управления инфраструктурой не просто гарантирует надежное исполнение цифровых решений организации, а учитывает их продуктовую специфику. Это априори
означает существенную модификацию процесса.
Продуктовая трансформация компании оказывает серьезнейшее влияние на процесс
управления релизами. Мы подробно описывали современные подходы к релизным моделям
в разделе «Архитектура как сквозной артефакт создания ценности» книги «Архитектура
цифрового мира», а потому не будем повторять в настоящем изложении все тезисы, ранее
нами озвученные. Ограничимся констатацией того, что все они сохранили свою актуальность.
Но необходимо сказать несколько слов о процессах управления релизами в современной продуктовой архитектуре.
Однажды автору этих строк в ходе профессиональной дискуссии был задан вопрос:
«Является ли красным флагом рост числа локальных релизов при сохранении числа релизов
интеграционных?» Автор, со своей стороны, не удержался от занудства, отметив, что в терминологии отрасли ИТ не содержится такого термина, как «красный флаг», а в контексте конкретной организации и принятых в ней жаргонных выражений подобный «термин» может означать
все что угодно. Но если предположить, что красный флаг в общем случае сигнализирует о наличии проблемы, а в противоположность ему некий «зеленый флаг» может свидетельствовать
об отсутствии потенциальных проблем, то факт, отмеченный в вопросе, сам по себе не свидетельствует ни о чем в части ИТ. Сам по себе рост числа локальных релизов не является ни
«красным флагом», ни «зеленым». Но он может считаться «красным флагом» в части мировоззрения, указывая на то, что автор вопроса мыслит категориями предшествующих архитектурных и технологических поколений. И, вполне возможно, культивирует их в своей профессиональной деятельности.
Внимательный читатель, тщательно изучивший настоящее изложение, практически
моментально воскликнет: «Так ведь это здорово, что растет число локальных релизов!» И будет
абсолютно прав, если речь идет об организации, осуществляющей продуктовую трансформацию. Но не будем забегать вперед, а разберем два диаметрально противоположных случая,
характерных для озвученного выше вопроса.
Начнем с уже упомянутых предшествующих архитектурных и технологических поколений. Еще раз напомним, чем характеризовался ИТ-ландшафт, созданный в соответствии
с ними. Он был представлен некоторым количеством информационных систем с разным технологическим стеком, лежавшим в основе реализации последних. Системы интегрировались
всевозможными способами: точечные интеграции самого разнообразного характера, интеграционные шины, возможно, даже потоковое программное обеспечение, при этом конкретный
способ интеграции для нас сейчас не представляет интереса. Главное заключается в другом –
в подобным образом организованном ИТ-ландшафте необходимо задействовать множество
информационных систем для автоматизации полезной для клиента функции. Задействуются
фронтальные системы, учетные системы, комплексы управления бизнес-процессами, интеграционное ПО. В таком случае даже неловко говорить о продуктах, особенно после всего вышеизложенного. Здесь и возникает концепция интеграционного релиза: для вывода в опытную,
а затем и в постоянную эксплуатацию той или иной функции необходимо доработать множество систем, при этом доработки должны быть согласованными. Затем необходимо провести
224

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

Рисунок 62. Пример взаимосвязи систем предыдущих
архитектурных и технологических поколений
На Рисунке 62 схематично показан элемент ИТ-ландшафта предыдущих поколений. Данные продуктов организации (в приведенном примере их принципиально неверно было бы
именовать end-to-end продуктами) хранятся в учетной системе, на уровне которой автоматизируются операции учетной логики. В компании присутствуют две фронтальные системы
(отмеченные как 1 и 2 на Рисунке 62). При этом в них выполняются различные процессы фронтального обслуживания с разными классами критичности. Для упрощения примера предположим, что на уровне Фронтальной системы 1 исполняются процессы уровня Business Critical
(BC) и Business Operational (BO), а на уровне Фронтальной системы 2 исполняются про225

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

цессы уровня Mission Critical (MC). Интеграция информационных систем осуществляется при
помощи корпоративной сервисной шины ESB.
В соответствии с требованиями реализуются доработки Фронтальной системы 1. При
этом указанные доработки затрагивают учетную логику, то есть Учетную систему, а также
интеграционную шину ввиду необходимости отражения изменений на уровне интеграции.
Разумеется, в рамках интеграционного релиза необходимо синхронизировать доработки указанных трех систем. Но функции Учетной системы используются Фронтальной системой 2,
в том числе могут использоваться дорабатываемые функции. При этом класс критичности процессов, исполняющихся во Фронтальной системе 2, выше, нежели процессов, исполняющихся
во Фронтальной системе 1. То есть интеграционный релиз оказывает влияние на Фронтальную
систему 2 и потенциально может нарушить непрерывность процессов с более высоким уровнем
критичности, нежели дорабатываемые. В такой ситуации, разумеется, необходимо множество
согласований на уровне планирования релиза, проектирования и реализации доработок, их
последующего тестирования, формирования релиза и передачи его в эксплуатацию. В противном случае может пострадать непрерывность деятельности организации.
В такой ситуации у команд разработки появляется соблазн сформировать локальный
релиз уровня Фронтальной системы 1, включающий все необходимые дополнения функционала, после чего провести тестирование подобного релиза и передать его в эксплуатацию.
Но что же будет в таком случае содержать подобный релиз? Кроме логики фронтальных операций, характерной для Фронтальной системы 1, он будет также содержать учетную логику, являющуюся нетиповой для соответствующей информационной системы. В этом случае подобная
логика может также отличаться с точки зрения архитектуры и базовых технологий реализации.
Фактически на уровне фронтальной системы осуществляется смешение архитектурных уровней и усложнение всей системы. Впоследствии возможно и дублирование логики на уровне
различных информационных систем. Результатом же подобного подхода к релизной политике
становится «винегрет» технологий и функций, которые могут быть как локализованы в рамках
той или иной системы, так и распределены между ними. Совокупная стоимость владения ИТландшафтом организации в таких условиях существенно возрастет, а его устойчивость, напротив, снизится.
Таким образом, в рассмотренном нами примере рост числа локальных релизов при
сохранении числа интеграционных является тревожным фактом, наводящим на подозрения,
что команды разработки путем локализации релизов наполняют информационные системы
несвойственными последним функциями. При этом снижается надежность ИТ-ландшафта
и растет его стоимость. Поэтому с подобным явлением стоит бороться. Но каким же образом?
Об этом мы порассуждаем чуть ниже.
Отметим также, что в рассмотренном примере не имеет значения архитектура самих
информационных систем. Нередко, заявляя необходимость перехода к микросервисной архитектуре, компании ограничивают последнюю конкретными информационными системами.
Но в примере, схематически представленном на Рисунке 62, сложность релиза не уменьшается
вследствие того, что системы перейдут от монолитной архитектуры к микросервисной – релиз
усложняется смешением функций, характерных для тех или иных систем.
Второй случай, диаметрально противоположный только что рассмотренному, характерен
для организации, уже осуществившей продуктовую трансформацию ИТ-ландшафта. Он схематично показан на Рисунке 63.

226

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 63. Пример внесения доработок в продуктовый
ИТ-ландшафт
На Рисунке 63 представлен ИТ-ландшафт компании, осуществившей продуктовую
трансформацию. Как мы неоднократно показывали по ходу настоящей книги, подобный ИТландшафт состоит из набора end-to-end продуктов, определяющих весь набор логики, характерной для них. Ранее мы уже проиллюстрировали примерами, что даже крайне сложные общекорпоративные задачи возможно спроектировать и реализовать в продуктовой парадигме.
В приведенном примере доработки фронтальной логики одного из продуктов (на Рисунке
63 это продукт 1), в случае связанных с ними изменений продуктовой логики либо логики
управления бизнес-процессами, оказываются локализованными в границах этого же продукта.
При этом влияние указанных доработок на смежные продуктовые ИТ-решения минимально
(а в идеале отсутствует). То есть релиз в данном случае ограничен конкретным цифровым
продуктом, а потому может считаться локальным. Повторим, при архитектуре ИТ-ландшафта,
позволяющей формировать end-to-end продукты с минимальной связностью, становится возможным обеспечить независимые релизные циклы для каждого продуктового ИТ-решения.
В этом случае все релизы становятся локальными (и, к слову, требуют минимум согласований).
То есть мы уходим от концепции интеграционных релизов в принципе, а рост числа локальных релизов не является проблемой, более того, он свидетельствует об ускорении продуктовой
разработки.
Двумя приведенными примерами мы показали некорректность поставленного вопроса,
если он задается «в вакууме», то есть без контекста. Настоящая проблема возникает в тот
момент, когда в организации начинают бороться с локальными релизами, пытаясь запретить
227

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

их и всю деятельность в данном направлении свести к релизам интеграционным. Нередкими
являются ситуации, когда борьба с локальными релизами сводится к упрощению согласований – это примерно соответствует лечению онкологии примочками.
Нужно не бороться с локальными релизами, а менять мышление в масштабах компании и осуществлять продуктовую трансформацию. И тогда рост числа локальных релизов станет сигналом улучшения time-to-market, то есть к росту числа подобных релизов компания,
наоборот, будет стремиться. А выход релизов будет повышать конкурентоспособность организации, продуктовая структура ИТ-ландшафта положительно сказываться на обеспечении
непрерывности, станет возможным снижать совокупную стоимость владения ИТ-активами.
На относительно простом примере мы показали вариант изменения процесса управления
релизами. Первично здесь изменение мышления. Переход к продуктовому мышлению позволяет в корне пересмотреть релизную политику компании и превратить вчерашние проблемы
в завтрашние возможности.
Говоря о релизной политике, нельзя не сказать несколько слов о платформенном подходе.
Мы уже неоднократно акцентировали внимание читателя на том, что в примерах создания
цифровых продуктов прибегаем к использованию цифровой платформы. Но в рамках платформенного развития и для самого платформенного решения осуществляется выпуск релизов,
более того, релизы могут касаться отдельных подсистем платформы, платформенных сервисов
и компонентов. И вот здесь крайне важно следовать практике распределенности. Релизы распределенных сервисов и компонентов оказывают минимальное взаимовлияние. В свою очередь релизы продуктов, цифровизируемых в формате платформенных приложений и самой
платформы, также должны минимальным образом влиять друг на друга. Разумеется, если при
развитии продукта возникают новые требования к платформе, то без влияния не обойтись.
Но в этом случае архитектура платформы должна следовать свойству открытости – дополнения
могут вноситься продуктовой командой и публиковаться таким образом, чтобы быть доступными для дальнейшего использования смежными продуктовыми командами. При этом действующий платформенный функционал не подвергается изменениям: при помощи механизма
версионности продуктовые компоненты, для которых не требуется применение обновлений,
продолжают использовать ранее созданные функции платформы. Очевидно, что поддержка
множества действующих платформенных релизов является финансовой нагрузкой для компании. Поэтому при планировании и проектировании архитектуры платформы и продуктов
на ее основе следует создавать финансовую модель, позволяющую оценить допустимое количество одновременно поддерживаемых платформенных релизов. Релизная модель является
обязательной составляющей как платформы в целом, так и каждого платформенного сервиса
в отдельности.
Внимательный читатель может отметить, что при выходе новых релизов платформы
не избежать влияния на платформенные приложения. Подобное влияние вполне вероятно.
Но с целью обеспечения лучших рыночных показателей цифровых продуктов, а также достижения положительного развития P&L такое влияние следует минимизировать. Читатель может
задаться вопросом: «Релизная модель платформы и P&L продуктов, создаваемых на ее основе,
являются параметрами разных характеристик – технической и финансовой соответственно.
Как корректно в таком случае отразить их связь?» Мы предлагаем читателю подойти к этому
вопросу с другой стороны: предположим, что в организации применяется платформенное
решение, а также функционируют пять-шесть десятков цифровых продуктов, автоматизация
которых осуществлена в формате платформенных приложений. Если выход нового релиза
платформы потребует пересборки всех приложений, то сложившаяся ситуация однозначно
свидетельствует о недостатках архитектуры. И здесь наблюдается прямая связь с P&L продуктов: если ввиду технического процесса (ввода нового релиза платформы) приходится
осуществлять пересборку приложения, проводить его повторное тестирование и отладку, то
228

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

выполнение указанных процессов является совсем небесплатным для компании само по себе,
к тому же отвлекает существенные трудовые, временные и финансовые ресурсы от развития.
То есть в период потенциального развития конкурирующих предложений компания растрачивает свои ресурсы на повторное тестирование уже находящихся в эксплуатации приложений.
Очевидно, что влияние на P&L продуктов подобный платформенный релиз оказывает. Причем весьма негативное.
Как же избежать описанного негативного сценария? Одним из вариантов является встраивание платформы, которое мы подробно описывали в предыдущих книгах («Архитектура
цифрового мира» и «Архитектура цифровых платформ. От настоящего к будущему»). Мы
не будем в настоящем изложении повторять все ранее представленные тезисы, приведем
небольшой пример. Схематично он показан на Рисунке 64.

Рисунок 64. Пример встраиваемости платформы
в платформенные приложения
На иллюстрации представлен пример реализации цифрового продукта с использованием
платформенного подхода. Продукт состоит из трех компонентов, платформа предоставляет
четыре сервиса. На Рисунке схематично представлены связи компонентов цифрового продукта и платформенных сервисов, при этом мы специально показываем, что компоненты могут
использовать различный набор сервисов.
Предоставление сервисов осуществляется посредством платформенного SDK, который
встраивается в структуру приложений: именно таким образом в нашем примере реализуется свойство встраиваемости платформ. При этом вполне возможна такая архитектура платформы, при которой каждый платформенный сервис или компонент может предоставлять
собственное независимое подмножество SDK для использования потребителями – платформенными приложениями. Отметим, что в таком случае при реализации продуктов в парадигме
serverless приложений необходимо тщательно учитывать все зависимости платформенных сервисов между собой. В противном случае возможны ошибки времени выполнения, связанные
с отсутствием в составе исполняемого компонента требуемых библиотек. В случае же использования контейнеров и вариантов сборок, предполагающих интроспекцию зависимостей (примером может выступать Spring Boot), указанная проблема не носит столь заметного характера.
Фактически платформа компании в нашем примере аналогичная, например, платформе Java.
229

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Зависимости платформенных библиотек включаются в состав приложения аналогично зависимостям Java.
В представленном примере при обновлении платформенных сервисов и компонентов
в рамках релизов возможно продолжение независимого исполнения компонентов приложений
при условии поддержки платформой обратной совместимости SDK. Добавим, что обеспечение
указанной совместимости осуществляется общепринятым прозрачным способом по аналогии
с тем, как это происходит в программных фреймворках. При этом на уровне платформы могут
поддерживаться и несколько исполняемых релизов для тех случаев, когда совместимость SDK
как в части сигнатуры, так и в части реализации не гарантируется. Приведенный подход позволяет минимизировать зависимость жизненного цикла приложений, то есть продуктов компании, от релизов платформы. Обратим внимание, что и продукт, и платформа в представленном
примере являются распределенными, вследствие чего релизы сервисов и компонентов могут
выпускаться независимо. Разумеется, в реальности платформа должна предоставлять своим
потребителям правила формирования релизов (релизную политику), а потребители использовать ее в ходе проектирования и реализации приложений. В противном случае возможны
ошибки при развитии платформенной экосистемы, включающей саму платформу, платформенные приложения компании и приложения партнеров.
Мы привели примеры изменения ряда процессов организации в условиях продуктовой
трансформации и создания подлинно цифровых продуктов. Мы далеки от мысли, что перечислили все возможные процессы в компании и их потенциальные изменения. Но главное, что
необходимо отметить, заключается в том, что изменение процессов характеризует изменение
мышления, которое является первичным. Мы продемонстрировали, что новое мышление позволяет не решать старые проблемы, порожденные предыдущими архитектурными и технологическими подходами, а превратить их в новые возможности, а в каких-то случаях и попросту исключить. Важно подчеркнуть, что изменение мышления представляет собой длительный
и непростой процесс, а организации и конкретные персоналии, следующие этому процессу,
должны избегать ключевых ментальных ошибок современности. Мы уже перечисляли последние в книге «Архитектура цифрового мира». Они сохранили свою актуальность, а потому мы
не будем повторять соответствующую главу указанной книги, а лишь тезисно напомним их
читателю:
• Гибкие практики. При реализации продуктового подхода необходимо помнить, что гибкие практики не могут считаться догмой, но являются руководством к действию. Их необходимо адаптировать к реалиям конкретной организации, учитывая специфику деятельности,
текущий этап трансформации, регуляторные ограничения и многое другое. Ни в коем случае
нельзя превращать гибкие практики в карго-культ.
• Информационная безопасность, конечно, не может считаться ошибкой сама по себе.
Но в данном аспекте важно уйти от согласовательной работы к реальному сотрудничеству.
Специалисты по информационной безопасности сами должны во многом стать архитекторами,
создавать решения соответствующего класса, гарантирующие надежность предоставляемых
организацией цифровых продуктов. И работать они должны совместно с командами гибких
практик.
• Шаблоны проектирования. Ни в коем случае специалисты, задействованные в продуктовой трансформации компании, не должны увлекаться подходом «паттерны ради паттернов»,
что, к сожалению, нередко наблюдается на рынке. Перед применением при создании и развитии цифровых продуктов каждый шаблон проектирования должен анализироваться на предмет
актуальности и применимости к конкретным реалиям организации, продуктовой специфике,
рыночным требованиям, современному технологическому стеку.
230

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Эффект Даннинга – Крюгера. Данная ментальная ошибка является частым спутником на пути любой трансформации. Продуктовая трансформация не является исключением.
Подводными камнями, ведущими к «обрыву сознания», могут выступать такие факторы, как
отсутствие быстрых результатов, недостаток отдачи инвестиций на первых этапах трансформации, большое количество разнородных MVP, трудности с преобразованием информационных
систем в продуктовые ИТ-решения и многое другое. Здесь крайне важно не останавливаться
на полпути, не зацикливаться на неудачах и временных трудностях, а как можно скорее проходить «ущелье отчаяния» на пути к «плато стабильности». Лучше допустить ошибку раньше,
но устранить ее, нежели свернуть трансформацию, не окончив ее. Ведь прекращение трансформации не вернет уже затраченные ресурсы, но и не позволит достичь высокого уровня конкурентоспособности на современном рынке.
Детальное рассмотрение проблем ментальности в области информационных технологий
приведено в главе «Ментальные ловушки современности» книги «Архитектура цифрового
мира».
По ходу настоящей главы мы рассмотрели такой исключительно важный аспект продуктовой трансформации, как изменение мышления в компании, а также связанное с этим изменение организационных процессов. Был приведен ряд примеров изменения процессов, критичных с точки зрения управления созданием и развитием цифровых продуктов. В следующей
главе мы подробно рассмотрим связь между цифровыми продуктами и платформенным подходом.

231

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровые платформы и цифровые продукты
Применение цифровых платформ
в создании цифровых продуктов
Внимательный читатель может упрекнуть нас за название и тематику настоящей главы
и обвинить в повторении. Апеллировать при этом он будет к тому, что в книге «Архитектура цифрового мира» платформам был посвящен весьма обширный раздел, книга же «Архитектура цифровых платформ. От настоящего к будущему» вся целиком посвящена платформам и платформенному подходу. Неоднократно упоминались платформы и платформенные
сервисы по ходу настоящего изложения. Мы же возразим читателю, что огромная важность
вопроса применения цифровых платформ вынуждает нас возвращаться к нему снова и снова,
тем более что в текущем изложении необходимо рассмотреть специфические особенности
использования платформенного подхода именно в контексте создания и развития цифровых
продуктов. Также отметим, что ответы на ряд вопросов читателя, озвученных по ходу предыдущих глав, мы несколько придержали, попросив его набраться терпения. И в настоящей главе
мы наконец удовлетворим его любопытство.
Как мы уже неоднократно отмечали, в настоящее время отсутствует строгое и общепринятое определение цифровых платформ. Безусловно, соответствующие термины вносятся
в законодательство, присутствуют в ряде нормативных актов, по ним читаются курсы в ведущих вузах. Но нельзя не обратить внимание читателя на два факта:
• В различных источниках термины, определяющие, что такое цифровые платформы,
заметно отличаются и нередко противоречат друг другу.
• В достаточно большом количестве случаев определения, которые даются платформам, либо значительно сужают, либо, наоборот, необоснованно расширяют данное понятие.
Например, под ряд определений цифровых платформ подойдет любой сайт в сети Интернет.
Либо же присутствуют определения цифровых платформ через «информационные системы»,
что, на наш взгляд, принципиально противоречит всем современным тенденциям развития
архитектуры.
Мы, со своей стороны, продолжаем делать упор на то, что современная платформа
предоставляет опосредованную ценность клиентам, поскольку существенно упрощает, ускоряет и удешевляет создание цифровых продуктов в формате платформенных приложений. При
этом платформенные приложения реализуются в соответствии с унифицированными архитектурными и технологическими практиками. А использование платформенных сервисов и компонентов характерно не только для этапа создания или доработки приложений, но и для
их исполнения, поддержки жизненного цикла приложения. То есть платформа представляет
собой среду создания и исполнения приложений. А поскольку мы говорим об унификации
приложений, об их бесшовной интеграции между собой, об общих принципах управления жизненным циклом, то можно даже усилить определение и сказать, что современная платформа
представляет собой экосистему создания и исполнения приложений.
Приведенное определение позволяет нам сразу исключить в качестве неприемлемого
подход «множества платформ», который был упомянут в книге «Архитектура цифровых платформ. От настоящего к будущему» и по ходу предыдущего изложения. Невозможно эффективное создание комплексных end-to-end продуктов с применением множества платформ,
232

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

например, отдельных омниканальной, учетной, процессной и прочих. Платформа должна
обеспечивать поддержку всех архитектурных уровней цифрового продукта. Это не означает,
что каждый продуктовый компонент использует все возможности платформы (хотя, конечно,
запрет на подобное отсутствует), но каждый компонент создается и развивается с использованием общей платформы компании. Ранее мы уже подробно рассматривали такую ключевую
тенденцию развития архитектуры, как распределенность. И распределенная платформа обеспечивает независимость использования платформенных сервисов и компонентов платформенными приложениями – цифровыми продуктами. То есть различные компоненты цифровых
продуктов могут использовать различные подмножества платформенных сервисов. Но это сервисы общей платформы.
Напомним читателю основные свойства современных и устремленных в будущее цифровых платформ:
• Платформа не является информационной системой.
• Платформа не является обособленным программным комплексом.
• Платформа должна быть открытой, и изменения в нее могут вносить любые команды,
которые должны брать на себя ответственность за вносимые доработки.
• Платформа не должна быть замкнутой.
В контексте настоящей книги особенно важное значение приобретает свойство открытости платформ, поэтому в данной главе мы посвятим ему отдельный раздел. Сейчас же рассмотрим подробнее остальные свойства платформ.
Потенциальное позиционирование платформы в качестве информационной системы
предполагало ее овеществление в ИТ-ландшафте организации. Но что означает подобное овеществление? Фактически самостоятельное позиционирование платформы предполагает, что
у подобного элемента ИТ-ландшафта компании появляются собственные пользователи, а главное, что он предоставляет самостоятельную ценность. Но пользователями платформы являются платформенные приложения, а ценность она предоставляет опосредованную, улучшая
P&L продуктов. Последние в свою очередь автоматизируются путем создания платформенных приложений. Проведем некоторую историческую аналогию. При реализации приложений в соответствии со спецификацией Java EE (а до этого J2EE) нередко применялся сервер
приложений IBM WebSphere Application Server (WAS). Фактически WAS представлял собой
платформу реализации Java EE приложений. При этом очень редкие организации прибегали
к использованию термина «информационная система» в отношении WAS. Аналогичным образом нет никакого смысла обозначать современную платформу в качестве отдельной системы,
тем более что мы уже неоднократно подчеркивали тот факт, что термин «информационная
система» уже потерял свое классическое значение в условиях продуктовой трансформации.
Кроме того, самостоятельное позиционирование цифровой платформы в ИТ-ландшафте в виде
отдельной информационной системы предполагает и наличие отдельных команд по развитию
указанного направления. А мы уже неоднократно по ходу наших книг поднимали вопрос о том,
что грань между платформенными и продуктовыми командами должна стираться, платформа
должна быть прозрачной для продуктовых команд. Одним из важных шагов на данном пути
к прозрачности и является отсутствие обособления платформы в формате отдельной системы.
Отсутствие замкнутости, отмеченное в качестве обязательного свойства современных платформ, означает, что платформа постоянно развивается, учитывает технологические
новинки, технологии проходят апробацию и немедленно внедряются в структуру платформы
организации. Таким образом достигается технологическая адекватность платформы реалиям
современности. Поскольку мы уже неоднократно подчеркивали крайне высокую скорость как
развития, так и устаревания технологий, то и платформа должна быть адекватна указанным
233

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

изменениям. В противном случае она быстро станет тормозом прогресса и инноваций, а организация вследствие этого утратит конкурентоспособность. По ходу настоящей книги мы уже
неоднократно приводили примеры расширения платформенных возможностей. При этом надо
понимать, что указанное расширение может происходить не только вследствие появления
новых продуктовых требований, но и ввиду архитектурного и технологического развития. Продуктовое и технологическое развитие должны уравновешивать друг друга, при этом лица, принимающие решения в компании, должны отдавать себе отчет в том, что одного из указанных
вариантов развития без другого не существует.
Если предположить, что для платформы обеспечивается только архитектурно-технологическое развитие, то в таком случае платформа может стать в организации черной дырой,
поглощающей огромное количество средств, но дающей весьма незначительный результат
в части сокращения ресурсных затрат на создание продуктов. При таком развитии событий
компания становится заложницей собственной платформы, что недопустимо, ведь развиваться
в первую очередь должен бизнес, в цифровом мире – цифровой бизнес. А цифровой бизнес
реализуется посредством предоставления цифровых продуктов. Архитектурные и технологические новинки современности появляются не просто так. Их появление, развитие и внедрение основано либо на требованиях рынка (принципиально новые показатели производительности и надежности, значение time-to-market и т. д.), либо на необходимости создания новых
рынков, что является критически важным условием продолжения развития при исчерпании
рынков традиционных. Отметим, что сам рынок информационных технологий в свое время
стал именно таким новым рынком.
С другой стороны, развитие платформы, продиктованное исключительно продуктовыми
требованиями, является крайне ограниченным и также зачастую не учитывает рыночные тенденции. Автору этих строк пришлось столкнуться с ситуацией, когда целый сегмент бизнеса крупной организации автоматизировался с использованием ключевой информационной
системы, созданной около 15 лет назад и которая впоследствии развивалась исключительно
в соответствии с продуктовыми требованиями. Если сказать, что это представляло собой тяжелое зрелище, то это означает не сказать ничего. Продукты создавались по полгода и более, при
этом в системе были намертво закреплены продукты, уже по несколько лет не предоставлявшиеся компанией, производительность была крайне невысокой – единственным способом ее
повысить уже довольно давно считалось исключительно добавление новых инфраструктурных
мощностей, что, впрочем, закономерно не приводило в сложившейся ситуации к значимым
улучшениям. Как тут не вспомнить знаменитую фразу, ставшую символом современного технологического развития: «Автоматизация эффективной функции повышает эффективность,
автоматизация неэффективной функции повышает неэффективность». Все это стало результатом практически полного отсутствия технологического развития: фактически только обновлялись версии программного фреймворка реализации. Справедливости ради необходимо
отметить, что компания успешно изменила мышление и провела продуктовую трансформацию данного сегмента бизнеса с соответствующей продуктовой переработкой ИТ-ландшафта.
Результаты получились потрясающими. Достаточно сказать, что time-to-market с полугода
и более сократился до 2—4 недель.
Резюмируя вышеизложенное, подчеркнем, что организации крайне важно найти баланс
между продуктовым и технологическим развитием платформы. Причем под продуктовым развитием мы понимаем не включение продуктов в платформу, а развитие последней в соответствии с продуктовыми требованиями. Таким образом организация обеспечивает собственную
конкурентоспособность.
Учитывая вышеизложенные свойства платформ, а также позиционирование платформы
относительно приложений в ИТ-ландшафте организации, мы можем сформулировать перечень
преимуществ, которые платформа предоставляет цифровым продуктам:
234

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Архитектурная и методологическая унификация. Платформа предоставляет инструкции по собственному использованию. Мы уже отмечали, что подобные инструкции являются
обязательной частью платформы. Фактически платформа определяет принципиальную структуру платформенного приложения, которое сможет эффективно использовать платформенное
решение, при этом жизненный цикл такого приложения будет максимально эффективно автоматизирован. В приведенных по ходу книги примерах мы рассматривали унифицированную
продуктовую структуру, представляющую набор типовых уровней автоматизации. Разумеется,
конкретная канальная логика или бизнес-процессы являются специфичными для каждого продукта, но их архитектурная и технологическая организация унифицированы вследствие применения общего платформенного подхода. Методология разработки аналогичным образом унифицируется, что снижает затраты трудовых, временных и финансовых ресурсов, в том числе
на реализацию специфичной продуктовой логики. Происходит сокращение затрат на планирование технологической организации платформенного приложения, его проектирование, также
снижается сложность реализации прикладной продуктовой логики.
• Снижение затрат на выполнение общих инфраструктурных функций. Поскольку платформа берет на себя унифицированное выполнение инфраструктурных функций, то разработчики платформенных приложений (цифровых продуктов) освобождаются от необходимости
самостоятельно реализовывать указанный функционал. Сокращение трудозатрат на создание
приложений на сегодняшний день составляет в этом контексте 30—40%. Мы приводим интегральный показатель, поскольку влияние каждого платформенного сервиса является дифференцированным, и наблюдается больший разброс в оценках в ту или другую сторону.
• Бесшовная интеграция. Создание архитектурно и технологически унифицированных
продуктовых ИТ-решений в формате платформенных приложений позволяет существенно
снизить затраты на их интеграцию между собой и в идеале сделать ее бесшовной. Даже при
низкой связности платформенных приложений в ИТ-ландшафте организации необходимость
интеграции в ряде случаев присутствует и остается трудоемкой задачей. Особенно это актуально при обеспечении сквозных процессов в масштабах компании. Платформенная унификация позволяет на порядки снизить затраты на интеграцию приложений и улучшить P&L продуктов.
• Возможность быстрого развития продуктовой экосистемы. Методологическая, архитектурная и технологическая унификация вкупе с поддержкой механизма открытых API позволяет сформировать прозрачные и выполнимые требования к партнерским приложениям, что
ускоряет создание экосистемы на основании цифровых продуктов компании. Развитие экосистемы является важной составляющей конкурентоспособности компании, и платформа становится в данном направлении незаменимым помощником.
Но есть и еще одно важное преимущество применения платформенного подхода, которое
необходимо обсудить отдельно, – платформа ограничивает рост энтропии как в ИТ-ландшафте
организации, так и в каждом продукте.
Как известно, любая медаль имеет свою обратную сторону. И обратной стороной ключевых тенденций развития архитектуры может считаться рост энтропии. Почему так происходит?
Краткое объяснение оказывается очень простым: все отмеченные ранее ключевые и связанные тенденции развития архитектуры дают свободу командам разработки, увеличивают пространство решений, которые могут принимать члены команд. Но бесконтрольное увеличение
пространства решений ведет к лавинообразному нарастанию хаоса, энтропии. Рассмотрим это
подробнее.
Мы неоднократно отмечали, что использование решений с открытым исходным кодом
позволяет принципиально повысить производительность труда при создании цифровых про235

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

дуктов. В основе повышения производительности труда лежит увеличение длины цепочки разделения труда – закрытые проприетарные решения не могут обеспечить вовлечение сопоставимого числа специалистов в создание программных продуктов. ПО с открытым исходным кодом
предоставляет значительное число работоспособных топологий и вариантов использования,
оставляя далеко в кильватере закрытые vendor-lock решения. Но при этом ответственность
за выбор тех или иных решений, топологий, вариантов использования ложится на пользователей, которыми являются команды разработки. И в общем случае количество различных вариантов использования даже одной и той же технологии может оказаться равным числу команд
разработки. Может оказаться и большим, в случае если свободой технологического выбора
в условиях конкретной команды обладает каждый член продуктовой команды. Добавим также,
что экосистема программных продуктов с открытым исходным кодом чрезвычайно обширна.
Мы уже разбирали примеры выбора различных альтернативных технологий для решения аналогичных задач разными командами разработки. При всей гибкости подобного выбора совокупная стоимость владения создаваемыми в таком случае продуктами значительно возрастает,
что должна учитывать компания как при составлении финансовой модели продуктовой и платформенной разработки, так и в ходе последующей реализации продуктов и предоставлении их
клиентам и партнерам.
Поддержка распределенности, как мы отмечали, актуальна в двух смысловых плоскостях: организационной и технологической. Организационная распределенность предполагает
как возможность создания и развития цифрового продукта множеством команд, которые могут
располагаться по всей стране или даже по всему земному шару, так и распределенность каждой
конкретной команды разработки, члены которой могут принимать участие в работе над продуктом из любой географической точки (главное, чтобы она была в адекватной коммуникационной доступности). Но подобная распределенность, предоставляя свободу формирования
команд и привлечения самых разных компетенций, содержит и подводные камни: сложности
коммуникации увеличивают потенциальный хаос в создаваемом решении. Не случайно на заре
внедрения гибких практик предполагалось, что Agile команда сидит в одной комнате для вдумчивой и согласованной работы над продуктом. Но в реалиях крупных компаний и сложнейших
продуктов подобный подход невозможен. Если и попытаться догматически его воспроизвести, он серьезно увеличит сроки и стоимость создания цифровых продуктов. Распределенные
команды же являются потенциальным источником хаоса. Распределенность технологическая
позволяет формировать ИТ-решения из большого количества слабо связанных распределенных компонентов. Такие решения удобно развивать и масштабировать. Но каждый компонент
обладает собственным жизненным циклом. И в этой ситуации их независимое создание и развитие также является потенциальным источником роста энтропии.
Управление бизнес-процессами в современной архитектуре аналогично содержит достаточно оснований для роста энтропии. Сложнейшие процессы жизненного цикла цифровых
продуктов становятся базой для сложных бизнес-процессов, поскольку в рамках продуктового
рефакторинга бизнес-процессы организации, как мы отмечали ранее, должны быть основаны
на процессах жизненного цикла предоставляемых компанией продуктов. Технический рефакторинг бизнес-процессов предполагает гибкую работу с контекстом, выделение локальных
транзакций в составе глобальных, определение правил сохранения состояния при исполнении
экземпляров бизнес-процессов и многое другое. Нельзя забывать про шаблоны оркестровки
и хореографии при управлении бизнес-процессами: команды разработки должны осуществлять выбор актуального для каждого бизнес-процесса шаблона, а также при необходимости
проектировать их комбинацию. Например, управление глобальным процессом в парадигме
хореографии, а локальными в его составе в соответствии с шаблоном оркестровки. Распределенные команды могут иметь принципиально разный взгляд на организацию бизнес-процессов, что приведет к значительному разнообразию при автоматизации бизнес-процессов
236

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

компании. Отметим, что подобное разнообразие весьма прискорбно сказывается как на непрерывности деятельности компании, так и на совокупной стоимости владения подобным ИТландшафтом. То есть повышается вероятность крайне негативного влияния на P&L продуктов. И связано указанное влияние с ростом энтропии при автоматизации бизнес-процессов.
Новая парадигма работы с данными также становится потенциальным источником роста
энтропии в ИТ-ландшафте компании. Напомним, что в современной архитектуре хорошим
тоном при работе с данными стало использование концепции «сетки данных» Data Mesh, при
которой узлы упомянутой сетки могут развиваться максимально независимо друг от друга.
Кроме того, мы уже отмечали ранее, что продукт данных имеет свой собственный жизненный
цикл. Жизненный цикл продукта данных в общем случае отличается от жизненного цикла
ассоциированного с ним продукта компании. То есть на сложность процессов жизненного
цикла продуктов компании накладывается сложность жизненных циклов продуктов данных,
разработанных в ходе процесса цифровизации. ИТ-решения, ранее носившие общекорпоративный характер, в современной архитектурной парадигме стали цифровыми продуктами – мы
уже приводили примеры продуктов MDM и DWH по ходу настоящей книги. При этом при рассмотрении указанных примеров мы подчеркивали, что продукты следуют всем современным
архитектурным практикам, в том числе распределенности. То есть задачи по работе с данными
решают распределенные команды, а сами продукты являются технологически распределенными. Подобная архитектура предоставляет широкие возможности для развития компании,
но и создает серьезные риски роста энтропии, что в свою очередь может негативно повлиять
на P&L всех цифровых продуктов, предоставляемых компанией.
Искусственный интеллект, хоть и является самой молодой из ключевых тенденций развития архитектуры, уже успел создать немало хаоса как самим фактом появления новых решений, основанных на данной концепции, так и перспективами дальнейшего взрывообразного
роста применения указанного класса технологий. Сегодняшние модели удивляют результатами своего самообучения даже собственных создателей. Многие компании создают этический
кодекс искусственного интеллекта, пытаясь ограничить его развитие. Но пока вместо ограничений растет, не побоимся этого слова, хаос результатов. Допускаем, что вдумчивая систематизация и структуризация работы ИИ еще впереди, но на сегодня внедрение решений подобного класса является безусловным источником роста энтропии в деятельности организации
и в конкретных продуктах, предоставляемых ею.
Источником для потенциального роста энтропии являются и рассмотренные нами ранее
связанные тенденции развития архитектуры. Эластичное масштабирование требует различных алгоритмов для различных технологий. Рост числа алгоритмов управления масштабированием, а также динамическое изменение количества компонентов в ИТ-ландшафте (зачастую
весьма значительное) приводят и к потенциальному росту хаоса. Аналогичным образом применение бессерверных технологий и концепции микрофронтендов также имеют одним из результатов взрывной рост числа исполняемых компонентов. Динамическое управление инфраструктурой, обеспечиваемое облачными технологиями, дополняет картину.
Какой же выход из этой ситуации? Неужели нужно отказаться от следования ключевым трендам развития архитектуры, чтобы сохранить упорядоченность в ИТ-ландшафте организации? Но как тогда создавать конкурентоспособные продукты, которые будут востребованы рынком и на которых зиждется успех всей компании? Приведем некоторую аналогию.
В замечательном философском фильме «Обитель проклятых» (Stonehearst Asylum, 2014)
жестким и безжалостным методам главного врача психиатрической лечебницы Бенджамена
Солта противопоставляется анархическая демократия предводителя восставших и захвативших власть в больнице пациентов Сайлеса Лэмба, блестяще сыгранного сэром Беном Кингсли
(Ben Kingsley). События фильма показывают, что методы первого не приводят к улучшению
состояния пациентов, провоцируют бунт. Но и анархическая демократия лишь приводит к раз237

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

валу работавшего механизма лечебницы, ставит врачей и пациентов на грань гибели. Выход
находят персонажи Джима Стёрджесса (Jim Sturgess) и Кейт Бекинсейл (Kate Beckinsale),
которые, исходя из сюжета, излечиваются в ходе фильма. Им удалось найти сложный путь
между двумя крайностями. И такой же путь необходимо найти в ходе цифровизации и продуктовой трансформации, ведь мы не можем пойти на сознательное снижение эффективности. А именно снижение эффективности и утрата рыночной конкурентоспособности станут
следствием отказа от следования современным трендам развития архитектуры. И выход этот
заключается в применении платформенного подхода.
Современная платформа упорядочивает технологический стек, применяемый в организации, при этом сопоставляет технологиям рекомендуемые топологии и варианты использования. В состав платформы должны входить методики использования платформенных сервисов и компонентов, то есть в том числе и технологий, входящих в их состав. Команды
могут использовать множество вариаций, предоставляемых платформой. Они могут и развивать платформу, добавляя новые технологии, топологии и варианты использования. Аналогичным образом платформенные сервисы, компоненты и рекомендации, предоставляемые платформенным решением, задают направляющие для создания распределенных платформенных
приложений, а также для работы распределенных команд над продуктами компании. Управление бизнес-процессами аналогично регламентируется платформой с сохранением свободы
творчества для продуктовых команд. В приведенных ранее примерах мы рассматривали платформенные сервисы управления бизнес-процессами и подчеркивали вариативность их применения. Работа с данными в рамках современных платформенных решений занимает наиважнейшее место, позволяя вести как транзакционную, так и аналитическую работу, используя
в том числе технологии больших данных. Поэтому конкурентоспособная платформа должна
предоставлять сервисы работы с данными, обеспечивая весь спектр потенциальных вариантов использования и ограничивая рост энтропии. То же самое касается и искусственного
интеллекта – платформа должна стать базисом его гармоничного внедрения в организации.
Поддержка платформой связанных тенденций развития архитектуры даже не должна обсуждаться – в современных условиях именно платформенное решение позволяет стандартизировать применение соответствующих технологий.
Подробное описание платформенных решений как средства противодействия росту
энтропии приведено в разделе «Платформы и энтропия» нашей предыдущей книги «Архитектура цифровых платформ. От настоящего к будущему».
Таким образом, мы можем констатировать, что современная цифровая платформа является важным ограничителем хаоса в ИТ-ландшафте. Она позволяет следовать ключевым трендам развития архитектуры, при этом снижает риски возрастания энтропии, которые возникают
как сопутствующее следствие данных трендов. Тем самым оказывается положительное влияние на P&L цифровых продуктов, предоставляемых организацией клиентам и партнерам.
Подводя итог настоящему разделу, отметим, что применение платформенного подхода
позволяет:
• Снизить расходы компании на создание цифровых продуктов.
• Уменьшить расходы на выполнение инфраструктурных и типовых операций в ИТ-ландшафте компании.
• Обеспечить бесшовную интеграцию приложений между собой и поддержать эффективное кросс-продуктовое взаимодействие.
• Сдержать рост энтропии, вероятность которого в современном ИТ-ландшафте возрастает.

238

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

При этом нельзя считать само по себе применение платформенного подхода серебряной
пулей, автоматически позволяющей достичь указанных положительных эффектов. Платформенное решение должно органично соответствовать тем требованиям, которые предъявляются
к ИТ-ландшафту компании. А требования следуют из ИТ-стратегии, утвержденной в организации. То есть платформа определяется на основе ИТ-стратегии. Данный тезис, к которому
мы логически пришли, означает, что принципиально неверно в современном цифровом мире
говорить о готовой платформе, априори применимой для цифровизации деятельности компании. Любая платформа нуждается в адаптации. При этом возможны различные варианты
создания платформенного решения:
• Реализация цифровой платформы с чистого листа. Данный подход предполагает, что
создание цифровых продуктов компании возможно только при определенной готовности платформенного решения. И для достижения лучших показателей P&L архитектор должен сформировать тот необходимый объем платформенных сервисов и компонентов, по итогам реализации которого становится возможным создание платформенных приложений. С одной стороны,
указанный объем (ядро платформы) должен позволять продуктовым командам воспользоваться преимуществами платформенного подхода, с другой стороны, он не должен требовать
значительных временных затрат на свое создание, дабы организация могла путем вывода цифровых продуктов на рынок как можно скорее перейти к окупаемости инвестиций. И решение
архитектора в данном случае имеет очень большую ценность.
• Использование рыночного платформенного решения с адаптацией его под соответствие
требованиям ИТ-стратегии. Подобный подход обычно позволяет снизить сроки готовности
платформенного решения для создания полноценных цифровых сервисов. Но при этом он
гораздо более требовательный с точки зрения лицензионных платежей – компания использует внешний программный комплекс. Но главное в другом. Компания в данном случае рискует лишиться свободы маневра в развитии используемой платформы и попасть в зависимость
от поставщика платформенного решения. Вендор может диктовать применение тех или иных
технологий, искусственно ограничивать топологическое разнообразие и те или иные варианты
использования. Компании при выборе данного варианта имеет смысл прорабатывать корпоративное соглашение, позволяющее самостоятельно развивать платформу и фактически поддерживать ее fork с возможными commit’ами в upstream, если она желает сохранить свободу
развития в быстро меняющемся цифровом мире.
• Использование готового платформенного решения для создания цифровых продуктов.
Фактически в этом случае компания делегирует вопросы технологического развития стороннему игроку, поставляющему цифровую платформу. Мы можем констатировать, что, делая
подобный выбор, компания игнорирует современные тенденции развития архитектуры. Она
вынуждена ждать реализации доработок платформы тот временной период, который определяется вендором. Более того, доработки нередко принимают формат, который с точки зрения поставщика обеспечит его предложению лучшую рыночную востребованность, но далеко
не всегда соответствует требованиям компании, не обеспечивает ее конкурентоспособность.
Но поскольку мы по ходу всех наших книг декларировали необходимость свободы выбора, то
мы обязаны упомянуть и данный вариант.
По ходу настоящего раздела мы продемонстрировали те преимущества, которые применение платформенного подхода несет цифровым продуктам и компании в целом. Также
мы отметили варианты внедрения платформенных решений в организации с указанием возможностей и ограничений каждого из них. Архитектор, являясь лидером технологических
изменений, обязан принимать активнейшее участие в выборе целевого варианта внедрения
239

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

240

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Открытость цифровых платформ
в продуктовой методологии
Ранее мы продекларировали, что открытость платформ является столь важным их свойством, что заслуживает отдельного рассмотрения. Если по ходу предыдущего раздела мы рассмотрели влияние остальных ключевых свойств современных цифровых платформ на создание конкурентоспособных цифровых продуктов, то текущий раздел посвятим именно свойству
открытости. Разберем более детально, почему именно данное свойство несет особое значение
для процесса создания ценности.
Мы неоднократно обращали внимание читателя на то, что одной из ключевых тенденций развития архитектуры является использование решений с открытым исходным кодом.
Причем оно может присутствовать и неявным образом, когда вроде бы проприетарные решения включают в свой состав немало открытых технологий. И в этой связи конкурентоспособные платформы сами должны поддерживать свойство открытости. Подчеркнем, что, рассуждая о конкурентоспособности, мы говорим не о лицензионных отчислениях. Если учитывать
в рассуждениях только подобный тип платежей и сводить к ним конкурентоспособность технологического решения, то можно с уверенностью в собственной правоте заявить, например,
что в части конкурентоспособности продукция семейства IBM WebSphere оставила позади
абсолютное большинство конкурентов, в том числе занимающую аналогичную нишу рынка
продукцию компании RedHat. Реальность, однако, иная, что и нашло свое подтверждение, как
в структуре корпоративных сделок и последовавших за ними организационных изменениях,
так и в развитии и позиционировании программных продуктов.
Конкурентоспособность современной платформы во многом определяется способностью
создать вокруг нее экосистему приложений и партнеров. Партнеры используют платформенное
решение для создания собственных приложений и их продвижения на рынке. Клиенты же платформы применяют ее для создания собственных приложений и предоставления на их основе
ценности собственным клиентам и партнерам, обеспечивая дальнейшее расширение платформенной экосистемы. В контексте данного рассмотрения не так важно, по какому пути следует
компания:
• Создание собственной платформы. В таком случае платформа должна быть открытой
для всех продуктовых команд компании. Также желательной является коллаборация с партнерами, позволяющая развивать платформенное решение совместно по принципам открытости.
• Использование платформы технологического партнера. Каким бы высоким ни был
уровень зрелости применяемого платформенного решения, но в случае, если его создатель
находится вне контура организации, то платформа должна быть адаптирована к применению
в компании. И одним из факторов адаптируемости и является создание открытой среды коллаборации. Платформа должна развиваться в соответствии с принципами открытости. Желательным является открытое взаимодействие всех компаний, применяющих подобную платформу.
Что же понимается под открытым развитием цифровой платформы? Фактически платформа должна следовать принципам открытого кода, даже если с юридической точки зрения открытость будет ограничена корпоративными рамками: современная компания должна
учитывать необходимость постоянного расширения. То есть платформа не является для
своих клиентов, а под клиентами в данном случае подразумеваются платформенные приложения, «черным ящиком». Если развитие платформы предполагает, что продуктовая команда,
столкнувшись с нехваткой того или иного платформенного функционала либо некорректным
с точки зрения продуктового контекста выполнением платформенных функций, создает запрос
241

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

на изменение платформы, после чего некая платформенная команда будет в соответствии
с собственным бэклогом отрабатывать указанный запрос на изменение, то платформа не может
считаться открытой. Поясним это на примере.
Предположим, что в организации работают десять продуктовых команд, при этом используется общее платформенное решение, покрывающее все архитектурные уровни продуктовой
автоматизации. Одновременно с этим в организации присутствует платформенная команда,
которая отвечает за развитие применяемой цифровой платформы и отработку соответствующих запросов на изменения, поступающих от продуктовых команд. Резонно предположить,
что масштабирование платформенной команды ограничено по сравнению с продуктовыми,
поскольку данная команда не создает непосредственной ценности. Ценность создается продуктовыми командами, а затраты на платформенную команду фактически учитываются в P&L
всех цифровых продуктов компании. Поэтому емкость платформенной команды с точки зрения выполнения задач является ограниченной. Исходя из этого, вполне возможна следующая ситуация. Предположим, для ровного счета, что в течение месяца каждая продуктовая
команда выявляет десять несоответствий в части платформенного функционала, требующих
доработки для обеспечения продуктового развития. Выявляемые несоответствия необходимым образом оформляются и помещаются в бэклог платформенной команды. А платформенная команда может реализовать десять дополнений в платформу в течение месяца. Мы специально для наглядности рассматриваем максимально простой пример. В таком случае в течение
месяца у компании в целом накапливается технический долг (а платформенные доработки –
это именно технический долг) в девяносто задач. При этом дополнительные затраты временных ресурсов происходят при расстановке приоритетов доработок, которые носят динамический характер – напомним, что доработки относятся к разным продуктам. Получается,
что продуктовые команды могут ожидать требуемых им доработок месяцы, а в иных случаях
и годы, если приоритеты изменятся негативным для них образом.
Фактически в приведенном примере платформа представляет собой корпоративную
интеграционную шину нового поколения, которая в теории должна упрощать реализацию
приложений, но в реальности лишь усложняет ее, вынуждая продуктовые команды искать
обходные пути реализации ценности. Результатом закономерно становится неуправляемый
архитектурный и технологический «зоопарк» продуктовых ИТ-решений, что неминуемо ухудшает P&L продуктов и увеличивает совокупную стоимость владения (TCO) ИТ-ландшафтом. Возможным является и еще одно негативное следствие подобной организации работ.
Продуктовые команды могут начать «дополнять» платформу, включая в ее состав доработки,
архитектурно и технологически являющиеся инородными элементами, либо создавать платформенную «обвязку», представляющую собой набор дополнительных модулей и компонентов, именуемых на ИТ жаргоне «костылями». Подобные дополнения становятся головной
болью компании в процессе управления конфигурациями: в ходе релизных циклов необходимо поддерживать целостность дополнений, что возможно обеспечить далеко не всегда при
выходе новых версий как платформенных, так и продуктовых ИТ-решений. В результате страдает надежность ИТ-ландшафта организации и непрерывность бизнеса.

242

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 65. Совместная работа продуктовых команд
с использованием открытой платформы
В приведенном примере платформа фактически является закрытой для продуктовых
команд и теряет многие преимущества платформенного подхода. Особенно критичен вариант, когда платформа предоставляется внешним с точки зрения организации технологическим партнером – компания становится заложником «партнера» (кавычки в данном случае
совсем не лишние). И «партнер» может диктовать стратегию продуктового развития компании
и принципиально влиять на ее бизнес-показатели. Стратегия организации становится зависимой от развития внешнего технологического решения, что крайне негативно влияет на конкурентоспособность на современном динамичном рынке.
Ответом на подобный негативный сценарий развития событий является использование открытой платформы. Платформа должна быть прозрачной для всех команд, которые ее
используют: в идеале не только команд организации, но и партнерских. Выявляя недостатки
платформенного решения, продуктовые команды фиксируют их, добавляют в собственный бэклог и самостоятельно устраняют. При этом публикация дополнений в платформу
должна осуществляться таким образом, чтобы вносимые изменения становились доступными
для всех смежных продуктовых команд. Схематично данный подход показан на Рисунке 65.
Для сохранения удобства восприятия в примере, проиллюстрированном Рисунком 65,
предполагается, что в организации создаются два продукта, каждый из которых реализуется собственной продуктовой командой. При создании и развитии продуктовых ИТ-решений применяется платформенный подход, что выражается в стандартизированной архитектуре
и использовании продуктами платформенных сервисов. На Рисунке 65 схематично показано
задействование платформы компании в продуктовой разработке и предоставление платфор243

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

мой необходимых продуктам сервисов. При этом обе команды, выявляя недостатки в платформенном решении, вносят дополнения в платформу. Использование платформы, ее доработки
и развитие осуществляются параллельно в непрерывном жизненном цикле. Таким образом
достигается как исключение простоев в командной работе в ожидании доработок платформы,
так и минимизируется риск создания «костылей», позволяющих временно избежать недостатков текущей реализации платформы. При подобной организации работы необходимо соблюдение ряда условий:
• Платформа должна предоставлять руководство по собственному расширению, делающее возможным ведение совестных доработок командами и общедоступную публикацию вносимых изменений. Указанное руководство может носить не только методологический, но и технологический характер, имеющий, например, стандартизированный формат платформенных
расширений. Примером организации параллельной работы и интенсивного развития, учитывающего множество вносимых доработок, могут выступать популярные решения с открытым
исходным кодом.
• Платформа должна поддерживать механизм версионности сервисов и компонентов. Должна быть исключена необходимость повторной сборки платформенных приложений при выходе новых версий платформенных компонентов. Глубина поддержки версионности должна определяться потребностями продуктов, технологическими возможностями
платформы и финансовой моделью организации.
• Платформа должна предоставлять релизные модели, учитывающие параллелизм развития как самой платформы, так и платформенных приложений.
Только платформа, удовлетворяющая вышеприведенным условиям, может претендовать
на право называться открытой.
«Здесь было сказано очень много красивых слов, но как обеспечить открытость на уровне
архитектуры?» – не удержится от каверзного вопроса внимательный читатель. Мы удовлетворим его любопытство и рассмотрим соответствующий пример.
Мы сразу оговоримся, что приводимый нами пример является весьма простым и призван наглядно продемонстрировать использование свойства открытости платформы продуктовыми командами. Реальные кейсы оказываются гораздо более сложными. Также отметим, что
мы приводим в примере далеко не единственный вариант открытой расширяемой платформы.
Схематично пример архитектурных зависимостей приведен на Рисунке 66.

244

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 66. Расширение открытой платформы
продуктовыми командами
На иллюстрации приведен вариант связи одного из составляющих продуктовое ИТ-решение микросервисов (отмечен как «Микросервис прикладной продуктовой логики») с плат245

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

форменными сервисами. Напомним читателю, что в наших примерах мы предполагаем, что
при реализации цифровых продуктов применяется парадигма микросервисной архитектуры.
Также подчеркнем, что приведенный на Рисунке 66 характер связей является примером,
а не догмой, а имеющиеся на связях пояснения носят в первую очередь концептуальный характер, помогающий обеспечить наглядность восприятия.
Цифровой продукт автоматизируется посредством платформенного приложения, состоящего из компонентов. Различные компоненты приложения отвечают за фронтальную и канальную логику, прикладную продуктовую логику, логику управления бизнес-процессами, а также
логику оперативного и архивного хранения. Мы приводим на Рисунке 66 структуризацию
приложения, отвечающую приведенным ранее в настоящей книге архитектурным уровням
цифрового продукта. Компоненты приложения реализуются в различном формате: логики,
инфраструктурных компонентов, инструкций по развертыванию и управлению и т. д. Сборка
приложения и включение в его состав тех или иных компонентов осуществляется в соответствии со спроектированной архитектурой конкретного платформенного приложения. В нашем
примере приведен вариант компонента прикладной продуктовой логики, реализованного
в формате микросервиса. Микросервис является исполняемым компонентом, что принципиально влияет на его структуру. В представленном на Рисунке 66 примере структура микросервиса содержит несколько составляющих:
• Непосредственно продуктовая логика, реализованная с использованием выбранных
технологий программирования, например, Java.
• Зависимости от используемых платформенных модулей (будут детализированы ниже)
и компонентов. Отметим, что использование платформенных модулей и компонентов осуществляется посредством платформенного SDK, что отражено на иллюстрации. Подобный
способ использования предполагает включение требуемых зависимостей в инструкции сборки
микросервиса.
• Набор инфраструктурных библиотек, требуемых для эффективного функционирования микросервиса во время выполнения. Примерами могут быть включения технологий,
используемых в основе реализации тех или иных платформенных сервисов.
• Среда исполнения, обеспечивающая корректное функционирование микросервиса.
Примерами могут выступать Tomcat, Undertow, Netty и т. д.
При этом в состав исполняемого микросервиса входит ряд важных служебных объектов,
которые резонно назвать контекстом исполнения. Поскольку данные объекты характеризуют
именно исполнение микросервиса, то они также должны быть исполняемыми, а потому отмечены на Рисунке 66 в формате модуля. Контекст исполнения содержит набор событий жизненного цикла микросервиса. Это могут быть как инфраструктурные и служебные события,
так и события бизнес-характера. Также в состав контекста исполнения входит состояние микросервиса. Фактически, если поставить задачу визуализировать контекст исполнения, то мы
получим диаграмму состояний микросервиса, характеризующую состояния жизненного цикла
и потенциальные переходы между ними при генерации событий. Отметим, что каждый экземпляр микросервиса обладает и собственным экземпляром контекста.
Когда мы говорим об использовании платформенного подхода при реализации микросервисов, то мы автоматически понимаем, что сервисы и компоненты платформы допускают
инстанциирование, то есть овеществление. Указанное овеществление не является противоречием с рассмотренным ранее свойством современных платформ: платформа не является
информационной системой. В нашем примере происходит овеществление компонентов и сервисов, но не платформы в целом, кроме того, инстанциирование происходит строго в контексте
реализации, сборки и исполнения компонентов продуктового ИТ-решения. То есть на основе
246

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

платформенных сервисов и компонентов создаются платформенные модули, используемые
компонентами платформенного приложения посредством платформенного SDK. В примере,
приведенном на Рисунке 66, указан один платформенный модуль, созданный на основе одного
платформенного сервиса. Но в реальных случаях, с которыми в ходе практической деятельности столкнется внимательный читатель, возможны самые разные связи приложений, модулей
и платформенных сервисов. Архитектор должен внимательно следить за тем, чтобы соответствующая организация сборки исполняемых компонентов следовала ключевым трендам развития архитектуры. При этом особое внимание необходимо уделить тенденции распределенности.
Платформенный модуль содержит в своем составе:
• Реализацию платформенного сервиса, предоставляемую компоненту платформенного
приложения с учетом требуемых топологий и доступных вариантов использования.
• Контекст исполнения, во многом аналогичный контексту исполнения микросервиса,
но содержащий собственные состояния жизненного цикла и события перехода, основанные
на жизненном цикле платформенного сервиса и актуальных топологиях и вариантах использования.
• Реализацию вспомогательных платформенных компонентов. Последние могут не входить в состав платформенного сервиса, указанного выше, но их совместное использование
с реализацией платформенного сервиса может потребоваться в соответствии с жизненным циклом потребителя – компонента платформенного приложения (микросервиса).
• Версионирование. Сюда входит информация о доступных для использования потребителями версиях модуля, а также политика версионирования, применяемая при возникновении
потребностей в обновлении модуля и создании новых версий, а также при потенциальном совместном использовании последних.
• Набор используемых расширений, предполагающих специфические дополнения
в состав модуля.
Платформенный сервис содержит в своем составе:
• Собственно платформенную логику. Мы уже неоднократно по ходу настоящей книги
рассматривали вопросы реализации технологической логики общего характера в формате
выделенных платформенных сервисов. Подобный подход позволяет значительно сократить
затраты на создание цифровых продуктов. И в настоящем примере, схематично представленном на Рисунке 66, показано, что платформенная логика реализуется в формате платформенного сервиса, инкапсулированного в исполняемый платформенный модуль. При этом платформенная логика тесно связана с технологическими решениями, выбранными для обеспечения
инфраструктурных задач. Например, с реализацией событийного обмена в журнальной парадигме с применением программного обеспечения Apache Kafka. Напомним читателю, что возможны различные технологические реализации платформенных сервисов.
• Логику связей с другими платформенными сервисами. Мы уже неоднократно подчеркивали, что решение ряда задач возможно посредством использования нескольких платформенных сервисов. Например, управление бизнес-процессами предполагает, что мы используем
соответствующие платформенные сервисы. В приведенных ранее по ходу настоящей книги
примерах мы показывали, что платформенный сервис управления бизнес-процессами объединяет управление ими в соответствии с обоими распространенными шаблонами – оркестровки и хореографии. При этом большинство современных популярных движков управления
бизнес-процессами, которые могут использоваться в качестве технологической реализации
соответствующего платформенного сервиса, задействуют при хранении контекста процесса
реляционную базу данных. При наличии высоких требований в части производительности
247

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

248

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Расширения платформенного модуля и расширения платформенного сервиса принципиально отличны друг от друга. Если расширения платформенного сервиса представляют собой
инструментарий развития платформы в соответствии с принципами открытости, то расширения платформенного модуля содержат специфику времени выполнения. Указанная специфика актуальна в первую очередь для конкретного компонента и значительно реже может быть
повторно использована по сравнению с расширениями платформенных сервисов, которые публикуются открытыми для экосистемы платформенной и продуктовой разработки, создаваемой
компанией.
Внимательный читатель может задать очередной актуальный вопрос: «Не создает ли
подобный вариант архитектуры площадку для бесконтрольного роста числа платформенных компонентов вследствие механизмов версионности и применения расширений?» Вопрос
исключительно злободневный, поскольку поддержание каждого компонента в ИТ-ландшафте
компании исчисляется для последней в ненулевом финансовом эквиваленте. Вклад в стоимость владения компонентов вносит и трудовая, и инфраструктурная, и программная составляющая. Кроме того, рост числа компонентов сам по себе усложняет ИТ-ландшафт и повышает совокупную стоимость владения им. Ответ на этот вопрос носит несколько философский
характер: механизм открытости является инструментом развития, а корректное использование инструмента – прерогатива компании. Для исключения бесконтрольного роста количества
компонентов необходимо привлечение архитектурных и финансовых инструментов. Архитектор должен закладывать такую реализацию механизмов версионности и расширений, которая
позволит минимизировать число создаваемых и параллельно исполняемых версий. Финансовая модель компании должна обеспечивать расчет экономически обоснованного количества
компонентов в ИТ-ландшафте. Таким образом, оперируя на стыке технологических и финансовых инструментов, становится возможным гарантировать как интенсивное развитие компании,
так и ее финансовое благополучие. Отметим, что рост числа компонентов влияет на P&L цифрового продукта, автоматизируемого посредством платформенного приложения, ведь именно
приложение заинтересовано в развитии сервисов, сопряженном с расширением последних
и созданием их новых версий.
Подчеркнем, что приведенный пример является не единственным способом поддержки
свойства открытости платформ. Читатель может предложить и иные способы. Мы будем только
рады разнообразию архитектурных и технологических подходов.
Важную роль в применении свойства открытости платформы при создании цифровых
продуктов играют репозитории. Вопросы информационной безопасности имеют в современном нам мире крайне важное значение. Для исключения утечек информации и злонамеренных действий со стороны третьих лиц компании должны создавать собственные репозитории,
на уровне которых необходимо размещение и проверка дистрибутивов, сборка образов программного обеспечения, совместная работа и развитие платформенных и продуктовых решений. При этом на уровне партнерских отношений возможно создание сети доверенных репозиториев. Мы говорим об открытости, но открытость не подразумевает бездумное скачивание
образов программного обеспечения из открытых репозиториев и автоматическое использование такого ПО на стендах компании. Совсем нет. Рассуждая об открытости, мы говорим
об открытости развития. Но современный цифровой мир предъявляет крайне жесткие требования в части обеспечения безопасности и жестоко наказывает за их невыполнение. Поэтому
внутренние репозитории, в которых содержится код цифровых решений компании, должны
быть закрыты от деструктивного внешнего влияния, пусть оно в каких-то случаях может
и не носить злонамеренного характера. Подробно вопрос работы с репозиториями рассматривался нами в книге «Архитектура цифровых платформ. От настоящего к будущему».
По ходу текущего раздела мы рассмотрели свойство открытости современных и устремленных в будущее цифровых платформ, а также применение данного свойства при создании
249

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

250

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровые продукты и платформенные сервисы
Вопросы применения платформенного подхода при создании современных ИТ-решений мы рассматривали и по ходу наших предыдущих книг «Архитектура цифрового мира»
и «Архитектура цифровых платформ. От настоящего к будущему», и в рамках настоящего
изложения. Значимость этих вопросов связана с тем, что в условиях высокой конкуренции,
которая на сегодняшний день присутствует во всех рыночных сегментах, каждая компания
обязана искать способы повышения собственной конкурентоспособности. Конкурентоспособность складывается, помимо всего прочего, из повышения привлекательности продуктов компании для клиентов и партнеров и снижения затрат на их создание. Современная платформа
обеспечивает достижение второго эффекта, при этом положительно влияя на первый: продуктовые команды, которые не загружены реализацией вспомогательной инфраструктурной
логики, могут полноценно сосредоточить свои усилия на создании ценности и повышении тем
самым привлекательности развиваемых ими цифровых продуктов на рынке.
Как мы неоднократно подчеркивали, платформа берет на себя выполнение вспомогательных инфраструктурных задач, но создание непосредственной ценности для клиентов и партнеров осуществляют продуктовые команды. То есть ценность формирует строго платформенное
приложение. Почему же так происходит? Казалось бы, возможно выносить все общие задачи
на уровень платформы, а на уровне платформенного приложения реализовывать исключительно специфическую прикладную логику. Попытки создать подобные платформы предпринимались неоднократно. Но результат, как правило, оказывался весьма плачевным. Приведем
два примера, с которыми пришлось столкнуться в рамках нашей практической деятельности,
чтобы сделать наше утверждение более наглядным и убедительным.
Некая крупная компания многое поставила на сокращение затрат вследствие применения платформенного подхода. Планировалось запустить создание множества (речь шла более
чем о сотне) продуктов в параллельном режиме. Достичь успеха предполагалось за счет того,
что значительную часть трудозатрат (в кулуарах обсуждалось число в 80%) возьмет на себя
платформенное решение. Читатель наверняка понимает, что одновременное создание сотен
сложных цифровых продуктов требует привлечения огромного количества специалистов, что
влечет за собой существенные финансовые затраты. Какой бы динамики P&L продуктов ни
удалось добиться, очевидно, что понадобился бы значительный временной промежуток, чтобы
окупить подобные затраты. В современном мире столь длительная окупаемость, как правило,
является неприемлемой, поэтому пристальное внимание уделялось платформенному решению, которое перегружалось продуктовой логикой. Предполагалось, что между инфраструктурным платформенным уровнем и специфичной прикладной продуктовой логикой будет
создан слой общих прикладных компонентов, который возьмет на себя значительный объем
трудозатрат, при этом компоненты будут общими для всех или большинства продуктов компании. Для реализации подобного подхода было принято решение создать платформенные
команды, реализующие общий инфраструктурный и технологический функционал, а также
компонентные команды, которые должны были заниматься разработкой общих компонентов
и предоставлять их продуктовым решениям. За счет такого подхода планировалось существенно сократить численность продуктовых команд и повысить эффективность их работы
путем использования общих компонентов. В реальности получилось обратное:
• Бэклог компонентных команд стал постоянным объектом внимания в контексте расстановки и изменения приоритетов реализуемых задач. Потребности в численности компонентных команд непрерывно возрастали.
251

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Не владея деталями продуктовой специфики, компонентные команды создавали обобщенный функционал, который был лишь минимальным образом применим к конкретным цифровым продуктам. При поиске своих пользовательских историй в бэклогах компонентов продуктовые команды находили подходящие им лишь с точки зрения русского языка элементы.
• Объем регрессионного тестирования при развитии компонентов рос едва ли не экспоненциально. Количество зависимостей от компонентов увеличивалось, при этом характер
зависимостей усложнялся.
• И т. д.
Окончательно погребло благую идею сокращения издержек при создании продуктов
обновление платформы, повлекшее за собой пересборку всех компонентов, что отразилось
на абсолютно всех создававшихся или уже созданных продуктах компании.
Второй пример был не столь масштабным, но также привел к плачевным последствиям.
Автор этих строк был привлечен в качестве внешнего эксперта к одному крупному проекту.
Предполагалось оценить качество повторного использования платформенных сервисов. При
этом платформа так же, как и в первом из приведенных нами примеров, перегружалась продуктовой логикой. Фактически любой сервис, необходимый продукту, переводился на уровень платформы при появлении лишь подозрения на возможность повторного использования.
Предполагалось сокращение таким образом трудозатрат на создание цифровых продуктов.
Поскольку речь в данном примере идет о финансовой организации, то на уровень платформы
был вынесен «сервис выписки». Если читатель знаком со спецификой автоматизации финансовой организации, то он, уже изучив предшествующее изложение, понимает грубейшую ошибку
подобного архитектурного проектирования. Если же читателю не приходилось сталкиваться
с автоматизацией финансового сектора экономики, то кратко поясним, что выписка предоставляется клиентам практически по каждому продукту финансовой организации и учитывает
соответствующую продуктовую специфику. На тот момент в организации велся пилотный проект по применению платформенного подхода. Автор спросил лишь о том, сколько потребителей было у указанного сервиса и, получив ответ, что сорок, сделал предположение, что при
переводе платформы в постоянную эксплуатацию потребителей станет минимум сто сорок.
Надо сказать, что воображение автора несколько преуменьшило масштаб бедствия. В результате расстановка приоритетов в доработках подобного сервиса оказалась нетривиальной задачей, а ожидание продуктами требуемых им доработок – весьма длительным и непредсказуемым. Продолжение, как нам думается, излишне.
В обоих приведенных выше примерах компании, рассчитывая на сокращение трудозатрат, пришли к «божественным» объектам и высокой связности создаваемых ими ИТрешений. В результате, например, создаваемые подобным образом платформы категорически
не отвечали свойству распределенности, важность которого нами подробно рассматривалась.
Резюмируя вышеизложенное, необходимо отметить, что продуктовая специфика является
характеристикой конкретного продукта, а потому должна реализовываться в рамках платформенного приложения. Нет смысла выносить продуктовый функционал на уровень платформы,
ведь он меняется чрезвычайно динамично, и нет никакого резона выводить его из состава продуктового ИТ-решения. Платформа берет на себя выполнение общих инфраструктурных и технологических задач. Каждая из таких задач автоматизируется при помощи платформенных
сервисов и компонентов, которые задействуются платформенными приложениями при необходимости. Развитие платформенных сервисов осуществляется с учетом свойства открытости
платформ. И для обеспечения прозрачности релизных циклов платформенного решения необходимо публиковать дополнения в платформу в формате платформенных расширений таким
образом, чтобы они были доступны всем потребителям платформы – платформенным приложениям и продуктовым командам.
252

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Здесь необходимо напомнить читателю важный тезис, который мы приводили в книге
«Архитектура цифровых платформ. От настоящего к будущему». То, что платформа предоставляет сервисы, вовсе не означает ее реализацию строго в микросервисной парадигме.
Далеко не все компоненты платформы могут быть представлены в виде микросервисов и если
следовать классическому определению последних, и если исходить из здравого смысла. Потоковое программное обеспечение, базы данных, кэширующие компоненты могут считаться сервисами, хотя мы настаиваем на том, что современная платформа не может просто предоставлять то или иное программное обеспечение, но никак не микросервисами. Платформенный
сервис представляет собой сложное ИТ-решение, которое применяется платформенным приложением в соответствии с предоставляемыми им топологиями и вариантами использования.
И это гораздо больше, нежели микросервис. Если же в качестве главного преимущества платформы утверждается то, что она является микросервисной, что нередко можно встретить
на современном рынке, то это не просто не может считаться преимуществом, но и должно
вызывать серьезные подозрения: понимает ли говорящий суть современной цифровой платформы.
Для наглядности восприятия рассуждений о платформенных сервисах приведем пример проектирования одного из ключевых сервисов, предоставляемых современными платформами. Это тем более необходимо сделать, поскольку внимательный читатель задавал уже
немало вопросов по ходу настоящей книги о том, как создаются платформенные сервисы,
источниками требований к которым выступают платформенные приложения. В настоящем
примере мы рассмотрим платформенный сервис работы с журнальной потоковой передачей
информации, поскольку он активнейшим образом используется продуктовыми ИТ-решениями, примеры которых приведены в настоящей книге. Для упрощения представленного примера мы выберем одну технологическую реализацию 2.1.1 из списка платформенных сервисов, представленного на Рисунке 50. Подчеркнем, что мы рассматриваем демонстрационный
пример, а не реальный платформенный сервис.
На старте рассмотрения примера необходимо обрисовать те задачи, для решения которых
применяется платформенный сервис 2.1.1:
• Обеспечение информационного взаимодействия компонентов в парадигме событийно-ориентированной архитектуры EDA.
• Обеспечение асинхронного взаимодействия программных компонентов. Напомним
читателю, что событийное и асинхронное взаимодействие принципиально отличаются.
• Накопление событий работы партнерской экосистемы, что требует повышенных мер
безопасности решения.
• При необходимости экранирование компонентов долговременного хранения, таких как
базы данных, для обеспечения выполнения операций взаимодействия компонентов логики
приложений с указанными компонентами хранения в событийной парадигме.
• Обеспечение прогрева кэширующих компонентов.
Отметим, что в современной платформе сервисы должны осуществлять поддержку мультитенантности, что также необходимо учитывать при проектировании. Напомним, что в качестве технологической реализации платформенного сервиса 2.1.1 используется программное
обеспечение Apache Kafka.
Проектирование начнем с функционально-информационной архитектуры, которая представлена на Рисунке 67.

253

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Рисунок 67. Функционально-информационная архитектура платформенного сервиса
работы с журнальной потоковой передачей информации
Рисунок 67 иллюстрирует функционально-информационную архитектуру платформенного сервиса, акцентируя внимание на следующих аспектах данного ИТ-решения:
• Прикладные функции платформенного сервиса описывают те задачи, которые решаются рассматриваемым платформенным сервисом либо непосредственно в интересах его
потребителей, либо носят вспомогательный характер при решении задач потребителей.
• Информационные объекты, представляющие собой множества объектов данных, которыми оперирует платформенный сервис при выполнении прикладных функций.
• Прикладные процессы, которые исполняются в ходе реализации прикладных функций
по запросам потребителей либо в фоновом режиме.
Также в составе архитектуры представлены внешние по отношению к платформенному
сервису сущности:
• Сотрудник организации, осуществляющий взаимодействие с платформенным сервисом и при необходимости управление им. В зависимости от конкретной компании и набора
вариантов использования это может быть системный администратор, выполняющий служебные обязанности по управлению сервисом, бизнес-администратор, осуществляющий тонкую настройку в соответствии с потребностями платформенных приложений, администратор
информационной безопасности, отслеживающий логи событий соответствующей направленности, и т. д. Поскольку мы в настоящей книге не занимаемся проектированием платформенных сервисов для конкретной организации, то в данном примере мы вводим обобщенную роль,
254

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

которую именуем «Сотрудник». Конкретный перечень его полномочий не является принципиальным с точки зрения нашего примера.
• Платформенные приложения, которые представляют собой ИТ-решения по автоматизации цифровых продуктов компании с применением платформенного подхода. В настоящем
примере они показаны обобщенно, поскольку платформенный сервис реализует набор общих
инфраструктурных задач, связанных с асинхронным и событийным взаимодействием. Использовать данный сервис может любое платформенное приложение.
• Партнерские приложения, которые обеспечивают создание экосистемы для повышения конкурентоспособности компании. Мы уже приводили пример подобного приложения:
возможно использование внешних партнерских приложений для лидогенерации кредитных
заявок, при этом процессы обработки заявок и их скоринга реализованы внутри контура организации. Одновременно с этим создание партнерских приложений возможно с использованием платформенного подхода для обеспечения их бесшовной интеграции с продуктовым
ИТ-ландшафтом компании. Принципы реализации партнерских приложений с использованием цифровой платформы унифицированы по аналогии с платформенными приложениями
самой компании, а потому указанные компоненты партнерской экосистемы также показаны
на Рисунке 67 в обезличенном виде.
• Платформенные сервисы. Мы уже обращали внимание читателя на то, что возможны
взаимосвязи платформенных сервисов, в том числе скрытые от потребителя. Взаимодействие платформенных сервисов между собой также должно осуществляться унифицированным образом, чтобы обеспечить гибкость релизных циклов, снизить объемы регрессионного
тестирования и сократить количество ошибок, возникающих при развитии платформенного
решения.
Ключевыми прикладными процессами, характерными для рассматриваемого платформенного сервиса, являются следующие:
• Асинхронное взаимодействие. Асинхронное взаимодействие доступно для компонентов приложений с целью исключения необходимости ожидания ответа. Компоненты не блокируются и могут выполнять требуемые им операции, обрабатывая ответы по мере их готовности.
• Событийное взаимодействие. Событийное взаимодействие принципиально отличается
от асинхронного тем, что событие не является асинхронным запросом или отложенной командой на исполнение. Публикация события характеризует изменение состояния в приложении.
На события подписываются заинтересованные в нем программные компоненты, которые реализуют логику реакции на изменения состояния приложения.
Отметим, что используемое в примере программное обеспечение Apache Kafka поддерживает оба механизма работы и предоставляет соответствующий API. Потенциальная необходимость создания программных оберток связана с тем, что на уровне платформенного сервиса
2 (см. Рисунок 50) может потребоваться обобщенная работа с различными технологическими
реализациями.
Платформенный сервис реализует следующие ключевые прикладные функции:
• Платформенный SDK. Мы уже неоднократно подчеркивали важность предоставления цифровой платформой SDK для обеспечения встраиваемости и достижения максимальной прозрачности работы платформенного решения с точки зрения потребителей. Поэтому
платформенный SDK сам по себе является важнейшей платформенной прикладной функцией. Наполнение SDK может варьироваться в зависимости от позиционирования как самой
платформы, так и конкретного платформенного сервиса по управлению потоками данных.
255

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

В нашем примере в задачи данной прикладной функции входят: управление потребителями
и поставщиками платформенного сервиса (в частности, их регистрация с последующей корректной и адресной обработкой запросов), управление событиями и/или сообщениями в рамках взаимодействий с применением платформенного сервиса, предоставление унифицированных интерфейсов для работы с объектами (поскольку речь идет о широковещательном
механизме взаимодействия с использованием программного обеспечения Apache Kafka, то
под объектами следует понимать топики), управление схемами данных, их импорт и экспорт,
а также доступ к необходимой потребителям мониторинговой информации. Также в состав
SDK могут входить и дополнительные методы.
• Управление потоками данных. Ввиду использования программного обеспечения
Apache Kafka в качестве основы технологической реализации платформенного сервиса,
в управление потоками данных входят следующие задачи: управление топиками, в том числе
создание и развертывание в соответствии с предопределенными стабильными и надежными
конфигурациями, при этом состав последних может меняться в зависимости от потребностей
платформенных приложений; управление процессами передачи сообщений и событий в зависимости от исполняемого прикладного процесса, предполагающего асинхронное или событийное взаимодействие; управление правами доступа к топикам, событиям и сообщениям с учетом практик «мелкозернистого» контроля (Fine-Grained Access Control); мониторинг объектов,
связанных с потоковой передачей данных, и т. д.
• Управление схемами данных. В рамках указанной прикладной функции реализуется
достаточно широкий спектр задач, связанных с валидацией сообщений: загрузка схем данных
и управление их реестром, валидация сообщений на соответствие схемам, управление правами
доступа к схемам в соответствии с Fine-Grained Access Control, поддержка версионности схем
событий и сообщений.
Мы говорим о прикладных функциях, хотя рассматриваем реализующий инфраструктурные задачи платформенный сервис, поскольку решение инфраструктурных задач в его контексте и является выполнением прикладной логики.
Информационные объекты характеризуют ключевые элементы, с которыми оперирует
платформенный сервис. В рассматриваемом примере ими являются:
• Схема данных. Представляет собой объект, содержащий структуру сообщения и/или
события. Структура подразумевает набор атрибутов и их описание, на основании которого
возможно проведение валидации сообщений и событий на предмет их соответствия схемам.
Соответствие проверяется с учетом версионности.
• Топик. Представляет собой объект хранения сообщений и/или событий, при этом возможна группировка или сегментация последних. Возможно задание времени их актуальности,
приоритетов и т. д. При этом группировка и сегментация могут осуществляться по произвольным критериям, в том числе задаваемым потребителями – платформенными приложениями.
• Сообщение. Представляет собой набор данных, используемый приложениями и их компонентами в рамках асинхронного обмена. С точки зрения рассматриваемого информационного объекта не является принципиальным его назначение – сообщение асинхронного обмена
или событие в событийно-ориентированной парадигме.
На Рисунке 67 также приведена легенда к схеме функционально-информационной архитектуры.
Представленная функционально-информационная архитектура спроектирована таким
образом, чтобы платформенный сервис мог использоваться максимальным числом внутренних
и внешних с точки зрения организации потребителей. При этом архитектура допускает мак256

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

Рисунок 68. Компонентная архитектура платформенного сервиса работы с журнальной
потоковой передачей информации
• Компоненты логики сервиса, создаваемые при разработке сервиса. Компоненты могут
создаваться как непосредственно в процессе разработки, так и с применением практик DevOps.
• Объекты хранения, обеспечивающие хранение тех или иных данных, задействованных
в ходе работы платформенного сервиса.
• Иные платформенные сервисы, применяемые в ходе работы рассматриваемого платформенного сервиса.
• Внешнее программное обеспечение, используемое для упрощения реализации задач
сервиса.
257

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Собственно журналы, реализованные на основе программного обеспечения Apache
Kafka.
• Платформенный SDK, посредством которого сервис предоставляется потребителям.
Рассмотрим подробнее компоненты, составляющие архитектуру, представленную
на Рисунке 68.
АРМ сотрудника реализуется в формате веб-интерфейса. Учитывая служебную направленность как платформенного решения в целом, так и конкретных платформенных сервисов,
логично предположить, что данный тип интерфейсов останется единственным. Но, учитывая постоянное развитие современной архитектуры, мы закладываем основу для расширения:
интерфейс реализуется в соответствии с концепцией микрофронтендов, также допускается
расширение числа каналов с соответствующим развитием фронтальной и канальной логики.
Для поддержки технологии микрофронтендов в архитектуру введены компоненты BFF.
При этом для контроля корректности доступа сотрудника к сервису должна осуществляться проверка как подлинности лица, запрашивающего доступ, так и интроспекция его
уровня доступа. Подобная задача является служебной и актуальна как для платформенных
сервисов, так и для платформенных приложений. Поэтому имеет смысл реализовать ее путем
дополнения платформенного решения специализированным сервисом. На Рисунке 68 показано его использование, а сам сервис обозначен ИААА – по первым буквам решаемых им
задач:
• Идентификация пользователя с запросом его объектов учетных данных (credentials).
• Аутентификация пользователя, в ходе которой подтверждается или опровергается его
право на доступ к системе – в нашем примере к платформенному сервису 2.1.1.
• Авторизация пользователя, в ходе которой определяется уровень его полномочий и их
достаточность для выполнения тех или иных операций.
• Аудит действий, в ходе которого осуществляется сбор событий информационной безопасности. Тип и количество таких событий могут настраиваться динамически.
Ранее указанный сервис не вводился в наш перечень платформенных, так что мы вновь
сталкиваемся с развитием платформы в соответствии с требованиями приложений. Ввиду
этого на Рисунке 68 сервис ИААА не отмечен числовым обозначением.
Собственно журналы хранения событий, посредством которых осуществляется событийный или асинхронный обмен, изображены на Рисунке 68 в виде двух отдельных компонентов
программного обеспечения Apache Kafka. Разнесение компонентов необходимо вследствие
двух принципиально различных классов потребителей рассматриваемого в примере платформенного сервиса: платформенных и партнерских приложений. Указанные классы потребителей являются внутренними и внешними с точки зрения их размещения внутри или вне контура организации, а потому требования информационной безопасности к ним предъявляются
различные. Требования по масштабируемости и надежности к журналам внутренних и внешних приложений также различны, поэтому, невзирая на возможность сегментации топиков
Kafka, мы физически разделяем данные объекты. Также для них могут быть применены различные топологии развертывания и варианты использования, что существенно проще обеспечить при физическом разделении, что и продемонстрировано в архитектуре. Добавим, что
Apache Kafka не только представляет собой свободно распространяемое программное обеспечение с открытым исходным кодом, но и предоставляет широкие возможности масштабирования, в том числе эластичного.

258

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Резервирование решений потоковой передачи информации осуществляется несколькими способами. Во-первых, средства Apache Kafka позволяют реализовывать отказоустойчивые решения, в том числе распределенные географически.
Во-вторых, в рамках концепции многослойного хранения с возможностью архивировать сообщения применяется решение Kafka tiered storage для хранения сообщений/событий
в журнальном формате в распределенной файловой системе, реализованной в соответствии
с поддержкой объектного хранилища S3. Поскольку ранее мы закладывали в платформу поддержку работы с контентом, то при реализации указанного механизма резервирования применяется платформенный сервис 1.3.4. Его использование осуществляется посредством платформенного SDK, причем неявно с точки зрения потребителя. Таким образом платформенный
сервис снижает нагрузку в части реализации инфраструктурных задач на команды платформенных приложений. Для управления перемещением данных в рассматриваемом случае многослойного хранения применяется программное обеспечение с открытым исходным кодом
Kafka Streams и Kafka Connect, расширяющими экосистему Apache Kafka. Отметим также,
что указанные программные решения реализуют большинство стандартизированных случаев
переноса данных, но для относительно небольшой доли специфических случаев необходима
дополнительная кастомизация. Последняя в рассматриваемом примере обеспечивается дополнительной логикой, реализуемой в составе платформенного сервиса. Данная логика обозначена на Рисунке 68 как «Логика управления перемещением данных» и реализуется в микросервисной парадигме. Соответствующие компоненты расширяют возможности перемещения
данных, дополняя такое программное обеспечение, как Kafka Connect, а также добавляют
в рассматриваемый класс логики данные, сформированные в результате работы фронтальной и канало-специфичной логики платформенного сервиса. Поскольку Kafka Streams/Kafka
Connect представляют собой внешнее программное обеспечение, то на Рисунке 68 они показаны отдельной цветовой гаммой. Подчеркнем, что логика перемещения данных применяется
для журналов работы как платформенных, так и партнерских приложений.
В-третьих, для решения задач резервирования, обеспечиваемых с большей эффективностью, нежели архивирование сообщений в распределенной файловой системе, в нашем примере используется достаточно частый шаблон связи потокового программного обеспечения
и распределенной базы данных, в качестве реализации которой применяется программное
обеспечение Apache Cassandra. Но мы не используем указанный шаблон в чистом виде. Мы
добавляем логику управления резервированием для обеспечения кастомизации специфических случаев взаимодействия потокового программного обеспечения и распределенной базы
данных. Кроме того, распределенная база данных используется не напрямую, а посредством
платформенного сервиса работы с нереляционными данными 1.2.1, что обеспечивает методологическую и технологическую унификацию на уровне всего платформенного решения.
Необходимо подчеркнуть, что и Apache Kafka, и реализации S3 хранилища, и СУБД
Apache Cassandra обеспечивают возможности эластичного масштабирования. Предложенная
в компонентной архитектуре схема резервирования позволяет независимо масштабировать все
указанные программные компоненты, следуя лучшим практикам распределенности.
Мы уже отмечали необходимость обеспечения валидации сообщений с использованием реестра схем. При этом должны поддерживаться различные форматы сообщений: с учетом того, что мы рассматриваем в настоящем примере реализацию платформенного сервиса
2.1.1 на основе программного обеспечения Apache Kafka, то речь может идти о таких форматах, как Avro, JSON, Protobuf. В базовом варианте мы можем использовать для управления реестром схем решение Confluent, предоставляющее реализацию с открытым исходным
кодом в рамках Community Edition. Указанный компонент также показан на Рисунке 68 и отображен отдельной цветовой гаммой, так как является внешним программным обеспечением,
как и Kafka Connect. Но, как и в случае резервирования, не все возможные кастомизирован259

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ные сценарии работы с форматами сообщений поддерживаются подобным заимствованным
компонентом. Поэтому мы расширяем архитектуру дополнительным компонентом, обозначенным на Рисунке 68 как «Логика управления валидацией сообщений». Данный компонент призван поддерживать специфические случаи валидации, которые могут возникнуть в ходе развития платформенных приложений, и реализован в микросервисной парадигме. Для повышения
устойчивости платформенного сервиса 2.1.1 в архитектуру добавляется долговременное хранение схем сообщений в распределенной базе данных на основе программного обеспечения
Apache Cassandra. Взаимодействие с указанной БД осуществляется посредством платформенного SDK с задействованием платформенного сервиса 1.2.1.
При проектировании компонентной архитектуры платформенного сервиса необходимо
обратить внимание на следующее важное обстоятельство. Мы неоднократно подчеркивали, что
распределенность является одним из ключевых трендов развития архитектуры. Она предоставляет исключительно обширные возможности для создания гибких, ориентированных на широкую аудиторию цифровых решений, обеспечивая им недостижимые ранее производительность
и надежность. Но у нее есть и обратная сторона. В условиях наличия в ИТ-ландшафте организации большого количества распределенных компонентов, а также наблюдаемого в современных условиях резкого увеличения числа хакерских атак, компании должны быть уверены в том,
что запросы к каждому компоненту осуществляет доверенный контрагент. Это касается в том
числе и внутреннего контура компании. То есть при осуществлении запроса к тому или иному
компоненту необходима проверка запроса на целостность и правомерность его осуществления.
Это необходимо ввиду того, что значительная часть запросов приняла удаленный характер.
Для решения указанной задачи используются секреты – конфиденциальная информация, позволяющая подтвердить правомерность выполнения запроса, а также зафиксировать источник
данного запроса. Подобный функционал необходим как во время выполнения, так и при разборе инцидентов. В данном случае речь идет о служебном функционале, который востребован
и платформенными сервисами, и платформенными приложениями, и партнерскими приложениями:
• Платформенные сервисы являются распределенными, а потому необходимо управление
секретами даже при внутренних вызовах между компонентами, входящими в состав сервиса.
• Платформенные приложения также являются распределенными, кроме того, они обрабатывают огромное количество внешних с точки зрения организации запросов ввиду повсеместного распространения удаленных каналов обслуживания.
• Партнерские приложения в принципе находятся вне контура организации, а потому
представляют собой повышенную угрозу с точки зрения информационной безопасности.
Ввиду вышеизложенного мы вводим в состав платформенного решения сервис управления секретами. Ранее он не был нами представлен в структуре платформы, но подобное
включение лишний раз демонстрирует возможность развития современной цифровой платформы в соответствии с потребностями организации и ее продуктов. Данный сервис отмечен
на Рисунке 68 как «платформенный сервис контроля доступа», который дополнен кастомизированным компонентом платформенного сервиса 2.1.1, отмеченным на иллюстрации как
«Логика контроля доступа». Взаимодействие с вводимым платформенным сервисом осуществляется посредством платформенного SDK для обеспечения методологической и технологической унификации платформы и платформенных приложений. При этом SDK платформенного сервиса 2.1.1 при выполнении вызовов методов осуществляет проверку контроля доступа
и обеспечивает корректность всех вызовов и фиксацию их инициаторов, поддерживая механизмы Fine-Grained Access Control.
260

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Если говорить о примерах функциональных возможностей, доступных сотрудникам при
работе с платформенным сервисом, то можно привести следующие:
• Просмотр сообщений.
• Просмотр топиков – напоминаем, речь идет о применении программного обеспечения
Apache Kafka в качестве основы технологической реализации.
• Редактирование и конфигурирование топиков.
• Мониторинг сервиса.
• Управление схемами данных.
• И т. д.
Но главными потребителями платформенного сервиса с точки зрения организации являются платформенные и партнерские приложения, использующие SDK, также представленный
на Рисунке 68. SDK обеспечивает доступ и к журналам, и к схемам сообщений, естественно,
при условии успешной проверки контроля доступа. Необходимо напомнить, что платформенный SDK обеспечивает механизм гибкого встраивания платформенного решения в структуру
платформенных приложений. Также SDK сервиса 2.1.1 используют другие платформенные
сервисы, заинтересованные в предоставляемых им возможностях. Например, сервис работы
с кэширующими компонентами 1.4 может задействовать спроектированный нами в представленном примере платформенный сервис в сценариях прогрева кэш.
Завершая рассмотрение компонентной архитектуры, необходимо сказать несколько слов
о том, что осталось за кадром представленного примера.
Во-первых, даже в столь обобщенном примере мы видим наличие неявных зависимостей платформенных сервисов. Платформенный сервис 2.1.1, архитектуру которого мы разбираем, использует платформенные сервисы 1.2.1 и 1.3.4, а также вводит в наше платформенное
решение два дополнительных сервиса, причем происходит это неявно с точки зрения потребителя. Отметим, что аналогичным образом и сервис 2.1.1 может неявно использоваться другими платформенными сервисами в рамках их архитектуры. При реализации потребителей,
которыми являются платформенные и партнерские приложения, в парадигме serverless архитектуры, необходимо внимательно отслеживать подобные неявные зависимости, в противном
случае можно столкнуться с множественными ошибками во время выполнения приложений.
Свойство открытости платформы в данном случае выступает незаменимым помощником.
Во-вторых, в компонентной архитектуре не показаны различные скрипты и задачи развертывания. Указанные артефакты, не являясь в общем случае исполняемыми логическими
компонентами, тем не менее обеспечивают развертывание требуемых топологий компонентов
сервиса и поддержку вариантов использования, востребованных потребителями. Указанные
категории артефактов нельзя упускать из виду.
В-третьих, во избежание загромождения нашего примера мы не рассматриваем детализацию всех интеграционных взаимодействий, реализующихся в рамках платформенного сервиса, архитектуру которого мы проектируем. С позволения читателя, детализацию его интеграционной архитектуры мы оставляем за скобками.
В-четвертых, во избежание излишнего загромождения примера мы не приводим использование рассматриваемым платформенным сервисом таких элементов, как трассировка, логирование и т. д., которые также в реальных примерах должны быть представлены самостоятельными платформенными сервисами.
При проектировании технологической архитектуры платформенного сервиса необходимо обеспечить облачное развертывание компонентов. Поскольку в первую очередь речь
идет о развертывании программного обеспечения Apache Kafka, то необходимо выбрать технологию оператора, поддерживающую облачное исполнение. Для Apache Kafka существует
261

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

немало операторов, таких как Koperator или Strimzi. Выбор оператора осуществляется в соответствии с потребностями конкретного платформенного решения и не является принципиальным с точки зрения настоящего изложения.
Для обеспечения надежности решений Apache Kafka в настоящем примере используется
технология KRaft, что позволяет исключить развертывание кластера ZooKeeper и существенно
упростить архитектуру. При масштабировании компонентов архитектуры нужно учитывать
необходимость поддержки кворума в компонентах, где это требуется. Масштабирование микросервисных компонентов, не предполагающих сохранение состояния, обеспечивается применением технологий управления контейнерами, в частности Kubernetes.
Следует также придерживаться правил разнесения по различным вычислительным узлам
задач хранения и обработки логики, чтобы поддерживать наилучшие показатели масштабируемости.
Указанные подходы к технологической архитектуре позволяют обеспечить как надежность, так и эластичное масштабирование платформенного сервиса.
При этом расширяется набор платформенных сервисов. Обновленный набор платформенных сервисов приведен на Рисунке 69.
На иллюстрации дополнительной окантовкой показаны вновь введенные платформенные сервисы ИААА (идентификации, аутентификации, авторизации и аудита) и контроля
доступа (управления секретами). Они отмечены как 5 и 6 соответственно. Им сопоставлено
по одной технологической реализации: для сервиса ИААА на основе программного обеспечения Keycloack, для сервиса контроля доступа – на основе программного обеспечения
HashiCorp Vault в версии, предполагающей открытую лицензию. Сервисы технологической
реализации отмечены на Рисунке 69 5.1 и 6.1 соответственно.
Данный пример спроектированного платформенного сервиса наглядно показывает следование ключевым трендам развития архитектуры:

262

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• В самом платформенном сервисе не реализуется сложная логика управления бизнес-процессами, но он сам может использоваться, например, при реализации шаблона хореографии.
• Платформенный сервис содержит развитую логику работы с данными, акцентируя внимание на их неструктурированном распределенном хранении, и может быть использован в том
числе при работе с большими данными.
• В столь простом примере не внедряются технологии искусственного интеллекта, но при
имплементации решений ИИ возможно применение платформенного сервиса для упрощения
реализации инфраструктурных задач.
• Спроектированное решение следует связанным тенденциям развития архитектуры: оно
является эластично масштабируемым, готово к исполнению в облачной среде, с озвученными
выше ограничениями поддерживает концепцию serverless, его фронтальные интерфейсы реализованы в рамках следованию шаблону микрофронтендов, заложены перспективы поддержки
омниканальности. Оговоримся, что целесообразность последнего для подобного инфраструктурного компонента не является подтвержденной.
При этом необходимо добавить, что архитектура не является детальным техническим
заданием на разработку, которое должно создаваться отдельно. Но вопросы формирования
технических заданий не составляют предмет нашего рассмотрения.
Подробно обсудив аспекты проектирования платформенного сервиса, мы можем рассмотреть ответ на уже давно назревший вопрос – что же получает потребитель от подобного
сервиса? Учитывая, что потребителями платформенного сервиса в первую очередь являются
платформенные приложения, отвечающие за перевод в цифровой вид продуктов компании,
то вопрос можно несколько переформулировать: что дает платформенный сервис цифровым
продуктам компании?
Мы уже неоднократно разбирали по ходу настоящей книги примеры продуктовой архитектуры: приводили не только примеры таких продуктов, как кредит и ЭБГ, но и показывали,
что даже такие сложные решения, как MDM или DWH, возможно представить в продуктовой парадигме. В рамках рассмотренных примеров мы указывали потенциально используемые
платформенные сервисы. И сервис обеспечения интеграции на основе потоковой передачи данных стал одним из основным в наших примерах. Именно поэтому мы рассмотрели пример его
детального проектирования. Данный сервис использовался для интеграции компонентов платформенных приложений между собой, для интеграции самих платформенных приложений,
загрузки больших объемов данных, прогрева кэширующих компонентов, наполнения данными
партнерской экосистемы и т. д. Можно с уверенностью сказать, что приведенная выше архитектура обеспечивает исполнение всех перечисленных вариантов использования:
• В соответствии с детализированной ранее архитектурой платформенное приложение
может эффективно управлять конфигурацией используемого потокового программного обеспечения Apache Kafka, при этом для последнего предусмотрены топологии, обеспечивающие
выполнение всех требований, предъявляемых к цифровому продукту. Отметим, что создание
сложных инфраструктурных объектов с чистого листа предъявляет высокие требования к квалификации продуктовой команды разработки и приводит к необходимости затраты значительных трудовых, временных и в конечном итоге финансовых ресурсов. В нашем случае указанные кейсы реализуются автоматически вследствие применения платформенного сервиса, что
существенно снижает затраты компании.
• Использование платформенного сервиса обеспечивает возможности как интеграции
компонентов, находящихся внутри контура организации, так и наполнение данными партнер264

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ской экосистемы, позволяя быстро создавать партнерские приложения на основе продуктов
организации. Для этого в архитектуре предусмотрено разграничение компонентов.
• При осуществлении взаимодействия компонентов посредством событийного или асинхронного обмена сохраняемые события и/или сообщения резервируются, причем для различных компонентов архитектуры применимо независимое масштабирование. То есть продуктовые команды могут не задумываться о решении указанных инфраструктурных задач, а решать
проблемы непосредственно продуктовой логики. Вследствие этого значительно повышается
производительность труда.
• В ходе распределенного взаимодействия с использованием приведенного в примере
платформенного сервиса обеспечивается логика контроля доступа, подтверждение подлинности запросов, фиксируется цепочка вызовов с указанием участников. При этом указанные операции осуществляются неявно на платформенном уровне, что позволяет снизить трудозатраты
продуктовых команд.
• Платформенный сервис предоставляет потребителям SDK, позволяющий гибко встраивать зависимости по аналогии с традиционными программными библиотеками и упрощать
релизные циклы. Таким образом достигается независимое развитие и выпуск релизов платформой и платформенными приложениями. Посредством указанного SDK могут решаться и внешние по отношению к сервису задачи, например, асинхронный прогрев кэш.
• Платформенный сервис использует архитектурные подходы, обеспечивающие его гибкое эластичное масштабирование и резервирование передаваемых данных, что позволяет
гарантировать высокие показатели надежности, отвечающие классам критичности MC и BC,
которые, при условии следования платформенным механизмам развития, в дальнейшем достижимы и платформенными приложениями, то есть цифровыми продуктами компании.
Приведенные выше тезисы убедительно свидетельствуют: платформенный сервис предоставляет ценность для цифровых продуктов, то есть формирует опосредованную ценность
для клиентов и партнеров компании. Указанные задачи, выполняемые на уровне цифровой
платформы, позволяют существенно снизить нагрузку на продуктовые команды в части решения инфраструктурных задач. Учитывая, что мы указывали применение данного платформенного сервиса в наших примерах, то мы можем дать экспертную оценку, что его корректные
проектирование, реализация и последующее применение могут снизить трудозатраты в части
использования технологий потокового взаимодействия на уровне платформенных приложений на 30 процентов и более. Повторимся, что здесь приведена авторская экспертная оценка,
а не результат рыночного исследования. Добавим также, что указанный пример платформенного сервиса не включает собственно продуктовой специфики, что позволяет исключить необходимость развития в рамках непосредственно продуктового бэклога. Последнее сокращает
риск конфликтов и торможения развития в ходе жизненного цикла платформы и платформенных приложений.
Подчеркнем, что мы привели обобщенный пример проектирования платформенного сервиса. При проектировании и реализации конкретных платформ и их сервисов необходима
детализация вариантов использования, особенностей технологий, учет требований, предъявляемых продуктами к инфраструктурной логике, и т. д.
Проектирование платформенных расширений, обеспечивающих возможности совместного параллельного развития платформенного сервиса, выходит за рамки настоящего примера.
Отметим, что в данном случае создание указанных расширений уже относительно несложно,
но оно должно учитывать функциональные и технические характеристики компонентов сервиса, развитие которых предполагается.
Внимательный читатель может задать нам очередной злободневный вопрос: «Ну хорошо,
вот запроектировали мы с Вами платформенный сервис. Он даже следует ключевым трендам
265

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

развития архитектуры, гарантирует высокий уровень доступности. А можем ли мы обеспечить
его повторное использование продуктовыми командами?» Ответ на этот вопрос, безусловно,
положительный. Посредством SDK платформенное решение и его сервисы встраиваются
в платформенные приложения, которые используют их в параллельном режиме. Более того,
основываясь на свойстве открытости современных платформ, они могут и развивать платформенные сервисы параллельно. Здесь важно следовать практикам создания платформенных расширений, а также поддерживать механизм версионности, дабы SDK платформенного приложения использовал актуальную для него версию платформенного сервиса.
При этом еще раз подчеркнем. Принципиально неверно считать, что можно сформировать в организации некую платформенную команду или набор таких команд, которые будут
обрабатывать запросы продуктовых команд в части развития платформы. Подобный подход
приводит к:
• Длительному времени ожидания доработок продуктовыми командами, поскольку
емкость любой команды ограничена, платформенная команда не является исключением. Сбор
всех требований к доработке платформы воедино приводит к необходимости расстановки приоритетов, в результате чего ожидание конкретной продуктовой команды может избыточно
затянуться. Итогом станет ухудшение P&L цифрового продукта, снижение его конкурентоспособности и убытки организации.
• Развитию платформы, не отвечающему требованиям продуктов. Платформенная
команда не может владеть продуктовой спецификой, а потому выполненные доработки платформы могут не отвечать в точности требованиям цифрового продукта.
Свойство открытости цифровых платформ является фундаментальным с точки зрения
перспектив их интенсивного развития. Мы специально привели в примере наглядную и прозрачную архитектуру. Компетентная продуктовая команда не просто может, но и должна
принимать участие в ее развитии. А прозрачность архитектуры платформенных сервисов
обеспечивается простым фактом: в состав платформенных сервисов включается решение
инфраструктурных, а не продуктовых задач. Безусловно, как мы отмечали выше, продуктовая
специфика должна учитываться при развитии платформы, но сами продукты не входят в ее
состав. В противном случае, сохраняя прозрачность для одних продуктовых команд, продукты
которых вошли в те или иные платформенные сервисы, платформа станет «черным ящиком»
для других команд, продукты которых не столь массово представлены в составе компонентов
платформы.
В настоящем разделе мы рассмотрели вопросы позиционирования платформенных сервисов, их применение цифровыми продуктами. Привели пример архитектуры платформенного сервиса, показали ту опосредованную ценность для клиентов, которую приносит данный
сервис. На основании приведенного примера показали решение ряда задач, необходимых для
платформенных приложений, а также обозначили возможные пути сокращения трудозатрат
и повышения производительности труда в процессе создания ценности. В следующем разделе
мы рассмотрим важный вопрос, касающийся взаимосвязей цифровых продуктов и платформенных приложений.

266

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Цифровые продукты как платформенные приложения
По ходу настоящей книги мы неоднократно подчеркивали, что ключевой задачей современной автоматизации является создание ценности для клиента. Мы сознательно ушли в данном тезисе от термина «цифровизация», поскольку цифровизация предполагает в первую
очередь изменение мышления, а уже следствием изменения мышления становится акцентирование целей автоматизации на ценности для клиента. Ценность является ключевой характеристикой продукта, предоставляемого компанией клиентам и/или партнерам. И в нашей предшествующей книге «Архитектура цифровых платформ. От настоящего к будущему», и в рамках
настоящего изложения мы неоднократно подчеркивали, что применение даже самой современной цифровой платформы создает лишь опосредованную ценность для клиентов. Платформа
упрощает и удешевляет создание цифровых продуктов. Последние реализуются в виде платформенных приложений. То есть мы можем в контексте архитектуры поставить знак равенства
между продуктом и платформенным приложением. А что же такое платформенное приложение?
На основании тезисов, изложенных нами в настоящей книге, мы можем отметить, что
платформенное приложение обладает следующими ключевыми характеристиками:
• Поскольку платформенное приложение создается с использованием платформы и платформенного подхода, то платформа предоставляет рекомендации по архитектуре платформенных приложений. Платформенное приложение должно следовать этим рекомендациям.
• Платформенное приложение создается с использованием платформенных сервисов.
Мы неоднократно подчеркивали тот факт, что в состав платформенного сервиса должны входить наборы топологий и вариантов использования, а также рекомендации по применению
платформенных сервисов. Приложение должно следовать указанным рекомендациям.
• При проектировании и реализации платформенных приложений архитектор и продуктовая команда должны тщательнейшим образом анализировать функционал приложения,
использовать для решения общих инфраструктурных задач платформенные сервисы. То есть
платформенное приложение не может быть перегружено инфраструктурными функциями.
• Платформенное приложение следует ключевым и связанным трендам развития архитектуры.
• Платформенное приложение использует свойство открытости цифровых платформ
в ходе исполнения процессов жизненного цикла продукта.
Как нетрудно заметить, вышеперечисленные пункты тесно связаны между собой.
Внимательный читатель и здесь не удержится от вопроса: «Вы столь часто подчеркивали необходимость свободы продуктовых команд, даже в примере платформенного решения
привели целые массивы технологических реализаций платформенных сервисов, а сейчас говорите о том, что платформа диктует архитектуру приложений. Нет ли здесь противоречия?» Мы
со своей стороны ответим, что противоречие отсутствует, а ниже объясним почему.
Во-первых, принципиально неверно ставить знак равенства между свободой и анархией.
Даже на уровне стартапов, ключевой ценностью работы которых является свобода, перевод
последней в анархию обычно приводил к тому, что успешное развитие получали их конкуренты. То есть свобода предполагает некие рамки, в которых она допускается. И если организация ставит себе целью создание конкурентоспособных продуктов, то она должна задать
эти рамки для продуктовых команд. Они должны быть достаточно жесткими, чтобы свобода
не превратилась в анархию, но в то же время достаточно гибкими, чтобы не подавлять инициативу. В главе, посвященной организационным процессам в эпоху продуктовой трансформации,
267

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

на каких открытых технологиях они основаны, насколько сквозными компетенциями по развитию и поддержке всего технологического стека обладает поставщик решения.
Следование тенденции распределенности является абсолютно необходимым условием
создания конкурентоспособного продукта. Современные продукты являются достаточно сложными, а потому для их создания необходимо привлекать множество команд разработки, а сами
команды также оказываются распределенными, поскольку компании могут использовать весь
рынок труда страны. Единственная команда, находящаяся в одном помещении и ограниченная
в соответствии с классикой гибких методологий десятью участниками, конечно, может создать
и очень сложный продукт. Но это займет весьма продолжительное время, в течение которого
другие компании выведут на рынок не одно конкурирующее решение. Технологически продукты также должны быть распределенными, поскольку в противном случае их производительность и надежность продуктовых решений окажутся на уровне, не отвечающем рыночным
требованиям.
Автоматизация бизнес-процессов обязательна для платформенного приложения. Особенно с учетом того, что, как мы отмечали, в современном мире необходимо осуществление продуктового рефакторинга бизнес-процессов в ходе продуктовой трансформации.
Бизнес-процессы должны быть ассоциированы с процессами жизненного цикла продукта компании, поэтому было бы странным при автоматизации последнего пренебречь бизнес-процессами.
Данные, как мы неоднократно подчеркивали, составляют основное богатство компании,
поэтому организация эффективной работы с ними на уровне продуктового ИТ-решения, которым и является платформенное приложение, представляет собой исключительно важную и,
не побоимся этого слова, ключевую задачу автоматизации продуктов и перевода их в цифровой вид. При реализации платформенного приложения необходимо продумывать архитектуру
продуктов данных, в рамках комплексной автоматизации создавать сетку данных в соответствии с шаблоном Data Mesh. Мы уже приводили примеры того, что даже такие традиционно
громоздкие программные комплексы, как MDM и DWH, в современных условиях представимы в виде цифровых продуктов, то есть могут быть реализованы в формате платформенных приложений. Исходя из этого, любое платформенное приложение должно ставить работу
с данными во главу угла, а платформа, в свою очередь, предоставлять для этого высокоэффективные инструменты.
Использование искусственного интеллекта является необходимым условием для большинства платформенных приложений, поскольку без этого невозможно поддерживать конкурентоспособность продуктов на современном рынке. Возможно, озвучиваемые мнения о том,
что продукты, не применяющие технологии ИИ, уже являются продуктами каменного века,
на сегодняшний день избыточно радикальны, но уже завтра они могут адекватно отображать
реальность.
Следование связанным тенденциям развития архитектуры также является необходимым
для платформенного приложения. В случае если оно не поддерживает эластичное масштабирование, то под угрозой находятся производительность и надежность продуктового ИТ-решения. Если приложение не может быть эластично масштабируемым, то одним из вариантов
удовлетворения требований в части производительности и надежности является избыточное
потребление вычислительных ресурсов, призванное обеспечить корректное функционирование платформенного приложения в условиях пиковых нагрузок. Однако подобный подход приводит к чрезмерным затратам финансовых ресурсов и крайне негативному влиянию на P&L
цифрового продукта. В условиях повсеместного использования облачных технологий каждый
цифровой продукт должен поддерживать исполнение в облачной среде, в противном случае
он оказывается неконкурентоспособным. Мы можем даже усилить данный тезис и указать, что
современное платформенное приложение является cloud-native. Только в таком случае орга269

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

низация может считать, что продуктовая трансформация осуществляется успешно. Вопрос
следования архитектурной парадигме serverless несколько более сложен. Мы уже отмечали,
что на сегодняшний день создание serverless решений сталкивается с некоторыми трудностями, причина которых заключается в уровне зрелости поставщика облака. Поэтому архитектор и продуктовая команда должны в первую очередь закладывать основу для эффективной
миграции платформенного приложения к serverless архитектуре. Омниканальность является
на сегодня стандартом де-факто для конкурентоспособных компаний, поэтому следование данной тенденции, как и использованию микрофронтендов для улучшения клиентского опыта
и поддержки распределенности, является обязательным для платформенных приложений.
Платформенное приложение должно активнейшим образом использовать свойство
открытости цифровых платформ. Мы уже рассматривали важную роль данного свойства в продуктовой разработке. Продукты являются источником требований к платформенному решению, а потому последнее должно быть прозрачным для продуктовых команд. Мы неоднократно подчеркивали тот факт, что компания, стремящаяся сохранять конкурентоспособность
в современном цифровом мире, должна стремиться стереть грань между платформенными
и продуктовыми командами. Продуктовая команда является лучшим источником сведений
о собственных потребностях, она понимает их гораздо более детально, нежели любая внешняя платформенная команда, пусть и состоящая из высококвалифицированных специалистов.
Поэтому организации должны стремиться к тому, чтобы продуктовые команды самостоятельно
вносили дополнения в платформу. При этом дополнения должны вноситься и публиковаться
таким образом, чтобы следовать принципам релизной модели платформы и не нарушать ее
функционирование, а также становиться доступными всем потребителям. То есть дополнение,
выполненное в рамках развития одного платформенного приложения, доступно остальным
платформенным приложениям.
Подробно рассмотрев назначение и характеристики платформенных приложений, мы
должны сказать несколько слов о требованиях, предъявляемых к их архитектуре. Можно выделить следующие ключевые требования:
• Архитектура платформенных приложений должна быть структурирована и разбита
на набор архитектурных уровней, отличающихся по своему функциональному назначению.
Отметим, что в примерах, приведенных по ходу настоящей книги, мы следовали данному требованию, выделяя уровни фронтального и канального представления, канало-специфичной
продуктовой логики, логики оперативного хранения продуктовых данных, прикладной продуктовой логики и управления бизнес-процессами, интеграционной логики, а также архивного
хранения.
• Для платформенного приложения должны создаваться архитектуры различного уровня
детализации, позволяющие связать реализуемое приложение с бизнес-потребностями, то есть
явным образом указать связь цифрового продукта с предоставляемой им ценностью, а также
с исполняемыми и техническими артефактами, то есть продемонстрировать реализуемость
продукта. Мы приводили по ходу книги примеры таких архитектур: функционально-информационная, компонентная, интеграционная, технологическая.
• Жизненный цикл архитектуры в организации должен предоставлять возможность изменять набор артефактов детализированной архитектуры, добавлять новые типы архитектурных
моделей либо изменять подходы к ним. Архитектура и процесс управления ею являются динамично развиваемыми артефактами, поэтому и набор архитектурных моделей, ассоциированных с платформенными приложениями, также может изменяться.
• Для гибкого управления архитектурой цифровых продуктов необходимо создание метамодели продуктовой архитектуры. Указанная метамодель позволит как вносить новые типы
архитектуры продуктов, так и изменять степень детализации архитектурных артефактов.
270

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Выше мы уже указывали на сочетание характеристик, которым должно соответствовать
платформенное приложение: быть распределенным и использовать платформенные сервисы
для решения общих инфраструктурных задач. Покажем на примере, каким образом это может
происходить. Схематично пример представлен на Рисунке 70.

Рисунок 70. Пример распределенных компонентов платформенного приложения,
использующего цифровую платформу
На иллюстрации детализирован пример архитектуры платформенного приложения, реализуемого в соответствии с тенденцией распределенности и с применением платформенных
сервисов. При проектировании и разработке платформенного приложения используется парадигма микросервисной архитектуры, поэтому распределенные компоненты логики приложения в данном примере представляют собой микросервисы. В примере указаны три микросервиса. При этом они реализуют различную логику, отвечают за выполнение разных задач,
а потому задействуют в ходе своего жизненного цикла отличные подмножества инфраструктурного обеспечения.
Микросервис 1 в ходе своего жизненного цикла осуществляет взаимодействие со смежными компонентами посредством как событийного обмена, так и прямых интеграций. Микросервис 2 задействован в событийном обмене, а также в ходе выполнения логики кэширует используемые данные. Микросервис 3 участвует в прямых интеграциях с микросервисом
1. Исходя из этого, приведенные в примере микросервисы используют различные платформенные сервисы и, соответственно, различные подмножества платформенного SDK. По ходу
настоящего изложения мы уже отмечали, что платформенный SDK может предоставляться
потребителям – платформенным приложениям – как целиком, так и раздельно в соответствии
с потребностями цифровых продуктов в конкретных платформенных сервисах. В приведенном нами примере задействован второй способ предоставления SDK.
271

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Микросервис 1 использует SDK платформенного сервиса 2.1.1 (нумерация платформенных сервисов соответствует Рисунку 69) для осуществления событийной интеграции
на основе технологической реализации с применением программного обеспечения Apache
Kafka. Поэтому в состав микросервиса включены библиотеки, обеспечивающие использование
указанного API (SDK 2.1.1). Кроме того, поскольку микросервис 1 должен напрямую взаимодействовать с микросервисом 3, для обеспечения эффективности, прозрачности и управляемости указанной интеграции в архитектуру включена поддержка шаблона «сетки сервисов» (Service Mesh). Поддержка подобного типа интеграции еще не была включена в состав
платформенного решения, рассматривавшегося нами по ходу настоящей книги. Сейчас самое
время сделать это. Поскольку ранее не задавалась нумерация для платформенного сервиса
Service Mesh, то последний включен в пример, представленный на Рисунке 70, с аббревиатурой SM, которая ассоциирована как с самим платформенным сервисом, так и с его SDK.
Поэтому в состав сборки микросервисов 1 и 3 включен платформенный SDK SM, обеспечивающий вызов платформенного сервиса SM, который, в свою очередь, отвечает за взаимодействие с решением, непосредственно реализующим шаблон сетки сервисов (Service Mesh). Мы
не детализируем в данном примере конкретную технологическую реализацию.
Микросервис 2, как и микросервис 1, использует технологии событийного обмена в ходе
интеграции между компонентами. Поэтому в рамках применения платформенного подхода
в состав микросервиса 2 включен платформенный SDK, обеспечивающий взаимодействие
с платформенным сервисом 2.1.1, в качестве основы технологической реализации которого
выступает ПО Apache Kafka. Кроме того, микросервис 2 предполагает высоконагруженную
обработку данных и, возможно, выполнение ресурсоемких операций, требующих высокой производительности при исполнении. С этой целью рассматриваемый микросервис задействует
платформенный сервис 1.4.1, обеспечивающий кэширование информации, применяемое для
выполнения обоих заявленных сценариев использования. Применение указанного платформенного сервиса также осуществляется посредством платформенного SDK. Для микросервиса
2, как и для микросервисов 1 и 3, мы указываем индекс подключаемого сервиса в составе SDK
на иллюстрации.
При этом для резервирования кэширующего компонента используется распределенная
база данных на основе NoSQL СУБД Apache Cassandra. Указанное резервирование осуществляется неявно с точки зрения потребителя и обеспечивается на уровне связи соответствующих
платформенных сервисов и их реализаций. Мы уже рассматривали ранее расширение платформенной архитектуры связью сервиса работы с кэширующими компонентами с сервисом
работы с реляционными и нереляционными СУБД в рамках обеспечения надежного и долговременного хранения. Аналогичным образом осуществляется связь при резервировании журналов, основанных на потоковом программном обеспечении, с распределенной базой данных.
На Рисунке 70 сделан ряд упрощений по сравнению с рассматриваемыми ранее архитектурными примерами. Это выполнено с целью обеспечения наглядности восприятия иллюстрации и никоим образом не дезавуирует ранее приведенные примеры:
• На схеме показаны платформенные сервисы, а не сформированные и инстанциированные на их основе исполняемые модули, с целью снижения числа отображаемых объектов. При
полномасштабной отрисовке примера нам пришлось бы показывать и сервис, и модуль, и расширения, и их контексты, что привело бы к значительному усложнению примера, но ничего
не изменило бы с точки зрения концепции демонстрируемого цифрового продукта. В реальности используется, конечно, модуль. При этом совместно используемые сервисы, такие как платформенный сервис 2.1.1 в настоящем примере, могут предоставлять в рамках модели платформенных приложений как отдельные экземпляры модулей для каждого потребителя, так
272

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

и общие модули, используемые повторно компонентами приложений. Выбор варианта исполнения модулей осуществляется архитектором при проектировании платформенного решения.
• На схеме приведены не обобщенные, а конкретные реализации платформенных сервисов. Например, указан сервис 1.4.1, предполагающий технологическую реализацию с использованием программного обеспечения Apache Ignite, а не сервис 1.4, который обобщенным
образом работает с кэш, или сервис работы с данными 1. Это сделано во избежание включения в иллюстрацию дополнительных связей между обобщенными платформенными сервисами и их детальными имплементациями. Подобные связи усложняют восприятие рисунка,
но не дают существенной дополнительной информации именно к данному примеру.
• На схеме показана прямая связь технологий при резервировании, в частности кэширующего компонента и распределенной базы данных, журналов потокового программного обеспечения и распределенной базы данных. При осуществлении указанных связей также используются платформенные сервисы и формируемые на их основе модули, как показано в примере,
приведенном нами ранее на Рисунке 68. В настоящем же примере мы стремимся не усложнять
представление, поскольку акцентируем внимание читателя на структуре платформенного приложения, а не платформенного сервиса.
• Кроме того, схема микросервиса в данном примере не содержит требуемую ему среду
исполнения, а также ряд инфраструктурных библиотек. В реальности, разумеется, в состав
исполняемого компонента входит дополнительный набор SDK для работы с транзакциями,
сообщениями, кэшированием, сохраняемыми сущностями и т. д. Кроме того, как правило,
для исполнения микросервисов предусматривается использование контейнерной виртуализации с применением оркестратора контейнеров, например, Kubernetes или основанных на нем
решений, что, в частности, требует организации точек доступа API. Но указанные аспекты
не характеризуют именно платформенное приложение – они актуальны практически для
любого варианта микросервисной архитектуры. Поэтому мы не стремимся загромоздить этими
подробностями иллюстрацию, а обсуждаем структуру именно платформенного приложения.
Подводя итог приведенному примеру, мы можем констатировать, что платформенное
приложение характеризуется распределенной архитектурой, при этом структура каждого компонента определяется выполняемыми им задачами. В соответствии с указанным перечнем
задач компонент включает в свой состав требуемый набор платформенных SDK и посредством данных инструментов использует платформенные сервисы. Последние предоставляют
возможность решения общих инфраструктурных задач, в том числе неявных с точки зрения
платформенного приложения. К таким задачам относится, например, обеспечение дополнительных возможностей по масштабированию и надежному исполнению компонентов приложения. Каждый компонент приложения может развиваться независимо и обладает собственным релизным циклом. При этом обновление платформенных сервисов не требует повторной
сборки и тестирования всех компонентов – обновляются только те компоненты, которые являются потребителями обновления на основе SDK. Также необходимо отметить, что представленный пример платформенного приложения допускает исполнение в облачной среде. Кроме
того, при условиях соответствующей организации каждого микросервиса, возможен переход
к serverless архитектуре. Необходимо подчеркнуть высокий потенциал эластичного масштабирования приведенного в примере приложения в целом, как и составляющих его компонентов
в отдельности.
На основании рассмотренного примера мы можем сформулировать общую концепцию
платформенного приложения:
• Платформенное приложение в своей архитектуре следует ключевым и связанным трендам развития архитектуры.
273

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

• Платформенное приложение реализуется в соответствии с рекомендациями, предоставляемыми в составе платформенного решения, и обладает типовой архитектурой.
• Платформенное приложение состоит из компонентов. Набор компонентов обеспечивает автоматизацию в соответствии с концепцией архитектурных слоев и покрывает все слои,
представленные в типовой архитектуре и востребованные конкретным приложением.
• Каждый компонент использует собственное подмножество платформенных сервисов
и соответствующего платформенного SDK.
• Платформенные сервисы могут содержать неявные для приложения зависимости между
собой для обеспечения решения инфраструктурных и вспомогательных задач. Данный факт
необходимо учитывать при сборке приложения и его компонентов.
• Инстанциирование платформенных сервисов для использования компонентами платформенных приложений может осуществляться различным образом, то есть могут присутствовать разные типы связей уровня «компонент – платформенный модуль». Выбор способов
инстанциирования осуществляется архитектором.
• Задачей продуктовых команд является грамотное и ответственное использование платформенных сервисов и концентрация внимания на реализации непосредственно продуктовой
логики. Используя свойство открытости платформ, они могут развивать последние при отсутствии в них необходимых функций.
Напомним читателю, что именно платформенное приложение осуществляет предоставление цифрового продукта клиентам и партнерам компании.
Необходимо отметить, что в нашем примере мы добавили в рассмотрение новый платформенный сервис – интеграции с использованием шаблона «сетки сервисов» Service Mesh.
Соответственно, необходимо добавить указанный сервис в общую структуру платформенных сервисов, рассматриваемую нами в настоящей книге. Схематично она представлена
на Рисунке 71.
На Рисунке 71 показано дополнение структуры платформенных сервисов сервисом реализации шаблона Service Mesh. На рисунке он пронумерован как 7. Платформенному сервису
7 сопоставлены 2 технологические реализации – на основе программного обеспечения Istio
и Linkerd. Они отмечены на иллюстрации индексами 7.1 и 7.2 соответственно. Дополнения
платформенной структуры обведены специальной окантовкой. Поскольку мы не детализируем
в нашем примере дальнейшее рассмотрение указанных сервисов, то мы не исследуем их последующую связь с другими платформенными сервисами, например с сервисом работы с данными 1.

274

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

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

276

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Будущее цифровых продуктов
(вместо заключения)
Вот мы и достигли завершающей главы настоящей книги. Будем надеяться, что мы
не слишком утомили читателя в предыдущих главах. Сейчас же настало время подвести некоторые итоги. И для начала ответим на вопрос, о чем же книга, которую читатель держит в руках
или открыл на экране своего электронного устройства.
Рассуждения о цифровых продуктах, которые мы можем найти в открытых источниках,
уже приняли характер заклинаний. Мы регулярно слышим: «цифровые продукты», «цифровые сервисы», «переход к продуктам». При этом сами «заклинатели» далеко не всегда оказываются в состоянии объяснить, к чему же мы переходим. Настоящая книга имеет своей целью
объяснить архитектурную и технологическую сторону цифрового продукта, понять тенденции
его развития, помочь как конкретным специалистам, так и организациям в целом в осуществлении продуктовой трансформации. Поэтому мы и можем тезисно сформулировать, чему же
посвящено достаточно объемное изложение, созданное нами и поставившее в фокус внимания
цифровые продукты:
• Продуктовое мышление. Вопрос перехода к цифровым продуктам на уровне компании
очень сложен и не имеет однозначного решения. Но каким бы образом мы ни начали указанный переход, стартовым этапом решения становится изменение мышления как всей компании,
так и конкретных специалистов, участвующих в трансформации. А новое мышление требует
полного пересмотра организационной деятельности, изменения позиционирования цифровизации в компании, трансформации всех ключевых процессов в ней. Данный аспект подробно
рассмотрен в главе «Цифровые продукты и процессы».
• Новые подходы к архитектуре. Новизна касается как процессов управления архитектурой, так и следования ключевым современным тенденциям ее развития. Изменение процессов управления архитектурой рассмотрено в главе «Цифровые продукты и процессы», ключевые тенденции развития архитектуры в преломлении на продуктовый контекст представлены
в главе «Цифровые продукты и ключевые тренды развития архитектуры».
• Платформенный подход. К сожалению, на сегодняшний день в открытых источниках
присутствуют заметные разночтения о том, что считать цифровой платформой. Мы рассматриваем позиционирование платформ в контексте их максимальной пользы для создания, развития и исполнения цифровых продуктов. Указанным вопросам посвящена глава «Цифровые
платформы и цифровые продукты».
• Ну и собственно цифровые продукты. Вся наша книга посвящена обсуждению того,
каким образом создавать цифровые продукты будущего. И краеугольным камнем такого создания является ценность, которую продукты несут клиентам и партнерам организации, вставшей
на путь продуктового развития.
При этом целью книги не является описание создания финансовых моделей цифровых
продуктов компании или расчета P&L. Указанные темы крайне интересны, но в данной части
мы отсылаем читателя к специализированной литературе.
Таким образом, резюмируя вышеизложенное, мы рассматриваем концепцию и архитектуру цифровых продуктов в контексте их создания и последующего развития.
Важным аспектом обсуждения в настоящей книге стали ключевые тренды развития архитектуры и их применение в жизненном цикле цифровых продуктов. Автору этих строк в ходе
профессиональных дискуссий, вызванных предыдущими книгами, уже приходилось сталки277

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

ваться с утверждением, что он якобы абсолютизирует приводимые им тенденции. Мы со своей
стороны отвергаем подобное обвинение. С тем же успехом можно упрекнуть авторов, работающих в любой профессиональной области, когда они рассуждают о тенденциях, наблюдающихся в занимающих их внимание сферах.
Мы не возводим в абсолют ни одну из приведенных в нашей книге тенденций. Более
того, мы даже не пытаемся присвоить себе пальму первенства в части их открытия. В самом
деле, рассматривая каждую из них, можно с уверенностью сделать непреложный вывод, что
все эти тенденции масштабно проявили себя еще до выхода нашей первой книги «Архитектура цифрового мира». Мы выделяем тенденции и именуем их ключевыми по очень простым
принципам:
• Указанные тенденции позволяют существеннейшим образом, иной раз даже
на порядки, повысить производительность труда при создании современных и устремленных
в будущее цифровых продуктов.
• Приводимые нами тенденции позволяют значительно повысить конкурентоспособность
продуктов, создаваемых с их применением.
Мы ни в коем случае не пытаемся возвести в абсолют какую-либо из рассмотренных нами
тенденций. Совсем наоборот – мы предлагаем читателю в ходе изучения настоящей книги их
совместно осмыслить и использовать в продуктовой разработке максимально гибко и эффективно. Ведь мало просто провозгласить распределенность или применение решений с открытым исходным кодом в качестве знамени – важно грамотно использовать их при создании ценности, ведь именно последнее характеризует истинно продуктовую разработку.
Пристальное внимание по ходу настоящей книги мы уделили применению платформенного подхода при создании цифровых продуктов. Внимательный читатель наверняка заготовил
вопрос: «Неужели без применения платформы невозможно создавать продукты?» Конечно,
возможно, ответим мы. И, к слову, весьма качественные продукты. Но вопрос следует ставить
совершенно иначе: можем ли мы создавать конкурентоспособные продукты массово, фактически серийно. Ведь именно таким образом должна выводить на рынок продукты современная организация. При условии потребности в серии необходимо сокращать стоимость создания каждого продукта. То есть, говоря о серийном выпуске продуктов, мы должны говорить
о серийном цифровом продукте. И именно структуру такого серийного продукта и резкое
сокращение стоимости его создания, развития и сопровождения обеспечивает современная
цифровая платформа. Мы подробно рассмотрели этот вопрос в соответствующей главе.
Основываясь на всем предыдущем изложении, попытаемся ответить на вопрос, каким мы
видим будущее цифровых продуктов. Безусловно, мы не стремимся утверждать, будто обладаем экстрасенсорными способностями, поэтому, говоря о будущем, мы его не предсказываем,
а анализируем текущее состояние дел и перспективные тенденции, на основании чего делаем
те или иные выводы.
Учитывая подчеркнутый нами еще в самом начале книги факт, что путь в рамках условной S-кривой цифровыми продуктами пройден больший, нежели платформами и особенно
мышлением, мы можем сделать важный вывод: те компании, которые не смогут перестроить
мышление и начать создавать полноценные end-to-end продукты, утратят конкурентоспособность, в результате чего они вполне могут уступить долю рынка.
Но и просто утверждать, что изменение мышления само по себе обеспечит конкурентоспособность создаваемых продуктов, несколько оптимистично.
Современный рынок крайне динамичен и, не побоимся этого слова, переполнен цифровыми «продуктами» невысокого качества. Последние, в свою очередь, нередко вызывают
у клиентов едва ли не утрату веры в информационные технологии и их возможности. Вместе
278

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

с тем экономические тенденции нельзя назвать сверхблагоприятными. Большинство рынков
мира не обладают избыточными ресурсами, которые можно вкладывать в цифровые продукты.
Это означает, что необходимо соответствовать следующим тенденциям:
• Максимально переводить продукты в цифровой вид, работать над адресной ценностью
и тем самым сокращать издержки компаний.
• Формировать новые рынки, на которых окажутся востребованными цифровые продукты. Обеспечить прибыль и последующие инвестиции за счет вновь созданных рынков.
Оба этих пути являются крайне нелегкими. Тем более непросто совместить их. Но мы
призываем компании не останавливаться. Решение просто переждать кризисные явления в экономике может оказаться крайне поспешным и недальновидным – фактически оно предваряет новый «кризис верхнего палеолита». Необходимо формировать новую модель ценности,
новую модель стоимости в экономике. И ни в коем случае не останавливаться. Ведь в случае
прекращения инвестиций в развитие первым под сокращение расходов неминуемо попадет
искусственный интеллект, как направление, характеризующееся высокой стоимостью. Искусственный интеллект, как мы подчеркивали в настоящей книге, еще не перешел в стадию интенсивного роста, поэтому остановка на пути его развития может оказаться фатальной для тенденции. Впрочем, любая высокотехнологичная отрасль крайне чувствительна к инвестициям,
направляемым в ее развитие. Мы выразим надежду, что уже в ближайшем будущем ситуация в отрасли информационных технологий станет более оптимистичной. Но и сама отрасль
должна для этого сделать упор на ценность. Создавать цифровые продукты, востребованные
рынком. Тогда и основания для новых инвестиций станут более твердыми.
Говоря о завершении настоящей книги, нельзя не сказать несколько слов о получившейся
трилогии. «Архитектура цифрового мира», «Архитектура цифровых платформ. От настоящего к будущему», «Цифровой продукт XXI века. Концепция и архитектура». Три эти книги
связаны не просто похожими названиями или фамилией автора. В первой книге мы рассматривали общий подход к современной архитектуре, во второй сконцентрировались на платформенном подходе и предоставляемых им преимуществах. В третьей же мы уделили основное
внимание продуктовому подходу, учитывающему ранее представленные архитектурные тенденции и дополненному подходом платформенным. Подобный способ решения задач позволяет создать продукты высокого качества, востребованные рынком и формирующие позитивное восприятие клиентами всей отрасли информационных технологий в целом. Мы надеемся,
что читателю, а он регулярно полемизировал с нами по ходу всех трех книг, последние принесут практическую пользу в деле современного цифрового развития. И если автору этих строк
удалось акцентировать внимание на современном мышлении, позиционировании цифровых
платформ и архитектурной специфике цифровых продуктов, то он может считать свои труды
не напрасными.

279

А. Н. Трушкин. «Цифровой продукт XXI века. Концепция и архитектура»

Благодарности
Прежде всего хочу выразить глубокую благодарность Билялову Марату Ранатовичу
за неустанную работу над высококачественными архитектурными решениями, предложенные
им прорывные идеи развития цифровых продуктов и их плодотворное совместное обсуждение.
Хочу поблагодарить Феоктистова Александра Юрьевича за ряд предложений по перспективным тенденциям развития цифрового мира и особенно за выдающийся вклад в развитие
технологий искусственного интеллекта.
Также хочу выразить благодарность моему научному руководителю – кандидату физикоматематических наук Кочетову Игорю Валериановичу за стимулирование интереса к творчеству и неоценимую поддержку на старте моей профессиональной деятельности.

280