Читать книгу: «Цифровой продукт XXI века. Концепция и архитектура», страница 3

• Продукт использует сервис управления бизнес-процессами (Сервис 4 на Рисунке 8), содержащий две реализации (при этом обе реализации основаны на идентичном программном обеспечении BPM Camunda):

○ Сервис оркестровки бизнес-процессов (4.1).

○ Сервис хореографии бизнес-процессов (4.2).

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

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

Далее рассмотрим исключительно важный вопрос: каким же образом продукт может использовать платформенные сервисы в своей архитектуре? Схематично логика этого использования представлена на Рисунках 9 и 10, которые иллюстрируют развитие реализации продукта от подхода «множества платформ» к применению современной цифровой платформы. Нумерация используемых платформенных сервисов соответствует Рисунку 8.

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

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

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

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

На уровне фронтального и канального представления используются платформенные сервисы хранения данных в реляционной СУБД (1.1) и кэш (1.4), журнальной передачи информации (2.1) и управления открытыми API (3). При хранении продуктовых данных используются платформенные сервисы хранения данных в реляционной СУБД (1.1) и кэш (1.4) и журнальной передачи информации (2.1) (см. Рисунок 9).

На уровне продуктовой логики используются платформенные сервисы хранения данных в реляционной СУБД (1.1), журнальной передачи информации (2.1), управления бизнес-процессами в парадигме оркестровки (4.1) и хореографии (4.2). На уровне интеграции и наполнения данными используются платформенные сервисы хранения данных в нереляционной СУБД (1.2) и кэш (1.4), журнальной передачи информации (2.1). На уровне архивного хранения используется платформенный сервис хранения данных в распределенной файловой системе (1.3) (см. Рисунок 10).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Данные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

архитектуры

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

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