97 этюдов для архитекторов программных систем

Архитектурные компромиссы Марк Ричардс

Каждый архитектор программного обеспечения должен знать и понимать, что нельзя получить все сразу. На практике невозможно спроектировать архитектуру, одновременно обладающую высокой производительностью, высокой доступностью, высоким уровнем безопасности и высоким уровнем абстракции. Существует одна реальная история, которую архитекторы программного обеспечения должны знать, понимать и рассказывать своим клиентам и коллегам. Я имею в виду историю корабля «Ваза».

В 1620 году шла война между Швецией и Польшей. Желая побыстрее завершить эту дорогостоящую войну, король Швеции приказал построить галеон, который назывался «Ваза». Это был необычный корабль. Требования к нему были не похожи на требования к любому другому кораблю того времени. Он должен был иметь длину более 60 метров, нести 64 пушки на двух батарейных палубах, а также брать на борт 300 солдат за раз для безопасной доставки в Польшу по морю. Время поджимало, денег не хватало (звучит знакомо, да?). Занимавшийся этим судном кораблестроитель еще никогда не проектировал такие корабли. Он специализировался на меньших, однопалубных судах. Тем не менее он взялся за проектирование и постройку «Вазы», полагаясь на свой прежний опыт. В итоге корабль, соответствующий этим спецификациям, был построен. Наступил день спуска на воду. Корабль гордо выплыл в гавань, отсалютовал из всех пушек… и вслед за тем затонул.

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

Архитектор ПО может почерпнуть из этой истории много полезного и учесть этот печальный опыт при проектировании архитектуры программных продуктов. Попытка выполнить все требования сразу (как в случае с «Вазой») создает неустойчивую архитектуру, которая не решает толком ни одну из поставленных задач. Хороший пример такого рода — требование заставить сервис-ориентированную архитектуру (SOA, service-oriented architecture) заодно функционировать в качестве решения «точка-точка». Обычно это вынуждает обходить различные уровни абстракции, создаваемые подходом SOA, и в результате возникает архитектура, напоминающая блюдо спагетти из итальянского ресторана. В распоряжении архитектора имеется несколько инструментов для определения тех компромиссов, на которые приходится идти при проектировании архитектур. Два популярных метода такого рода — АТАМ (Architecture Tradeoff Analysis Method) и CBAM (Cost Benefit Analysis Method). Дополнительную информацию об АТАМ и СВАМ можно найти на сайте SEI (Software Engineering Institute).

Биография автора приведена ранее.