В общем, после новинок от OpenAPI Initiative, набор стандартов, языков и спецификаций в области интеграций выглядит совсем уж запредельно 🤯

Итак, что вам нужно знать, чтобы разбираться в интеграциях в 2024:

🔲 JSON — язык разметки, чтобы читать и писать тела запросов и ответов в вызовах API
🔲 JSON Schema — чтобы описывать структуру JSON и валидировать документы
🔲 RegEx (ECMA-262) — чтобы задавать ограничения на формат для строковых полей
🔲 HTTP/1.1 — базовый протокол, нужно хотя бы понимать структуру запроса (метод, домен, путь, параметры, заголовок, тело, ошибки)
🔲 YAML — язык разметки для чтения и составления спецификаций OpenAPI
🔲 OpenAPI — собственно, стандарт для описания REST-подобных API.
🔲 XML, XSD — если вы работаете с государственными сервисами
🔲 WSDL — если у вас есть интеграции через SOAP
🔲 AsyncAPI — если у вас есть асинхронные интеграции, брокеры сообщений, очереди. Между прочим, уже версия 3.0.0 вышла, зрелый продукт!
🔲 AVRO — формат данных, часто использующийся в Kafka. Схема AVRO может быть включена в спецификацию AsyncAPI
🔲 OAuth 2.0 — протокол аутентификации авторизации

Про что нужно знать, что они есть, и рассматривать при необходимости:

🔲 Protobuf — формат данных gRPC, также может использоваться в Kafka, схему можно включить в AsyncAPI
🔲 JSON-RPC — легковесный формат вызова удаленных процедур через HTTP
🔲 GraphQL — формат описания схемы данных и язык запросов
🔲 TypeSpec — легковесный формат описания API, из которого генерируется спецификация OpenAPI (вот это я бы рекомендовал посмотреть — объем документа там в разы меньше, чем у OpenAPI)
🔲 XSLT — если вам приходится преобразовывать документы XML
🔲 JSLT или JSONata — как XSLT, но для JSON: языки запросов и преобразований
🔲 JSONPath — язык запросов к документу JSON

Для продвинутых и тех, кто занимается управлением API:

🔲 Модель OSI или TCP/IP — что происходит в сети на уровнях ниже HTTP
🔲 HAL — формат сообщений JSON, если вы хотите больше следовать принципам HATEOAS из REST
🔲 JSON:API — стандарт на формат сообщений (тоже в русле идей HATEOAS) и некоторые принципы формирования запросов
🔲 API Design Systems — язык спецификации правил для построения API (можно валидировать любое API в компании)
🔲 RFC 9457 — спецификация детального описания ошибок в ответах HTTP
🔲 JSON-Patch, JSON-Merge — форматы описания изменений документа JSON, то, что должно отправляться в команде PATCH
🔲 Overlay — спецификация изменений в документ OpenAPI
🔲 Arazzo — спецификация последовательности (воркфлоу) вызовов нескольких API

Вот, приятного чтения на каникулах 🙂 Специально поставил иконку пустого чек-бокса — можете мысленно отметить, что из этого вы уже знаете и с чем работали. 🧘‍♀️

Йу-ху! Вот это круто год начинается! Пока канал был на новогодних каникулах, к нему присоединились почти 400 человек!
Спасибо вам, и добро пожаловать!

Давайте я представлюсь: меня зовут Юрий Куприянов, и я аналитик, нет, на самом деле я никогда не был аналитиком. Ну, то есть, моя должность так никогда не называлась. Я был экспертом, разработчиком, советником (это было самое лучшее время!), начальником управления технологической документации и проектирования архитектуры, а потом директором по тому и по сему (по продуктам, по технологиям и развитию, техническим директором и т.п.)

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

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

Преподавать в институте я начал ещё в 2006 — очень хотелось хотя бы 50-60 людям рассказать, как на самом деле устроена разработка и что нужно знать и уметь кроме, собственно, знания языков программирования и алгоритмов. А к 2012 уже хотелось всем рассказать, как должно быть устроено преподавание и обучение 😝 Тогда же я начал вести курс в Школе системного анализа, известной теперь как Systems.Education. И знаете, что? Когда пытаешься объяснить другим, как правильно делать какую-то работу — гораздо лучше сам понимаешь, как её делать 🙃 Ну и когда через тебя проходят десятки и сотни людей, понимаешь, что ошибки у всех примерно одни и те же.

