Системы можно конструировать на основе крупных элементов, созданных сторонними разработчиками

Раньше программные парадигмы были ориентированы на программирование (programming) как на основной вид деятельности, а проделанная работа измеря­лась в строках кода; архитектурно-ориентированная разработка во многих случа­ях направлена на компоновку (composing) и сборку (assembling) элементов, кото­рые, вероятнее всего, разрабатывались отдельно, а может быть, даже независимо друг от друга. Возможность такой композиции появляется по той причине, что архитектура определяет те элементы, которые можно ввести в систему. В то же время она ограничивает проведение замен (или добавлений), исходя при этом из того, как они взаимодействуют со своей средой, как получают и передают управ­ление, какие данные потребляют и производят, как обращаются к данным и при помощи каких протоколов они осуществляют обмен информацией и совместное использование ресурсов.

Одним из наиболее важных аспектов архитектуры является организация струк­туры ее элементов, интерфейсов и рабочих понятий. Взаимозаменяемость (inter-changeability) считается самым важным принципом этой организации. Запущен­ное в 1793 году Эли Уитни (Eli Whitney) массовое производство мушкетов по принципу взаимозаменяемых частей положило начало эпохе промышленного производства. В отсутствие надежных физических измерений эта идея не внуша­ла доверия. В контексте современного программного обеспечения, пока добиться надежного разграничения абстракций не удалось, принцип структурной взаимо­заменяемости кажется не менее устрашающим, однако от этого он не теряет сво­ей важности.

Готовые компоненты, подсистемы, совместимые интерфейсы передачи дан­ных — все они основываются на принципе взаимозаменяемости. При этом нере­шенными остаются многие проблемы, связанные с разработкой программного обеспечения методом композиции. Когда в качестве компонентов, претендующих на внесение и многократное применение, выступают индивидуальные подсисте­мы, сконструированные на основе противоречащих друг другу архитектурных допущений, интеграция их функций может столкнуться с непредвиденными слож­ностями. Вслед за Дэвидом Гарланом (David Garlan) и некоторыми его коллега­ми эту ситуацию стали называть архитектурным несоответствием (architectural mismatch).

Чем меньше, тем больше: ограничивать словарь проектных альтернатив выгодно

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

Свойства программного проекта определяются выбранным архитектурным образцом. Те образцы, которые в наибольшей степени подходят для решения кон­кретной задачи, повышают качество реализации конечного проектного решения, а иногда и упрощают балансирование противоречащих проектных ограничений — этот эффект достигается путем углубления анализа плохо изученных проектных контекстов и/или формулирования противоречивости технических требований.