Шпаргалка по проектированию REST API

⏳ 8 мин | 🟤⚪️⚪️

Перейти | BA|SA

Как правильно формулировать нефункциональные требования

⏳ 9 мин | 🟤⚪️⚪️

Перейти | BA|SA

Примеры бизнес-применения модели C4

⏳ 7 мин | 🟤🟤⚪️

Перейти | BA|SA

Эволюция процессов: от классической автоматизации до самооптимизирующихся ИИ-агентов

⏳ 13 мин | 🟤🟤⚪️

Перейти | BA|SA

Внедрение API Gateway: проблемы, решения, практические рекомендации

⏳ 10 мин | 🟤🟤⚪️

Перейти | BA|SA

Альтернативная нотация описания архитектуры ИТ систем

⏳ 4 мин | 🟤🟤⚪️

Перейти | BA|SA

Салют! Я проводила опрос по интеграции систем для системных аналитиков и обещала поделиться своими мыслями, но что-то затянула, исправляюсь)))

1️⃣ «Ваш ключевой проект - интеграция новой CRM с устаревшей ERP-системой. Бюджет и сроки ограничены. Какой подход вы предпочитаете на старте?»

Мой ответ: C. API-led (во главе угла API) ✅

Почему?

Стратегия, а не тактика:
- Point-to-Point — это технический долг почти в чистом виде.
Мы решим сиюминутную задачу, но создадим монолитный стык, который будет сложно поддерживать и почти невозможно переиспользовать для других систем.
- ESB — это "тяжелая артиллерия". Для старта проекта с ограниченными сроками и бюджетом разворачивание и настройка ESB — это overengineering.
- iPaaS — хороший вариант, но он может создать зависимость от вендора и не решает проблему legacy-системы в корне.

- ✅ API-led как золотая середина: Этот подход позволяет нам создать современный, стандартизированный интерфейс (API) для нашей старой ERP. Это превращает её из "обузы" в полноценного участника экосистемы. Мы сначала инвестируем силы в создание этого слоя, что немного увеличивает время на старте, но затем подключение CRM (и любой будущей системы, например, портала для клиентов или бухгалтерского сервиса) становится вопросом дней, а не месяцев. Это стратегическое вложение, которое окупится в первом же крупном обновлении архитектуры.

2️⃣ «При выборе технологии интеграции для нового проекта, какой фактор для вас является решающим»

Мой ответ: A. Масштабируемость и гибкость ✅

Почему?

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

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

- Скорость внедрения: Быстро = костыльно. Создает технический долг, который обойдется дороже в будущем.
- TCO (стоимость владения): Низкий TCO — это прямое следствие масштабируемой архитектуры. Они не конкурируют, а масштабируемость — инструмент для достижения низкого TCO.
- Безопасность: Это must-have, гигиена. Должна быть заложена в любом решении по умолчанию, а не выбираться вместо гибкости.

3️⃣ «Как вы видите evolving роль системного аналитика в контексте интеграции»

Мой ответ: A. "Архитектор экосистем" ✅

Почему?

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

- Проектирование связей: Моя ценность всё больше заключается не в том, чтобы написать идеальное ТЗ для разработчика одной команды, а в том, чтобы спроектировать взаимодействие между командами и их системами. Я определяю контракты API, форматы событий, стандарты обмена данными. Я думаю не в терминах "функций", а в терминах "потоков данных" и "бизнес-процессов", которые проходят через несколько систем. Это роль архитектора, который рисует не здания, а дороги, коммуникации и связи между ними. Остальные роли ("переводчик", "data-детектив") — это важные, но подчинённые навыки в рамках этой главной роли.

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

Источник: @ba_and_sa

Салют! Продолжаем изучать Архитектуру ПО, и сегодня делюсь подборкой статей по теме:

📎 Основы архитектуры ПО:

- Все, что вам нужно знать об API в архитектуре программного обеспечения в 2024 году
- Освоение архитектуры API: подробное руководство
- Основные типы архитектуры программного обеспечения
- Шаблоны архитектуры программного обеспечения: руководство для разработчиков

📎 Роль системного аналитика в Архитектуре ПО

- Роль системного аналитика при проектировании архитектурных решений
- Скрытая работа аналитика по проектированию систем
- Архитектура систем для аналитиков: ТОП-5 нотаций моделирования архитектуры

📌 BA|SA

Салют! Вчера я поделилась своим мнением по-поводу работы Технического писателя и Системного аналитика, сегодня же предлагаю обратиться в инет и разобраться вместе, кто такие Технические писатели и что они делают))

📎 Подборка статей, для технических писателей:

👋 Знакомство с профессией:

- Профессия: технический писатель
- Кто такой технический писатель и как им стать

💡Навыки Технического писателя:

- 10 навыков, которые должны быть в резюме первоклассного технического писателя
- 11 навыков хорошего техрайтера

🧑‍💻 Инструменты и системы:

- Что нужно для создания документации: инструментарий технического писателя
- Выбор инструмента для технического писателя

✅ Если кратко и с моей т.з., то я бы выделила такие инструменты для ТехПисов, как:

- Confluence, MadCap Flare, GitBook и др Системы для управления документацией и знаний

- Подход "Docs-as-Code" и системы контроля версий Git (GitHub, GitLab, Bitbucket)

- Текстовые процессоры и редактирование Microsoft Word, Google Docs и др

- Планирование и управление задачами Jira, Trello и др