Если говорить про конкретные проекты:
➡️ я спроектировал и лично запрогал систему автоматизации казначейства Газпромбанка (интересно, она доработает до своего 20-летия, или её уже всё-таки перепишут?..);
➡️ я сопровождал проект замены технологической платформы Национального расчетного депозитария (когда это ещё не было модно, а слово "импортозамещение" вообще не было популярно);
➡️ я делал стартап по онлайн-трансляциям и пилил что-то типа Зума, но не сложилось;
➡️ спроектировал для Сбера платорму "СберИдея" (впрочем, кажется, они её уже переписали);
➡️ спроектировал и запустил платформу "Открытое образование" (openedu.ru);
➡️ спроектировал сервис coreapp.ai;
➡️ спроектировал первую версию системы для обучения цифровым профессиям за счет государства (ну и к другим проектам "Университета 2035" руку приложил);
➡️ пытался сделать что-то удобное и полезное из "Московской электронной школы", но это оказалось выше моих возможностей, к сожалению.

Я тусил с Левенчуком, когда все системные инженеры в России как раз помещались в одной переговорке в офисе "Техинвестлаба". Потом даже немного побыл членом INCOSE и поучаствовал в переводе "Руководства по написанию требований".

Я участвовал в первых форсайтах про образование, и написал несколько глав в методичку по технике Rapid Foresight.

Я выступал почти на всех крупнейших ИТ-конфах, на ЛАФе и AnalystDays делал лучшие доклады. Сейчас я состою в ПК аналитических конференций ЛАФ, Flow и WAW, и уже сам отбираю лучшие доклады для вас.

Участвовал в написании ГОСТ Р 59897-2021 "ДАННЫЕ ДЛЯ СИСТЕМ ИСКУССТВЕННОГО ИНТЕЛЛЕКТА В ОБРАЗОВАНИИ" и профстандарта "Системный аналитик" (второй редакции), был трекером в заочке ФРИИ (недолго), написал часть книги "Цифровое качество: свод знаний по цифровой трансформации" (или "Управление качеством цифровых продуктов и проектами цифровой трансформации" — она же в виде учебника).

Первым, кажется, попробовал применять LLM для генерации и анализа требований, и всем про это рассказывал, где только мог.

Вау! Вас уже больше 8 тысяч, дорогие читатели, и это круто! 🎆

Большое вам спасибо за доверие и интерес! 🤝

А вот вам по случаю круглого числа немного статистики. Мне давно уже было интересно — а сколько нас всего — в смысле, сколько системных аналитиков в РФ, ну или тех, кто так или иначе причисляет себя к ним? По оценкам, которые мы делали разными способами, получалось, что примерно 30-40 тысяч.

И вот, наконец, я нашел источник, на который можно сослаться! НИУ ВШЭ публикует ежегодный статистический сборник "Индикаторы цифровой экономики", и там есть данные по занятости в ИТ, а среди них есть системные аналитики! Сейчас опубликованы данные за 2022 год, их и будем смотреть.

Так, всего в ИКТ на 2022 год занято почти 1,9 млн. человек, из них разработчиков и аналитиков программного обеспечения и приложений — 761 тыс. (в 2021 было 800 тыс., между прочим). Такие дела, нас считают вместе с разработчиками.

Так сколько же именно аналитиков? Из этих 761 тысячи — 4.6%, то есть 35 тысяч!

Вот так, всего-то. То есть, если считать, что тут у меня только системные аналитики, то это было бы 22,8% всех системных аналитиков в РФ! Но тут, конечно, не только системные аналитики, я-то знаю :) Кстати, надо будет сделать опрос, очень интересно.

Что ещё можно вытащить из этих данных? Ну, например, теперь мы знаем среднее соотношение: на одного аналитика приходится примерно 21,5 разработчиков. Ну, это лукавая цифра, конечно — скорее, это говорит о том, что во многих компаниях разработчики работают без аналитиков вообще. Экспертно мы всегда оцениваем примерно как 1/10.

А вот, например, про дистанционную работу: 27.5% людей в ИТ работают дистанционно по состоянию на 2022 год. Теперь мы знаем точно, что не все и даже не половина.

Генерирует вся эта шняга около 3% ВВП в год, или 4,2 трлн. руб. в абсолютных числах. Из них, правда, чисто софт — всего 1,9 трлн. Зато рост цен на разработку и приобретение ПО в 2022 году — 35%! (в предыдущие годы был 3 и 7). И средняя зарплата теперь 151 тыс. (сравните со своей, на всякий случай).

Вот такая интересная статистика.

Ещё интересные данные про пользователей, чтобы вы не очень на их навыки рассчитывали.

Вот как вы думаете — какой процент людей в возрасте от 15 лет может отправить электронное письмо с вложением? А сколько процентов владеют искусством копирования и вставки в электронных документах? И какой процент людей может изменить настройки доступа к какой-нибудь информации? (в тексте почему-то "настройки доступа к учетной записи", я не понимаю, что они имеют в виду). Пишите в комменты!

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

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

