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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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