Текст бизнес-книги "Архитектура цифрового мира"

Автор книги: Андрей Трушкин

Раздел: Компьютеры: прочее, Компьютеры

• События должны быть «тонкими». Исключается передача в составе одного события больших объемов данных, создающих избыточную нагрузку на инфраструктуру.

• Фиксация событий. События отражают уже случившиеся изменения в микросервисах или системах, а не являются отложенными командами на исполнение.

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

• Наличие реестра схем. Общая структура событий и возможность быстрого получения ее, в том числе во время исполнения разработанных решений, позволит снизить число ошибок при выполнении микросервисов и информационных систем в течение их жизненного цикла.

• Валидация событий. При взаимодействии микросервисов и информационных систем между собой посредством EDA возможна публикация событий с некорректной структурой, что особенно актуально для распределенной мелко гранулированной информационной системы. Структуры событий должны проверяться на соответствие схемам для обеспечения надежности.

• Бизнес-ориентированность. События должны отражать значимые изменения в состоянии микросервисов и информационных систем. В противном случае в архитектуре возникнут риски создания большого количества незначимых событий, не несущих ценности, но снижающих прозрачность ИТ-ландшафта и создающих избыточную нагрузку на инфраструктуру.

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

• Возможность самопотребления. Микросервисы могут сами реагировать на опубликованные ими события. Такая возможность должна обеспечиваться при реализации.

Пример решения, выстроенного в соответствии с концепциями микросервисной архитектуры, продуктового подхода и EDA, представлен на Рисунке 10.

Рисунок 10. Пример продуктовой микросервисной архитектуры в сочетании с EDA

На Рисунке 10 показаны два банковских продукта, автоматизируемых в соответствии с принципами микросервисной архитектуры и EDA. Основной интеграционный поток осуществляется посредством публикации событий, управление которыми осуществляет платформа событийного обмена, представляющая собой внешний по отношению к микросервисам технический компонент. Отличие указанной платформы от ESB-решений эпохи SOA заключается в строго техническом характере решения и «пассивном» положении платформы в ИТ-ландшафте – она не оказывает непосредственного концептуального влияния на интегрируемые микросервисы. При этом прямые интеграционные взаимодействия между микросервисами также присутствуют, но минимизированы.

Сочетание микросервисной архитектуры, продуктового подхода и EDA позволило многих компаниям провести кардинальную трансформацию своего ИТ-ландшафта, осуществив новый революционный переход, и значительно повысить качество предлагаемых услуг, обеспечить высокую скорость внесения изменений и вывода продуктов на рынок. При этом на новый качественный уровень вышли производительность и надежность их решений. Соответствующие архитектурные подходы используются в LinkedIn, Uber, Netflix, Monzo Bank и других технологических лидерах современности.

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

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

Многие компании, активно развивающиеся в различных направлениях человеческой деятельности, имеют давнюю по меркам ИТ историю, что непосредственно сказывается на уровне их автоматизации. В России крупнейшие корпорации осуществляют автоматизацию своей деятельности 25—30 лет, в США и Западной Европе этот процесс даже более длителен. По ходу развития возникает ситуация сосуществования ИТ-решений различных поколений: рядом сосуществуют монолитные решения, многие из которых разработаны с использованием устаревших технологических стеков, сервис-ориентированные решения, есть наработки с использованием микросервисной архитектуры. Нередко в профессиональном экспертном сообществе поднимается вопрос, зачастую инициируемый и заказчиками решений по автоматизации, который заключается в том, какой путь выбрать в части архитектурных преобразований: эволюционный или революционный. В случае перехода организации, обладающей большим объемом унаследованного (legacy) ИТ-ландшафта вопрос можно конкретизировать следующим образом: стоит ли дробить системы предыдущего поколения на микросервисы, либо стоит создавать новый ИТ-ландшафт фактически с нуля.

Первый из представленных способов видится более простым, управляемым и (ключевое заблуждение) дешевым. К сожалению, большая часть комментариев негативного характера в адрес микросервисной архитектуры, о которых говорилось выше, обусловлена именно приоритетом данному варианту развития (эволюционному). На первый взгляд, ситуация кажется простой: провести анализ созданных ранее решений, выделить в них те элементы, которые могут представлять собой микросервисы, а далее провести реализацию очерченного функционала в соответствии с намеченным планом и на новом технологическом уровне. При этом зачастую к новым решениям применяется mindset прошлого – типовым вариантом разбиения информационных систем на микросервисы стала реализация функциональных подсистем в формате отдельных микросервисов. При этом подсистемы зачастую были сильно связаны между собой, содержали большое количество перекрестных вызовов, так называемые «божественные» объекты и функции (содержащие избыточное количество данных и функционала соответственно). Результатом обычно был рассмотренный по ходу настоящего раздела «распределенный монолит». Снижалась производительность систем, их надежность и управляемость ИТ-ландшафта организаций в целом. Релизные модели и циклы предыдущих поколений не позволяли эффективно управлять жизненным циклом изменений, объемы регрессионного тестирования существенно возрастали. Для устранения возникавших проблем приходилось расширять штат специалистов, решать возникшие проблемы механическим увеличением трудозатрат; альтернативой становился революционный переход (при этом существенные временные, трудовые и финансовые ресурсы уже были вложены в попытку перехода эволюционного).

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

Таким образом, варианты революционного и эволюционного развития архитектуры можно уподобить Сцилле и Харибде из «Одиссеи»: проход рядом со скалой Сциллы грозил Одиссею и его спутникам гибелью части экипажа, Харибда же – общей гибелью всех мореходов. Именно поэтому главным аспектом архитектурного перехода, развития архитектуры являлся и является mindset, который должен быть направлен строго на революционное развитие.

Архитектура и открытый код

Ранее уже отмечалось, что использование решений с открытым исходным кодом является одной из ключевых тенденций развития современной архитектуры. Следование данной тенденции позволяет существенно ускорить разработку новых ИТ решений, а также повысить их качество, но и предъявляет новые требования к работе архитектора.

17 сентября 1991 года Линус Торвальдс опубликовал в сети исходный код ядра операционной системы Linux, что считается началом эпохи программных продуктов с открытым исходным кодом. Долгое время программное обеспечение с открытым исходным кодом, имевшее свободно распространяемые версии, считалось уделом узких групп энтузиастов, его применение в реальной промышленной среде представлялось нецелесообразным ввиду опасений в части надежности, безопасности, сопровождения и т. д. Тем не менее, данное направление программного обеспечения оказалось востребовано стартапами (как утверждали недоброжелатели, исключительно из-за фактора отсутствия лицензионных платежей). Но и по мере успеха ряда стартапов и превращения их в технологические гиганты (например, Meta Platforms, ранее Facebook), интерес уже лидеров технологического рынка к решениям на базе открытого кода не только не снижался, но и сами компании стали активными участниками процесса создания новых решений с открытым исходным кодом – выше уже приводился пример распределенной СУБД Apache Cassandra (исходно проект создан в Facebook). Можно утверждать, что существует связь между гибкими практиками разработки, решениями с открытым исходным кодом и технологическим прорывом.

В XVII веке итальянский философ и экономист Антонио Серра в работе «Краткий трактат о средствах снабдить в изобилии золотом и серебром королевства, которые их не добывают» отметил: «Если ты хочешь узнать, какой из двух городов богаче, определи, каким количеством профессий владеют его жители. Чем больше профессий, тем богаче город». Приведенный тезис можно считать первым направлением в оценке влияния разделения труда на общую эффективность производства. Развитие данных наработок было произведено Адамом Смитом в труде «Исследование о природе и причинах богатства народов». Результатом стала теория разделения труда как основы повышения эффективности производственных цепочек. В дальнейшем данный тезис практически не оспаривался как сторонниками учения Смита, так и противниками. Необходимо отметить, что для ИТ данная теория также справедлива. Развитие и использование решений с открытым исходным кодом является ее наглядным подтверждением.

Безусловно, отсутствие лицензионных платежей было важным фактором, обусловившим использование открытых решений в стартапах. Но сводить все к фактору «бесплатности» в корне неверно. «Бесплатных» технологий не существует: свободно распространяемое программное обеспечение исходно требовало значительно больших усилий для достижения требуемых показателей работоспособности, нежели «закрытое» (vendor-lock), в случае которого можно было полагаться на экспертизу сотрудников компании поставщика. Но именно этот аспект, исходно казавшийся негативным, оказался серьезным преимуществом. За поставляемым солидными компаниями программным обеспечением стояли истории успеха, лучшие практики, «золотые» топологии, крупные и длительные проекты внедрений. В случае необходимости получения быстрых результатов и минимально жизнеспособного продукта, поставка которого заказчикам и/или инвесторам становилась вопросом выживания стартапов, во всех перечисленных выше атрибутах «закрытого» программного обеспечения не было практического смысла. Гораздо более важными аспектами, характеризующими технологии, были возможности максимально быстрой адаптации под нужды компании – добавление нового функционала, исправление ошибок, отработка новых конфигураций и т. д. В этих аспектах «открытое» программное обеспечение априори превосходило «закрытое». С одной стороны, у компании-стартапа была возможность доработки технологий с открытым исходным кодом под максимально полную технологическую синергию с решаемыми задачами. С другой стороны, заказчик получал решение именно своих конкретных задач, а не реализацию и повторение шаблонов прошлого. Указанные аспекты приносили открытому программному обеспечению соответствующую популярность. С ростом популярности происходило расширение и углубление разделения труда в разработке технологий.

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

