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

отыскать позиции, с которых удобно воспользоваться прострельной передачей мяча с фланга или по наитию доходить до того, какой маневр и в какой фазе игры ведет к созданию численного превосходства в контратаке… Я не против того, чтобы так „творили“ на поле наши соперники. Увы, они этим не занимаются. На международной арене мы имеем дело с командами, которые не тратят ни мгновения на выбор коллективных решений, когда возникает знакомая тактическая ситуация». И в случае независимого продуктового проектирования мы оказываемся в аналогичной ситуации – начинаем «творить» продукты и их автоматизацию на ходу, каждый раз заново формируя грануляцию, выбирая средства автоматизации для каждого уровня, теряя эффективность. Подобное является недопустимой роскошью в современном цифровом мире. Думается, что организация, вынужденная работать на высококонкурентном рынке, не против, чтобы ее конкуренты «творили» подобным образом, но итог для рынка в целом будет критичным: компании, «творящие» автоматизацию своих продуктов, будут покидать его, а оставшиеся – останавливаться в своем развитии и деградировать в отсутствие конкуренции.

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

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