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

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

Ну а дальше меня лично (или виртуально) можно будет увидеть на курсах Systems.Education:

25-27 сентября: «Системный анализ + ИИ. Разработка требований и функциональное проектирование систем». Это наш классический курс для систематизации знаний в системном анализе, где мы даем четкую последовательность действий и артефактов. Но сейчас — с помощью ИИ, когда мы можем ускорить анализ (например, выявление бизнес-сущностей из текстов), формирование текстов и диаграмм, и кросс-проверки. В общем, классика на новом уровне в формате интенсивного погружения за 3 дня. Курс-боевик. В очном формате, кстати, довольно редко проводится.

А с 29 сентября начинаем экспериментальный онлайн-курс «Микросервисы для системных аналитиков». Без программирования и DevOps, ровно то, что нужно аналитикам. По-сути, это введение в архитектуру: там будет Event Storming, построение архитектурных диаграмм C4 до уровня компонент, практика составления записей архитектурных решений ADR, расчет нагрузки, ну и проектирование интеграций, но уже применительно к микросервисам: основные паттерны, сценарии взаимодействия, описание контрактов в OpenAPI и AsyncAPI (для Rabbit и Kafka). Это будет онлайн по три часа с утра.

Ну и 3-4 октября — Flow в Санкт-Петербурге. Там буду делать доклад про логику построения карты интеграций, а точнее даже — про морфологию интеграций: что во всех технологиях в любом случае есть, о чем нужно задуматься и как разные технологии между собой сравнивать.

Про InBetween 2025.

Ещё одна экспериментальная джуговская конференция. Про задачи связи стратегии и тактики.

Очень бодрое начало, но к концу как будто не хватило заряда. А в первой половине доклады были прямо огненные!

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

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

Впрочем, в рассказе была и новая перспектива: как, собственно, запускать этот авральный режим, когда всё застыло. Ответ — через параллельные управленческие структуры. Про то же говорится и в курсе "История бюрократии", кстати — на примере разных стран и эпох. Ну и сам я, если задуматься, довольно часто работал именно в параллельных структурах, выключенных из устоявшейся системы. Знание, которому не учат в бизнес-школах (ну или мне так не повезло, напишите, если кого-то учили такому).

Следующий отличный доклад Ильи Балахнина про стратегические сессии. Доклад вокруг одного слайда — куда только ПК смотрит?! 😂
Много полезных советов про проектирование и ведение стратсессий, я раньше их вел иногда, так что отзывается. Из интересных тезисов:

* не жалейте времени на выяснение главного вопроса. Ну иначе результаты будут бесполезны. А в чем главный вопрос (а не острый симптом, например) — это нужно выяснять.

* используйте при анализе принцип деления MECE (Mutually Exclusive, Collectively Exhaustive) — так, чтобы предметы и признаки, которые вы делите, не попадали одновременно в разные категории (Mutually Exclusive), и покрывали все возможные варианты (Collectively Exhaustive). Нарушение этого принципа мы достаточно часто наблюдаем — когда часть вариантов пересекается, и из этого пересечения выстраиваются обобщения то в одну, то в другую сторону.

* применяйте разные методы анализа проблемы:
** структурный (раскладываем проблему на части, смотрим, из чего она состоит)
** хронологический (раскладываем по времени / последовательности / сезонности, смотрим — что было до, что будет после)
** причинно-следственный (раскладываем по логике: что из чего вытекает, что на что влияет. Дерево текущей реальности Голдратта, Impact Mapping)
** иерархический (раскладываем по важности — что тут самое главное, а что второстепенное, что во что вложено)

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

* не стройте дорожную карту сразу на сессии. Определите направления, фокус, а план пусть потом специально обученные люди строят в спокойной обстановке.

* фиксируйте зоны ответственности по RASCI: кто выполняет задачу (R), кто отвечает за то, чтобы задача была выполнена с должным уровнем качества (A), кто помогает (S), кто консультирует (C), кто должен быть в курсе (I). Тут мы потом немного поговорили про DACI: Driver, Approver, Contributor, Informed. Но supported и consulted тоже интересные роли, можно и так.

