Хм. Почему-то отвалился чат. Если хотите обсудить диаграмму робастности — комментируйте это сообщение.

Что я делаю с ChatGPT прямо сейчас (и это выглядит как чертова магия!)

В ChatGPT теперь можно вставлять файлы и скриншоты. И если вставить скриншот таблицы, то можно попросить сделать SQL-стейтмент для создания этой таблицы в БД, и INSERT INTO со всеми значениями из таблицы!!!1

Скреппинг данных никогда не был таким простым.

Upd: это мне в бесплатный аккаунт раскатили модель 4o, возможно, вы про неё слышали. Это сейчас самый топ, она по всем показателям пока впереди других LLM.

Как правильно отмечают в комментариях к посту про  Robustness Diagram, в UML её нет отдельно, потому что её можно сделать, например, из Communication Diagram.

Ранее она называлась Collaboration — как, собравшись вместе, части системы решают задачу. В конце концов, это просто объекты и стрелочки. Такую диаграмму можно и сейчас собрать в каком-нибудь PlantUML, хотя её нет в списке диаграмм, которые он поддерживает. Но стереотипы для Entity, Control и Boundary есть, и стрелки тоже.

Забавно, что Ивар Якобсон в расширении UML, описывающем Entity-Control-Boundary подход — у него он назывался Objectory — имел в виду скорее диаграмму классов. Собственно, он ведь какую задачу решал? Как правильно выявить структуру классов в приложении при использовании объектно-ориентированных языков. Это был 1992 год, ОО-языки уже появились, а методологии их применения — ещё нет. И дискуссия про пользу ОО-подхода против структурированного программирования стояла очень остро.

Ивар Якобсон и придумал Use Case'ы, как способ проектирования структуры классов. Методически это выражалось как последовательность:
1) реестр юскейсов (взгляд на систему с точки зрения задач пользователя) — диаграмма юскейсов;
2) шаги юскейса, и необходимые для них интефейсы, сущности и логика — диаграмма устойчивости;
3) классы, реализующие выявленные интерфейсы, сущности и логику — диаграмма классов.

Для своего времени это была прорывная идея, так как адепты ООП всё время твердили, что классы — это отражение объектов реального мира, и строить их нужно исходя из модели предметной области, не задавая вопроса, что с ними будет делать пользователь.

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

Разговоры по объектно-ориентированное программирование или проектирование сейчас, наверное, не так уж актуальны, но те же идеи на более верхнем уровне присутствуют в DDD и микросервисах.

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

Я долго задавался вопросом — почему диаграмма робастности? Ведь в статистике, электротехнике, инженерии и ML робастность — свойство сохранения работоспособности при резких и странных изменениях внешних параметров (выбросы, помехи). Так вот потому и робастности, говорит Якобсон: свойство системы сохранять работоспособность и целостность при поступлении неожиданных и странных требований!

Пришло от заказчика дикое, но неизбежное требование — а мы уже готовы! У нас архитектура так построена, что для дикого требования поменять-то нужно в одном месте небольшой сервис, ну может в двух. И работаем дальше! Система устойчива к выбросам и взбрыкам заказчика.

Сколько информации в ваших требованиях? Сложный пост с математическим уклоном.

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

А это напрямую связано с количеством информации, описывающей систему. Не сильно вдаваясь в математические модели, можно сказать, что энтропия — это разница между новой информацией, содержащейся в сообщении, и хорошо известной информацией (о которой, может, и говорить-то не стоит). Например, хорошо известно, что любая сущность в системе должна быть создана и предъявлена/прочитана/использована. С большой вероятностью она должна быть удалена или архивирована. С некоторой вероятностью — изменена. Это обычный CRUD, которым можно контролировать полноту, но который почти ничего нового не сообщает об устройстве системы: можно было бы просто перечислить список сущностей, и завести CRUD для каждой. А вот когда мы начинаем задавать вопросы — когда и кем создается сущность? кому, когда и для чего её показывать? зачем и кто её изменят? — мы можем извлечь дополнительную информацию, передать в требованиях что-то, что не очевидно с самого начала. Таким образом снизив энтропию — уменьшив количество вариантов и рассказав что-то интересное.

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

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

