Следующая большая вещь (next big thing) в ИТ-архитектуре, безусловно, заключается во встраивании создания и тестирования архитектурных артефактов (описаний, моделей и пр.) в CI/CD pipeline. Идея эта не особо оригинальная. В интернет можно найти множество материалов с заголовком непрерывная архитектура (Continuous Architecture) или Architecture as a Code но в большинстве из них речь идет о чем-то другом (см., например: https://pgppgp.wordpress.com/). Пожалуй, только у Саймона Брауна звучит эта тема (см. 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 назад, заставив авторов, при регистрации документа в системе электронного документооборота, заполнять специальную форму – карточку документа. Даже специальную историю придумали о том, что разбором документов в скором будущем займется искусственный интеллект. Пока же этого не случилось, искусственный интеллект должен пару лет подучиться, в порядке исключения карточку документа надо заполнять пользователям. Пользователи поверили и на протяжении десятилетий сопровождают контент структурированной информацией.
В общем, предлагаю пообсуждать эту тему, ведь сегодняшняя потребность организаций в ИТ-архитекторах такова, что всем их всё равно не хватит
Это чисто взгляд из DevOps (они видят только код). На самом деле, речь идет о машинно-исполняемых цифровых моделях для создания программируемого (software-defined) предприятия. https://bpm.com/blogs/executable-architecture-of-software-defined-enterprises
Что такое машинно-исполняемые цифровые модели я не знаю, врать не стану. Но как текст из комментариев в документацию попадает и по файлам конфигурации картинки рисуются видел своими глазами
машинно-исполняемые цифровые модели – ну например, исполняемые процессы, правила и т.д.
Более того, будущее уже потихоньку наступает – вот proof of concept Scala DSL для Archimate https://github.com/smeagol74/semod
Чем заниается архитектор?
Рисует кружочки, прямоугольнички и стрелочки.
Я понимаю, что для коммуникации все эти диаграмы нужны, но если из картинок они превратятся в код, который генерирует саму архитектуру и диаграмы – это будет следующий ход.
“Чем заниается архитектор? Рисует кружочки, прямоугольнички и стрелочки.” ‘ Прогресс! раньше были только прямоугольнички и стрелочки. Эти рисунки уже исполняемые модели (пример – процессы). Они суть 1) часть описания архитектуры системы и 2), иногда, часть системы.
Я не приуменьшаю роль работы архитектора, но я согласен с Максимом в том, что Next Big Thing будет исполняемая архитектура.
Наверное, я не очень четко написал. Нам бы научиться создавать архитектурные описания вместе с кодом, в процессе сборки и развертывания, встроить эту деятельность в pipeline. Причем сделать это неблокирующим, неинвазивным способом. Такая идея была когда-то сформулирована в CRM системах: след взаимодействия с клиентом(интеракция) должен формироваться максимально прозрачно и незаметно для осуществляющих это взаимодействие сотрудников
Спасибо, Максим, за заметку. Подскажите, сейчас, спустя 3 года, есть процессы/инструменты реализующие это?
Я чего-то внятного пока не видел. К сожалению
Пилотируем https://github.com/RabotaRu/DocHub, но похвастаться пока не чем
Ждём результатов