Вот эти доклады мне очень запомнились. Остальные были уже не такими насыщенными, но я не все смотрел. Интересная мысль была у Алексея Кирпичникова из Контура: при руководстве 80 продуктами и ~2,5 тыс. человек ты, как руководитель, вообще не можешь ни кем конкретно руководить, вот такой парадокс. Ты можешь только устанавливать правила и политики, задавать стандарты и контролировать их внедрение / соблюдение. Тоже, кстати, было в курсе про бюрократию — многие великие правители государств именно с этого начинали — со свода законов и конфигурации управленческих структур. А всё остальное уже потом "само" получается, если правильно организовано.

Про протоколы приколы интеграции.

Сижу, готовлю презу к Flow. Подходит сын, садится рядом и внимательно изучает, что я рисую. Потом говорит: "Ааа! Протоколы интеграции! А я думал — приколы интеграции!"

Ну, поговорили о приколах. Навскидку, вспомнил такие приколы:

* SOAP, один из самых сложных по структуре протоколов, расшифровывается как Simple Object Access Protocol. Простой он по сравнению с такими монстрами, как CORBA.

* MQTT, несмотря на буквы MQ в названии (обычно означающие Message Queue), вообще не содержит очередей.

* YAML не является языком разметки, его теперь так и расшифровывают: YAML Ain't Markup Language.

* Основной принцип REST — управление через гипермедиа, HATEOAS. Но этому принципу почти никто следует в реальных REST API.

* REST API (HTTP-запросы) считается синхронным, но в реальных программах почти всегда HTTP-запросы выполняются асинхронно.

* Брокеры типа Kafka и RabbitMQ считаются (и являются!) асинхронными, но скорость обмена (latency или round trip) в них может быть в разы меньше, чем в "синхронных" HTTP-запросах.

* FlatBuffers, несмотря на своё название (flat=плоский), может хранить и вложенные объекты (через опцию nested_flatbuffers).

* Продукты RabbitMQ и Kafka часто рассматривают, как альтернативы, но они принципиально отличаются: RabbitMQ — это брокер сообщений с очередями без записи на диск, а Kafka — распределенный журнал с высоконадежным хранением, но без маршрутизации и очередей. Впрочем, в последнее время в Kafka появились очереди (в каком-то виде), а в RabbitMQ — персистентные сообщения и журналы (в каком-то виде). Напоминает сказку Киплинга про ежа и черепаху, которые друг друга учили плавать и сворачиваться в клубок.

* Несмотря на наличие "семантики доставки" exactly-once в Kafka, на самом деле доставка консьюмеру тут вообще никак не контролируется, это только про однократную и без потерь запись в журнал.

Это те, что я вспомнил минут за пять. Какие у нас ещё есть приколы в области интеграции?

Один из принципов контроля качества обучения, я считаю — открытые защиты. Да и в принципе открытость. Если у школы/университета всё внутри, всё только для своих — это вызывает некоторое подозрение. Либо они так пытаются торговать своей закрытостью и эксклюзивностью, либо что-то скрывают 🤔

Когда я ещё работал в вузе (МИЭМ), у нас были открытые защиты с 2007 года — кажется первые в стране.

В конце концов, ваш результат — не оглавление программы и не презентации, а изменение в умениях и понимании выпускников. Ну и покажите товар лицом. Systems.Education вот регулярно устраивает публичные защиты.

Завершается летний поток трёхмесячного интенсивного курса Systems Analyst Bootcamp, и мы приглашаем Вас посетить финальное демо.

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

С полной программой курса можно ознакомиться по ссылке.
Порядок проведения демо - по ссылке.

🔹Как принять участие
Финальное демо пройдёт в онлайн-формате в 2х частях:
- в среду, 24 сентября, с 18:00 до 20:00 (мск)
- в четверг, 25 сентября, с 18:00 до 21:00 (мск).

Чтобы попасть на него, напишите нашему администратору Елене Гриценко: @elgritsenko. После подтверждения участия вам вышлют ссылку на онлайн-встречу.

Будем рады вашему присутствию!

