Границы архитектора: точка сингулярности
Есть мнение (но я считаю это заблуждением): хороший архитектор - это тот, кто знает технологии. Кто разбирается в базах данных, фреймворках и паттернах. Кто может нарисовать схему и объяснить, почему именно так.
Это важно. Но это не главное.
Главное - понимать границы. В каждый момент проектирования архитектор должен видеть, где заканчивается его зона контроля и начинается зона неопределённости. Где он может принимать решения, а где - только фиксировать риски. Где он может гарантировать, а где - только предполагать. И второе - проверяемость этих границ. Как понять, что граница не пересечена? Как проверить, что система не вышла за пределы зоны контроля? Как сформулировать критерий, по которому можно сказать: "здесь мы ещё в зоне, а здесь - уже нет"?
Граница 1. Технологическая
Это то, что мы привыкли считать главным. Язык, фреймворк, база данных, протоколы. Архитектор должен знать, где заканчиваются возможности технологии и начинаются её ограничения. Где она работает предсказуемо, а где - начинает вести себя странно. Где она масштабируется, а где - упирается в потолок. Но эта граница - самая простая. Она описана в документации. Она проверяется тестами. Она не требует от архитектора рефлексии - достаточно опыта и внимательности.
Граница 2. Человеческая
Архитектор должен понимать не только технологию, но и команду. Что могут разработчики? Что они не могут? Что они будут делать, а что - нет? Где заканчивается их зона комфорта и начинается зона риска? И границы коммуникации. Как архитектор объясняет свои решения? Как он проверяет, что его поняли? Где он предполагает, что его услышали, а где - уверен? Эта граница сложнее технологической. Она не описана в документации. Она проверяется только живым диалогом. И если архитектор не видит эту границу - его решения будут идеальными на бумаге и неработающими в реальности.
Граница 3. Бизнес
Это границы, которые часто вообще не замечают, считая вводной задачей. Считаем, что бизнес знает, чего хочет. Но бизнес не всегда формулирует то, что ему действительно нужно. И почти никогда - то, что ему может понадобиться через год или два. И вообще никогда - что можно реализовать на базе строящейся архитектуры для получения дохода. Бизнес мыслит текущей задачей, текущим бюджетом, текущим спринтом. Архитектор должен мыслить следующим шагом, следующим годом, следующим масштабом. При этом, подсвечивая бизнесу до какой степени и что можно получить попутно: где есть дополнительные точки роста. Архитектура - это не просто "как сделать", а "как сделать так, чтобы бизнес мог расти, не переписывая всё заново".
Граница 4. Между "я знаю" и "я предполагаю" - точка сингулярности
Три предыдущие границы - важны. Но они - лишь подготовка. Самая сложная граница - между тем, что архитектор знает, и тем, что он предполагает. Между тем, что он проверил, и тем, что принял на веру. Между уверенностью и риском. И это - ключевая граница. Потому что она определяет всё остальное. Архитектор должен чётко разделять, что он знает, а что он предполагает. Что он проверил, а что он принял на веру. Где у него есть данные, а где - только интуиция. И он должен уметь формулировать это. Не только для себя, но и для команды. Чтобы все понимали, где они находятся в зоне уверенности, а где - в зоне риска.
Что это даёт?
Когда архитектор чётко разделяет знание и предположение, он перестаёт быть "человеком, который рисует схемы". Он становится тем, кто управляет рисками. Он не обещает того, чего не может гарантировать. Он не скрывает неопределённости. Он не притворяется, что знает всё. Он просто - говорит правду. И на основе этой правды команда может принимать решения. Заказчик может оценивать риски. Бизнес может планировать бюджет.
Итог
Технологии меняются. Команды меняются. Паттерны меняются. Границы остаются. Главный навык архитектора - не знание технологий. А умение видеть границы. И проверять их. И разделять знание и предположение.
Всё остальное - просто детали.