дисциплина Архитектура корпоративных информационных систем Методологии построения

дисциплина “Архитектура корпоративных информационных систем” Методологии построения архитектур предприятия Лекция 4 Проф. Замятин Николай Владимирович zam@fet. tusur. ru 1

Вопросы на лекцию 4 “Методологии построения архитектур предприятия” 1. Основные цели создания архитектуры корпорации 2. Общие методические принципы создания архитектуры корпорации 3. Подходы при построении корпоративной архитектуры 4. Компоненты архитектуры корпорации 5. Процесс разработки архитектур предприятия 6 Модель архитектуры предприятия Дж. Захмана 7. Заполнение матрицы модели Захмана 8. Матрица согласованных моделей 9. Схема « 3 Д-предприятие 10. Требования к « 3 Д-модели 11. Методология TOGAF 12. Метология федеральной организации (FEA) 13. Методология GARTNER 14. Сравнение различных моделей и методологий архитектур

Возрастание интереса к ИТ-стратегии объективно связано с необходимостью обеспечения постоянного соответствия уровня развития информационных систем предприятия и требований бизнеса. Развитие бизнеса неминуемо должно сопровождаться соответствующими изменениями в информационных системах

Определение архитектуры корпорации (предприятия) архитектура системы (предприятия) представляет модель основного расположения и взаимосвязей внутренних частей системы (физического либо концептуального объекта или сущности) определяет: - структуру бизнеса; - информацию, необходимую для проведения этого бизнеса; - технологии, применяемые для поддержания бизнес-процессов; - переходные процессы преобразования, развития, которые необходимы для реализации новых технологий, как реакцию на появление новых изменяющихся бизнес - потребностей

Состав архитектуры в составе архитектуры предприятия выделяется несколько основных областей – «доменов» • Бизнес-архитектура, описывающая деятельность организации с точки зрения ее ключевых бизнес-процессов. • Архитектура приложений, определяющая, какие приложения используются и должны использоваться для управления данными и поддержки бизнес-функций. • Архитектура интеграции и общих сервисов, формирующая механизмы и совместно используемые компоненты для интеграции различных приложений и данных. • Архитектура информации (данных). Эта область определяет, какие данные необходимы для поддержания бизнес-процессов, а также для обеспечения стабильности и возможности долговременного использования этих данных в прикладных системах. • Архитектура инфраструктуры (технологическая, системная архитектура). Определяет, какие обеспечивающие технологии необходимы для создания среды работы приложений, которые, в свою очередь, управляют данными и обеспечивают бизнесфункции.

Подходы при построении архитектуры • Стандартный подход. В этом подходе сначала разрабатывается общая схема и правила для будущего описания архитектуры. Затем описывается вся текущая база, и после этого представляется вся целевая архитектура. Только после этого начинается конструирование, приобретение, реализация систем. Этот подход требует существенных начальных инвестиций - финансовых и временных, с одной стороны. • Подход "статус-кво". Разработка рассматривается как реакция на те или иные возникающие затруднения. • Сегментный подход. Этот подход опирается на модель разработки сегментов архитектуры в рамках общей структурированной схемы, направлен на главные области бизнеса Для сокращения возможных рисков, снижение начальных затрат и получения быстрой отдачи от проекта используется сегментный подход

парадигмы архитектуры предприятия Двигатели архитектуры (Architecture Drivers) отражают внешние стимулы изменения архитектуры: бизнес-стимулы и технические стимулы. В качестве бизнес - стимулов может выступать новое законодательство, новые инициативы администрации, ассигнования для ускорения развития отдельных сфер, рыночные силы. В роли технических двигателей могут выступать новое и улучшенное программное обеспечение, аппаратные средства ЭВМ и их комбинации. Стратегическое направление (Strategic Direction) - руководство для разработки целевой архитектуры, которое содержит видение миссии предприятия, принципы его построения, цели и объекты предприятия. Текущая архитектура (Carrent Architecture) определяет архитектуры предприятия "как есть" и состоит из двух частей: текущая бизнес-архитектура и техническая архитектура (данные, приложения и технологии). Она отражает текущие возможности и технологии, а также служит объектом для дальнейшего расширения. Целевая архитектура (Target Architecture) определяет архитектуру предприятия "как должно быть построено" и состоит из двух частей: целевая бизнес-архитектура и техническая архитектура (т. е. данные, приложения и технологии). Она представляет будущие возможности и технологии, которые являются результатом улучшения проекта поддержки изменяющихся бизнес - потребностей.