Требования должны быть неожиданными! И требования должны быть разными! Помните, как работает архиватор? Он выбирает одинаковые последовательности и заменяет их одним символом — повторение не несет информации. Если вы видите, что в ваших требованиях постоянно что-то повторяется: формулировка, обоснование, решение — остановитесь и задумайтесь. Не пропускаете ли вы здесь важную информацию? Стоит покопать поглубже, и получше разобраться? Или это хорошо известная информация? тогда и повторять её не имеет смысла, нужно упаковать в более компактный вид.

А сколько у вас в документе неожиданных требований? Знаете, как в шахматной нотации ставят ! и !! и иногда !? Хороший ход, отличный ход, и неожиданный ход (возможно, ловушка).

Скольким требованиям в документе вы может поставить такие значки?

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

А вот что меня натолкнуло на написание предыдущего поста. Это из таблицы с бизнес-требованиями, столбец с обоснованием требования.

Фактически, ответ на вопрос "Зачем мне, как <роли> это нужно?". Это работа аналитика-стажера, но я видел такое и у штатных аналитиков. Это мощный сигнал! Если вы видите такое — это повод разобраться, что тут происходит. Простое повторение не несет новой информации. Если несколько требований нужны для одного и того же — может быть, это одно требование и оно зря разбито на несколько? А может быть, обоснование взято слишком высокоуровневое, пропущен уровень один рассмотрения.

В любом случае, так быть не должно, это недоработка.

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

Но если вам вдруг интересно, что мне интересно и что я читаю каждый день — я создал отдельный канал https://news.1rj.ru/str/yksdailylinks.

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

В общем, если вам вдруг любопытны ссылки от меня — welcome!

Я редко делаю репосты, но тут просто огненная тема! Ну и Киру в принципе рекомендую, если интересуетесь процессами найма и HR.

Для аналитиков, о чем можно рассказать, помимо примеров в посте, и что меня бы, например, интересовало при собеседовании аналитиков (кстати, меня, если что, можно звать на собеседования, чтобы оценить кандидата):

⭐️ пример автоматизации бизнес-процесса или отдельной функции (сквозное описание: от выявления требований до технических решений и тестирования, если было);

⭐️ пример участия в проектировании технической архитектуры (или выбора способа реализации, выбора готового решения с учетом технических требований);

⭐️ пример задачи описания требований для проектирования интеграции систем или API;

⭐️ пример решения какой-то сложности в проекте — когда было непонятно, что делать, или заказчик не мог сформулировать требования, или когда требования были противоречивые; в общем — когда вы пришли и поправили всё, спасли бизнес и/или команду разработки;

⭐️ пример применения какой-то техники бизнес- или системного анализа (например, того же DDD или Impact Mapping) — с обязательным указанием, в чем была польза, в чем положительный эффект;

⭐️ пример организации управления требованиями: как фиксировали, как согласовывали, как управляли версиями, как передавали в работу, как принимали выполненную работу.

В идеале, всё это нужно раскладывать по методу STAR: Ситуация — Задача — Действие — Результат, прямо так и рассказывать. Я рекомендую при подготовке к интервью составить себе несколько таких примеров, расписанных по STAR, заучить и при случае вставлять. Рекрутеры сами по этому STAR работают, им зайдет. (то есть, если вы нанимаете людей, вы из спрашивать можете в той же логике!)

Как вариант, можно использовать метод PARLA: Проблема — Действие — Результат — Опыт — Применение. Последние два — это Learned и Applied: что вы вынесли из этой ситуации, чему научились, и как теперь это применяете. В принципе, даже без задачи подготовки к собеседованию это хорошие вопросы для ретроспективы любого проекта или его этапа.

Главное слово кандидата на собеседовании: «НАПРИМЕР»

📌 Никто не телепат. К сожалению, если вы не будете приводить примеры из своего опыта, нанимающий менеджер не сможет оценить, насколько вы действительно реализовывали те задачи, про которые говорите.

Сравните:

❌ Я закрывала сложные вакансии быстро и качественно.

✅ Я закрывала сложные вакансии быстро и качественно.
Например, однажды нам в компании срочно потребовался ещё один разработчик баз данных, а подходящих кандидатов на рынке не было, сроки поджимали. В итоге я лично опросила всех имеющихся в команде разработчиков баз данных и попросила рекомендаций на их бывших коллег, получила контакты 10 кандидатов, с каждым связалась и нашла троих, кто был готов не только рассмотреть нашу вакансию, но и выйти в короткие сроки. Всех трёх мы отсобеседовали за 2 дня, выбрали одного, который вышел сразу после согласования оффера. Весь процесс занял у меня неделю.

