Цифровой продукт 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) начинается именно с указанного визуального представления, поэтому и в концептуальной архитектуре оно незамедлительно занимает свое законное место. Естественно, в современном мире множества каналов визуальное представление должно быть реализовано с использованием необходимого объема канальной логики в формате фронтального и канального представления. Отметим, что визуальное представление продуктов может быть доступно не только клиентам и/или партнерам, но и сотрудникам организации. Структура же конкретных представлений определяется ролевой моделью и конкретными требованиями, предъявляемыми к функциональности ролей в разрезе продукта (например, полномочиями пользователя, оператора, администратора дистанционных каналов обслуживания и т. д.).

Продолжить чтение