Введение
Некоторое время назад нам
довелось выполнять консалтигновый
проект по разработке архитектуры
достаточно крупной и нетривиальной
информационной системы. И если
вопрос построения архитектур–кандидатов
казался более-менее очевидным (в
конце концов, существует несколько
содержательных — и существенно различных
— методик построения архитектур), то
вопрос выбора архитектуры из кандидатов,
как оказалось, существенно менее проработан.
В данной статье излагается метод выбора
архитектуры информационной системы (ИС),
к которому мы пришли в результате осуществления
двух аналогичных проектов, и основные
идеи которого могут быть сформулированы
в двух тезисах:
Для тех проектов построения
информационных систем, для которых
важен экономический эффект, должна
выбираться архитектура системы с минимальной
совокупной стоимостью владения
Совокупная стоимость владения
информационной системой состоит
из плановых затрат и стоимости
рисков. Совокупная стоимость рисков
определяется стоимостью бизнес–рисков,
вероятностями технических рисков и матрицей
соответствия между ними. Матрица соответствия
определяется архитектурой информационной
системы.
Если первый тезис может быть
для кого-то открытием, вероятно,
только в силу значительной
паранормальности многих проектов
ИС на постсоветском пространстве, то
второй впервые сформулирован, по-видимому,
здесь. С другой стороны, подобные предлагаемой
нами, хотя и менее детальные методики,
уже некоторое время известны. Так, например,
в [6] совокупная стоимость владения серверными
кластерами определяется как сумма затрат
на их приобретение, стоимости серверов,
эксплуатационных затрат и стоимости
потерь от простоев. Последняя как раз
и соответствует стоимости рисков в нашем
понимании.
Что такое архитектура ИС и инфраструктура
ИС
Архитектура — это то, за что
увольняют системного архитектора
и руководителя проекта. (Кто-то
может сказать, что проекты на
самом деле проваливаются из-за
неправильной организации процесса
разработки. Не отрицая этого, скажу,
что знаю существенно больше успешных
систем, построенных в кривом процессе
разработки, чем успешных систем с кривой
архитектурой.)
Между тем, слова “архитектура
информационной системы” обычно
довольно согласованно понимаются
специалистами на уровне подсознания,
и ровно столь же несогласованно определяются.
Два основных класса определений архитектур
— определения “конструктивные” и “идеологические”.
Два основных идеологических
определения архитектуры ИС таковы:
- “Архитектура ИС — это набор решений,
наиболее существенным образом влияющих
на совокупную стоимость владения системой”
-
“Архитектура ИС — это набор ключевых
решений, неизменных при изменении бизнес–технологии
в рамках бизнес–видения”
Оба эти определения согласованы
в том смысле, что если ключевое
решение приходится изменять при изменении
бизнес–технологии в рамках бизнес–видения,
то резко возрастает стоимость владения
системой. Следствием этих определений
является понимание важности принятия
архитектуры системы как стандарта предприятия,
ввиду значимости и стабильности архитектурных
решений. Еще одно важное следствие первого
определения — то, что архитектура системы
на самом деле должна строиться на стадии
технико–экономического обоснования
системы.
Конструктивно
архитектура обычно определяется как
набор ответов на следующие вопросы:
- что делает система ;
- как эти части взаимодействуют;
- где эти части размещены.
- на
какие части она разделяется;
Таким образом, архитектура ИС
является логическим построением,
или моделью. Как же она влияет
на совокупную стоимость владения?
Через набор связанных с ней решений по
выбору средств реализации, СУБД, операционной
платформы, телекоммуникационных средств
и т.п. — т.е. через то, что мы называем инфраструктурой ИС. Еще раз подчеркну,
что инфраструктура включает решения
не только по программному обеспечению,
но также и по аппаратному комплексу и
организационному обеспечению. Это вполне
соответствует пониманию системы в наиболее
современных стандартах типа ISO/IEC 15288.
Требования к методике выбора архитектуры
ИС
По всей видимости, число проектов,
в которых архитектура системы
сознательно выбирается, относительно
невелико (в отличии от архитектуры
программного обеспечения, которая,
в соответствии с нашими определениями,
является только частью архитектуры
системы). Естественно, архитектура будет
наличествовать в любом случае, другое
дело, что она может не конструироваться
и не выбираться сознательно.
Я сознательно говорю именно
о выборе, а не о разработке
архитектуры. Разработка архитектуры
– отдельный вопрос. В данном случае
речь идет о выборе одной из архитектур-кандидатов.
(То, что выбор делать надо, указывается,
например, в RUP [2], но, к сожалению, там не
объясняется, как это делать.)
Более того, несмотря на то, что
большинство методологий подчеркивают
важность архитектуры (исключением является,
пожалуй, XP), ни одна не дает внятной методики
ее выбора. Причины этого таковы:
- Фирменные методики навязывают, с разной
степенью настойчивости, фирменную же
архитектуру и инфраструктуру (таковы,
в частности, Oracle CDM и MSF);
- XP
фактически отрицает осознание архитектуры,
что оправданно для некрупных проектов,
выполняемых небольшой командой (1-3 пары
программистов).
Вопросы разработки архитектуры
довольно подробно рассматриваются
в традиционных методиках. Проблемами
этих подходов, на наш взгляд, являются:
- невозможность оценить качество разработанной
архитектуры;
- ориентированность на архитектуру программной
системы и дистанцирование от того факта,
что система состоит не только из программных,
но также и технических средств и людей;
- разделение процессов технико-экономического
обоснования системы, разработки бизнес-процессов
и разработки архитектуры системы;
- отсутствие
привязки к бизнес-целям и целям использования
системы.
В результате осмысления имеющихся
методик нами были сформулированы следующие
требования к методике выбора архитектуры.
Методика должна:
- отражать связь архитектуры и совокупной
стоимости владения;
- отражать итерационную природу разработки
ИС;
- иметь своей целью выбор архитектуры
системы в целом, а не только ее программной
составляющей.
- связывать
разработку архитектуры, бизнес-анализ
и технико-экономическое обоснование
в едином процессе;
Совокупная стоимость владения
системой и риски
Как мы уже говорили, естественным
критерием выбора архитектуры и инфраструктуры
ИС является минимизация совокупной стоимости
владения системой. По крайней мере, такой
критерий является естественным для коммерческих
организаций, эффективность деятельности
которых определяется по затратам и доходам.
К сожалению, интегральные затраты
на систему могут быть полностью
известны только после завершения
проекта. В любой момент до
завершения проекта интегральные
затраты могут быть только
оценены.
В
любой момент проекта
дисконтированные
интегральные затраты на систему могут
быть оценены как
где
— оценка дисконтированных
интегральных затрат проекта в момент
;
E—
норма дисконтирования.
— дисконтированная сумма
фактических интегральных затрат
проекта к моменту
;
T—
период жизненного цикла системы;
— оценка интегральных затрат на проект
в периоде t;
В
свою очередь, оценку интегральных затрат
на проект в периоде tможно представить как
где
— плановые затраты
на проект в периоде t;
— оценка потерь, связанных с бизнес-рисками
в периоде t.
Далее,
плановые затраты на проект определяются
следующим образом:
где
— затраты на приобретение
готового программного обеспечения и
технических средств в периоде t;
— затраты на проектирование
системы в периоде t;
— затраты на строительно-монтажные
работы в периоде t;
— затраты на внедрение
системы в периоде t;
— эксплуатационные затраты
в периоде t;
— затраты на сопровождение
в периоде t;
Отметим,
что в предложенном методе оценки затрат
использована величина
— оценка потерь, связанных с бизнес-рисками
в периоде t.
Конечно, мы будем использовать
характеристики и чисто технических,
ИТ-рисков. Для того, чтобы знать
и правильно организовать описание
всего набора возможных рисков, полезно
опираться на некую общую модель архитектуры
- как предприятия, так и его ИС. В качестве
таких моделей могут применяться модели
Захмана или Зиндера.
По всей видимости, с каждой
из ячеек этих моделей связаны
свои специфические риски. А связи этих
ячеек, предусмотренные неявно в или явно
в, позволяют, например, хорошо определять
связи между техническими, операционными
и бизнес-рисками, которые будут разбираться
далее. Кроме того, наличие временной оси
в модели позволяет работать не со статической
"фотографией" проекта или жизни
системы, но учитывать их существование
во времени (имеется ввиду то самое время,
которое "работает" в формульных
оценках затрат). Кроме того, наличие этой
оси времени позволяет вычленять бизнес-риски
типа "неопределенность" (см. ниже)
при рассмотрении проекта в бизнес-времени
и проектным рискам при рассмотрении проекта
в проектном времени.
Вопросы соответствия различных
типов рисков ячейкам архтектурной
модели и их связям требуют
дополнительной теоретической проработки.
Однако и без нее знакомым с вышеуказанными
моделями нетрудно будет соотнести определенные
ячейки архитектуры (architecturalframework) с различными
рисками и таким образом составить, назвать
и описать актуальные для проекта/системы
группы рисков. Мы же - в рамках данной
статьи - выделим несколько наиболее значимых
и принципиально различных типов рисков:
- проектные риски при создании системы;
- риски бизнес-потерь, связанные с эксплуатацией
системы (возникающие, в конечном счете,
из-за технических рисков). Такие риски
бизнес-потерь назовем бизнес-рисками.
Каждый бизнес-риск принадлежит по крайней
мере одному из вариантов бизнес-использования
системы. Например, для интернет-магазина
бизнес-риски “Покупатель не может сделать
заказ и уходит” и “Покупатель делает
заказ, но уходит рассерженный функционированием
системы” принадлежат вариантов бизнес-использования
“Сделать заказ”.
- риски бизнес-потерь, связанные с вариативностью
бизнес-процессов. При этом потери происходят
оттого, что а) бизнес-процессы надо изменять,
а информационная система не готова к
этому и потери связаны с неоптимальным
функционированием бизнеса и б) оттого,
что имеется стоимость модификации системы.
Такие риски бизнес–потерь назовем неопределенностями (RUP
упоминает аналогичные по смыслу "варианты
изменения" (change cases)).
- технические
риски, состоящие в простоях, отказах,
потере или искажении данных и т.п.;
Затраты на создание и эксплуатацию
системы с некоторой точностью
оцениваются достаточно прямолинейно.
Динамические бизнес-риски количественно
учесть невозможно и их следует оценивать
исключительно качественно (на уровне
понимания, насколько бизнес-процессы
в организации являются определенными
/ застывшими / неустоявшимися). Наиболее
интересной частью совокупной стоимости
владения системой являются статические
бизнес-риски и проектные риски.
Каждый вариант бизнес-использования
реализуется с помощью набора
операций соответствующих бизнес-процессов.
Соответственно, бизнес-риск возникает
по причине неисполнения одной
или нескольких операций бизнес-процесса
— это мы называем операционными рисками.
Таким образом, операционные риски являются
источниками бизнес-рисков.
Например, источниками риска “Покупатель
не может сделать заказ и
уходит” могут быть операционный
риск “Информация о заказе не может быть
передана для обработки в систему”.
В свою очередь операционные
риски для автоматизированных
операций могут возникать по
причине технических рисков. Например,
операционный риск “Информация
о заказе не может быть передана
для обработки в систему” может возникнуть
по причине реализации технического риска
“Обрыв канала связи”.
С другой стороны, бизнес-риск
может быть парирован соответствующей
организацией процесса и/или архитектурным
решением.
На рис. 1 приведена диаграмма отношений
(ERDв нотации Чена) для бизнес-рисков, операционных
рисков, технических рисков, вариантов
бизнес-использования, операций и элементов
архитектуры:
Рис.
1. Диаграмма отношений рисков
На
основе вышесказанного получаем следующую
методику выбора архитектуры ИС.
Проводится
описание бизнес-процессов в организации
с ограниченным уровнем детальности (как
правило, не пооперационно). Описание бизнес-процесса
должно включать его целевые нефункциональные
характеристики (частоту возникновения,
продолжительность и т.п.) Результатом
данного этапа может являться набор вариантов
использования (Usecaseview) описания архитектуры
системы в смысле RUP.
На
основе описания бизнес-процессов описываются
бизнес-риски. Каждый бизнес-риск оценивается
в терминах бизнес-потерь. Это описание
является параметрическим — бизнес-потери
могут зависеть от продолжительности
действия риска, частоты его возникновения
и т.п. Критериями качества описания статических
бизнес-рисков являются:
- уникальность оценок – если два риска
оцениваются по одной и той же формуле
(возможно, с точностью до константы), то
это два названия одного бизнес-риска;
- одночленность
– если оценка бизнес-риска состоит из
многих слагаемых без общих членов, то
на самом деле это несколько бизнес-рисков.