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

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

© Андрей Николаевич Трушкин, 2025

ISBN 978-5-0068-3471-2

Создано в интеллектуальной издательской системе Ridero

Введение

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

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

Сразу отметим, что в дальнейшем под продуктами мы будем понимать именно цифровые продукты, под платформами – цифровые платформы. Говоря об архитектуре, мы будем подразумевать ИТ-архитектуру.

Рассматривая вопросы концепции и архитектуры продуктов, создаваемых организациями в рамках интенсивного развития, мы будем опираться на материал, разобранный по ходу предыдущих книг, упомянутых ранее. Мы уже отмечали (см. «Архитектура цифрового мира»), что в современных реалиях актуален продукт, предоставляющий комплексную, законченную и самостоятельную ценность для клиентов и/или партнеров организации, – продукт, который мы именуем end-to-end продуктом. Указанный продукт с архитектурной точки зрения должен включать в себя все основные аспекты автоматизации, такие как:

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

• Собственно продуктовые процессы, описывающие полный жизненный цикл продукта.

• Работа с данными, имеющими отношение к продукту («продукт данных», рассмотрению которого будет посвящен соответствующий раздел в настоящей книге).

• И т. д.

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

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

• Платформа не является информационной системой.

• Платформа не является обособленным программным комплексом.

• Платформа должна быть открытой, и изменения в нее могут вносить любые команды, которые должны брать на себя ответственность за вносимые изменения.

• Платформа не должна быть замкнутой.

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

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

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

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

• Открытый код, на котором явно или неявно основываются ключевые технологические решения современности.

• Распределенность. Здесь будет нелишним напомнить читателю, что в данное понятие входит как технологическая, так и организационная составляющая.

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

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

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

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

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

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

Рисунок 1. S-кривая продуктового и платформенного подхода, а также мышления

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

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

Ситуация с мышлением во многом аналогичная. Начав на словах переходить к продуктовой методологии, к продуктовой разработке, многие компании продолжали оперировать категориями «проектного» мышления, что приводило к тому, что жизненный цикл продукта в их понимании соответствовал жизненному циклу проекта. Говорить об интенсивном развитии в таком случае не приходится, ведь продукт должен перманентно развиваться в соответствии с P&L (Profit&Loss Analysis – анализ прибылей и убытков), в то время как на фазе постпроекта его развитие будет в лучшем случае экстенсивным. И работа с мышлением далеко не завершена, можно сказать, что по-настоящему она только начинается. Поэтому проблематике организационных процессов, их месту в развитии продуктов будет посвящена отдельная глава.

Вопросы гибких методологий уже набили оскомину. Не первое десятилетие на крупных совещаниях, конференциях, презентациях звучит «Agile, agile, agile». Увы, одного звучания мало для достижения подлинной эффективности. Многие воспринимают гибкие методологии в формате карго-культа. И крупные компании вынуждены адаптировать их, в противном случае вместо гибкости они получают «Waterfall со стендапами», а вместо современных продуктов лоскутное одеяло автоматизированных систем или «множества платформ», на базе которых невозможно управлять эффективностью цифровизации. Ситуация на самом деле гораздо более серьезная, чем может показаться на первый взгляд. Уровень прохождения S-кривой продуктового подхода, как мы показали на Рисунке 1, выше, чем у платформенного, и, тем более, выше, нежели у продуктового мышления. Емкость мирового рынка конечна, а потому область насыщения для цифровых продуктов не является чем-то недостижимым. Указанное явление может привести к застою, а затем и деградации всего рынка информационных технологий. Потому крайне важно перейти к подлинно интенсивному продуктовому развитию. И в этом продуктовому подходу помогут подход платформенный, изменение мышления и грамотная адаптация гибких методологий, чему будет посвящена отдельная глава.

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

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

Общий подход к архитектуре цифровых продуктов

«Замечательно! Изучим данную главу, дальше можно не читать, ведь все уже сказано про архитектуру!» – воскликнет нетерпеливый читатель, увидев название настоящей главы. И будет в корне неправ, ведь разговор об архитектуре мы сейчас только начнем и наметим основные штрихи для дальнейшего обсуждения. Но базовый задел закладывается именно в данный момент.

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

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

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

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

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

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

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

• В ходе работы с современным продуктом обрабатывается большое количество данных, в результате чего при его проектировании должен определяться продукт данных, ассоциированный с конкретным продуктом организации. Мы рассматривали проблематику продукта данных в предыдущих книгах, в настоящем изложении мы также уделим ей внимание в соответствующем разделе. Данные не являются статичными, они оказывают определяющее влияние на P&L продукта, принимаемые решения по развитию его жизненного цикла, а потому должны иметь явно выраженную продуктовую направленность, входить в состав продукта, соответственно, и в его архитектуру. Обратим внимание читателя на то, что поскольку современные архитектурные подходы определяют данные как продукт, то указанный продукт данных может иметь жизненный цикл, отличный от общего жизненного цикла продукта организации, в состав которого он входит. Корректная синхронизация жизненных циклов продукта и продукта данных является ответственностью как продуктовой команды, так и архитектора.

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

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

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