Парадигмы архитектуры предприятия • Переходные процессы (Transitional Processes) поддерживают переход от текущей архитектуры к целевой архитектуре. Критические переходные процессы для предприятия включают планирование инвестиций в сферу ИТ, планирование перехода, управление конфигурацией, контроль и управление проектом. • Архитектурные сегменты (Architectural Segments) отражают ориентацию отдельных частей общей архитектуры на главные бизнес - области. • Архитектурные модели (Architectural Models) определяют бизнес - модели и конструкторские (технические) модели, которые отражают все необходимые сегменты для полного описания предприятия. • Стандарты (Standards) включают все стандарты, руководящие принципы (руководящие материалы), а также передовой опыт. Примерами стандартов являются: - стандарты безопасности; - стандарты данных относятся к данным, метаданным и другим связанным структурам; - стандарты приложений относятся к прикладному ПО;

Взаимосвязь АИТ и АП с целями организации Архитектура информационных технологий и архитектура предприятия в целом являются основным механизмом представления и реализации целей организации через адекватные ИТ - нфраструктуру и системы. Это достигается через создание определенного количества взаимосвязанных архитектурных представлений.

Основные этапы архитектурного процесса

Элементы архитектуры предприятия

Бизнес - модели Описывают: - Стратегию предприятия, - структуры управления, - требования, - ограничения и правила, - основные бизнес-процессы, включая взаимосвязи и зависимости между ними. Бизнес-архитектура описывает на уровне предприятия в целом то, как реализуются основные функции организации, включая организационные и функциональные структуры, роли и ответственности

Архитектура информации Определяет ключевые активы, связанные со структурированной и неструктурированной информацией, требующейся для бизнеса, включая: - расположение, - время, - типы файлов и баз данных; - других информационных хранилищ

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

Технологическая архитектура Включает описание ИТ-сервисов, которые требуются для реализации областей архитектуры Логические модели ИТ-сервисов построеные в абстрактной, технологически независимой форме и оставляющие свободу для оптимального выбора конкретных технологий. Физические модели определяются: - технологиями, - аппаратными платформами - программными платформами, выбранными для реализации ИТ-сервисов.

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

МЕТОДИКИ ОПИСАНИЯ АП

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

• • • Модели архитектур Структура Захмана Методология TOGAF (The Open Group Architectural Framework) Архитектура федеральной организации Методология Gartner Модель GERAM

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

• • Состав моделей архитектур Функциональная модель системы описывает совокупность выполняемых системой функций, характеризует морфологию системы (ее построение)состав функциональных подсистем, их взаимосвязи. Информационная модель отражает отношения между элементами системы в виде структур данных (состав и взаимосвязи). Поведенческая (событийная) модель описывает информационные процессы (динамику функционирования). В ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий. Организационная модель описывает структуру связей подразделений, из которых состоит предприятие.

формализованное представление модели предприятия в виде матрицы

Подход на основе архитектур Д. Захмана не определяет собственно методы построения моделей проблемной области. Развитые методологии моделирования предметных областей предполагают реализацию принципов последовательной детализации абстрактных категорий: целей, объектов, функций, организационных единиц и т. д. на уровнях определения требований к системе, их спецификации и реализации

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

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