Когда я работал программистом, потом аналитиком (или кем-то вроде того), меня постоянно раздражало, что задачу выбираю не я. Тебе почти всегда кто-то говорит, что делать. Вот, мол, есть такая задача — бери и делай. Выявляй требования, пиши код.

Поэтому я целенаправленно в какой-то момент стал стремиться к ролям, на которых сам бы мог определять, что делать. Называлось это по-разному: руководитель бизнес-практики, директор по развитию, директор по продуктам. Когда ты работаешь в небольшой компании, можешь сам себе придумывать название должности (впрочем, в больших компаниях тоже иногда можно). Я как раз бросил компанию из группы ММВБ и ушел делать стартап, а получилась R&D компания с несколькими продуктами, которую так и не удалось сфокусировать. Потом была ещё пара-тройка похожих историй.

И знаете, что оказалось? Даже когда ты продакт-менеджер или там директор, ты тоже далеко не всегда самостоятельно определяешь, что делать.

Я подсмотрел в канале у Кристины Гусевой отчет Atlassian о состоянии продуктовых команд (они опрашивали менеджеров продуктов сеньорного уровня в США, Германии и Франции, всего 700 респондентов).

И знаете, что? Только 52% говорят, что имеют полномочия (feel empowered) определять стратегию и внедрять инновации. Остальные в той или иной мере реализуют чужие идеи. Меньше половины (47%) говорят, что продакт вообще направляет работы. В лучшем случае (43%) они имеют то же влияние, что и другие команды.

И — та-дам! — знаете, на что времени у продактов всегда не хватает?

На стратегическое планирование и разработку дорожных карт (отметили 49% респондентов) и на анализ и отслеживание метрик (тоже 49%). На третьем месте — личное развитие и обучение, на 4-м — инновации и эксперименты.

Погодите, а чем тогда вообще занимается продакт? Как образно пишут в отчете: 'it seems like product teams are focused on keeping their heads above water', "прикладывают все усилия, чтобы не потонуть".

Там весь отчет про то, как продуктовые команды и их руководители пытаются жонглировать множеством проектов, конкурирующими приоритетами, capacity команд, и ещё судорожно думают, куда бы тут воткнуть ИИ, потому что в каждом же продукте теперь должен быть ИИ, так?

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

В общем, не то чтобы роль продакта была очень развеселой и давала больше полномочий. В основном совпадает с моим опытом. Определять развитие продукта можно? Можно, если хватает времени и по согласованию с топ-менеджментом / владельцами / советом директоров. Эксперименты проводить можно? Можно в ограниченном объеме, в низкорискованных областях и только с разрешения руководства. Да, и чтобы метрики прибыльности ни в коем случае не падали! А релизить нужно чаще! 'Product development becoming a more cutthroat environment' — пишут авторы. Cutthroat!

Причем ИИ не особо помогает (про него в отчете тоже есть). На максималках он может экономить до 2 часов в день, в 50% случаев — от 10 минут до часа, вот только им в основном генерят тексты PRD, user story и отчеты для руководства. Сами респонденты считают это автоматизацией отдельных рутинных операций, а целостного системного способа внедрения ИИ в процессы пока нет.

Вторая часть отчета, которая подробно раскрыта в посте у Кристины, про то, что с этим делать. Выглядит, честно говоря, немного как "мышки, станьте ежиками". Вам не дают заниматься стратегией и экспериментами? Отлично, занимайтесь больше стратегией и экспериментами! Ну, эээ, спасибо. Нет, ну ладно, это самая интересная часть работы, и инструменты там описаны классные, хотя в общем и простые. Но напомнить себе лишний раз не помешает.

Например, что думать нужно не про output (созданных артефактах), а про outcome (достигнутых результатах).

Или про пирамиду RUF: Reliability-Usability-Features. Сначала надежность, потом пользовательский опыт, и только над ними уже новые фичи.

Ну а свободу в принятии решений нужно искать, видимо, не на уровне продакта (или даже CPO), а ещё выше!

В комментариях к предыдущему посту пишут, что продакт и не должен самостоятельно никаких целей определять, его задача — достигать заданных бизнесом показателей.

