Архитектура как код
Следующая большая вещь (next big thing) в ИТ-архитектуре, безусловно, заключается во встраивании создания и тестирования архитектурных артефактов (описаний, моделей и пр.) в CI/CD pipeline. Идея эта не особо оригинальная. В интернет можно найти множество материалов с заголовком непрерывная архитектура (Continuous Architecture) или Architecture as a Code но в большинстве из них речь идет о чем-то другом (например тут). Пожалуй, только у Саймона Брауна звучит эта тема (Software architecture as code ), но в большей степени фоном для C4model. Одним словом, архитекторы по-прежнему полагают, что кто-то будет им рисовать и обновлять архитектурные описания повинуясь зову сердца и чувству долга. Наверное, так же в свое время думали тестировщики, пока не заставили разработчиков писать и прогонять unit-тесты или технические писатели, не настаивающие на использовании инструментов типа Javadoc или GoDoc.
The Go project takes documentation seriously. Documentation is a huge part of making software accessible and maintainable. Of course it must be well-written and accurate, but it also must be easy to write and to maintain. Ideally, it should be coupled to the code itself so the documentation evolves along with the code. The easier it is for programmers to produce good documentation, the better for everyone.
ИТ-архитекторы же продолжают сидеть в своих башнях из слоновой кости, подобно Винни-Пухам, застрявшим после сытного перекуса в домике Кролика. Даже тег DevArchOps остается неизвестен гуглу и воспринимаемся им как бессмысленный набор символов.
Архитектор решений (solution architect) мне возразит: «Кому интересны все эти классы, пакеты, процедуры и модули? Если уж что и описывать, то сервисы (процессы) и сетевые взаимодействия». Так средств визуализации развертывания – придумано невероятное количество. Например, здесь https://hub.docker.com/r/pmsipilot/docker-compose-viz/ или здесь https://github.com/spekt8/spekt8 и все прочие dvizz-ы, kvizz-ы и sonargraph-ы). Кроме того, насколько мне известно, символ ( # ) в yaml пока никто не запрещал.
Что делать, если интересные с точки зрения архитектуры артефакты создаются, обсуждаются и модифицируются вне всяких конвейеров непрерывной доставки и интеграции? Ответ на этот вопрос придумали специалисты по электронному документообороту лет 40-50 назад, заставив авторов, при регистрации документа в системе электронного документооборота, заполнять специальную форму – карточку документа. Даже специальную историю придумали о том, что разбором документов в скором будущем займется искусственный интеллект. Пока же этого не случилось, искусственный интеллект должен пару лет подучиться, в порядке исключения карточку документа надо заполнять пользователям. Пользователи поверили и на протяжении десятилетий сопровождают контент структурированной информацией.