Для системного аналитика важно понимать, как проектировать интеграции:
🔹 исследовать API,
🔹 разрабатывать сценарии работы системы, встраивая в них вызовы соответствующих API методов,
🔹 описывать архитектуру,
🔹 разрабатывать маппинги данных,
🔹 проверять как работает API внешних систем, используя Postman, чтобы лучше разбираться в технических деталях,
🔹 как документировать требования и ставить задачи.

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

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

👉 25 часов онлайн-практики в течение 2-х месяцев, где вы задаете вопросы и получаете ответы!
👉 Обратная связь по вашей работе онлайн с экспертами и обратной связью сразу, в моменте: мы даем теорию и пример, вы решаете задачу, и мы даем направление, чтобы у вас всё получалось самостоятельно!

Hard-skills по интеграциям и пониманию базовых принципов архитектуры систем - важнейший шаг для карьеры системного аналитика. Возможность освоить новые навыки на практике 👇

🗓 Предзапись на специальных условиях открыта до 10 декабря

Пример архитектуры MSA для проекта GetDelivery 👀📌 Этот пост надо сохранить!

Для проекта GetDelivery один из вариантов микросервисной архитектуры (MSA) может быть реализован так, как показано на приложенной схеме. Загружайте себе файл с примером и изучайте.

Сразу хочу заметить, что при детальном знакомстве со схемой, чистой микросервисной архитектуры вы не найдёте.

В проектах, с которыми я работала, были такие комбинации:

- Монолит,
- Сервисы,
- Монолит + Сервисы,
- Монолит + Микросервисы,
- Монолит + Сервисы + Микросервисы.
- Сервисы + Микросервисы.


В реальных проектах делают смесь архитектурных подходов. Это нормально.

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

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

Кстати, бывает сложно доказать, что микросервис на самом деле микро- 😁 В этом главный подвох микросервисной архитектуры. Когда сервис уже микро-, но ещё не нано-сервис?! 🙈

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

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

Какую архитектуру выбрать для проекта? 🧐

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


🟡 Нефункциональные требования напрямую влияют на подход к проектированию архитектуры.
Это требования не к тому, что система должна делать, а к тому, как она должна это делать.

Примеры:

+ Система должна сохранять одинаковую скорость отклика при нагрузке до 100 пользователей в 1 сек.

+ Обновление подсистемы интеграции со СДЭК не должно вызывать остановку работы остальных интеграций.

+ Доступность системы должна быть 99% времени в год. То есть допустим простой до 88 часов в год.

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



🟡 Процесс принятия решений по архитектуре проекта:

1. Собираем требования: узнаем у бизнеса, что от системы ожидают.

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

3. Выбираем архитектуру: определяем, какой тип архитектуры подходит под задачи.

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

5. Идем далее на этап детализации требований.


Продолжение 👇

Какой тип архитектуры выбрать? 🙄

🔺 Монолит:
Как один большой блок. Подходит для маленьких проектов и стартапов. Такие системы просты в реализации, но их сложно менять и развивать. Это может быть плохое решение при наличии строгих нефункциональных требований: скорость работы, нагрузки, масштабируемость и другие.

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

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


И моё любимое ❤️:
Выбор подхода к архитектуре зависит от проекта. Для GetDelivery подойдет и сервисная, и монолитная архитектура.

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

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

Тяжело быть IT-ишником, знаете 😅

Всем отличного настроения на трудовую неделю! Пусть работа будет в удовольствие 😘

Коллеги, всем привет!

Мы с вами завершили верхнеуровневое проектирование архитектуры GetDelivery. Я показала только ту часть проекта, которая касается интеграций с системами доставки. Можно было бы добавить ещё интеграции с системами уведомлений, очереди сообщений (rabbit, kafka), но мы, в контексте текущей задачи, их разбирать не будем. Выбран SOA (сервисно-ориентированный подход) - интеграции вынесены в отдельный сервис.

То, как сейчас отображена схема архитектуры - это моя нотация CR (CloudRectangle).

Пока я намеренно упустила часть обозначений, которые обычно использую:

- Виды API, по которым осуществляется взаимодействие между системами (REST, SOAP, и другие).

- Виды СУБД (SQLite, PostgreSQL, MongoDB и другие).
Но на первом подходе для выбора архитектуры этого достаточно.


Как системный аналитик, я считаю, что понятность и наглядность ценнее нотации. Поэтому в процессе проектирования, по договоренности с командой, могу использовать свою нотацию CR, которую также объясняю на программе по проектированию интеграций вместе с общепринятой нотацией архитектуры С4.

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

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

Нотация C4 (Model for Software Architecture) — это метод визуализации архитектуры программного обеспечения, разработанный Саймоном Брауном.

Название "C4" расшифровывается как "Context, Containers, Components, and Code". Эти четыре "C" представляют четыре уровня абстракции, которые используются в этой нотации для визуализации и описания архитектуры.

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

