Телеграм канал «Наташа Косинова. Варю айти СУП»

Как я проектирую интеграцию.

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

✅1.Первое с чего я начинаю, я собираю всю информацию. Всё подряд. Скидываю всё вмесие. Собираю спецификации, если есть бизнес требования, бизнес процессы, архитектуру, окружение и изучаю. Не каждому подойдёт такой первый пункт, потому что с большим объёмом информации без структуры сложно. И можно упасть на дно. И тем более сложно выстроить свой вижен по разным уровням абстракции.
✅2.Дальше, я рисую диаграмму компонентов uml, фактически это третий уровень в C4. Мне важно понимать, кто какие интерфейсы предоставляет, а кто использует и какие технологии у нас есть, как мы передаём данные. Тоже до неё может быть ещё несколько других диаграмм и циклов изучения. Можно начинать с DFD, или первого уровня С4.
✅3.Изучаю API, если они есть, то замечательно. Я могу визуализировать API в виде диаграммы, я её называю "точки интеграции", пытаюсь понять сервисы API, кто за что отвечает. Подёргать, посмотреть, что в реальности есть, как работает.
✅4.Понимая процесс, сразу рисую sequence диаграмму. Не все могут сходу нарисовать sequence, это нормально. И можно брать дополнительные инструменты, которые шаг за шагом помогут сделать срез информации.
✅5.Описываю диаграмму статусов объектов, которые участвуют в информационном обмене. Опять же тут уже у голове должны быть процессы. И модель предметки, которую тоже можно нарисовать, если сложно сходу выделить объекты, по которым идёт информационный обмен.
✅6.Изучаю, как ошибки, описанные в API нужно обработать, как администрировать интеграцию.
✅7.Возвращаюсь к sequence и дорабатываю. На самом деле к sequence я могу возвращаться много раз)) это ключевой артефакт и в него я могу добавить моменты, связанные с работой с мастер-данными, с гарантированной доставкой, параметрами настройки интеграционного слоя. И конечно учитываю, как сценарий влияет на жизненный цикл объекта, какие статусы меняются и какие обновления, синхронизации данных необходимы. Как раз поддерживаю требуемое качество данных с помощью процессов в слое интеграции.
✅8.Перехожу к маппингу данных. Чаще всего я описываю, как заполнять поля сервиса из API, который мы например вызываем, по каким правилам происходит преобразование данных, где берем значения из настроек. Добавляю обязательно примеры реальных данных.
✅9.Если требуется, отдельно описываю алгоритм работы интеграционного модуля (если у нас шинная интеграция, например), в виде обычной активити диаграммы.
✅10.Перехожу к НФТ. Сюда относится безопасность, производительность, масштабирование, администрирование. Если есть числовые данные, указываю, если нет, пытаюсь посчитать и согласовать с разработкой.
✅11.Отдельно описываю логирование, мониторинг, квотирование. И могут быть различные специфичные требования от администратора, которому должна быть доступна возможность управлять всем этим богатством, и правильно реагировать на индиценты.
✅12.В дополнение всегда прикладываю спецификацию API, примеры реальных данных, явки и пароли тестовых стендов.

Очень кратко описала процесс, опуская детали.

Сегодня с 19:00 до 21:00 по Москве, на мастер-классе по интеграции мы пойдём по процессу проектирования интеграции, как по технологичному процессу.

❗Мероприятие платное, чтобы оставить заявку на участие, пишите мне в личку слово "Интеграция".

#системныйаналитик #интеграция #системныйанализ #мойопыт #выводы #анонс

💡Качество данных в интеграции

Вчера у нас в комментариях завязался интересный разговор про требования к качеству данных.

Зачем вообще нужно качество данных и как это относится к интеграции?
1️⃣Во-первых, данные это фактически "кровь" айти ландшафта, и тут как и с нашим организмом важен состав, объем, потому что прежде всего бизнес принимает решения на основе данных.
2️⃣Во вторых, данные нужны для проведения бизнес операций, если они неполные, то какие-то вещи попросту не будут работать. Это всё из разряда #капитаночевидность
3️⃣В третьих, в интеграции мы формируем ряд процедур, которые обеспечивают нам проверку, очистку, обогащение, стандартизацию, мониторинг, объединение данных.