На это есть ответ в том же канале Product Games — кстати, очень рекомендую, если интересуетесь управлением продуктами. Я на несколько каналов продакт-менеджеров подписан, но они все почему-то странные — либо там бородатые мужики, которые все посты пишут матом, либо сплошная реклама каких-нибудь своих курсов. В этом смысле Product Games — прямо глоток свежего воздуха и чистой речи! (Реклама там тоже есть, но не чрезмерно).

Так вот, пост про разницу в понимании роли менеджера по продукту в разных странах:

в Европе это, действительно — чел, который координирует процессы, принимает готовый roadmap, и KPI — это «чтобы все были довольны». До пользователей далеко, решения принимаются "где-то наверху".

в США — PM отвечает за рост, влияет на стратегию, напрямую работает с выручкой, ценой и активацией. Много автономии, скорости и доверия.

В РФ я сталкивался с разными ожиданиями, даже пытался об этом рассказывать почти 10 лет назад на AgileDays.

Разброс, который я видел: от почти маркетингового содержания — закупка трафика, тюнинг конверсий и лендингов, активации и допродажи, и неважно, в чем вообще смысл продукта (помню, меня это поразило в Нетологии — когда я заикнулся про результат обучения для клиента и улучшение методик, тамошние продакты меня просто не поняли), до мини-CEO своего продукта, с владением бюджетом и ответственностью за бизнес-показатели.

Где-то посередине оказываются "продакты по европейскому образцу" — операционные менеджеры, своими управленческими и лидерскими усилиями переводящие чьё-то видение и роадмэп в реально работающий продукт.

На самом деле CEO ведь тоже не самый главный — он отвечает перед собственниками, инвесторами и советом директоров. И как мини-CEO, тоже будешь отвечать, и делать то, что тебе ставят как KPI.

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

Или, например, ты думаешь, что твои клиенты — обучающиеся, и выстраиваешь весь продукт под них, а совет директоров тебе говорит: думать нужно о ректорах региональных вузов, основные деньги будем брать от них. То есть продукт резко стал не B2C, а B2B (я придумал обозначение U2U — University to university), и всё совсем другое. Ну и продакт не нужен, больше нужны прошаренные сейлзы. Собственно, продуктовая история на этом закончилась.

Так что нужно выбирать, и выбирать аккуратно. Я про себя точно знаю, что в чистый маркетинг я не хочу идти, мне важно видеть, как идея превращается в работающий продукт и приносит пользу людям. Это, кстати, и в отчете видно: от продактов хотят достижения бизнес-показателей, но только 12% радует эта работа. Остальных больше драйвит создание чего-то нового, креативное решение проблем, глубокое понимание проблем пользователей и внедрение инноваций.

У Жени Калинина ("Школа трекеров") в рассылке подсмотрел отличную мысль про применение ИИ в бизнесе. Сейчас же все побежали, всем везде нужен ИИ. В какую тусовку не придёшь — все обсуждают ИИ.

У аналииков ИИ, у разработчиков ИИ, у архитекторов, у девопсов, у врачей, у учителей, у писателей — все только про ИИ говорят (имея в виду в основном LLM, конечно). В последнее время — про агентов.

Но эффект не очень виден — по крайне мере, не очень однозначен. Кому-то помогает, а кому-то вообще нет. На Pimon я слушал доклад про инструмент для настройки мэппинга и преобразования данных в шине при помощи LLM. У слушателей был главный вопрос — зачем?

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

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

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

Если бы, конечно, именно это было главным ограничением.

Мы же помним, что по Голдратту главное ограничение в каждый момент одно. И отследить его можно по недозагруженности следующего звена в производственной цепочке. Руки и головы есть, но они ждут задачу — не хватает входящих деталей (в нашем случае — информации. В наших проектах вообще только две причины простоев: любо люди ждут информацию, либо информация ждет людей).

Если у вас и так сильно загружены разработчики — нет смысла увеличивать число написанных постановок, их всё равно будет некому делать. Нужно сначала разработку разгрузить. И так далее. Опасность тут в том, что у нас зачастую каждая функция отвечает за себя, а не за весь процесс от начала до конца. А локальная оптимизация одного участка ведет к росту незавершенки, а не росту выпуска. Я до сих пор вижу, как в одном продукте продолжают реализацию разработанной мной ещё в 2022 году дорожной карты; я уже три года там не работаю, а они её всё никак не сделают.

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

