RustTTS/test_text_architecture.txt at main · askidmobile/RustTTS · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Архитектурные фреймворки: зачем они нужны, если все всё равно рисуют квадратики

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

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

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

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

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

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

Нет.

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

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

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