Современные методики описания архитектуры предприятия
жүктеу/скачать 135,46 Kb.
|
СРО
КЛИНИКАЛЫҚ ЕСЕПТЕР сұрақ, БЖБ№3 Қаз тарихы 7 сынып, 3-сынып ста д кені, ТРП курс.жум каз 2021, ет өндіру кәсіпорны
| методикой ADM, процесс разработки архитектуры включает следующие фазы:
Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта. Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством. Фаза B: разработка бизнес-архитектуры предприятия. Фаза C: разработка архитектуры данных и архитектуры приложений. Фаза D: разработка технологической архитектуры. Фаза E: проверка возможности реализации предложенных решений. Фаза F: планирование перехода к новой системе. Фаза G: формирование системы управления преобразованиями. Фаза H: управление изменением архитектуры. Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные подпроцессы: Описание существующей технологической архитектуры. Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации. Описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения. Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах. Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков. Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок. Формирование целевой технологической архитектуры. Описание существующей системы в терминах TOGAF. Определение перспектив (представлений) архитектуры. Формирование модели целевой архитектуры. Определение ИТ-служб (сервисов). Подтверждение учета бизнес-требований. Определение архитектуры и используемых блоков (шаблонов). Проведение анализа расхождений (gap analysis). Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Это может быть вызвано как необходимостью учета других существующих стандартов предприятия, так и привлечением аутсорсинговых компаний к разработке архитектуры. Интересным примером может являться проект внедрения корпоративной ERP-системы. В этом случае необходимо определенное изменение порядка разработки – так, бизнес-архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D! Процесс разработки не заканчивается после выбора оптимальной архитектуры и разработки плана миграции. Необходимыми элементами являются задачи, выполняемые на фазах G и H. В частности, для обеспечения практического принятия архитектуры в организации и успеха проекта обязательным является формирование Системы управления реализацией архитектуры (Implementation Governance). Так, фаза G предусматривает следующие задачи: Организация Совета по архитектуре, включающего представителей всех бизнес-подразделений и руководства. Этот Совет должен выполнять наблюдательную и координирующую роль. Разработка конкретной реализации достаточно полного набора Архитектурных принципов на основе существующего шаблона (см. ниже). Формирование Стратегии Соответствия Архитектуре, определяющей правила и рекомендации для оценки и выбора проектов в части их соответствия или несоответствия согласованной архитектуре, а также формальную процедуру проверки такого соответствия. Это похоже на жизненный цикл технологических стандартов германской архитектуры электронного правительства SAGA, и на правила использования стандартов: проект, который не полностью удовлетворяет всем обязательным стандартам, не может получить бюджетного финансирования. Список литературы 1. https://intuit.ru/studies/courses/995/152/lecture/4236?page=4 2. https://intuit.ru/studies/courses/995/152/lecture/4236?page=7 3. http://bodrenko.org/ap/ap-l2.htm жүктеу/скачать 135,46 Kb. Достарыңызбен бөлісу:
|