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

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

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

Рекомендуемая литература

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

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

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

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

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

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

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

Элементы описания бизнес –архитектуры и архитектуры информационных

технологий

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

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

Эволюция контента Архитектуры предприятия

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

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

Примеры декларируемых принципов в области ИТ-инфраструктуры

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

Примеры принципов в области управления данными:

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

Примеры принципов, связанных с прикладными системами:

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

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

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

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

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

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

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

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

Критерии классификации моделей

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

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

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

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

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

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

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

перспектив (уровней абстракции)

Домены Перспекивы (уровни абстракции)

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

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

Архитектура приложений

Технологическая архитектура

Контекст ("планировщик")

Классы бизнес-процессов (группа процессов, имеющих много общих активностей) Список бизнес-процессов

Список бизнес-сущностей – объектов, важных для бизнеса ("клиент", счет") Связи между сущностями (бизнес-объектами)

Список бизнес-процессов

Список мест расположения бизнеса

Концептуальный уровень("владелец" предприятия)

Сценарии использования (Use case) Модели бизнес-процессов

Семантические модели Модели связей Модели "сущность-связи"

Разбиение процессов на сервисы

Модели бизнес-логистики Операционные (нефункциональные) требования Архитектура расположения элементов центра обработки данных

Логический ("проектировщик")

Модели процессов (потоков работ) Модели бизнес-событий Модель расположения процессов Определения ролей

Логические модели данных Схемы данных Спецификации документов

Определения сервисов Взаимосвязи между сервисами Модели классов

Логические типы серверов: БД, почтовые, транзакционные, … Географическое распределение серверов Хостируемое ПО

Физический ("разработчик")

Спецификации процессов Модели интеграции процессов Описание ручных процедур Стандарты качества

Физические модели данных Схемы БД Код доступа к данным Справочники данных

Код программ Описания интерфейсов (WSDL) Расписания процессов Код workflow

Физические серверы Топология фрагментов сети Мапирование продуктов на сервисы и приложения

Пример описания системы

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

Концептуальный уровень абстракции

онцептуальный уровень абстракции

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

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

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

Статическая модель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основная область анализа

Результаты (артефакты) анализа

Основные вопросы

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

Подпроцессы основных бизнес-функций Идентификация излишних и малополезных, неэффективных активностей Требования к прикладным системам и информации

Каковы основные функции организации? Какие функции не несут в себе ценности? Какие функции пересекаются с другими бизнес-функциями?

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

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

Основная область анализа

Результаты (артефакты) анализа

Основные вопросы

Обеспечить понимание ограниченного набора основных бизнес-событий Анализ возможностей по оптимизации бизнес-процессов Повышение эффективности операции, улучшение взаимодействия с клиентами,…

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

Кто является инициатором бизнес-события? Как событие обрабатывается в рамках расширенного предприятия (партнеры и пр.)? Кто является основными участниками события? Возможны ли инновации, которые связаны с событием и требуются бизнесом?

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

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

Основная область анализа

Результаты (артефакты) анализа

Основные вопросы

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

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

Где выполняются основные функции? Какие функции связаны между собой? Существуют ли возможности по консолидации и рационализации?

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

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

Основная область анализа

Результаты (артефакты) анализа

Основные вопросы

Обеспечить понимание ключевых внутренних и внешних точек интеграции Информационные потоки между участниками бизнес-событий Понимание основных интерфейсов прикладных систем Понимание требований к технологической архитектуре с точки зрения интеграции

Потоки информации, которые требуются для реализации различных шаблонов бизнес-процессов Связи между функциями бизнеса Требования к архитектуре информации, приложениям и технологической архитектуре Возможности для организационных изменений

Какая информация является критической для новых шаблонов реализации бизнес-процессов? Какие потоки информации существуют между различными точками соединения моделей бизнес-событий? Каковы требования с точки зрения времени?

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

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

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

Сервис-ориентированная архитектура

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