![](data:image/svg+xml;charset=utf-8,<svg width="640" height="640" style="background-color:%2344badc;font-family:Nunito,sans-serif" viewBox="0 0 100 100" preserveAspectRatio="xMidYMid meet" xmlns="http://www.w3.org/2000/svg">
<text font-size="30" x="50%" y="50%" dy="5" fill="white" dominant-baseline="middle" text-anchor="middle">Ам</text>
</svg>)
Репост из: Yet Another Burakov
Верните анализ в аналитиков
На фоне смещения фокуса системных аналитиков в сторону проектирования появился интересный эффект - они все меньше занимаются анализом. Порой кажется, не особо хотят.
Спроектировать API или схему БД - это пожалуйста, порассуждать о выборе способа интеграции и особенностях NoSQL хранилищ - с удовольствием, поговорить про Rabbit vs Kafka - тоже можно.
Когда заходит речь о том, что же нужно пользователю, в каких процессах участвует система, какие из функций критичны для бизнеса и как посчитать пиковую нагрузку - пусть бизнес-аналитики с продуктами разбираются, у нас лапки архитектура.
Допустим, каждый сисаналитик мечтает стать архитектором. Посмотрим, какие темы регулярно обсуждают в архитектурном комьюнити: моделирование предметной области, business needs, event storming, атрибуты качества и не только. Т.е. в среде архитекторов и техлидов есть четкое понимание, что проектировать системы без понимания бизнес контекста невозможно.
Что называю бизнес-контекстом:
1. Общий контекст системы: с какими внутренними и внешними сервисами взаимодействуем, какие пользователи работают с системой. Поможет контекстная диаграмма или первый уровень C4
2. Процессы, в которых участвует система. Без понимания не сможем спроектировать адекватный UX, схему интеграций и внутреннюю архитектуру. Формат особого значения не имеет: классические BPMN-eEPC-UML, CJM и Service Blueprints, продукты Event Storming’а или стрелочки-квадратики.
3. Модель предметной области, чтобы понимать, какими бизнес-сущностями мы оперируем, и какие связи между ними существуют. Здесь на вкус и цвет: концептуальная ERD, вариации на тему контекстов DDD или декомпозиция в стиле ООП. Я обычно использую концептуальную ERD дополненную отношениями использования.
4. Ключевые бизнес-метрики, продуктовые метрики, атрибуты качества, внешние и внутренние ограничения - все что принято называть НФТ.
Для меня это смертельный минимум, без которого команда не сделает подходящее решение. Может ли аналитик перейти в архитектуру и успешно работать без сильных навыков анализа и моделирования? Сомнительно.
На фоне смещения фокуса системных аналитиков в сторону проектирования появился интересный эффект - они все меньше занимаются анализом. Порой кажется, не особо хотят.
Спроектировать API или схему БД - это пожалуйста, порассуждать о выборе способа интеграции и особенностях NoSQL хранилищ - с удовольствием, поговорить про Rabbit vs Kafka - тоже можно.
Когда заходит речь о том, что же нужно пользователю, в каких процессах участвует система, какие из функций критичны для бизнеса и как посчитать пиковую нагрузку - пусть бизнес-аналитики с продуктами разбираются, у нас лапки архитектура.
Допустим, каждый сисаналитик мечтает стать архитектором. Посмотрим, какие темы регулярно обсуждают в архитектурном комьюнити: моделирование предметной области, business needs, event storming, атрибуты качества и не только. Т.е. в среде архитекторов и техлидов есть четкое понимание, что проектировать системы без понимания бизнес контекста невозможно.
Что называю бизнес-контекстом:
1. Общий контекст системы: с какими внутренними и внешними сервисами взаимодействуем, какие пользователи работают с системой. Поможет контекстная диаграмма или первый уровень C4
2. Процессы, в которых участвует система. Без понимания не сможем спроектировать адекватный UX, схему интеграций и внутреннюю архитектуру. Формат особого значения не имеет: классические BPMN-eEPC-UML, CJM и Service Blueprints, продукты Event Storming’а или стрелочки-квадратики.
3. Модель предметной области, чтобы понимать, какими бизнес-сущностями мы оперируем, и какие связи между ними существуют. Здесь на вкус и цвет: концептуальная ERD, вариации на тему контекстов DDD или декомпозиция в стиле ООП. Я обычно использую концептуальную ERD дополненную отношениями использования.
4. Ключевые бизнес-метрики, продуктовые метрики, атрибуты качества, внешние и внутренние ограничения - все что принято называть НФТ.
Для меня это смертельный минимум, без которого команда не сделает подходящее решение. Может ли аналитик перейти в архитектуру и успешно работать без сильных навыков анализа и моделирования? Сомнительно.