Часто при обсуждении смысла и ценности роли аналитика (особенно системного аналитика!) говорят про снижение неопределенности. Это такой типовой ответ.

Хуже того — даже в профстандарте это есть! Аж в четырех местах:

"...определять задачи на доработки, устранение противоречий и неопределенности"

"...определять [..] уровень оставшейся неопределенности [после сбора данных]" и "собирать данные о неопределенности (нехватке информации, источников данных, проектных решений)" (не перепутайте!)

"Анализ последствий выявленной неопределенности"

Вот только это слово "неопределенность" само по себе содержит неопределенность. Какую именно неопределенность мы имеем в виду? Я люблю переводить всякие слова с одного языка на другой. Например, на английский — он интересен тем, что "сделан" примерно из 3-4 разных языков, и в нём, скорее всего, одно слово на русском превращается в несколько с чуть разными значениями. Помню, на экзамене нужно было перевести статью с названием "Precision And Accuracy", чуть не засыпался сразу на названии; и так со многими словами — efficiency, efficacy и effectiveness, например.

Так вот, неопределенность по-английски бывает:

🤷🏼‍♂️ uncertainty — это "неуверенность", нехватка информации — либо о том, что есть; либо о том, что будет (к чему приведет то или иное решение). Скорее всего речь идёт об определенных состояниях, но мы не знаем, какое выбрать. Если пытаться это измерять, то получится перечень возможных состояний, их вероятности и график распределения плотности вероятности (например, как в этом посте — мы не уверены в дате окончания работ, но можем её оценивать). Эта неопределенность связана с понятием риска. И с понятием выбора. То есть, не то что мы не знаем, что вообще может быть — мы, скорее всего, знаем, какие есть варианты, но не можем выбрать один из них.

🤌 ambiguity — это "неоднозначность", "двусмысленность" — это как раз про неопределенность результата. Не то, что мы выбрать один из вариантов не можем — мы вообще не понимаем, чем эти варианты отличаются. Или не понимаем, чем отличаются исходные параметры. Или разные участники понимают их по-разному.

😶‍🌫️vagueness — это "нечеткость", слышали про нечеткую логику? Это про граничные кейсы и разделение двух концептов или статусов. Когда мы четко не можем отделить одно от другого. Что значит, например, "человек посетил доклад"? Слушал от начала до конца? Начал слушать, но потом ушел? С середины ушел, или почти сразу? А если наоборот — зашел на середине и остался? Или ближе к концу пришел? Или заходил пару раз, постоял у дверей, и вышел? Ничего не понятно, а в аналитике его посчитать как-то нужно.

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

Можно сказать, что я душню, но эти различия важны: к их решению нужно подходить по-разному.

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

ambiguity устраняем понятно как — через определение общего языка, прояснение концептов, а если не выходит — через изоляцию их в разных частях системы — привет DDD.

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

В общем, говоря про неопределенность, желательно определиться — какой именно её вид вы имеете в виду.

Почему-то вспомнил сегодня задачку от Сергея Нужненко: описать входы и выходы стиральной машины. Такая типовая задачка для аналитика/проектировщика систем.

Подвох в том, что многие забывают то водоотведение, то электричество. Ну, опытный аналитик это всё учтет, конечно.

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

⚖️ машина имеет вес и центр тяжести, она давит на то, на чем стоит. При этом вес и центр тяжести разные в разных режимах. У машины есть допустимые углы наклона, при которых она сохраняет работоспособность и остается безопасной;

📳 машина подвержена вибрации и сама производит её, причем это тоже зависит от входа (вида и объема загрузки) — у всех, наверное, машина прыгала или даже падала, если узкая; у неё в целом есть резонансная частота и у отдельных её деталей есть свои частоты (например, у стекол и печатных плат — при входе в резонанс они могут треснуть); для крупных деталей с большой массой эти частоты не очень-то велики — поэтому у всех машин есть специальный режим для транспортировки;

🧲 машина подвержена электромагнитным излучениям и сама создаёт их;

🔨 машина подвержена внешним механическим воздействиям и имеет некоторую прочность;

💧 машина подвержена воздействию пыли и влажности; влажность она также может создавать сама;

♨️ машина подвержена воздействию тепла и создает его (это один из выходов);

🕶 машина подвержена воздействию ультрафиолета;

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

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

Наш преподаватель про неё говорил так: у вас нет предмета "сопромат", который "сдал сопромат — можешь жениться", но есть конструирование. Я вам гарантирую, что это не хуже.

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

Примерно тогда у меня произошел один из моментов сатори — внезапного просветления — когда препод спросил на защите "А как выбор корпуса обусловлен планируемым годовым объемом выпуска устройства?" — тут-то я и понял, что всё со всем связано. Это потом сильно помогало в системном анализе.

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