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

Программа конференции

Введение

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

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

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

Если первый тезис может быть для кого-то открытием, вероятно, только в силу  значительной паранормальности многих проектов ИС на постсоветском пространстве, то второй впервые сформулирован, по-видимому, здесь. С другой стороны, подобные предлагаемой нами, хотя и менее детальные методики, уже некоторое время известны. Так, например, в [6] совокупная стоимость владения серверными кластерами определяется как сумма затрат на их приобретение, стоимости серверов, эксплуатационных затрат и стоимости потерь от простоев. Последняя как раз и соответствует стоимости рисков в нашем понимании.

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

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

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

Два основных идеологических определения архитектуры ИС таковы:

• “Архитектура ИС — это набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой”
•   “Архитектура ИС — это набор ключевых решений, неизменных при изменении бизнес–технологии в рамках бизнес–видения”

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

Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы:

• что делает система ;
• как эти части взаимодействуют;
• где эти части размещены.3
• на какие части она разделяется;

Таким образом, архитектура ИС является логическим построением, или моделью. Как же она влияет на совокупную стоимость владения? Через набор связанных с ней решений по выбору средств реализации, СУБД, операционной платформы, телекоммуникационных средств и т.п. — т.е. через то, что мы называем инфраструктурой ИС. Еще раз подчеркну, что инфраструктура включает решения не только по программному обеспечению, но также и по аппаратному комплексу и организационному обеспечению. Это вполне соответствует пониманию системы в наиболее современных стандартах типа ISO/IEC 15288 [1].

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

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

Я сознательно говорю именно о выборе, а не о разработке архитектуры. Разработка архитектуры – отдельный вопрос. В данном случае речь идет о выборе одной из архитектур-кандидатов. (То, что выбор делать надо, указывается,  например, в RUP [2], но, к сожалению, там не объясняется, как это делать.)

Более того, несмотря на то, что большинство методологий подчеркивают важность архитектуры (исключением является, пожалуй, XP), ни одна не дает внятной методики ее выбора. Причины этого таковы:

• Фирменные методики навязывают, с разной степенью настойчивости,  фирменную же архитектуру и инфраструктуру (таковы, в частности, Oracle CDM и MSF);
• XP фактически отрицает осознание архитектуры, что оправданно для некрупных проектов, выполняемых небольшой командой (1-3 пары программистов).

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

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

В результате осмысления имеющихся методик нами были сформулированы следующие требования к методике выбора архитектуры. Методика должна:

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

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

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

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

В любой момент проекта

  дисконтированные интегральные затраты на систему могут быть оценены как

  (1)

где

  — оценка дисконтированных интегральных затрат проекта в момент

;

E— норма дисконтирования4;

  — дисконтированная сумма фактических интегральных затрат проекта к моменту

;

T— период жизненного цикла системы;

— оценка интегральных затрат на проект в периоде t;

В свою очередь, оценку интегральных затрат на проект в периоде tможно представить как

  (2)

где

  — плановые затраты на проект в периоде t;

— оценка потерь, связанных с бизнес-рисками в периоде t.

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

  (3)

где

  — затраты на приобретение готового программного обеспечения и технических средств в периоде t;

— затраты на проектирование системы в периоде t;

  — затраты на строительно-монтажные работы в периоде t;

— затраты на внедрение системы в периоде t;

— эксплуатационные затраты в периоде t;

— затраты на сопровождение в периоде t;

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

— оценка потерь, связанных с бизнес-рисками в периоде t.

Конечно, мы будем использовать характеристики и чисто технических, ИТ-рисков. Для того, чтобы знать и правильно организовать описание всего набора возможных рисков, полезно опираться на некую общую модель архитектуры - как предприятия, так и его ИС. В качестве таких моделей могут применяться модели Захмана [3] или Зиндера [4].

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

Вопросы соответствия различных типов рисков ячейкам архтектурной модели [4] и их связям требуют дополнительной теоретической проработки. Однако и без нее знакомым с вышеуказанными моделями нетрудно будет соотнести определенные ячейки архитектуры (architecturalframework) с различными рисками и таким образом составить, назвать и описать актуальные для проекта/системы группы рисков. Мы же - в рамках данной статьи - выделим несколько наиболее значимых и принципиально различных типов рисков:

• проектные риски при создании системы;
• риски бизнес-потерь, связанные с эксплуатацией системы (возникающие, в конечном счете, из-за технических рисков). Такие риски бизнес-потерь  назовем бизнес-рисками. Каждый бизнес-риск принадлежит по крайней мере одному из вариантов бизнес-использования системы. Например, для интернет-магазина бизнес-риски “Покупатель не может сделать заказ и уходит” и “Покупатель делает заказ, но уходит рассерженный функционированием системы” принадлежат вариантов бизнес-использования “Сделать заказ”.
• риски бизнес-потерь, связанные с вариативностью бизнес-процессов. При этом потери происходят оттого, что а) бизнес-процессы надо изменять, а информационная система не готова к этому и потери связаны с неоптимальным функционированием бизнеса и б) оттого, что имеется стоимость модификации системы. Такие риски бизнес–потерь назовем неопределенностями (RUP упоминает аналогичные по смыслу "варианты изменения" (change cases)).
• технические риски, состоящие в простоях, отказах, потере или искажении данных и т.п.;

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

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

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

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

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

На рис. 1 приведена диаграмма отношений (ERDв нотации Чена) для бизнес-рисков, операционных рисков, технических рисков, вариантов бизнес-использования, операций и элементов архитектуры:

Рис. 1. Диаграмма отношений рисков

На основе вышесказанного получаем следующую методику выбора  архитектуры ИС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Строится матрица соответствия элементов архитектуры–кандидата и операций. На основе этой матрицы и матрицы соответствия статических бизнес-рисков и операционных рисков строится матрица соответствия технических рисков и бизнес-рисков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

8 Естественно, сразу хочется просто перемножить эти матрицы. Это неправильно, так как операционные риски не независимы. Кроме этого, обычно более половины бизнес–рисков не будут являться архитектурно значимыми.

---

Программа конференции

Версия для печати