ЛЕКЦИЯ 8 17 страница

Если бизнес-руководители (которые, в конце концов, выделяют все необхо-димые финансовые ресурсы) не поддержат усилия по выработке архитектуры ИТ, то им стоит готовить себя к еще большим затратам в будущем, поскольку они неиз-бежно окажутся в ситуации, когда они зададут себе вопрос: «Почему же мы тра-тим так много средств для получения таких посредственных услуг от ИТ-службы?»

Следует иметь в виду, что при принятии решения о необходимости разра-ботки архитектуры предприятия - пока эффект от нее не доказан практикой,- следует избегать отнесения расходов по ее разработке на бизнес-подразделения организации или на бюджет конкретного ИТ-проекта.

Точно так же, как в строительстве существует должность главного архитек-тора города или проекта так и в организации кто-то должен быть ответственным за развитие архитектуры предприятия в целом, а информационных систем в частности. С уче-том отмеченной ранее тесной связи между архитектурой информационных тех-нологий и бизнес-архитектурой, один и тот же человек может отвечать за обе эти области.

По оценкам МЕТА Group, должность «Главного архитектора» введена при-мерно в 30% компаний. Собственно название этой должности, вообще говоря, может быть любым, так что за разработку архитектуры могут быть ответственны-ми, например, «Заместитель руководителя ИТ-службы» или «Директор по ИТ-стратегии». Гораздо более важным является статус данной должноспги в орга-низации.Существует большое количество примеров, когда такое «громкое на-звание» должности на самом деле используется одним из рядовых аналитиков в составе ИТ-службы, у которого нет реальных прав и возможностей влияния на ситуацию. В этом случае ответственность на практике размазывается (со всеми вытекающими из этого последствиями) по всей команде проекта, а то и по всем руководителям подразделений в ИТ-службе организации. Еще большую акту-альность эти вопросы могут иметь для государственных организаций и разра-ботки архитектуры «электронного правительства».

Интересным является вопрос об оптимальном составе команды проекта по разработке архитектуры. Обычно выделение отдельных структур считается це-лесообразным для достаточно больших по размеру ИТ-служб, насчитывающих порядка 100 и более сотрудников. Даже для больших организаций рекомендует-ся ограничивать состав основной команды 7-8 сотрудниками, а для более де-тальной проработки доменов архитектуры (частных архитектур данных, прило-жений и пр.) создавать отдельные проектные группы.

В меньших организациях чаще используется матричный метод когда в ко-манду проекта входят представители различных подразделений. Однако в лю-бом случае принципиальным скорее является не наличие или отсутствие фор-мальной кадровой структуры, а применение соответствующих методологий для формирования архитектуры и управления всем процессом.

Для Главного архитектора такие качества, как положительная харизма,уве-ренность при общении с высшим руководством, системный подход и осведом-ленность в бизнесе, умение распределять работу между подчиненными могут явиться более критичными, чем знание конкретных технологий.

Оптимальный состав команды, по мнению МЕТА, должен включать специа-листов со следующими ролями:

· Стратег, который взаимодействует с руководством организации и форму-лирует на понятном специалистам по информационным технологиям язы-ке те бизнес-требования, которые должны найти отражение в Архитектуре предприятия.

· Проектировщик, ответственный за определение общих архитектурных принципов.

· Тренер, который специализируется на объяснении высшему руководству и бизнес-пользователям необходимости и преимуществ Архитектуры пред-приятия.

· Советники, которые обеспечивают взаимодействие с командами, реализу-ющими отдельные программы и проекты, а также отслеживают перспектив-ные технологии и изменения в окружении.

· Контролер, отвечающий за постоянное сравнение всех проходящих клю-чевых преобразований с планом, а также эа необходимые изменения в плане в соответствии с потребностями организации.

Помимо собственно команды проекта, в организации должны существо-вать некоторые формальные структуры, каждая из которых выполняет опреде-ленные руководящие и контролирующие функции. Обычно создаются такие структуры, как Управляющий или Информационный комитет, утверждающий об-щий ИТ-бюджет и ИТ-стратегию коипании, и Совет по архитектуре (или Техниче-ский комитет), который следит за организацией процесса разработки архитек-туры, а также рассматривает и санкционирует отклонения от утвержденной ар-хитектуры.

Важно подчеркнуть, что, хотя команда проекта разработки архитектуры и выполняет основную работу, она, как правило, не является собственником этого процесса и результатов. Целесообразно, чтобы ее результаты были сформирова-ны в виде рекомендаций, подлежащих утверждению высшим руководством ор-ганизации для придания определенной значимости и легитимности. Более того, команда проекта или служба Главного Архитектора не должна сама выполнять «полицейские» функции в случае несоответствия проектов утвержденным архи-тектурным стандартам. Если вы решили, что Архитектура предприятия должна затрагивать еще партнеров и поставщиков, то, следовательно, это потребует определенного уча-стия их представителей в работе. Или наоборот, вы сознательно выберете некую часть предприятия, наиболее важную, и только часть бизнес--процессов организации.

Дата добавления: 2015-04-25