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

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

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

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

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

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

Многие смогли понять свои проблемы и написать план собственного развития и мощно обновили свои базы знаний 📈

Приходите к нам на интеграцию ➡️ https://sup.expert/

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

Через 2 недели стартует, последний в этом году, поток интеграции.
Вас ждёт аналитический марафон в 2 месяца! ✅

-------------------------------
Курс интеграции состоит из 8 блоков и разделён на два этапа:
Первый 🎯 - это проектирование интеграционного решения от концепции до уровня данных (блоки с 1 по 4).
Блок 1 - отвечаем на вопрос, что такое интеграция, строим С4
Блок 2 - use cases, онтологическая модель предметной области, state machine
Блок 3 - sequence, мастер данные, гарантированная доставка, обработка ошибок, валидация данных
Блок 4 - словарь данных, маппинг данных, администрирование, activity

Второй 🎯 - разбор технологий передачи данных, паттернов интеграции, шина и брокеры (блоки с 5 по 8).
Блок 5 - введение в OSI модель сети, REST API, json
Блок 6 - SOAP, xml
Блок 7 - graphQL, gRPC, логирование, мониторинг, квотирование, безопасность
Блок 8 - Паттерны интеграции, шина, брокер

-------------------------------
Кому подойдёт курс?

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

Если вы аналитик с опытом от 3 до 5 лет, курс поможет систематизировать знания понять свои пробелы, увидеть эволюцию проектирования, что в конечном итоге позволит вам выйти на новый уровень, составить план развития, а может и сменить работу (такие прецеденты у нас уже есть))).

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

Формат курса - онлайн занятия, приближенные к классической схеме обучения,
✅в четверг лекция (утром по Москве с 9 до 11),
✅во вторник семинар - разбор домашних заданий (утром по Москве с 9 до 11).

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

Сколько сможете унести знаний зависит только от вас))
Многие ребята пересматривают записи занятий и узнают снова и снова что-то новое.
➡️ Презентации
➡️ Материал
➡️ Видео записи занятий остаются у вас навсегда!

Мы предлагаем разные тарифы обучения:

Можно прийти на тариф "только послушать", участвовать в онлайн формате в обсуждениях, интерактивных практиках.

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

Мы специально проводим занятия в утреннее время в будние, чтобы вы со свежей головой смогли разобраться в сложной системной информации. Учиться и работать одновременно это действительно сложно, поэтому мы стараемся создать условия, чтобы вы успешно прошли весь аналитический марафон вместе с нами)) Каждый новый поток для нас, как новый вызов!

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

Ведущие:
Основные лекции по проектированию провожу я, Косинова Наталья, мой опыт интеграции более 15 лет, восновном шинная интеграция проектов Билайн, Тинькофф, А3, МТС, Госсектор, Утконос и другие.

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

Чтобы записаться на курс оставьте свою заявку на нашем сайте ➡️https://sup.expert/

Если у вас остались вопросы, пишите в комментариях, я обязательно отвечу 🔽

До встречи на занятиях!
#анонс #курсинтеграции #интеграция #системныйаналитик #системныйанализ #мойопыт

Аналитик, догони разработку!

Часто аналитик попадает в ловушку под названием "разработка опережает анализ".

При этом аналитик начинает летать в облаках "вот, вот, я сейчас поднажму и всех догоню!", ага, ага, плавали знаем... Турбо ускорителя у меня нет, да думаю и у вас тоже нет, у меня ни разу не получалось.

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

А ещё к этому добавим ситуацию "я один аналитик на проекте и мне нужно догонять" 😵‍💫 и он превращается в тестировщика, технического писателя, не может раскрыть весь свой потенциал, а может грешным делом думает, что всё в порядке, но тайно вечерами мечтает уволиться.

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

Я сама попадала в такие ситуации, при этом мой непосредственный руководитель считал, что всё хорошо.

-------------------------------
Что можно с этим сделать:

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

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

✅ аналитик помогает ускорить процесс разработки (на моем опыте, команда с хорошим аналитиком начинает "съедать" backlog задач быстрее в 2 раза)

✅ признаться аналитику, что вам нужен тестировщик или технический писатель, а что?)) может правда нужны другие специалисты

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

Иногда стоит просто открыть рот и начать говорить, о том, что что-то не так. И просить изменить процесс.

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

А тут, глядишь и оценка сроков станет более чёткой)))

Сплошные плюсы, а всего лишь, всё расставили по своим местам))

#мойопыт #системныйаналитик #системныйанализ #больаналитика #управление #смертныегрехи #догониразработку

Как выбрать паттерн интеграции?

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

➡️ Один из ответов, к сожалению, звучит так - потому что так сложилось. 🤷‍♀ Действительно, часто нет логического чёткого объяснения почему так. Потому что наш директор поехал на презентацию, там выпил водки и купил лицензию по шине, а теперь нам с ней работать. Занавес.