В общем, применяйте генеративный ИИ не где попало, а где у вас сейчас главное ограничение! Тогда и эффект будет значимый.

По поводу продуктового подхода мы тут немного зарубились в комментах с Димой Безуглым. Я, причем, даже вполне одобряю и приветствую этот самый продуктовый подход, но давайте поймем, в чем он выражается?

Я считаю — у любого явления должны быть свои проявления. За изменением в способе мышления должна следовать перестройка способа деятельности. И это можно отследить. Ну не может быть такого, что делаем мы всё так же, как и раньше, но теперь у нас продуктовый подход! Хотя, если посмотреть на Agile и SAFe...

И наоборот — в конце концов, мы же знаем, что критерием научного подхода является не доказательство правильности, а фальсифицируемость — какие признаки помогут нам установить, что продуктовым подходом тут и не пахнет?

Есть хороший пример про школы, мне один директор подсказал: руководство может сколько угодно говорить, как они ориентированы на ребенка, но посмотрите — на каком уровне висят плакаты на стенах? На уровне глаз детей или взрослых?

Вот хочется такие же критерии про продуктовый подход. Заходишь в офис, и сразу видишь — тут продуктовый подход. А вот у этой — не-а, вообще другой какой-то. Что это может быть?

Ну, точно понятно, когда не. Это мне в одной организации директор по разработке говорил — а кто такие продакты? Какая от них польза? Как пользователи работают — бизнес-аналитики опишут. Удобные интерфейсы дизайнеры нарисуют. Даже CSI и NPS мы в опросах выясняем регулярно. Roadmap по функциям верхнее начальство спустит, исходя из своих соображений. А продакты ваши что делают?

Тут как раз всё понятно. И, глядишь, года через три — они уже и сами продактов нанимают, разобрались.

А вот если даже и продакты есть, как узнать — настоящие они, или для виду? Может это и не продакты вовсе, а, например, маркетологи. Или PO с чисто технической ролью — карточки по канбан-доске двигать.

Я попробую накинуть, а вы, пожалуйста, отреагируйте как-нибудь — отзывается, или совсем не то:

* Связь функций и деятельности пользователей. Вот прямо в явном виде: есть такой документ/рисунок, где видно, как какая-то функция на какую-то деятельность влияет. Может быть даже функция-деятельность-метрика (внедрение функции ведет к изменению деятельности, что ведет к изменению целевой метрики). Это, если роль пользователя добавить, Impact map получается. Ну или карта гипотез, как её Александр Бындю перебрендировал.
(Вот как надо, кстати говоря! Я на курсе-то примерно то же самое рассказывал, только упаковать не сумел).

В общем, ни курс не был востребован, ни живьем я ни у кого такой карты не видел (ну, кроме как у себя). Ну ладно, изменение деятельности — это слишком сложно, но хотя бы связь функций с метриками? То есть, набиваем бэклог не по принципу "что влезает", а по текущим целям и показателями продуктовых метрик. Можно даже таблицу составить — какая функция на какую метрику и в каком масштабе влияет. Мне Леша Кулаков (директор по продукту Ridero) такую показывал — у него ещё шкала влияния была нелинейная: 1,3,9. Гипотезы, конечно, но хоть что-то.

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

Критерий: есть ли артефакт, в котором можно посмотреть — какие функции для кого и зачем сделаны? Как они должны были повлиять на поведение/метрики, и как реально повлияли?

* Структура и предмет коммуникации. Это сложнее вытащить, но можно по назначенным встречам посмотреть. Кто, с кем и о чем говорит? Если мы хотим внедрить сквозное понимание, зачем мы каждое движение в продукте делаем, то обсуждаем ли мы цели продукта с разработкой и поддержкой? А берем их откуда, это с кем обсуждаем и как часто? Пользователи в этом участвуют?

* Представленность пользователей продукта. Откуда мы вообще узнаем о пользователях? Насколько мы от них далеки? Кто их вообще видел в последний раз? Как мы их слышим? Являются ли сами члены команды пользователями?

