Стартапы, ряд которых перерастает в технологические гиганты, используют для автоматизации своих потребностей программное обеспечение Х с открытым исходным кодом. При этом география компаний распределенная, они работают по всему миру и на регулярной основе публикуют изменения, производимые в Х. Необходимо отметить, что при развитии стартапов до уровня технологических лидеров они занимали на рынке ниши, которые оставались незанятыми (или занятыми в незначительном объеме) компаниями традиционных направлений человеческой деятельности. При этом и требования к ним предъявлялись новые. Например, упоминавшийся пример технологического гиганта Meta Platforms (ранее Facebook), предложившего миру глобальную социальную платформу, ставшую не только средством общения, формирования и продвижения социальных связей, но и площадкой ведения бизнеса, предполагал работу с принципиально новым кругом пользователей и партнеров, а также предложение и поддержку новых форматов работы. Данный пример предполагал качественно новые требования к используемому программному обеспечению, в результате специалисты компании активно развивали технологические платформы, публикуя вносимые изменения. В итоге программное обеспечение с открытым исходным кодом приобретало функционал, качественно отличавший его от «закрытых» решений.
Рисунок 11. Стартапы и открытый код (Х)
На Рисунке 11 показано, как стартапы, работающие в самых разных областях человеческой деятельности, создающие новые ее направления, используют и развивают программное обеспечение с открытым исходным кодом Х, составляя глобальную технологическую цепочку в рамках концепции разделения труда.
Более того, по мере роста технологических гигантов компании традиционных отраслей экономики также стремятся в открывающиеся и/или создаваемые новые рынки. И в этом случае программное обеспечение Х уже покрывает часть требуемого функционала, либо же обеспечивает выполнение нефункциональных требований. Например, созданная компанией Meta Platforms (ранее Facebook) распределенная СУБД Cassandra (ныне Apache Cassandra) исходно поддерживала децентрализованное исполнение и нереляционную логику, что на момент выхода ряда компаний на рынки, требовавшие распределенности, либо не поддерживалось популярными «закрытыми» СУБД, либо было побочным функционалом последних. Компании традиционных отраслей экономики (например, Goldman Sachs Group) также включаются в процесс работы над открытым кодом и зачастую публикуют производимые в нем изменения, тем самым дополнительно повышая функциональность и качество Х. Итогом подобного стремительного развития становится цепочка разделения и углубления труда, недостижимая «закрытыми» решениями, какими бы крупными корпорациями последние ни развивались. В соответствии с базовыми экономическими законами это обеспечивает и большую эффективность развития решений с открытым исходным кодом. Неудивительно, что данный класс программного обеспечения исключительно быстро прошел путь от удела небольших групп энтузиастов до флагманского направления ИТ.
На сегодня программное обеспечение с открытым исходным кодом используется крупнейшими компаниями, работающими во всех отраслях человеческой деятельности. И это является архитектурно значимым фактором, в корне меняющим характер деятельности архитекторов, а также само развитие архитектуры.
В эпоху господства «закрытого» программного обеспечения архитектор, работавший в компании-заказчике программных решений, при проектировании информационных систем учитывал ключевые решения компаний-поставщиков, имевшиеся с ними контракты, ключевые топологии, но при этом зачастую не погружался глубоко в особенности функционирования поставляемых комплексов. Многие знания были и закрыты от него, составляя богатство служб поддержки премиального уровня. Требования к архитектору, работавшему в компании, реализовывавшей решения на базе «закрытого» программного обеспечения, например, в компании-партнере поставщика соответствующего ПО, были во многом аналогичными. Результатами проектирования были программные комплексы, учитывавшие известные особенности и лучшие практики внедрения поставляемого программного обеспечения, дополненного кодом, разработанным на его основе.
Проектирование и разработка решений на основе программного обеспечения с открытым исходным кодом значительно отличаются. Данное программное обеспечение предоставляет широкий набор функциональных возможностей, обеспечивает выполнение широкого спектра нефункциональных требований, но нуждается в «тонкой» настройке, кроме того, его конфигурация выбирается в соответствии с такими особенностями создаваемого решения, как характер исполнения, число, характеристики и классы пользователей, категории функционала, подлежащего автоматизации, принципы хранения и обработки данных, а также многими другими. Архитектор при проектировании новой информационной системы должен учитывать все вышеупомянутые особенности, а также возможности использования открытого программного обеспечения, выбирать топологию последнего соответствующим образом. Безусловно, архитектор не может быть специалистом в деталях используемого программного обеспечения, но ключевые для создаваемого решения детали он обязан как знать, так и учитывать в архитектурном решении, делать на них акцент, задавая тем самым путь команде разработки. Если ранее недоброжелатели сравнивали работу архитектора с отрисовкой геометрических фигур («квадраты», «кубы»), серьезно упрощая ее, но используя в качестве основы для недобросовестной критики собственно результаты работы архитектора, то современные архитектурные решения содержат гораздо более глубокий уровень проработки, выбивающий почву из-под ног подобных критиков.
Проектирование и разработка решений на основе программного обеспечения с открытым исходным кодом значительно отличаются. Данное программное обеспечение предоставляет широкий набор функциональных возможностей, обеспечивает выполнение широкого спектра нефункциональных требований, но нуждается в «тонкой» настройке, кроме того, его конфигурация выбирается в соответствии с такими особенностями создаваемого решения, как характер исполнения, число, характеристики и классы пользователей, категории функционала, подлежащего автоматизации, принципы хранения и обработки данных, а также многими другими. Архитектор при проектировании новой информационной системы должен учитывать все вышеупомянутые особенности, а также возможности использования открытого программного обеспечения, выбирать топологию последнего соответствующим образом. Безусловно, архитектор не может быть специалистом в деталях используемого программного обеспечения, но ключевые для создаваемого решения детали он обязан как знать, так и учитывать в архитектурном решении, делать на них акцент, задавая тем самым путь команде разработки. Если ранее недоброжелатели сравнивали работу архитектора с отрисовкой геометрических фигур («квадраты», «кубы»), серьезно упрощая ее, но используя в качестве основы для недобросовестной критики собственно результаты работы архитектора, то современные архитектурные решения содержат гораздо более глубокий уровень проработки, выбивающий почву из-под ног подобных критиков.
Необходимо рассмотреть и другое важное обстоятельство. Ранее уже отмечалось, что в процессе революционных переходов от традиционных монолитных решений к современной микросервисной архитектуре с учетом продуктового подхода и принципов EDA проявилась тенденция на упрощение разработки отдельных программных компонентов с одновременным увеличением сложности проектирования информационных систем. Наряду с разрабатываемыми программными компонентами (микросервисами) используется программное обеспечение с открытым исходным кодом: СУБД, движки управления бизнес-процессами, кэширующие элементы, потоковые платформы и т. д. Ранее (в эпоху монолитных приложений и SOA) фреймворк разработки программного кода имел важное, если не определяющее значение. На сегодня микросервисы могут разрабатываться на любом языке программирования, с использованием любого подходящего фреймворка. И гораздо более важное значение приобретает не выбор языка программирования, но совместимость и полная поддержка всего функционала используемого открытого программного обеспечения. Последнее, как и практически любое направление человеческой деятельности, развивается неравномерно. Полноценная совместимость и поддержка функционала в экосистеме Java может опережать аналогичную для. NET и наоборот. И здесь также крайне важна роль (и полномочия в компании) архитектора, закладывающего соответствующий технологический выбор.
Соответственно, и развитие архитектуры направлено не только в сторону расширения функционала и повышения удобства фреймворков программирования, не только в сторону добавления функционала, конфигураций, отказоустойчивости открытых программных комплексов, но и на достижение их синергии при создании новых решений.
Использование открытого кода, увеличение роли стартапов, превращение последних в технологических гигантов привело также к фундаментальным изменениям в mindset всего рынка ИТ. Важную роль здесь играет и программное обеспечение с открытым исходным кодом, которое стало одним из ключевых факторов (наряду с культурой стартапов) в формировании так называемых открытых организаций. Последние описаны в книге Джима Уайтхерста (James M. «Jim» Whitehurst) «Открытая организация: Страсть, приносящая плоды» (2015, ISBN 978-5-9693-0405-5).
Целью настоящей книги не является изложение и разбор аспектов функционирования открытой организации. Важнее отметить другое: стартапы, превращаясь в технологические компании, сохранили культуру работы с открытым кодом, которая во многом формируется в рамках взаимного плодотворного влияния друг на друга открытого кода и общей производственной культуры компании-стартапа, предполагающей определенную свободу сотрудников. Успехи технологических гигантов, в короткое время выросших из стартапов, вдохновили на соответствующую трансформацию компании, имеющие давнюю историю работы. При этом трансформация осуществлялась не только в технологических компаниях, но и в тех организациях, непосредственная деятельность которых осуществлялась в других направлениях человеческой деятельности. По ходу данной книги отмечалось, что для современности характерно взаимовлияние ИТ и мира, превращающее все компании, которые развиваются с целью сохранения собственной конкурентоспособности, в технологические компании, оказывающие услуги в различных сферах бизнеса. Наглядным примером такой трансформации является «Сбербанк России», который предоставляет на основе собственной технологической платформы, созданной по гибким методологиям, целую экосистему услуг: финансовые, транспортные, деловые, медиа и многие другие. Таким образом, трансформация становится актуальной для всех мировых компаний. Происходит повсеместный переход к работе по гибким методологиям, цифровизация отраслей деятельности, открытие и занятие новых рынков, меняется mindset. И особенно важное влияние оказывает открытый код. Разберем это влияние в контексте архитектуры, основываясь на ключевым тезисах книги Джима Уайтхерста, посвященных открытой организации: