Работа ИТ-архитектора

Рискну поделиться субъективным мнением, надеясь, что его обсуждение не выльется в холивар. Есть много хороших бизнес/системных аналитиков, которым более-менее регулярно приходится заниматься проектированием ИТ-решений. ИТ-архитекторам тоже регулярно приходится заниматься анализом. Причем речь идет не только о технологиях, но, в не меньшей степени, о погружении в предметные области, концептуализации присущих им вещей и операции, конкретных практик деятельности организации. Может быть разделение профессий аналитика и архитектора необоснованно? Думаю, что нет. Я знаю хороших аналитиков, которые не хотят быть архитекторами, а также архитекторов, которые не смогут, да и не станут работать аналитиками.

Сначала я выскажу гипотезу, с которой вы вправе не согласиться. На мой взгляд бизнес / системный анализ формировался и довольно долго рассматривался как практика описания (моделирования) текущей деятельности. То есть предметом такого описания являлось нечто уже существующее: процесс, требующий автоматизации, нуждающиеся в учете документы и вещи, необходимые для принятия решений показатели и т. д. То есть речь изначально шла о том, чтоб концептуализировать, структурировать и оптимизировать уже существующее, происходящее. Сделать это следовало максимально полно, непротиворечиво и понятно. Качеством, помогающим такой работе является дотошность, желание основательно во всем разобраться, внимание к деталям и любовь к построению абстракций. Даже если речь идет об описании чего-то пока не существующего, а только планируемого, всегда есть человек, знающий, как должно быть сделано правильно. Этот тот самый пользователь, поставленный дисциплиной бизнес-анализа на пьедестал. Слова его после критического осмысления и фиксируются в виде требований (второе важное слово).

А вот предметом деятельности ИТ-архитектора является то, чего нет. Архитектор он обычно про будущее. Достижимое или недостижимое, туманное или отчетливое, принимаемое всеми заинтересованными лицами или сопротивляющимися ему. Про вещи и процессы, которые можно нафантазировать, но нельзя увидеть или пощупать. Архитектор отвечает за проект. В текущем лексиконе это слово утащили себе проектные менеджеры. Но раньше оно часто использовалось для обозначения непосредственно самого замысла, а не плана его достижения. Потому описание такого замысла – это скорее предложения или договоренности, чем формальные спецификации. Сколь детально бы мы будущее решение не описали, от этого оно не появится. Процесс воплощения идеи – отдельная история, в которой редко все идет гладко. Да и сама идея в ходе своей реализации десять раз поменяется. Потому важно понимать не требования, а потребности, опираться на уже существующие данные, сервисы, технологии, а не стараться изобрести их заново, мириться с неопределенность и не принимать необратимых решений. Не станет архитектор скрупулёзно описывать то, чего еще нет. А то, что уже существует захочет в формате architecture-as-code.

Теперь о требованиях. У аналитика требования как бы уже существуют. Вначале они просто не высказаны и не задокументированы. У архитектора же требования осознаются заказчиком в процессе обсуждения вариантов реализации решения. То есть требования — это вещи (разочарования?), возникающие в ходе понимая заинтересованными лицами реальных технологических возможностей. А еще, у аналитика требования непротиворечивы. А вот архитектор формирует решения отчетливо осознавая противоречия. Такие, как несовместимые ожидания от системы разными группами заинтересованных или разный темп изменений для разных элементов решения.

Можно ли совместить эти два подхода в деятельности одного человека? Может быть и да, а может и нет. Вопрос: зачем? Не лучше ли каждому выбрать роль исходя из собственных предпочтений, а в работе, осознавая разницу точек зрения, взаимно друг друга дополнять.