Руководство по написанию требований от INCOSE, которое я считаю одним из лучших и компактных описаний процесса работы с текстами требований, было обновлено в 2023 году до версии 4, и, видимо, по случайности, его финальный драфт (на английском) можно свободно скачать вот тут: https://www.incose.org/docs/default-source/working-groups/requirements-wg/gtwr/incose_rwg_gtwr_v4_040423_final_drafts.pdf

Так что, если вы хотели ознакомиться — скачивайте, пока доступно! Обычно драфт не очень сильно отличается от финальной версии. В чем его отличие от предыдущей версии, я пока не понял, но вроде бы документ стал длиннее страниц на 20.

Ещё про обучение: мне кажется, есть две стратегии. В обсуждении ко вчерашнему посту говорили про растяжку "фундаментальные знания" <-> "прикладные", вот из этого и выбор стратегии тоже строится.

Я впервые об этом задумался, когда был в гостях в Швейцарии, и речь зашла об образовании и карьере. У них там всё чётко: либо ты быстро получаешь рабочее образование (сюда же и программисты относятся, в смысле "кодеры"), и сразу идёшь работать — но тогда твой потенциальный заработок принципиально ограничен, больше какой-то суммы ты не будешь получать. Но работу найти несложно. Либо ты учишься на инженера или магистра, это плюс ещё года 3-4, и тогда твой потенциальный доход гораздо выше, но и число доступных тебе работ ограничено — человек, который мне это рассказывал, как раз недавно вышел на работу, после полутора лет(!) поиска — не было подходящих вакансий, а на более простую работу его не берут — overqualified! (Я не проверял, правда ли именно так устроена рабочая система Швейцарии, но звучит правдоподобно).

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

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

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

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

А вот у моего однокурсника была другая стратегия. Он спокойно отучился в аспирантуре и защитился, работая при этом кем-то вроде сисадмина/техдира совсем маленькой компании — не очень круто, зато дало время на подготовку диссера. Потом, уже будучи к.т.н. по модной теме, спокойно осмотрелся на рынке и пошел в Яндекс. Поделал крутые штуки в Яндексе, дорос до начальника группы, отучился в яндексовом ШАДе (это примерно уровень магистратуры).

Уволился, и начал опять учиться. Как раз появились MOOC'и, и, пока они были бесплатными, он прошел их все (ну, несколько десятков точно. Я осилил два). И вот с этим багажом уже стал искать, что делать дальше, и через несколько лет нашёл — и стал CTO и сооснователем стартапа с миллионными инвестициями и одним из признанных специалистов в ИИ и ML.

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

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

Нельзя сказать, что в методах системного анализа ничего не происходит. Вот, например, Ивар Якобсон совместно с Алистером Коберном на днях выпустили новое(!) руководство по юскейсам: Use Cases 3.0 (pdf)

Версия 3.0! Кто-то слышал про Use Cases 2.0? Там появилась такая идея, как "слайсы" — срезы юскейсов, напоминаюшие чем-то разбивку юзер-сторей, про которую я рассказывал на Flow в 2022 году.

Вообще, я и Ивара и Алистера очень уважаю, но ещё первая книге Коберна звучала как монолог из советского фильма: "Не будет ни театра, ни кино — одно сплошное телевидение одни сплошые use cases!", ничего, кроме юскейсов, вам для описания системы не нужно, и юскейсами можно описывать всё на любом уровне — от бизнеса до глубоко внутренних процессов внутри системы, и, конечно же, интеграции.

Собственно, Use Cases 3.0 ровно об этом. Они вводят 10 принципов:
1. Юзкейсами можно описывать любые системы: и бизнес, и ИТ-системы, и физические;
2. Юзкейсы помогают увидеть "картину в целом": назначение системы и как ей пользоваться;
3. Юзкейсы фокусируются на ценностях: целях пользователя и как лучше всего достичь их;
4. Вовлечение стейкхолдеров обязательно: соберите их всех;
5. Юзкейс рассказывает историю, от начального события до получения ценности или неудачи, включая все альтернативы и проблемы;
6. Юзкейс должен вызывать обсуждения — только так вы обнаружите все пропущенные шаги и расширения;
7. Приоритет — удобство чтения. Цель — представить общую картину всем вовлеченным сторонам, получить комментарии, подсветить все пробелы, получить все согласия;
8. Формат юзкейса и уровень детализации может быть очень разным: вы можете начать с наброска последовательности событий и добавлять детали постепенно;
9. Юзкейс реализуется поэтапно: сначала разрабатываются ключевые сценарии, потом более редкие и менее критичные;
10. Система может быть разработана через "слайсы" юзкейсов, каждый слайс добавляет свою часть архитектуры, кода и тестов.

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

