- -
- 100%
- +
Корректор Лилиана Голава
© Андрей Николаевич Трушкин, 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 и сделана соответствующая оговорка.