ArchiMate убрать нельзя оставить

Наконец-то я добрался до просмотра обзорного вебинара про ArchiMate. Пять спикеров по 15 минут делятся опытом использования ArchiMate, рассказывают чем они рисуют прямоугольники и стрелки.

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

Итак, тезисно, что я для себя вынес. Что-то из этого было сказано явно, что-то является моими личными умозаключениями.

Компания должна культурно и всецело дорасти до инструментов, только тогда эти инструменты принесут желаемый эффект. Очень тяжело принести инструмент в компанию и пытаться таким образом поднять культуру компании. В последнем случае есть риск, что вы окажитесь в роли Моисея, который так и не вывел людей из пустыни.
ArchiMate — это не догма, а стандартизированный графический язык моделирования. Он очень проработанный, зрелый, но с высоким порогом для входа. Если вы до сих пор эффективно решаете свои задачи без ArchiMate, не переживайте, вы всё делаете правильно.
Адаптируйте инструменты под себя, свою культуру и потребности. Никто не обязывает пользоваться всем спектром функциональных возможностей или педантично следовать стандартам или рекомендациям. Не вы должны работать на них, а они на вас.
В большинстве компаний нет явно выделенного архитектора, поэтому многим хватает моделей в стиле C4 Model и сопутствующих инструментов типа PlantUML, Structurizr, LikeC4. Про LikeC4 я услышал впервые, но он стал моим фаворитом, поэтому рекомендую!
Все хотят web-based-решение, т.к. это существенно упрощает коммуникацию. Картинки устаревают сразу после их отправки, а диаграмма по ссылке всегда актуальна и для ее просмотра не требуются предустановки. Также web-based-решения концентрируют все знания об архитектуре в одном месте и позволяют возможность создания интерактивных диаграмм.
Продолжаю наблюдать повышенный интерес к теме AaC и связанные с ним вопросы: автогенерация архитектурных диаграмм, дезайн-ревью, автотестирование архитектуры. Многие начинают с автогенерации с использованием трэйсинга, анализа кода или deployment-файлов. Подробнее об этом см. по ссылкам 1, 2, 3.
Был наброс, что behavior-диаграммы не нужны, они очень быстро устаревают, а поддерживать их в актуальном состоянии очень сложно и дорого. Например, Sequence Diagram. Доля правды в этом есть, но с точки зрения разработчика именно behavior-диаграммы позволяют быстрей разобраться, что происходит, т.к. по одним статическим моделям о многих вещах можно лишь догадываться.

Близится День программиста и достаточно насыщенные выходные. Я собираюсь принять очное участие в E-CODE 2025. Если кто-то будет там же, пишите, встретимся. ;)

А для остальных у меня есть ссылка на еще одно крутое событие — онлайн-конференция HighLoad++ Genesis, которая пройдет 13 сентября! Мероприятие бесплатное.

Понравилась статья?