Универсального инструмента нет — есть инструмент под задачу. Диаграммы как код (PlantUML для UML/C4/sequence) — для схем, которые живут в репозитории, диффятся и ревьюются. Excalidraw — для быстрых набросков на созвоне. BPMN рисуют в отдельных редакторах (Storm BPMN, bpmn.io/Camunda). API-контракты ведут в OpenAPI (Swagger Editor, Stoplight) и AsyncAPI. База знаний и журнал решений — Confluence или Obsidian. Задачи — Jira или YouTrack. Схемы данных — dbdiagram или Draw.io. Главный принцип: чем важнее схема, тем сильнее она хочет быть кодом.
Я долго рисовал диаграммы мышкой в красивых редакторах. Пока однажды разработчик не поменял один сервис, а схема в Confluence осталась старой — и новый человек в команде неделю проектировал интеграцию по картинке, которая уже врала. С тех пор моя графика живёт как код: я пишу её текстом, она лежит рядом с проектом, и любое изменение видно в истории как обычный коммит. Это не вопрос вкуса — это вопрос того, чтобы схема не врала.
Дальше — набор по задачам. Не «топ инструментов», а карта «какая задача — чем закрывается». Многое из этого — то, чем я пользуюсь каждый день.
Диаграммы как код
Главная идея, которую стоит усвоить раньше любого конкретного инструмента: схему можно писать текстом, а не рисовать. Вы описываете диаграмму на простом языке, а движок рендерит картинку. Звучит как лишний шаг — а на деле это меняет всё.
PlantUML — рабочая лошадка для этого. UML, C4, sequence — всё описывается текстом. Вся моя графика-как-код живёт здесь: sequence-диаграммы, компонентные, C4. Текст диаграммы лежит в репозитории, его ревьюят в пул-реквесте, как обычный код, и он не разъезжается с реальностью, потому что меняется вместе с ней. Mermaid — та же идея, встроенная прямо в Markdown и многие вики, удобна для быстрых схем по месту.
Почему «как код» выигрывает
Текстовую схему можно диффить (видно, что именно поменялось между версиями), ревьюить (комментарии прямо в пул-реквесте) и хранить рядом с проектом, чтобы она не разъезжалась с кодом. Картинку, нарисованную мышкой, нельзя ни продиффить, ни нормально отревьюить — она просто молча устаревает. Чем дольше живёт схема и чем важнее её точность, тем сильнее она хочет быть кодом.
Быстрые наброски
Обратная сторона: не всё надо превращать в код. Когда вы на созвоне за пять минут объясняете идею или набрасываете черновик, который завтра выкинете, — текстовый движок только мешает. Тут нужен лист и маркер.
Excalidraw — для этого идеален. Это единственный диаграммер, в котором не тянет полировать: нарочито «карандашный» стиль сразу говорит «это черновик, не финальный документ», и никто не воспринимает набросок как контракт. Правило простое: одноразовое и для разговора — рисуйте от руки в Excalidraw; долгоживущее и точное — пишите кодом.
BPMN
BPMN — особый случай: у него строгая нотация со своими правилами, и удобнее рисовать в редакторе, который эти правила знает и подсказывает. Storm BPMN — рабочий инструмент под нотацию, не игрушка, рекомендую именно его для BPMN. bpmn.io (движок, на котором построен моделлер Camunda) — открытый редактор BPMN, удобен, если процесс потом пойдёт в исполнение в Camunda. Подробнее про саму нотацию — в записи какую нотацию когда использовать, а как читать BPMN по символам — в записи BPMN на практике.
API-контракты
Контракт API — это тоже код, и ведётся он текстом. OpenAPI (бывший Swagger) — стандарт описания REST-API в YAML: эндпоинты, параметры, схемы запросов и ответов, коды ошибок. Редактируют в Swagger Editor (показывает ошибки и рисует интерактивную документацию) или Stoplight (визуальный редактор поверх того же OpenAPI). Для событийных, асинхронных интеграций — очереди, топики Kafka — есть родственный стандарт AsyncAPI. Контракт в YAML диффится и ревьюится так же, как диаграмма-как-код. Что вообще должно быть в контракте — в записи REST API для аналитика.
База знаний и журнал решений
Схемы и контракты — это «что». Но не менее важно «почему»: почему выбрали такую интеграцию, почему отказались от очереди, какие были альтернативы. Это журнал решений, и его стоит вести отдельно. Confluence — корпоративный стандарт, общая вики команды. Obsidian — для личных заметок и журнала решений: журнал решений и мои личные заметки живут именно здесь, локально и в Markdown. Связку обычно делят так: личное и черновики — в Obsidian, согласованное и общекомандное — в Confluence.
Задачи и схемы данных
Задачи и бэклог ведут в трекере: Jira (индустриальный стандарт) или YouTrack. Для аналитика трекер — это не просто список дел, а место, где требование связано с задачей разработки, тестом и релизом. Схемы данных (ER-диаграммы) удобно рисовать в dbdiagram.io — там та же идея «как код»: пишете описание таблиц текстом, получаете ER-диаграмму. Draw.io — универсальный бесплатный редактор «нарисовать что угодно», когда под задачу нет специализированного инструмента.
Задача → инструмент
| Задача | Инструмент |
|---|---|
| UML, C4, sequence (долгоживущие, точные) | PlantUML, mermaid |
| Быстрый набросок на созвоне | Excalidraw |
| BPMN-процесс | Storm BPMN, bpmn.io / Camunda |
| REST API-контракт | OpenAPI в Swagger Editor / Stoplight |
| Асинхронная интеграция (очереди, события) | AsyncAPI |
| База знаний, журнал решений | Confluence (общее), Obsidian (личное) |
| Задачи и бэклог | Jira, YouTrack |
| ER-диаграммы, схемы данных | dbdiagram.io, Draw.io |
Откуда это взялось
Идея «диаграммы как код» (diagrams-as-code) выросла из PlantUML, который появился в конце 2000-х. До него архитектурные схемы рисовали мышкой в Visio и подобных редакторах — и они неизбежно устаревали, потому что жили в стороне от кода и менялись отдельно от него. PlantUML предложил простое: раз код мы версионируем, диффим и ревьюим — давайте делать то же со схемами. Та же логика позже легла в основу OpenAPI и AsyncAPI: контракт — это тоже текст, который живёт в git.
Частые вопросы
Какие инструменты нужны системному аналитику?
Минимальный набор по задачам: PlantUML или mermaid для диаграмм-как-код (UML, C4, sequence), Excalidraw для быстрых набросков, отдельный редактор для BPMN (Storm BPMN, bpmn.io), OpenAPI/Swagger для API-контрактов, Confluence или Obsidian для базы знаний и журнала решений, Jira или YouTrack для задач. Не нужно учить всё сразу — берите инструмент под конкретную задачу.
Чем рисовать UML и BPMN?
UML, sequence и C4 удобнее всего писать кодом в PlantUML или mermaid — такие схемы диффятся, ревьюятся и не разъезжаются с проектом. BPMN со своей строгой нотацией лучше рисовать в специализированном редакторе: Storm BPMN или bpmn.io (движок моделлера Camunda). Для одноразового наброска на созвоне подойдёт Excalidraw.
В чём вести API-контракты?
REST-контракты ведут в стандарте OpenAPI (бывший Swagger) — это YAML с эндпоинтами, параметрами, схемами и кодами ошибок; редактируют в Swagger Editor или Stoplight. Для асинхронных интеграций (очереди, Kafka) есть родственный стандарт AsyncAPI. Контракт в YAML лежит в git, диффится и ревьюится наравне с кодом.