Цифровой продукт XXI века. Концепция и архитектура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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