Роль ИТ-архитектора в организации

08.10.2014, Максим Смирнов, http://mxsmirnov.com/2014/10/08/solution-architect-2

Несколько месяцев назад я написал заметку Когда, кому и зачем нужна Архитектура Предприятия Справедливости ради надо отметить, что полномасштабный проект по выстраиванию Enterprise Architecture  встречается достаточно редко. Намного чаще услуги архитектора бывают востребованы для решения более локальных задач: структурирование приложений, процессов и данных в рамках отдельного продукта, бизнес-функции или направления деятельности организации. В таких случаях обычно говорят об архитектуре ИТ-решения, а человека который её делает называют Solution architect. Одной из задач этого уважаемого эксперта является разработка архитектуры в ИТ-проекте. На прошлом месте работы мы называли эту деятельность High Level Design Но у Solution architect есть еще одна, не менее важная задача – подготовка вариантов решения. О том как это сделать можно почитать здесь Create a solution architecture А я напишу несколько слов о том, почему это важно.

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

1. Чаще всего заказчики стремятся напрямую обратиться к ИТ-команде, осуществляющей развитие какого-то конкретного приложения, с просьбой что-нибудь доработать. И те с радостью идут им навстречу, добавляя в систему очередную ненужную фичу. Если таких обращений становиться много или же доработки требует некоторых дополнительных денег, то процесс развивается по сценарию номер два.
2. Подключаются руководители ИТ или бизнес-заказчики. Обычно рассказ о том, почему нужно что-то доработать в системе выглядит довольно сумбурно и заканчивается фразой: «дай денег!». Руководители пытаются что-нибудь с этим сделать, например, внедрить проектное управление, организовать соответствующий комитет, в общем, как-нибудь упорядочить эту деятельность. Однако, после достижения данного уровня зрелости в голове ИТ-директора все чаще возникает вопрос: а что из этого мы, действительно, должны делать и почему делать следует именно так.
3. Решение о варианте реализации той или иной бизнес-потребности осуществляется на основании рассмотрения альтернатив. Это как в процедуре закупок – никогда не надо покупать решение от единственного поставщика. Точно так же, прежде чем делать какой-то проект, полезно рассмотреть несколько вариантов реализации.

Собственно говоря, для подготовки альтернативных вариантов и организации процесса их рассмотрения и нужны ИТ-архитекторы. Делается это на этапе проекта, который в PMBOK называется «инициация». С точки зрения ИТ в этот момент все плохо: требования отсутствуют, заинтересованные лица между собой еще ни о чем не договорились, но кто-то уже настойчиво продвигает один из вариантов реализации. А еще, в компании в этот момент появляются вендоры новых систем и системные интеграторы. Причем обычно приходят они не с пустыми руками, а с утверждением, что у них все есть и их предложение самое лучшее.
Одним словом, работа архитектору предстоит сложная. Однако, это пожалуй единственный способ включить руководителей в процесс принятия решения. Потому что в сценариях 1 и 2 никто никаких решений, на самом деле, не принимает. Просто потому, что погружение в технические детали — задача для большинства руководителей не реализуемая. Не от того, что они не способны разобраться в «технике». Просто у них не хватает на это времени и, обычно, необходимой объективной информации. В общем, если ИТ-начальник хочет что-то решать, то ему стоит подумать об организации такого процесса.