Дима Дзюба всем передает привет:

«В своем докладе на ArchDays 24 "Enterprise governance c доставкой в продукт" я рассказывал про инструменты AaaC, которые мы разрабатываем и применяем в Beeline. Я обещал, что мы начнем их выкладывать в Opensource. И вот, с некоторым опозданием, мы начали выкладывать наши инструменты. Первым выложили плагин к Visual Studio Code для работы с архитектурой в нотации Structurizr DSL https://github.com/tech-beeline »

Мы продолжаем набор спикеров на конференцию ArchDays!

Это первая в РФ конференция по архитектуре, получившая достаточно серьезное признание за 6 лет проведения.

Мы ждем интересные выступление по темам проектирования, корпоративной архитектуре, использовании AI, в том числе построении систем на их базе.

Уверен, компаниям участников этого чата есть чем поделиться.

Конференция пройдет 7 ноября в Москве, подаваться на сайте: http://archdays.ru

Если нужны пояснения, то можно написать мне в ЛС.

Сегодня опубликуем первые включенные в программу выступления

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

Почему именно сейчас?
Я скоро выпущу статью о проблемах, с которыми сталкиваемся не только мы в свете последнних событий, но и в целом мир, а именно – решения становятся сложнее, риски нарастают, технологии меняются, подходы к работе тоже меняются.

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

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

Подходов к построеию архитектурной функции достаточно много, есть три основных категории – централизованная, децентрализованная и гибридная/аутсорсинговая, в каждой из которых обширный выбор методов. И выбирать, конечно, нужно с умом, учитывая, что они еще и комбинируются и в своей структуре не должны стать противоречивыми.

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

Напишите свое мнение, либо опишите свою ситуацию, либо вопросы, либо критику, все, что покажется полезным.

А позже я сюда напишу еще, уже более конкретных вещей.

Спасибо,
Сергей Баранов

Рассказывая про атрибуты качества, я раньше приводил в пример страницу из Википедии, их тут перечисленно 92 штуки.

Иногда выводил из на один слайд, получается впечатляюще.

Но теперь я нашел ещё более ужасающую картинку.

Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).

Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.

Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.

Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/

Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.

Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.

Получится очень прагматично.

Сегодня состоаялся интересный диалог о стратегических и тактических аспектах в развитии продукта. Так как у нас канал архитектурный, давайте затронем тему стратегических и тактических аспектов в архитектуре.

Начнем с определений, чтобы задать контекст.
Стратегия - cовокупность долгосрочных целей и плана их достижения, охватывающая всю экосистему; формирует «что достичь» и «почему»
Тактика – комплекс краткосрочных мер и решений, обеспечивающих достижение стратегических целей; описывает «как реализовать»

Исходя из определений уже становится понятно, что баланс между стратегией и тактикой – это ложная дихотомия, так как тактика – это то, как достигаются стратегические цели.

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

То есть цели формируют стратегию, стратегия фиксируется через принципы, дорожные карты и портфель, а тактика ежедневно реализует стратегию через проектиные решения, контроль стандартов и оперативное управление данными и техдолгом (если упрощенно).

А если постоянно все реализуется на костылях, то это либо часть стратегии и осознанные действия, либо блуждание в темноте без четких ориентиров. Блуждаие в темноте тоже может быть эффективным, своего рода оппортунистическим, но вероятность этого настолько мала, что я бы не советовал так делать 🙂

Catalog of legacy modernization patterns by Nick Tune:
https://legacy-modernization.io/patterns/

"On Orchestrators: You Are All Right, But You Are All Wrong Too"
by Anuun Chinbat, Junior Software Engineer

Мне показался интересным это раздел статьи с ссылками:
The Fundamentals
- A Brief History of Workflow Orchestration by Prefect.
- What is Data Orchestration and why is it misunderstood? by Hugo Lu.
- The evolution of data orchestration: Part 1 - the past and present by Jonathan Neo.
- The evolution of data orchestration: Part 2 - the future by Jonathan Neo.
- Bash-Script vs. Stored Procedure vs. Traditional - ETL Tools vs. Python-Script by Simon Späti.

Курируемый список «The 2025 AI Engineer Reading List»

https://www.latent.space/p/2025-papers

В чате ассоциации идет достаточно бурно обсуждение фитнес-функций. Думаю, что как человек, который строил функции приспособленности в области генетических алгоритмов, а с другой стороны лично знаком с Патриком Куа (соавтором первой книги по Evolutionary Arch) и привозил его в РФ с выступлением на эту тему, а так же много лет применяю концепцию на практике, имею право высказать свое мнение с некоторым запросом на достоверность.

Функция приспособленности в генетических алгоритмах, если очень просто, – это математическая функция, оценивающая качества каждого индивида в популяции. Это по своей сути частный случай целевой функции, направляющей эволюцию в сторону оптимума. Можно сказать, что это математическое описание приспособленности из фразы «выживает самый приспособленный».

На практике это выглядит так, что есть некоторая функция, описывающая индивидуумов, а фитнес-функция оценивает каждого идивидуума, присваивая ему некоторое число, далее происходит селекция родителей для следующего поколения. Фактически - это направление поиска оптимума. В генетических алгоритмах это обычно миллиарды и триллионы индивидуумов. Еще одна важная особенность – фитнес-функция выступает и как критерий остановки алгоритма селекции.

Эти функции построить очень сложно, объективно сложно, особенно часто они страдают от невозможности различать решения различного качества.

Архитектурная же фитнес-функция – это механизм объективной оценки целостности некоторых арх характеристик. Фактически - аналог тестирования функциональных требований, только тут тестируем NFR. И вот тут начинается недопонимание. Цель арх. фитнес-функции – предотвратить деградацию архитектуры со временем. Тут практически не будет свойств оригинальной фитнес-функции, авторы взяли термин и от оригинального термина и придали другие свойства (защита ключевых хар-к, то есть защита от деградации и автономность команд, т.е. возможность принимать командам арх решения, оставаясь в рамках заданных ограничений), от оригинальных свойств осталась только объективная оценка движения архитектуры в нужном направлении.

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

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

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

Этого не будет, я заболел, голоса нет. На след неделю перенесем.

Суммирую свои мысли из чата асссоциации, чтобы не потерялось.

Есть много компаний, где ресурсов на архитектуру нет вообще (людей/компетенций/процессов). И нередко в таких компаниях архитектура душит бизнес. Просто на больших масштабах это не так заметно: системы живучие, инерционные. Но в средних и малых компаниях (даже с большой выручкой) это вылезает на первый план и бьёт по самым больным местам.

Почему? Всё просто: эффект от каждого решения в маленькой структуре ЗНАЧИТЕЛЬНО сильнее.
– Когда у тебя 200 разработчиков — кривые решения нивелируются массой. Просадка в производительности есть, но она растянута и не так смертельна.
– А когда две команды по 8 человек — тут уже любое архитектурное решение играет фундаментальную роль. Ошибка выбора стеков, неправильная декомпозиция сервисов или кривая БД бьёт сразу по всем процессам. Негде спрятаться.

И да, архитектурный стиль для системы, когда она одна и ключевая, — это совсем другая история, нежели когда она просто одна из 500 в огромной экосистеме.

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