Экономическая рационализация принятия технологических решений

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

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

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

И тут нам на помощь приходит CBAM (Cost Benefit Analysis Method).

Впервые я узнал об этом методе из книги Software Architecture in Practice (Len Bass, Paul Clements, Rick Kazman) и с тех пор стараюсь периодически использовать его в своей работе “по ту сторону баррикад” (со стороны бизнесовой части).

Контекст принятия решения

Основы

Для использования метода нам нужно 4 составляющих:

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

При этом надо не забывать, что у каждого сценарии могут быть trade-off влияющие на другие атрибуты качества.

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

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

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

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

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

Для каждого результата каждого сценария нужно определить его ценность от 0 до 100:

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

Допустим, наша рассматриваемая стратегия предполагает, что результат выполнения отчета станет равным 1 минуте.

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

Если мы рассчитаем ценность для генерации отчета в течение 1 минуты по указанной формуле, то получим её ценность равной 86 (оставив только целую часть).

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

На этом этапе мы определяем стоимость реализации каждой стратегии и считаем её Value For Cost (VFC), основываясь на итоговой ценности, далее ранжируем стратегии по убыванию VFC и выбираем самую верхнюю

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

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

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

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