В июне на конференции TechLeadConf в Питере я буду куратором и членом жюри архитектурной каты — соревнования по проектированию ИТ-архитектуры. И пока думаю, как это всё лучше организовать и по каким критериям потом оценивать решения, меня всё сильнее гложет одна неудобная мысль.
⚠️ Если попросить десять сильных архитекторов независимо друг от друга спроектировать одну и ту же систему, почти наверняка мы получим десять разных архитектур.
И ладно бы просто разных.
Почти каждая будет выглядеть убедительно.
В одной будут красивые bounded context’ы. В другой — event-driven и асинхронщина. В третьей — платформы, observability, service mesh и прочие признаки взрослой айтишечки. И почти у каждой найдутся разумные аргументы, ссылки на прошлый опыт и очень уверенная защита.
То есть проблема даже не в том, что решений много.
Проблема в том, что внешне они слишком часто выглядят одинаково правильными.
И вот тут начинается самое интересное.
А что мы тогда вообще оцениваем — красоту схемы, напор на защите, количество модных слов на квадратный сантиметр слайда, совпадение с тем, что сейчас считается хорошим тоном в индустрии?
Если честно, архитектурные решения слишком часто принимаются именно так. Никто, конечно, не говорит в лоб: “давайте возьмём Kafka, потому что у меня её ещё нет в резюме”. Нет, всё звучит намного благороднее: это стандарт индустрии, так делают в ◀️ваш любимый бигтех▶️, так правильнее, гибче, надежнее. И вот это вот всё.
Но если снять с решения красивую упаковку, очень часто под ней нет самого важного: нормальной логики, явных гипотез и понятных критериев проверки.
По сути, слишком большая часть архитектуры в индустрии до сих пор строится на вере. Не в мистическом смысле. На вере в авторитет, в паттерны, в привычные формы, в чужой опыт и в надежду, что если у кого-то это уже сработало, то у нас тоже как-нибудь взлетит.
На короткой дистанции такой подход иногда даже работает. На длинной — внезапно выясняется, что эту архитектуру трудно объяснить бизнесу, трудно пересмотреть, трудно измерить и ещё труднее развивать без новых слоёв случайной сложности.
И самое неприятное: у архитектуры, принятой на вере, обычно очень слабая связь с той реальностью, в которой ей потом жить.
И чем больше я думаю про архитектурную кату, тем меньше верю в оценку по красоте квадратиков. Кажется, смотреть надо на другое: есть ли у решения логика, понятно ли, от какого контекста оно отталкивается, и можно ли вообще проверить, что это не просто хорошо упакованное мнение.
Потому что хорошая архитектура начинается не там, где нарисовали самую убедительную схему.
А там, где у решения появляется связь с реальностью. Или где хотя бы обозначены гипотезы, почему так а не иначе, и как это вяжется с бизнесом. Гипотезы хотя бы можно будет проверить
⚠️ Если попросить десять сильных архитекторов независимо друг от друга спроектировать одну и ту же систему, почти наверняка мы получим десять разных архитектур.
И ладно бы просто разных.
Почти каждая будет выглядеть убедительно.
В одной будут красивые bounded context’ы. В другой — event-driven и асинхронщина. В третьей — платформы, observability, service mesh и прочие признаки взрослой айтишечки. И почти у каждой найдутся разумные аргументы, ссылки на прошлый опыт и очень уверенная защита.
То есть проблема даже не в том, что решений много.
Проблема в том, что внешне они слишком часто выглядят одинаково правильными.
И вот тут начинается самое интересное.
А что мы тогда вообще оцениваем — красоту схемы, напор на защите, количество модных слов на квадратный сантиметр слайда, совпадение с тем, что сейчас считается хорошим тоном в индустрии?
Если честно, архитектурные решения слишком часто принимаются именно так. Никто, конечно, не говорит в лоб: “давайте возьмём Kafka, потому что у меня её ещё нет в резюме”. Нет, всё звучит намного благороднее: это стандарт индустрии, так делают в ◀️ваш любимый бигтех▶️, так правильнее, гибче, надежнее. И вот это вот всё.
Но если снять с решения красивую упаковку, очень часто под ней нет самого важного: нормальной логики, явных гипотез и понятных критериев проверки.
По сути, слишком большая часть архитектуры в индустрии до сих пор строится на вере. Не в мистическом смысле. На вере в авторитет, в паттерны, в привычные формы, в чужой опыт и в надежду, что если у кого-то это уже сработало, то у нас тоже как-нибудь взлетит.
На короткой дистанции такой подход иногда даже работает. На длинной — внезапно выясняется, что эту архитектуру трудно объяснить бизнесу, трудно пересмотреть, трудно измерить и ещё труднее развивать без новых слоёв случайной сложности.
И самое неприятное: у архитектуры, принятой на вере, обычно очень слабая связь с той реальностью, в которой ей потом жить.
И чем больше я думаю про архитектурную кату, тем меньше верю в оценку по красоте квадратиков. Кажется, смотреть надо на другое: есть ли у решения логика, понятно ли, от какого контекста оно отталкивается, и можно ли вообще проверить, что это не просто хорошо упакованное мнение.
Потому что хорошая архитектура начинается не там, где нарисовали самую убедительную схему.
А там, где у решения появляется связь с реальностью. Или где хотя бы обозначены гипотезы, почему так а не иначе, и как это вяжется с бизнесом. Гипотезы хотя бы можно будет проверить