Как обеспечить внедрение результатов проекта разработки архитектуры

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

Обеспечение поддержки усилий по разработке архитектуры предприятия предполагает знания того, что действительно важно для людей, которые могут способствовать или " блокировать" процесс принятия соответствующих решений [6.22]. Этих людей можно условно разделить на три группы:

· руководство организации и руководители бизнес-направлений;

· среднее звено управления бизнесом;

· различный технический персонал, а также " продвинутые и влиятельные" пользователи.

В частности, высших руководителей в отношении архитектуры, как правило, интересуют три основные цели: сохранение своей автономии, минимизация затрат на ИТ и отсутствие препятствий со стороны ИТ в плане гибкости или надежности. Для обеспечения поддержки этой категории людей важны такие вещи, как примеры удачного опыта (case studies), сравнение с другими передовыми организациями (benchmarking), улучшение финансовых показателей и продуктивности.

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

Таблица 11.4. Различия в ожидании преимуществ от архитектуры
	Высшее руководство	Руководители бизнес-подразделений	Участники разработки приложений	Специалисты по эксплуатации ИТ
Повышение способности к взаимодействию
Стоимость владения ИС
Гибкость и масштабируемость
Быстрота разработки
Соответствие бизнесу
Эффективное использование ресурсов
Безопасность
Риск
Инновации в бизнесе

Специалисты Gartner рекомендуют апеллировать к специфическим для каждой отдельной группы участников аргументам в пользу архитектуры предприятия.

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

Достаточно очевидным является влияние определенной архитектуры на совокупную стоимость владения информационной системой. Действительно, единые стандарты на оборудование и программное обеспечениепозволяют получать дополнительные количественные скидки от вендоров, упрощают мониторинг и обслуживание систем, а также позволяют оптимально организовать обучение. Время разработки и внедрения компонентсистемы также может быть существенно снижено при реализации на практике стандартных подходов и четкого разделения системы на логические уровни. Аналогичные взаимоотношения достаточно легко прослеживаются и для остальных отмеченных критических факторов. Поэтому важным условием успеха " внутренней продажи" концепции архитектуры в рамках организации будет концентрация фокуса на критичных для каждой группы ценностях и выбор правильного уровня детализации, в соответствии с ожиданиями и уровнем понимания слушателей. Разумеется, обязательным фактором успеха такого продвижения архитектурных идей будет прямаяподдержка высшего руководства.

Один хороший метод в объяснении важности архитектуры ИТ для бизнес-руководителей и неспециалистов в области ИТ сводится к двум темам [6.23]:

· архитектура и решение сложных проблем;

· влияние архитектуры на затраты.

Естественным ожиданием руководства является то, что ИТ обеспечивают некоторые важные услуги для деятельности организации на должном уровне надежности. Архитектура ИТ, описывающая все области, связанные с ИТ на предприятии, включает несколько уровней, или областей. Каждая новая область вносит новый уровень ненадежности и затраты на ее существование. Реальность состоит в том, что надежность всего комплекса ИТ определяется как произведение надежностей каждого уровня и, соответственно, ненадежность хотя бы одного из них " сводит на нет" усилия по обеспечению надежности всего комплекса ИТ. Поэтому некоторый уровень сложности и связанные с этим затраты при эксплуатации ИТ-инфраструктуры неизбежны.

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

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

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

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

Таблица 11.5.
Название	Типичная доля, %	Позиция по отношению к Архитектуре Предприятия	Решения
Техно-циники	5-10	Корпоративная архитектура – это очередная блажь, и ею не стоит заниматься вообще	Не пытаться убеждать напрямую в преимуществах архитектуры, а целенаправленно просвещать с целью превращения в " умеренных" на бизнес-примерах или же использовать давление через руководителей
Cтароверы	10-20	Наши существующие приложения, может, морально и устарели, но вполне адекватны, и их не нужно трогать	Превращение в сторонников путем последовательного убеждения на конкретных фактах, с уважением к их заслугам и демонстрацией способности справляться с возникающими рисками преобразований
Умеренные	50-60	В принципе интересно, но вряд ли получится у нас	Организация совместных команд, тщательное планирование процессов и обоснование эффекта
Технофилы	10-25	Я говорил об этом 5 лет назад, а меня даже не слушали!	Использовать энтузиазм, фокусируя их на решении отдельных выделенных задач как партнеров команды проекта

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

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

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