📌 Список бесплатных онлайн-курсов по базам данных и SQL

▪️ Курс от Stepik: Интерактивный тренажер по SQL - практические задания на создание SQL-запросов.

▪️ Курс от Stepik: Введение в базы данных - Знакомство с методами структурированного хранения данных, основами SQL, принципами использования баз данных в приложениях

▪️ LearnDB- интерактивные онлайн-курсы по SQL СУБД PostgreSQL.

▪️ Базовый курс SQL для аналитиков и менеджеров — 24 видеоурока по SQL для начинающих, автор Максим Кухарь

▪️ Основы SQL  - базовый курс на платформе Интуит, теоретические материалы + тесты для самопроверки.

▪️ Видеокурс по SQL от IT Proger - изучение SQL и работа с базами данных на примере MySQL.

▪️ SQL для начинающих - курс по основам SQL от Академии IT

Онлайн-тренажёры по SQL
🔹 SQL Academy - онлайн тренажер с упражнениями по SQL;
🔹SQL-EX упражнения и Интерактивный учебник по SQL;
🔹 SQLBolt - пошаговый интерактивный учебник (уроки + упражнения);
🔹 Solve SQL | HackerRank - платформа для практики и изучения языков программирования;
🔹 SQL Fiddle  - эмулятор написания SQL-запросов, позволяет практиковаться на разных типах СУБД (MySQL, PostgreSQL, SQLite, MS SQL Server);
🔹 SQL Tutorial - справочник с множеством примеров и упражнений.

Источник: @notes_analyst

#sql #бд

🔥 Книги для системного аналитика бесплатно без регистрации и СМС 📚

Собрали для Вас 20 лучших книг для развития аналитика. Ссылки кликабельны, можно скачивать любую книгу отдельно или весь архив целиком.
👉 Скачать весь архив

Пересылайте коллегам, пусть тоже развиваются, хотя бы чуть-чуть 😉

Требования
📖 Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению
📖 Алистер Коберн. Современные методы описания функциональных требований к системам
📖 Дин Леффингуэлл. Принципы работы с требованиями к программному обеспечению
📖 Джефф Паттон. Пользовательские истории. Искусство гибкой разработки ПО

Архитектура
📕 Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения
📕 Эрик Эванс. Предметно-ориентированное проектирование (DDD)
📕 Вон Вернон. Реализация методов предметно ориентированного проектирования
📕 Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга
📕 Сэм Ньюмен. Создание микросервисов
📕 Александр Швец. Погружение в Паттерны Проектирования

Интеграции
📗 Грегор Хоп и Бобби Вульф. Шаблоны интеграции корпоративных приложений
📗 Арно Лоре. Проектирование веб-API
📗 Сергей Константинов. API

Своды знаний
📔 BABOK v3
📔 INCOSE Guide for Writing Requirements

Навыки
📓 Алан Купер. Психбольница в руках пациентов
📓 Карл Андерсон. Аналитическая культура
📓 Вера Иванова. Путь аналитика. Практическое руководство
📓 Максим Ильяхов и Людмила Сарычева. Пиши, сокращай: Как создавать сильный текст
📓 Роберт Фитцпатрик. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?

Библиотека будет пополняться в канале Библиотека Системного Аналитика

#подборка

Интерактивная карта навыков системного аналитика

Вариант 1
Вариант 2
Вариант 3 (здесь просто перечисление)
Вариант 4 — BA & SA Roadmap от TestEngineer

#развитие

Это я завтра утром

Задачник для системных аналитиков от Тинькофф. В задачнике 29 вопросов с нарастающим уровнем сложности.

Очень интересное чтиво, советуем ознакомиться

#развитие

〽️ Нефункциональные требования и зачем они нужны

Нефункциональные требования (НФТ) — это требования, которые определяют качество системы, а не ее функциональность. НФТ описывают, как система должна работать, а не что она должна делать. НФТ влияют на удовлетворенность пользователей и эффективность системы.

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

Например, ФТ для онлайн-магазина могут быть такими:
▪️Система должна позволять пользователям регистрироваться и входить в свои аккаунты.
▪️Система должна показывать список товаров с их ценами и описаниями.
▪️Система должна позволять пользователям добавлять товары в корзину и оформлять заказы.