📌 Примеры нужны для иллюстрации каждой компетенции или ключевого тезиса, которую вы презентуете работодателю.

Пример:

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

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

📌 Любое утверждение становится весомее и понятнее, если вы подкрепляете его примером.

Например:

❌ Что я больше всего не люблю в работе? Когда внутренний заказчик возвращается с правками 🙁

✅ Что я больше всего не люблю в работе?
Расскажу пример: мы работали как внешний подрядчик и я, как проджект, очень много внимания уделил брифингу клиента, выявлению потребности и формированию полного ТЗ, которое полностью устроит клиента. Каждые 2 недели мы сверялись с клиентом по процессу, чтобы сразу же выявлять проблемные места. Всё шло гладко, мы резво двигались по плану, клиент вносил минорные правки и мы уже подошли к финалу проекта. И тут, когда до дедлайна оставался месяц, на стороне клиента поменялся руководитель, который остановил весь процесс, а потом кардинально поменял ТЗ и потребовал, чтобы мы уложились в изначальные сроки. Я очень не люблю такие ситуации. Хорошо, что я внимательно документировал каждый шаг и мы были документально защищены от такой ситуации. В итоге, я смог наладить контакт с новым руководителем, обсудить с ним его пожелания и наши возможности. Мы сформировали новый план действий и смогли реализовать то, что клиенту было необходимо.

👉 Быстрый совет: напишите на бумажке слово «НАПРИМЕР», приклейте возле экрана на время собеседования, чтобы почаще использовать это слово и подкреплять свои слова наглядными примерами 🙏

Опубликовали статью по мотивам выступления на Flow'2023 (вот тут в формате видео https://www.youtube.com/watch?v=HzynqWGKehQ)

Опубликовали статью Юрия Куприянова на тему «Скрытая работа аналитика по проектированию систем»

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

Статья будет полезна системным аналитикам уровня junior и middle

Содержание:
1. Что такое системный анализ
— Парадокс системного анализа
— Требования вместо системы
— Граница требований и проектных решений
2. Проблемы требований к ПО
— Существуют ли требования?
— Иллюзия требований к ПО
— Рекомендации по работе с требованиями
3. Компетенции аналитика в проектировании
— Проектирование взаимодействие пользователя с системой
— Проектирование хранения данных
— Проектирование интеграций, взаимодействия с внешними системами
— Архитектура системы
4. Что делать системному аналитику? Переквалифицироваться в проектировщики или в архитекторы?

Почитать можно тут

Если бы Ивар Якобсон создавал диаграмму устойчивости сейчас, он бы назвал её "диаграммой антихрупкости". Звучит модно, не то что какая-то там робастность!

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

Как это обеспечить в реальности? Система должна иметь возможность изменять своё поведение без радикальной перестройки внутренней структуры. То есть, структура системы должна обеспечивать возможность таких изменений. Например, один из вариантов — избыточность. Мы почти всегда боремся за отсутствие избыточности и дублирования (принцип DRY), но в случае потенциальной высокой изменчивости среды это может выйти боком (например, см. заметку про это в блоге Гугла).

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

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

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

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

Пост по заявкам читателей (да, так тоже можно!) про названия.

Тема-то актуальная, регулярно в чатах кто-нибудь спрашивает.

Итак, мы проектируем системы и даём названия разным элементам.
В основном это:
* таблицы в базах данных
* поля в таблицах
* индексы, ограничения и бизнес-правила
* эндпоинты API
* поля в JSON
* названия файлов

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

Что же у нас с рекомендациями? Удивительно, но они разные :) Вот какие вопросы обычно обсуждают.

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

👨‍🎓 PascalCase (без пробелов, с большими буквами в начале слов)

🐫 camelCase (без пробелов, с большими буквами в начале слов, начиная со второго, как горбы у верблюда)

🐍 snake_case (вместо пробелов используется подчеркивание, всё маленькими буквами)

🍢 kebab-case (вместо пробелов используется "минус", слова нанизаны на шампур)

Во-вторых, какие части речи использовать — глаголы, существительные? Особенно актуально для эндпоинтов API

В-третьих, для существительных — во множественном или в единственном числе их называть?

В-четверых, словарь. Какими словами вы называете объекты, и как переводите на английский (надо ли говорить, что называть все объекты нужно на английском, если только у вас не 1С). Как вы назовете счет клиента? Account, Check или Schet?

Любопытно, что рекомендации и лучшие практики для API и для БД иногда противоположны!

