Комментарии 6
Если строить architecture-as-code через управление документами, то особой пользы не будет. Да и какая бизнес цель у этого процесса?
На мой взгляд, подход архитектура как код должен решать задачи повышения прозрачности (observability) и удешевления верификации архитектуры. Убедиться что архитектура соответствует реализации очень сложно. И строить административные процессы управления изменениями вокруг этого задача малоперспективная и сильно замедлит скорость разработки.
В современных развитых микросервисных платформах архитектура уже де-факто описывается как код на декларативном языке. Описываются объекты (микросервисы), их зависимости (потоки данных), SLA (RPS), ответственности (code ownership) и др. Соотвественно можно настроить эффективный процесс ревью на такие спецификации с участием нужных ролей в организации.
Соответственно можно построить модель системы (в виде диаграмм и документов) и есть возможность дешево реализовать средства гарантирующие что она верна (как правило разрешения в сетевых экранах настраиваются по этой же модели или используются исторические данные по сетевому трафику для подтверждения). Достигается прозрачность системы и ее архитектуры в реальном времени.
Таким образом можно ускорить аудит системы и ее сертификацию (всегда есть корректная HLA модель), автоматизировать проверки, повысить продуктивность команды которая отвечает за эксплуатацию и SLA.
Собственно я про то, что "декларативный язык" или какой другой язык, но именно не просто картинки, как раз и формирует "документ". С помощью которого мы можем и описывать, и управлять архитектурой. Я как раз не понимаю других возможностей. Есть "картинка" - диаграмма в Visio, draw.io или еще чего. Но это только картинка. Есть желание хотя бы формировать ее на основе данных. И есть понимание - что этого недостаточно, что бы говорить "мы управляем архитектурой". А что "достаточно" - попытался изложить в заметке.
Очень спорные они, Ваши тезисы. Вы их на практике пробовали обкатывать/проверять?
Очень упрощённая у Вас картина мира и задачи представляются надуманными.
К сожалению, в отличие от машиностроения или той же строительной области в ИТ практически пропала культура проектирования. UML забыт начисто. Отсюда и разговоры про документы, а не про модели.
Со спорностью, а главное - упрощенностью - согласен. Именно упрощенно. И потому - тезисы. Это как раз начало попытки разобраться. Если кто-то даст на эти тезисы более НЕ упрощенный ответ - будет здорово.
Ну и по поводу "документ" - "модель". Здесь "документ" скорее технический термин. А документами технически могут описываться и модели. Даже - должны. Но что это такое "модели", и как их "пощупать" - вот вопрос.
Что касается модели. Ничего лучше UML до сих пор придумано не было, на мой взгляд. И это хорошо функционирует. Правда, при больших затратах на первоначальное обучение команды или отбор в неё уже обученных специалистов. Я это пережил сам.
К сожалению, потом пришёл агильный подход с его коллективной безответственностью и решением мировых проблем методом голосования.
Под документом я понимаю способ показа модели или вытекающих из неё требований человеку или автомату (генератору). В принципе - прямая аналогия с машиностроением или электротехникой, где есть электронные модели или по крайней мере наборы согласованных, строго формализованных чертежей на бумаге.
Такой подход действительно хорошо работал.
Мои соображения на эту тему я опубликовал в статье:
https://habr.com/ru/post/425321/
Эту темы мы пытаемся обсуждать в Телеграмм-группе https://t.me/rpseru, к сожалению, последнее время мы много отвлекались от темы.
Просмотрел Вашу статью. Не сказал бы что идея нова, но в общем с ней согласен.
Мой подход немного о другом. О том как АВТОМАТИЗИРОВАТЬ процесс управления архитектурой. "модель" в этом смысле - что то как раз нематериальное, пока мы не материализуем ее хотя бы в виде документа или диаграммы. Пусть UML или C4 или BPM или чего еще. То что Вы называете "модель" я скорее называю "методикой".
И после того, как мы "вынули" модель "из головы" - что и как с ней делать? Как ее оценить, как реализовать "в железе" или ИТ, или бизнеса. И даже не про саму реализацию, а про управление процессом реализации. Вот я о чем.
Публикации
Управление архитектурой как кодом (январские тезисы)