На данном этапе мы рассмотрели концептуальную архитектуру продукта, максимально близкую к его бизнес-архитектуре. Именно поэтому мы не разделяли на Рисунке 2 уровни архитектуры на составляющие. Мы лишь отметили условными обозначениями основные задачи каждого уровня: обработка логики или работа с данными. Но при дальнейшей детализации архитектуры вопросы структуризации каждого уровня выходят на первый план. Остановимся на них подробнее.

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

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

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

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

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

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

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

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

Вторая часть примера детализации архитектуры продукта схематично представлена на Рисунке 4.

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

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

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

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

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

Мы уже отмечали по ходу настоящей главы, что участниками создания ценности могут быть и внешние по отношению к продукту элементы. Например, в кредитном продукте, предоставляемом финансовой организацией, немаловажную роль играет информация, получаемая о клиенте, созаемщиках, поручителях из внешних банков кредитных историй. Данная информация получается в рамках интеграционного взаимодействия продуктового решения с внешними информационными системами, зачастую находящимися за пределами организации, создающей и развивающей конкретный продукт. В такой ситуации и организация в целом, и конкретная продуктовая команда не могут влиять на уровень предоставления внешнего сервиса. Безусловно, существуют контракты на обслуживание, но ценность, предоставляемая клиентам и партнерам, не опирается на контракты, заключаемые организацией, пусть они и однозначно влияют на P&L. В эпоху дистанционных каналов обслуживания любая задержка в получении данных и предоставлении на их основании информации клиенту может оказаться фатальной с точки зрения конкурентоспособности всей организации. Поэтому при детализации слоя интеграции необходимо указать в контексте архитектуры не только интеграционную логику, ответственную за получение данных из внешних источников и отправку в них требуемой информации, но и механизмы, обеспечивающие производительность и надежность детализируемого слоя. В нашем примере, схематично показанном на Рисунке 4, в качестве указанного механизма используется кэширование. При этом для наполнения кэш и обеспечения максимально слабой связности продукта с внешними решениями используется механизм событийного обмена. Подчеркнем, что мы рассматриваем здесь случай внешнего по отношению к организации интеграционного взаимодействия, но приведенные рассуждения справедливы и для интеграций внутренних, когда взаимодействие, например, может осуществляться между несколькими продуктовыми решениями. Принципиальное отличие будет в таком случае заключаться лишь в большей степени влияния на уровень доступности взаимодействующих решений.

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

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

По ходу изложения, представленного в книге «Архитектура цифровых платформ. От настоящего к будущему», мы описывали различия между архитектурным подходом времен SOA, подходом «множества платформ» и современной платформенной автоматизацией. Рассмотрим приведенный выше пример архитектуры продукта в приложении к трем указанным подходам. И начнем с «седой старины» – сервис-ориентированной архитектуры, SOA. Иллюстративно данный подход отображен на Рисунке 5, при этом за основу взят немного измененный Рисунок 2 из книги «Архитектура цифровых платформ. От настоящего к будущему».

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

• Система 1 отвечает за логику представления и реализует канальную и канало-специфичную продуктовую логику.

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

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

• Система 4 отвечает за эффективное хранение данных о продукте.

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

Рисунок 5. Продуктовая автоматизация при использовании концепции SOA

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

Мы уже неоднократно отмечали, что ценность продукта является комплексной, а потому запросы заинтересованных лиц, связанные с изменениями, например рыночной конъюнктуры, приводят к столь же комплексным изменениям продуктовой автоматизации: новые требования к автоматизации могут затрагивать и фронтальное представление продукта, и структуру автоматизируемой продуктовой логики, например, добавляя новые процессы в структуру жизненного цикла продукта, и требовать дополнения продукта новыми внешними данными. Хранение продуктовых данных также в таком случае может требовать обновления. Если каждая из отвечающих за продуктовую автоматизацию информационных систем реализована в собственной архитектурной и технологической парадигме, то и развивает каждую из систем своя команда, состоящая из различных специалистов с самыми разными компетенциями. В таком случае каждое значимое изменение, вносимое в продукт, будет требовать синхронизации деятельности упомянутых команд развития, что является далеко не самым простым процессом, требующим серьезных затрат временных, трудовых и финансовых ресурсов. Очевидно, что в этом случае говорить о лучших рыночных значениях показателя time-to-market не приходится. И P&L продукта в таком случае претерпевает самое драматическое изменение.

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

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

В книге «Архитектура цифровых платформ. От настоящего к будущему» мы также описывали подход к автоматизации, который характеризовали как «множество платформ». Данный подход характеризуется тем, что применяющие его организации создают отдельные программные платформы для того или иного уровня автоматизации. Иногда платформы выделяют по архитектурным уровням, иногда по бизнес-задачам. Так и появляются «омниканальные платформы», «учетные платформы», «платформы CRM», зачастую слабо связанные друг с другом. Рассмотрим применение данного подхода к автоматизации продукта и его концептуальной архитектуре, описанным выше. Схематично оно приведено на Рисунках 6 и 7. Мы вновь разделяем детализацию концептуальной архитектуры продукта на две иллюстрации, чтобы обеспечить наглядность последних.

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

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

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

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

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

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

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

