Поскольку платформа представляет собой среду создания и исполнения цифровых решений, а результатом исполнения цифровых решений является предоставление ценности клиентам и партнерам организации (то есть продуктов), то платформенные средства должны поддерживать все составляющие end-to-end продукта (все уровни максимально мелкой грануляции). Разумеется, частные продукты могут не обладать той или иной составляющей, но в общем случае продукты организации должны соответствовать ее специфике и быть достаточно комплексными, чтобы сохранять конкурентоспособность на рынке, а потому для них актуален максимум составляющих. Платформа же обязана поддерживать все составляющие, возможные для продуктов организации.
На основании предыдущего тезиса мы можем сделать важный вывод: платформа и продукты организации оказывают взаимовлияние друг на друга. При проектировании платформы архитектор, являясь лидером технологических изменений, обязан провести предварительное технологическое проектирование продуктов (действующих и потенциальных) организации, чтобы на их основе запланировать необходимый набор составляющих, поддерживаемых платформой (как мы помним, каждая составляющая характеризуется своим технологическим набором и вариантами его использования, диктующими, например, топологии развертывания). Аналогичным образом для продуктов должна производиться декомпозиция на составляющие, для каждой из которых определяется платформенный инструментарий, осуществляющий ее поддержку. Таким образом, формируется унифицированный подход к автоматизации продуктов.
Можно ли автоматизировать каждый end-to-end продукт независимо от других с точки зрения не только конкретной разработки, но и архитектуры (в том числе платформенной)? Конечно, можно. Но тогда пострадает эффективность работы организации в целом. В своей книге «Бесконечный матч» великий футбольный тренер В. В. Лобановский писал: «Не кажется ли вам странным, что в наше время унификации элементарных – не говоря уже о сложнейших – производственных и мыслительных процессов почему-то только к футболистам все еще предъявляются требования изобретать на ходу? Им вполне серьезно рекомендуют на ощупь отыскать позиции, с которых удобно воспользоваться прострельной передачей мяча с фланга или по наитию доходить до того, какой маневр и в какой фазе игры ведет к созданию численного превосходства в контратаке… Я не против того, чтобы так „творили“ на поле наши соперники. Увы, они этим не занимаются. На международной арене мы имеем дело с командами, которые не тратят ни мгновения на выбор коллективных решений, когда возникает знакомая тактическая ситуация». И в случае независимого продуктового проектирования мы оказываемся в аналогичной ситуации – начинаем «творить» продукты и их автоматизацию на ходу, каждый раз заново формируя грануляцию, выбирая средства автоматизации для каждого уровня, теряя эффективность. Подобное является недопустимой роскошью в современном цифровом мире. Думается, что организация, вынужденная работать на высококонкурентном рынке, не против, чтобы ее конкуренты «творили» подобным образом, но итог для рынка в целом будет критичным: компании, «творящие» автоматизацию своих продуктов, будут покидать его, а оставшиеся – останавливаться в своем развитии и деградировать в отсутствие конкуренции.
По итогам приведенных тезисов можно отметить, что платформа определяет набор инструментов создания и исполнения продуктов организации, при этом предлагает схожие наборы указанных инструментов для общих продуктовых составляющих (в нашем примере их четыре). То есть уже на уровне концепции платформенного подхода происходит снижение рисков для отдельных участников рабочего процесса (как конкретных специалистов, так и команд гибких практик) вследствие структуризации (составляющие продуктов) и унифицированной поддержки работы (общие наборы инструментов для продуктовых составляющих). При этом кроме собственно инструментов платформы предлагают и общие направляющие реализации продуктов, учитывающие опыт организации, риски использования тех или иных инструментов, проработанные варианты использования и т. д. И роль архитектора в данном случае крайне важна. Ведь именно на нем лежит задача технологического проектирования будущих продуктов организации, структуризация платформы, определение продуктовых составляющих, технологий их автоматизации (и применяемых топологий), выработка общих направляющих. Разумеется, архитектор не может быть надсмотрщиком, диктующим командам разработки правила их работы – указанные правила формируются в рамках рабочего диалога, отвечающего принципам открытого кода и открытой организации.
Важно отметить, что в разговоре об общих инструментальных наборах, предоставляемых платформами для автоматизации продуктовых составляющих, речь не идет о повторном использовании сервисов и компонентов в вульгарном смысле этого слова. В «Архитектуре цифрового мира» мы уже касались опасности бездумного повторного использования (или переиспользования). К сожалению, нельзя не отметить, что концепция переиспользования (именно в вульгарном смысле) продолжает оставаться популярной, что резко снижает эффективность цифровизации многих рыночных игроков. Итогом следования подобной абсурдной концепции становится позиционирование платформы в качестве овеществленного компонента ИТ-ландшафта, фактически информационной системы, что ранее уже отмечалось нами как одна из ключевых ментальных ошибок, допускаемых на пути реализации платформенного подхода. При вульгаризации принципа повторного использования, как правило, происходит следующее:
– Максимум компонентов, содержащих близкий функционал, выделяются в общие и «переиспользуются». Зачастую все такие компоненты становятся «платформенными». Так и появляется, например, «платформенный компонент Клиент», который зачастую либо не реализует требуемые функции платформенных приложений, либо является избыточным. В результате команды развития либо приходят к антипаттерну «Распределенный монолит», либо начинают создавать дублирующий функционал, не руководствуясь никакими общими направляющими и технологическими средами продуктов. Любой из приведенных вариантов кратно увеличивает требующиеся для реализации ценности трудозатраты и риски участников рабочего процесса, что недопустимо в современном цифровом мире, так как приводит к застою и деградации организаций, допустивших подобное.
• Продолжением предыдущего пункта, формулирующего чрезмерную перегрузку платформ несвойственными им компонентами, становится формирование платформенных команд, не создающих ценность и являющихся высококонкурентным ресурсом, что уже рассматривалось нами ранее в качестве крайне негативного фактора и барьера на пути интенсивного развития.
• Вульгарное толкование термина «повторное использование» приводит к тому, что возникает огромное количество распределенных компонентов, предоставляющих собственные API (различных версий), а также их потребителей, использующих различные версии указанных API. В подобных условиях формируются зависимости релизных циклов компонентов и платформенных приложений, что крайне негативно влияет на значение такого определяющего показателя эффективности, как время вывода продукта на рынок (time-to-market).
Перечисление негативных факторов, следующих из вульгаризации концепции повторного использования, можно продолжать, но смысл уже понятен: резкое усложнение релизных циклов, увеличение объемов регрессионного тестирования, сложность цифровых платформ, для которых формируются подобные факторы, сводит на нет концепцию платформы как ценностного мультипликатора. Поэтому при рассмотрении вопросов повторного использования, позволяющего повышать производительность цепочки разделения труда, необходимо придерживаться следующих ключевых положений:
• Платформа представляет собой среду создания и исполнения приложений, автоматизирующих продукты организации и предоставляющих ценность клиентам и партнерам. Следовательно, платформа не содержит прикладных компонентов (отвечающих за непосредственное создание ценности), она предоставляет опосредованную ценность.
• Ключевым свойством предоставления API платформенными компонентами является их встраиваемость: API предоставляется в формате встраиваемых библиотек, используемых платформенными приложениями. Указанный подход позволяет избегать необходимости пересборки приложений при обновлениях платформенных компонентов либо максимально снизить данную необходимость.
• Подсистемы, сервисы, компоненты и другие структурные составляющие платформы не предоставляются в виде единой сущности всем потребителям – они могут представлять собой наборы сущностей, при этом настройки каждой сущности (в том числе топология) могут адаптироваться под потребности потребителей (платформенных приложений).
• Кроме собственно технологических компонентов платформа предоставляет общие направляющие для потребителей, включающие (но не ограничивающиеся ими) варианты использования компонентов, рекомендации и другие материалы, позволяющие обеспечить максимально эффективное предоставление платформы платформенным приложениям.
Следуя вышеперечисленным положениям, мы можем разделить технологический и прикладной функционал, обеспечить независимость последнего, разделить релизные циклы компонентов, снизить потенциальные объемы регрессионного тестирования, а также адаптировать платформу под требования потребителей. Тем самым повышается производительность труда технологической цепочки создания ценности и снижаются риски ее участников. Важно отметить, что платформенный подход и принципы открытого кода дополняют друг друга, обеспечивая тот самый ценностный мультипликатор, о котором говорилось по ходу настоящего изложения. В результате организация, применяющая платформенный подход, достигает более высокого уровня конкурентоспособности по сравнению с теми своими конкурентами, кто либо игнорирует соответствующий подход, либо попадает в ментальные ловушки в ходе его применения.
Таким образом, следование платформенному подходу, реализация, внедрение и использование платформ позволяют не просто повышать эффективность цифровизации продуктов, предоставляемых организациями своим клиентам и партнерам. Платформы поддерживают распределенную структуру команд, обеспечивают вовлечение все большего числа участников в общие технологические цепочки, стирают между ними барьеры. Мы приходим к выводу: чем более полно внедряется современный платформенный подход, чем более современная (и устремленная в будущее) платформа используется в организации, тем в большей степени цифровая архитектура организации соответствует такой ключевой тенденции развития, как распределенность.
При этом для участников технологической цепочки платформа является открытой. Подробно открытость платформ мы рассмотрим в соответствующей главе. В контексте же распределенности отметим, что распределенные команды могут и должны становиться участниками развития платформы, дополняя ее необходимым им функционалом, публикуя его в доступном коллегам виде. Подчиняясь принципам открытого кода, платформа развивается ее же потребителями, в результате чего максимально полно отвечает их нуждам. Синергия публикуемых обновлений позволяет всем распределенным командам повышать свою эффективность, как следствие, растет производительность всей цепочки разделения труда.
Рассмотрим теперь поддержку платформами смысловой составляющей технологической распределенности. Последняя предполагает возможность реализации при помощи платформы таких платформенных приложений, которые могут исполняться в распределенном режиме, предоставлять сервисы клиентам и партнерам в любой точке земного шара. При этом мы должны учитывать, что посредством платформенных приложений переводятся в цифровой вид продукты организации, несущие непосредственную ценность клиентам/партнерам. Перечень продуктов не является законченным – организация постоянно создает новые продукты или вносит изменения в уже существующие, следя за рыночной конъюнктурой. Характеристики продуктов являются совершенно различными. Продукты, отвечающие структурной декомпозиции, показанной на Рисунке 5, могут кардинально отличаться друг от друга функциональным наполнением в рамках общих составляющих, автоматизация которых осуществляется с применением платформенного подхода. Примерами таких отличий могут стать сложность и специфика исполнения бизнес-процессов (например, количество шаблонов процессов и сложность схем продуктовых процессов, подлежащих автоматизации), доступность продуктов в различных множествах дистанционных каналов (подобная характеристика влияет на нефункциональные требования, но принимается на уровне владельца продукта, а потому исходно может считаться функциональной), характеристики аналитического учета и т. д. Таким образом, и требования продуктов к платформе также существенно отличаются.
Приведем следующий пример. Если в продуктах отличается набор дистанционных каналов предоставления, то при проектировании как фронтальной, так и иных составляющих необходимо учитывать детализацию соответствующего набора. Например, может оказаться, что один продукт предполагает предоставление ценности посредством каналов, не предполагающих аутентификации и авторизации клиентов, в то время как другой продукт доступен только авторизованным клиентам. Результатом данного отличия становится необходимость поддерживать принципиально разный уровень производительности при исполнении продуктовых решений (платформенных приложений). Речь идет не только о фронтальной составляющей – все составляющие продукта должны учитывать необходимость собственного корректного исполнения при соответствующих требованиях к производительности. Фронтальная составляющая должна обеспечивать время отклика, гарантирующее удовлетворенность пользователей, при этом наполнение фронтальной составляющей данными невозможно без корректной отработки процессной и учетной составляющих, также сталкивающихся с повышенными требованиями к производительности. При этом продукт, потребителями которого являются только авторизованные пользователи, не предъявляет аналогичных требований. Платформа же, обеспечивающая автоматизацию продуктовых решений, является общей. Каким же образом достичь эффективности и в то же время учесть все требования, предъявляемые продуктами?
Как мы уже отмечали, платформа предоставляет общую среду создания и исполнения приложений. Таким образом, мы исходим из того, что и набор технологических инструментов для автоматизации продуктовых составляющих является общим (с точки зрения доступности командам разработки). Но здесь вновь вступает в дело архитектор, являющийся лидером технологических изменений. Доступные платформенным приложениям технологические решения, предоставляемые платформой, должны проектироваться и создаваться таким образом, чтобы:
• Охватывать множество продуктов и поддерживать распределенное исполнение предоставляющих их платформенных приложений.
• Допускать множество вариантов использования, чтобы иметь возможность избегать предоставления платформенным приложениям избыточно сложных или тяжеловесных платформенных сервисов.
• Быть открытыми, чтобы иметь возможность развиваться при расширении набора продуктов и появлении новых/дополнительных требований.
Для рассматриваемого примера можно выделить следующие варианты совместного исполнения приложений, автоматизирующих предоставляемые продукты (с учетом вышеприведенных характеристик технологических решений):
• Для обеспечения высокой производительности фронтальной составляющей может использоваться решение по обработке и хранению данных в оперативной памяти (IMDG/IMDB). При этом данное решение должно быть технологически общим, дабы при поддержке и развитии продуктов не приходилось учитывать «зоопарк технологий». Примером неудачного проектирования может служить вариант, при котором в роли IMDG/IMDB-решения для высокопроизводительного продукта выступает Apache Ignite, а для продукта, требования к производительности которого ниже, Redis. В дальнейшем при появлении еще одного продукта с высокими требованиями по производительности команда развития внедрит Hazelcast, после чего драматически возрастет стоимость обеспечения непрерывности, поддержки и развития подобного «унифицированного» решения. Но выбором общей технологии работы (например, Apache Ignite ввиду наличия требований по высокой нагрузочной способности) дело не ограничивается. На первый план выступает вопрос использования топологий. И платформа должна предоставлять возможность развернуть топологию, поддерживающую исполнение продукта в соответствии с требованиями. Например, соответствующее число узлов, правила репликации, даже сложность и развитость встраиваемого платформенного API могут различаться в зависимости от требований, предъявляемых к продукту. Таким образом, и варианты использования платформенного сервиса также могут различаться. В конце концов, и обеспечение групп продуктов может осуществляться множеством платформенных сервисов, каждый из которых отвечает своему подмножеству требований.
• Подобное технологическое решение по обеспечению высокой производительности может (и должно) применяться при автоматизации процессной составляющей рассматриваемых продуктов. Как мы уже отмечали ранее, стандартные средства автоматизации бизнес-процессов, как правило, не отличаются высокой производительностью. В них закладываются возможности гибкого моделирования процессов, их быстрой сборки и развертывания, возможности мониторинга, но производительность отказывается не самым передовым показателем данного класса инструментов. Одновременно (и мы также обращали внимание читателя на данный факт) в современной архитектуре бизнес-процессы не могут характеризоваться низкой производительностью, в противном случае организация потеряет конкурентоспособность на рынке. Поэтому (так как базовый инструмент управления процессами не может сам по себе обеспечить адекватную требованиям дистанционного обслуживания производительность) на уровне реализации процессной составляющей продуктовой автоматизации могут применяться упомянутые выше IMDG/IMDB-инструменты. С их помощью, например, может осуществляться высокоэффективная работа с контекстом экземпляра процесса, его бизнес-данными, обеспечиваться надежность и т. д. Конкретные топологии (и сущности) развертывания могут различаться как от продукта к продукту, так и в зависимости от той продуктовой составляющей, к которой они относятся. Но технологическая унификация, а также специфика платформенных сервисов должны быть общими на уровне платформенных приложений и предоставляемых ими продуктов организации клиентам и партнерам последней. Фактически множество платформенных сервисов, обеспечивающее исполнение фронтальной составляющей продукта, пересекается с множеством платформенных сервисов, обеспечивающих исполнение процессной составляющей продукта, по принципу кругов Эйлера. Аналогичным образом пересекаются множества платформенных сервисов, обеспечивающих исполнение различных продуктов (даже при аналогичной структуре последних). А требования к платформенным сервисам, режимам их функционирования, топологиям развертывания технологической составляющей предъявляют продукты. Отметим, что указанные требования не являются статическими. Например, при добавлении новых продуктовых бизнес-процессов или расширении использования существующих требования к инструментальной поддержке высокой производительности процессов могут кардинально измениться – как вариант, возрасти. Подобное происходит при добавлении новых каналов лидогенерации, привлекающих большие объемы клиентов. Соответственно, используемые в платформах технологии, а также предоставляемые платформами сервисы должны быть адаптируемыми к подобным изменениям требований, что, в свою очередь, напрямую следует из свойства отсутствия замкнутости платформ.
• Каждый продукт, реализуемый платформенными приложениями, может функционировать в собственном режиме, а требования к нему могут изменяться независимо от остальных продуктов, предоставляемых организацией клиентам и партнерам. А потому платформа должна обеспечивать достаточную гибкость для независимой поддержки развития каждого продукта. То есть платформа должна быть распределенной, каждый ее модуль, каждый платформенный сервис должен быть распределенным, в противном случае он окажется узким местом развития независимых продуктов.
Мы не будем подробно рассматривать варианты распределенного исполнения остальных составляющих продуктовой автоматизации, представленных на Рисунке 5. Их сопоставление (как между собой, так и в контексте нескольких автоматизируемых продуктов) будет аналогично приведенному выше для фронтальной и процессной составляющих. Здесь важно отметить другое. При технологической унификации решений, предлагаемых платформами для продуктовой автоматизации, необходимо учитывать раздельное и распределенное исполнение как продуктов, так и отдельных уровней автоматизации, то есть платформы должны предлагать (с точки зрения визуализации Рисунка 5) как горизонтальную, так и вертикальную распределенность. И добиться такого результата позволит эластичное масштабирование.
Поддержка той или иной технологией эластичного масштабирования подразумевает, что соответствующая технология обеспечивает:
• Сегментацию собственных сущностей. В приведенном выше примере мы можем, в частности, сформировать отдельные сегменты IMDG/IMDB-решения для поддержки различных составляющих автоматизации продуктов, разделить по сегментам те или иные продуктовые процессы в зависимости от требований.
• Каждый сегмент может масштабироваться независимо. Например, может быть выделен сегмент IMDG/IMDB под каждый тип продуктового процесса, при этом сегменты, обеспечивающие производительность высоконагруженных процессов, масштабируются независимо от других. Таким образом обеспечивается использование ресурсов в соответствии с реальными потребностями приложений, причем гранулированное, исключающее избыточные затраты.
• Технологическое решение, применяемое для автоматизации соответствующего сегмента, может использовать динамически расширяемое или сокращаемое количество вычислительных узлов для своего функционирования.
• Технологические решения сохраняют корректность функционирования при увеличении или уменьшении количества используемых ими вычислительных узлов (разумеется, уменьшение в данном случае не подразумевает сокращения количества узлов ниже требуемого для обеспечения минимальной нагрузочной способности).
Отметим, что приводимые нами в качестве примеров в течение настоящей книги технологии Apache Ignite, Apache Cassandra, Apache Kafka и многие другие ведущие решения с открытым исходным кодом обеспечивают вышеприведенные характеристики.
Но мало применять технологии, поддерживающие эластичное масштабирование. Платформенные сервисы и платформенные приложения, использующие подобные технологии, также должны поддерживать эластичное масштабирование. И здесь задача архитектора совместно с командами развития – спроектировать и реализовать сервисы и приложения таким образом, чтобы они не стали узким местом платформы, чтобы сама платформа не стала барьером между развитыми технологиями с открытым исходным кодом и командами развития, которые в таком случае окажутся вынуждены «бороться» с предоставляемыми им сервисами, чтобы обеспечить распределенность.
Считаем нелишним еще раз подчеркнуть, что мы не рассматриваем конкретные платформенные решения. Реализации конкретных платформ как требуют детальной проработки технологий и их топологий, так и содержат гораздо большее количество поддерживаемых составляющих автоматизации продуктов организации, наполняя их существенно более богатым набором технологических решений. Наша же задача в рамках данного изложения заключается в том, чтобы показать читателю связь цифровых платформ и такой ключевой тенденции развития архитектуры, как распределенность, проиллюстрировать способы поддержки соответствующей тенденции путем платформенного подхода.
Цифровые платформы и бизнес-процессы
Перечисляя ключевые тенденции развития архитектуры, мы говорили о том, что современные организации, ставящие себе целью перманентное интенсивное развитие, стараются уйти от процессной методологии работы к продуктовой. При этом смещение фокуса внимания на продукты не отменяет важности бизнес-процессов, более того, мы относим последние к трендам, определяющим развитие архитектуры. Внимательный читатель и тут не оставит нас без каверзного вопроса: «Нет ли противоречия в указанной логике?» Мы отвечаем, что противоречие отсутствует, а ниже объясним, почему так происходит.
Для обеспечения полноты рассмотрения мы возьмем за основу организацию с относительно длительной историей, прошедшую уже не одно поколение автоматизации (применявшую различные архитектурные парадигмы), поскольку вариант рассмотрения стартапа чреват применением к нему фразы Исаака Ньютона: «Если я видел дальше других, то потому, что стоял на плечах гигантов». Случай стартапа может характеризоваться учетом опыта предшественников, при котором удается избежать тех или иных ошибок, кроме того, влияние унаследованного ИТ-ландшафта и устаревшего mindset может оказаться пренебрежимо малым.
Как правило, такая организация уже проводила описание выполняемых бизнес-процессов (в ряде случае они могут именоваться производственными ввиду специфики деятельности), зачастую с приглашением внешних консультантов проводились попытки провести и некую оптимизацию последних. Результаты подобных действий могут различаться:
• Возможно, дело ограничилось просто описанием бизнес-процессов с созданием (и то не всегда) визуализирующих диаграмм в общепринятых форматах – например, BPMN.
• Исполнение бизнес-процессов в автоматизированном режиме может осуществляться в каждой информационной системе отдельно (специфичные процессы выполняются в специфичных информационных системах).
• В организации мог быть внедрен BPM-инструмент для централизованного управления бизнес-процессами (с различным охватом внедрения соответствующего инструментария).
Отметим, что вышеперечисленные пункты не являются фиксированными шагами на пути компании к успеху – возможны самые разные варианты реализации каждого из них, включая различные подводные камни:
• Бизнес-процессы могут быть описаны халатно или в формате «вроде как сейчас так происходит», то есть без необходимой верификации описания.
• Бизнес-процессы, реализованные в информационных системах либо посредством выделенного BPM-инструмента, могут содержать большое количество элементов, автоматизированных с использованием «ручного» программирования, и требовать масштабного привлечения разработчиков при изменениях.
• Элементы бизнес-процессов могут быть реализованы (или управляться) в различных информационных системах, что приводит к избыточным трудозатратам при внесении изменений в автоматизируемые процессы.
• И т. д.
При переходе к современным архитектурным и технологическим принципам необходимо учитывать первичность продуктового подхода, когда деятельность организации определяется тем, какую ценность она приносит клиентам и/или партнерам. При этом ценность в современном мире реализуется автоматизируемыми продуктами – цифровыми продуктами. Бизнес-процессы сегментируются в соответствии с продуктовой логикой. Но далеко не все процессы могут быть ограничены лишь одним продуктом:
• Безусловно, бизнес-процессы, ассоциированные с тем или иным продуктом, автоматизируются в соответствии с ним и размещаются (с точки зрения архитектуры) в соответствующей функциональной области.
• Сложные кросс-продукты (или связанные продукты) могут требовать и сложных бизнес-процессов, которые будут включать в себя инструкции по исполнению продуктовой логики, реализуемой в составе множества продуктов.
