Системный сдвиг

30 октября (чт) в 18:00 МСК проведём вебинар в формате ИТ-дебаттлов на тему «Продуктовый подход — философия или просто удобная методика?» Продолжаем серию профессиональных дискуссий о границах аналитического мышления и управленческих подходов в ИТ. В новом выпуске ИТ-дебаттлов, посвящённому сравнению системного и продуктового подхода к проектированию, встретятся два опытных практика, чтобы обсудить, во что превратился продуктовый подход — в новую философию управления или просто в удобную технику системного проектирования? В начале и в конце дискуссии зрители проголосуют, какая из позиций им ближе — и мы увидим, кто сумел переубедить аудиторию. ▫️План дискуссии: — Что на самом деле означает «продуктовый подход» сегодня? — Это новая философия управления или просто способ делать то же самое, но под другим названием? — Как сочетаются системный и продуктовый подходы? — Всегда ли продуктовый подход полезен — или иногда вреден? — Что происходит с ним в эпоху ИИ и «затягивания поясов»? ▫️Участники дискуссии Юрий Куприянов — системный архитектор, методолог, автор курсов по системному мышлению и визуальному моделированию, преподаватель школы Systems Education. Лучший докладчик конференций ЛАФ 2022 и Analyst Days 2023. Дмитрий Безуглый — консультант по управлению продуктами и цифровыми сервисами, эксперт в области продуктовой аналитики. Сертифицированный командный коуч CCE ICF, фасилитатор Pinpoint. Преподаватель ВШЭ, РАНХиГС, MBA Mail.Ru Group с 2007 года. 🎥 Мы выложим видеозапись в течение недели после проведения вебинара. Анонсируем в @se_webinars. Регистрация обязательна Вебинар @systems_education

Ну что, аналитики, настало ваше время! Самый модный способ разработки программ с помощью ИИ сейчас — SDD, spec-driven development. Человек пишет требования и спецификации, ИИ пишет по ним код. Программисты не нужны. Вот сейчас мы и посмотрим — насколько важная роль разработчика и что он вообще делает, и насколько точно аналитики могут формулировать требования и задачи. Идея похожа на подход "documentation first", знакомый нам по API. Как конкретно код написан — уже не очень важно, пока он соответствует спецификациям. И меняется в ходе проекта в первую очередь спецификация, она становится ключевым артефактом. А как все смеялись над российским подходом с обязательными аналитиками и постановками на каждом проекте! Инструменты SDD уже выкатил GitHub: Spec Kit, есть отдельные проекты — Tessl.io и Kiro. Недавно на сайте Мартина Фаулера вышла обзорная статья, кратко перескажу её здесь. Три основные идеи SDD: 1. Spec-first: сначала пишется (ну или генерируется) спецификация. Код генерируется только по этой спецификации. 2. Spec-anchored: спецификация сохраняется надолго. Если в дальнейшем понадобятся изменения — меняется спецификация, а не код. Изменения в коде следуют за изменениями в спецификации. 3. Spec-as-source: спецификация — главный артефакт, и только над ней работает человек. К коду человек не прикасается. Отдельно от самих спецификаций живет существующая кодовая база, принципы архитектурного разбиения, разнообразные правила именования и оформления кода и т.п. Работает примерно так: Kiro предлагает цепочку Requirements → Design → Tasks (Требования → Проект → Задачи). Требования записываются в виде юзер-сторей с критериями приемки в формате BDD-сценариев (Дано... Когда... Тогда...). Проект представляет собой описание устройства будущей системы: Архитектура: Компоненты архитектуры Потоки данных Компоненты и интерфейсы Модели данных и т.д. Задачи — это как в таск-трекере. Создай функцию такую-то, напиши набор тестов, добавь функцию фильтрации и т.п. Каждая задача имеет ссылку на требование. У Spec Kit всё примерно так же, но перед требованиями есть ещё общий документ "Constitution" (Конституция), это что-то вроде системного промпта, где перечислены главные правила, вроде "Никакого кода без заранее написанных юнит-тестов" и "Обязательная модульность: каждая фича реализуется как отдельно стоящая библиотека". В промптах используется очень много чеклистов для проверки каждого шага (правда, проверяет их сам же ИИ). Tessl пока выглядит, как база спецификаций для агентов, создающих других агентов. Там некая смесь задач и инструкций по генерации, это уже совсем близко к коду. Теперь о проблемах. В статье есть и описание попыток что-то сделать в логике SDD, и основной вывод — непонятно, для какого кейса применим этот подход. В туториалах, если они есть, показано создание небольшого проекта с нуля (greenfield). Но именно что небольших. При попытке исправить небольшой баг в существующем проекте (brownfield) быстро выяснилось, что нужно написать 4 разных юзер-стори и проверить 16 приемочных сценариев. Причем в одном из случаев ИИ неплохо разобрался с кодовой базой, но когда дошло дело до самостоятельного написания — принялся дублировать уже существующие классы... В общем, пока возникает множество вопросов. Удобнее ли проверять спеки, тест-кейсы и задачи, чем проверять код? В какой момент нужно переходить от проработки спецификации к написанию (или исправлению) кода? Какие вообще есть кейсы: написание системы с нуля, доработки, исправления багов, рефакторинг — и в каких случаях SDD оправдано, а когда скорее вредит? Поминается MDD, который так и не взлетел. А я думаю, вопросы-то совсем концептуальные — могут ли в принципе существовать спецификации отдельно от кода? Есть ли граница между проработкой требований и проектированием? Что составляет суть работы программиста, если спецификации и модели уже готовы? Кажется, тут есть что-то, чего мы не очень улавливаем, и всё время думаем, что это автоматическая перекладка требований в код. Возможно, глядя в зеркало ИИ, мы лучше поймем свою собственную деятельность.