• Сервис управления открытыми API.

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

• Сервис хранения информации, для которого используются две реализации: реализация хранения в кэш и в реляционных СУБД.

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

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

• Сервис хранения информации, для которого используются три реализации: реализация хранения в кэш, в реляционных СУБД и в распределенной файловой системе.

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

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

• Сервис хранения информации, для которого используются две реализации: реализация хранения в кэш и в нереляционных СУБД.

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

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

• Сервис хранения информации, для которого используется реализация хранения в реляционной СУБД.

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

• Сервис управления бизнес-процессами, для которого представлены две реализации: оркестровка и хореография.

Приведенный объемный пример убедительно свидетельствует: на разных уровнях продуктовой автоматизации используются схожие по применимости платформенные сервисы. Но в случае подхода «множества платформ» они предоставляются разными платформами. Соответственно, их способ реализации и варианты использования могут принципиально отличаться. Но в таком случае члены продуктовой команды должны владеть методиками использования каждой платформы, понимать различия, например, сервисов хранения данных в реляционных СУБД на уровне каждой из набора платформ. И внесение значимого изменения в продукт оказывается не менее, а зачастую и более сложным, нежели в парадигме SOA. Поэтому говорить о применимости подхода «множества платформ» в современной продуктовой автоматизации принципиально неверно.

Действительно, в случае значимого изменения, вносимого в продукт, продуктовые команды сталкиваются с необходимостью вносить изменения в использование платформенных сервисов, предоставляемых четырьмя платформами. Предположим, что следствием требуемого изменения становится вопрос развития продукта с точки зрения значимого повышения производительности. Подобное повышение может оказаться связанным с использованием кэширующих компонентов. Реализации платформенных сервисов, использующие кэширующие компоненты, предоставляются тремя платформами: омниканальной, интеграционной и учетной. Соответствующие сервисы могут быть реализованы каждой платформой с использованием различных технологических решений (например, Apache Ignite, Infinispan, Redis, Hazelcast и т. д.), для них могут применяться различные топологии развертывания, потребителям могут быть доступны отличные друг от друга и жестко специфицированные конкретной платформой варианты использования. Таким образом, существенное изменение в продукте, связанное с повышением производительности, потребует погружения продуктовой команды в три принципиально различные реализации сервиса хранения информации в кэш. Аналогичная ситуация будет наблюдаться в случаях хранения информации в реляционных базах данных, использования событийного взаимодействия и т. д. Продуктовые команды будут тратить временные, трудовые и финансовые ресурсы на корректный выбор конкретного платформенного сервиса, а не на реализацию собственно продуктовой логики, что крайне негативно скажется на P&L продукта.

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

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