Интеграция, это прослойка, перекладчик, набор процедур можно сказать, чтобы создать единое информационное пространство для поддержания бизнес-процессов. И тут важно понимать, с кем и как мы интегрируемся. Это как ворота с охранником, у него есть правила и регламент и он их придерживается))

Я собирала #грехианалитика и один из них звучал, как - "положиться на других", "довериться партнерам по интеграции".

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

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

✅1. Во первых, не забываем принципы СОА архитектуры, что все сервисы независимы друг от друга, и смотрят друг на друга как на черный ящик. Микросервисы это ребёнок СОА архитектуры.
✅2. Нам нужна гибкость решения, масштабирования. Сегодня наш партнер по интеграции Газпром, а завтра нет. На практике у меня за год сторонний сервис сменился 3 раза! Нам нужна независимая логика работы нашей внутренней кухни, без завязок на внешнее.
✅3. Очень важная вещь, о которой многие не думают. Это юридическая составляющая работы с данными. К сожалению, многие аналитики и вцелом айтишники не очень сильны в юридических нюансах (я сама такая же), но не стоит забывать, что работая с данными мы можем быть ограничены законами, регламентами. И если какая-то произойдёт, простите, жопа, придут разбираться на низкий уровень решения. И тут очень глупо говорить о том, что нууууу мы же завязали решение на нашего соседа по парте. А сосед скажет, у меня то всё хорошо, а это уже ваша зона ответственности.

📊Итого: решение интеграции - это всегда узкое горлышко, и делать его еще сложнее, завязываясь на сторонний сервис точно не нужно. Как пример, основу, взять конечно можно, так и делают, нужно же от чего-то отталкиваться, а вот объекты своего огорода, но составу и описанию могут быть совсем другими. И тут в помощь в том числе онтологическая модель предметки, даже в сокращённом варианте, уже принесёт помощь в проектирование.

✔️Уже в эту среду 25.03.2026 с 19:00 до 21:00 пройдёт мастер-класс по проектированию интеграций, как раз будем говорить про алгоритм действий, что и как необходимо сделать, чтобы спроектировать решение.

❗Мероприятие платное, чтобы оставить заявку на участие, пишите мне в личку слово "Интеграция".

#интеграция #качестводанных

В этот день год назад 24.03.2025 рассказывала почему в режиме стартапа мы нагородили интеграционный огород, который фонит более 10 лет

24.03.2024 я писала про названия систем, и откуда они берутся)

🔥Чек-лист интеграции.

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

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

--------------------------
1.  Определить системы, участвующие в обмене
2.  Описать потоки данных
3.  Понять наличие гарантированной доставки данных
4.  Описать регламент взаимодействия систем:
•  передаваемые данные
•  частота передачи
•  расписание
•  система-инициатор обмена
5.  Описать формат передачи данных:
•  Названия атрибутов
•  Тип, длина
•  Обязательность
•  Кодировка
6.  Зафиксировать маппинг данных из формата системы-источника в формат системы-приёмника.
7.  Понять в какой системе хранятся мастер-данные по объектам.
8.  Выявить необходимость преобразования/проверки на актуальность/обогащения данных.
9.  Зафиксировать протоколы обмена данными.
10.  Понять ограничения платформы/канала интеграции.
11.  Нефункциональные требования:
•  Выявить требования к скорости обработки и передачи данных.
•  Понять необходимость шифрования данных.
•  Оценить объем передаваемых данных.
•  Понять наличие ограничений на уровне регулятора (152 ФЗ, PCI DSS).
12.  Описать интеграционный сценарий взаимодействия.
13.  Понять способ взаимодействия – синхронное/асинхронное.
14.  Описать механизм обработки ошибок.
15.  Выявить требования к настройкам, администрированию, мониторинг, логирование, квотирование.
--------------------------

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

