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

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

Часто в таких случаях раздражение выплескивается на архитектора. Он же ведь эти диаграммы рисовал, а ведь мог бы вместо того пойти код писать. Только архитектор во всём это не виноват, ведь правда?