🔸 Как одно требование на интеграцию может превратиться в 10+ задач на разработчиков 🔸

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

Можно подойти к аналитике и декомпозиции поверхностно, создать и описать следующие задачи:

1. Дизайн экрана - изменения в связи добавлением функциональности.
2. Одна задача на Backend, на разработку метода API, который будут использовать приложения.
3-5. По одной задаче на каждый фронтенд (веб- / мобильные приложения).

Но это всего лишь группы работ, но не конкретные задачи на разработчиков.

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

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

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

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

Хочу поделиться им с вами в следующем посте 🙂

#ИнтеграцииGA

🤓 Я всё знаю 😞

Каждый раз, когда я приближаюсь к состоянию “я всё знаю”, это становится неприятной ситуацией, требующей срочного решения. Почему?

Это сигнал того, что я остановилась в развитии, ленюсь и больше ни к чему не стремлюсь. Знать всё просто невозможно.

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

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

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

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

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

А на какой стороне вы?))
Ставьте реакции:
🔥 - "Я ничего не знаю"
👍 - “Я всё знаю”

💡 Интеграции — это не магия, а навык. Технический навык системного аналитика, который открывает путь к самым интересным проектам и вакансиям.

🚀 26 июня стартует практическая программа по интеграциям от GetAnalyst. На ней мы поможем вам освоить этот востребованный навык и прокачать карьеру.

Вас ждет:
◽️ 10 живых онлайн-встреч с опытными системными аналитиками.
◽️ Работа над ОДНИМ проектом в течение всей программы.
◽️ Разбор всех этапов проектирования интеграций от А до Я на его примере.
◽️ Возможность задать вопросы и получить обратную связь от экспертов сразу.

👉 Узнать подробности о программе и записаться
🎁 При записи до 24 июня: самые выгодные предложения и дополнительное обучение по БД в подарок.

Есть вопросы или не уверены, что эта программа актуальна для вас?
Пишите @getanalyst или заполняйте анкету предзаписи на сайте. Мы свяжемся с вами и поможем оценить ваши текущие навыки и ответим на все вопросы!

📝📌 Образец по декомпозиции задач на Интеграции 📌📝

Рассказала теорию по декомпозиции задач на интеграции, теперь хочу продемонстрировать, как это работает на примере проекта #GABank - экранная форма для заполнения реквизитов на перевод юридическим лицам.

Frontend (пользовательские интерфейсы)

🟪 1. Дизайн UI/UX для web-, iOS, Android
Считаем, что подключаем интеграцию к экрану, который уже работал до доработок. То есть переводы между юрлицами уже можно делать неудобно, вводя все реквизиты вручную.

Теперь передаем дизайнеру информацию о том, что нам нужны выпадающие списки для автозаполнения остальных полей после выбора:
- ИНН + организации
- БИК + банка

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


По картинке со схемой дальше идут задачи на Frontend, а по факту я сначала делаю постановки задач на Backend.

Backend (сервер-приложения, БД и др)

⬛️ 2. Изменения в БД
Банковские переводы уже работали. Поэтому я считаю, что база данных “как есть” для хранения сведений, которые будем получать из DaData, подойдёт нам и в текущем виде - уже есть таблица своих и чужих компаний, можно только отметки “синхронизировано с DaData” добавить в обе таблицы с компаниями, но смысла не вижу. Описывала БД здесь.

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

А еще может быть задача на добавление поля external_id в существующую таблицу (идентификатор записи во внешней системе), когда надо сохранять данные из внешней системы, чтобы знать источник - откуда мы это взяли и как проверить. Но у DaData нет своих id для компаний, они их не возвращают в ответе, только ИНН. Так что дорабатывать БД не надо. Ура.


#ИнтеграцииGA
Продолжение скоро 👇

📝📌 Образец по декомпозиции задач на Интеграции - часть 2 📌📝

⬛️ 3. Новый сервис
Для #GABank не нужен, так как решили работать в монолитной архитектуре. Но бывает, что интеграции нужно выносить в отдельные сервисы или микросервисы.

Примеры:
+ сервис уведомлений с интеграциями к системам push, sms, email;
+ сервис с однотипным набором интеграций, например для сравнения цен на отели интеграция с 10-ками систем, где есть возможность забронировать номер, у которых примерно одинаковая логика работы.


🟪 4. Настройка конфигураций
Для интеграции с DaData необходим минимум конфигураций, которые надо будет настроить в системе:

+ Сохранить базовый URL системы для выполнения запросов

POST http://suggestions.dadata.ru/suggestions/api/4_1/rs/findById/party

(документация)

POST http://suggestions.dadata.ru/suggestions/api/4_1/rs/suggest/bank

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

Для разных API DaData сохраняется одинаковый адрес:

http://suggestions.dadata.ru/suggestions/api/4_1/rs

