Рискну поднять холиварную тему: где границы ролей BA и SA?

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

И я, честно говоря, не видел чёткого и признанного определения.

У нас есть профессиональные стандарты, в которых весьма конкретно определена разница: BA — специалист по организационным изменениям и оптимизации;
SA — специалист по проектированию и координации создания информационных систем.

Это чёткие определения, но они мало признаны. Обычная реакция — а, профстандарты! Разве они имеют какое-то отношение к жизни? Вот BABoK! (В этом своде знаний, кстати, системные аналитики упоминаются лишь один раз вскользь. Но и для BA работа с ИТ-системой там описана как частный случай)

В реальной жизни я чаще вижу другой подход (видимо, сложившийся естественным путем): BA — тот, кто может поговорить с пользователями и записать их требования(!), проанализровать и описать их деятельность, и сформулировать концепцию ИТ-решения, а иногда и достаточно детальные постановки (BRD), но всё ещё понятные бизнес-заказчикам.

А SA в такой конфигурации — эксперт по устройству систем. Он осуществляет распределение требований и задач на системы и их элементы, переводит концептуальные и логические модели в физические, проектирует схемы данных, API и брокеры, описывает технические моменты типа журналирования, метаданных, ретраев и т.п. То есть, смотрит на систему не как на черный ящик, а уже хорошо разбирается в её устройстве. И останавливается только перед непосредственным прораммированием.

И тут я у вас хочу спросить -- где, по-вашему, граница ролей и деятельности? До чего в пределе может дойти BA, а что для него уже перебор? Чтобы структурировать обсуждение, предложу рассматривать следующие аспекты:

1. Цели бизнеса / создания системы
2. Модель деятельности (процессы, юзкейсы, сценарии)
3. Модель данных, состояний
4. Пользовательские, функциональные и системные требования
5. Интерфейсы пользователя и API
6. Отчеты, метрики, дэшборды
7. Нефункциональные требования
8. Архитектура системы

Насколько далеко в каждом направлении может/должен продвинуться BA, а где ему придется остановиться?