✔️Уже в эту среду 25.03.2026 с 19:00 до 21:00 пройдёт мастер-класс по проектированию интеграций, как раз будем говорить про алгоритм действий, что и как необходимо сделать, чтобы спроектировать решение.

❗️Мероприятие платное, чтобы оставить заявку на участие пишите мне в личку слово "Интеграция".

В этот день год назад 23.03.2025 я писала, о том как нагородили интеграционный огород)
#интеграция #чеклист

ПЕРЕНОС!!!

Друзья! Либо у меня окривели руки, либо с выкаткой нового функционала VK Video сломали запуск трансляций. Ставлю на второе, ибо уже даже и по инструкции сделал – всё равно не работает.

А нет трансляции – нет эфира.

В общем, переносим наш с Наташей Косиновой сегодняшний эфир про житиё аналитическое тяжкое предположительно на четверг, 26 марта, 18:00. Предположительно, так как вдруг не Вконтактике и не РКН, а отрицательная прямота моих рук? Но к четвергу и её исправим, ежели что – не впервой.

На таймпаде дату/время тоже поправил, как заработает VK Video – ещё раз вышлю напоминалочку.

Сорри за инконвиниенс.

👉 Об ИТ и менеджменте. Подписываемся и пересылаем друзьям

Решение в бизнес-анализе VS в системном анализе

Очень часто я писала, про то, что системный аналитик формирует и формулирует требования и не стоит обсуждать с заказчиком решения. В ТЗ описывается решение на языке требований.

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

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

Например, у нас кофейня, и наш бариста проводит оплату мимо кассы. Что мы можем сделать?

Можем написать "вам не дали чек, сообщите нам, и получите кофе за наш счёт", можно поставить камеру, как элемент контроля. Или сделать оплату только безналичную. Может ещё какие-то варианты...

То есть бизнес решение - это набор процедур, которые описывают как мы будем реорганизовывать деятельность.

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

Бизнес аналитик - анализирует как выстроена деятельность, между кем и кем она разделена, как выстроены отношения между участниками деятельности, и нужны ли нам технические инструменты (ИТ решения), и под какие функции.

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

#бизнесрешение #бизнесанализ

Внезапное аналитическое. Уже сегодня

20 марта 2026 года в 17:30 погрузимся во внутреннюю кухню проектов: поговорим о том, как правильно выстроить работу аналитиков на проекте и каких ошибок нужно избегать.

Совместный эфир Тараса Сороки – эксперта по управлению ИТ и цифровой трансформацией, ведущего канала Сорока пишет | Об ИТ и менеджменте и Натальи Косиновой – эксперта в системном и бизнес-анализе, автора тренингов для аналитиков и ведущей канала Наташа Косинова. Варю айти СУП.

C толком, с чувством, с расстановкой пройдёмся по всем граблям, по которым ходят проектные команды в своём взаимодействии с аналитиками:

➡️ отсутствие аналитика! Руководитель проекта пишет ТЗ самостоятельно;
➡️ хороший руководитель проекта с точки зрения аналитика – какой он?
➡️ аналитик – товарищ руководителя проекта или заноза у него в ж?… Роль аналитика на проекте;
➡️ коммуникация с разработкой. Что делать, если разработка воспринимает аналитика в штыки?
➡️ коммуникация с заказчиком. Как не пообещать лишнего, не имея полномочий?
➡️ управление скоупом проекта. Впихиваем невпихуемое – роль аналитика в этой активности;
➡️ управление рисками проекта – командная работа аналитика или РП;
➡️ смена стейкхолдера. Переписывать ТЗ полностью, или, может, обойдётся?

Подключайтесь, будет познавательно.

👉 Об ИТ и менеджменте. Подписываемся и пересылаем друзьям

‼️К сожалению завтра 19 марта, не будет семинара в Лаборатории Системного анализа, мы его переносим, о новой дате сообщим заранее.
Просим прощения, за такую накладку.