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

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

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

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

      При соблюдении озвученных выше принципов команды, представленные на Рисунке 13, могут работать независимо друг от друга и располагаться территориально таким образом, насколько это наиболее эффективно с точки зрения цепочки разделения труда. Команда 1 может работать в Москве, команда 2 в Екатеринбурге, команда 3 в Новосибирске. Инфраструктурная поддержка команд разработки может осуществляться из Санкт-Петербурга. Города представлены в качестве иллюстративного примера. В случае создания продуктов, имеющих меньшую зависимость от локализованных правил регулятора, возможно размещение команд в самых разных уголках Земли. Иллюстративно это представлено на Рисунке 14.

      Рисунок 14. Географически распределенная