«У нас в ИТ все хорошо» (или, более вероятно, «у нас в ИТ все плохо»). «Чем мне может помочь архитектура? Только время зря потратим. И без нее забот достаточно. Модные эти словечки— ‘архитектура’ и ‘стратегия’— от консультантов, которые хотят раскрутить нас на деньги. Лучше сервер куплю или сетку новую сделаю».

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

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

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

Об архитектуре предприятия (Enterprise Architecture) говорят сегодня все, кому не лень, и хотя в западных статьях эту даму все чаще величают зрелой матроной, единое представление о ней пока не сложилось. Бывает и так, что приходит консультант и спрашивает у руководства компании: «А у вас архитектурная модель есть?» И руководство начинает лихорадочно вспоминать, где у него начальник отдела капитального строительства.

Это, однако, не означает, что архитектурная модель как орден на груди предприятия— построил, и все сразу стало хорошо. Это скорее автомобиль, который может помочь компании «приехать» к светлому будущему. Но как всякий автомобиль, он требует топлива, регулярного техобслуживания и, что немаловажно, умения ездить. Конечно, иногда архитектурные модели просто ставятся в шкаф и показываются партнерам и клиентам, на которых надо произвести впечатление. Впрочем, подобная судьба складывается и у некоторых автомобилей. Но все-таки намного полезнее заставить архитектурную модель «ездить».

Понятие архитектура, выйдя из области строительства зданий, расширилось до описания любой системы. Существует множество определений этого термина; наверное, наиболее популярно определение IEEE: «Архитектура— это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие ее проектирование и развитие» (IEEE 1471, standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html). Как обычно, одно определение тянет за собой другое, поэтому приведу также определение системы, взятое из того же источника: «Система— это набор компонентов, объединенных для выполнения отдельной функции или набора функций... Система существует для выполнения одной или более миссий в своем окружении». Очевидно, что такое определение системы идеально подходит для любого предприятия.

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

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

Поэтому так важна общая картина предприятия, а именно, его архитектура.

В следующий раз мы поговорим об определениях архитектуры предприятия и о ее составе.

Есть у любой компании натура:
характер, вдохновение, полет.
понять все это сможет только тот,
кто разглядит ее архитектуру.

Марина Аншина (anshina@sibur-rt.ru)— начальник Управления ИТ ОАО «Сибур— Русские шины», президент фонда ФОСТАС, автор книги «Технология создания распределенных систем» и статей по тематикам стратегии и архитектуры ИТ, оценки эффективности и рисков проектов ИТ, технологии CORBA и компонентного программного обеспечения.