Вот что сразу в голову приходит, на что ещё стоит посмотреть?

Отдельная тема для интеграций — сериализация данных. Про неё почему-то мало говорят на "курсах по интеграциям и проектированию API".

А это, между тем, чуть ли не половина успеха интеграционного решения.

Вот, например, CSV. Существует же чуть ли не с 1972 года, говорят, его удобно было на перфокартах пробивать. И ведь до сих пор активно используется! Весь ETL, вся BigData, весь ML на нём только и держится.

А почему? Потому что
* человекочитаемый
* самый легковесный из человеко-читаемых (из оверхеда — только разделители, кавычки, переносы строк и символы экранирования — почти ничего, если сравнивать с JSON или XML)
* самый быстрый для обработки (до 300 тыс. строк в сек, какое API столько выдержит?), отлично параллелится

С другой стороны:
* не стандартизованный (а вы видели CSV с табуляцией? А с палками | в качестве разделителей? А с крышками ^?)
* бессхемный, нетипизированный
* плоский
* невероятно хрупкий — одна лишняя запятая, кавычка или разрыв строки, и конец обработке

Но если мы это понимаем, то можем предположить, что на каждую проблему должно быть своё решение. И действительно — есть CSV Schema , правда в статусе вечного драфта. С другой стороны, есть стандарт метаданных для описания табличных данных в Вебе: https://www.w3.org/TR/tabular-data-primer/

Как обычно, если нет одного стандарта, значит их будет два.

Ну и, конечно, есть альтернативный формат на основе JSON, берущий лучшее из двух миров — JSON Lines, JSONL.

Выглядит примерно так:

["Name", "Session", "Score", "Completed"]
["Gilbert", "2013", 24, true]
["Alexa", "2013", 29, true]
["May", "2012B", 14, false]
["Deloise", "2012A", 19, true] 

Решена проблема с внезапными разрывами строк, вложенными объектами и неоднозначностью разделителей. Правда, для него даже RFC пока нет.

В общем, всё укладывается в теорию гибридов Клейтона Кристенсена — в процессе подрывной инновации индустрия проходит стадию гибридов: парусно-паровые суда, гибридные автомобили, я в одном музее выдел даже гибрид шпаги и пистолета. У нас в интеграциях — странные наполовину JSONы, наполовину CSV; или вот диковинные гибриды JSON и XML (в NoSQL языке запросов JSONiq):

[ xs:date("1066-10-14"), <mercury>Hg</mercury>, "ice cream" ]

Так что, если вы видите какой-то гибрид (например, гибрид редактора кода и ИИ-генератора), это значит, что мы посреди подрывной инновации.

Правда, Кристенсен это писал про смешанное обучение, но пока подрыва школьной системы не видно — тут ковид одновременно и дал мощный толчок, и так всех напугал, что все хотят вернуться обратно к очным форматам. Ну посмотрим.

Из каких ролей переходят в аналитики? Мы не знаем. Самый популярный ответ — другое (36%). На втором месте — первая работа в ИТ (21%). На третьем — другая роль в ИТ (не разработчик, не QA, не из поддержки и не тех.пис) — 19%.

Среди предыдущих профессий есть авиадиспетчер, юрист, геолог, пиццамейкер и проектировщик мостов.

Стажеров-системных аналитиков не бывает (1%)

Про задачи: что приходится делать и что нравится делать. Удивительно, но первая тройка совпадает: что делают, то и нравится (ну или наоборот). Это работа с требованиями, с моделями бизнес-процессов и проектирование интеграций.

А вот следующая тройка желаемого: проектирование архитектуры, проектирование систем и ресерч.

Но приходится заниматься управлением изменениями, написанием документации и поддержкой.

Соответственно, все хотят прокачать навыки в system design, solution architecture и проектировании интеграций.

Если это правда — что, нужно срочно делать образовательные продукты для аналитиков по архитектуре и system design?

Я привез на Flow обновленную карту интеграций.

Обновлений много:

