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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1.1

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

Подход	Преимущества	Недостатки
(1)	(2)	(3)
«сверху-вниз»	С самого начала создается ясное ви-дение существующей ситуации в це-лом C самого начала сформулированы бизнес-потребности и проблемы С самого начала задаются широкие рамки процесса с необходииой под-держкой высшего руководства	Процесс может носить весьма абст-рактный характер (выбор методик, типов моделей и пр.) Маловероятно, что будут получены яв-ные, видимые результаты в течение первого года работ Может сложиться впечатление, что результатом проекта являются никому не нужные документы Процесс сбора информации приво-дит к задержкам в построении струк-тур управления архитектурныи про-цессом Использование формальных методо-логий требует обучения Использование многих формальных методик требует наличия навыков и опыта в реинжиниринге бизнес-про-цессов

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

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

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

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

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

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

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

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

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

· формирование структур и процессов управления и контроля (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) инструменты и механизмы.

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

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

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

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

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

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

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