Что ещё нового: использование юзкейсов описано в терминах Essence, как практика (с Альфами, их состояниями — жизненным циклом — и всяким таким). А вот что на самом деле интересно: авторы наконец-то дают ответ на вопрос, как юзкейсы связаны с user story.

Оказывается, вот как: диаграмма юзкейсов описывает всю систему, отдельный юзкейс описывает одну цель пользователя, слайс юзкейса описывает один из способов достижения этой цели с возможными ограничениями, а user story — это, оказывается, единица работы, которую нужно выполнить, чтобы реализовать этот слайс (на один слайс может приходиться несколько юзер сторей). Единицей работы может быть также задача (task) или фича.

В общем, для меня вся эта история выглядит, как попытка объяснить всем, что наш метод ещё ого-го! И вовсе он не устарел! И очень даже он крутой! А то, что вы там какие-то юзер-стори наизобретали, или job story, или ещё какой хипстерский способ описания — мы сейчас вам докажем, что это ерунда, и нужно использовать проверенный дедовский метод.

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

Заодно обращу внимание, что никаких "пакетов юзкейсов" или "системных юзкейсов" в этом руководстве нет (но есть "инфраструктурные юзкейсы"!)

В общем, если вы интенсивно используете в работе юзкейсы — вам должно быть любопытно, как их создатели видят их на исходе 2024 года (почти через 30 лет после изобретения).

UPD: Добавил картинку с юзкейсом и юзер-сторями

Или вот ещё в октябре OpenAPI Initiative выпустила первую версию спецификации Overlay : стандарта для описания изменений в спецификации API. Помните пост про метод PATCH и специальный тип документа для описания изменений ресурса? Вот такая же штука для изменения спецификации в формате OpenAPI.

В Overlay предусмотрено пока два вида операций (actions): update и remove. Первая позволяет что-то добавить или изменить в исходной спецификации, вторая, соответственно, удалить. Что именно удалить или добавить — задается полем target, в который пишется путь в формате JSONPath. Вот, скажем, пример удаления из спеки всех упоминаний localhost:

actions:
 - target: $.servers[?(@.url == 'http://localhost:8080')]
   remove: true

Для чего могут понадобиться эти оверлеи? Например, как в примере выше — для удаления или замены адресов для API в разных контурах — базовая спека одна и та же, а для каждого контура свои адреса, и, например, свои требования к аутентификации. Или (не очень для нас актуальный пример) — описание API на нескольких языках. А вот это можно себе представить: автоматическая генерация OpenAPI спеки из кода без комментариев и описаний + документ в формате Overlay, который эти описания добавляет. Ещё при помощи Overlay можно консистентно поддерживать два видов описаний: для внутреннего использования и для внешнего. А ещё можно в спеку Overlay вынести типовые для всех ваших API вещи: ту же аутентификацию и, например, описание ошибок. А можно убрать из общедоступной спецификации внутренние методы или параметры.

Поддержка нового формата пока ограниченная, но уже есть пара тулзов для встраивания в ваш CI/CD-пайплайн: отдельный тул openapi-overlays-js и ещё несколько в составе платформ для управления API.


Ранее в этом году OpenAPI Iniriative выпустила также спецификацию The Arazzo (Гобелен) , это тоже интересная штука. Помните принцип HATEOAS от Роя Филдинга? Ответ API должен содержать в себе все необходимые ссылки для работы с этим API? Вот Arazzo — что-то в этом духе. Только не внутри каждого ответа, а вынесенное в отдельную спецификацию. Этот формат описывает workflow для API. То есть, в какой последовательности нужно вызывать ваши эндпоинты, чтобы достичь нужного результата. Вот она, новая жизнь юзкейсов! В общем, идеи, не взлетевшие за 25 лет, не дают покоя исследователям и появляются в новых инкарнациях. С другой стороны, почему нет, посмотрим, как оно заживет.

Структурно спецификация Arrazo и правда похожа на формальное описание юзкейса: идентификатор, назначение, описание, входные параметры (inputs), предусловия (воркфлоу, которые должны быть выполнены до начала этого), шаги, ветвления при успехе/неудаче, результат выполнения (outputs). На каждом шаге мы можем получить результат вызова какого-то API (это могут быть API разных сервисов!), проверить эти результаты (не ошибка ли? есть ли нужные поля/значения?), сохранить ответ и перейти на другой шаг в зависимости от успеха или неудачи (есть операция goto). Что вам ещё нужно.