- Проектирование и визуализация Диаграммы (BPMN, UML и др)

- AI-инструменты ChatGPT, Docsie и другие AI-ассистенты

💡 Ключевые компетенции и принципы работы

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

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

- Понимание стандартов: Знание и опыт применения отраслевых стандартов, таких как ГОСТ 19 и ГОСТ 34, что критически важно для работы с государственными и крупными корпоративными заказчиками в России.

- Базовые навыки веб-разработки: Знание основ HTML и CSS позволяет гибко настраивать внешний вид и формат веб-документации, выходя за рамки готовых шаблонов.

- Адаптивность и выбор инструмента: Главный навык — это способность оценить потребности проекта и команды, а затем выбрать наиболее подходящий инструмент. Не существует единственно правильного решения, и комбинация инструментов — обычная практика.

📌 BA|SA

Что значит «хороший вкус» в разработке ПО?

⏳ 7 мин | 🟤⚪️⚪️

Перейти | BA|SA

Один простой способ оптимизации API

⏳ 4 мин | 🟤🟤⚪️

Перейти | BA|SA

ArchiMate+BPMN: апгрейд роли «бизнес-аналитик»

⏳ 4 мин | 🟡🟡⚪️

Читать статью | Analyst IT

Подход к анализу требований в проектах внедрения ERP-систем

⏳ 4 мин | 🟤⚪️⚪️

Перейти | BA|SA

BPMN, EPC, IDEF0... Какую нотацию выбрать? Карта мира бизнес-процессов от практика.

Салют! Кто меня не знает, я - Оксана, которая уже более 10 лет в сфере БА/СА, и я именно тот самый человек, который проводит не мало рабочего времени, рисуя квадратики и стрелочки, чтобы потом весь коллектив сказал «Ага! Теперь ясно!».
Одна из самых частых тем для дискуссий в начале любого проекта: «А на чём будем рисовать?».

Давайте разберемся без лишней теории и воды.
Нотации — это как языки. Можно описать один и тот же процесс на английском, русском или китайском. Суть не поменяется, но аудитория поймет по-разному.

🎯 Зачем вообще это нужно?

Прежде чем смотреть на инструменты, спросите себя: «Зачем мы описываем процесс?»

- Чтобы регламентировать и дать сотрудникам четкую инструкцию?
- Чтобы проанализировать и найти «узкие места» и оптимизировать?
- Чтобы разработать на основе процесса ПО?
- Чтобы согласовать понимание между бизнесом и айтишниками?

Ответ на этот вопрос — ваш главный компас в выборе.

‼️ ТОП-3 нотации, которые правда стоит знать в 2025 году (по моему мнению)

1️⃣ BPMN 2.0 (Business Process Model and Notation) — «Золотой стандарт»

Что это? - Мощный и гибкий язык, который понятен и бизнесу, и разработчикам.

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

Плюсы и Минусы:

➕ Универсальность: Подходит для описания как есть (As-Is), так и будущего (To-Be) процесса.
➕ Детализация: Позволяет показать сообщения, события, ошибки и параллельные потоки. Можно описать процесс от общего взгляда до уровня, достаточного для автоматизации.
➕ Однозначность: Минимум разночтений.

➖Сложновата для абсолютных новичков. Есть риск «перегрузить» диаграмму.

Когда выбирать BPMN?

- Практически всегда, особенно если процесс кросс-функциональный (затрагивает несколько отделов).
- Когда процесс готовят к автоматизации в BPM-системе (Camunda, ELMA, etc.).
- Когда нужно четко прописать исключения и обработку ошибок («а что, если заявка не согласована?»).

2️⃣ EPC (Event-Driven Process Chain) — «Классика жанра»

Что это? Нотация, популярная в связке с методологией ARIS. Её философия: любое действие начинается и заканчивается событием.

Ключевые элементы: События (шестиугольники), функции (прямоугольники с закругленными углами), логические операторы (и/или) и ресурсы (документы, данные, исполнители).

Плюсы и Минусы

➕ Наглядность для бизнеса: Легко читается сотрудниками, не погруженными в тонкости моделирования.
➕ Хорошо показывает связку «событие-действие».

➖ Может стать слишком громоздкой на сложных процессах.
➖ Менее строгая, чем BPMN, что может порождать разные трактовки.

Когда выбирать EPC?

- Если в компании уже устоялась экосистема ARIS.
- Когда основная цель — описание и регламентация процессов «как есть» для внутреннего использования.
- Когда ваша аудитория — в первую очередь бизнес-пользователи, а не разработчики.

3️⃣ IDEF0 (Integration DEFinition for Function Modeling) — «Взгляд сверху»

Что это? Менее популярная сегодня, но очень дисциплинирующая нотация. Она заставляет думать о процессе как о «черном ящике», у которого есть Входы, Выходы, Управление и Механизмы.

Ключевые элементы: Функциональные блоки (прямоугольники) и стрелки четырех типов, которые строго регламентированы.

Плюсы и минусы:

➕ Отлично показывает контекст и взаимосвязи системы.
➕ Заставляет думать о ресурсах (Механизмы) и правилах (Управление) для каждой функции.
➕ Идеальна для высокоуровневого описания сложных систем.

➖ Слишком абстрактна для описания пошаговых сценариев.
➖ Не подходит для описания логики принятия решений и временных последовательностей.

Когда выбирать IDEF0?

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

Сама работала во всех трех нотациях, но 80% - BPMN, если не больше ))

Источник: @ba_and_sa