ПОЗНАВАТЕЛЬНОЕ

Оси и плоскости тела человека - Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.

Отёска стен и прирубка косяков - Когда на доме не достаёт окон и дверей, красивое высокое крыльцо ещё только в воображении, приходится подниматься с улицы в дом по трапу.

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

Общая схема архитектурного процесса

Модель процесса разработки и использования архитектуры

Какое бы определение Архитектуры предприятия мы, в конечном итоге, ни выбрали, общими для всех методик описания архитектуры является систематическое и рекурсивное применение таких принципов, как:

декомпозиция на различные представления архитектуры (предметные области): область прикладных систем, технологическая архитектура и т.д.;

различные уровни детализации и абстракции для описания каждой из этих областей.

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

Рис. 3. Схема процесса разработки архитектуры и стратегии ИТ

Эта схема состоит из следующих шагов:

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

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

На основе этого анализа формулируются в самом общем виде требования к информационным технологиям с точки зрения информации (данных) и архитектуры ИТ.

Принимаются общие для организации стандарты и понятия о том, что такое Архитектура предприятия: принципы, общие методы описания архитектуры и ее разделы, стандарты, конкретные продукты и технологии.

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

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

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

После этого начинается фаза реализации конкретных проектов в рамках выработанной на данный момент архитектуры предприятия.

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

Основой работы на этих этапах является эволюционный, итеративный процесс, связанный с определением и описанием текущего и желаемого состояния архитектуры, совмещенный с процессом анализа результатов, идентификацией направлений и планов развития (Gap-анализ), который обеспечит синхронизацию архитектуры с изменениями в функциях подразделений, с изменениями в бизнес-требованиях и изменениями в технологиях. Этот процесс условно показан на рис. 4.

Рис. 4. Общая схема процесса разработки архитектуры

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

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

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

Архитектура задает цели для отдельных проектов и инициатив, но важна и обратная связь: систематический анализ опыта реализации отдельных проектов и систем является неотъемлемой частью всего процесса планирования и разработки архитектуры.

Ниже описаны этапы каждой итерации процесса разработки и обновления архитектуры, которые следуют, в основном, рекомендациям META Group. Характерными для этого подхода элементами описания архитектуры являются такие документы, как Общее видение и Концептуальная архитектура. Заметим, что, даже в случае выбора какой-то другой методики, вам скорее всего придется создавать аналоги этих документов. Каждая итерация включает:

Этап 1: Описание или уточнение Общего видения (видение общих требований к архитектуре).

Этап 2: Описание или уточнение Концептуальной архитектуры, а также разработка и уточнение архитектуры отдельных представлений (или предметных областей, доменов): бизнес-архитектура, архитектура информации, архитектура приложений, технологическая архитектура и пр.

Этап 3: Разработка или уточнение Плана реализации.

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

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

Этап 1: Разработка Общего видения архитектуры

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

Основными элементами Общего видения являются:

описание технологических тенденций, важных для предприятия;

идентификация бизнес-требований и стратегий;

идентификация основных требований к информации и технологиям, которые важны с точки зрения реализации бизнес-стратегий;

идентификация требований к архитектуре предприятия в целом.

Этап 2: Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей

На этом этапе ведется параллельная разработка Концептуальной архитектуры, основанной на ранее определенных принципах и лучших практиках, а также более детальная проработка Архитектур отдельных предметных областей.

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

Заметим, что основой разработки архитектур отдельных предметных областей (доменов) служит Концептуальная архитектура.

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

Этап 3: Разработка Плана реализации

Этап 3 включает в себя следующие два шага:

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

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

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

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

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

Направления разработки архитектуры: "сверху-вниз" или "снизу-вверх"

В общем виде можно сказать, что существуют два принципиально различных подхода в разработке архитектуры предприятия [6.6]:

Подход "сверху-вниз" предполагает достаточно широкий охват проблем и точное следование формальному процессу. Основу этому подходу положили методики Захмана и Спивака. Он начинается со сбора информации, требующейся для описания различных доменов архитектуры "как есть". Далее следует этап, связанный с описанием и реинжинирингом бизнес-процессов, консолидации прикладных систем, выстраивание архитектуры данных и, наконец, стандартизация технологической архитектуры. Например, многие государственные проекты ориентированы на этот подход (например, в США в рамках Федеральной архитектуры FEAF).

