Читать книгу: «Цифровой продукт XXI века. Концепция и архитектура», страница 4

Цифровые продукты и открытый код

В наших предыдущих книгах («Архитектура цифрового мира» и «Архитектура цифровых платформ. От настоящего к будущему») мы указывали две исключительно важные даты для всего цифрового мира: 17 сентября 1991 года и 28 октября 2018 года. Обе приведенные даты имеют непосредственное отношение к открытому коду. В 1991 году Линус Торвальдс опубликовал исходный код ядра операционной системы Linux. И мы вновь и вновь повторяем, что это событие стало эпохальным, а дата 17.09.1991 – отсчетом новой эры программных продуктов. Не только программных продуктов с открытым исходным кодом, но вообще любых, поскольку незамедлительно возникла синергия открытых и «закрытых» (vendor-lock) программных продуктов, которая в дальнейшем лишь набирала силу. Фактически сегодня мы с уверенностью можем сказать, что любой программный продукт так или иначе использует открытый код.

Но это было лишь началом большого пути. Вторая из вышеприведенных дат знаменательна тем, что именно в этот день свершилась одна из наиболее значимых сделок в истории открытого кода. Корпорация, ставшая, казалось бы, синонимом масштабных, тяжеловесных, исключительно дорогостоящих решений, вложила огромные денежные средства в приобретение экспертизы в открытом коде. Да, формально сделка по покупке компанией IBM ведущего разработчика решений с открытым исходным кодом RedHat была просто очередным корпоративным мероприятием, каковых было множество на тернистом пути «голубого гиганта». Но подобные формальности можно считать сугубо вторичными. Главным же стало другое – рассматриваемая сделка ознаменовала собой ключевое изменение философии в цифровом мире в целом. Да, в программные решения вкладывается огромные труд, интеллектуальные ресурсы специалистов и исследователей со всего мира, но безусловным приоритетом на сегодня стала эффективность, эффективность создания новых решений, скорейшее предоставление ценности клиентам и партнерам. И открытый код стал тем решением, которое безусловно позволяет повысить указанную эффективность. По факту 28.10.2018 навсегда изменилось мировоззрение цифрового мира. На смену дорогостоящим тяжеловесным решениям (например, тем же масштабным серверам приложений) пришли легковесные программные компоненты, использовать которые могут команды по всему миру. Но не только использовать, но и развивать, расширять и улучшать.

В качестве примера дрейфа даже, казалось бы, апологетов vendor-lock решений в сторону открытости можно привести такой популярнейший фреймворк разработки и исполнения приложений, как. NET. Выпущенный из недр корпорации Microsoft, всегда считавшейся в ИТ среде едва ли не главным сторонником закрытости, популярный фреймворк также стал открытым. Сперва в 2014 году появилась открытая сборка. NET Core, впоследствии и весь. NET ушел от «темной стороны силы», если цитировать знаменитую киносагу. И не просто ушел в сторону открытого кода, но и полностью поддержал исполнение в Linux среде, теперь фреймворк развивается и такими компаниями, как упомянутая выше RedHat. То есть на наших глазах происходит синергия решений, которые самыми разными путями неумолимо движутся в сторону открытости. Кто-то исходно придерживался данной философии, кто-то переходил к ней в тяжелые корпоративные моменты, кто-то же, наоборот, на волне успеха. Но главное случилось – шаг в сторону приоритета открытого кода сделан. И это, если использовать метафору из еще одной исключительно популярной серии фильмов, та «красная таблетка», после которой невозможно смотреть на мир, как прежде.

Но в чем же заключается упомянутое повышение эффективности, которое дает открытый код? Что побуждает таких в прошлом апологетов закрытости, как IBM и Microsoft, выбирать этот путь? В книге «Архитектура цифрового мира» мы уже подробно разбирали ответы на эти вопросы. Вкратце напомним их читателю.

Современная экономическая теория, восходящая еще к итальянским натурфилософам, таким как Антонио Серра, выводит повышение эффективности из увеличения разделения труда – длинные экономические цепочки, предполагающие задействование большего числа участников, позволяют резко повышать общую эффективность. Серьезнейший вклад в развитие данной теории и ее систематизацию внес Адам Смит и его последователи. Есть представители и отечественной школы, внесшие свою лепту в развитие указанного научного направления, такие как М. Л. Хазин. Целью настоящей книги не является повторение всех их логических умопостроений, мы принимаем их выводы: увеличение разделения труда ведет к повышению производительности. И для области информационных технологий данный факт исключительно важен. Открытые решения позволяют вовлечь в их развитие такое количество специалистов со всего мира, которое невозможно ни для одного закрытого программного обеспечения, сколь бы крупная корпорация его ни развивала. И это принципиальный момент – открытые решения обеспечивают уровень производительности труда, недоступный для закрытых решений. Именно подобный уровень производительности труда и привел крупнейших игроков ИТ-рынка в стан сторонников открытого кода.

