Опубликован: 07.05.2007 | Уровень: специалист | Доступ: платный
Лекция 10:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Денис Бочаров
Денис Бочаров
Россия
Анна Небеснюк
Анна Небеснюк
Россия, Софрино-1, Майская средняя, 2012