А НФТ для той же системы могут быть такими:
🔹Система должна быть доступна 99,999% времени.
🔹Время отклика Системы не должно превышать 1 сек (для 90% запросов).
🔹Система должна защищать личные данные и платежную информацию пользователей от несанкционированного доступа.

Какие виды нефункциональных требований существуют

Есть много видов НФТ, разные источники классифицируют их по-разному, например, Карл Вигерс, BABOK, ISO/IEC 25000.
Для примера, рассмотрим классификацию по FURPS+.

➖ Functionality (Функциональность) — это классические функциональные требования. Пример: Система должна иметь возможность выбора способа доставки на этапе оформления заказа.

➖ Usability (Удобство использования) — это характеристики, которые определяют удобство и привлекательность системы для пользователей, такие как эргономика, эстетика, интуитивность, обучаемость и т.д. Пример: Система должна иметь адаптивный дизайн, который подстраивается под разные размеры экранов и устройств.

➖ Reliability (Надежность) - это характеристики, которые определяют способность системы работать без ошибок и сбоев, а также восстанавливаться после них, такие как доступность, непрерывность, отказоустойчивость и т.д. Пример: Система должна иметь резервное копирование данных и автоматическое восстановление в случае сбоя.

➖ Performance (Производительность) — это характеристики, которые определяют скорость и эффективность работы системы, такие как время отклика, пропускная способность, масштабируемость и т.д. Пример: Система должна обрабатывать не менее 1000 запросов в секунду при нагрузке до 10 000 одновременных пользователей.

➖Supportability (Поддерживаемость) — это характеристики, которые определяют легкость сопровождения и модификации системы, такие как тестируемость, документированность, совместимость и т.д. Пример: Система должна быть написана на языке программирования Python с использованием фреймворка Django.

➖ "+" в названии модели означает, что к ней можно добавить другие категории НФТ в зависимости от специфики проекта, такие как экологичность, экономичность, правовые аспекты, ограничения и т.д. Пример: Система должна соответствовать требованиям GDPR по обработке персональных данных.

📎 Статьи по теме
1. Нефункциональные требования к программному обеспечению — Хабр
2. О нефункциональных требованиях — Школа системного аналитика
3. Высокая доступность и удобный интерфейс: разрабатываем нефункциональные требования — BABOK School
4. Нефункциональные требования: как не пустить систему ко дну — Хабр, больше о практике
5. Нефункциональные требования? Нет, модели обеспечения качества — Хабр, предложен интересный подход к проработке НФТ

Вебинары
▶️ Немного о требованиях, которые все меняют — доклад с Analyst Days 2020
▶️ Нефункциональные требования · При чем тут заказчик? Александра Галамага

#требования

🖥 ⇆ 🗄 Как работает клиент-серверная архитектура

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

Клиент-серверная архитектура описывает, как взаимодействуют между собой клиент (в нашем случае фронтенд) и сервер (бэкенд).

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

Сервер — это та часть приложения, которая обрабатывает запросы от клиента и возвращает ответы. Сервер может быть физическим или виртуальным. Сервер отвечает за выполнение бизнес-логики и доступ к базе данных.

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

Пример работы клиент-серверной архитектуры

1️⃣ Пользователь вводит данные в форму на клиенте и нажимает кнопку “Отправить”.
2️⃣ Клиент формирует запрос на сервер и отправляет его через сеть.
Сервер получает запрос от клиента и обрабатывает его согласно бизнес-логике.
3️⃣ Сервер формирует запрос на базу данных и отправляет его через сеть или локально.
4️⃣ База данных получает запрос от сервера и выполняет его, возвращая результаты.
5️⃣ Сервер получает результаты от базы данных и формирует ответ на клиент.
6️⃣ Сервер отправляет ответ на клиент через сеть.
7️⃣ Клиент получает ответ от сервера и отображает его пользователю.

Виды клиент-серверной архитектуры

🔹 Двухзвенная — это архитектура, в которой есть только два слоя: клиентский и серверный. К двухуровневой архитектуре «клиент-сервер» следует относить такую, в которой прикладные программы сосредоточены на сервере приложений, например, на сервере CRM, а в рабочих станциях находятся программы-клиенты, которые предоставляют для пользователей интерфейс для работы с приложениями на общем сервере.

🔹 Трехзвенная — сервер баз данных, файловый сервер и другие представляют собой отдельный уровень, результаты работы которого использует сервер приложений. Логика данных и бизнес-логика находятся в сервере приложений.

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