Для БД советуют использовать snake_case (так проще различать слова). Для эндпоинтов API — kebab-case, т.к. в вебе ссылки принято подчеркивать, и значок "_" может потеряться. Почему не camelCase? Потому что труднее различать слова и нужно переключать регистр (URI регистрозависимые).

В обоих случаях рекомендуется использовать в качестве названий существительные во множественном числе (для ресурсов REST API и для названий таблиц в БД). Один из аргументов для БД — меньше риск, что имя таблицы совпадет с зарезервированным словом. Хотя есть и контраргумент: давать таблицам и представлениям названия в единственном числе, чтобы не думать, как переводить во множественное (person — это persons или people?). Холиварная тема!

Следующая тема — идентификаторы. Должны ли они называться просто id, или повторять название сущности (team_id?) Есть аргументы за и против. Внешние ключи, понятно, должны назваться по названию внешней таблицы+id.

Названия таблиц и полей должны содержать полные слова, не сокращения. Нет ничего хуже таблицы pmnt23, состоящей из полей P1, NMT, ABBR14, FIELD28, ACC_NO и т.д. Названия типов также не должны становиться именами полей: DATE, TEXT или TIMESTAMP не дают никакого объяснения смысла. Также стоит подумать над более конкретными названиями — source_warehouse_id а не просто source_id.

Для API, кроме того, нужно понимать — запрашиваем ли мы коллекцию или единичный элемент? Если это элемент из коллекции, то будет существительное во множественном числе / id (users/{id}), но это может быть и служебное слово, указывающее на особенный элемент коллекции (users/me).

Про глаголы в REST писать не буду, пуристы скажут, что никаких глаголов в названиях эндпоинтов быть не может, но вот Google, например, считает иначе.

Ну а если у вас не REST, а наоборот даже RPC, то названия методов рекомендуется писать в PascalCase по формату "ГлаголСуществительное" — что мы делаем и над чем мы это делаем, причем существительное должно указывать на тип передаваемого объекта (GetBook возвращает объект Book).

Ну и пока нам не встречался camelCase, куда же без него. Он у нас живет внутри JSON — так записываются названия полей.

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

Ссылки на стили наименования, сборники лучших практик и посты по этому поводу:
https://github.com/RootSoft/Database-Naming-Convention
https://dev.to/ovid/database-naming-standards-2061
https://www.belgif.be/specification/rest/api-guide/#resource-archetypes
https://restfulapi.net/resource-naming/

Практикум радует (правда, статья-то ещё прошлогодняя). А давайте поможем Даше накидаем разные способы классификации интеграций? Вот вы какие знаете?

Чудная статья от Яндекс.Практикума про типы интеграций. Написана как будто специально, чтобы поиздеваться над аналитиками: у нас есть два способа классификации интеграций и по нескольку видов интеграций в каждой классификации. Объединим обе классификации в единый нумерованный список и расскажем вам про них по очереди! 🤯

Считаю, что зря они только две классификации взяли. Нужно было расстараться и штук пять взять! И по одному примеру из каждой классификации в список добавить! В общем, какое-то "системный аналитик изнасиловал журналиста" получилось.

https://practicum.yandex.ru/blog/sistemnaya-integraciya

Ладно, какие я знаю способы классификации интеграций:

🔹 по предмету, что именно интегрируем: данные, документы, справочники, функции? Вот у нас есть две или несколько систем. Мы хотим чтобы что из одной системы оказалось в другой? Появились какие-то данные? Или документ из одной системы можно было бы открыть в другой? Или чтобы в обеих системах были одинаковые справочники и актуальная основная информация? Или чтобы функциями одной системы можно было воспользоваться в другой?

🔹 по "глубине": что значит "появились"? Можно просто посмотреть данные/документы, или с ними можно что-то сделать? Сделать через интерфейс, или программно? Вот я сейчас вожусь с Битрикс24 (не спрашивайте), и там многие "интеграции" выглядят так: да, теперь можно посмотреть в интерфейсе Битрикса данные из другой системы. Нет, использовать их в процессах или, например, привязать к карточке сделки/клиента — нельзя. Только посмотреть. Вот такая интеграция.

Соответственно, можно рассмотреть "глубину" интеграции: те данные, документы, справочники и функции, которые вы получаете из другой системы — они насколько глубоко интегрированы в вашу систему? Практически так же, как нативные объекты, или живут в ограниченных контекстах, или существуют в совсем отдельных изолированных "резервациях", или просто точечно используются по месту, почти не проникая в вашу систему?

