Архитектура предприятия

   Наш опыт показывает, что для  достаточно крупных систем выявляется  порядка 20-30 бизнес-рисков, из которых  действительно архитектурно значимыми  являются 7-10. Для каждого такого риска мы строим маленькую экономическую модель, позволяющую оценить величну риска в зависимости от параметров.

   Определяются возможные вариации  бизнес-процессов. На их основе  описываются неопределенности.

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

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

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

Например, мы в своих проектах остаточно крупных и территориально распределенных систем расматриваем по крайней мере три архитектуры-кандидата:

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

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

Например, характерными элементами архитектуры являются:

• центральный сервер;
• центральная БД;
• коммуникационный канал между центром и филиалом;
• сервер филиала;
• БД филиала;
• рабочие станции;
• ПО Message Oriented Middleware.

Технические риски в данной архитектуре при этом относятся к одному из классов, приведенных в таблице 1.

Таблица 1. Технические риски

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

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

Таблица 2. Коэффициенты надежности серверных платформ

Платформа	Коэффициент	Источник
OCWindows2000, процессор Intel	99.9	[5]
OC Solaris, процессорUltraSparc	99.95	[5]
Кластер на базе Solaris, процессор UltraSparc	99.975	[5]
OpenVMS, Compaq Alpha	99.95	[6]
Кластер на базе ОС OpenVMS, CompaqAlpha	99.99	[7]
NonStopHimalaya	99.9979	[8]

   Строится матрица соответствия  элементов архитектуры–кандидата  и операций. На основе этой  матрицы и матрицы соответствия  статических бизнес-рисков и операционных рисков строится матрица соответствия технических рисков и бизнес-рисков. Значения элементов этой матрицы получаются как количество реализаций бизнес-риска на одну реализацию технического риска.

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

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

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

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

   В качестве архитектуры системы  выбирается архитектура-кандидат с минимальной оценкой совокупной стоимости владения.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Литература

1. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504), М., Книга и бизнес, 2001

2. Rational Unified Process 2002a, Rational Software, 2002

3. J.F. Sowa, J.A. Zachman. Extending and Formalizing the Framework for Information System Architecture. IBM System Journal, vol. 31, no. 3, 1992

4. Е.З. Зиндер. "3D-предприятие" — модель трансформирующейся системы.//CWR Директору информационной службы, №4, 2000

5. Comparing Sun Solaris 8 and Microsoft Windows 2000 Server Technologies. White paper. Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA 09/2000

6. Total Cost of Ownership for Low-End and Mid-Range Server Clusters. A Detailed Analysis of the Total Cost of Ownership of Various RISC and Intel-Based Server Cluster Solutions. TechWise Research, 2001

7. OpenVMS: When Continuous Availability Really Matters. Harvard Research Group, 2001

8. Real-World System Availability Measurements for Compaq NonStop™ Integrity Systems. Compaq Inform №28, 1999

9. Ссылка "http://www.cfin.ru/management/practice/supremum2002/16.shtml"

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

План работы

 

1. Введение

 

2. Что такое архитектура ИС и инфраструктура ИС

 

3. Требования к методике выбора архитектуры ИС

 

4. Совокупная стоимость владения системой и риски

 

5. Литература

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

 

 

 

«ФИНАНСОВЫЙ УНИВЕРСИТЕТ ПРИ ПРАВИТЕЛЬСТВЕ РОССИЙСКОЙ ФЕДЕРАЦИИ»

 

 

 

 

Контрольная работа

 

 

Дисциплина: «Архитектура предприятий»

 

 

Вариант №9

"Методы обоснования выбора архитектуры информационной системы"

 

 

 

 

 

 

 

 

 

                                                           Работа: Ковраева Ислама Хасановича

                                                           Факультет: Учетно - статистический

                                                           Специальность: бизнес - информатика

                                                           Номер личного дела:100.10/120077

                                                           Преподаватель: Ткаченко А. А.

 

 

Москва 2014