Кпр. Архитектура (копия). Treasury Enterprise Architecture

• Название: Treasury Enterprise Architecture
• Дата: 19.12.2022
• Размер: 0.74 Mb.
• Имя файла: Архитектура (копия).docx
• Тип: Руководство; #852858
• страница: 2 из 6

DoDAF (англ. Department of Defense Architecture Framework, Архитектурный фреймворк Министерства обороны США) — это архитектурный, комплексный и всеобъемлющий фреймворк (методология), позволяющий Министерству обороны США облегчить управление на всех уровнях, что позволяет принимать более эффективные ключевые решения[1]. Это достигается путем организации эффективной передачи информации через Департаменты, JCAs, Миссии, Компоненты и Программные связки ("Program boundaries"). Визуализация и отображение архитектурных данных производится с помощью моделей (так называемых «продуктов» в предыдущих версиях фреймворка). 
DoDAF предназначен для составления архитектурного описания системы. Результатом его применения будет являться набор документов, а не информационная система.
Модели в понимании DoDAF-методологии — это документы, таблицы и любые другие графические отображения, которые используются в роли шаблона для организации и отображения данных в более понятном виде. Когда данные собраны, заполнены и показаны в моделях, результат называют представлением («view»). Собрание таких представлений (часто – процессов, систем, сервисов, стандартов и так далее) относится к точкам зрения («viewpoints») и с соответствующими определениями все вместе называются Архитектурным Описанием.

DoDAF использует мета-модель данных (Data Meta-Model – DM2), которая является онтологией(набор структурированных данных), составленной из уровней, отражающих особенности представления информации для конкретных групп пользователей. При необходимости, DM2 может быть расширена.

Базовые принципыПравить

Существует восемь базовых принципов (советов), руководствуясь которыми, можно успешно применять DoDAF: 

1. 
   Архитектурное описание должно быть чётко ориентировано на провозглашённые цели.
   
2. 
   Архитектурное описание должно быть по возможности простым и понятным, но не упрощённым.
   
3. 
   Архитектурное описание должно облегчать, а не затруднять процесс принятия решений.
   
4. 
   Архитектурное описание должно быть составлено таким образом, чтобы его можно было использовать для сравнения различных архитектур. При составлении архитектурного описания должны в максимальной степени использоваться стандартные типы данных, определяемые в DM2.
   
5. 
   Архитектурное описание должно выполняться в терминах самих данных, а не инструментальных средств работы с данными.
   
6. 
   Архитектурные данные должны быть организованы в виде, удобном для групповой работы.
   
7. 
   Архитектура информационных систем
   
8. 
   Архитектурное описание должно быть построено таким образом, чтобы его можно было использовать в сетевой среде.
   
9. 
   Этапы описания и построения архитектуры предприятия по DoDAFПравить
   
10. 
    
    
11. 
    Графическое представление этапов построения и описания архитектуры предприятия в методологии DoDAF[4]
    
12. 
    Определить планируемое использование Архитектуры;Править
    
13. 
    Данный шаг определяет то, как разрабатываемую Архитектуру будут использовать. Исследование проводится с целью покрыть требования по использованию на дальнейших шагах («Fit-for-Purpose»).
    
14. 
    Определить контекст Архитектуры;Править
    
15. 
    Данный шаг определяет глубину и размах описания Архитектуры и устанавливает набор проблем, помогает узнать контекст и уровень детализации, требуемый для данного контекста.
    
16. 
    Определить данные, требуемые для поддержки разработки Архитектуры;Править
    
17. 
    После того, как требуемый уровень детализации Архитектуры определен, встает вопрос, какие данные и типы данных для Архитектуры требуются. Данных шаг отвечает на этот вопрос.
    
18. 
    Собрать, организовать, привести в соответствие изначальному плану («correlate») и хранить данные Архитектуры;Править
    
19. 
    Данный шаг включает в себя создание классификации данных: сбор и сортировку (классификацию) данных. На этом шаге и также проводятся работы по классификационному хранению отсортированных данных.
    
20. 
    Провести анализ поддержки целей создания Архитектуры;Править
    
21. 
    На данном шаге проводится анализ по отклонениям от изначальных целей и требований по созданию и поддержке Архитектуры.
    
22. 
    Представить результаты в соответствии с нуждами блока принятия решений;Править
    
23. 
    На данном шаге Архитектура разрабатываемой системы презентуется лицам, отвечающим за принятие решений в понятном для них виде.
    

Цикл разработки архитектуры.

Процесс разработки архитектуры включает следующие фазы:

Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.

· Фаза 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. Техническая архитектура описывает программное обеспечение и оборудование, которое необходимо для развертывания бизнес-сервисов, сервисов данных и приложений. Она включает в себя ИТ-инфраструктуру, сервера приложений, сети, телекоммуникации, стандарты и т.д.

Процессы, управляющие процессами. Новые типы процессов - процессы соответствия.

Актуальность разработки ИТ-стратегии и ИТ-архитектуры.

Актуальность разработки ИТ-стратегии и формирования ИТ- архитектуры определяется рядом факторов, основные из которых связаны с происходящими изменениями в самом бизнесе и индустриальном обществе; изменением роли информационных технологий в бизнесе и обществе; изменением корпоративной культуры и стиля управления в бизнесе; а также с объективным увеличением ИТ-бюджетов компаний. К числу характерных изменений бизнеса, которые оказывают существенное влияние на использование информационных технологий, относятся: • глобализация бизнеса, связанная с необходимостью объединения различных национальных процессов, данных и персонала; • динамика слияний и поглощений, приводящая к объективно необходимой интеграции различных информационных систем, объединению ИТ-служб и, что является наиболее сложным, интеграции различных корпоративных культур; • появление адаптивного стиля бизнеса - переход от модели, основанной на имеющейся линейке продуктов (т.н. "make-and- sell"), к модели, основанной на гибком реагировании на потребности рынка - ("sense-and-respond"). Этот стиль связан с признанием неизбежности и непредсказуемости изменений во внешней среде. Компании, принявшие такую модель, связывают достижение успеха с осуществлением таких преобразований в бизнес-процессах и организационной структуре, которые могли бы оперативно и адекватно подстраиваться под происходящие изменения; • сокращение длительности бизнес-процессов и виртуализация бизнеса («Динамичность предприятия», Enterpriseagility и «Предприятие реального времени», Real-TimeEnterprise, RTE). Рассмотрим последнее утверждение более подробно. Под динамичностью предприятия понимается способность предприятия к быстрой реализации бизнес-инициатив с широким использованием возможностей интеграции. На практике это означает концентрацию на основных компетенциях, максимально возможную передачу непрофильной деятельности внешним поставщикам услуг (аутсорсинг), а в ряде случаев и аутсорсинг управления проектами, систематическую разработку и реализацию инноваций, активность в образовании альянсов, в том числе частичное сотрудничество с конкурентами, а так же расширение полномочий нижестоящих менеджеров - иерархическая структура управления как бы "раздается вширь" и максимальное использование опыта и способностей всех сотрудников. Существенное сокращение характерного времени изменения для бизнес-процессов и организационной структуры компании - с 10 лет до 3 лет, с перспективой дальнейшего сокращения до полутора-двух лет. Очевидное несоответствие между временными рамками краткосрочного планирования ИТ в рамках годовых бюджетов и реализацией крупных ИТ-проектов - таких, как внедрение ERP-систем, требующих 2-5 лет. Современные условия бизнеса характеризуются существенным сокращением времени выполнения всех процессов. Типичные деловые транзакции занимают секунды вместо дней, сроки жизни продуктов снижаются с десятилетий до десятков месяцев, преобразования в организациях становятся все более частыми и также реализуются в течение нескольких месяцев вместо нескольких лет, требовавшихся ранее. Изменения в окружающей среде все чаще случаются за более короткие промежутки времени, чем организация способна отреагировать. Это и является причиной того, что время, требующееся для перехода на новые бизнес-процессы и для реализации бизнес-стратегии, является новым узким местом. Предприятие реального времени регистрирует и анализирует явные события и их первопричины, которые являются критичными для его успеха, в момент их возникновения, для того чтобы определить новые возможности, избежать ошибок и минимизировать задержки в выполнении основных бизнес-процессов. Затем предприятие реального времени использует эту информацию для дальнейшего сокращения задержек в управлении и выполнении ключевых процессов. Основной критический фактор для обеспечения функциональности предприятия реального времени будет связан с развитием коммуникационных возможностей и системами электронного документооборота. Концепция предприятия реального времени базируется на интеграции практически всего, что связано с деятельностью организации: инфраструктуры, систем, информации, процессов и людей. А основой этого как раз и является архитектура информационных технологий, а в более широком смысле -архитектура предприятия в целом. Другое важное следствие - переход к сервис-ориентированной архитектуре (Service Oriented Architecture) - когда функции системы реализуются в виде сервисов (услуг), доступных другим информационным системам. Технологической основой такого взаимодействия между системами по принципу предоставления услуг друг другу является технология веб-сервисов, влияние которой на будущую архитектуру ИТ предприятий можно сравнить разве что с влиянием Интернет на мировые коммуникации. Бизнес-стратегии "динамичного предприятия" с большой вероятностью будут включать реализацию таких проектов, как внедрение систем управления отношениями с клиентами и управления цепочками поставок, организацию виртуальных команд разработчиков и специалистов, расположенных в разных частях страны или даже мира, централизацию общих служб поддержки и сервисов, агрессивное приобретение и интеграцию других компаний. Реализация всех этих принципов основана на широком использовании возможностей и средств информационных систем организации.

Бизнес-стратегия и информационные технологии. Основные понятия ИТинфраструктуры предприятия.

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

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

chernogolovka.com реклама Подробнее

РЕКЛАМА