Рискну поделиться субъективным мнением, надеясь, что его обсуждение не выльется в холивар. Есть много хороших бизнес/системных аналитиков, которым более-менее регулярно приходится заниматься проектированием ИТ-решений. ИТ-архитекторам тоже регулярно приходится заниматься анализом. Причем речь идет не только о технологиях, но, в не меньшей степени, о погружении в предметные области, концептуализации присущих им вещей и операции, конкретных практик деятельности организации. Может быть разделение профессий аналитика и архитектора необоснованно? Думаю, что нет. Я знаю хороших аналитиков, которые не хотят быть архитекторами, а также архитекторов, которые не смогут, да и не станут работать аналитиками. О том, как разобраться в собственных предпочтениях этот текст.
Сначала я выскажу гипотезу, с которой вы вправе не согласиться. На мой взгляд бизнес/системный анализ формировался и довольно долго рассматривался как практика описания(моделирования) текущей деятельности. Т.е. предметом такого описания являлось нечто уже существующее: процесс, требующий автоматизации, нуждающиеся в учете документы и вещи, необходимые для принятия решений показатели и т.д. Т.е. речь изначально шла о том, чтоб концептуализировать, структурировать и оптимизировать уже существующее, происходящее. Сделать это следовало максимально полно, непротиворечиво и понятно. Качеством, помогающим такой работе является дотошность, желание основательно во всем разобраться, внимание к деталям и любовь к построению абстракций. Даже если речь идет об описании чего-то пока не существующего, а только планируемого, всегда есть человек, знающий, как должно быть сделано правильно. Этот тот самый пользователь, поставленный дисциплиной бизнес-анализа на пьедестал. Слова его после критического осмысления и фиксируются в виде требований (второе важное слово).
А вот предметом деятельности ИТ-архитектора является то, чего нет. Архитектор он обычно про будущее. Достижимое или недостижимое, туманное или отчетливое, принимаемое всеми заинтересованными лицами или сопротивляющимися ему. Про вещи и процессы, которые можно нафантазировать, но нельзя увидеть или пощупать. Архитектор отвечает за проект. В текущем лексиконе это слово утащили себе проектные менеджеры. Но раньше оно часто использовалось для обозначения непосредственно самого замысла, а не плана его достижения. Потому описание такого замысла – это скорее предложения или договоренности, чем формальные спецификации. Сколь детально бы мы будущее решение не описали, от этого оно не появится. Процесс воплощения идеи – отдельная история, в которой редко все идет гладко. Да и сама идея в ходе своей реализации десять раз поменяется. Потому важно понимать не требования, а потребности, опираться на уже существующие данные, сервисы, технологии, а не стараться изобрести их заново, мириться с неопределенность и не принимать необратимых решений. Не станет архитектор скрупулёзно описывать то, чего еще нет. А то, что уже существует захочет в формате architecture-as-code
Теперь о требованиях. У аналитика требования как бы уже существуют. Вначале они просто не высказаны и не задокументированы. У архитектора же требования осознаются заказчиком в процессе обсуждения вариантов реализации решения. Т.е. требования – это вещи(разочарования?), возникающие в ходе понимая заинтересованными лицами реальных технологических возможностей. А еще, у аналитика требования непротиворечивы. А вот архитектор формирует решения отчетливо осознавая противоречия. Такие, как несовместимые ожидания от системы разными группами заинтересованных или разный темп изменений для разных элементов решения.
Можно ли совместить эти два подхода в деятельности одного человека? Может быть и да, а может и нет. Вопрос: зачем? Не лучше ли каждому выбрать роль исходя из собственных предпочтений, а в работе, осознавая разницу точек зрения, взаимно друг друга дополнять.
Максим, спасибо за размышления вслух! Я согласен практически со всем написанным, но добавлю свои 5 копеек.
“То, что есть” и “То, что надо сделать” взаимозависимы, т.к. в определенный момент они должны слиться в одно “То, что будет”. В этом состоянии обязательно останется что-то из “Того, что есть”. Вопрос в том, что именно должно остаться (где пройдет граница) и что в результате получится. На мой взгляд, эти решения должен готовить тот, кого вы назвали “аналитик”, кто понимает их влияние на бизнес, кто представляет будущего владельца “Того, что будет”. В последнее время эту роль часто называют “Product manager” или “Product owner”, что вполне справедливо. Архитектор же может предлагать какие-то варианты по объему решения, но в целом ему необходимо проектировать в рамках, заданных product manager’ом.
Из моего опыта, попытка объединять в одном человеке и PdM и Архитектора, приводит к внутренней борьбе, в которой одна из сторон проигрывает. Обычно побеждает Архитектор, и это не всегда бывает хорошо для бизнеса.
Слова его после критического осмысления и фиксируются в виде требований (второе важное слово).
/*Вот корень ошибки в размышлениях. Требования аналитик документирует не собственные, а чужие. Соответственно аналитику нужно описать то, что есть, понять новые чужие требования, на обнаруженную дельту написать БТ, а на БТ, если это системный аналитик, написать ТЗ. И при написании ТЗ как раз во всю проявляется “придумывание нового”.
Именно аналитик отвечает на вопрос “как”. Аналитик обращается к архитектору за требованиями в какой системе реализовывать тот или иной функционал, какое интеграционное решение будет лучшим – то есть отвечает на вопрос “где / на каком стэке”.
А на вопрос “что”, который по вашим словам, прибрали себе пмы, отвечает бизнес, пм лишь ретранслирует этот ответ, вкупе с вопросом “когда”.
В ваших терминах архитектор это пуп земли, а остальные просто не нужны. */