Архитектура в масштабе

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

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

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

В этом контексте рассматриваются RFC и ADR. Предложение позволяет обсудить существенное изменение, а запись решения сохраняет выбранный вариант и его причины. Польза такого подхода — в доступности контекста для других команд и будущих участников разработки. Сам документ не заменяет обсуждение: без понятного назначения и связи с реальной работой формальная запись лишь добавляет ещё один слой документации.

На уровне предприятия доклад обсуждает подход Zachman и риск избыточной бюрократии. Описываемая компания не решает задачу простым созданием отдельной роли корпоративного архитектора. Вместо предположения, что единый метод автоматически подходит всем, рассматриваются практики, которые позволяют поддерживать общую картину и согласовывать решения при сохранении распределённой ответственности за продукты.

Один из таких инструментов — технологический радар по примеру ThoughtWorks: он помогает обсуждать принятие технологий, их применимость и отказ от устаревающих вариантов. Другой путь связан с платформенными решениями и переходом к PaaS, через которые общие подходы становятся частью повседневной разработки. Итоговый принцип — масштабировать не личный контроль архитектора, а доступные командам знания, правила и инструменты. Конкретное устройство при этом зависит от масштаба и задач организации.