- -
- 100%
- +
На Рисунках 14 и 15 представлен пример реализации архитектурных уровней продуктовой логики с использованием открытого программного обеспечения. Еще раз подчеркнем – это именно упрощенный пример. Мы не включаем в него вопросы сбора логов, трассировки, аудит, аутентификацию, авторизацию, управление секретами, события клиентских приложений и т. д. Но мы видим, что открытые решения в состоянии покрыть полную реализацию архитектуры end-to-end продукта. Разумеется, в таком подходе существуют и свои собственные ограничения – пока в цифровом мире не создана «цифровая серебряная пуля».
В свое время в русскоязычном сегменте сети Интернет пользовался популярностью юмористический рассказ, сравнивавший программное обеспечение с самолетами. Проприетарное программное обеспечение было ассоциировано с продукцией уважаемых мировых авиаконцернов, свободное же программное обеспечение было уподоблено «кукурузнику», который собирался под конкретный полет, причем метод сборки был весьма оригинальным. Например, такой воздухоплавательный аппарат мог одновременно перевозить пассажиров и опылять поля, при этом перевозка пассажиров без опылителя была невозможна. В приведенном юмористическом примере была доля горькой правды: за корректное использование открытого программного обеспечения надо платить. И в первую очередь платить за экспертизу по его использованию. Отметим, что экспертиза может быть как внешней, так и внутренней. Например, возможным является привлечение внешних консалтинговых услуг, включая архитектурный анализ использования тех или иных технологий. Учитывая же, что технологии являются свободными, то и рынок консалтинга и архитектуры существенно шире, нежели в случае применения «закрытых» (vendor-lock) технологий. Альтернативным вариантом привлечения экспертизы является использование проприетарных решений, основанных на открытом коде, решений, в которых свободное программное обеспечение является своеобразным «ядром». В настоящее время существует немало рыночных игроков, ведущих свою деятельность подобным образом. Например, они используют то или иное программное обеспечение с открытым исходным кодом, расширяя его возможности. В таком случае именно дополнительные возможности являются интеллектуальной собственностью конкретного рыночного игрока, то есть обеспечивается синергия длинных технологических цепочек создания и развития решения с открытым кодом и экспертизы компании, производящей его адаптацию к конкретным применениям в индустрии. Использование подобных решений обеспечивает заказчикам экономию на внутренней экспертизе. Разумеется, требования к поставщику подобного решения в таком случае должны включать по-настоящему развитые компетенции в открытом решении. В противном случае заказчик будет поставлен перед необходимостью отдельно оплачивать экспертизу в открытом решении и тех дополнениях, что внес поставщик. Поставщик должен обеспечивать совместимость дополнений (как технологическую, так и методологическую) с открытым решением, сам обладать компетенциями по внесению дополнений (commit’ов) в открытый код, им используемый.
Если же компания, создающая цифровые продукты, минимизирует привлечение внешней экспертизы, например, для снижения зависимости от внешних поставщиков, то это также не препятствует полноценному использованию открытого кода. Никто не запрещает компаниям создавать внутренние центры экспертизы. Более того, наличие подобных центров (внутренних или внешних) является необходимым для полноценного использования решений с открытым исходным кодом. Ведь открытый код предлагает философию, кардинальным образом отличающуюся от использования проприетарных решений. И эта философия заключается все в том же разделении труда, о котором мы говорим и по ходу наших предыдущих книг, и по ходу настоящего изложения. Огромное преимущество длинной цепочки разделения труда в случае открытого кода заключается в том, что количество участников, вносящих изменения в программный продукт, на порядки превышает количество контрибьюторов проприетарных решений. И исключительно важную роль в этом играют заказчики – те самые компании, которые создают продукты. Создавая продукты с прямым или опосредованным вовлечением открытых решений, они становятся именно заказчиками для открытого программного обеспечения. Ведь именно они предлагают новые варианты использования для решений с открытым кодом, самостоятельно или совместно с партнерами дополняют открытое программное обеспечение в тех аспектах, где оно не полностью покрывает потребности продуктовых решений. А открытость позволяет вносить эти дополнения прозрачно и быстро.
С сожалением отметим, что в тот временной период, когда пишутся эти строки, появляется все больше преград на пути внесения дополнений в открытый код. И преграды эти не носят технического или методологического характера. Вынуждены констатировать, что подобное искусственное ограничение развития носит дискриминационный характер и должно быть преодолено. Оно не может иметь оправдания ни со стороны заказчиков, ни тем более со стороны сообществ, развивающих открытые решения. Сообщества, как бы это пафосно ни звучало, ответственны перед всем миром за скорость и качество развития цифровых решений. Искусственные ограничения никому не принесут пользы, но останутся примером сознательного ограничения развития цифровой сферы. А поскольку сам современный мир уже стал цифровым, то и ограничение цифровой сферы ограничивает развитие всего мира.
Резюмируя вышесказанное, подчеркнем, что создать современный продукт с использованием только программного обеспечения с открытым исходным кодом возможно. Но это потребует от организаций изменений как ментального, так и финансового характера. Об изменении мировоззрения, организационных процессов, командного взаимодействия мы еще поговорим в соответствующих разделах настоящей книги, здесь же обратим внимание на изменение финансовой модели создания продуктов.
Ранее (при использовании закрытого проприетарного программного обеспечения) компании заключали дорогостоящие лицензионные договоры с поставщиками программных комплексов, заказывали у них или их партнеров консалтинговые услуги по выбору наилучших вариантов использования поставляемого ПО (как правило, выбирались стандартизированные варианты из закрытых баз знаний), а затем «наслаивали» продуктовые решения на полученные комплексы. Значительные финансовые средства инвестировались в экспертизу по использованию закрытого ПО, знание содержащихся в нем «подводных камней» и т. д. То есть финансовая модель намертво привязывала компанию к поставщику программного обеспечения. С другой стороны, корпоративная прозрачность предполагала приемлемость данной модели.
Использование открытого ПО предполагает совершенно иное направление инвестиций в цифровизацию. Инвестиции направляются в первую очередь в экспертизу. Действительно, необходим выбор наиболее подходящего программного обеспечения – не одного программного продукта, но экосистемы, покрывающей потребности заказчика. Кроме этого, необходимо осуществлять выбор топологий, наиболее применимых для решения как тактических, так и стратегических задач заказчика, формирование вариантов использования технологий, ведение доработок внедряемого программного обеспечения, обеспечивающих максимальное удовлетворение потребностей заказчика. Отметим, что это не исключает привлечение компаний, развивающих программное обеспечение с открытым исходным кодом или оказывающих консалтинговые услуги. Но поскольку мы говорим об открытом коде, мы можем самостоятельно выбирать компании-партнеры, основываясь на их экспертизе и истории успеха. Внимательный читатель может озадачить нас вопросом: «Мы вкладываемся в людей, а завтра люди уволятся. И что же мы будем делать? Неужели наши инвестиции пропадут?» Мы уверенно отметаем все сомнения – вкладываясь в экспертизу, мы ее институционализируем посредством создания центров компетенций как в компании заказчике, так и в партнерах. Конкретное распределение центров компетенций не имеет сейчас принципиального значения – оно определяется организациями в рамках собственной стратегии развития. В настоящем изложении мы говорим о принципах. Мы уходим от эфемерных инвестиций в лицензии к инвестициям в экспертизу. Увы, до сих пор иногда приходится слышать на рынке выражения из серии «внедрить лицензии». Но рынок ждет от компаний не внедренных лицензий, пусть и уважаемых поставщиков, а продуктов, представляющих ценность для клиентов и партнеров. И здесь надо инвестировать в экспертизу создания этой ценности. Главный капитал XXI века – человеческий. И открытый код стимулирует инвестиции непосредственно в человеческий капитал. Именно поэтому он и является одной из ключевых тенденций развития архитектуры, поэтому он так важен для создания современных цифровых продуктов.
Отдельно отметим еще одно направление инвестиций в экспертизу. Используя открытые решения при создании продуктов, компании формируют для них новые варианты использования, которые приводят к расширению возможностей открытого ПО. Нередко подобное расширение возможностей материализуется в виде доработок, вносимых в решения с открытым исходным кодом. И крайне важно в таком случае следовать рекомендациям от сообществ, разрабатывающих решения с открытым исходным кодом, по внесению изменений и их последующей публикации. Указанный подход позволит обеспечить совместимость используемых версий открытого ПО с вновь появляющимися, не сделает код, содержащийся в репозиториях компании, тупиковой ветвью эволюции. Благодаря этому продукты компании смогут использовать актуальные версии свободного ПО, поддерживать прозрачность собственных релизных моделей. И это отдельное направление экспертизы, о котором нельзя забывать в том числе при формировании финансовой модели продуктовой разработки.
Внимательный читатель наверняка задаст нам и еще один каверзный вопрос: «Вы все время говорите о ценности, предоставляемой продуктом, о P&L продукта, но в то же время называете продуктом свободно распространяемое программное обеспечение с открытым исходным кодом – какой же это продукт?» Мы незамедлительно дадим ответ, что открытый код безусловно является продуктом, и ниже объясним почему.
Создание и развитие программного обеспечения с открытым исходным кодом не является бесплатным, ведь в данный процесс привлекается значительная экспертиза. И, как показывает практика, вложения в открытое ПО осуществляют технологические гиганты, лидеры рынка ИТ. Зачем же они это делают? Основой их мотивации является все та же теория разделения труда. Лидеры рынка создают длинные технологические цепочки, обеспечивают высокую производительность труда при создании открытого программного обеспечения, гарантируют эффективность развития последнего. При этом они, развивая интересующее их ПО, обладают высокими компетенциями по части его использования и создания на его основе продуктов заказчиками. И таким образом осуществляется возврат инвестиций – путем включения открытого ПО в проприетарные продукты, оказание консалтинговых услуг, услуг по внедрению и адаптации программных продуктов, монетизации соответствующей экспертизы. Участниками процесса развития являются и заказчики, которые могут как добавлять новые варианты использования открытого программного обеспечения, так и включать новые дополнения в его состав. Просто цикл создания ценности стал длиннее и обширнее, нежели это выглядело в случае проприетарного программного обеспечения. И поэтому открытое программное обеспечение безусловно является продуктом. Ценность же оно предоставляет заказчикам, позволяя им создавать гибкие, надежные и современные цифровые продукты.
Внимательный читатель может прервать наши рассуждения злободневным саркастическим вопросом: «Неужели мы просто так разворачиваем открытое программное обеспечение, например, представленное на рисунках выше, и получаем современные цифровые продукты?» Мы понимаем и принимаем сарказм, выраженный в данном вопросе. Разумеется, и само программное обеспечение корректно развернуть и подготовить к использованию зачастую совсем непросто, особенно если речь идет о сложном корпоративном ИТ-ландшафте, содержащем как унаследованные, так и устремленные в будущее компоненты. Но и просто набор программного обеспечения не составит продукта для компании, осуществившей развертывание выбранного технологического стека на собственной или арендованной ИТ-инфраструктуре. Отвечая на вопрос читателя, мы вернемся к книге «Архитектура цифровых платформ. От настоящего к будущему». Аналогичный вопрос читатель задавал относительно платформы. Мы же указывали, что при создании и развитии платформы, во-первых, осуществляется технологическая унификация, во-вторых, формируются варианты использования технологий. И это требует серьезного интеллектуального ноу-хау, серьезных инвестиций от компании, создающей платформу. С продуктами ситуация во многом аналогичная. Цифровой продукт представляет собой независимую ценность для клиентов и/или партнеров компании, создающей и развивающей продукт. И для обеспечения этой ценности осуществляется автоматизация деятельности компании. Формат автоматизации определяется процессами компании. Программное обеспечение в данном случае используется в качестве инструмента. Мы аргументируем выбор в пользу программного обеспечения с открытым исходным кодом на основании той гибкости, которую оно несет продуктам. Высокая скорость внесения изменений, множество топологий развертывания, большое число вариантов использования позволяют создавать максимально адекватные требованиям рынка продукты, более того, создавать продукты, меняющие рынок. Например, Uber изменил рынок пассажирских перевозок. И основывался при этом на открытом коде.
Как правило, компания предлагает своим клиентам и партнерам множество продуктов. И если допустить их независимое развитие, то многообразие программного обеспечения с открытым исходным кодом может сыграть против компании. Если каждый продукт будет использовать собственный технологический стек, то это приведет к «зоопарку» технологий, увеличению трудозатрат на создание и сопровождение продуктовых ИТ-решений. Самый элементарный пример подобных затруднений представлен на Рисунках 16 и 17.
Мы специально доводим наши примеры до абсурда: при выборе технологической реализации двух продуктов мы сохраняем общей технологией только реляционные СУБД, указав для них одну из наиболее популярных на сегодняшний день технологий с открытым кодом PostgreSQL. Для автоматизации всех остальных продуктовых задач мы используем различные технологии, при этом все они представляют программное обеспечение с открытым исходным кодом. В качестве фреймворков языков высокого уровня представлены Java и. NET, управления API WSO2 и Gravitee, фреймворков фронтальной разработки Angular и React, технологий кэширования Infinispan и Ignite, потоковой передачи данных Apache Kafka и Apache Pulsar, нереляционных СУБД Apache Cassandra и ScyllaDB, управления бизнес-процессами – Camunda и Kogito, архивного хранения – S3 и Apache Hadoop (здесь и далее мы не приводим конкретные продукты реализации S3 с целью избежать избыточного загромождения иллюстраций).
Рисунок 16. Пример технологического «разнообразия»
продуктовой автоматизации при использовании ПО
с открытым исходным кодом (часть 1)
Рисунок 17. Пример технологического «разнообразия»
продуктовой автоматизации при использовании
ПО с открытым исходным кодом (часть 2)
Повторим еще раз, весь перечисленный технологический стек состоит из программных продуктов с открытым исходным кодом. Но использовать подобный подход для современной продуктовой автоматизации зачастую нецелесообразно по финансовым соображениям: необходимы вложения в экспертизу в части каждого из используемых программных продуктов. Поэтому при автоматизации продуктовой деятельности мы выбираем технологический стек, закрепляем его на уровне платформы, которая в свою очередь определяет рекомендуемые топологии программного обеспечения и его варианты использования в зависимости от архитектурного уровня, на котором оно применяется, и тех функциональных требований, которые предъявляются к продукту. Как мы отмечали в предыдущих книгах, платформа представляет собой среду создания и исполнения приложений, а продуктовые решения реализуются в виде платформенных приложений. Платформа, как и открытый код, является ценностным мультипликатором, а потому и используются указанные мультипликаторы совместно. Платформа использует открытый код и предоставляет его возможности для создания продуктов максимально эффективным образом. Подробнее аспекты сочетания платформенной и продуктовой автоматизации будут рассмотрены в дальнейшем в соответствующей главе.
Нельзя обойти вниманием и еще один исключительно важный аспект использования решений с открытым исходным кодом – аспект безопасности. Часто можно услышать голоса, предостерегающие от использования открытого программного обеспечения. Нам пытаются доказать, что использование открытого кода таит в себе нешуточную опасность, мол, включить в него недокументированные возможности может каждый. Любой из коммитов, включенных в основную ветку программного продукта, потенциально является вредоносным. Это, безусловно, так. Но давайте подумаем о том, исключаем ли мы указанный риск при использовании закрытого проприетарного ПО. Ранее мы уже отмечали, что любое современное программное обеспечение основано на открытом коде. Даже при локализации всех пакетов в собственных репозиториях ни одна компания в мире не может себе позволить развивать все пакеты самостоятельно. И заимствование кода осуществляется на перманентной основе. И компания, внедряющая внешние решения в качестве основы продуктовой автоматизации, в любом случае должна полностью проверять все дистрибутивы программного обеспечения, получаемые извне. Это касается как открытых, так и проприетарных решений. И логичным следствием будет обязательный процесс сборки решений на инфраструктуре компании-заказчика. Мы отдаем себе отчет в том, что это непростой, трудоемкий и финансово обременительный процесс. Да, можно заключать с поставщиками контракты жизненного цикла и выставлять штрафные санкции в случае обнаружения уязвимостей и недокументированных возможностей в процессе жизненного цикла уже продуктовых решений. Но зачастую последствия подобного отложенного обнаружения окажутся для компании катастрофическими. Здесь тот случай, когда известная поговорка, что «скупой платит дважды», может оказаться избыточно мягкой. И мы приходим к логичному выводу, что в любом случае, какое бы программное обеспечение (открытое или проприетарное) ни использовалось, необходимо осуществлять максимально полный анализ его состава, структуры и возможностей с точки зрения информационной безопасности. И здесь как раз открытый код с его понятной и логичной структурой оказывается предпочтительным – его исследования осуществляются по всему миру с публикацией результатов, что и подтверждено масштабами внедрения успешных решений.
Отдельно подчеркнем, что мы ни в коем случае не рекомендуем напрямую устанавливать в среду постоянной эксплуатации решения с открытым исходным кодом, взятые из открытых репозиториев. Разумеется, подобное было бы откровенно авантюрным поведением с закономерным итогом. Компании должны разворачивать собственные репозитории программного обеспечения с открытым исходным кодом, заимствовать информацию из открытых репозиториев, проверять полученные программные пакеты и поддерживать высокий уровень защищенности. Установка программного обеспечения в среды опытной или постоянной эксплуатации может осуществляться только из доверенных источников.
Мы уже отмечали, что по ходу настоящей книги мы будем неоднократно рассматривать мировоззренческие вопросы продуктовой разработки ввиду их особой важности в части повышения эффективности создания цифровых продуктов. В настоящем разделе коснемся некоторых моментов мировоззрения компаний, на которые напрямую влияет использование решений с открытым исходным кодом. Здесь, как и в наших предыдущих книгах, мы возьмем за основу тезисы Джима Уайтхерста (James M. «Jim» Whitehurst), изложенные им в книге «Открытая организация: Страсть, приносящая плоды» (2015, ISBN 978-5-9693-0405-5): мотивация, меритократия, прозрачность принятых решений, развитие новых направлений. Рассмотрим данные тезисы в контексте продуктового подхода.
• Мотивация. Данный тезис исключительно важен в контексте современной продуктовой разработки: эффективность работы коллектива резко возрастает, когда каждый член команды видит результаты своего труда и их место в общекомандном результате. Отметим также, что общекомандный результат в таком случае получается большим, нежели просто сумма частных результатов каждого участника рабочего процесса, то есть проявляется синергетический эффект. В книге «Архитектура цифрового мира» мы отмечали, что само по себе развитие решений с открытым исходным кодом является наглядным примером высокоэффективной совместной работы огромного количества замотивированных специалистов со всего мира, а результаты говорят сами за себя. В книге «Архитектура цифровых платформ. От настоящего к будущему» мы рассматривали развитие данного тезиса в применении к современным платформам: команды работают совместно как над платформой, так и над платформенными приложениями, публикуют изменения как в платформу (ввиду свойства открытости платформ), так и непосредственно в открытое программное обеспечение, развиваемое международными сообществами, создают новые топологии и варианты использования платформенных решений, что кардинально повышает производительность общей работы. А в случае продуктовой разработки мы идем дальше: команды совместно работают над продуктами, используя платформенный подход и опыт друг друга. При этом, создавая продукты, команды добавляют новые варианты использования для платформ и платформенных сервисов, публикуют дополнения общедоступными в рамках платформенной экосистемы, расширяя тем самым возможности не только самой платформы, но и смежных команд, работающих над другими продуктами. Со временем, как мы отмечали при рассмотрении платформенных подходов, должна стираться грань между платформенными и продуктовыми командами – развитие платформы начинает определяться потребностями продуктов, что повышает прозрачность деятельности и улучшает мотивацию всех членов команд продуктовой разработки. Необходимо подчеркнуть, что рассматриваемое повышение мотивации продуктивно сказывается и на экономической деятельности компаний, создающих и развивающих продукты. Если ключевым направлением финансирования, как мы отмечали выше, становится экспертиза, то мотивация носителей этой экспертизы, в том числе нематериальными стимулами, к которым относится использование решений с открытым кодом и следование философии открытого кода, является исключительно положительным моментом. И это становится важным мировоззренческим аспектом современного цифрового мира.
• Меритократия. Задачи меритократии в рассматриваемом контексте тесно связаны с предыдущим тезисом – мотивацией. Суть меритократии заключается в том, что полномочия при принятии решений каждого конкретного члена команды соразмерны его вкладу в общекомандное дело. И наша задача – обеспечить максимальную вовлеченность ответственных и компетентных членов команды. И вовлеченность их напрямую зависит от их мотивации. В контексте использования решений с открытым исходным кодом вклад каждого участника рабочего процесса является максимально прозрачным. И если мы выстраиваем платформы и продукты на их основе также с использованием практик открытого кода, то мы можем перенести указанную прозрачность и в корпоративную деятельность. А уже на основе прозрачности определять вклад каждого участника и, следовательно, степень его полномочий в рамках меритократии. В рамках совместной деятельности может быть выстроена не только меритократия отдельных членов команд, но и команд в целом. Мы уже говорили о том, что продуктовое развитие организации должно быть унифицированным технологически – этому способствует платформенный подход. И продуктовые команды, дополняя и развивая платформу организации, повышают и свой вес с точки зрения меритократии. Разумеется, когда мы говорим о продуктовой разработке, то меритократия не может исчерпываться исключительно дополнениями в платформу, необходимо учитывать скорость развития продуктов, их качество, их P&L и т. д. Из всех этих факторов складывается объем полномочий команд и их членов при развитии цифровизации в масштабах всей компании. А основу данной философии в ИТ дает открытый код. Архитектор же со своей стороны может проводить независимую оценку тех дополнений, которые вносятся членами продуктовых команд и командами в целом в платформу или общие используемые компоненты.
• Прозрачность принятых решений. Основываясь на принципах меритократии и обеспечив высокую мотивацию всех вовлеченных в процесс создания и развития продуктов специалистов, становится возможным достигнуть прозрачности при принятии решений в ходе продуктовой разработки, ведь последняя непосредственно влияет на развитие всей компании. Таким образом, обеспечивается прозрачность не только принятия решений, но и влияния всех членов команд разработки на общекорпоративное развитие в целом. Указанная прозрачность повышает вовлеченность и производительность труда всех специалистов, становясь дополнительным фактором повышения эффективности деятельности организации, увеличивая ее конкурентоспособность. Направление развития продукта непосредственно связано таким образом с развитием компании, развитие платформы прозрачно для продуктовых команд и также прозрачно для всех участников процесса создания ценности. Таким образом, все изменения, выполняемые в ходе рабочего процесса, становятся прозрачными, понятным оказывается их влияние как на текущее развитие, так и на более долговременные перспективы. Становится возможной грамотная оценка каждого изменения, учет его последствий, возникающих в ходе производственной деятельности рисков, в конечном итоге – предсказуемость развития платформы, продукта, компании в целом. И это также позволяет кардинально повысить производительность труда в компании, принявшей для себя mindset открытого кода, mindset открытой организации.