Что же все вышесказанное означает для цифровых продуктов? Мы и по ходу предыдущих книг, и в течение настоящего изложения неоднократно говорили о ценности, которую несет продукт клиентам и партнерам организации, создающей и развивающей продукт. Отмечали мы и P&L продукта в качестве его обязательной характеристики. То есть мы подчеркиваем тот факт, что ценность необходимо создавать как можно быстрее и эффективнее. Рассуждая же о преимуществах открытого кода, мы во главу угла ставим производительность труда, характеризующую развитие и использование открытых решений. Таким образом, применение открытых технологий становится ценностным мультипликатором, позволяющим существенно повысить производительность труда при создании и развитии современных продуктов. Это означает, что если ставится цель создавать конкурентоспособные продукты (а это в свою очередь означает, что должны выискиваться все варианты повышения производительности их разработки), то организация, имеющая указанную цель, обязана использовать открытое программное обеспечение.

Как и в случае с цифровыми платформами, продукт для своего эффективного развития должен использовать лучшие практики открытого кода. Платформа же, как мы неоднократно отмечали в книге «Архитектура цифровых платформ. От настоящего к будущему», предоставляет опосредованную ценность, позволяя разгрузить продуктовые команды от рутинной деятельности, что также приводит к росту производительности продуктовой разработки. То есть платформа также является ценностным мультипликатором. Мы приходим к логичному выводу: платформа должна использовать практики открытого кода, продукты же должны использовать практики открытого кода и разрабатываться на платформе. Сочетание указанных ценностных мультипликаторов позволяет многократно повысить производительность труда – мы уже ссылались в нашем предыдущем труде на исследование, показавшее, что технологические гиганты оказываются в состоянии вносить изменения, дополнения и в конечном счете улучшения в свои решения, находящиеся в постоянной эксплуатации, практически каждые десять секунд. Это и есть движение к достижению эффективности XXI века. Но только начало этого движения. Необходимо не просто не останавливаться на достигнутом, но и постоянно искать новые пути повышения производительности труда.

Неоднократно по ходу своей профессиональной деятельности автор этих строк сталкивается с вопросом: «Можно ли построить продукт вообще без какого-либо использования открытого кода?» Иногда этот вопрос ставится несколько по-другому: «Объектом уточнения становятся платформы, возможно ли создание последних без применения открытого кода?» И краткий ответ на подобные вопросы всегда один: «Можно». Читатель может удивиться: «Как же так, мне пришлось прочитать столько хвалебных од в адрес открытого кода, а теперь автор так просто признается, что сложнейшие программные комплексы можно создать и без него! Меня вводят в заблуждение!» На самом деле ввод читателя в заблуждение – это последнее, чего бы хотел добиться автор. Поэтому вслед за кратким ответом о принципиальной возможности создания продуктов без применения практик открытого кода необходимо дать более развернутое объяснение.

И поскольку настоящая книга, как и две предыдущие, посвящена архитектуре, то и объяснение, даваемое автором, также будет базироваться именно на архитектуре.

Для начала вернемся к детализации концептуальной архитектуры продукта, приведенной на Рисунках 9 и 10 и описанной в предыдущей главе. В соответствии с описанием в архитектуре задействованы такие программные компоненты и фреймворки, как:

• Языки программирования высокого уровня (в том числе позволяющие разрабатывать легковесные фронтальные решения).

• Реляционные СУБД.

• Нереляционные СУБД.

• Потоковое программное обеспечение.

• Кэширующие компоненты.

• BPM движки.

• Программное обеспечение для управления открытыми API.

• Распределенная файловая система.

• И т. д.

Для всех указанных пунктов существует свободно распространяемое программное обеспечение с открытым исходным кодом, позволяющее решать задачи по автоматизации продуктов. Пример такого сочетания технологий приведен на Рисунке 13. В очередной раз оговоримся, что мы приводим иллюстративный пример, а не разбираем конкретные случаи продуктовой разработки. Взаимодействие, показанное для технологий реализации, также является иллюстративным и может отличаться при конкретной продуктовой автоматизации. По сравнению с ранее приведенным примером мы на Рисунке 13 заменили BPM Camunda на BPM Kogito, чтобы следовать принципу выбора максимально открытой лицензии, тем более в главе, посвященной открытому коду.

