Пара слов о значимости архитектуры

Отсутствие архитектуры столь же критично, как отсутствие требований к системе (вне зависимости от того, являются ли они иерархией полноценных требований или лишь набором user stories). И если к управлению требованиями за последние годы начали относится, наконец, с должным уважением, разработка архитектуры, зачастую, остаётся деятельностью достаточно хаотичной и бессистемной.

Я позволил себе привести ниже вольный перевод (м.б. и со смещением некоторых акцентов) характиристики двух сценариев - с архитектурой и без неё, которые в свое время были сформулированы экспертами Bredemeyer Consulting в замечательном, не потерявшем с моей точки зрения актуальности, материале " Enterprise Architecture as Business Capabilities Architecture ":

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

Например, использование тех или иных библиотек, соответствие топологии развёртывания компонент системы, ограничениям безопасности, доступности инфраструктуры, нагрузочным характеристикам и другим требованиям.

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

Моё резюме очень простое - и проектирование архитектуры и управление требованиями являются обязательными аспектами деятельности. Недостаточное внимание любой из этих областей - неприемлемо (да-да, столь максималистки ;) и так же как управление требованиями является дисциплиной, проектирование архитектуры - дисциплина (и в системной и в программной инженерии).

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