Выглядит довольно перспективно — как легковесная замена BPEL, почти всех интеграционных сервисов типа MAKE (ну, нужно только добавить средства преобразования данных). Ну и для AI-решений, куда же без них: описываем цепочку вызовов разных LLM.

Вообще идеи такие были и раньше: тот же BPEL и BPEL-for-REST, WS-CDL для SOAP, RESTalk — ну посмотрим, как заживет предложение от OpenAPI.

Продолжая тему образования. Я тут посмотрел подкаст Виктора Кантора MLinside про вход и развитие в сфере Machine Learning и Data Science. Гость — Алексей Толстиков, руководитель Школы анализа данных Яндекса (ШАД).

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

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

Понятно, что вход в ML непростой, в первую очередь из-за математики. Алексей в видео рассказал о некоторых особенностях обучения в ШАДе — и про суровый отбор, и про тяжесть обучения. Ну и 30 часов нагрузки в неделю — это не для всех.

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

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

Тут в основном только перечисления названий протоколов и технологий, но зато даёт общую картину. Это ещё круче, чем в предыдущем посте, тут есть и про выбор, и про синхронные-асинхронные способы, и про разные интеграционные стили. Что на картинке:

4 интеграционных стиля:
- файловый обмен
- общая БД
- вызов удаленной процедуры
- асинхронный обмен сообщениями

Или по другой классификации:
- Ресурсный стиль (REST)
- RPC-стиль
- Query-стиль
- Стиль Publisher/Subscriber

Технологии:
- REST
- SOAP
- GraphQL
- gRPC
- Webhooks
- WebSockets
- Long Polling
- AMQP (RabbitMQ и др.)
- MQTT
- Kafka
- Redis

...и связанные с ними вещи: форматы сообщений/сериализации, языки спецификации интерфейсов и схем данных, средства документирования и тестирования.

Это первый вариант, пишите, если есть предложения и замечания, буду в следующем году его развивать. Хочу, чтобы такой плакат висел в каждом офисе :)

Интересный флешмоб: лучшие доклады 2024 года (из тех, что в открытом доступе).

Целый канал под это! Если у вас найдется время на новогодних каникулах.

Мой вариант — доклад Романа Цирульникова "Модель архитектуры предприятия на графе" с весенней конференции Flow.

https://www.youtube.com/watch?v=cMQE_pXA260

(альтернативная ссылка в VK: https://vkvideo.ru/video-214741188_456239295)

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

Рекомендую посмотреть всем аналитикам для расширения понимания о том, что возможно.

#лучшийдоклад2024_arch #лучшийдоклад2024_analyst
#flowconf

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

А вот и итоги года! Кажется, получилось круто. И всё благодаря вам! 🙏🏻 Спасибо! Ваши подписки, реакции, комментарии, репосты — всё это очень поддерживает и вдохновляет! Спасибо вам!

В следующем году постараюсь радовать вас ещё больше качественным вдохновляющим контентом!

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

Короче, приветствую вас на канале, и буду стараться генерировать для вас интересный контент!

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

В общем, рад вас всех приветствовать на канале, enjoy yourself!

В комментах к посту про технологии интеграций просили картинку в виде pdf. Вот, держите: https://github.com/yksi12/integrations/blob/main/Integrations_tech.pdf

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

Кстати, если есть идеи, в каком инструменте было бы удобно эту картинку перерисовать — пишите в комментариях. А то в miro рисовать удобно, а вот экспортировать уже не очень.

Про рекламу. Реклама в канале есть. Не очень много — примерно 4 поста в месяц.

Других способов монетизации канала у меня нет — я не продаю вам свои курсы, не навязываю консультации и не беру денег за подписку. Хотя, возможно, стоит что-то попробовать :)

Реклама очень хорошо стимулирует меня писать посты, даже когда не очень хочется, и поддерживать регулярность. Обычно я пишу примерно по посту в один-два дня, когда выхожу на полную мощность. Удивительно, но почти всегда находится, о чем написать.
А с рекламой посты писать приходится — я считаю приличным, когда до рекламы обязательно есть пост, и после рекламы он есть. Две рекламы встык я не ставлю, я всё-таки не рекламная площадка. Некоторые рекламодатели почему-то любят размещение на час-два в топе — приходится закрывать постом. Не знаю, зачем они так делают, видимо, привыкли размещаться в каналах, где посты идут сплошной лентой в течение дня.

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

