'

Архитектура информационных систем

Понравилась презентация – покажи это...





Слайд 0

Лекция 3. Элементы Бизнес-архитектуры и ИТ-архитектуры Архитектура информационных систем


Слайд 1

Рекомендуемая литература Б. Я. Советов, А. И. Водяхо, В. А. Дубенецкий, В. В. Цехановский. Архитектура информационных систем: учебник для студ. учреждений высш. проф. образования. - М. : Издательский центр «Академия», 2012.  А.В. Данилин, А.И. Слюсаренко. Архитектура предприятия. М: ИНТУИТ, 2007 - http://www.intuit.ru/department/itmngt/entarc/


Слайд 2

Домены (предметные области) архитектуры


Слайд 3

Архитектура информационной системы


Слайд 4

Иные представления архитектуры


Слайд 5

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


Слайд 6

Элементы описания стратегии и архитектуры информационных технологий Миссия и видение. Руководящие принципы. Утверждения, описывающие принципы и ключевые элементы философии использования информационных технологий. Цели, задачи и стратегии. Архитектура информационных технологий.


Слайд 7

Элементы описания бизнес –архитектуры и архитектуры информационных технологий Политики (правила). Политики являются общими утверждениями, которые задают направления и цели, связанные с инициативами в области ИТ. Они носят, как правило, достаточно высокоуровневый и общий характер и обеспечивают скоординированный процесс планирования, закупку критически важных технологий, эффективную разработку систем и эффективное использование информационных технологий и ресурсов. ИТ-стандарты. Стандарты – это обязательные к использованию утверждения, касающиеся используемых технологий, продуктов и/или услуг. Они должны быть достаточно полными и в то же время определять разумный минимум требований, обязательных для использования. Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе. Руководства или рекомендации. Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.


Слайд 8

Политики, стандарты и процедуры


Слайд 9

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


Слайд 10

Примеры общих принципов, связанных с архитектурой в целом


Слайд 11

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


Слайд 12

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


Слайд 13

Примеры принципов, связанных с прикладными системами: Прикладные системы разрабатываются на основе стандартной, единой методологии. Все структурные подразделения используют общие методы представления информации пользователям в своих приложениях и координируют работы по созданию пользовательского интерфейса межфункциональных систем. Создание межфункциональных прикладных систем приветствуется. Руководство заранее планирует процесс замены устаревших прикладных систем.


Слайд 14

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


Слайд 15

Стандарты архитектуры предприятия


Слайд 16

Разработка и применение стандартов


Слайд 17

Руководства (рекомендации)


Слайд 18

Модель системы


Слайд 19

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


Слайд 20

Примеры качественных и описательных моделей 


Слайд 21

Примеры количественных моделей 


Слайд 22

Разработка моделей


Слайд 23

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


Слайд 24

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


Слайд 25

Концептуальный уровень абстракции Модель на самом высоком уровне описывает бизнес-процессы продавца и содержит простой сценарий использования (use case), описывающий взаимодействия между системой и акторами Динамическая модель для этого уровня должна отражать взаимодействия между клиентом и магазином. При этом сама проектируемая система выступает как один из акторов процесса в качестве "черного ящика". Клиент и сотрудник(и) магазина выступают как внешние по отношению к системе акторы. Весь процесс рассматривается с точки зрения клиента и сотрудника. Клиент осуществляет заказ через Интернет. Оплата выполняется с помощью кредитной карты. Заказ посылается по указанному адресу. Уведомление о выполнении заказа посылается по электронной почте.


Слайд 26

 Динамическая концептуальная модель процесса закупки товара


Слайд 27

Статическая модель Статическая модель на этом уровне абстракции отражает структуру классов и связи между объектами, необходимость в которых становится очевидной при анализе динамической модели. Модель отвечает на вопрос "Какие объекты должен понимать клиент для того, чтобы выполнить транзакцию, связанную с покупкой?"


Слайд 28

Статическая модель процесса закупки товара в магазине


Слайд 29

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


Слайд 30

Построение бизнес-архитектуры 


Слайд 31

Контекст Бизнес-архитектуры


Слайд 32

Построение моделей


Слайд 33

Шаги моделирования


Слайд 34

Основные модели и инструменты описания бизнес-архитектуры


Слайд 35

Инструменты декомпозиции


Слайд 36

Декомпозиция бизнес-процессов 


Слайд 37

Компоненты декомпозиции функций/процессов


Слайд 38

Анализ бизнес-событий


Слайд 39

Компоненты анализа бизнес-событий


Слайд 40

Модель местоположений


Слайд 41

Компоненты модели местоположений


Слайд 42

Модель интеграции


Слайд 43

Компоненты модели интеграции


Слайд 44

Примеры анализа бизнес-архитектуры Анализ цепочек создания добавочной стоимости (А нужно ли вообще выполнять этот шаг?) Динамическое моделирование (Как эта модель выполнения бизнес-функций будет себя вести при различных значениях на входе и доступных ресурсах, и как со временем будет меняться поведение процесса?) Анализ пересечений и непокрытых областей (Gap-overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней "пробелы"?) Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?) Обучение (Как эти бизнес-процессы соотносятся с другими?) Общая стоимость владения (Сколько стоит этот процесс?) Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)


Слайд 45

Другие методы анализа бизнес-архитектуры


Слайд 46

Сервис-ориентированная архитектура В связи с развитием принципов сервис-ориентированной архитектуры и появлением технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business Process Execution Language) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов. К этому можно добавить также возможности еще одного стандарта XML Metadata Interchange (XMI) для обмена (экспорта/импорта) данных практически в любые интеграционные продукты. Это дает возможность создавать модели и репозитории бизнес-процессов для их эффективной интеграции. Подробная информация о новых стандартах для моделирования процессов можно найти на сайте www.bpmi.org.


×

HTML:





Ссылка: