Андрей Трушкин - Архитектура цифрового мира

Необходимо рассмотреть и другое важное обстоятельство. Ранее уже отмечалось, что в процессе революционных переходов от традиционных монолитных решений к современной микросервисной архитектуре с учетом продуктового подхода и принципов EDA проявилась тенденция на упрощение разработки отдельных программных компонентов с одновременным увеличением сложности проектирования информационных систем. Наряду с разрабатываемыми программными компонентами (микросервисами) используется программное обеспечение с открытым исходным кодом: СУБД, движки управления бизнес-процессами, кэширующие элементы, потоковые платформы и т. д. Ранее (в эпоху монолитных приложений и SOA) фреймворк разработки программного кода имел важное, если не определяющее значение. На сегодня микросервисы могут разрабатываться на любом языке программирования, с использованием любого подходящего фреймворка. И гораздо более важное значение приобретает не выбор языка программирования, но совместимость и полная поддержка всего функционала используемого открытого программного обеспечения. Последнее, как и практически любое направление человеческой деятельности, развивается неравномерно. Полноценная совместимость и поддержка функционала в экосистеме Java может опережать аналогичную для. NET и наоборот. И здесь также крайне важна роль (и полномочия в компании) архитектора, закладывающего соответствующий технологический выбор.

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

Использование открытого кода, увеличение роли стартапов, превращение последних в технологических гигантов привело также к фундаментальным изменениям в mindset всего рынка ИТ. Важную роль здесь играет и программное обеспечение с открытым исходным кодом, которое стало одним из ключевых факторов (наряду с культурой стартапов) в формировании так называемых открытых организаций. Последние описаны в книге Джима Уайтхерста (James M. «Jim» Whitehurst) «Открытая организация: Страсть, приносящая плоды» (2015, ISBN 978-5-9693-0405-5).

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

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

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