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

Существует #архитектура документации, которая включает в себя и её физическую структуру с точки зрения итоговых документов, так и логическую - из каких исходных материалов и каким образом эта документация образуется. Я с большим интересом смотрел презентацию дизайн системы МТС, первый раз видел такой системный, не побоюсь этого слова, архитектурный подход к дизайну. Даже у деятельности по созданию продукта есть архитектура, которая описывает структуру и взаимоотношения между работами, практиками, которые выполняются на разных стадиях жизненного цикла программной системы. То же самое касается и требований, и даже тестов. И конечно, этот список не исчерпывающий.

Вы конечно можете не думать про архитектуру этого всего. В общем-то, можете не думать и про архитектуру самой системы. 😉 Просто про ИТ архитектуру уже много написано. И рассказано, как плохо и вредно её игнорировать. Но что-то мне подсказывает, что игнорирование архитектуры "всего остального" обладает примерно такими же последствиями. И тоже приводит к образованию Big Ball of Mud в соответствующем месте. Со всеми, как говорится, вытекающими. 💩