Его можно внести в конфигурацию. Осторожно учитывать версию API. То, как внешняя система работает с версионированием методов может повлиять на то, можем внести версию в постоянные конфигурации или нет.

+ Сохранить в хранилище ключей или в конфигурации API-ключи для продакшн и для теста.

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


⬛️ 5.1. Разработка механизма авторизации
Для DaData механизм авторизации заключается в подстановке постоянного API-ключа из хранилища ключей в Header запроса “Authorization”.

#ИнтеграцииGA

Далее про авторизацию, доработки интеграционных API-методов и Frontend 👇👇👇

📝📌 Образец по декомпозиции задач на Интеграции - часть 3 📌📝

⬛️ 5.1. Авторизация - продолжение👇
Нужно подготовить отдельную статью на разработчика, с этим описанием: как проходит авторизация запросов в DaData.

А реализацию он может сделать вместе с реализацией первого интеграционного API-метода (п. 6). Мельчить задачи не нужно.

А для OAuth 2.0 у внешней системы, например, всё сложнее))


⬛️ 5.2. Разработка механизма ре-авторизации (повторной авторизации)
Для DaData это не актуально, так как API-ключ постоянный.
Это, кстати, причина, почему мы не можем напрямую обращаться с frontend в DaData, т.к. этот секретный API-ключ могут отследить через консоль, украсть, и начать расходовать наши лимиты платных запросов((


🟪🟪 6. Интеграционные API-методы
Вызов API будет в трех местах:

6.1. Вызов интеграционного метода REST API GABank на получение организаций по ИНН. После вызова метода необходимо будет проверить внутреннюю базу на наличие организации по ИНН + добавить к ней ответы из внешней системы DaData.

POST http://suggestions.dadata.ru/suggestions/api/4_1/rs/findById/party

(документация)

6.2. Вызов REST API GABank на получение банков по БИК. Как в п.1, но под капотом вызов другого API-метода внешней системы.

POST http://suggestions.dadata.ru/suggestions/api/4_1/rs/suggest/bank

(документация)


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



Возвращаемся к Frontend

🟪🟪🟪 7. Задача на доработку web-, iOS, Android
Нужно поменять дизайн экрана и его поведение при вводе ИНН + БИК на основе ранее созданных макетов UI/UX (п.1) и подключить интеграционные API-методы (п.6).



Готово!
Получилось 7 полноценных задач для одного простого требования.

Такие вот интеграции: “приключение на час”, которое оборачивается в кучу исследований от аналитика и большие работы со стороны разработки 🙌

#ИнтеграцииGA

🧡 Гайд по проверке API через Postman 🧡

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

Для этого нужно:

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

Для #GABank тестовый и боевой доступы к DaData не разделяются. При желании можно создать тестовую учетную запись в DaData и продуктовую.


2. Прочитать документацию "по диагонали" и найти важную информацию:
- Авторизация и аутентификация.
- Рекомендации по использованию API. Примеры сценариев использования. Это не всегда есть в API-документации. Но если есть, то считайте, что задача почти готова.
- Общие требования к обработке ошибок. Коды ответов.
- Список методов, необходимых для реализации интеграционных сценариев. Нужно понять, что методов для реализации бизнес-процессов в нашей системе достаточно.

Для интеграции с DaData все это описано в рамках отдельных документов (веб-страниц) по каждому методу.
🔗 Метод поиска компании по ИНН
🔗 Поиск банка по БИК


3. Протестировать API и понять как он работает. В основном для этого используют инструмент Postman. Для SOAP API - инструмент SOAP UI.

Для интеграции с DaData нам потребуется Postman.
🧡 Ссылка на гайд по тестированию одного из методов API DaData в Postman 🧡


Предлагаю посвятить сегодня 20-30 минут (или даже меньше), чтобы разобраться с двумя нужными нам методами API DaData и получить ваш опыт работы с инструментом Postman 😉🧡

#ИнтеграцииGA

Карьера может обеспечить до 70% того, что мы хотим от жизни: уверенность в завтрашнем дне, чувство востребованности, собственный дом, путешествия и хорошее образование для детей.

Она должна быть частью жизни, с соблюдением work-life balance (баланс работа-жизнь), помогая достигать целей и реализовывать мечты.

Для системных аналитиков карьера – это не только про деньги. Это про самореализацию, удовольствие от работы, новые знакомства, саморазвитие и вызовы самому себе. Мы проводим много времени в работе, и важно, чтобы она приносила удовлетворение.

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


Несколько рекомендаций, как развивать карьеру Системным Аналитикам:

🌱 Ставьте перед собой четкие цели:
+ Определите, чего вы хотите достичь в своей карьере.
+ Создайте план развития с конкретными шагами и сроками.

🌱 Постоянно учитесь и развивайте технические навыки, будьте в курсе новых трендов:
+ Участвуйте в конференциях и вебинарах.
+ Изучайте новые технологии, инструменты и методы работы.
+ Следите за экспертами в ИТ.
+ Получайте сертификаты.

🌱 Развивайте мягкие навыки (soft skills):
+ Коммуникационные навыки важны для успешного взаимодействия с командой и заказчиками.
+ Развивайте навыки решения конфликтов и переговоров.

🌱 Создайте личный бренд:
+ Делитесь своими знаниями и опытом на профессиональных платформах, таких как LinkedIn, Habr.
+ Пишите статьи, ведите блог или выступайте на конференциях.

🌱 Нетворкинг:
+ Стройте профессиональные связи с коллегами и экспертами в вашей области.
+ Вступайте в профессиональные сообщества.

🌱 Ищите наставников:
+ Найдите наставников, которые смогут направлять и поддерживать вас в вашем развитии.
+ Учитесь у более опытных коллег.


Главное – ставить цели, постоянно учиться и развиваться, следить за новинками в отрасли и учиться у экспертов. С такими усилиями успех неизбежен.

🔗 Backend: задача на интеграционный API-метод 🔗

В общем случае в интеграциях есть несколько слоев, между которыми "гуляют" данные:

🪄 Пользователь
🪄 Наше UI - приложение пользователя
🪄 Наше Backend-приложение + связанные БД, которое может добавить несколько слоев в сценарий работы системы, если это сервисная или микросервисная архитектура
🪄 Внешняя(-ие) системы.

Backend - самый интересный слой этого взаимодействия. Он пограничное звено между нашими приложениями пользователей и внешними системами, который реализует интеграционные методы и отвечает за:
✔️ Авторизацию запросов во внешнюю систему.
✔️ Алгоритм передачи и получения данных из внешней системы.
✔️ Вызов API-методов внешней системы.
✔️ Обработку данных и сопоставление их с БД системы.
✔️ Предоставление данных клиентам API (мобильным приложениям, сайтам, другим системам, которые могут вызывать нашу).

Интеграции через UI к внешним системам тоже делают, но очень редко, так как это может привести к проблемам с безопасностью при взаимодействии с внешними системами.


В постановке задачи на Backend для реализации интеграционного API-метода необходимо предоставить разработчику:

1. Название метода на русском
1*. Название API-эндпоинта

2. Общее описание, кратко: что это? для кого? почему мы это делаем?
2*. Архитектура взаимодействия компонентов системы в любой нотации (например, C4)

3. Сценарий работы - алгоритм, интеграционный Use Case для части Backend
3.1. Входные данные и результат (какие данные на выходе)
3.2. Алгоритм, включающий вызовы конкретных API-методов, требования к обработке ошибок и работе с БД
3.3*. UML-диаграмма

4*. Технические требования к методу API.
На примере REST API:
- тип метода (GET, POST…),
- URL (эндпоинт)
- JSON-ы запроса и ответа
- список кодов ответов HTTP

5. Маппинг данных:
+ БД
+ API внешней системы
+ разрабатываемый API-метод (из JSON или названия на русском из Use Case)

6*. Логирование

*Продвинутый уровень или не обязательная часть.


Предлагаю рассмотреть пример постановки задачи 🙂👇

#ИнтеграцииGA

🔔 Предзапись на практическую программу Интеграции закрывается сегодня.

Подробности тут.

Предобучение начинаем с 26 июня.

А завтра будет анонс открытого урока 😉

🧩 Маппинг данных - что это и зачем? 🧩

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

Этот процесс необходим в задачах на интеграции.

Маппинг описывают в виде таблицы. Допустимо делать и в виде структурированного списка, но по опыту скажу - таблицы удобнее.

🟢 В таблице с маппингом делают несколько основных колонок:

- название параметра на разговорном языке;
- описание, требования к валидации, ФЛК (форматно-логический контроль) и преобразованиям, если это необходимо;
- типы данных в каждой системе;
- названия параметра в API каждой системы (например, поле из JSON, поле из xml или другого формата сообщения, query из URL и др);
- название параметра в БД системы, которая отвечает за работу интеграции, если в процессе работы метода надо сохранить данные в БД.

Допустима вариативность с колонками. Их может быть больше, а может быть и меньше.


Если говорить про задачу интеграции банковской системы #GABank с DaData для получения данных о компаниях по ИНН, то маппинг будет содержать несколько колонок:

- название поля на русском;
- название поля в REST API системы банка, который создается для его веб- и мобильных приложений;
- название поля в БД банка, т.к. часть данных из DaData может далее сохраняться в БД;
- название параметра в HTTP API системы DaData, чтобы установить соответствие с её полями в интеграции;
- описание и требования к обработке и проверкам.
- типы данных в API банка, API DaData и БД банка. Я бы добавила только отдельную колонку “Тип данных в БД”. Все остальные типы данных очевидны. Но зависит от опыта команды. Чтобы наверняка не получить вопросы - лучше по всем частям прописать типы данных в таблице маппинга.


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

#ИнтеграцииGA