* Изменена структура: добавлены колонки "Семантика взаимодействия", "Стандарты", "Гарантии доставки"
* Добавлена семантика для REST: ресурсный стиль (REST уровня 2) и гипермедиа стиль (HATEOAS, REST уровня 3)
* Добавлены JSON:API, HAL, JSON-LD
* SOAP включен в асинхронные методы
* Добавлен WS-RM для SOAP — протокол гарантированной доставки
* Добавлены подходы к целостности транзакций: ACID и BASE
* Добавлено описание паттернов API Gateway и ESB
* Добавлено описание ETL-процесса
* Добавлена CAP-теорема
* Добавлено описание семантик гарантированной доставки
* Раздел "Особенности" объединен с разделом "Когда использовать"
* Исправлены опечатки

А самое главное — я, кажется, придумал шаблон для описания любой технологии интеграции!

Какие вопросы мы должны задать, когда смотрим на технологию?
1. Что это? Протокол, язык, набор принципов, конкретный продукт?
2. Какой верхнеуровневый паттерн? (по Грегору Хопу: файловый обмен, общая БД, удаленный вызов, сообщения)
3. Режим взаимодействия — синхронный или асинхронный? (скорость против пропускной способности)
4. Семантика запроса / интеграционный стиль: RPC, Query, ресурсный (REST 2 lvl — ресурсы и методы HTTP), гипермедиа (REST 3 lvl, HATEOAS), стриминг, публикация/подписка — в общем, как мы смотрим на интеграцию?
5. Протокол: опираемся на HTTP или используем что-то низкоуровневое? Если HTTP — то используем ли строку запроса и хедеры? То есть, получится ли подключить кэширование, маршрутизацию и все эти готовые штуки?
6. Формат сериализации: текстовый или бинарный? Есть ли схема? Обязательна ли она? Насколько строгая типизация? Есть ли сложные структуры: вложенные объекты, массивы, maps, множества?
7. Есть ли возможность определять и передавать кастомные ошибки?
8. Есть ли встроенные средства гарантированной доставки, и какие семантики поддерживаются?
9. Что с безопасностью? Шифрование, аутентификация, контроль прав.
10. Скорость сериализации / десериализации, размер сообщений
11. Есть ли инструменты преобразования данных?
12. Есть ли язык определения интерфейсов / спецификаций?
13. Статус стандартизации / распространенность / надежность / поддержка в разных языках и фреймворках
14. Какие особенные фишки есть у технологии?
15. С какими проблемами мы столкнемся?

Вот такие 15 вопросов, возможно ещё что-то появится. Но уже с этим можно оценивать и сравнивать разные технологии — насколько они близки, что будет стоить переход и имеет ли он смысл, как вообще об этом думать.

Ссылка на актуальную версию карты: https://disk.yandex.ru/i/k69r0Qr39_1P-w

А вот и презентация с доклада про карту интеграций. Она отчасти повторяет карту, но в постраничном формате, и задает ту самую рамку для рассмотрения любой технологии.

Через эту рамку я попробовал несколько технологий разложить:

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 красивые шрифты побились :( )

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

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

Я вот, например, в разговоре с Дмитрием Таболичем сформулировал важное понимание про роль архитектора. Обсуждали мы доклад Дениса Бескова про пошаговый алгоритм проектирования архитектуры систем. Ну или system design. Денис его перед конференцией показывал в чате архитекторов (RASA Chat) и у себя в канале.

И вот среди архитекторов в чате разгорелось обсуждение, суть которого свелась к следующему (пересказываю своими словами):

Задачи архитектора настолько разноплановы и разносторонни, что свести их к какой-то единой схеме, или, упаси б-г, алгоритму — совершенно не представляется возможным. Поэтому заниматься таким не нужно, и даже вредно. Всё, что делает архитектор — уникально. Любая систематизация — обман для профанов. Никакие стандарты, таксономии и алгоритмы не работают. Каждый проект уникален, и к каждому нужно подходить с особой стороны, а с какой — может знать только архитектор. Поэтому советы тут скорее навредят и направят не в том направлении. Поэтому и советов никаких никому давать нельзя. В лучшем случае их может давать один опытный архитектор другому опытному архитектору. А тот, естественно, их с негодованием будет отвергать, так как советчик не в курсе всей полноты и сложности ситуации, советует глупость, и вообще, судя по всему, архитектором не является.

