Мотивация. Достаточно давно зафиксирован следующий психологический аспект: совместная работа служит делу сплочения коллектива, в результате чего все участники рабочего процесса начинают работать более эффективно, повышая эффективность всей производственной цепочки в целом. Наиболее оптимальным проявлением совместной работы является значимость вклада каждого члена команды. Сложно придумать более наглядный пример совместной работы, нежели развитие решений с открытым кодом: команды профессионалов со всего мира вовлечены в данный процесс, каждый может публиковать вносимые изменения, включаясь в состав тех, кто развивает ведущие мировые технологические решения. Практика учета всех публикаций позволяет отметить вклад каждого, про эффективность же глобальной цепочки разделения труда уже говорилось выше. Отметим, что одним из основополагающих пунктов манифеста Agile являлся тезис о том, что лучшие технологические и архитектурные практики рождаются у самоорганизующихся команд. В масштабе глобальной цепочки разделения труда архитектор, во-первых, становится трендсеттером, который может и должен задавать и корректировать направление работы, во-вторых, он должен анализировать все те предложения и формирующиеся практики, которые идут от команд разработки, и учитывать их при создании архитектурных решений. Таким образом, роль архитектора существенно трансформируется. Если ранее он диктовал правила игры, но лишь высокоуровневые, то теперь он становится участником процесса, не только формируя базовые правила, но и учитывая наработки команд, а потому его решения должны быть гораздо более детализированными с соответствующей глубиной проработки. Следование новой роли требует расширения вовлеченности архитектора в процесс создания программного обеспечения, а также во все рабочие процессы.
Меритократия. При анализе и выборе технологических решений используются принципы меритократии, в соответствии с которыми полномочия при принятии решений соразмерны вкладу участников в развитие создаваемой или развиваемой информационной системы. В соответствии с данным тезисом, роль архитектора также меняется: принятие архитектурно-технологических решений исключительно на основе предшествующего опыта или наличествующих предубеждений категорически недопустимо. В обсуждение при принятии технологических решений включается широкий круг специалистов, принимающих участие в производственной цепочке (напомним, глобальной), учитываются практики, вырабатываемые командами и отдельными участниками развития. В стартапах подобная культура дала взрывной эффект, поэтому не было никаких оснований отказываться от нее при росте компаний до статуса технологических гигантов, а также при трансформации компаний традиционных отраслей человеческой деятельности. Практика же учета соразмерности вклада в общее дело весу вносимых предложений позволяет исключить возможность перехода обсуждения выбора технологического решения лишь в разбор большого числа «мусорных» предложений. Соответственно, в задачи архитектора входит обеспечение своего значимого вклада в дело создания и развития программного обеспечения, формирование соответствующего авторитета, в противном случае он превратится в технического писателя, задачи которого сведутся к фиксации предложений ведущих участников технологической цепочки. Отметим, что данный принцип работы побуждает сотрудников активнее участвовать в процессе создания ценности, ведь тогда их мнения по будущим направлениям развития будут иметь больший вес.
Прозрачность принятых решений. Очевидным следствием вышеперечисленных пунктов является прозрачность архитектурных решений для всех участников процесса создания программного обеспечения. В связи с этим следует подчеркнуть актуальность формирования архитектурных фреймворков, позволяющих вовлекать в обсуждение архитектуры максимально широкий круг участников. Создание и развитие в рамках общего решения артефактов, позволяющих вести дискуссии с узким кругом участников, становится малоэффективной потерей времени.
Развитие новых направлений. При развитии новых направлений в открытой организации часто принято начинать с разбора сырых идей, не дожидаясь доведения последних до совершенства. Эффективнее становится обсуждать сырые идеи, проводя их шлифовку в рамках итераций обсуждения, доработки, прототипирования и т. д. Подобный подход, идущий в русле гибких практик, оказывает существенное влияние на развитие архитектуры. Архитектурные артефакты следует представлять команде и выносить на обсуждение как можно раньше. Коррективы, вносимые командой, могут оказаться исключительно значимыми, а потому получить их в качестве направляющей необходимо на ранних этапах развития идей. При выработке лучших идей и практик следует искать баланс между предложениями, основываясь на принципах меритократии. Максимально ранний и широкий учет мнений позволяет выявлять ошибки на ранних этапах проектирования, что повышает эффективность всей технологической цепочки.
Прозрачность принятых решений. Очевидным следствием вышеперечисленных пунктов является прозрачность архитектурных решений для всех участников процесса создания программного обеспечения. В связи с этим следует подчеркнуть актуальность формирования архитектурных фреймворков, позволяющих вовлекать в обсуждение архитектуры максимально широкий круг участников. Создание и развитие в рамках общего решения артефактов, позволяющих вести дискуссии с узким кругом участников, становится малоэффективной потерей времени.
Развитие новых направлений. При развитии новых направлений в открытой организации часто принято начинать с разбора сырых идей, не дожидаясь доведения последних до совершенства. Эффективнее становится обсуждать сырые идеи, проводя их шлифовку в рамках итераций обсуждения, доработки, прототипирования и т. д. Подобный подход, идущий в русле гибких практик, оказывает существенное влияние на развитие архитектуры. Архитектурные артефакты следует представлять команде и выносить на обсуждение как можно раньше. Коррективы, вносимые командой, могут оказаться исключительно значимыми, а потому получить их в качестве направляющей необходимо на ранних этапах развития идей. При выработке лучших идей и практик следует искать баланс между предложениями, основываясь на принципах меритократии. Максимально ранний и широкий учет мнений позволяет выявлять ошибки на ранних этапах проектирования, что повышает эффективность всей технологической цепочки.
Основываясь на вышеизложенном, следует отметить, что практики использования открытого кода (как и гибких практик) оказывают существенное влияние на создание архитектурных решений, а также на mindset архитектора. Также необходимо отметить, что при росте текущих цепочек разделения труда в части создания решений с открытым исходным кодом возможно дальнейшее повышение эффективности в части развития ИТ на сегодняшний день данный потенциал расширения далеко не исчерпан. Исчерпание же соответствующего потенциала поставит вопрос о новом революционном переходе в сфере ИТ (при этом очевидно, что данный аспект необходимости революционного перехода не является единственным).
В завершение данного раздела автор выражает глубокую благодарность сообществу разработчиков и пользователей открытого кода, благодаря которым происходит столь интенсивное развитие ИТ. Особую благодарность мы выражаем фонду Apache Software Foundation, способствующему развитию огромного числа программных продуктов высшего мирового уровня, многие из которых автор и его коллеги использовали и продолжают использовать в своей непосредственной работе.
Архитектура и распределенность
Выше уже отмечалось, что распределенность является одной из ключевых тенденций развития архитектуры. При этом распределенность понимается в двух смысловых плоскостях: архитектура должна поддерживать распределенную структуру команд разработки, создающих новые ИТ-решения, а также распределенную топологию функционирования самих создаваемых ИТ-решений.
Как уже отмечалось, идеология развития программного обеспечения с открытым исходным кодом, создания решений на его основе позволили существенно увеличить цепочки разделения труда в сфере ИТ, что обеспечило кардинальное повышение эффективности реализации новых информационных систем. При этом при увеличении степени разделения труда растут риски отдельных участников цепочки, которые зависят от все большего числа поставщиков и потребителей. Данная тенденция характерна и для ИТ. Представим себе ситуацию, что информационную систему А разрабатывает команда из 100 человек. Но эти 100 человек не работают в одном офисе, выполняя заранее согласованные и спланированные блоки работ. Коллектив разбит на 10 команд по 10 специалистов, при этом каждая команда создает свой собственный блок функционала. Между блоками присутствуют зависимости как интеграционного (взаимодействие в рамках процессов обменов информацией), так и встраиваемого характера. Под последним традиционно понимается возможность включения результатов работы одной команды в рабочие блоки, создаваемые другой командой, в формате библиотеки. Современные технологии в части ИТ позволяют проводить тестирование функционала с помощью механизма «заглушек», эмулирующих функционал контрагентов, но указанный способ тестирования имеет известные пределы. Пример описываемой ситуации представлен на Рисунке 12.