Определение границ архитектуры и используемых методик
Следующий важный элемент, с которым необходимо определиться, – это границы архитектуры. Например, если вы отвечаете за разработку архитектуры электронного правительства на региональном, городском уровне, то, возможно, вы сознательно сосредоточите основные усилия в разработке архитектуры на вопросах, связанных с межведомственным информационным взаимодействием (как, например, это сделано в проекте e-GIF проекта электронного правительства Великобритании).
Если вы решили, что архитектура предприятия должна затрагивать ваших партнеров и поставщиков, то, следовательно, это потребует определенного участия их представителей в работе. Или наоборот, вы сознательно выберете некую часть предприятия, наиболее важную в каком-то смысле, и только часть бизнес-процессов организации.
Предположим, что команда проекта разработки архитектуры сформирована и готова начать свою работу. Как и для традиционных проектов, прежде всего следует обеспечить формализацию этого процесса путем составления и утверждения устава проекта. Такой устав определяет задачи проекта, график выполнения, используемый подход и процедуры, а также фиксирует тот факт, что эта деятельность поддержана руководством организации. Соответственно, такой устав должен будет периодически, обычно раз в год, пересматриваться и утверждаться Управляющим комитетом организации.
При переходе к практической реализации очевидно, что для достижения конечной цели необходимо предварительно определить некоторую согласованную основу. В качестве такой основы может выступить набор архитектурных моделей высокого уровня.
|
|
|
Сформированный таким образом набор моделей документируется в произвольном формате, например, в виде обычного файла текстового редактора. Поскольку его основным назначением является использование для широкого обсуждения не только внутри команды проекта, но и с представителями различных подразделений, то применение специализированных средств моделирования на данном этапе может затруднить взаимодействие из-за отсутствия у всех участников необходимой подготовки и установленных специализированных средств. Например, даже применение UML-диаграмм может быть избыточно сложным для обсуждения со специалистами бизнес-подразделений.
Еще раз стоит подчеркнуть, что на данном этапе не следует углубляться в излишнюю детализацию. Напротив, более важным является "расширение" области охвата. При этом временные рамки этапа также должны быть четко определены и ограничены – так, что даже для больших компаний срок реализации этапа с учетом обсуждений и согласований не должен превышать трех месяцев, а для мелких и средних – значительно меньше.
|
|
|
Другой важной задачей начального этапа будет выбор и согласование внутри команды наиболее подходящей методики или модели (framework) для детального описания архитектуры. Какой-либо одной, обязательной к применению методики не существует – каждая организация вправе выбирать ту, которая наиболее для нее удобна. Самым целесообразным будет выбор одной из методик в качестве основной с дополнением элементов других методик. Необходимым шагом будет документирование выбранного решения (или точнее, выбранного подмножества) с тем, чтобы это краткое, не более чем на 10 страниц, описание могло быть использовано командой проекта в качестве методологической основы.
Другими важными документами, которые будут использоваться в качестве основы, являются:
1. стратегия коммуникации, то есть распространения информации по проекту внутри организации с учетом потребностей в информации всех заинтересованных участников – то есть, с самого начала проекта необходимо предусматривать шаги для обеспечения внедрения его результатов;
2. процедуры рассмотрения и разбора исключительных ситуаций и отклонений от стандартов архитектуры.
|
|
|
В целом для успеха архитектурного проекта необходимы следующие пять элементов:
1. тщательное планирование;
2. адекватное финансирование и обеспечение ресурсами (участники, время);
3. мотивация и реализация ("кнут и пряник");
4. талант и квалификация команды;
5. видение цели.
Реальный эффект достигается за счет синергетического сочетания всех этих элементов, так что отсутствие или недостаточность отдельных частей может приводить к следующим вариантам неудач:
1. недостаточное финансирование и нехватка ресурсов, как правило, приводит к тому, что проект ограничивается решением тактических задач на уровне ИТ-службы, типа выбора версии того или иного продукта без учета реальных бизнес-потребностей. Будущая архитектура будет нечетко определена и не позволит получить реальную отдачу при практической реализации;
2. недостаточная мотивация персонала команды может быть связана с ощущением "работы на полку" – если разработанные архитектурные решения не будут поддержаны соответствующими организационными мерами и политикой реализации на практике;
3. страх перед изменениями – предлагаемые решения не должны восприниматься как невозможные. Предлагаемые изменения должны быть поддержаны соответствующим развитием квалификации;
4. распыленность – изменения, как правило, являются достаточно болезненными и поэтому будут объективно затягиваться под различными предлогами без принятия соответствующих мер. Важным является четкое фокусирование на конечной, определяемой видением, цели, – иначе многие реализуемые инициативы могут быть проведены впустую.
Дата добавления: 2019-02-12; просмотров: 93; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!