Понятие «архитектура» обычно определяют как “структурная декомпозиция системы, включающая ее разделение на части, их связность, механизмы взаимодействия и руководящие принципы, которые формируют проект системы.” [1]

Хотя, с технической точки зрения это не такое уж ошибочное определение, оно все же достаточно вольно интерпретируется.Оно может означать что угодно, от наброска высокоуровневого дизайна, едва ли имеющего отношение к технологии, коду, или фактическую систему, которая строится в соответствии с масштабным, четким, глубоко проработанным проектом, со множеством мелких деталей уровня кода. На практике, ни одно из этих представлений не обеспечивает нас достаточным объемом ведущих принципов, необходимых для понимания реального процесса разработки, требуемого вклада в “качественную” архитектуру. Первая форма достаточно абстрактна, чтобы предоставить конкретное руководство к разработке; вторая форма слишком преждевременная (избыточная), разработанная до того, как станут известны необходимые детали. Поэтому не удивительно, что некоторые участники Agile сообщества считают, что архитектура не является основной проблемой в разработке практического программного обеспечения.

В то же время Grady Booch и Martin Fowler [4] предлагают ценностно-ориентированные определения архитектуры программного обеспечения. Оба определяют архитектуру с точки зрения значимых решений, которые являются дорогостоящими и трудноизменяемыми. Paul Dyson и Andy Longshaw [5] расширили структурное рассмотрение архитектуры логически обоснованным "почему" фактором, который направляет ход проектных решений. Эти определения помогают нам посмотреть на архитектуру как на реалию, отвечающую набору требований, таких как функциональные требования, эксплуатационные характеристики и приспособленность разработчика.

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

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

--

Оригинал статьи: http://www.infoq.com/articles/architecture-and-agility-good-friends

Авторы: Frank Buschmann, Kevlin Henney

Литература

1 J. Rumbaugh, I. Jacobsen, and G. Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1998.

2 J. Spolsky, “Architecture Astronauts Take Over,” 1 May 2008.

3 G. Booch, “On Design,” blog, Mar. 2006.

4 M. Fowler, “Who Needs an Architect?,” IEEE Software, vol. 20, no. 5, 2003, pp. 11–13.

5 P. Dyson and A. Longshaw, Architecting Enterprise Solutions, John Wiley & Sons, 2004.

6 R. Faber, “Architects as Service Providers,”IEEE Software, vol. 27, no. 2, 2010, pp.33–40.

Еще интересные статьи на эту тему:

• Легкое документирование
• Лучше программировать, чем документировать
• Значение архитектуры для Agile разработки
• Авторитетность и власть - разные значения одного слова "authority"
• Архитектор в команде - лидерство или полномочия?