Опубликован: 07.05.2007 | Доступ: свободный | Студентов: 10802 / 2785 | Оценка: 4.16 / 3.71 | Длительность: 23:54:00
ISBN: 978-5-9556-0045-1
Специальности: Руководитель
Лекция 10:

Процесс разработки архитектур: цели и задачи, общая схема

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

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

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

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

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

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

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

Другой важной задачей начального этапа будет выбор и согласование внутри команды наиболее подходящей методики или модели (framework) для детального описания архитектуры. Ранее в "Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF" , "NASCIO. Модели "4+1" и SAM. Методики Microsoft и другие. Выбор "оптимальной" методики" мы уже рассмотрели несколько распространенных методик и даже указали некоторые сравнительные характеристики. Какой-либо одной, обязательной к применению методики не существует – каждая организация вправе выбирать ту, которая наиболее для нее удобна. Самым целесообразным будет выбор одной из методик в качестве основной с дополнением элементов других методик. Необходимым шагом будет документирование выбранного решения (или точнее, выбранного подмножества) с тем, чтобы это краткое, не более чем на 10 страниц, описание могло быть использовано командой проекта в качестве методологической основы.

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

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

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

  • тщательное планирование;
  • адекватное финансирование и обеспечение ресурсами (участники, время);
  • мотивация и реализация ("кнут и пряник");
  • талант и квалификация команды;
  • видение цели.

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

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

Примерная структура описания ИТ-архитектуры

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

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

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

Грета Березовская
Грета Березовская
Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?