Кпр. Архитектура (копия). Treasury Enterprise Architecture
![]()
|
DoDAF (англ. Department of Defense Architecture Framework, Архитектурный фреймворк Министерства обороны США) — это архитектурный, комплексный и всеобъемлющий фреймворк (методология), позволяющий Министерству обороны США облегчить управление на всех уровнях, что позволяет принимать более эффективные ключевые решения[1]. Это достигается путем организации эффективной передачи информации через Департаменты, JCAs, Миссии, Компоненты и Программные связки ("Program boundaries"). Визуализация и отображение архитектурных данных производится с помощью моделей (так называемых «продуктов» в предыдущих версиях фреймворка). DoDAF предназначен для составления архитектурного описания системы. Результатом его применения будет являться набор документов, а не информационная система. Модели в понимании DoDAF-методологии — это документы, таблицы и любые другие графические отображения, которые используются в роли шаблона для организации и отображения данных в более понятном виде. Когда данные собраны, заполнены и показаны в моделях, результат называют представлением («view»). Собрание таких представлений (часто – процессов, систем, сервисов, стандартов и так далее) относится к точкам зрения («viewpoints») и с соответствующими определениями все вместе называются Архитектурным Описанием. DoDAF использует мета-модель данных (Data Meta-Model – DM2), которая является онтологией(набор структурированных данных), составленной из уровней, отражающих особенности представления информации для конкретных групп пользователей. При необходимости, DM2 может быть расширена. Базовые принципыПравить Существует восемь базовых принципов (советов), руководствуясь которыми, можно успешно применять DoDAF: Архитектурное описание должно быть чётко ориентировано на провозглашённые цели. Архитектурное описание должно быть по возможности простым и понятным, но не упрощённым. Архитектурное описание должно облегчать, а не затруднять процесс принятия решений. Архитектурное описание должно быть составлено таким образом, чтобы его можно было использовать для сравнения различных архитектур. При составлении архитектурного описания должны в максимальной степени использоваться стандартные типы данных, определяемые в DM2. Архитектурное описание должно выполняться в терминах самих данных, а не инструментальных средств работы с данными. Архитектурные данные должны быть организованы в виде, удобном для групповой работы. Архитектура информационных систем Архитектурное описание должно быть построено таким образом, чтобы его можно было использовать в сетевой среде. Этапы описания и построения архитектуры предприятия по DoDAFПравить ![]() Графическое представление этапов построения и описания архитектуры предприятия в методологии DoDAF[4] Определить планируемое использование Архитектуры;Править Данный шаг определяет то, как разрабатываемую Архитектуру будут использовать. Исследование проводится с целью покрыть требования по использованию на дальнейших шагах («Fit-for-Purpose»). Определить контекст Архитектуры;Править Данный шаг определяет глубину и размах описания Архитектуры и устанавливает набор проблем, помогает узнать контекст и уровень детализации, требуемый для данного контекста. Определить данные, требуемые для поддержки разработки Архитектуры;Править После того, как требуемый уровень детализации Архитектуры определен, встает вопрос, какие данные и типы данных для Архитектуры требуются. Данных шаг отвечает на этот вопрос. Собрать, организовать, привести в соответствие изначальному плану («correlate») и хранить данные Архитектуры;Править Данный шаг включает в себя создание классификации данных: сбор и сортировку (классификацию) данных. На этом шаге и также проводятся работы по классификационному хранению отсортированных данных. Провести анализ поддержки целей создания Архитектуры;Править На данном шаге проводится анализ по отклонениям от изначальных целей и требований по созданию и поддержке Архитектуры. Представить результаты в соответствии с нуждами блока принятия решений;Править На данном шаге Архитектура разрабатываемой системы презентуется лицам, отвечающим за принятие решений в понятном для них виде. Цикл разработки архитектуры. Процесс разработки архитектуры включает следующие фазы: Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта. · Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством. · Фаза B: разработка бизнес-архитектуры предприятия. Фаза C: разработка архитектуры данных и архитектуры приложений. Фаза D: разработка технологической архитектуры. · Фаза E: проверка возможности реализации предложенных решений. Фаза F: планирование перехода к новой системе. · Фаза G: формирование системы управления преобразованиями. · Фаза H: управление изменением архитектуры. Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные подпроцессы: Описание существующей технологической архитектуры. Реклама Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации. o Описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения. o Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах. o Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков. o Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок. · Формирование целевой технологической архитектуры. o Описание существующей системы в терминах TOGAF. Определение перспектив (представлений) архитектуры. o Формирование модели целевой архитектуры. Определение ИТ-служб (сервисов). o Подтверждение учета бизнес-требований. o Определение архитектуры и используемых блоков (шаблонов). o Проведение анализа расхождений (gap analysis). Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Это может быть вызвано как необходимостью учета других существующих стандартов предприятия, так и привлечением аутсорсинговых компаний к разработке архитектуры. Интересным примером может являться проект внедрения корпоративной ERP-системы. В этом случае необходимо определенное изменение порядка разработки – так, бизнес-архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D! Процесс разработки не заканчивается после выбора оптимальной архитектуры и разработки плана миграции. Необходимыми элементами являются задачи, выполняемые на фазах G и H. В частности, для обеспечения практического принятия архитектуры в организации и успеха проекта обязательным является формирование Системы управления реализацией архитектуры (Implementation Governance). Так, фаза G предусматривает следующие задачи: · Организация Совета по архитектуре, включающего представителей всех бизнес-подразделений и руководства. Этот Совет должен выполнять наблюдательную и координирующую роль. · Разработка конкретной реализации достаточно полного набора Архитектурных принципов на основе существующего шаблона (см. ниже). · Формирование Стратегии Соответствия Архитектуре, определяющей правила и рекомендации для оценки и выбора проектов в части их соответствия или несоответствия согласованной архитектуре, а также формальную процедуру проверки такого соответствия. Это похоже на жизненный цикл технологических стандартов германской архитектуры электронного правительства SAGA, и на правила использования стандартов: проект, который не полностью удовлетворяет всем обязательным стандартам, не может получить бюджетного финансирования. 2.Описание текущей архитектуры предприятия – архитектуры «как есть» Для описания текущей архитектуры предприятия – архитектуры «как есть» мы выделим 4 домена: 1. Бизнес-архитектура, содержит стратегию компании, подход к управлению, организационную структуру и ключевые бизнес-процессы. . Архитектура данных содержит описание логической и физической структуры данных компании, а также подход и средства управления данными. . Архитектура приложений показывает бизнес-приложения, развернутые в компании, их взаимодействие друг с другом, а также их связь с бизнес-процессами компании. 4. Техническая архитектура описывает программное обеспечение и оборудование, которое необходимо для развертывания бизнес-сервисов, сервисов данных и приложений. Она включает в себя ИТ-инфраструктуру, сервера приложений, сети, телекоммуникации, стандарты и т.д. Процессы, управляющие процессами. Новые типы процессов - процессы соответствия. Актуальность разработки ИТ-стратегии и ИТ-архитектуры.
Бизнес-стратегия и информационные технологии. Основные понятия ИТинфраструктуры предприятия. Если архитектура характеризует определенное состояние информационных технологий, то ИТ-стратегия задает направление для изменения этих состояний и правила таких переходов. Грубо говоря, если в отсутствие стратегии к цели может вести множество путей, то определенная стратегия позволяет выбрать только оптимальные. Образно говоря, архитектура и стратегия аналогичны силам "инь" и "янь" древнекитайской философии, которые характеризуют баланс сохранения и изменения. Все хорошее в этом мире строится на взаимодействии этих дополняющих друг друга сил. Архитектура информационных технологий обеспечивает определенный уровень стабильности, возможность сохранять высокую степень соответствия прикладных систем потребностям бизнеса, соответствие инфраструктуры потребностям прикладных систем. В то же время стратегия информационных технологий определяет необходимый процесс управляемых, целенаправленных изменений и прогресса в архитектуре и наборе прикладных систем и технологий, которые необходимы для удовлетворения будущих потребностей организации (воображаемое будущее).
|