Андрей Трушкин – Архитектура цифровых платформ. От настоящего к будущему (страница 11)

• Вульгарное толкование термина «повторное использование» приводит к тому, что возникает огромное количество распределенных компонентов, предоставляющих собственные API (различных версий), а также их потребителей, использующих различные версии указанных API. В подобных условиях формируются зависимости релизных циклов компонентов и платформенных приложений, что крайне негативно влияет на значение такого определяющего показателя эффективности, как время вывода продукта на рынок (time-to-market).

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

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

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

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

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

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

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

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

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

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

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

• Охватывать множество продуктов и поддерживать распределенное исполнение предоставляющих их платформенных приложений.

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

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

Для рассматриваемого примера можно выделить следующие варианты совместного исполнения приложений, автоматизирующих предоставляемые продукты (с учетом вышеприведенных характеристик технологических решений):

• Для обеспечения высокой производительности фронтальной составляющей может использоваться решение по обработке и хранению данных в оперативной памяти (IMDG/IMDB). При этом данное решение должно быть технологически общим, дабы при поддержке и развитии продуктов не приходилось учитывать «зоопарк технологий». Примером неудачного проектирования может служить вариант, при котором в роли IMDG/IMDB-решения для высокопроизводительного продукта выступает Apache Ignite, а для продукта, требования к производительности которого ниже, Redis. В дальнейшем при появлении еще одного продукта с высокими требованиями по производительности команда развития внедрит Hazelcast, после чего драматически возрастет стоимость обеспечения непрерывности, поддержки и развития подобного «унифицированного» решения. Но выбором общей технологии работы (например, Apache Ignite ввиду наличия требований по высокой нагрузочной способности) дело не ограничивается. На первый план выступает вопрос использования топологий. И платформа должна предоставлять возможность развернуть топологию, поддерживающую исполнение продукта в соответствии с требованиями. Например, соответствующее число узлов, правила репликации, даже сложность и развитость встраиваемого платформенного API могут различаться в зависимости от требований, предъявляемых к продукту. Таким образом, и варианты использования платформенного сервиса также могут различаться. В конце концов, и обеспечение групп продуктов может осуществляться множеством платформенных сервисов, каждый из которых отвечает своему подмножеству требований.