Преимущества и недостатки клиент-серверной архитектуры

Клиент-серверная архитектура имеет много преимуществ перед другими архитектурами, например, файл-серверная, в которой все файлы хранятся на одном сервере и доступны для всех клиентов:

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

Однако клиент-серверная архитектура также имеет некоторые недостатки, такие как:
🔻 Зависимость от сети и доступности сервера, так как если сеть пропадет или сервер упадет, то пользователь не сможет работать с приложением.
🔻 Сложность обеспечения отказоустойчивости, так как если нагрузка на приложение возрастет или произойдет сбой на одном из серверов, то нужно предусмотреть механизмы балансировки и резервирования.

📎 Материалы по теме
1. Клиент-серверная архитектура в картинках: статья на Хабре и видео
2. Клиент - серверная архитектура (Client-Server Architecture)
3. Клиент-серверная архитектура — JavaRush
4. Как работают веб-приложения
5. Грамотная клиент-серверная архитектура: как правильно проектировать и разрабатывать web API

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

HTTP. Что нужно знать аналитику

HTTP (HyperText Transfer Protocol) — это, если дословно, протокол передачи гипертекста. Простыми словами, гипертекст – это текст + теги. Сегодня HTTP – самый популярный протокол интернета и в целом интеграций через API.

Несмотря на название, через протокол можно передавать любые данные. Протокол есть набор правил, определяющих, как обмениваться данными. Благодаря своей простоте и гибкости, HTTP используется практически повсеместно при проектировании API систем и сервисов.

Основой HTTP является технология «клиент-сервер», есть две роли: сервер и клиент.
➖ Клиент инициируют соединение и посылает запрос на сервер
➖ Сервер обрабатывает запрос и посылает ответ клиенту.

Структура HTTP-сообщения всегда одинакова:

🔹 Стартовая строка, в которой определяется адрес, по которому отправляется запрос, и тип сообщения. Указывается метод, который определяет действия при получении этого сообщения (GET, POST и т.д.)

🔹 Заголовки (Headers), в которых прописаны определённые параметры сообщения. Например, может быть напрямую задан язык.

🔹 Тело запроса (Request Body), текст сообщения — данные, которые передаются. Например, файлы, отправляемые на сервер.

Пример запроса:

