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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1.1

«Плюсы» и «минусы» разных подходов при разработке архитектуры предприятия

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

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

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

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

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

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

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

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

· формирование структур и процессов управления и контроля (governance).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· архитектура новых систем будет проходить формальные процедуры кон-троля на эффективность.

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

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

· будут разработаны и поддерживаться стандарты и правила (политики).

· соответствие стандартам и правилам будет контролироваться.

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

· технологическая архитектура будет контролироваться на уровне предпри-ятия в целом.

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

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

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

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

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

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

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

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

Рис. 1.10. Управление и контроль на разных этапах разработки архитектуры предприятия

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

Интересными являются данные о том, какие механизмы - жестко контро-лируемое выполнение правил или информирование и общие рекомендации организации чаще применяют на практике для обеспечения соответствия техни-ческих решений архитектуре. В частности, опрос, проведенный в 2003 году ком-панией Gartner среди финансовых организаций, показал, что примерно 50-60% организаций реализуют механизмы жесткого контроля за соблюдением предпи-саний архитектуры. Примерно 20-25% используют такие механизмы как общие рекомендации, при этом подразделения несут дополнительные затраты, связан-ные с несоответствием проектов утвержденной архитектуре. Только в 15-25% организаций архитектура носит рекомендательный характер, и невыполнение рекомендаций не имеет никаких явных организационных последствий.

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

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

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

Рис. 1.11. Организационная структура управления разработкой архитектуры предприятия

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

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

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

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

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

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

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

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

Таким образом, постоянная работа непосредственно над архитектурой с организационной точки зрения ведется как бы на трех уровнях:

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

· уровень внесения существенных изменений в архитектуру;

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

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

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

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

· делаются определенные изменения в архитектуре с учетом накопленного опыта;

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

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

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

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

Рис. 1.12. Модель рассмотрения архитектуры от Giga Group

Ядро архитектуры (центральная зона) - это те архитектурные решения, технологии, стандарты, которые в данный момент времени приняты организаци-ей в качестве стратегических.

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

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

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

· инвестиции в достаточной мере соответствуют архитектуре и могут быть рекомендованы;

· новые инвестиции отклонены из-за плохого соответствия архитектуре; инвестиции признаны необходимыми даже в условиях несоответствия Ар-хитектуре, и в Архитектуру вносятся изменения, чтобы отразить это несо-ответствие, описать новые функции, объекты данных и необходимые при-ложения;

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

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

Более развернутые рекомендации по контролю соответствия содержатся в модели TOGAF, где описаны два основных процесса:

· формализованная проверка проекта на соответствие архитектуре;

· оценка влияния архитектуры на проекты.

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

· соответствие развития системы утвержденной стратегии;

· обеспечение необходимой функциональности;

· приверженность стандартам и архитектурным принципам.

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

Рис. 1.13. Возсможные соотношения между реализацией и описанием архитектуры по TOGAF

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

· уменьшение проектных рисков за счет идентификации ошибок и «узких мест» в архитектуре разрабатываемой системы;

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

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

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

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

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

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

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

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

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

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

Текущие затраты на сопровождение Архитектуры включают:

· обеспечение поддержки Архитектуры со стороны сотрудников ИТ-службы и бизнес-подразделений;

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

· проведение анализа и контроль соответствия архитектурных решений от-дельных проектов;

· обучение и оценка результатов;

· подготовка планов технологического развития, связанных с новыми техно-логиями.

Все это имеет отношение как к коммерческим, так и к государственным ор-ганизациям.