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

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

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

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

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

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

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

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

Рисунок 12. Распределенная команда разработки программного обеспечения

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

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