Обнаружил у себя привычку анализировать различные сбои с точки зрения их возможного предотвращения системным аналитиком. Вот если бы на проекте был аналитик — смог бы он задуматься о возможном сбое? Вот и сейчас — смотрю на отчет по сбою амазоновского US-EAST-1, который уронил чуть ли не все сервисы (люди урок в Duolingo пройти не могли! Стрики свои многомесячные потеряли!) Ну и что, всё то же, что и в других случаях: гонки параллельной записи, непредсказуемый эффект ретраев, плохо выстроенные границы транзакций, отсутствие проверок пустых значений, зажатые таймауты. Темы интеграций, на самом деле. Но аналитики редко туда заглядывают. А тут ещё точка возникновения сбоя — план DNS, это в 99.9% случаев за пределами внимания аналитика. Технически там вот что произошло: в AWS есть база DynamoDB, в которой хранится много всего интересного (например, настройки других сервисов). Эта база очень широко распараллелена, поэтому нужно балансировать нагрузку, динамически масштабировать, отключать и подключать вылетевшие и восстановившиеся копии. Это делается через DNS, поэтому планы DNS меняются очень динамично. Но в какой-то момент одно из изменений зависло, пересеклось с другими транзакциями и ушло в ретраи. Пока оно пыталось отретраиться, планы успели поменяться уже несколько раз. А отдельный процесс после успешной смены конфигурации ходит по узлам и удаляет старые планы. И вот в зазоре между обновлением плана и запуском очистки наконец успешно сработал один из ретраев, и переписал все планы на старую версию. Процесс очистки обнаружил план старой версии, и тут же его удалил. В DNS не осталось записей. А так как актуального плана не было, не на чем было основывать новые версии, и план вообще перестал обновляться, застряв в пустом состоянии. Потом по цепочке всё начало валиться, в том числе перестали создаваться инстансы динамического масштабирования серверов EC2 — потому что даже после восстановления доступа к DynamoDB запросов на их создание скопилось столько, что их менеджер начал тормозить, и создание новых инстансов отваливалось по таймауту. Непонятно, могли ли тут заранее помочь аналитики. Мне кажется, не особо. Возможно, помогло бы моделирование сценариев, но вся архитектура скорее всего развивалась эволюционно, и на каждое небольшое изменение имитационный сценарий не будешь запускать. Это особенно касается гонок параллельных процессов с учетом ретраев, потому что в голове такое сложно уложить, все варианты не учтешь. Но вот удаление всех записей в базе (в DNS, в данном случае) — пожалуй, можно предотвратить. Пустые поля, удаленные записи — у Гугла же последний массовый сбой был тоже из-за отсутствия проверки на пустое значение. Тут, мне кажется, аналитик мог бы помочь. Я на тренинге упоминаю о статистических проверках данных: не просто вам пришло что-то, и ок, а проверьте — то, что пришло, оно вообще похоже на то, что вы ожидали? Возможно, обычно вам записей приходит около 10000, а тут пришло 100 — это нормально, или ошибка? Обычно суммы в договорах распределяются нормально, а тут вдруг 70% одинаковые — это нормально? Время выполнения домашних заданий у студентов тоже как-то распределено, а тут мы получили все с одним временем загрузки — подозрительно? Наш процесс собирается удалить все IP-адреса — правильно ли это? И так далее. Думать о таких вещах заранее — верх душноты. С другой стороны, достаточно один раз потерять все записи за день из-за сбоя в интеграционном слое — и будешь вставлять такие проверки на автомате. Отдельная тема — стратегия восстановления. Если у вас накопилось много сообщений или заданий в очередях, пока какой-то сервис лежал — как вы будете их накатывать? Если все сразу — это может превысить планируемую пиковую нагрузку, нужно как-то хитрее. А главное, это всё может возникнуть совершенно неожиданно в любой сколько-нибудь нагруженной интеграции. И как это всё учесть?

