На прошлой ArchDays я выступал с докладом, где приводил анализ вакансий и сравнивал с реальностью.
Промежуточный итог анализа вакансий архитекторов за этот год:
- Чем выше вилка зарплаты — тем размытее требования к специализации
- Чем ниже позиция — тем строже требования к формату (офис)
- Опыт работы в банке — универсальный скилл для архитектора в любой области (В вакансиях из совершенно других доменов (телеком, ритейл, госсектор) в требованиях часто пишут: «Опыт работы в банковской сфере будет преимуществом»)
- Архитектор — это новая HR-функция (В обязанности архитектора в вакансиях всё чаще включают пункты: «формирование команды», «менторство», «наставничество», «помощь в росте сотрудников». Его роль эволюционирует от чисто технической к роли технического лидера и наставника)

Важное про цифровизацию и AI от Натальи Касперской

Судя по тенденциям, общению, анализу, скоро появится потребность в навыке архитектурного устранения последствий vibe coding.

А проблема там усугубляется тем, что при обычной архитектурной диагностике есть носители контекста, а люди (с разной степенью) последовательны, даже если архитектура не очень «стройная».

А вот с вайб кодингом проблема оказалась в том, что носителя контекста как-бы нет, точнее контекст порой вообще не бьется с физическим воплощением и много странных заплаток, то есть пока непонятно, как-будто требуется полное проектирование с нуля (пока кейсов очень мало, но я не нашел других рабочих методов, пока не нашел), но с использованием хотя бы данных о реальном использовании пользователями и эксплуатации в проде.

Итак, выглядит так, что на текущий момент работа с нейросетями и архитектурой фундаментально не решается. LLM по своей природе стремятся не к строгой истинности, а к правдоподобной связности. Собственно, додумывание и искажение – фундаментальное свойство архитектуры. А решения достаточно дорогие на текущий момент, из того, что я пробовал или нашел:
1. Строгая онтология и терминология как каркасс. Тогда модель не генерит текст напрямую, а заполняет слоты в онтологической структуре. Но это дорого.
2. Использование RAG, но без жесткого schema enforcement все равно будут искажения, особенно на больших объемах
3. Хоть какой-то способ облегчить себе жизнь - использование строгих формальных языков и моделей, строгая грамматика помогает валидировать
4. Комбинация - строгий формальный язык + RAG + валидация другим агентом (валидация на соответствие с источником)

DSL+LLM на уровне структуры галлюцинации практически исключает (хотя и может в валидной с точки зрения грамматики модели не то не туда поместить), но смысловые концепции все равно додумывет.

Думаем, что с этим делать 🙂

Новые паттерны для создания GenAI-продуктов

Один из уважаемых мной старых дедов классической разработки программного обеспечения — Мартин Фаулер (автор книг "Рефакторинг", "Шаблоны корпоративных приложений", а еще соавтор Аджайл Манифеста и популяризатор кучи правильных вещей, за что ему низкий поклон), написал большую работу, где структурировал базовые новые паттерны разработки приложений на основе генеративного искусственного интеллекта

Читаю его труд и кайфую, как он приятно и наглядно излагает свои мысли. Очень советую всем, кто только начинает с разбираться с созданием приложений на GenAI:
1) Direct Prompting, как базовый слой приложения
2) Зачем нужен этап Evaluation
3) Что такое Embedding'и
4) RAG на дефолнтом векторном поиске
5) Hybrid Retriever для дополнения векторного поиском по подстроке
6) Query Rewriting для улучшения запросов от человека
7) Reranking для отсечения мусора в результатах поиска
8) Guardrails для безопасности — валидация инпута, верификация аутпута
9) Fine Tuning, для крайних случаев, когда остальные не дают роста eval-метрик

А еще, как же он прав:

LLM — это такой джун-исследователь: начитан, умеет красиво излагать, но в деталях плавает, а самоуверенности хоть отбавляй — вместо «не знаю» предпочитает с умным видом выдумать что-то правдоподобное. RAG в этой картине — это когда мы задаём этому джуну вопрос и при этом подсовываем ему папку с нужными документами, строго намекая: «Прочитай это, прежде чем снова начать фантазировать».