🔹 по уровню: об интеграции чего мы говорим? Объектов и модулей внутри одной системы? (Например, многослойная архитектура, API между бэкендом и фронтендом). Или интеграции нескольких систем/сервисов в рамках одного подразделения, с одним владельцем? Систем из разных департаментов с разными владельцами и политиками? Систем из разных организаций? Тут речь идёт о подконтрольности систем и наших возможностях диктовать правила взаимодействия и вносить изменения в системы.

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

🔹 по топологии: ну, тут понятно: точка-точка, звезда, шина, последовательное соединение (pipes-and-filters).

🔹 по "стилю" (из книжки "Паттерны интеграций корпоративных приложений") — не совсем классификация, поэтому авторы и называют эти стилями: файловый обмен; общая база данных; вызов удаленной процедуры (включая сюда и REST!); асинхронный обмен сообщениями.

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

🔹 по цели, очевидно: мы чего хотим от интеграции? Ускорения? Увеличения гибкости? Улучшения качества данных? Снижения расходов? Для чего всё затевается?

🔹 по "аспекту", я не придумал лучшего слова. Про какой аспект информационных систем мы думаем в первую очередь, что хотим объединить? Возможно, эту классификацию можно объединить с первой, про объекты. Итак, аспекты: данные (в любом виде, включая документы), системы (имея в виду, в первую очередь, взаимозаменяемость и унифицированность интерфейсов), процессы/функции/сервисы, UI/UX (унификация и консистентность пользовательского опыта), инфраструктуры, безопасности.

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

- централизация или стандартизация?
- оркестрация или хореография?
- синхронное или асинхронное взаимодействие?
- от данных или от функций (ресурсы vs методы, REST vs RPC)?
- CA, CP или AP?
- at least once, at most once или exactly once?
- бинарные данные или человекочитаемые?
- шифрование канала или каждого сообщения?

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

Программа ЛАФ практически сформирована, прием заявок на Flow закрыт. В этом году очень много заявок, и многим приходится отказывать. Что лично я ищу в докладах, и какими качествами обладает идеальный доклад:

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

2. Содержит обобщения или дистиллированный опыт, готовый к переносу и использованию в другой компании, а не просто рассказывает об одном кейсе. Рассказы про кейсы очень хороши, когда это блиц-доклады на 15-20 минут. На внутренних конференциях это отличный формат. К сожалению, открытые конференции практически не могут себе такого позволить, если оплачивают проживание спикеров. Так что многочисленные заявки "как мы организовали развитие аналитиков", "как мы работали над проектом мобильного приложения", "как у нас в компании работают с требованиями" как правило отсеиваются — если они не содержат ничего, кроме изложения хода проекта.

3. Поднимает актуальную тему, интересную аудитории. Можно сделать очень крутой доклад про очень узкую тему, но это всегда лотерея — возможно, ПК решит, что эта тема украсит и разбавит типовые надоевшие доклады, а может быть срежет из-за низкой востребованности. Узкие нетипичные темы:
- очень специальная организационная ситуация ("как выжить в проекте, где все всех подставляют" — да не выживать там надо, а бежать; "как работать в максимально бюрократизированной организации" — надеюсь, мы в такую организацию не попадём);
- очень специальные/устаревшие технологии ("специфика работы аналитика на проектах c Delphi/Fortran/1C/без пользовательского интерфейса")
- очень специальные предметные области (встраиваемые системы, военка, системы со сложной математикой — тут можно попасть в интерес ПК, но лучше кроме области иметь ищё какую-то мысль).

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

5. Прагматичен: идеи из доклада можно брать и применять в своей деятельности. Использовать приемы, инструменты, технологии, подходы, чеклисты, шаблоны. Знать, чему учиться. Что-то поменять: отношение или способ действий. Очень плохо, когда этого в идее доклада нет. ПК обычно спрашивает: для чего участники придут на доклад и с чем они уйдут? Многие авторы не могут толком ответить на этот вопрос, а он для ПК первоочередной.

6. Драматургически выстроен: в докладе должна быть логика изложения, путь героя, вызовы, провалы, препятствия, ложные победы, сюжетный поворот, повышение ставок... Нет ничего хуже ровного доклада, в котором ничего не происходит, только монотонное бу-бу-бу. Мы строили, строили, и наконец построили. Конец.

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

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