Самое интересное на Pimon, как мне показалось, было выступление Сергея Скирдина с обзором российских ESB, а точнее — критериев их оценки. Я послушал доклад, скачал обзор, прочел несколько постов Сергея на Хабре. Вот что мне показалось любопытным: Во-первых, в РФ вендоров ESB больше 40 штук! Это само по себе удивительно, потому что в Википедии всего 28 во всем мире перечислено, а на Capterra и того меньше — 19 (но там, как обычно, мусор какой-то). Если копнуть глубже, становится понятен такой разброс: российские "продукты" — это, в большинстве случаев, просто сборки open-source компонент, дополненные специфическими российскими адаптерами и прошедшие специфическую российскую сертификацию. Иногда там что-то свое дописано, иногда к сборке прилагается методика внедрения. Поэтому очень круто, что такие обзоры появляются — если вы собираетесь внедрять шину, а доступны только российские решения — хорошо бы в них разобраться, что там на самом деле внутри. Во-вторых, и это, на мой взгляд, недостаток — у нас нет эталонного набора функций для ESB. Этот термин вообще зыбкий — то ли корпоративная шина, то ли интеграционный фреймворк, то ли движок бизнес-процессов, то ли брокер сообщений — все по-разному называют. Как в анекдоте: почему иногда говорят "Будапешт", а иногда — "Бухарест"?.. Тут бы хотелось какую-то классификацию, ну или профили — как сборки типовых функций. Сергей, насколько я понял, выделяет следующие: 1. Набор типов коннекторов и возможности их конфигурации. Тут нужно раскрывать, что там внутри: правила, форматы, фильтры, протоколы. 2. Функции и возможности преобразования данных 3. Настройка маршрутизации и, как расширение, целых сценариев и бизнес-процессов 4. Проверки корректности данных и контрактов 5. Мониторинг и траблшутинг — тоже в широком смысле, от логов до механизмов гарантированной доставки и очередей ошибок 6. В принципе наличие очередей, их виды и назначение Пока это всё описано немного бессистемно, выхвачены какие-то отдельные фишки, описание функциональности перемешаны с описанием интерфейсов и нефункциональными требованиями, в общем, интересно, но винегрет. Я, как вы понимаете, люблю систематизацию, и в идеале хотел бы видеть какую-то таблицу с референсным набором функций и галочками. Ну или в графическом виде. Надеюсь, такая работа ведется (и готов участвовать, кстати). То же касается и НФТ: выцеплены отдельные характеристики, но хочется систематизации. В-третьих, из любопытного: в продуктах появляется ИИ. Обычно это почему-то LLama, а используется она для составления маршрутов и настройки преобразований, или для выявления нестандартного поведения и ошибок (вот это интересно!) Ну и про остальные критерии: понятно, что при примерно одинаковых функциях и примерно одинаковых показателях нагрузки и скорости отличия кроются в деталях, и нужен более детальный анализ. Но можно посмотреть на косвенные признаки: насколько компания давно на рынке, какая у неё история, насколько активно продукт развивается, есть ли специалисты по нему, и — очень мне понравилось — возвращает ли компания в open source свои разработки? Участвует ли в развитии проектов, на которых основывается? Выкладывает ли собственные инструменты? Вот это очень классный критерий. Ведь внутрь проприетарной системы не залезешь, а открытое ПО контролирует сообщество. К сожалению, как раз этот критерий в обзоре не раскрыт, а было бы очень интересно. С другой стороны, если анализировать продуктовую сторону такого обзора, возникают некоторые сомнения — кому и в какой момент он нужен? Шину выбирают не так часто, а меняют и того реже. И если так, то обзор должен стоить довольно дорого, и быть довольно детальным, с результатами пилотов и экспериментов, с рассмотрением типовых кейсов (это, кстати, раскрыто у Сергея в серии постов — некоторые решения он пилотировал). На западных рынках есть такой тип компаний: технологический брокер, или консультант по выбору ПО. Который только советует и выбирает, но не ведет сам проект внедрения (этим занимаются интеграторы). Интересно, есть ли у нас похожие сервисы, и готовы компании платить за такую услугу?