https://martinfowler.com/articles/gen-ai-patterns/

П.С. А дальше, поверх этих паттернов нужно делать когнитивную архитектуру, с планировщиками, постановщиками задач, сервисами вызова тулинга и рефлексией, но это — уже другая история)

У нас тут старт через 3 минуты =)

Предложите надежные альтернативы Контур.Толку, пожалуйста.

Уже второй вебинар фейлится, проблемы не решаются.

Основных проблем две:
1. По сути не работает шаринг экрана. Прекращается в случайный момент, когда находишься в полном экране, не узнаешь об этом и в итоге говоришь без картинки.
2. При шаринге даже по проводу, с хорошим каналом, видео переходит в пошаговый режим.

В альтернативном варианте должна быть возможность деления по комнатам.

Это критические для меня проблемы.

Я уже прям расстроился, никак не могу найти российский надежный аналог зума, а в условиях, когда много удаленки - это суперважно.

Я запишу этот вебинар отдельно и выложу в записи везде, где анонсировали, а для обсуждения вопросов этого и может предыдущих вебинаров сделаем отдельную встречу.

Заодно дополню контентом.

Давно в блоге не писал ничего, по следам реальных кейсов.

Статья раскрывает ключевые принципы и технические подходы к независимому развертыванию IT-решений в разных странах с учетом локальных особенностей, экономических факторов и необходимости стандартизации, помогая читателю оценить преимущества и ограничения такого процесса.

http://agilemindset.ru/независимое-развертывание-в-междуна/

ArchiMate переходит на NEXT: что важно знать

В новой версии спецификации ArchiMate происходит значимый сдвиг в сторону унификации и упрощения метамодели.

Главное — переход от традиционного разделения на “слои” (Business, Application, Technology) к доменам, включая Strategy, Motivation и Implementation and Migration.

Новая модульная структура обеспечивает гибкость, сохраняя ключевые аспекты (Behavior, Active Structure, Passive Structure, Motivation) и позволяет использовать элементы кросс-доменно, без строгой иерархии.

Ранее различавшиеся поведенческие элементы — такие как Business Process, Application Function и Technology Process — теперь объединены в четыре универсальные категории Common Domain: process, function, service и event. Это устраняет избыточность и упрощает моделирование.

Из языка исключены элементы, дублирующие базовые сущности: contract, constraint, gap, representation, implementation event, а также все виды interaction. Их заменяют специализированные формы, такие как requirement, business object, assessment, data object, artifact, material, event.

В целом ArchiMate NEXT делает язык компактнее, чище и лучше приспособленным к автоматизации.

Еще один обзор изменений Archimate Next:
https://habr.com/ru/posts/932602/

Кому интересен Even Storming, я тут снова начал активно писать, уже два поста из серии вышло.

Решил попробовать формат серий постов, чтобы тематики были не такими разрозненными, привнести больше целенаправленности.
Первая серия, которую хочу сделать – «Темные стороны Event Storming»

Дело в том, что иногда складывается ощущение, что про event storming уже все написано и все ошибки давно разобраны, на самом же деле настоящая практика всегда чуть сложнее и чуть глубже, чем кажется из описаний сессий. Я немного порефлексировал и собрал самые сложные и неочевидные истории, встречающиеся регулярно. Некоторым из участников этого канала я их уже рассказывал лично, а кто-то, может быть, узнает свою сессию.

Расскажу и про тишину экспертов и про иллюзию консенсуса и про колоритные примеры, которые уводят обсуждения в сторону. Пока набралось семь тем, а там посмотрим. Цель простая – дать честный срез как бывает, зачем это видеть и что с этим делать. Смысл в том, что ошибки, которые повторяет каждая группа, очень похожи, а опыт приходится нарабатывать каждый раз свой.