Подход "снизу-вверх", когда процесс начинается со стандартизации инфраструктурных технологий (технологическая архитектура), а затем развивается в направлении решения проблем более высокого уровня и, в конечном итоге, решает вопросы, связанные с бизнес-архитектурой. Этот подход, видимо, имеет более широкое распространение в бизнесе и в частном секторе.

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

Архитектура предприятия как планирование города

Большое количество авторов указывает на поразительную аналогию архитектурного процесса, связанного с использованием информационных технологий на достаточно крупном предприятии или в области государственного управления, и процесса архитектурного планирования города [6.7], [6.8],[6.9], [6.10]. Мы думаем, что эта метафора будет небезынтересна читателям так же, как и предыдущее сравнение двух подходов "сверху-вниз" и "снизу-вверх" при организации работ над архитектурой.

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

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

Если вы пройдетесь по Москве или Санкт-Петербургу, то увидите удивительное разнообразие зданий, построенных в разные эпохи: древние монастыри и Кремль Москвы, классический стиль зданий, построенных после пожара в Москве 1812 года или дворцов в Санкт-Петербурге, ампир и, наконец, современные бизнес-центры, не говоря уже о скучных спальных районах застройки 60-80-х годов прошлого века. Очевидно, что хотя подавляющее большинство зданий было построено в течение последних ста лет, но, тем не менее, заложенная веками ранее инфраструктура – основные улицы и мосты, некоторые архитектурные доминанты – до сих пор определяют то, как развиваются два этих города. Москва, например, не потеряла своей радиальной структуры, точно так же как и Санкт-Петербург – свои прямые проспекты. Очевидно, что люди, которые занимались все эти годы городским управлением, старались сохранять и в какой-то степени развивать оставленное им наследство и добавлять новые необходимые элементы.

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

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

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

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

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

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

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

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

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

Какие уроки можно извлечь из этой аналогии архитектуры информационных систем предприятия и городского планирования?

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

Второе: помните о том, что разнообразие систем и платформ – это неизбежность для предприятия, так что интеграции нельзя достичь выбором единой платформы и технологии. У вас будет много "зданий" разных цветов и архитектуры. Думайте об архитектуре интеграции, которая основана не на единстве платформ, а на принципах сервис-ориентированной архитектуры.

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

Четвертое: важность стабильной инфраструктуры. Инфраструктура ИТ должна обслуживать текущие потребности и в какой-то степени предвосхищать будущие потребности в системах.

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

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

С чего начать?

В самом начале проекта (процесса) разработки архитектуры организации очень часто стремятся как можно скорее выбрать одну из известных на рынке методик или создать на их основе свою собственную. Однако в действительности есть несколько "более первоочередных" моментов, важных для успеха проекта в целом:

· обоснование необходимости проекта и факторов, влияющих на разработку архитектуры;

· формирование команды проекта разработки архитектуры;

· определение границ архитектуры и используемых методик;

· формирование структур и процессов управления и контроля (governance) (этому посвящен особый раздел).

Обоснование необходимости проекта разработки архитектуры и факторы влияния

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

Основная сложность обоснования необходимости архитектурного проекта и выделения соответствующих инвестиций связана с тем, что прогнозируемые результаты обычно предполагают косвенное улучшение бизнеса организации, то есть являются, как правило, качественными и редко могут быть связаны с конкретными финансовыми выгодами. Даже в том случае, когда бизнес-показатели типа "увеличение стоимости акций компании" или "доля на рынке" измеримы, конкретные связи между ними и проведенным реформированием архитектуры предприятия обычно бывают трудно доказуемы. Доля таких компаний не превышает величины порядка 5%. При этом аналитики МЕТА отмечают, что в настоящее время более чем в 70% компаний ИТ-служба все еще является центром затрат, а более 90% ИТ-служб не имеют согласованных с бизнес-руководством финансовых моделей, позволяющих количественно измерить эффект от внедрения ИТ для бизнеса.

