Архитектура программного обеспечения — это совокупность значимых решений об организации системы: выбор структурных элементов и их интерфейсов, описание их поведения в рамках взаимодействия, а также объединение этих элементов в подсистемы всё возрастающего масштаба. Но прежде чем погружаться в стили и паттерны, необходимо разобраться, кто принимает эти решения и почему разные контексты требуют разных ролей. В этом уроке мы рассмотрим работу архитектора, необходимые для неё навыки и таксономию типов архитектур, с которыми вы встретитесь на практике.
Расхожий образ архитектора — человека, который спускает схемы с небес и раздаёт указания командам, — давно устарел. Современные архитекторы работают в четырёх взаимопересекающихся измерениях: техническое лидерство, проектирование систем, коммуникация внутри организации и непрерывное обучение. Они определяют атрибуты качества (производительность, масштабируемость, безопасность, сопровождаемость), переводят бизнес-цели в структурные ограничения, наставляют команды разработки и берут на себя ответственность за решения, которые иначе принимались бы несогласованно в разных командах.
Архитектура — одна из немногих ролей, требующих одновременно и предельной глубины, и предельной широты. Старший инженер может быть мировым экспертом в одной области; архитектор должен быть компетентен во многих. Классическая метафора — T-образный набор навыков: глубина хотя бы в одной технической дисциплине, но достаточная широта, чтобы убедительно говорить о других. Марк Ричардс и Нил Форд добавляют второе измерение: анти-паттерн «замороженного пещерного человека» описывает архитекторов, которые перестали расширять кругозор и теперь применяют десятилетние решения к современным задачам.
Архитектура — не одна дисциплина, а семейство взаимопересекающихся задач на разных масштабах. Два наиболее часто смешиваемых в индустрии типа — Solution Architecture и System Architecture (она же Software Architecture). Понимание разницы критично: каждый из них работает на своём уровне охвата, отвечает на разные вопросы и производит разные артефакты.
Эти два типа часто путают, хотя они отвечают на совершенно разные вопросы. Solution-архитектура спрашивает: «Какие системы, сервисы и вендоры мы объединяем, чтобы решить эту бизнес-задачу, и как они соединяются?» Системная архитектура спрашивает: «Как мы структурируем внутреннее устройство конкретной системы, чтобы она соответствовала функциональным и нефункциональным требованиям?» Solution-архитектор рисует карту; системный архитектор проектирует кварталы города.
Нил Форд, Ребекка Парсонс и Патрик Куа ввели концепцию «эволюционной архитектуры» — архитектуры, которая направляет изменения, а не противится им. В её основе лежит функция пригодности (fitness function): объективная функция, измеряющая, насколько текущая архитектура соответствует конкретной архитектурной характеристике. Такие функции могут быть автоматизированными тестами (проверка нежелательных зависимостей, верификация SLO времени отклика), ручными процессами (аудиты безопасности) или метрическими дашбордами. Ключевой вывод: архитектура — это не единоразовое проектирование, а непрерывное свойство системы, которое необходимо активно поддерживать и измерять.
Большинство архитекторов приходят из разработки — и переход сложнее, чем кажется. Навыки, сделавшие вас отличным разработчиком (глубокая техническая фокусировка, решение конкретных задач, поставка работающего кода), необходимы, но недостаточны для архитектуры. Переход требует развития новых «мышц»: системного мышления (как это решение повлияет на систему через десять шагов?), работы со стейкхолдерами (как согласовать людей с конкурирующими интересами?) и комфорта с неопределённостью (как принять правильное решение, не имея всей нужной информации?).