Я уже писал про митап Pimon 2025, посвященный ESB — очень классный, это фактически специализированная конференция про шины. И в комментариях спрашивали про записи. Я обещал написать, когда опубликуют записи. И вот они опубликованы: Интеграционные платформы: Панацея или лишний слой?», Антон Копылов, «Аксеникс» видео | презентация «ESB в России: тренды и перспективы. Результаты исследования», Александр Жиляев, Size Marketing видео | презентация «Российские платформы ESB: критерии выбора, практическое применение», Сергей Скирдин, «Белый Код» видео | презентация «Применение нейросети для трансформации сообщений в FESB», Олег Рубцов и Франклин Банкуе, «Неолант Тенакс» видео | презентация «Integration Gears: новый модуль Monitoring Center», Антон Курудинов, «ЛАБ СП» видео | презентация «Прототип инструмента для миграции с SAP PO на Integration Gears», Денис Бекишев, «ЛАБ СП» видео | презентация «JSON-first integration flows», Марат Бареев, BeringPro видео | презентация «Репликация в «Нормализаторе», Леонид Шумский и Александр Грищенко, «Т1» видео | презентация «Подсистема интеграции для 1С:Предприятия», Андрей Соколов и Сергей Сулимов, «Корус Консалтинг» видео | презентация Ну или все видео в одном плейлисте: https://youtube.com/playlist?list=PLHiGNvm26VdMoauuMRoSOxQV7tkq-7iie Надеюсь, в следующем году мероприятие будет ещё масштабнее!

Какие вы знаете методы приоритизации? Например, функций продукта или пользовательских историй? MoSCoW, RICE, модель Кано, value/effort, buy a feature, USM, Weighted Shortest Job First, что ещё бывает? В целом, это, конечно, многофакторный анализ — то, чему учат на предмете "Системный анализ" в институтах. Чтобы не учитывать много факторов — их схлопывают до 2-4. Но мне, честно говоря, и этого всегда было много и как-то сложно. Хочется чего-то более легковесного. Например, просто попарное сравнение функций. Из пары десятков сложно выбрать, но уже из двух-то можно сказать, какая выглядит более важной? И, может быть, даже без строгого анализа, чисто интуитивно. Ну или поставить на групповое обсуждение, тоже интересно. Вопрос — как перейти от попарного сравнению к упорядоченному списку. И такой метод есть — это рейтинговая система Эло (Elo rating system), которую используют в шахматах для оценки силы игроков. Идея довольно простая — все начинают с одинакового значения рейтинга, а после каждой "игры" (в нашем случае — выбора из двух) победитель получает прирост рейтинга с учетом рейтинга того, кого он победил. Почему-то не вижу статей про применение рейтингов Эло для приоритизации, зато есть инструмент, куда можно забить свой бэклог и прогнать приоритизацию https://elo.bytes.zone/ (кстати, там можно всё, что угодно, сравнивать, не только элементы бэклога). Я попробовал один список загнать, с которым мы группой часа два работали и чуть не переругались — получился ровно тот же результат, причем минут за 5-7. Попробуйте, очень интересно, что у вас получится?