Учитывая приведенную ранее детализацию архитектуры продукта, мы можем сформулировать использование платформенных сервисов платформенным приложением, реализующим продукт (см. Рисунок 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.

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

в архитектуре продукта (часть 1)

Рисунок 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 продукта зависит от способности реагировать на вновь возникающие вызовы. Проекция каждого вызова на тот или иной архитектурный уровень будет различной. Поэтому не только сам продукт, но и платформенные сервисы должны обеспечивать необходимую гибкость – не может сервис кэширования единственным образом функционировать для задач канального отображения продукта и его интеграционных зависимостей. Платформенный сервис должен содержать набор топологий и вариантов использования, позволяющих адекватно применять его на всех уровнях продуктовой автоматизации. Выбор же конкретных условий использования сервиса осуществляет продуктовая команда, владеющая необходимыми компетенциями в части платформы.

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

Хочется надеяться, что читатель получил исчерпывающее обоснование нашего возражения на его восклицание, озвученное в начале настоящей главы. Вопросы архитектуры современного продукта только ею не исчерпываются, они будут рассматриваться и далее в книге. Но сейчас, изучив базовые аспекты архитектуры продукта, читатель готов задать новый вопрос: «Так что, неужели необходимо осуществить реализацию всех уровней архитектуры продукта, чтобы начать предоставлять ценность клиентам и партнерам, ведь это так дорого и долго?»

Мы поспешим успокоить читателя. Мы не для того обсуждаем необходимость предоставления самостоятельной ценности клиентам в качестве обязательной характеристики продукта, не для того говорим о гибких методах разработки, не для того подчеркиваем необходимость трансформации мышления организации, предоставляющей продукт, чтобы в завершение предложить годами ожидать создание этой самой ценности. Разумеется, в запущенной ситуации, например, если организация длительное время вкладывалась исключительно в «лоскутную» автоматизацию, временные и финансовые ресурсы, требуемые для осуществления истинной цифровой трансформации, могут оказаться значительными. К сожалению, так происходит всегда: как заноза, вовремя не извлеченная, может привести к необходимости сложной операции и долговременного восстановления, так и пренебрежение тенденциями развития цифрового мира требует серьезных инвестиций в преодоление закономерно возникающего отставания от лидеров. Но при этом необходимо принимать во внимание и тот факт, что вновь создаваемые решения, предполагающие продуктовую направленность, должны учитывать рыночные тенденции, изменение клиентских потребностей, сами формировать лучший пользовательский опыт и т. д. И для этого необходимо обеспечивать скорейший вывод продуктов на рынок, лучшие показатели time-to-market, что зачастую противоречит полноценной готовности всех архитектурных слоев, разбиравшихся для абстрактного продукта по ходу настоящей главы.

Как же совместить скорейший вывод продукта на рынок и его качественную проработку, учитывающую необходимость корректной архитектуры? Ответ на этот вопрос уже содержится в методиках гибких практик и их адаптациях к применению в крупных компаниях. Продуктовые команды должны создавать MVP (minimum viable product, минимально жизнеспособные версии продуктов), позволяющие оценить реакцию рынка на продукт, скорректировать его в соответствии с пользовательскими предпочтениями и рыночными тенденциями. Но здесь важно не забывать о том, что MVP непременно должен быть верифицируемым. Например, если MVP запускается на некой выделенной группе пользователей, то результат его отработки должен быть применимым и для рынка в целом, не может считаться удовлетворительной ограниченная группа, которая выбрана таким образом, что не отражает последующее рыночное применение полноценной версии продукта. Но, кроме этого, верификация должна осуществляться и в части технической готовности: если MVP показывает себя удачно, но для полноценного запуска необходимо пересмотреть всю архитектуру продукта, с нуля вести его разработку, то такой MVP не может считаться верифицируемым: он не несет ценности для клиентов, а лишь потребляет значимые временные, трудовые и в конечном итоге финансовые ресурсы организации. Как же определить верифицируемость MVP?

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

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

Рисунок 11. Поэтапная реализация продукта

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

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

Цифровые продукты и ключевые тренды развития архитектуры

Ключевые тренды развития архитектуры в концепции цифровых продуктов

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

Напомним основные тренды развития архитектуры:

• Открытый код.

• Распределенность.

• Бизнес-процессы.

• Данные.

• Искусственный интеллект.

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

Использование решений с открытым исходным кодом позволило существенно повысить производительность труда в сфере информационных технологий. Поскольку же данная сфера настолько пронизывает современный мир, что мы с первой нашей книги говорим о современном мире как о цифровом, то можно сделать вывод, что использование решений с открытым исходным кодом привело к общему повышению производительности труда во всем мире, во всех сферах человеческой деятельности. Суть указанного повышения производительности труда заключается в том, что в создание, развитие и внедрение технологий с открытым исходным кодом вовлечено на порядки (и это не фигура речи) больше специалистов, нежели в закрытые (vendor-lock) решения. Данное вовлечение позволяет формировать существенное большее разделение труда и более длинные технологические цепочки, нежели при использовании закрытых решений, что и приводит к повышению эффективности в соответствии с классическими экономическими теориями. На сегодняшний день в среде экономистов, философов, политологов ведутся споры об эффективности роста производительности труда в XX—XXI веках, имеющих ключевое значение для эпохи цифровизации. Мы не будем в настоящем труде обсуждать масштабы этого роста, оставляя данный вопрос специалистам. Мы принимаем сам факт роста за данность, а поскольку современный мир стал цифровым миром, роль информационных технологий в котором огромна, то констатируем, что значимая часть упомянутого роста производительности (каким бы он ни был) обусловлена применением именно программного обеспечения с открытым исходным кодом.

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 12. Продукт и ключевые тенденции развития

архитектуры

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

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

Цифровые продукты и открытый код

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

Современная экономическая теория, восходящая еще к итальянским натурфилософам, таким как Антонио Серра, выводит повышение эффективности из увеличения разделения труда – длинные экономические цепочки, предполагающие задействование большего числа участников, позволяют резко повышать общую эффективность. Серьезнейший вклад в развитие данной теории и ее систематизацию внес Адам Смит и его последователи. Есть представители и отечественной школы, внесшие свою лепту в развитие указанного научного направления, такие как М. Л. Хазин. Целью настоящей книги не является повторение всех их логических умопостроений, мы принимаем их выводы: увеличение разделения труда ведет к повышению производительности. И для области информационных технологий данный факт исключительно важен. Открытые решения позволяют вовлечь в их развитие такое количество специалистов со всего мира, которое невозможно ни для одного закрытого программного обеспечения, сколь бы крупная корпорация его ни развивала. И это принципиальный момент – открытые решения обеспечивают уровень производительности труда, недоступный для закрытых решений. Именно подобный уровень производительности труда и привел крупнейших игроков ИТ-рынка в стан сторонников открытого кода.

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

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

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

И поскольку настоящая книга, как и две предыдущие, посвящена архитектуре, то и объяснение, даваемое автором, также будет базироваться именно на архитектуре.

Для начала вернемся к детализации концептуальной архитектуры продукта, приведенной на Рисунках 9 и 10 и описанной в предыдущей главе. В соответствии с описанием в архитектуре задействованы такие программные компоненты и фреймворки, как:

• Языки программирования высокого уровня (в том числе позволяющие разрабатывать легковесные фронтальные решения).

• Реляционные СУБД.

• Нереляционные СУБД.

• Потоковое программное обеспечение.

• Кэширующие компоненты.

• BPM движки.

• Программное обеспечение для управления открытыми API.

• Распределенная файловая система.

• И т. д.

Для всех указанных пунктов существует свободно распространяемое программное обеспечение с открытым исходным кодом, позволяющее решать задачи по автоматизации продуктов. Пример такого сочетания технологий приведен на Рисунке 13. В очередной раз оговоримся, что мы приводим иллюстративный пример, а не разбираем конкретные случаи продуктовой разработки. Взаимодействие, показанное для технологий реализации, также является иллюстративным и может отличаться при конкретной продуктовой автоматизации. По сравнению с ранее приведенным примером мы на Рисунке 13 заменили BPM Camunda на BPM Kogito, чтобы следовать принципу выбора максимально открытой лицензии, тем более в главе, посвященной открытому коду.

Рисунок 13. Пример перечня технологий с открытым исходным

кодом для продуктовой автоматизации

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

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

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

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

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

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

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

На Рисунках 14 и 15 представлен пример реализации архитектурных уровней продуктовой логики с использованием открытого программного обеспечения. Еще раз подчеркнем – это именно упрощенный пример. Мы не включаем в него вопросы сбора логов, трассировки, аудит, аутентификацию, авторизацию, управление секретами, события клиентских приложений и т. д. Но мы видим, что открытые решения в состоянии покрыть полную реализацию архитектуры end-to-end продукта. Разумеется, в таком подходе существуют и свои собственные ограничения – пока в цифровом мире не создана «цифровая серебряная пуля».

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

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

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

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

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

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

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

Внимательный читатель наверняка задаст нам и еще один каверзный вопрос: «Вы все время говорите о ценности, предоставляемой продуктом, о P&L продукта, но в то же время называете продуктом свободно распространяемое программное обеспечение с открытым исходным кодом – какой же это продукт?» Мы незамедлительно дадим ответ, что открытый код безусловно является продуктом, и ниже объясним почему.

Создание и развитие программного обеспечения с открытым исходным кодом не является бесплатным, ведь в данный процесс привлекается значительная экспертиза. И, как показывает практика, вложения в открытое ПО осуществляют технологические гиганты, лидеры рынка ИТ. Зачем же они это делают? Основой их мотивации является все та же теория разделения труда. Лидеры рынка создают длинные технологические цепочки, обеспечивают высокую производительность труда при создании открытого программного обеспечения, гарантируют эффективность развития последнего. При этом они, развивая интересующее их ПО, обладают высокими компетенциями по части его использования и создания на его основе продуктов заказчиками. И таким образом осуществляется возврат инвестиций – путем включения открытого ПО в проприетарные продукты, оказание консалтинговых услуг, услуг по внедрению и адаптации программных продуктов, монетизации соответствующей экспертизы. Участниками процесса развития являются и заказчики, которые могут как добавлять новые варианты использования открытого программного обеспечения, так и включать новые дополнения в его состав. Просто цикл создания ценности стал длиннее и обширнее, нежели это выглядело в случае проприетарного программного обеспечения. И поэтому открытое программное обеспечение безусловно является продуктом. Ценность же оно предоставляет заказчикам, позволяя им создавать гибкие, надежные и современные цифровые продукты.

Внимательный читатель может прервать наши рассуждения злободневным саркастическим вопросом: «Неужели мы просто так разворачиваем открытое программное обеспечение, например, представленное на рисунках выше, и получаем современные цифровые продукты?» Мы понимаем и принимаем сарказм, выраженный в данном вопросе. Разумеется, и само программное обеспечение корректно развернуть и подготовить к использованию зачастую совсем непросто, особенно если речь идет о сложном корпоративном ИТ-ландшафте, содержащем как унаследованные, так и устремленные в будущее компоненты. Но и просто набор программного обеспечения не составит продукта для компании, осуществившей развертывание выбранного технологического стека на собственной или арендованной ИТ-инфраструктуре. Отвечая на вопрос читателя, мы вернемся к книге «Архитектура цифровых платформ. От настоящего к будущему». Аналогичный вопрос читатель задавал относительно платформы. Мы же указывали, что при создании и развитии платформы, во-первых, осуществляется технологическая унификация, во-вторых, формируются варианты использования технологий. И это требует серьезного интеллектуального ноу-хау, серьезных инвестиций от компании, создающей платформу. С продуктами ситуация во многом аналогичная. Цифровой продукт представляет собой независимую ценность для клиентов и/или партнеров компании, создающей и развивающей продукт. И для обеспечения этой ценности осуществляется автоматизация деятельности компании. Формат автоматизации определяется процессами компании. Программное обеспечение в данном случае используется в качестве инструмента. Мы аргументируем выбор в пользу программного обеспечения с открытым исходным кодом на основании той гибкости, которую оно несет продуктам. Высокая скорость внесения изменений, множество топологий развертывания, большое число вариантов использования позволяют создавать максимально адекватные требованиям рынка продукты, более того, создавать продукты, меняющие рынок. Например, 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 с целью избежать избыточного загромождения иллюстраций).