Модель Захмана n n 1987 год - появились первая статья Джона Захмана, 1992 год - вторая (в соавторстве с Дж. Сова) статья Джона Захмана (1. Sowa J. F. , Zachman J. A. Extending and Formalizing the Framework for Information System Architecture // IBM Systems Journal. 1992. V. 31. № 3. предложен вариант обобщенной схемы или структуры (framework, или «фреймвок» ) для описания и анализа архитектуры: формально (по названию) еще архитектуры ИС, но по содержанию - уже предприятия.

Модель Захмана

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

Матрица Захмана ПОЧЕМУ? КТО? ЧТО? КАК? ГДЕ? КОГДА? Стратег Бизнес-архитектура (концептуальная) Владелец взгляд (видение) Этапы создания информационной системы (рамки) Oрганиза. Архитектура ционная правил данных приложений Проектировщик архитектура (логическая) (физическая) Разработчик (реализация) Программист Инфраструктура Временн. Ая архитектура

Матрица Захмана n Ряд 1 – Контекст n Ряд 2 – Модель бизнеса n Ряд 3 – Системная модель Внешние требования и движущие факторы Моделирование бизнес-функций Модели бизнес-процессов Логические модели n Ряд 4 – Технологическая модель Физические модели Определение и разработка решения n Ряд 5 – Детальное представление (Как выстроено) Как выстроено Внедрение n Ряд 6 – Работающая организация Функционирование организации Оценка

Правила n Правило 1: Нет заданного порядка расположения колонок n Правило 2: Каждая колонка имеет в основе простую, базовую модель n Правило 3: Базовая модель в каждой колонке уникальна n Правило 4: Каждый ряд представляет различную точку зрения (взгляд на систему) n Правило 5: Каждая клетка уникальна n Правило 6: Совокупность клеток одного ряда формирует полное описание системы с соответствующей точки зрения

Матрица Захмана – Ряд 1 Контекст/Уровень Владельца процесса n n n Мотивация/Почему Цели бизнеса, задачи и результаты деятельности Меры, относящиеся к каждой функции Данные/Что Классы данных верхнего уровня, связанные с каждой Люди/Кто функцией Держатели акций, имеющие отношение к каждой функции Функции/Как Бизнес-функции верхнего уровня Место/Где Местоположения, связанные с каждой функцией Время/Когда Циклы и события, относящиеся к каждой функции ● Внешние требования и движущие факторы ● Моделирование бизнесфункций

Матрица Захмана – Ряд 2 Модель организации/Уровень Аналитика n n Мотивация/Почему Политики, процедуры и стандарты для каждого процесса Люди/Кто Роли и ответственность в каждом процессе n Данные/Что Информация о бизнесе n Функции/Как Бизнес-процессы n n Место/Где Местоположения, связанные с каждым процессом Время/Когда Действия в рамках каждого процесса и последовательность интеграции и оптимизации процессов ● Модели бизнес-процессов ● Окружение бизнес-функций ● Ислючение пересечения и дублирования функций

Матрица Захмана – Ряд 3 Системная модель/Уровень Архитектора n n n Мотивация/Почему Политики, процедуры и стандарты в рамках модели бизнес-правил Люди/Кто Логическое представление прав доступа в зависимости от роли и ответственности Данные/Что Логические модели данных и взаимосвязи между данными Функции/Как Логическое представление информационных систем и их взаимосвязей Место/Где Логическое представление распределения системной архитектуры по местам Время/Когда Логические события и их следствия в рамках бизнессобытий и их следствий ● Логические модели ● Управление проектами ● Определение требований

Матрица Захмана – Ряд 4 Технологическая модель/Уровень Проектировщика n n n Мотивация/Почему Бизнес-правила в рамках стандартов информационных систем Люди/Кто ● Физические модели Спецификация прав доступа в рамках выбранных платформ ● Управление технологиями и технологий ● Выбор решений и их Данные/Что реализация Требования к типам систем управления базами данных в рамках логических моделей данных Функции/Как Спецификация приложений, функционирующих на основе выбранных технологических платформ Место/Где Спецификация сетевых устройств и их взаимосвязей в пределах физических границ системы Время/Когда Спецификация «переключателей» событий в системе в рамках выбранных платформ и технологий

Матрица Захмана – Ряд 5 Как выстроено/Уровень Программиста n n n Мотивация/Почему Бизнес-правила в рамках выбранных технологических стандартов Люди/Кто Права доступа, созданные для контроля доступа к выбранным платформам и технологиям Данные/Что Определение данных в рамках физических моделей данных Функции/Как Программы, написанные для работы на основе выбранных технологических платформ Место/Где Сетевые устройства, формируемые для соответствия Время/Когда спецификациям узлов Программирование временных промежутков для упорядочивания последовательности действий в рамках выбранных платформ и технологий ● Как выстроено ● Управление конфигурацией ● Внедрение

Матрица Захмана – Ряд 6 Работа организации/Уровень Пользователя Мотивация/Почему Использование возможностей специальных технологий в рамках стандартов n n n Люди/Кто Сотрудники и ключевые акционеры, работающие с системой в рамках своих ролей и уровня ответственности Данные/Что Внесение данных и их хранение в активных базах данных Функции/Как Функционирующие компьютерные инструкции Место/Где Отправка и получение сообщений Время/Когда Установление временных промежутков для задания последовательности событий ● Работа организации ● Управление операциями ● Оценка

Метод Захмана Концептуально важные идеи: n рекурсивность логики формирования моделей и метамоделей на основе одной обобщенной схемы; n использование репозитория архитектурной информации для работы с разными моделями и их состояниями; n управление архитектурой и изменениями предприятия на основе репозитория.

Метод Захмана позволяет: n n концентрироваться на отдельных аспектах предприятия или его конкретной системы и в то же время не терять взгляда на него как на целое; использовать одну понятную и бизнесруководителям, и компьютерным специалистам концептуальную основу для совместных обсуждений и планирования; планировать соответствие другу описанийячеек, обеспечивая тем самым согласование бизнеса и ИТ; сохранять при этом независимость от какого-либо программного продукта (инструмента) с его формализмами, особенностями и ограничениями.

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

модель TOGAF

Содержание корпорации

состав модели TOGAF – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, – базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Основной областью применения TOGAF является, прежде всего, программная инфраструктура информационной системы

Общая структура TOGAF

Фазы моделирования • Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта. • Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством. • Фаза B: разработка бизнес-архитектуры предприятия. • Фаза C: разработка архитектуры данных и архитектуры приложений. • Фаза D: разработка технологической архитектуры. • Фаза E: проверка возможности реализации предложенных решений. • Фаза F: планирование перехода к новой системе. • Фаза G: формирование системы управления преобразованиями. • Фаза H: управление изменением архитектуры.

Методика разработки архитектуры

Сегменты федерального правительства

FEA • архитектура предприятия состоит из отдельных сегментов. Сегмент представляет собой один из основных аспектов бизнеса, например трудовые ресурсы. Сегменты подразделяются на два типа: базовые и служебные. • Базовый сегмент представляет собой ключевой аспект деятельности предприятия в границах политико-административного деления. Служебный сегмент — это сегмент, который является фундаментальным если не для всех, то для большинства политических организаций

Общий процесс разработки архитектуры • Этап 1. Анализ архитектуры: формирование простого и лаконичного представления сегмента с привязкой к плану организации. • Этап 2. Архитектурное определение: задание желаемого состояния сегмента, документация целевых показателей производительности, рассмотрение альтернатив и разработка архитектуры предприятия для сегмента, в том числе архитектуры бизнеса, архитектуры данных, архитектуры служб и технологической архитектуры. • Этап 3. Стратегия инвестиций и финансирования: рассмотрение способов финансирования проекта. • Этап 4. План управления программой и реализация проектов: создание плана управления проектом и его реализации, включающего контрольные точки и показатели производительности для оценки успешности проекта.

Модели Gartner Архитектура предприятия, согласно представлению Gartner, связана со стратегией, а не с технической реализацией. Она направлена на достижение цели. Два самых важных вопроса, которыми задается компания Gartner, — это куда организация стремится и как она туда попадет Любое действие, не связанное напрямую с этими вопросами, считается неуместным. Аналитики Gartner любят употреблять следующую фразу: «Ровно столько архитектуры, сколько необходимо, и точно в срок»

Уровни модели архитектуры Gartner

Схема « 3 Д-предприятие» Плоские схемы моделей архитектуры – это средство для организации знаний предприятия, которые важны в условиях приспособления к изменениям предприятия во времени Для управления проектами развития ИС и трансформации предприятия вводится трехмерная схема, которая образуется путем введения оси стратегического времени

Как надо завтра. Как надо сегодня. Текущие потребности. Ц. Л. Ф. О. К. В. Главные потребности, цели, планы, ограничения. Бизнес-модель Логическая модель. Техническая архитектура Ось уровня проектирования Детальная реализация Практика использования Ось раздела обеспечения Ось СТРАТЕГИЧЕСЕКОГО ОБЕСПЕЧЕНИЯ

GERAM (Generalised Enterprise Reference Architecture and Methodology) - Обобщенная референсная архитектура и методология предприятия. GERAM включено в качестве приложения в действующий базовый стандарт - ISO 15704: 2000 «Requirements for enterprisereference architectures and methodologies»

Обобщенная схема GERAM

Обобщенная схема GERAM ПРЕДУСМАТРИВАЕТ • четыре группы аспектов архитектуры предприятия, названных представлениями (Views) - типы моделей ( «функции» , «данные» , «ресурсы» , «организация» , что уже, чем шесть аспектов Захмана), назначения (может быть ассоциировано со столбцом «ЗАЧЕМ» Захмана), реализации и «физические представления» (аппаратура, ПО) и возможность определять дополнительные аспекты; • описание всех аспектов или какой-то их части на каждой из семи или восьми фаз формирования архитектуры и функционирования предприятия; • конкретизацию модели архитектуры на трех уровнях - обобщенном, уровне частичных моделей (они же повторно используемые референсные, reference) и

Оценки сравнения моделей архитектур