Рисунок 13. Пример перечня технологий с открытым исходным

кодом для продуктовой автоматизации

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

Любое современное программное обеспечение, решающее задачи повышенной сложности, например в части управления базами данных, является огромным программным комплексом, содержащим множество компонентов. И даже в случае предоставления подобной СУБД в формате vendor-lock оно будет использовать значительное число внешних библиотек, требовать для своего исполнения определенного программного окружения. Это касается и программных библиотек в реализации, и компиляторов, и интерпретаторов, и многих других аспектов. И во всех этих компонентах содержится свободное программное обеспечение. В противном случае компания, предоставляющая соответствующее ИТ-решение, должна разработать его полностью самостоятельно, вплоть до компилятора. Подобная реализация, конечно, достижима, но оценить ее стоимость и сроки не представляется возможным. Мировые технологические гиганты идут другим путем и включают в предоставляемые ими решения компоненты с открытым исходным кодом, а зачастую и базируются на них. Ведь именно таким образом оказывается возможным выстроить максимально длинную цепочку разделения труда и снизить стоимость итогового ИТ-решения. Тем самым улучшается и P&L конечного продукта.

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

В ходе своей профессиональной деятельности (и особенно после выхода предыдущих книг) автору приходилось сталкиваться и с обратным вопросом: «Возможно ли построить современный цифровой продукт только с использованием открытых решений?» Зачастую собеседники автора высказывали сомнения в реализуемости подобной парадигмы.

Мы понимаем, что каждая компания действует в собственных финансовых, экономических, технологических и иных условиях. И поэтому однозначного рецепта по созданию продуктов дать не можем. Начнем свой ответ с совмещения Рисунков 9, 10, на которых представлена детализация концептуальной архитектуры продукта, и Рисунка 13, демонстрирующего пример сочетания ряда технологий с открытым исходным кодом, используемых в ходе продуктовой разработки. Проиллюстрируем указанное совмещение на Рисунках 14 и 15 (мы продолжаем разбивать детализацию архитектуры на два рисунка для удобочитаемости).

Рисунок 14. Детализация архитектуры продукта с использованием открытого программного обеспечения (часть 1)

Рисунок 15. Детализация архитектуры продукта с использованием открытого программного обеспечения (часть 2)

На Рисунках 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)

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

Нельзя обойти вниманием и еще один исключительно важный аспект использования решений с открытым исходным кодом – аспект безопасности. Часто можно услышать голоса, предостерегающие от использования открытого программного обеспечения. Нам пытаются доказать, что использование открытого кода таит в себе нешуточную опасность, мол, включить в него недокументированные возможности может каждый. Любой из коммитов, включенных в основную ветку программного продукта, потенциально является вредоносным. Это, безусловно, так. Но давайте подумаем о том, исключаем ли мы указанный риск при использовании закрытого проприетарного ПО. Ранее мы уже отмечали, что любое современное программное обеспечение основано на открытом коде. Даже при локализации всех пакетов в собственных репозиториях ни одна компания в мире не может себе позволить развивать все пакеты самостоятельно. И заимствование кода осуществляется на перманентной основе. И компания, внедряющая внешние решения в качестве основы продуктовой автоматизации, в любом случае должна полностью проверять все дистрибутивы программного обеспечения, получаемые извне. Это касается как открытых, так и проприетарных решений. И логичным следствием будет обязательный процесс сборки решений на инфраструктуре компании-заказчика. Мы отдаем себе отчет в том, что это непростой, трудоемкий и финансово обременительный процесс. Да, можно заключать с поставщиками контракты жизненного цикла и выставлять штрафные санкции в случае обнаружения уязвимостей и недокументированных возможностей в процессе жизненного цикла уже продуктовых решений. Но зачастую последствия подобного отложенного обнаружения окажутся для компании катастрофическими. Здесь тот случай, когда известная поговорка, что «скупой платит дважды», может оказаться избыточно мягкой. И мы приходим к логичному выводу, что в любом случае, какое бы программное обеспечение (открытое или проприетарное) ни использовалось, необходимо осуществлять максимально полный анализ его состава, структуры и возможностей с точки зрения информационной безопасности. И здесь как раз открытый код с его понятной и логичной структурой оказывается предпочтительным – его исследования осуществляются по всему миру с публикацией результатов, что и подтверждено масштабами внедрения успешных решений.