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

Рисунок 5. Продукты, автоматизируемые с помощью платформы

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

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

– Автоматизация end-to-end продукта должна осуществляться максимально гранулированным образом, дабы иметь возможность как вписать таковой продукт в унаследованные архитектурные ландшафты, так и подготовить его к переводу на новые архитектурные поколения.

– Элементы end-to-end продукта должны быть отчуждаемыми (следствие грануляции) и реализовываться различным образом в соответствии с теми или иными архитектурными практиками (и архитектурными поколениями).

– End-to-end продукты должны иметь независимые релизные циклы.

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

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

Можно ли автоматизировать каждый end-to-end продукт независимо от других с точки зрения не только конкретной разработки, но и архитектуры (в том числе платформенной)? Конечно, можно. Но тогда пострадает эффективность работы организации в целом. В своей книге «Бесконечный матч» великий футбольный тренер В. В. Лобановский писал: «Не кажется ли вам странным, что в наше время унификации элементарных – не говоря уже о сложнейших – производственных и мыслительных процессов почему-то только к футболистам все еще предъявляются требования изобретать на ходу? Им вполне серьезно рекомендуют на ощупь отыскать позиции, с которых удобно воспользоваться прострельной передачей мяча с фланга или по наитию доходить до того, какой маневр и в какой фазе игры ведет к созданию численного превосходства в контратаке… Я не против того, чтобы так „творили“ на поле наши соперники. Увы, они этим не занимаются. На международной арене мы имеем дело с командами, которые не тратят ни мгновения на выбор коллективных решений, когда возникает знакомая тактическая ситуация». И в случае независимого продуктового проектирования мы оказываемся в аналогичной ситуации – начинаем «творить» продукты и их автоматизацию на ходу, каждый раз заново формируя грануляцию, выбирая средства автоматизации для каждого уровня, теряя эффективность. Подобное является недопустимой роскошью в современном цифровом мире. Думается, что организация, вынужденная работать на высококонкурентном рынке, не против, чтобы ее конкуренты «творили» подобным образом, но итог для рынка в целом будет критичным: компании, «творящие» автоматизацию своих продуктов, будут покидать его, а оставшиеся – останавливаться в своем развитии и деградировать в отсутствие конкуренции.

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

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

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

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