Рисунок 16. Пример технологического «разнообразия»

продуктовой автоматизации при использовании ПО

с открытым исходным кодом (часть 1)

Рисунок 17. Пример технологического «разнообразия»

продуктовой автоматизации при использовании

ПО с открытым исходным кодом (часть 2)

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

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

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

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

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

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

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

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

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

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

Цифровые продукты и распределенность

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

Рассмотрение проблематики распределенности в контексте продуктового подхода начнем с распределенности организационной. Мы уже неоднократно отмечали как по ходу текущего изложения, так и предыдущих книг, что в настоящее время стандартом де-факто стали гибкие практики разработки, ставящие продукт во главу угла. «Вот и замечательно, в соответствии с гибкими практиками сразу создается ценность для клиента. И нет никаких проблем!» – воскликнет нетерпеливый читатель. И будет неправ. К сожалению, проблемы только начинаются.

Адам Смит на научной основе доказал, и его тезисы пока не опровергнуты ни для одной сферы деятельности, что увеличение разделения труда повышает общую производительность труда. Чем более длинными являются цепочки разделения труда, тем они более эффективны. Но великий шотландец также показал, что при этом растут риски каждого отдельного участника указанной цепочки разделения труда. Каждый участник становится зависимым как от поставщиков, так и от потребителей. Чем больше и тех и других, тем выше риски участника цепочки разделения труда. Покажем это на примере отрасли информационных технологий, взяв за основу базовую детализацию концептуальной архитектуры продукта, которую мы приводили ранее по ходу настоящей книги (Рисунки 9 и 10). И добавим на эти рисунки командное распределение. Предположим, что каждый уровень архитектуры реализуется собственной командой разработки. При этом мы продолжаем рассмотрение с учетом того, что, как и ранее, при создании и развитии продукта используется платформенный подход. Иллюстративно наше представление приведено на Рисунках 18 и 19.