Как этим пользоваться – выбор каждого, кто-то прокачает свой скилл, кто-то обратиться за проведением сессии, понимая, что может не потянуть, тут каждый решает сам, но уж совершенно точно наиболее рациональным будет поделиться, а не замыкать в себе.

Сегодня выйдет первый пост на тему «Ложное согласование понятий»

Прекрасный тред
«Lead Architect wants to break our monolith into 47 microservices in 6 months, is this insane?»
https://www.reddit.com/r/softwarearchitecture/comments/1o6re10/lead_architect_wants_to_break_our_monolith_into/

Недавно Саша Лучков написал в чате отличное сообщение о разнице в оценке типовых и исследовательских задач. Это навело меня на мысль, что материалы, что встречались, обычно прямолинейные - бери вот такую технику и оценивай любую задачу (что, очевидо не так) и я решил подготовить обобщенный, но практичный материал на эту тему, прошу к ознакомлению:

http://agilemindset.ru/item-estimation/

А Саше спасибо за ревью статьи 🙂

Всем привет!

Немного о том, как развивалась конференция, – уже можно отследить некоторые тренды на основе всех поданных на конференцию выступлений за все годы 🧐

▪️2019 – год, когда инженеры снова поверили в архитектуру. Тогда всем хотелось строить красиво – микросервисы, доменные модели, API как кирпичики конструктора. В воздухе витала энергия ремесла: делаем хорошо, честно, не потому что «тренд», а потому что так правильно. Было ощущение, что архитектура – это не про власть, а про ответственность за форму (микросервисы же 🙂 ).

▪️2020 стал моментом взросления. Устав от энтузиазма, люди начали понимать, что дисциплина важнее подхода. Говорили про платформы, про то, как разные команды могут работать синхронно, когда система одна, а люди разные. Возникла боль роста – не техническая, а организационная. Архитектура начала становиться зеркалом того, как устроена компания.

▪️В 2021-м на сцене прозвучала новая тема – осознанность архитектора. Все меньше вдохновляющих слайдов про паттерны, все больше разговоров про то, как строить архитектуру не только систем, но и отношений. Люди стали говорить про культуру, доверие, совместное мышление. Про то, что архитектор теперь не «над», но и «рядом».

▪️2022-й принес ощущение, что мир стал облачным, а риски – земными. Архитектура вернулась к инженерии, но уже зрелой. Разговоры про DevSecOps, автоматизацию, платформы звучали не ради моды, а ради устойчивости. Архитекторы начали учиться говорить с безопасностью и бизнесом на одном языке. И это был заметный сдвиг – от контроля к сотрудничеству.

▪️2023-й – время данных и осмысленности. Архитектура перестала быть абстракцией. Мы начали видеть, что у каждого решения есть вес, который отражается в цифрах. Data Mesh, Capability Maps, все это было не про технологии, а про прозрачность. Про умение смотреть на компанию как на живую систему, где архитектура – это нервная система, а не скелет.

▪️2024-й стал годом зрелых архитекторов. Люди вышли за рамки IT. Мир корпоративной архитектуры показал, что можно управлять изменениями не через власть, а через осознанные горизонтальные и вертикальные связи. Появились школы архитекторов, сообщества, события про людей, а не про фреймворки. Архитектура стала более человечной.

▪️И вот 2025-й. Искусственный интеллект не разрушил архитектуру – он ее расширил. Теперь речь идет не только о проектировании систем, а о том, как они учатся вместе с нами. Архитектура стала способом мышления, где AI помогает видеть связи, которые раньше были скрыты. Это уже не каркас и не схема, это среда для развития – и людей, и бизнеса, и идей. При этом идеи корпоративной архитектуры и технические навыки никуда не делись, однако они все больше переплетаются со смежными областями.

Предвосхищаю много кулуарных, противоречивых разговоров о применении AI в проектировании. А там есть что обсудить.

С Уважением,
Сергей Баранов

Интересная статья какая, про влияние вирусного контента на мозги LLM.

https://www.arxiv.org/pdf/2510.13928