Оглавление

Введение

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

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

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

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

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

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

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

• И т. д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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