Давайте легкую тему для пятницы. Как вы даете имена своим системам или их версиям? У меня с этим всегда были проблемы. Самая моя долгоживущая система долго вообще никак не называлась. Ей уже полгода пользовались, а названия не было. Пользователи её называли "считалка". Ну, такое. В итоге назвали её АСК: Автоматизированная система казначейства. Причем он оказался мужчиной: "Опять это вас АСК не работает!" А другую систему, для маржинальной торговли, тоже долго не называли, потом так и прижилось - Margin Trading. Ещё в одной системе были десятки сервисов с трехбуквенными аббревиатурами: PLP, PLE, XLE, LMS, LRS, FMS и т.д. Своим всё понятно, человек со стороны не разберется. Кому-то это легко дается легко — мой младший ребенок отлично придумывает названия: смастерил что-то из лего, и говорит — это Шушик! Смотришь — ну точно, вылитый Шушик, по-другому и не назовешь. Мне это дается мучительно. Если бы я давал какой-нибудь системе имя, поступил бы как Шарик из Простоквашино: написал бы первое пришедшее в голову, например "утюг". В одной компании версии систем называли именами озер: Байкал, Селигер, Сенеж. Стойкая ассоциация с чем-то военным. В другой компании — очень российской! — версии были по номерам, но сама система называлась почему-то по имени города в Калифорнии - Аламеда. В иностранном ПО любят кроме номеров версиям давать ещё и кодовые имена. У ОС Android это были разные сласти: мармелад, нуга, пирог, орео. У Microsoft - названия городов. У Apple - то примечательные места, то города, то кошки, то сорта яблок. У OpenEdX релизы именуются по видам деревьев, выбранных по первым буквам алфавита. Правда, они дошли уже до Ulmo (Эвкрифия сердцелистная) и Verawood (на русском вообще названия нет), не знаю, что дальше будут делать. Самые креативные названия версий у Ubuntu, есть даже целая страница: https://wiki.ubuntu.com/DevelopmentCodeNames, там у них всякие "Бдительные Бородавочники" и "Сметливые Селезни" (прилагательное + животное на одну букву). У Intel кодовые имена процессоров назывались по горам, рекам, озерам и городам вокруг мест, где расположены фабрики по производству. До сих пор помню фотку в офисе Бабаяна: "Команда Эльбруса покорила МакКинли" (гора на Аляске, кодовое имя одной из версий процессора Itanium). Фантазия разнообразна: кто-то использует имена героев фильмов, кто-то — названия химических элементов, женские имена, названия национальных парков, драгоценных камней, звезд и планет, и так далее. Хотя планеты у нас и сами названы по именам римских богов. А вот астрофизик Батыгин собирается назвать предсказанную им транснептуновую планету "Белая стрекоза любви". Почему нет. Я пытался найти какие-то исследования о воздействии именований релизов... на что-нибудь. Но не нашел. Попадаются только статьи про автоматическую генерацию описаний — release notes. Так что мы не знаем — приносит ли кодовое именование пользу, или это просто приятное развлечение. А как у вас принято именовать релизы? Номера, кодовые имена, какие-то правила их присвоения?

