Архитектура цифровых платформ. От настоящего к будущему
- -
- 100%
- +
Рассмотрим те аспекты экосистем продуктов с открытым кодом и их развития, использование которых (аспектов) позволяет фундаментально изменить мировоззрение компаний при реализации новых решений в части применения современного платформенного подхода. В «Архитектуре цифрового мира» мы взяли за основу тезисы Джима Уайтхерста (James M. «Jim» Whitehurst), изложенные им в книге «Открытая организация: Страсть, приносящая плоды» (2015, ISBN 978-5-9693-0405-5): мотивация, меритократия, прозрачность принятых решений, развитие новых направлений. Рассмотрим данные тезисы в контексте платформенного подхода.
• Мотивация. Указанный тезис, столь важный для современного цифрового мира, подразумевает, что эффективность работы коллектива резко возрастает при обеспечении слаженной совместной работы всех его участников; при этом каждый член коллектива работает более эффективно, воочию наблюдая значимость собственного вклада в общее дело. В предыдущем своем труде («Архитектура цифрового мира») мы отмечали, что развитие решений с открытым исходным кодом является наглядным примером эффективной совместной работы. Современный платформенный подход, основанный на философии открытого кода, идет дальше: стираются границы между командами, обеспечивающими цифровую трансформацию, исчезают команды развития отдельных информационных систем, команды развития отдельных «платформ». В рамках общей платформы, использующей открытый код, все команды создают и публикуют изменения, доступные коллегам. При этом, развивая платформу, формируя новые топологии и дополнения в решения с открытым исходным кодом, команды должны публиковать их в сообществах, дополнительно повышая производительность. Мы уже отмечали, что платформа становится ценностным мультипликатором, открытый код является мультипликатором эффективности, а их совместное и согласованное использование является и мультипликатором мотивационным, позволяющим резко повышать эффективность командного труда, создавать современные решения. И важнейшее слово здесь принадлежит архитектору, который должен возглавлять технологические изменения, определять структуру платформ, состав и компоненты используемых технологий, способы их применения, необходимые дополнения и т. д. Но все это возможно лишь при достижении уровня mindset, адекватного современному цифровому миру.
• Меритократия. Суть меритократии в контексте нашего рассмотрения заключается в том, что полномочия при принятии решений соразмерны вкладу участников в создание и/или развитие ИТ-решения. Данный принцип обеспечивает мотивацию ответственных членов команды принимать участие в выработке технологических решений. В случае применения платформенного подхода имеет смысл говорить не только о меритократии отдельных участников рабочего процесса, но о меритократии команд, ведь в рамках платформы и создаваемых на ее основе платформенных приложений в процессе цифровой трансформации участвует множество команд развития. И все команды развития обязаны предлагать решения в том числе уровня платформы, публиковать их, делать общедоступными хотя бы в масштабе организации. И полномочия при принятии решений командами, вес мнения тех или иных команд будут тем выше, чем больший вклад они вносят в развитие платформ. Именно таким образом команды продвигают свое видение, обеспечивают лучшие технологические решения, мотивируют лучших участников рабочего процесса становиться членами именно самых успешных команд; по факту таким образом формируется добросовестная конкуренция на уровне развития не отдельных технологий (пусть и успешных), но целых цифровых платформ. То есть меритократия дополнительно усиливает фактор мотивации, а драйвером усиления становятся платформы (при условии использования философии открытого кода). При этом исключительно важной является роль архитектора, ведь именно представитель данной роли отвечает в том числе за учет предложений, оценку их веса и последующие полномочия команд, основанные на публикуемых обновлениях платформы и ее составляющих.
• Прозрачность принятых решений. Мотивированные команды разработки, их участники, выступающие с принципов меритократии, обеспечивают прозрачность решений, принимаемых в процессе развития платформ и создаваемой с их помощью ценности для клиентов и партнеров организации. Прозрачность решений позволяет обеспечить наглядность тренда развития, задаваемого как для платформы в целом, так и для платформенных сервисов и приложений. А наглядность тренда развития в свою очередь обеспечивает более полное вовлечение всех участников рабочего процесса в дальнейшее развитие, интенсифицируя его. Таким образом, использование платформенного подхода, отвечающего принципам открытого кода, повышает прозрачность принятых решений, мотивацию всех членов команд развития и обеспечивает кардинальное повышение производительности труда. При этом в задачи архитектора входит наглядная выработка решений, помощь в их оценке, формирование архитектурных фреймворков, обеспечивающих прозрачность принятия решений, утверждение их на уровне платформы и постоянное развитие.
• Развитие новых направлений. Рассматриваемый тезис предполагает максимально быструю проверку возникающих идей, их шлифовку уже в ходе практического применения. Платформенный подход полностью укладывается в следование данному тезису. Команда прорабатывает новые идеи, при их успешности публикует их на уровне платформы, делая тем самым доступными для смежных команд развития, которые также обкатывают соответствующие наработки, выявляя ошибки и неточности, повышая качество и добавляя новые применимые варианты использования. Тем самым резко повышается производительность труда, а каждая ошибка (в полном соответствии с фундаментальными постулатами гибких практик) становится не барьером, а вызовом на пути развития.
На основании рассмотрения указанных тезисов мы можем утверждать, что платформы являются фундаментом построения открытых организаций, то есть становятся краеугольным камнем повышения эффективности цепочек разделения труда. В «Архитектуре цифрового мира» мы отмечали, что потенциал расширения цепочек разделения труда в ИТ далеко не исчерпан, но по мере его исчерпания встанет вопрос нового революционного перехода в сфере ИТ (эволюционное и революционное развитие архитектуры описаны в соответствующей главе там же). На сегодняшний день уже можно утверждать, что платформы стали основой революционного перехода, резко повышающего производительность труда в цифровой сфере, позволяющего выстраивать открытые организации во все новых областях человеческой деятельности. И этот переход находится в самом разгаре.
В завершение данного раздела автор выражает глубокую благодарность сообществу разработчиков и пользователей открытого кода за ту страсть, которую они добавляют в ИТ, революционное развитие данной сферы человеческой деятельности, создание прекрасных программных продуктов, используемых автором и его коллегами в своей работе.
Цифровые платформы и распределенность
В «Архитектуре цифрового мира» мы отмечали, что распределенность является одной из ключевых тенденций развития архитектуры в цифровую эпоху. При этом распределенность рассматривалась в двух смысловых плоскостях: организационной, предполагающей реализацию ИТ-решений силами распределенных команд, состоящих из специалистов самого разного профиля, и технологической, подразумевающей распределенное исполнение современных решений. Соответствующая тенденция актуальна и для платформ. Именно в контексте платформенного подхода распределенность будет рассмотрена в настоящем разделе.
Начнем с организационной распределенности. В современном цифровом мире использование гибких практик стало стандартом де-факто (напомним, что подобное использование может привести к попаданию в ментальные ловушки, разобранные в соответствующей главе «Архитектуры цифрового мира»). Гибкие практики (и их адаптации для применения в крупных компаниях) предполагают, что в организации определяются продукты, при этом продукты создаются и развиваются выделенными командами специалистов, минимальным образом зависящими друг от друга. Подобные команды могут находиться в самых разных точках земного шара, при этом все они должны работать согласованно (в архитектурном, а не управленческом смысле, поскольку последнее граничит с «микроменеджментом») для обеспечения создания ценности и сохранения конкурентоспособности организации.
Мы уже неоднократно отмечали (как в текущем изложении, так и в предыдущем труде автора), что открытый код и гибкие практики позволяют увеличивать разделение труда и тем самым кардинально повышать его производительность по сравнению с использованием «закрытых» решений (как технологически, так и при «закрытой» философии). В цепочку создания ценности вовлекаются все новые участники (как отдельные специалисты, так и команды), которые отвечают за свои участки деятельности, обеспечивая максимальную эффективность. При этом возрастает общая производительность труда в цепочке разделения, но обратной стороной медали являются резко возрастающие риски отдельных участников технологической цепочки. Ведь чем больше участников цепочки разделения труда (при создании общей ценности), тем больше они зависят от результатов работы друг друга (увеличивается число как поставщиков составляющих, используемых командами в своей работе, так и потребителей результатов этих работ). И в данном случае платформа, выступающая, как говорилось ранее, ценностным мультипликатором, позволяет обеспечить управление соответствующими рисками в цепочке разделения труда. Рассмотрим это на примере, который визуально представлен на Рисунке 5.
Рисунок 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 продукт независимо от других с точки зрения не только конкретной разработки, но и архитектуры (в том числе платформенной)? Конечно, можно. Но тогда пострадает эффективность работы организации в целом. В своей книге «Бесконечный матч» великий футбольный тренер В. В. Лобановский писал: «Не кажется ли вам странным, что в наше время унификации элементарных – не говоря уже о сложнейших – производственных и мыслительных процессов почему-то только к футболистам все еще предъявляются требования изобретать на ходу? Им вполне серьезно рекомендуют на ощупь отыскать позиции, с которых удобно воспользоваться прострельной передачей мяча с фланга или по наитию доходить до того, какой маневр и в какой фазе игры ведет к созданию численного превосходства в контратаке… Я не против того, чтобы так „творили“ на поле наши соперники. Увы, они этим не занимаются. На международной арене мы имеем дело с командами, которые не тратят ни мгновения на выбор коллективных решений, когда возникает знакомая тактическая ситуация». И в случае независимого продуктового проектирования мы оказываемся в аналогичной ситуации – начинаем «творить» продукты и их автоматизацию на ходу, каждый раз заново формируя грануляцию, выбирая средства автоматизации для каждого уровня, теряя эффективность. Подобное является недопустимой роскошью в современном цифровом мире. Думается, что организация, вынужденная работать на высококонкурентном рынке, не против, чтобы ее конкуренты «творили» подобным образом, но итог для рынка в целом будет критичным: компании, «творящие» автоматизацию своих продуктов, будут покидать его, а оставшиеся – останавливаться в своем развитии и деградировать в отсутствие конкуренции.
По итогам приведенных тезисов можно отметить, что платформа определяет набор инструментов создания и исполнения продуктов организации, при этом предлагает схожие наборы указанных инструментов для общих продуктовых составляющих (в нашем примере их четыре). То есть уже на уровне концепции платформенного подхода происходит снижение рисков для отдельных участников рабочего процесса (как конкретных специалистов, так и команд гибких практик) вследствие структуризации (составляющие продуктов) и унифицированной поддержки работы (общие наборы инструментов для продуктовых составляющих). При этом кроме собственно инструментов платформы предлагают и общие направляющие реализации продуктов, учитывающие опыт организации, риски использования тех или иных инструментов, проработанные варианты использования и т. д. И роль архитектора в данном случае крайне важна. Ведь именно на нем лежит задача технологического проектирования будущих продуктов организации, структуризация платформы, определение продуктовых составляющих, технологий их автоматизации (и применяемых топологий), выработка общих направляющих. Разумеется, архитектор не может быть надсмотрщиком, диктующим командам разработки правила их работы – указанные правила формируются в рамках рабочего диалога, отвечающего принципам открытого кода и открытой организации.
Важно отметить, что в разговоре об общих инструментальных наборах, предоставляемых платформами для автоматизации продуктовых составляющих, речь не идет о повторном использовании сервисов и компонентов в вульгарном смысле этого слова. В «Архитектуре цифрового мира» мы уже касались опасности бездумного повторного использования (или переиспользования). К сожалению, нельзя не отметить, что концепция переиспользования (именно в вульгарном смысле) продолжает оставаться популярной, что резко снижает эффективность цифровизации многих рыночных игроков. Итогом следования подобной абсурдной концепции становится позиционирование платформы в качестве овеществленного компонента ИТ-ландшафта, фактически информационной системы, что ранее уже отмечалось нами как одна из ключевых ментальных ошибок, допускаемых на пути реализации платформенного подхода. При вульгаризации принципа повторного использования, как правило, происходит следующее:
– Максимум компонентов, содержащих близкий функционал, выделяются в общие и «переиспользуются». Зачастую все такие компоненты становятся «платформенными». Так и появляется, например, «платформенный компонент Клиент», который зачастую либо не реализует требуемые функции платформенных приложений, либо является избыточным. В результате команды развития либо приходят к антипаттерну «Распределенный монолит», либо начинают создавать дублирующий функционал, не руководствуясь никакими общими направляющими и технологическими средами продуктов. Любой из приведенных вариантов кратно увеличивает требующиеся для реализации ценности трудозатраты и риски участников рабочего процесса, что недопустимо в современном цифровом мире, так как приводит к застою и деградации организаций, допустивших подобное.
• Продолжением предыдущего пункта, формулирующего чрезмерную перегрузку платформ несвойственными им компонентами, становится формирование платформенных команд, не создающих ценность и являющихся высококонкурентным ресурсом, что уже рассматривалось нами ранее в качестве крайне негативного фактора и барьера на пути интенсивного развития.
• Вульгарное толкование термина «повторное использование» приводит к тому, что возникает огромное количество распределенных компонентов, предоставляющих собственные API (различных версий), а также их потребителей, использующих различные версии указанных API. В подобных условиях формируются зависимости релизных циклов компонентов и платформенных приложений, что крайне негативно влияет на значение такого определяющего показателя эффективности, как время вывода продукта на рынок (time-to-market).
Перечисление негативных факторов, следующих из вульгаризации концепции повторного использования, можно продолжать, но смысл уже понятен: резкое усложнение релизных циклов, увеличение объемов регрессионного тестирования, сложность цифровых платформ, для которых формируются подобные факторы, сводит на нет концепцию платформы как ценностного мультипликатора. Поэтому при рассмотрении вопросов повторного использования, позволяющего повышать производительность цепочки разделения труда, необходимо придерживаться следующих ключевых положений:
• Платформа представляет собой среду создания и исполнения приложений, автоматизирующих продукты организации и предоставляющих ценность клиентам и партнерам. Следовательно, платформа не содержит прикладных компонентов (отвечающих за непосредственное создание ценности), она предоставляет опосредованную ценность.
• Ключевым свойством предоставления API платформенными компонентами является их встраиваемость: API предоставляется в формате встраиваемых библиотек, используемых платформенными приложениями. Указанный подход позволяет избегать необходимости пересборки приложений при обновлениях платформенных компонентов либо максимально снизить данную необходимость.
• Подсистемы, сервисы, компоненты и другие структурные составляющие платформы не предоставляются в виде единой сущности всем потребителям – они могут представлять собой наборы сущностей, при этом настройки каждой сущности (в том числе топология) могут адаптироваться под потребности потребителей (платформенных приложений).
• Кроме собственно технологических компонентов платформа предоставляет общие направляющие для потребителей, включающие (но не ограничивающиеся ими) варианты использования компонентов, рекомендации и другие материалы, позволяющие обеспечить максимально эффективное предоставление платформы платформенным приложениям.
Следуя вышеперечисленным положениям, мы можем разделить технологический и прикладной функционал, обеспечить независимость последнего, разделить релизные циклы компонентов, снизить потенциальные объемы регрессионного тестирования, а также адаптировать платформу под требования потребителей. Тем самым повышается производительность труда технологической цепочки создания ценности и снижаются риски ее участников. Важно отметить, что платформенный подход и принципы открытого кода дополняют друг друга, обеспечивая тот самый ценностный мультипликатор, о котором говорилось по ходу настоящего изложения. В результате организация, применяющая платформенный подход, достигает более высокого уровня конкурентоспособности по сравнению с теми своими конкурентами, кто либо игнорирует соответствующий подход, либо попадает в ментальные ловушки в ходе его применения.
Таким образом, следование платформенному подходу, реализация, внедрение и использование платформ позволяют не просто повышать эффективность цифровизации продуктов, предоставляемых организациями своим клиентам и партнерам. Платформы поддерживают распределенную структуру команд, обеспечивают вовлечение все большего числа участников в общие технологические цепочки, стирают между ними барьеры. Мы приходим к выводу: чем более полно внедряется современный платформенный подход, чем более современная (и устремленная в будущее) платформа используется в организации, тем в большей степени цифровая архитектура организации соответствует такой ключевой тенденции развития, как распределенность.
При этом для участников технологической цепочки платформа является открытой. Подробно открытость платформ мы рассмотрим в соответствующей главе. В контексте же распределенности отметим, что распределенные команды могут и должны становиться участниками развития платформы, дополняя ее необходимым им функционалом, публикуя его в доступном коллегам виде. Подчиняясь принципам открытого кода, платформа развивается ее же потребителями, в результате чего максимально полно отвечает их нуждам. Синергия публикуемых обновлений позволяет всем распределенным командам повышать свою эффективность, как следствие, растет производительность всей цепочки разделения труда.
Рассмотрим теперь поддержку платформами смысловой составляющей технологической распределенности. Последняя предполагает возможность реализации при помощи платформы таких платформенных приложений, которые могут исполняться в распределенном режиме, предоставлять сервисы клиентам и партнерам в любой точке земного шара. При этом мы должны учитывать, что посредством платформенных приложений переводятся в цифровой вид продукты организации, несущие непосредственную ценность клиентам/партнерам. Перечень продуктов не является законченным – организация постоянно создает новые продукты или вносит изменения в уже существующие, следя за рыночной конъюнктурой. Характеристики продуктов являются совершенно различными. Продукты, отвечающие структурной декомпозиции, показанной на Рисунке 5, могут кардинально отличаться друг от друга функциональным наполнением в рамках общих составляющих, автоматизация которых осуществляется с применением платформенного подхода. Примерами таких отличий могут стать сложность и специфика исполнения бизнес-процессов (например, количество шаблонов процессов и сложность схем продуктовых процессов, подлежащих автоматизации), доступность продуктов в различных множествах дистанционных каналов (подобная характеристика влияет на нефункциональные требования, но принимается на уровне владельца продукта, а потому исходно может считаться функциональной), характеристики аналитического учета и т. д. Таким образом, и требования продуктов к платформе также существенно отличаются.