С точки зрения обоснования цифр экономии практически невозможно дать какие-то общие, применимые на все случаи, оценки затрат, связанных с отсутствием архитектуры ИТ. Это зависит от уникальности ситуации в каждой конкретной организации. Экономия может быть достигнута, в частности, за счет сокращения расходов, связанных с повторным использованием оборудования или программного обеспечения, за счет сокращения времени разработки, оптимизации расходов на ведение проектов, снижения стоимости технической поддержки, приобретения новых активов или экономии за счет более простой адаптируемости системы, построенной на базе единой архитектуры, к изменению требований бизнеса. Последняя составляющая выгоды обычно становится заметной при сравнении затраченных усилий, средств и времени для проведения изменений в различных подразделениях организации с отличающимися исходными архитектурами. В целом, по данным опроса META, снижение величины расходов на ИТ в расчете на одного сотрудника в случае реализации единой корпоративной архитектуры может достигать величины порядка 30%. По оценке Gartner отсутствие архитектуры приводит к 12-18% дополнительных затрат, связанных только с эксплуатацией ИТ-инфраструктуры.

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

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

Инвестиции в архитектуру предприятия, эффект от использования которой может быть не столь очевиден в течение трех-пяти лет, требуют иных мер оценки эффективности. Возможной стратегической альтернативой является величина "Возврата на основные фонды" (ROA – Return on Assets), которая будет стимулировать компанию оценивать архитектуру ИТ с точки зрения повышения эффективности своих основных фондов. Другим полезным показателем может быть "Возврат на возможность" (Return on opportunity). Он не является формальной финансовой метрикой, но описывает влияние инвестиций на бизнес. Подробнее обсуждение возможных финансовых инструментов содержится в курсе "ИТ-стратегия".

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

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

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

Формирование команды проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение границ архитектуры и используемых методик

Следующий важный элемент, с которым необходимо определиться, – это границы архитектуры. Например, если вы отвечаете за разработку архитектуры электронного правительства на региональном, городском уровне, то, возможно, вы сознательно сосредоточите основные усилия в разработке архитектуры на вопросах, связанных с межведомственным информационным взаимодействием (как, например, это сделано в проекте e-GIF проекта электронного правительства Великобритании).

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

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

При переходе к практической реализации очевидно, что для достижения конечной цели необходимо предварительно определить некоторую согласованную основу. В качестве такой основы может выступить набор архитектурных моделей высокого уровня [6.11].

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

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

Другой важной задачей начального этапа будет выбор и согласование внутри команды наиболее подходящей методики или модели (framework) для детального описания архитектуры. Какой-либо одной, обязательной к применению методики не существует – каждая организация вправе выбирать ту, которая наиболее для нее удобна. Самым целесообразным будет выбор одной из методик в качестве основной с дополнением элементов других методик. Необходимым шагом будет документирование выбранного решения (или точнее, выбранного подмножества) с тем, чтобы это краткое, не более чем на 10 страниц, описание могло быть использовано командой проекта в качестве методологической основы.

Другими важными документами, которые будут использоваться в качестве основы, являются:

· стратегия коммуникации, то есть распространения информации по проекту внутри организации с учетом потребностей в информации всех заинтересованных участников – то есть, с самого начала проекта необходимо предусматривать шаги для обеспечения внедрения его результатов;

· процедуры рассмотрения и разбора исключительных ситуаций и отклонений от стандартов архитектуры.

В целом, как отмечается в публикации [6.12], для успеха архитектурного проекта необходимы следующие пять элементов:

· тщательное планирование;

· адекватное финансирование и обеспечение ресурсами (участники, время);

· мотивация и реализация ("кнут и пряник");

· талант и квалификация команды;

· видение цели.

Реальный эффект достигается за счет синергетического сочетания всех этих элементов, так что отсутствие или недостаточность отдельных частей может приводить к следующим вариантам неудач:

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

· недостаточная мотивация персонала команды может быть связана с ощущением "работы на полку" – если разработанные архитектурные решения не будут поддержаны соответствующими организационными мерами и политикой реализации на практике;

· страх перед изменениями – предлагаемые решения не должны восприниматься как невозможные. Предлагаемые изменения должны быть поддержаны соответствующим развитием квалификации;

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