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

В. В. Цехановский. Архитектура информационных систем: учебник для студ. учреждений

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

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

задачи и стратегии.
Архитектура информационных технологий.

являются общими утверждениями, которые задают направления и цели, связанные с

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

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

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

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

и разработки приложений) должна обеспечивать взаимодействие систем.

передан в управление менеджерам, и этим ресурсом необходимо соответствующим образом

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

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

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

и руководства используются всеми структурными подразделениями в процессе принятия решений

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

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

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

некоторого гипотетического магазина.
Для описания требований к системе, ее проектирования

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

содержит простой сценарий использования (use case), описывающий взаимодействия между системой

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

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

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

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

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

вообще выполнять этот шаг?)
Динамическое моделирование (Как эта модель выполнения бизнес-функций

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

технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business

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