Архитектурно-экономический цикл

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

К. Моррис & К. Фергюсон [Morris 93]

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

Архитектура (architecture) — предмет настоящего исследования - является неотъемлемым этапом процесса проектирования. Программная архитектура (software architecture) содержит в себе структуры, из которых складываются крупные программные системы. Архитектурное представление системы абстрактно; не затрагивая детали реализации, алгоритмы и представление данных, оно ориентировано на поведение и взаимодействие «черных ящиков». Появление программной архитектуры — это первый шаг на пути к созданию системы с заданными свойствами. Подробно программная архитектура рассматривается в главе 2. Пока что, не вдаваясь в подробности, мы приведем ее определение.

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

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

ШВЕДСКИЙ ВОЕННЫЙ КОРАБЛЬ «ВАЗА»

1620-е годы ознаменовались войной между Швецией и Польшей. Король Швеции Густав Адольф, предполагая завершить ее быстро и победоносно, распорядился спустить на воду новый военный корабль невиданной ранее мощи. «Ваза», изображенный на рис.' 1.1 Одолжен был стать самым грозным орудием войны во всем мире. Его длина составляла 70 метров, на нем помещалось 300 солдат, а на двух орудийных палубах было установлено 64 тяжелых орудия. Желая обеспечить своему флоту подавляющее преимущество и нанести противнику решающий удар на море, король потребовал загрузить «Ваза» орудиями до отказа. Создателем корабля был Хенрик Хибертсон (Henrik Hybertsson) — опытный голландский судостроитель с безупречной репутацией, — но и для него столь грандиозный проект был первым. Двухпалубные корабли в то время встречались крайне редко, и среди них не было ни одного, сравнимого с «Ваза» по размерам и вооружению.

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

безнадежность этого проекта, но ему повезло умереть примерно за год до окончания строительства.

Громадное судно, построенное согласно его инструкциям, спустили на воду 10 августа 1628 года. Сразу после пушечного салюта, произведенного по выходе в глубокую стокгольмскую гавань, корабль накренился на борт. Вода хлынула в трюм через орудийные порты, и «Ваза» опрокинулся. Через несколько минут его первое и единственное плавание закончилось на 30-метровой глубине. Десятки членов экипажа, составившего в общей сумме 150 человек, утонули.

По результатам проведенного расследования установили, что корабль был «скверно спроектирован». Другими словами, никчемной оказалась его архитектура. С высоты сегодняшнего уровня знаний мы можем заключить, что Хибертсон не справился с балансированием противоречивых ограничений. В частности, в его деятельности отсутствовали управление рисками и требованиями заказчика (хотя, вероятно, лучше с этой задачей не справился бы никто). Он молча согласился с изложенными требованиями, хотя те были невыполнимы.

История «Ваза», насчитывающая уже 375 лет, служит прекрасной иллюстрацией архитектурно-экономическому циклу: задачи компании определяют требования, требования определяют архитектуру, а архитектура — систему. Архитектура ограничена опытом архитектора и современным уровнем технической оснащенности. У Хибертсона не было ни опыта, ни необходимых технических средств.

Наша книга содержит три элемента, которые могли бы ему пригодиться:

1. Конкретные примеры удачной архитектуры, которые, с одной стороны, удовлетворяют выдвинутым требованиям, а с другой — расширяют современную техническую базу.

2. Методы оценки архитектуры, проводящейся до построения на ее основе систем и, таким образом, способствующей снижению рисков, связанных с реализацией беспрецедентных проектов.

3. Приемы инкрементной (пошаговой) архитектурно-ориентированной разработки, позволяющей своевременно исправлять изъяны проектов.

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

- РСС

Эта позиция недальновидна (см. врезку «Шведский военный корабль “Ваза”») и неполна. Как вы думаете, что произойдет, если двум архитекторам, работающим в разных компаниях, представить одну и ту же спецификацию требований к системе? Будут ли созданные ими варианты архитектуры тождественны?

Как правило, в таких случаях варианты архитектуры получаются разными; следовательно, утверждение о том, что архитектуру определяют исключительно требования, неверно. Существуют и другие факторы влияния, и не обращать на них внимания — все равно что работать впотьмах.

Поставим уточняющий вопрос: какова связь между программной архитектурой системы, с одной стороны, и средой, в которой эта система конструируется и используется? Ответ на этот вопрос составляет лейтмотив настоящей книги. Программная архитектура появляется как результат взаимодействия технических, экономических и социальных факторов влияния. Впоследствии архитектура оказывает обратное, причем довольно существенное, воздействие на технические, экономические и социальные условия, а также косвенное влияние на последующие варианты архитектуры. Эту совокупность влияний, распространяющихся от среды на архитектуру, а затем обратно на среду, мы предпочитаем называть архитектурно-экономическим циклом (Architecture Business Cycle, ABC).

В настоящей главе мы проводим подробный анализ ABC и тем самым подготавливаем почву для подачи всего последующего материала. В четырех частях книги цикл рассматривается с различных точек зрения:

♦ каким образом задачи компании определяют требования и стратегию разработки;

♦ как на основе требований получается архитектура;

♦ как производится анализ вариантов архитектуры;

♦ каким образом на основе архитектуры создаются системы, задающие для компании новую, более высокую планку по части возможностей и требований.

1.1. Откуда берутся варианты архитектуры?

Любая архитектура являет собой результат принятия ряда экономических и технических решений. Эти факторы влияния играют свою роль в процессе проектирования, а их конкретная реализация обусловливается средой, в которой архитектура должна работать. Архитектор, которому для проектирования системы отводятся сжатые сроки в реальном времени, принимает одни проектные решения; тот же архитектор, не стесненный временными ограничениями, принимает уже другие решения. Еще один ряд решений принимается в ходе разработки системы вне реального времени. Даже если архитектору предъявляют те же требования, предоставляют то же оборудование, сопроводительное программное обеспечение и тот же штат, что и пять лет назад, сегодня он, скорее всего, будет принимать новые решения.

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

Анализ архитектурно-экономического цикла мы начнем с выявления различных факторов влияния — как тех, что воздействуют на архитектуру, так и тех, посредством которых она воздействует на среду.