Из этого вытекает одно очень важное следствие: обучить архитектора невозможно. Так как всё меняется, один проект не похож на другой, в разное время приходится делать разное — то и определить, кто такой архитектор и чем он занимается, не представляется возможным. Значит, нельзя построить программу обучения архитекторов, это профанация. Чему бы на этой программе не учили — это будет однобокий взгляд и только часть правды. Всей же сложности, с которой архитектор сталкивается в работе передать нельзя, см. выше. Столь же бесперспективной и вредной является идея профессионального стандарта архитектора — это просто оксюморон. А тем более — попытка задавать требования к образованию или уровню квалификации.

Но если научиться быть архитектором невозможно, то откуда тогда берутся архитекторы? И вот тут я словил инсайт: дело в том, что архитекторами просто становятся. Невозможно научиться, нужно стать им. Просто в какой-то момент ты понимаешь — да, я архитектор. Появляется такое внутреннее неоспоримое убеждение. После этого, конечно, тебе уже не нужны никакие подпорки в виде алгоритмов, стандартов или чего-то там, они даже смешны. Ведь ты — архитектор [Гарри], и всё, что ты делаешь — дело архитектора. И никто другой тебе не может сказать, что ты — не он. Да кто ты такой, чтобы мне говорить, кто я такой? Сам ты не архитектор. Косвенным признаком можно считать, когда архитекторы тебя признают в тусовке своим. Как лебедя из сказки Андерсена. Думаешь — пусть они меня заклюют, эти прекрасные птицы, ан нет, не клюют — прислушиваются даже и кивают.

Вот, и это не про обучение. Разве гадкий утенок пытался научиться, как стать лебедем? Он просто был им. Так и архитектор — просто в какой-то момент им становишься, и всё, уже никто не сомневается.

Это не про насмотренность, опыт или экспертность в программировании. Это про уверенность. У аналитиков, правда, с этим большие проблемы — видели в опросе, 54% испытывают синдром самозванца часто или всегда. Обращали внимание, как люди говорят о своей профессии? "Ну, я работаю кем-то вроде системного аналитика..."

Ни один программист не скажет, что работает "кем-то вроде фронтендера", у них всё чётко. И архитектор не будет сомневаться. Так что нужно качать не столько знания, сколько уверенность в себе и самоопределение.

Посты про роль архитектора вызвали просто бурю обсуждений в комментах. Попробую ещё с одной стороны зайти.

Любой объект можно рассматривать с разных точек зрения и через разную оптику. Это называется концептуальная рамка: через призму каких концепций мы смотрим на объект, что мы в нем выделяем?

Вот деятельность архитектора — это что? У нас был спор в рамке "проектирование"—"не проектирование", и из-за неопределенности этого "не-проектирования" дискуссия дальше не пошла, каждый предлагал что-то своё. Рамка оказалась недоопределена.

Предлагалось деление на проектирование и сбор материалов для проектирования.

Но мне кажется (из опыта работы архитектором и опыта работы с архитекторами), что архитектор не обязательно проектирует. Продуктом архитектора часто является не сама архитектура системы, а решения относительно архитектуры.

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

А можем ещё сильнее заострить, и задать вопрос — когда требуется принятие решений? Мне кажется, принимать решение нужно, когда есть конфликт.

То есть, мы можем посмотреть через рамку конфликта. Ещё точнее — конфликта, связанного с техническими и функциональными свойствами системы.

И архитектор не столько проектирует, сколько решает конфликты. А решать их можно по-разному: сотрудничать, побеждать, искать компромисс, избегать, приспосабливаться, находить взаимовыгодные решения.

У нас в книге, кстати, есть кусок про конфликты, т.к. мой соавтор защитил диссертацию про конфликты в ИТ-проектах.

Технический долг возникает как раз из-за компромиссов и избегания решения конфликтов. ТРИЗ дает советы, как решить конфликт (противоречие) с улучшением всех аспектов и удовлетворением всех сторон.

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