Мы предполагаем, что при разработке продукта используется платформенный подход, поэтому указали на Рисунках 18 и 19 номера используемых платформенных сервисов в соответствии с ранее разобранными примерами (см. Рисунки 8—10). Также мы добавили на Рисунки 18 и 19 команды разработки продукта, специализирующиеся на разных его составляющих, соответствующих ранее выделенным архитектурным уровням.

Рисунок 18. Реализация архитектуры продукта

командами разработки (часть 1)

Рисунок 19. Реализация архитектуры продукта

командами разработки (часть 2)

Фронтальное и канальное представление продукта, а также канало-специфичную логику реализует команда фронтальной разработки, специализирующаяся на создании легковесных приложений, соответствующих требуемым для продукта каналам обслуживания, а также на предоставлении внешних API. Такая команда должна содержать дизайнеров, специалистов по пользовательскому интерфейсу, разработчиков фронтальной логики (со знанием таких фреймворков разработки, как, например, Angular), разработчиков связанной с фронтальными компонентами прикладной логики, например, с использованием Java или. NET, специалистов DevOps и т. д. Также, учитывая специфику детализируемой архитектуры, члены команды должны обладать знаниями в кэширующих компонентах, потоковом программном обеспечении, управлении API и т. д.

Оперативное и архивное хранение продуктовых данных (оперативное представлено на Рисунке 18, архивное – на Рисунке 19) реализуется силами команды логики хранения. Такая команда должна содержать в своем составе разработчиков, владеющих языками программирования высокого уровня, такими как Java или C#, специалистов DevOps, специалистов со знанием различных технологий долговременного хранения, кэширующих компонентов, потокового программного обеспечения и т. д.

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

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

Итогом подобного разделения становится четко определенная граница работ каждой из команд. Наличие же платформы (используемые платформенные сервисы представлены на Рисунках 18 и 19 в соответствии с нумерацией, приведенной на Рисунке 8) обеспечивает технологическую и методологическую унификацию работы команд. Казалось бы, осталось совсем немного – реализовать ценность, требуемую пользователям. И тут мы подходим к самому главному – приведенная конфигурация оказывается неработоспособной или в лучшем случае крайне неэффективной в современном цифровом мире.

Ни одна из приведенных выше команд не создает самостоятельной ценности: ценность предоставляет продукт, а не его отдельный слой. Мы уже разбирали данный факт ранее на примере кредитного продукта. Ценность для клиента заключается в самом продукте (кредите), а не может исчерпываться визуальным представлением заявки на кредит и даже самой заявкой. Заявка на кредит может представлять собой один из этапов жизненного цикла продукта (по опыту автора, далеко не самый трудоемкий), но лишь один из. И отсюда следует непреложный вывод – все указанные на Рисунках 18 и 19 команды являются частями целого – продуктовой команды разработки. Здесь мы и приходим к организационной распределенности. Забегая вперед, отметим, что Рисунки 18 и 19 демонстрируют и технологическую распределенность, но последнюю детально мы рассмотрим несколько позже.

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

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