GET /users/octocat HTTP/1.1
Host: api.github.com
User-Agent: curl/7.64.1
Accept: */*

Процесс работы HTTP-протокола

1️⃣ Клиент формирует и отправляет запрос на сервер по адресу (URL), который может быть введен в браузере или сгенерирован автоматически.

2️⃣ Запрос передается по сети с помощью других протоколов, например TCP/IP, которые разбивают его на пакеты данных.

3️⃣ Сервер получает запрос, обрабатывает его и отправляет ответ, который также передается по сети в виде пакетов данных.

4️⃣ Клиент получает ответ и отображает результат, например веб-страницу в формате HTML.

Структура ответа в HTTP состоит всё из тех же частей, что и запрос:

🔸 Cтартовая строка содержит версию протокола, код состояния и текст результата запроса, например, HTTP/1.1 200 OK

🔸 Заголовки содержат дополнительную информацию о ответе, такую как тип и длина контента, дата и время, куки, кэширование и т.д.
Например:

Content-Type: text/html; charset=utf-8
Content-Length: 125829
Date: Mon, 29 Nov 2021 10:24:06 GMT

🔸 Тело содержит данные ответа, например HTML-документ, изображение, JSON-объект и т.д.

Пример ответа

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Content-Length: 29769
Content-Type: text/json

{
    "isFree": false,
    "price": 200
}

📎 Материалы по теме
1. Стандарт HTTP 1.1 — RFC 2616
2. Статья Что такое протокол HTTP и почему на нём работают почти все сайты
3. Статья на сайте Backend interview
4. Обзор протокола HTTP — Mozilla
5. HTTP-запросы: структура, методы, строка статуса и коды состояния — Академия Selectel
6. Самые распространённые HTTP-заголовки

В продолжение к посту кидаем полезные шпаргалки 👇

#интеграции #api

Методы HTTP

Свойства методов HTTP
(картинка, кстати, с англоязычной Википедии 😁)

Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы

Классическая книга про управление проектами в ИТ.

Фактически книга Брукса представляет собой сборник очерков, в которых последовательно обсуждаются узловые проблемы разработки крупных программных проектов: повышение производительности труда программистов, организация коллективной работы, планирование и выполнение графика реализации. Одной из главных тем книги стала идея, получившая впоследствии название «закон Брукса», о том что привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта

#управление_проектами

HTTP. Краткие советы по использованию протокола

📌 URL идентифицирует ресурс. Вызов метода — не ресурс.
Не делайте так:
GET /?method=шарахнуть&to=Луна
Лучше так:
POST /шарахалка/?to=Луна

📌 URL состоит из схемы, хоста, пути, запроса и фрагмента. Путь — для иерархических ресурсов, запрос — для неиерархических и параметров операции. Фрагмент — для подчинённых ресурсов без URL.

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

http://nyashnye-kotiki.xxx/breeds/maine-coon/?deliver_to=Moscow#photo

📌 Обращение по HTTP — это применение метода (глагола) к URL. Результат должен соответствовать глаголу. Например, GET возвращает ресурс, DELETE удаляет его.

📌 Методы GET, HEAD, OPTIONS — безопасные. Они не изменяют состояние ресурса. Некоторые сетевые агенты могут вызывать их без вашего согласия.

📌 Методы GET и HEAD кэшируются по умолчанию, остальные — нет. Если вы хотите шарахнуть по Луне методом GET, то можете получить ответ из кэша и не шарахнуть на самом деле.

📌 Методы GET, PUT, DELETE идемпотентны, то есть возвращают один и тот же результат. PUT кладёт ресурс по URL-у, GET возвращает его, DELETE удаляет его. Метод HEAD возвращает только заголовки ресурса.

📌 POST используется, если у вас нет URL для операции. Например, если вы создаёте новое сообщение на форуме и не можете самостоятельно сгенерировать его ID.

POST /threads/php-rulezz/messages

Если вы повторите POST запрос — создастся дубликат сообщения. PUT можно повторять сколько угодно — результат не изменится. Это свойство называется идемпотентностью. Если клиент сам может сгенерировать ID, лучше использовать PUT:

PUT /threads/php-rulezz/messages/100500

📌 PUT может создавать или обновлять ресурсы целиком. PATCH может модифицировать ресурсы частично.

📌 Коды ответа нужны, чтобы клиент мог понять, что ему делать дальше.
3хх говорит, что нужно выполнить дополнительное действие.
4хх говорит, что клиент сделал что-то неправильно. В 4хх крайне рекомендуется включать информацию о том, что конкретно клиент сделал не так.
5хх говорит о том, что клиент всё сделал правильно — проблема на стороне сервера.

📌 Обычно при успешном выполнении операции сервер отвечает на GET — 200, на PUT — 201 Created (если ресурс создан) или 200 (ресурс обновлён), на DELETE — 204 (операция успешна, возвращать нечего), на POST — 200 или 201 (во втором случае в заголовке, обычно Location, указывается URL созданного ресурса).


📌 Работа с HTTP-статусами:

401 Unauthorized обязан сопровождаться заголовком WWW-Authenticate и подходит только для HTTP-аутентификации. Используйте 403 Forbidden для других случаев.

3xx статусы требуют дополнительного действия от клиента. Например, 304 Not Modified означает, что клиент должен взять ресурс из кэша.

404 статус может повторяться, так как ресурс может появиться позже. Если ресурса нет и не будет, используйте 410 Gone или 400.

📎 Материалы по теме
1. 15 тривиальных фактов о правильной работе с протоколом HTTP — Хабр, Яндекс
2. REST API Best Practices / Хабр
3. Best Practices in API Design — блог Swagger

Требования к требованиям, или свойства качественных требований

✅ Полнота. Требование содержит всю необходимую информацию, ничто не пропущено по соображениям «это и так всем понятно».

⛔️ Типичные проблемы:
➖ «пароли должны храниться в зашифрованном виде» - каков алгоритм шифрования?
➖ «экспорт осуществляется в форматы PDF, PNG и т.д.» — что мы должны понимать под «и т.д.»?
➖ «см. выше» вместо «см. раздел 123.45.b»

✅ Атомарность. Требование описывает одну ситуацию и не может быть разбито на части без потери смысла.

⛔️ Типичные проблемы:
➖ «кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя» — в одном предложении описаны разные элементы интерфейса в разных контекстах
➖ «если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату» — описаны три разных случая, и это требование стоит разбить на три отдельных во избежание путаницы
➖ «когда пользователь входит в систему, ему должно отображаться приветствие; когда пользователь вошел в систему, должно отображаться имя пользователя; когда пользователь выходит из системы, должно отображаться прощание» — все три ситуации должны быть описаны отдельно и более детально

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

⛔️ Типичные проблемы:
➖ «после успешного входа в систему пользователя, не имеющего права входить в систему…» — тогда как он успешно вошёл в систему, если не имел такого права?
➖ Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка “Close” всегда должна быть красной» и «36452.x Кнопка “Close” всегда должна быть синей»

✅ Недвусмысленность. Требование формулируется ясно и однозначно, без использования жаргона, аббревиатур или расплывчатых выражений. Старайтесь избегать таких слов, как: много, мало, часто, редко, эффективно, большой, быстро, легко, несколько…

⛔️ Типичные проблемы:
➖ Использование терминов или фраз, допускающих субъективное толкование: «приложение должно поддерживать передачу больших объемов данных» — насколько больших?
➖ «В случае необходимости оптимизации передачи больших файлов система должна эффективно использовать минимум оперативной памяти, если это возможно»

✅ Выполнимость. Требование должно быть реализуемым в рамках бюджета и сроков разработки проекта.

⛔️ Типичные проблемы:
➖ «система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты»
➖ «анализ договоров должен выполняться с применением искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора»

✅ Актуальность. Требование необходимо для успеха проекта и соответствует текущим условиям. Требование имеет приоритет, например, по MoSCoW.

⛔️ Типичные проблемы:
➖ Требование было добавлено «на всякий случай», хотя реальной потребности в нём нет
➖ Ошибки приоритета требования
➖ Требование устарело

✅ Прослеживаемость. Требования должны иметь атрибуты, позволяющие осуществлять трассировку требований и вносить изменения. Например: номер/ID, приоритет, владельца, ответственного

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

⛔️ Типичные проблемы:
➖ плохое оформление и ошибки в тексте;
➖ слишком глубокая детализация требования на уровне бизнес-требований или недостаточная детализация на уровне требований к продукту);
➖ «пользователь должен быть в состоянии отправить сообщение» — увы, мы не можем влиять на пользователя
➖ «в случае, если разрешение окна составляет менее 800x600…» — разрешение есть у экрана, у окна есть размер

📎 Статьи по теме
1. Требования (Requirements) — QA_Bible
2. Критерии качества требований — Наталья Чаусова
3. О критериях качества требований
— Art of Business Analysis

📄 Документы
Стандарт IEEE 830-1998 (SRS) на русском

#требования

Типы интеграции систем. Преимущества и недостатки

Выделяют 4 основных типа интеграции:
1. Файловая интеграция
2. Общая база данных
3. Удалённый вызов процедур
4. Обмен сообщениями

1️⃣ Файловая интеграция. Cистема А передает файл системе Б в определенном формате (например, CSV или XML). Файл с данными размещается в хранилище (например, файловом сервере), откуда другие системы могут его считать.

🟢 Преимущества

▫️Универсальность. Файлы поддерживаются любой операционной системой и языком программирования

▫️Простота. Просто закинули данные в файлик и готово

🔴 Недостатки

▪️Скорость. Обмен данными через файлы может быть медленным и приводить к рассинхронизации данных.

▪️Ненадежность. Нет гарантии, что файл дойдет до целевой системы и будет корректно обработан.

2️⃣ Общая база данных. Система А размещает свои данные в общей БД, из которой система Б может спокойно читать.

🟢 Преимущества

▫️Высокая скорость. Нет нагрузки на сеть. Данные доступны для чтения сразу после их записи в общую БД

▫️Единый формат данных и их целостность

🔴 Недостатки

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

▪️Сложность проектирования. БД общая, схема БД общая. Нужно учесть особенности всех систем, а это очень трудоёмко и долго.

▪️Точка отказа. Если БД выйдет из строя, то конец всему.

3️⃣ Удалённый вызов процедур, или интеграция через API. Система А удаленно вызывает метод системы Б, передавая туда нужные параметры. Самые популярные способы реализовать этот подход: REST, SOAP, GraphQL и gRPC и т.д.

🟢 Преимущества

▫️Гибкость. Разработка и развертывание сервисов может быть выполнена независимо и быстро, без влияния на другие сервисы.

▫️Инкапсуляция. Данные и логика их обработки скрыты внутри удаленной процедуры, что повышает безопасность и целостность данных.

▫️Масштабируемость. Каждый сервис может быть масштабирован по отдельности в зависимости от нагрузки и потребностей.

🔴 Недостатки

▪️Контракты. Вызывающая система должна знать контракт вызываемой системы, а также ее доступность и адрес. Любое изменение в API может потребовать изменения в вызывающей системе.

▪️Сложность интеграции и эксплуатации. Распределение логики и данных по нескольким сервисам может затруднить координацию и мониторинг интеграционного решения.

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

4️⃣ Обмен сообщениями. Это асинхронный способ взаимодействия, при котором система А формирует сообщение и кладёт его в очередь. Система Б читает это сообщение и выполняет определённую логику. К этому способу относятся брокеры очередей сообщений (например, Kafka или RabbitMQ) и шины данных (ESB).

🟢 Преимущества

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

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

▫️Масштабируемость. Сравнительно легко: просто добавляем больше ёмкости в наш брокер

▫️Асинхронность. Система А не должна ждать ответа от системы Б и может продолжать работу. Не требуется одновременной доступности обоих систем.

🔴 Недостатки

▪️Сложность интеграции и эксплуатации. Разработка и поддержка интеграционного решения требует знания и управления брокером сообщений, его коннекторами, форматами и правилами обмена сообщениями.

▪️Производительность. Обмен сообщениями может быть менее эффективным, чем прямой вызов, из-за сетевых затрат и дополнительной обработки сообщений брокером.

▪️Трудности согласования данных. Обмен сообщениями может приводить к рассинхронизации данных между системами из-за асинхронности.

В следующем посте поговорим о критериях выбора типа интеграции.

📎 Материалы по теме
1. Шаблоны интеграции корпоративных приложений — книга Хопа и Вульфа
2. Интеграции IT систем и при чем тут бар? — статья на Хабре

#интеграции

❓Как выбрать тип межсистемной интеграции

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

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

1️⃣ Периодичность межсистемного взаимодействия. Как часто системы должны взаимодействовать? Отчего это зависит? Периодичность может быть следующей:
• По расписанию: система Б получает сведения из системы А раз в определенный период времени (минута, час, сутки и пр.).
• По событию: передача данных и удаленные вызовы функций выполняются при наступлении какого-то события в одной из систем или внешнем мире.
• По запросу: по явному запросу пользователя или другой системы.

2️⃣ Допустимая задержка обработки данных. Это время, которое проходит с момента появления данных в источнике до их получения приемником. Если данные нужно обрабатывать в реальном времени или с минимальной задержкой, то подходят технологии потоковой передачи, такие как gRPC

3️⃣ Степень связанности и зависимости систем. Чем сильнее системы связаны и зависят друг от друга, тем выше требования к согласованности и актуальности данных.

4️⃣ Степень изменчивости и динамичности систем. Чем чаще и сильнее системы меняются и развиваются, тем выше требования к гибкости и масштабируемости интеграции. Мы не можем использовать в таком случае единую БД, так как невозможно менять схему данных настолько часто, насколько это необходимо.

6️⃣ Масштабируемость. Это способность системы к росту путем увеличения количества вычислительных узлов (серверов). Масштабируемость зависит от балансировки нагрузки и пропускной способности технологии. Например, Kafka может обеспечить высокую пропускную способность и автоматическую балансировку нагрузки при передаче большого количества сообщений. Также важно учитывать количество источников и приемников данных, которые должны быть подключены к системе интеграции.

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

Итого

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

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

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

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

💬 Пишите в комментариях, как вы определяете, какой тип интеграции нужно использовать👇

📎 Материалы по теме
1. Шаблоны интеграции корпоративных приложений — книга Хопа и Вульфа
2. 7 главных требований к интеграции ИС, чтобы определить решение — BABOK School
3. Типы системной интеграции
4. Базовое проектирование и разработка требований к интеграции систем (для начинающих аналитиков)
5. Интеграции IT систем и при чем тут бар?

#интеграции

В качестве дополнения сравнение видов (не путать с типами) интеграций. Типов в этой таблице всего 2: удалённый вызов процедур (первые 4) и обмен сообщениями (последние 2)