Уровни Представления:


🔺 Уровень системы (System Context diagram)

Показывает, как система взаимодействует с внешними сущностями (пользователями, внешними системами). Сразу видно интеграции.

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

Элементы:
- системы,
- пользователи,
- взаимосвязи.


🔺 Уровень контейнеров (Container diagram)

Описывает верхнеуровневую архитектуру и технологии.
Используется для понимания технологического стека и разделения зон ответственности.

Элементы:
- контейнеры (например, веб-приложения, базы данных),
- взаимосвязи,
- технологии.


🔺 Уровень компонентов (Component diagram)

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

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

Элементы:
- компоненты,
- взаимосвязи,
- технологии,
- зависимости.


🔺 Уровень кода (Code diagram)

Показывает детали реализации отдельных компонентов.

Используется для документирования структуры кода. На практике не используется, т.к. разработчикам это не надо. Это как диаграмма классов UML: вроде полезно понимать, а по факту не нужна.

Элементы:
- классы,
- интерфейсы,
- отношения между ними.


❤️ Красивая схема C4 в Miro c примером проекта.

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

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

Многие люди так и остаются в своем текущем состоянии из-за страха. Но зачем бояться? Можно же просто ввязаться в игру и действовать!


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


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

2. Не поддавайтесь сомнениям, действуйте. "А если не получится..." замените на фразу "Когда я это сделаю, то...".

3. Планируйте: записывайте задачи, которые помогут прийти к цели, и время их выполнения.

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


Хотите меняться, но сомневаетесь? Не надо сомневаться. Нравится? Берите, пробуйте и воплощайте мечты в жизнь! Всё будет! ❤️

💫 Собрала теорию, примеры и инструменты для визуализации C4 в одну статью 💫

Что получилось:

1. Краткая сводка по теории.
2. Собранные в одном месте примеры диаграмм С4 (несколько для каждого уровня), на которых можно осваивать нотацию.
3. Подборка инструментов для создания схем архитектуры C4.
4. Подборка дополнительных материалов.
5. Заключение по применению C4 в процессе проектирования архитектуры.


➡️ Читать на Habr

3️⃣ Анализ API-документации

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

В работе с интеграционным проектом, важнейшим этапом является анализ API-документации партнеров: СДЭК, Возовоз и Деловые линии. Системному аналитику важно понимание их API.

Попытка описывать функциональность системы с интеграциями без детального изучения API-документации может привести к рискам в процессе разработки:

✖️ Нет нужных методов, чтобы реализовать получение или запись данных во внешней системе.

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

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

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

✖️ Проблемы с авторизацией и аутентификацией запросов: не учли, что нужны дополнительные системные или пользовательские авторизации и потеряли логику авторизации запросов.


С каждым риском можно будет разобраться позже. Но скорее всего это уже будут придуманные “костыли” на ходу, вместо заранее продуманного плана действия.

Такая работа похожа на марафон без подготовки: ты ни разу не бегал 42 км, а теперь после 6 км пытаешься придумать на ходу как пробежать ещё 36, и чтобы сердце не отказало сейчас 🏃‍♀️💀❤️‍🩹

🔌 Use Case с брокером: Завершение зарядки авто с оплатой по привязанной карте 🔌


👉 Предусловия:
▫️ Пользователь завершает зарядку электромобиля на станции.
▫️ В его аккаунте уже привязана банковская карта.
▫️ Нужно корректно завершить сессию, рассчитать оплату, списать деньги и уведомить пользователя.


👉 Use Case — старт зарядки






#АрхитектураGA

Сомнительная зона комфорта 🤨

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

И, казалось бы, это успех! Тебя любит команда, чувствуешь свою важность и, главное, уверенность! В чем проблема? Где подвох?

Долго наслаждаться этим состоянием зоны комфорта не получается. Становится скучно. В IT это распространенная практика для всех специалистов.

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

И вот, на первых собеседованиях в компании, которые интересны, спрашивают больше - за пределами того, что делал на текущем месте работы. А переходить в другое место с похожими условиями и задачами не хочется. Зачем? Хорошая команда и комфортное место и так есть.

Это в вас проснулся синдром самозванца и "и так сойдёт". В эти моменты, когда что-то сразу не получается, важно не опускать руки, иметь поддержку от близких и наставников, строить собственный план роста, и делать всё возможное для его реализации. Любые ошибки должны становиться мотивацией. Да, придётся приложить усилия, но это того стоит!

Ребята, вы поймите, пока зону комфорта не покинете, ничего в жизни не поменяется.

Я вижу много успешных примеров среди своих учеников, кто в процессе обучения улучшает свою позицию: повышение в должности, ЗП, новая ответственность, смена компании. Это говорит о том, что постановка целей и работа над их реализацией приводят к результатам.

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

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