Архитектор и заказчик

Архитекторы не только верят, что сидят по правую руку от Бога, но и считают, что если Бог встанет, то они займут его место.
Этот немного странный эпиграф я украла у своего коллеги Кейта Брайтуэйта, он меня точно не знает, но его предложение заменить слово «Бог» на «Заказчик» сначала очень возмутило меня, но потом я поняла, что, в общем и целом, это звучит очень правдиво. Смотрите, друзья:

Иногда архитекторам и разработчикам кажется, что коллеги по ту сторону от нас (заказчики) не очень погруженные в предметную область люди, и иногда это даже правда. Но я призываю вас, друзья, не пренебрегать основной группой заинтересованных лиц в своей работе, это закончится очень плохо. Так что именно в этом разделе будет очень много про компромисс.
Заказчик собирательный образ, обозначающий большое количество заинтересованных сторон (подробнее работу со стейкхолдерами рассмотрим в отдельной статье и попозже). Умение корректно выявить стейкхолдеров очень даже важно, еще более важно – уметь выявить их истинные потребности. Истинные потребности не те, что в явном виде озвучены в задаче, а те, которые помогут ответить на вопрос: «какую бизнес-ценность нам это принесет?» или «как вы планируете достичь бизнес-ценности за счет требуемых доработок на уровне прикладной архитектуры?».
Несмотря на то, что бизнес-архитектура ну очень уж связана с прикладной, стороны, несущие ответственность за развитие этих двух слоев, иногда начисто не понимают друг друга. Откровенно говоря, мне иногда самой кажется смешным, что даже самые здравомыслящие сдержанные люди, и я, не могут обойти соблазн сказать про представителей противоположной стороны: «они сами не знают, что хотят». Все это напоминает мне легенду о Вавилоне, как будто, если бы все говорили на одном языке, мы бы построили самую совершенную архитектуру предприятия. Единый язык существует, правда, и вы не поверите, друзья, но именно для архитектора важнее всего им обладать, мы, своего рода, англичане в мире разных культур, мы должны уметь понятно сказать все стейкхолдерам, от заказчика, до команд.
Общий язык, или универсальный язык, понятный всем, которым должен владеть архитектор включает несколько важных составляющих: финансово-экономическая модель (простая), понятная нотация с укрупненными сущностями, термины, понятные как с точки зрения бизнес-архитектуры, так и с точки зрения конкретного бизнес домена, формулирование взаимосвязей изменений в прикладной архитектуре с поставкой бизнес-ценности.
Мне показалось, что нагляднее будет показать два основных перекоса при взаимодействии с заинтересованными сторонами (которые не заканчиваются на заказчике):

1.Я не доверяю способности заинтересованных сторон действовать и ставить задачи корректно. Их цели и потребности никак не связаны со светлым будущим организации;

2.Мне сказали – я сделал. Мне за это деньги платят.

Рассмотрим первую грань. Так или иначе, чем дольше карьера архитектора, тем чаще нам встречаются похожие ситуации, похожая реакция заинтересованных сторон из проекта в проект, который так и подталкивают нас уже устало сказать: я знаю лучше. И это, наверное, один из худших антипаттернов, лишающий дискуссию шанса на конструктивный исход. Кроме того, как я писала выше, у архитектора чаще всего имеется некоторый кредит доверия и уважения, которыми так и соблазняет воспользоваться выгорание, усталость, рутина. Полезным в данном случае будет подумать о том, кто оправдывает наше существование. Прикладная архитектура является своего рода цифровым двойником бизнес-модели, а в случае с карманными ИТ-организациями прикладная архитектура наследует еще и все характеристики организационной структуры организации (по закону Конвея). Иначе говоря, наше существование оправдано существованием заинтересованных сторон, как бы обидно это не звучало. Без коллег заказчиков не будет финансирования, без команды разработки не будет разработано ничего. Поэтому, одним из искусств архитектора является способность формировать и подкреплять конкретными эффектами свое ценностное предложение.
Вторая грань говорит о тех ситуациях и тех проявлениях архитектора, в которых, боюсь, нету и не будет места авторитету архитектора, как и кредит уважения к нему будет уменьшаться (наравне с предпосылкой 1 выше). Архитектор является весьма недешевым ресурсом компании, но заблуждение состоит в том, что нам платят лишь за то, чтобы мы делали ровно по бизнес-требованиям. Это не совсем так, нам платят за экспертизу, за насмотренность, за возможность предложить еще лучше. Я верю, что каждый из вас, друзья, держит это в голове, когда отстаивает необходимость очередных инвестиций в ИТ-ландшафт. Но есть разница между «нам нужна еще одна система/нам нужно переработать сервис, потому что мне виднее» и «нам нужна еще одна система/нам нужно переработать сервис, чтобы вы смогли реализовать не только то, что заявляли в исходных бизнес-требованиях, но и смочь быстро масштабировать до функционала А и Б, как уже делают конкуренты А, Б и С». Оба пункта приводят нас к необходимости подготовки аналитических записок и освоению универсального языка архитектора.
Аналитическая записка представляет собой понятный стейкхолдерам документ, построенный с применением нижеследующих пунктов.
Наличие ценностного предложения. Необходимо доступно объяснить, почему именно указанные изменения в ИТ-ландшафте приведут нас к достижению конкретных (важных для заинтересованных сторон) ценностей;
Количественные метрики. Ожидаемые положительные эффекты должны быть измеримыми и прозрачными для заинтересованных сторон. Кроме того, наличие количественных метрик поможет выстроить доверительный и конструктивный настрой при обсуждении архитектурного решения с заинтересованными сторонами;
Взаимосвязь как метрик, так и ценностного предложения с традиционными бизнес-метриками. Пояснительная записка/доклад архитектора обязательно должны демонстрировать ожидаемый результат на понятном каждой заинтересованной стороне языке;
Понятные этапы и вехи (инициативы). Пояснительная записка должна явно демонстрировать этапы (инициативы в рамках пояснительной записки), каждый из которых приносит ту или иную бизнес-ценность в заданные сроки;
Умение выбрать подходящий момент. Друзья, контекст нас не только направляет, но и помогает усилить или нивелировать эффект доклада архитектора при его правильном или неправильном использовании. Навык найти идеальный момент – один из метанавыков архитектора, позволяющий обернуть контекст себе во благо, сделать его своим союзником. И тут каждому придется поискать это в себе.
Весь этот комплекс компромиссов, обсуждений, приготовление является этапом подготовки к самому главному, самому интересному этапу в жизни как архитектора, так и заинтересованных лиц – к проектированию. Проектируя отдельный элемент ИТ-ландшафта, мы видоизменяем не кипы бумаг, хотя и это тоже, мы изменяем Архитектуру предприятия