Что же это означает с точки зрения концепции и архитектуры продукта, которым посвящена настоящая книга? Архитектура продукта должна поддерживать согласованную работу распределенной команды. Данное утверждение означает, что на уровне архитектуры должны определяться компоненты, которые могут выделенно реализовываться членами команды, а затем составлять итоговый готовый продукт. При этом компоненты, определяемые в составе архитектуры продукта, должны допускать реализацию с прозрачным планом по спринтам в соответствии с гибкими методологиями разработки. То есть уже по итогам одного-двух спринтов работы над компонентом исполнитель должен предоставлять хотя бы первичные работоспособные результаты, например, в формате MVP. При этом компоненты должны быть максимально независимы друг от друга, чтобы обеспечивалась независимая работа членов команды и сокращался объем синхронизирующего их «микроменеджмента». Проиллюстрируем это на примере (схематично представлен на Рисунке 20).

Рисунок 20. Пример компонентной структуры продукта

На Рисунке 20 показан пример компонентов продукта – электронной банковской гарантии. Банковская гарантия содержит структуру и описание самого объекта, представляющего гарантию, заявку на предоставление продукта, формируемую клиентом, объекты и действия, связанные с процедурой оценки и выставления рейтинга заявке (скоринг). Кроме того, с гарантией должен быть ассоциирован клиент, а также файловые вложения, содержащие, например, копии документов, необходимых для обеспечения исполнения процессов жизненного цикла продукта. Сразу оговоримся, что подобное разбиение продукта по составляющим компонентам не является единственно верным, а представлено в настоящей главе исключительно для примера.

Внимательный читатель незамедлительно поинтересуется структурой каждого компонента, а также самим смыслом разделения продукта на подобные компоненты. Отметим, что разделение на компоненты имеет своей целью архитектурное разграничение участков работ над продуктом, позволяющее поддержать согласованную деятельность многочисленных команд развития. Если же говорить о структуре компонентов, то в общем случае она отвечает структуре всего продукта, но при этом отдельные архитектурные уровни могут быть не представлены в том или ином компоненте. Наличие или отсутствие архитектурных уровней, а также их наполнение логикой определяются функциональными требованиями к продукту. А наполнение уровней с технологической точки зрения в составе компонентов определяется нефункциональными требованиями к продукту (например, требованиями к производительности и надежности). Ориентируясь на детализацию концептуальной архитектуры продукта, представленную на Рисунках 18 и 19, мы отмечаем, что в общем случае компоненты продукта должны содержать уровни канальной и канало-специфичной логики, продуктовой логики и логики управления бизнес-процессами, интеграционной логики, оперативного и архивного хранения продуктовых данных.

Если проецировать приведенные выше утверждения на компонентную структуру продукта «Электронная банковская гарантия», схематично представленную на Рисунке 20, то можно сделать некоторые выводы о ключевых архитектурных требованиях к компонентам:

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

• Компонент «Скоринг заявки» должен обладать развитой продуктовой логикой и логикой управления бизнес-процессами, при этом для данного компонента исключительно важен уровень интеграционной логики – зачастую при проведении процесса оценки привлекается внешняя по отношению к организации информация.

• Для компонента «Вложения к заявке» исключительно важны задачи оперативного и особенно архивного хранения – как правило, файловые вложения являются весьма объемными и дорогостоящими с точки зрения хранения.

• Компонент «Банковская гарантия» должен обеспечивать исполнение процессов жизненного цикла продукта, а потому важнейшим архитектурным слоем для него является управление бизнес-процессами вкупе с прикладной продуктовой логикой.

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

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

Также отметим, что в примере рассматривается продукт именно «электронная», а не «цифровая» банковская гарантия, поскольку для последней архитектурное представление будет во многом отличаться.

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

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

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

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

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

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

Итак, мы расширим пример представления платформенных сервисов. Схематично расширенный пример изображен на Рисунке 21. Структура реализаций платформенных сервисов выбрана таким образом, чтобы соответствовать технологическому многообразию, проиллюстрированному ранее на Рисунках 16 и 17.

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

Наиболее существенным в нашем примере в контексте экосистем разработки является их значимое отличие: различные виртуальные машины, используемые библиотеки, разная детализация сборки приложений (при внешнем сходстве) и т. д. И в подобных условиях платформенный подход должен поддерживать весь использующийся инструментарий. Для упрощения же использования платформы предлагается применять «фасадные» компоненты (мы берем название от шаблона проектирования «Фасад», подробно рассмотренного в книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования», авторы Эрих Гамма, Ричард Хельм, Ральф Джонсон, Джон Влиссидес), экранирующие пользователей, в качестве которых выступают в данном случае платформенные приложения, от деталей реализации. Именно в этой экранизации и состоит важность платформенного сервиса. Он обозначен на Рисунке 21 как 0. Отметим, что мы рассматриваем концептуальную архитектуру, при дальнейшей же архитектурной детализации и в рамках постановки задач на разработку «Платформенный сервис» совершенно не обязательно будет представлен единой сущностью. Например, в рамках детализации компонентной архитектуры он может состоять из набора логических сущностей, зачастую имеющих прямое отношение к разрабатываемым физическим сущностям. На Рисунке 21 он для упрощения показан единой концептуальной сущностью, предоставляющей два типа платформенного SDK клиентам. Предвосхищая потенциальное саркастичное замечание внимательного читателя о переизбытке сущностей различных типов, отметим, что здесь все упомянутые сущности являются необходимыми и полностью соответствуют «бритве Оккама». Подчеркнем, что мы не вводим дополнительно к платформенному SDK платформенный API для упрощения примера.

