В одном из прошлых постов я писал о том, что архитектура часто строится на вере:
Предлагаю порассуждать, что в архитектуре можно считать доказательством.
Как только мы произносим слово "доказательство" применительно к архитектуре, появляется соблазн понять его слишком буквально.
В математике доказательство — это вывод из аксиом, который верен всегда и везде. В физике — воспроизводимый эксперимент. В медицине — иерархия исследований, на вершине которой двойные слепые рандомизированные испытания. И во всех трёх случаях за словом "доказано" стоит вполне определённый, формализованный процесс.
В ИТ-архитектуре такого процесса нет. И, скорее всего, не будет. Мы не можем провести рандомизированное контролируемое испытание на двух одинаковых компаниях, в одной из которых внедрили event-driven, а в другой — нет. Мы не можем повторить эксперимент с теми же командами, тем же легаси и тем же рынком. Каждая наша система — это эксперимент с выборкой из одного элемента, который к тому же нельзя перезапустить.
Из этого факта обычно делают два противоположных и одинаково вредных вывода.
1️⃣. Раз строгое доказательство невозможно, то и говорить не о чем — архитектура была и останется делом опыта и вкуса, поэтому слушайте старших.
2️⃣. Раз доказательство невозможно, давайте сделаем вид, что возможно, обложимся метриками на каждый чих, заведём архитектурный комитет с формальными скорингами и будем называть это data-driven architecture.
Оба вывода ошибочны, и оба по одной и той же причине: они требуют от доказательства абсолютности. А нам в инженерии нужна не абсолютность. Нам нужно нечто гораздо более скромное и гораздо более полезное: умение различать сильные и слабые аргументы, умение собирать сигналы из реальной системы и умение честно отвечать на вопрос, на чём именно держится наше решение.
Зависит от контекста
Начнём с главного свойства любого архитектурного аргумента: он контекстен (все же помнят коронную фразу архитекторов и анекдот про попугая 💃?)
Контекстность встроена в саму ткань архитектуры — вплоть до того, что даже базовые понятия, которыми мы оцениваем "хорошесть" структуры, меняют знак даже от того. где мы проведем собственно границу нашего контекста.
Разберём на примере моего принципа каскадного снижения связанности:
Если даже фундаментальные свойства архитектуры не имеют оценки вне контекста, то конкретные архитектурные решения не имеют её тем более. "Микросервисы — это хорошо" — высказывание того же сорта, что "связи — это плохо". Оно не истинно и не ложно. Оно недоопределено́.
Поэтому когда я говорю о доказательстве в архитектуре, я всегда имею в виду конструкцию из трёх частей:
1️⃣ требования — описание назначения (целей), гипотез, поведения и свойств системы;
2️⃣явный контекст, в котором сделаны требования;
3️⃣способ их проверить в этом контексте.
Уберите любую из трёх частей — и доказательство развалится. Цель без контекста — это лозунг. Контекст без способа проверки — это сочинение на тему.. Способ проверки без целей и гипотез — это дашборд, на который никто не смотрит.
Из контекстности следует и ещё одна важная вещь: архитектурные доказательства устаревают. Решение, честно подтверждённое метриками три года назад, могло протухнуть вместе с контекстом: вырос масштаб, сменились команды, продукт повернул в другую сторону. В математике доказанная теорема остаётся доказанной навсегда. В архитектуре подтверждённая гипотеза остаётся подтверждённой до изменения условий. Это сама суть подхода — и именно поэтому в каждой архитектурной гипотезе мы должны прописывать явные условия пересмотра.
Я бы прям добавил такой пункт в формат ваших ADR — помимо обязательного описания контекста, в рамках которого принято решение; прописывать ещё и критерии и условия пересмотра (или устаревания) инженерного решения.
➡️ Продолжение следует.. в будущих постах продолжу тему доказательства и метрик в архитектуре
По сути, слишком большая часть архитектуры в индустрии до сих пор строится на вере. На вере в авторитет, в паттерны, в привычные формы, в чужой опыт и в надежду, что если у кого-то это уже сработало, то у нас тоже как-нибудь взлетит.
Предлагаю порассуждать, что в архитектуре можно считать доказательством.
Как только мы произносим слово "доказательство" применительно к архитектуре, появляется соблазн понять его слишком буквально.
В математике доказательство — это вывод из аксиом, который верен всегда и везде. В физике — воспроизводимый эксперимент. В медицине — иерархия исследований, на вершине которой двойные слепые рандомизированные испытания. И во всех трёх случаях за словом "доказано" стоит вполне определённый, формализованный процесс.
В ИТ-архитектуре такого процесса нет. И, скорее всего, не будет. Мы не можем провести рандомизированное контролируемое испытание на двух одинаковых компаниях, в одной из которых внедрили event-driven, а в другой — нет. Мы не можем повторить эксперимент с теми же командами, тем же легаси и тем же рынком. Каждая наша система — это эксперимент с выборкой из одного элемента, который к тому же нельзя перезапустить.
Из этого факта обычно делают два противоположных и одинаково вредных вывода.
1️⃣. Раз строгое доказательство невозможно, то и говорить не о чем — архитектура была и останется делом опыта и вкуса, поэтому слушайте старших.
2️⃣. Раз доказательство невозможно, давайте сделаем вид, что возможно, обложимся метриками на каждый чих, заведём архитектурный комитет с формальными скорингами и будем называть это data-driven architecture.
Оба вывода ошибочны, и оба по одной и той же причине: они требуют от доказательства абсолютности. А нам в инженерии нужна не абсолютность. Нам нужно нечто гораздо более скромное и гораздо более полезное: умение различать сильные и слабые аргументы, умение собирать сигналы из реальной системы и умение честно отвечать на вопрос, на чём именно держится наше решение.
Зависит от контекста
Начнём с главного свойства любого архитектурного аргумента: он контекстен (все же помнят коронную фразу архитекторов и анекдот про попугая 💃?)
Контекстность встроена в саму ткань архитектуры — вплоть до того, что даже базовые понятия, которыми мы оцениваем "хорошесть" структуры, меняют знак даже от того. где мы проведем собственно границу нашего контекста.
Разберём на примере моего принципа каскадного снижения связанности:
Возьмём классическую пару: связанность и прочность, coupling и cohesion. Полвека индустрия повторяет мантру: связанность — плохо, прочность — хорошо. Low coupling, high cohesion. Но ведь и то и другое — это просто связи между элементами. Почему одна связь хорошая, а другая плохая?
Ответ неожиданно прост и неожиданно неприятен для любителей абсолютных истин: связь становится связанностью или прочностью в зависимости от того, как проведены границы компонентов. Та самая связь, которая на одном уровне компонентизации была внешней связанностью (и считалась злом), после перерисовки границ оказывается внутренней прочностью (и считается добром). Сама связь при этом не изменилась ни на байт. Изменился контекст, в котором мы её оцениваем.
Если даже фундаментальные свойства архитектуры не имеют оценки вне контекста, то конкретные архитектурные решения не имеют её тем более. "Микросервисы — это хорошо" — высказывание того же сорта, что "связи — это плохо". Оно не истинно и не ложно. Оно недоопределено́.
Поэтому когда я говорю о доказательстве в архитектуре, я всегда имею в виду конструкцию из трёх частей:
1️⃣ требования — описание назначения (целей), гипотез, поведения и свойств системы;
2️⃣явный контекст, в котором сделаны требования;
3️⃣способ их проверить в этом контексте.
Уберите любую из трёх частей — и доказательство развалится. Цель без контекста — это лозунг. Контекст без способа проверки — это сочинение на тему.. Способ проверки без целей и гипотез — это дашборд, на который никто не смотрит.
Из контекстности следует и ещё одна важная вещь: архитектурные доказательства устаревают. Решение, честно подтверждённое метриками три года назад, могло протухнуть вместе с контекстом: вырос масштаб, сменились команды, продукт повернул в другую сторону. В математике доказанная теорема остаётся доказанной навсегда. В архитектуре подтверждённая гипотеза остаётся подтверждённой до изменения условий. Это сама суть подхода — и именно поэтому в каждой архитектурной гипотезе мы должны прописывать явные условия пересмотра.
Я бы прям добавил такой пункт в формат ваших ADR — помимо обязательного описания контекста, в рамках которого принято решение; прописывать ещё и критерии и условия пересмотра (или устаревания) инженерного решения.
➡️ Продолжение следует.. в будущих постах продолжу тему доказательства и метрик в архитектуре