➡️ Следующий ответ звучит, как - а мы только так можем, и никак по-другому. Действительно, команда просто по-другому не умеет, и делает так, как привычно. Нет компетенций, опыта, бюджета на новое, на обучение. Всё что угодно. Оно работает? Работает. Тогда не ломай, не трогай.

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

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

Какие есть Паттерны?
По способу передачи данных:

Обмен данных с помощью
✅ файлов
✅ общей базы данных - это антипаттерны интеграции, от них лучше уходить.

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

И остаётся чаще всего применяемые паттерны -
✅ удалённый вызов процедур
✅ обмен сообщениями (шина, брокер).

Удалённый вызов процедур - по сути онлайн обмен между двух систем, которые соединены напрямую, через API.

Брокер - это работа с абстракцией в виде очереди, которая может быть реализована по-разному (например, на основе протокола AMQP).

Шина - это швейцарский ножик, который вбирает в себя все Паттерны и нюансы управления интеграционным слоем.

Шина с централизованным обменом данных является одним из паттернов SOA архитектуры.

Брокер может быть с очередями частью шины или способом передачи сообщений в микросервисной архитектуре.

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

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

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

Почитать про курс можно вот тут ➡️ sup.expert

#курсинтеграции #курс #системныйанализ #паттерныинтеграции

⚡️Остались вопросы или вы хотите записаться, пишите напрямую мне))

Реальные результаты наших участников курса интеграции.

В большинстве своём на курс приходят ребята, кто был у меня на менторстве, оно и понятно, но и не только! У каждого свои цели. И вот немного классифицирую, по грейдам, кто что уносит и использует на практике:
1.Начну с джунов или тех кто хочет стать системным аналитиком. Очень сложно бывает показать, что именно нужно специалисту для прокачки. Курс интеграции, как курс молодого бойца показывает систему знаний, инструментов, подходов и практик. Что хорошо, мы полностью проходим по пирамиде артефактов и доходим до уровня технологий, данных. Я не хочу давать обещания, которые считаю нереальными. Но то, что джун поймёт, куда ему дальше и что такое системный анализ это точно.
2.По результатам курса можно написать свой собственный план развития, и взять за основу те ссылки, те внешние источники, книги которые мы рекомендуем, и на которые опираемся.
3.Миддл аналитики обретают уверенность! Это очень важно. Они могут чего-то не знать, но понимать объем, границы задачи и чувствовать себя увереннее. Понимают, куда смотреть, что делать.
4.Как так уже давно получилось, что я стала для многих "карьерной феей"))) Ребята после работы со мной идут дальше, есть даже те кто вырос в айти директора, кто-то в архитектора, тим лида. И вот по результатам наших даже двух потоков курса, много кто сменил работу! Пошёл выше по грейдам, прибавил в деньгах. Как говорит Андрей Корниенко, у аналитиков открылись глаза и поняли, что именно они должны делать, отсюда уверенность, энергия перемен и попытка дальше себя развивать, для этого меняют среду. Мы ничего специально не делаем, так получается))) А то компании, чего неладное подумают))
5.Многие отмечали такой факт, что стали увереннее на собеседованиях и смогли ответить на каверзные вопросы. Или честно сказать, что они и в каком объёме могут сделать.

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

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

Приглашаю вас присоединиться к группе, старт уже завтра! В новый год вы вступите с новыми знаниями))

#системныйанализ #курс #курсинтеграции #анонс #результатыучастников #интеграция

Остались вопросы, пишите мне‼️

⚡️Сбор требований, это не ядерная физика!

Хуже, когда тебе нужно собрать требования в ядерной физике 🤯

Что же поможет аналитику при работе с требованиями?

✅Первое, это начать замечать уровни требований. Чтобы заметить проблему, её нужно сначала просто назвать. Тут поможет пирамида артефактов, дополнительные вопросы.

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

✅Третье, это абстрактное мышление. До сих пор ведутся споры, что такое мышление, а тут ещё и абстрактное. Но действительно оно есть, способ думать так, чтобы минимально опираться на самое решение, разработку. Это действительно сложно. И подобный навык дают технические вузы, но как любое мышление, абстрактное мышление можно развивать.

✅Четвёртое, логика и взаимносвязи наших требований. Тут помогут знания по формальной логики, теория по пирамиде Минто, теория графов, математика. Но я бы ещё добавила и философию. Всё в системе даёт результат.

✅Пятое, банальные вещи, опыт, насмотренность, вопросы старшим коллегам, активность. Да и просто иногда нужно делать, как другие.

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

✅Седьмое, понимание, когда нужно остановиться. Чем больше требований вы описываете на низком уровне, тем больше падает качество результата.

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

✅Девятое, soft skills, никто не отменял. Адекватность, умение открыть рот и начать говорить, кажется очень простым навыком, но по факту, это нефига не просто.

#требования #системныйаналитик #работастребованиями #чеклист #системныйанализ #моемнение

А что вам помогает в работе? Пишите в комментариях 👇