🏛 Архитектурные фреймворки: зачем они нужны, если все всё равно рисуют квадратики

На этой неделе хочу сделать небольшую серию про архитектурную базу.

Без академической пыли. Без “enterprise-шаманства”. Без ощущения, что архитектор - это человек, который просто рисует квадратики и усложняет жизнь команде.

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

В программе недели: • TOGAF - архитектура предприятия как процесс • Zachman Framework - таблица, которая учит задавать правильные вопросы • TOGAF vs Zachman - методология против классификатора • C4 Model - как объяснять архитектуру людям, а не только архитекторам • 12 правил архитектуры - практические принципы против хаоса • ADR - как фиксировать архитектурные решения, чтобы через полгода не играть в “кто это придумал?”

И начнем с главного вопроса: зачем все это нужно, если в итоге все равно рисуют схемы?

Одна из главных ошибок в архитектуре - считать, что архитектура начинается с диаграммы.

Нет.

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

Диаграмма - это уже упаковка мысли.

А если мысли нет, то получается не архитектура, а красивый скриншот без управленческой ценности.

🔹 Зачем нужны архитектурные фреймворки

TOGAF, Zachman, C4, ADR, архитектурные принципы - всё это часто воспринимают как бюрократию.

И иногда заслуженно.

Проблема начинается, когда фреймворк используют как религию: • надо заполнить все артефакты • надо пройти все этапы • надо нарисовать все виды • надо согласовать всё со всеми • надо сделать так, чтобы никто уже не помнил, зачем мы начинали

Но нормальный архитектор использует фреймворк не как клетку, а как набор линз.

Одна линза помогает увидеть бизнес-цели. Другая - данные. Третья - интеграции. Четвертая - ограничения. Пятая - последствия решений.

💡 Фреймворк не думает за архитектора

TOGAF не сделает вам архитектуру. Zachman не спасет плохую систему. C4 не заменит понимание домена. ADR не исправит хаос, если решения принимаются случайно.

Но они дают важную вещь - структуру мышления.

Потому что архитектура - это не “нарисовать микросервисы”.

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

⚠️ Важный момент

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

Они нужны, чтобы не забыть важное: • бизнес-контекст • данные • интеграции • риски • ограничения • стоимость изменений • ответственность • эксплуатацию • безопасность • эволюцию системы

Если фреймворк помогает думать - он полезен. Если фреймворк заменяет мышление - его пора выкинуть.

Если коротко: зрелая архитектура начинается не с диаграммы, а с умения задавать правильные вопросы.

#architecture #EnterpriseArchitecture #TOGAF #Zachman #C4Model #ITArchitecture