После этих книг, роман "Deadline" (который многие советуют), смотрится как бледное подражание

Можешь "на пальцах" TOC показать?

Это и есть обсуждение - нужно тему как-то поставить, отсылки к книгам это методичная-медленная работа - а у нас чат )

Да, можно частично согласиться. Но TOC шире чем ФТ и НФТ (анализ). ТОС больше про процесс и про принятие решений. Примеры из жизни: сокращается (увольняется) половина команды поддержки приложения. Нанять быстро не можем или нет бюджета. Это становится узким местом системы. Со стороны разработки концентрируем усилия на увеличение поддерживаемости (supportability) приложения, разгружаем поддержку от рутинной работы. Другой пример - разработка выдает продукт быстрее, чем QA могут протестировать. В этом случае QA - узкое место. Просим разработчиков помочь QA - организовываем автоматизированное тестирование, больше времени DEV команды тратим на реализацию качественного продукта (другие виды тестов - unit, integration и т.д). Третий пример - разработчик остался один в проекте - он узкое место. Меняем процесс таким образом, чтобы он не тратил время непродуктивно - освобождаем его от не очень важных активностей (к примеру оценка того, сколько займет разработка релиза - на данном этапе на это не надо тратить время), позволяем выдавать непротестированный продукт, который сразу же идет в QA команду и они ему показывают где ошибки,  подробно расписывают случаи когда они возникают, на что обратить внимание.

Как-то без полной цитаты ответ висит в воздухе )

Пока серия форвардов в полагании "так должно быть" - давай лучше диалог

Не читал, но по википедии кажется, что банальные ФТ и НФТ в понимании архитектора это оно и есть. Или шире - набор ключевых характеристик бизнеса, культуры, компании, проекта, продукта, системы итп, которые определяют архитектуру.
Часто представляют как совокупность осей (в гуманитарном смысле) с полюсами и диапазоном между ними: бизнес продуктовый или проектный, компания устроена иерархично или с плоской структурой, система онлайн или офлайн, с гарантированным временем отклика или нет, защищённая или нет, хранилище персистентное или нет, масштабируем линейно или нет, итд итп.

Я лично считаю, что основная работа архитектора это как раз выбор правильного набора ограничений (и приоритезация их), всё остальное проектирование (системы ли, солюшена ли, энтерпрайза, без разницы) - чисто механическая работа по компоновке подобранных таким образом кирпичиков.

Да, можно частично согласиться. Но TOC шире чем ФТ и НФТ (анализ). ТОС больше про процесс и про принятие решений. Примеры из жизни: сокращается (увольняется) половина команды поддержки приложения. Нанять быстро не можем или нет бюджета. Это становится узким местом системы. Со стороны разработки концентрируем усилия на увеличение поддерживаемости (supportability) приложения, разгружаем поддержку от рутинной работы. Другой пример - разработка выдает продукт быстрее, чем QA могут протестировать. В этом случае QA - узкое место. Просим разработчиков помочь QA - организовываем автоматизированное тестирование, больше времени DEV команды тратим на реализацию качественного продукта (другие виды тестов - unit, integration и т.д). Третий пример - разработчик остался один в проекте - он узкое место. Меняем процесс таким образом, чтобы он не тратил время непродуктивно - освобождаем его от не очень важных активностей (к примеру оценка того, сколько займет разработка релиза - на данном этапе на это не надо тратить время), позволяем выдавать непротестированный продукт, который сразу же идет в QA команду и они ему показывают где ошибки,  подробно расписывают случаи когда они возникают, на что обратить внимание.

"Ничем не отличается от здравого смысла" ©

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

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

Кстати, имхо, лучшее управленческое решение во всех вышеперечисленных ситуациях - перестать уже влезать с прямым управлением )
В том смысле, что люди сами перераспределят ресурсы и приоритеты наилучшим образом (а дальше длинная тирада про "если, конечно, они хоть сколько-нибудь мотивированы, нацелены на результат и им не запрещают отклоняться от регламентов")

мой последний форвард был быстрым ответом на "показать на пальцах"

На самом деле я хотел бы понять именно отношение сообщества, типа "Да, знаем, примерно так и работаем, только называем другими словами" или "Это не работает потому что ... (и дальше объяснение)" или "Нет, не слышали". Только не в виде опроса, а в виде обсуждения. А самое интересное, если кто-то ответит вторым пунктом и объяснит почему так.

У меня мнение что ТоС работает частично, из-за второстепенной для самой теории концентрации усилий в каждый момент времени на одной проблеме

Ну и ТоС похож на заделывание дыр по принципу где течет там и чиним

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

Не идентичным, но можно провести аналогии. Ну и вообще - если в руках TOC, то вокруг одни ограничения

"Это не работает потому что ..."
1) люди не рационализируемы до процесса
2) то, что можно рационализировать до процесса сразу же черствеет
3) чтобы не черствело, но был процесс - необходимы команды, понимающие Конвея, а не TOC

Близко к теме доклад про бородача максима Дорофеева