Стартапы, ряд которых перерастает в технологические гиганты, используют для автоматизации своих потребностей программное обеспечение Х с открытым исходным кодом. При этом география компаний распределенная, они работают по всему миру и на регулярной основе публикуют изменения, производимые в Х. Необходимо отметить, что при развитии стартапов до уровня технологических лидеров они занимали на рынке ниши, которые оставались незанятыми (или занятыми в незначительном объеме) компаниями традиционных направлений человеческой деятельности. При этом и требования к ним предъявлялись новые. Например, упоминавшийся пример технологического гиганта 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. И особенно важное влияние оказывает открытый код. Разберем это влияние в контексте архитектуры, основываясь на ключевым тезисах книги Джима Уайтхерста, посвященных открытой организации:

• Мотивация. Достаточно давно зафиксирован следующий психологический аспект: совместная работа служит делу сплочения коллектива, в результате чего все участники рабочего процесса начинают работать более эффективно, повышая эффективность всей производственной цепочки в целом. Наиболее оптимальным проявлением совместной работы является значимость вклада каждого члена команды. Сложно придумать более наглядный пример совместной работы, нежели развитие решений с открытым кодом: команды профессионалов со всего мира вовлечены в данный процесс, каждый может публиковать вносимые изменения, включаясь в состав тех, кто развивает ведущие мировые технологические решения. Практика учета всех публикаций позволяет отметить вклад каждого, про эффективность же глобальной цепочки разделения труда уже говорилось выше. Отметим, что одним из основополагающих пунктов манифеста Agile являлся тезис о том, что лучшие технологические и архитектурные практики рождаются у самоорганизующихся команд. В масштабе глобальной цепочки разделения труда архитектор, во-первых, становится трендсеттером, который может и должен задавать и корректировать направление работы, во-вторых, он должен анализировать все те предложения и формирующиеся практики, которые идут от команд разработки, и учитывать их при создании архитектурных решений. Таким образом, роль архитектора существенно трансформируется. Если ранее он диктовал правила игры, но лишь высокоуровневые, то теперь он становится участником процесса, не только формируя базовые правила, но и учитывая наработки команд, а потому его решения должны быть гораздо более детализированными с соответствующей глубиной проработки. Следование новой роли требует расширения вовлеченности архитектора в процесс создания программного обеспечения, а также во все рабочие процессы.

• Меритократия. При анализе и выборе технологических решений используются принципы меритократии, в соответствии с которыми полномочия при принятии решений соразмерны вкладу участников в развитие создаваемой или развиваемой информационной системы. В соответствии с данным тезисом, роль архитектора также меняется: принятие архитектурно-технологических решений исключительно на основе предшествующего опыта или наличествующих предубеждений категорически недопустимо. В обсуждение при принятии технологических решений включается широкий круг специалистов, принимающих участие в производственной цепочке (напомним, глобальной), учитываются практики, вырабатываемые командами и отдельными участниками развития. В стартапах подобная культура дала взрывной эффект, поэтому не было никаких оснований отказываться от нее при росте компаний до статуса технологических гигантов, а также при трансформации компаний традиционных отраслей человеческой деятельности. Практика же учета соразмерности вклада в общее дело весу вносимых предложений позволяет исключить возможность перехода обсуждения выбора технологического решения лишь в разбор большого числа «мусорных» предложений. Соответственно, в задачи архитектора входит обеспечение своего значимого вклада в дело создания и развития программного обеспечения, формирование соответствующего авторитета, в противном случае он превратится в технического писателя, задачи которого сведутся к фиксации предложений ведущих участников технологической цепочки. Отметим, что данный принцип работы побуждает сотрудников активнее участвовать в процессе создания ценности, ведь тогда их мнения по будущим направлениям развития будут иметь больший вес.

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

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

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

В завершение данного раздела автор выражает глубокую благодарность сообществу разработчиков и пользователей открытого кода, благодаря которым происходит столь интенсивное развитие ИТ. Особую благодарность мы выражаем фонду Apache Software Foundation, способствующему развитию огромного числа программных продуктов высшего мирового уровня, многие из которых автор и его коллеги использовали и продолжают использовать в своей непосредственной работе.