Системный сдвиг pinned «Я привез на Flow обновленную карту интеграций. Обновлений много: * Изменена структура: добавлены колонки "Семантика взаимодействия", "Стандарты", "Гарантии доставки" * Добавлена семантика для REST: ресурсный стиль (REST уровня 2) и гипермедиа стиль (HATEOAS…»

Завершая тему про конфликты. Аналитик, конечно же, тоже работает с конфликтами. Вообще, если вы не нашли ни одного конфликта в своем проекте — это очень тревожный сигнал, возможно, вы что-то упускаете. На днях мне попалась книга Патрика Ленсиони "5 пороков команды", и второй по счету порок — страх конфликтов (до него — отсутствие доверия, а за ним — безответственность, нетребовательность, безразличие к результатам. Ленсиони рисует пирамидку, и говорит, что один порок тянет за собой следующий). Так вот, про страх конфликтов. Тут Ленсиони говорит про скучные совещания. А скучные они ровно потому, что на них не вскрываются и не обсуждаются никакие конфликты. Если нет конфликта — такое совещание вообще не нужно. Это может быть запрос информации, или оповещение, в общем — это совещание должно быть письмом. А в настоящем совещании должна быть драматургия, конфликт! И если кажется, что его нет, то нужно поискать. По-английски он даже использует фразу conflict mining — добыча конфликтов. И это задача лидера — искать их, вытаскивать и обострять, не давать закапывать. Ну и задача аналитика тоже. И тут можно задать резонный вопрос: должен ли аналитик быть лидером? Или он должен только готовить материалы для принятия решений, а обеспечивать их принятие должна какая-то другая роль, от которой это лидерство ожидают? Тот же тех.лид, или архитектор — не видел архитекторов, которые не были бы лидерами и не могли бы принимать решения и добиваться принятия решений — тогда это не архитектор, а проектировщик. В этом смысле мне лично очень нравится роль фасилитатора или даже медиатора. Я (как аналитик) — внешний для вашего бизнеса и для ваших систем актор. Я не встаю ни на чью сторону, я не ангажирован. Я представляю интересы бизнеса (владельца, вообще говоря, CEO) и моя задача — обеспечить решение задачи наиболее эффективным способом. Это, конечно, относится к аналитикам, не аллоцированным по командам. Изнутри команды трудно позиционировать себя независимым невовлеченным экспертом. Но уж конфликты выкапывать нужно как можно раньше! Вопрос, конечно — как в вашей организации в целом принято обращаться с конфликтами — вытаскивать или замалчивать? И какие типовые способы решения применяются.

Посты про роль архитектора вызвали просто бурю обсуждений в комментах. Попробую ещё с одной стороны зайти. Любой объект можно рассматривать с разных точек зрения и через разную оптику. Это называется концептуальная рамка: через призму каких концепций мы смотрим на объект, что мы в нем выделяем? Вот деятельность архитектора — это что? У нас был спор в рамке "проектирование"—"не проектирование", и из-за неопределенности этого "не-проектирования" дискуссия дальше не пошла, каждый предлагал что-то своё. Рамка оказалась недоопределена. Предлагалось деление на проектирование и сбор материалов для проектирования. Но мне кажется (из опыта работы архитектором и опыта работы с архитекторами), что архитектор не обязательно проектирует. Продуктом архитектора часто является не сама архитектура системы, а решения относительно архитектуры. Причём часто это могут быть решения о том, чего мы не делаем. Или что мы делаем не в системе. В общем, мы можем рассмотреть деятельность архитектора через рамку принятия решений. А можем ещё сильнее заострить, и задать вопрос — когда требуется принятие решений? Мне кажется, принимать решение нужно, когда есть конфликт. То есть, мы можем посмотреть через рамку конфликта. Ещё точнее — конфликта, связанного с техническими и функциональными свойствами системы. И архитектор не столько проектирует, сколько решает конфликты. А решать их можно по-разному: сотрудничать, побеждать, искать компромисс, избегать, приспосабливаться, находить взаимовыгодные решения. У нас в книге, кстати, есть кусок про конфликты, т.к. мой соавтор защитил диссертацию про конфликты в ИТ-проектах. Технический долг возникает как раз из-за компромиссов и избегания решения конфликтов. ТРИЗ дает советы, как решить конфликт (противоречие) с улучшением всех аспектов и удовлетворением всех сторон. Гипотеза: архитектор в принципе нужен там, где есть много конфликтов (в технических системах) и их нужно решать.

На любой конференции важны не только доклады, но и кулуары. На Flow для этого есть специальный формат — дискуссионная зона, где можно ещё долго обсуждать доклад и связанные темы, иногда это обсуждение длится дольше, чем сам доклад, и даже превращается в мастер-класс. А для спикеров есть спикерский ужин. Это лучший нетворкинг, поэтому всех призываю подавать доклады, если вы хотите от конфы именно новых встреч и знакомств. А ещё можно узнать что-нибудь новое или осмыслить существующее. Я вот, например, в разговоре с Дмитрием Таболичем сформулировал важное понимание про роль архитектора. Обсуждали мы доклад Дениса Бескова про пошаговый алгоритм проектирования архитектуры систем. Ну или system design. Денис его перед конференцией показывал в чате архитекторов (RASA Chat) и у себя в канале. И вот среди архитекторов в чате разгорелось обсуждение, суть которого свелась к следующему (пересказываю своими словами): Задачи архитектора настолько разноплановы и разносторонни, что свести их к какой-то единой схеме, или, упаси б-г, алгоритму — совершенно не представляется возможным. Поэтому заниматься таким не нужно, и даже вредно. Всё, что делает архитектор — уникально. Любая систематизация — обман для профанов. Никакие стандарты, таксономии и алгоритмы не работают. Каждый проект уникален, и к каждому нужно подходить с особой стороны, а с какой — может знать только архитектор. Поэтому советы тут скорее навредят и направят не в том направлении. Поэтому и советов никаких никому давать нельзя. В лучшем случае их может давать один опытный архитектор другому опытному архитектору. А тот, естественно, их с негодованием будет отвергать, так как советчик не в курсе всей полноты и сложности ситуации, советует глупость, и вообще, судя по всему, архитектором не является. Из этого вытекает одно очень важное следствие: обучить архитектора невозможно. Так как всё меняется, один проект не похож на другой, в разное время приходится делать разное — то и определить, кто такой архитектор и чем он занимается, не представляется возможным. Значит, нельзя построить программу обучения архитекторов, это профанация. Чему бы на этой программе не учили — это будет однобокий взгляд и только часть правды. Всей же сложности, с которой архитектор сталкивается в работе передать нельзя, см. выше. Столь же бесперспективной и вредной является идея профессионального стандарта архитектора — это просто оксюморон. А тем более — попытка задавать требования к образованию или уровню квалификации. Но если научиться быть архитектором невозможно, то откуда тогда берутся архитекторы? И вот тут я словил инсайт: дело в том, что архитекторами просто становятся. Невозможно научиться, нужно стать им. Просто в какой-то момент ты понимаешь — да, я архитектор. Появляется такое внутреннее неоспоримое убеждение. После этого, конечно, тебе уже не нужны никакие подпорки в виде алгоритмов, стандартов или чего-то там, они даже смешны. Ведь ты — архитектор [Гарри], и всё, что ты делаешь — дело архитектора. И никто другой тебе не может сказать, что ты — не он. Да кто ты такой, чтобы мне говорить, кто я такой? Сам ты не архитектор. Косвенным признаком можно считать, когда архитекторы тебя признают в тусовке своим. Как лебедя из сказки Андерсена. Думаешь — пусть они меня заклюют, эти прекрасные птицы, ан нет, не клюют — прислушиваются даже и кивают. Вот, и это не про обучение. Разве гадкий утенок пытался научиться, как стать лебедем? Он просто был им. Так и архитектор — просто в какой-то момент им становишься, и всё, уже никто не сомневается. Это не про насмотренность, опыт или экспертность в программировании. Это про уверенность. У аналитиков, правда, с этим большие проблемы — видели в опросе, 54% испытывают синдром самозванца часто или всегда. Обращали внимание, как люди говорят о своей профессии? "Ну, я работаю кем-то вроде системного аналитика..." Ни один программист не скажет, что работает "кем-то вроде фронтендера", у них всё чётко. И архитектор не будет сомневаться. Так что нужно качать не столько знания, сколько уверенность в себе и самоопределение.

А вот и презентация с доклада про карту интеграций. Она отчасти повторяет карту, но в постраничном формате, и задает ту самую рамку для рассмотрения любой технологии. Через эту рамку я попробовал несколько технологий разложить: JSON-RPC: протокол Паттерн: удаленный вызов Режим взаимодействия: синхронный Семантика запроса: RPC Протокол: не зависит от протокола. Существующие реализации: HTTP, WebSockets, TCP Формат: текстовый, JSON, свой формат вызовов и ответов. Схемы нет. Ошибки: встроенные + кастомные (код+описание) Инструменты преобразования данных: встроенных нет Безопасность: встроенная в HTTP (SSL) Семантика доставки: at-most-once Язык спецификаций: OpenRPC (необязательный; есть генерация кода) Фишки: легковесный, пакетные запросы Проблемы: затруднен роутинг, кэширование, мониторинг, передача бинарных данных Кейсы применения: взаимодействие ИИ-агентов с системами и сервисами (MCP), крипта, отправка команд. Apache Thrift:язык описания данных и интерфейсов (IDL) + фреймворк кодогенерации Паттерн: удаленный вызов Режим взаимодействия: синхронный, асинхронный Семантика запроса: RPC Протокол: TCP-сокеты, файл, память, IPC-сокеты, HTTP Формат: бинарный, компактный, JSON. Схема: обязательна. Строгая типизация. Сложные структуры. Ошибки: специальный тип exception Инструменты преобразованияданных: нет Безопасность: TLS, SASL Семантика доставки: at-most-once Язык спецификаций: Thrift (обязателен, генерация кода обязательна) Фишки: вариативность форматов сериализации и транспортных протоколов Проблемы: плохая документация, поддерживаемые функции различаются в разных языках. Кейсы применения: Взаимодействие с разнотипными фронтами; сериализация данных без использования транспортных функций, в т.ч. в Kafka. И так можно любой способ интеграции расписать, даже совершенно новый для вас. (Upd.: В комментах есть в формате PDF, а то, говорят, в PPTX красивые шрифты побились :( )