Так же я подхожу и к выбору рекламы. Я размещаю только то, что, как мне кажется, может быть полезно моей аудитории. В основном это анонсы каких-то мероприятий: курсов, конференций, вебинаров, вакансий и one-day-offer'ов. Иногда — реклама софта. Я довольно часто отказываю рекламодателям, если сомневаюсь, что реклама будет совсем мимо.

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

Также, я не отключаю эмоджи — если будут негативные, пусть будут негативные. Негатив можно обсудить, это тоже бывает полезно.

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

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

С маленькими каналами я не меняюсь, а просто регулярно даю возможность написать о себе — вот скоро как раз будет очередная такая акция :)) Кстати, я кажется задолжал общий пост про каналы подписчиков с прошлого раза — обязательно исправлюсь!

А вот к чему этот пост, вы уже наверное догадались: сегодня будет первая реклама, стартуем коммерческий год!

В схеме из поста приведена двойная классификация: с одной стороны, по книге "Паттерны интеграций корпоративных приложений" (Enterprise Integration Patterns, EIP) Грегора Хопа и Бобби Вульфа, там перечислены такие стили интеграции ("известные на момент написания этой книги", т.е. на 2003 год):

- Передача файла
- Общая база данных
- Удаленный вызов процедуры
- Обмен сообщениями

Собственно, авторы довольно быстро подводят к выводу, что стиль "обмен [асинхронными] сообщениями" самый лучший, и дальше всё разбирается в основном в отношении него. Хотя, конечно, многие паттерны довольно универсальны, т.к. представляют собой решения проблем, возникающих в любом проекте интеграций, безотносительно технологии, по которой он сделан.

Основанием для классификации в данном случае выступает природа канала, через который производится обмен, куда пишется сообщение: в файл на диске; в базу данных; никуда не пишется, а пакуется в TCP-пакет и летит по сети; или в промежуточную очередь/шину (в широком смысле — MOM: Message Oriented Middleware). Это всё логические абстракции, обусловленные программной обвязкой: строго говоря, база данных — это тоже набор файлов, как и журналы Кафки, например. Да что там, сокет TCP для операционной системы тоже файл, никакой разницы. В основе своей всё — файловый обмен :))

Книга EIP немного касается содержания сообщений, выделяя такие:
- Сообщение с командой
- Сообщение с документом
- Сообщение о событии
- Запрос
- Ответ (подтверждение, результат, исключение)

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

Вторая классификация взята из книги Майка Амундсена и др. "Непрерывное развитие API" (Continuous API Management), написанной в 2018. В ней речь идёт не вообще об интеграции, а именно про API (сравните смещение ракурса за 15 лет!), и классификация стилей построена как раз на типах сообщений: что мы передаем и что ожидаем в ответ. В первой редакции отдельно про стили API не говорилось, они просто упоминались, как что-то известное. Во 2-й редакции — в 2021 году — появилась отдельная глава, там перечислены такие стили:

- Туннельный (это RPC — выполнение команды на удаленном сервере)
- Ресурсный (это "простой" REST, в первой редакции книги он называется "CRUD-over-HTTP")
- Гипермедиа (это HATEOAS из REST'а: не просто содержание ресурса, а также и необходимые ссылки для работы с этим ресурсом, связанные с ним ресурсы и даже, возможно, какой-то воркфлоу/код для обработки)
- Стиль запросов (это когда API предоставляет единую точку для выполнения произвольных запросов: GraphQL, SparQL, поисковые запросы через HTTP и т.п.)
- Событийно-ориентированный стиль (это и паттерн "издатель/подписчик", и вообще любая реализация асинхронного обмена).

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

Хуже того — мало кто знает, но у Хопа есть вторая книга: Enterprise Integration Patterns, Vol. 2: Conversation Patterns, вышедшая в 2019, не переведенная на русский, и содержащая как раз в качестве одного из паттернов тот же HATEOAS, например (в первой книге никаких упоминаний REST вообще нет, там сплошной SOAP).

Идея второй книги примерно в русле Амундсена — да и написаны они, видимо, примерно в одно время: кроме технических моментов, связанных с синхронностью/асинхронностью, гарантией доставки, преобразования данных, маршрутизации и т.п. в интеграционных взаимодействиях ещё имеет значение их последовательность, "разговор", "conversation".

У Хопа в второй части EIP появляются паттерны, обеспечивающие как раз этот разговор: оркестрация, хореография, гипермедиа, и новые паттерны, характеризующие стиль общения (например, поллинг и ретраи). В эту же сторону движется и OpenAPI Initiative со своим новым стандартом Arazzo Specification.

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