Конкретные платформенные сервисы в нашем примере, схематично проиллюстрированном Рисунком 21, существенно детализированы и расширены по сравнению с примером, приведенным на Рисунке 8. Детализация основана на компетенциях команд, задействованных при реализации продуктов (рисунки 16 и 17). Рассмотрим эту детализацию подробнее.

• Первым из платформенных сервисов на Рисунке 21 представлен сервис работы с данными (сервис 1), посредством которого унифицируются операции с данными. Он содержит четыре реализации:

○ Сервис работы с реляционными данными (1.1), используемый для работы с данными, хранящимися в реляционных СУБД, представленный единственной технологической реализацией 1.1.1 – на основе СУБД PostgreSQL.

○ Сервис работы с нереляционными данными (1.2), используемый для работы с данными, которые, например, ввиду требований к обеспечению эластичного масштабирования, хранятся в нереляционных СУБД. Данный сервис содержит две технологические реализации – на основе СУБД 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. Для удобства восприятия использование платформенного сервиса 0 не показано, при этом в реальности он задействован при предоставлении всех остальных платформенных сервисов потребителям. Для обозначения продукта электронной банковской гарантии на Рисунках 22 и 23 используется сокращение-аббревиатура ЭБГ.

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

Рисунок 23. Пример применения платформенного подхода

при реализации двух продуктов (часть 2)

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

• На уровне фронтальной и канальной логики обоими продуктами используются платформенные сервисы работы с данными в части реляционных СУБД и кэширующих компонентов, при этом команда кредитного продукта использует реализации 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) позволяет членам продуктовых команд при необходимости использовать платформенные сервисы в каждом компоненте цифрового продукта. Проиллюстрируем это примером для продукта электронных банковских гарантий. Схематично пример приведен на Рисунке 24.

Рисунок 24. Использование платформенных сервисов

продуктовыми компонентами

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

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

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

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

• Компонент «Банковская гарантия» обеспечивает исполнение процессов жизненного цикла продукта, а потому важнейшим архитектурным слоем для него является управление бизнес-процессами вместе с прикладной продуктовой логикой. Ввиду всего вышеперечисленного при реализации компонента используются платформенный сервис работы с данными в части поддержки реляционных СУБД, сервис потоковой передачи данных, сервис управления бизнес-процессами с поддержкой оркестровки и хореографии.

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

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

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

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

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

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

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

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

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

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

• Множество поддерживаемых платформой технологических реализаций позволяет формировать продуктовые команды таким образом, чтобы снижать стоимость указанных команд как в части снижения требований к компетенциям их членов (ввиду реализации трудоемких инфраструктурных задач на уровне платформы), так и в части набора специалистов с более дешевым техническим бэкграундом, если последний поддерживается на уровне платформы. Данный подход также положительно влияет на P&L продукта.

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

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

На этом мы завершаем рассмотрение организационной распределенности как одного из ключевых трендов развития архитектуры и переходим к распределенности технологической.

Современные технологии изменяют мир таким образом, что получение доступа к цифровым продуктам становится возможным в любой точке земного шара, причем практически мгновенно. Современный цифровой мир является миром дистанционных каналов, что в огромном количестве случаев стирает различия между крупными и мелкими компаниями в части доступности их продуктов и услуг для клиентов и партнеров. Например, если 15 лет назад исключительно принципиальным при выборе финансовой организации для обслуживания было количество точек присутствия (отделений, банкоматов и т. д.) даже на уровне конкретного региона, то на сегодня данный параметр не является столь существенным в части доступности для клиентов и уступил свое место в списке приоритетов качеству предоставляемых организацией продуктов и их удобству с точки зрения конкретного клиента. Однако у каждой медали есть обратная сторона. Современный продукт должен быть доступен посредством дистанционных каналов в режиме 24х7, обеспечивать соответствующий уровень непрерывности, производительности и надежности. И это предъявляет серьезные требования к архитектуре продукта. Архитектура продукта должна быть распределенной – поддерживать распределенное предоставление и исполнение продукта.

Поскольку мы рассматриваем архитектуру обобщенного продукта без свойственной различным организациям конкретики, то для примера возьмем уже обсуждавшийся выше продукт – электронную банковскую гарантию. Детализация концептуальной архитектуры данного продукта представлена на Рисунках 25 и 26.

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

Рисунок 26. Детализация концептуальной архитектуры

продукта «Электронная банковская гарантия» (часть 2)

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.