Рассмотрим, к примеру, задачу вывода нового продукта на рынок. Все мы считаем, что делать надо хорошо, а делать плохо - не надо. И потому нужно делать программы с использованием современных фреймворков, применять правильные паттерны декомпозиции и абстракции, а всяким легаси-системам место на свалке.

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

И вот тут очень нужен архитектурный взгляд, способность смотреть на программный продукт в динамике разработки и с учетом перспектив его развития. Выбрать, на чем можно сэкономить на ранних этапах, но сделать это так, чтобы получившийся продукт можно было постепенно развивать и улучшать, причем без полной переделки, не теряя темпа разработки. Т.е. нужно принимать технические решения не только "здесь и сейчас", но обязательно с учетом контекста, стратегических планов и перспектив.