97 вещей которые должен знать solution arcitect - 22

2020-05-18 14:51:12 +0600 +0600

Architectural Tradeoffs

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

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

В 1620-х годах Швеция и Польша были в состоянии войны. Желая скорого окончания этой дорогостоящей войны, король Швеции заказал строительство корабля под названием Vasa.

Это был не обычный корабль. Требования к этому кораблю были непохожими на другие корабли того времени; он должен был быть длиной более 200 футов, иметь 64 орудия на двух палубах и иметь возможность безопасно перевозить 300 солдат через воды в Польшу.

Время было существенным, а денег было мало (звучит знакомо?). Корабельный архитектор никогда не проектировал такой корабль раньше.

Меньшие корабли были в его области знаний.

Тем не менее, архитектор корабля экстраполировал свой предыдущий опыт и начал проектирование и постройку Vasa.

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

Проблема с Vasa была очевидна; Любой, кто когда-либо видел палубу большого боевого корабля с 1600-х и 1700-х годов, знает, что палубы на этих кораблях были переполнены и небезопасны, особенно в бою.

Строительство корабля, который был одновременно боевым и транспортным, было дорогой ошибкой.

Архитектор корабля, пытаясь выполнить все желания королей, создал неуравновешенный и нестабильный корабль.

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

Хорошим примером трэйдофа является требование, чтобы сервис-ориентированная архитектура (SOA) работала так же, как и решение point-to-point.

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

Существует несколько инструментов, доступных архитекторам для определения компромиссов при проектировании архитектуры. Два популярных метода - метод анализа трэйдоф компромиссов архитектуры (ATAM) и метод анализа затрат и выгод (CBAM).

можно узнать больше об ATAM и CBAM, посетив Software Engineering Веб-сайты института (SEI) по адресу

http://www.sei.cmu.edu/architecture/ata_method.html and http://www.sei.cmu.edu/architecture/cbam.html

By Mark Richards