Содержание


Политики и правила – повышение динамичности бизнеса

Часть 1. Поддержка динамичности бизнеса

Comments

Серия контента:

Этот контент является частью # из серии # статей: Политики и правила – повышение динамичности бизнеса

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Политики и правила – повышение динамичности бизнеса

Следите за выходом новых статей этой серии.

Цели

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

Главная цель первой части – дать черновые определения понятий "политика" и "правило", а также представить контекст для оценки как взаимосвязи между политиками и правилами, так и взаимосвязи между бизнес-аналитиками, разработчиками архитектуры и ИТ-персоналом. Приведенное в начале статьи краткое объяснение взаимосвязи между бизнес-политиками и бизнес-правилами поможет установить контекст для анализа того, как можно использовать политики и правила (вместе или порознь) для реализации бизнес-стратегии, тактики и отраслевых норм. Наша цель – продемонстрировать, как разработчики архитектуры могут помочь бизнес- и ИТ-персоналу достичь конкретных установленных бизнес-целей. Для этого в первом разделе данной статьи мы формулируем определения понятий и выдвигаем ряд положений, касающихся использования этих понятий и их взаимосвязи друг с другом. Эта часть статьи может показаться в значительной степени абстрактной, поскольку основное внимание в ней уделяется взаимосвязям и представлению задач обеспечения динамичности бизнеса, которые являются динамичными по самой своей природе.

Обзор

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

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

Раздел "Уровни абстракции" отражает нашу стратегию применения этих положений к ряду технических проблем. Архитектура бизнес-логики не является чем-то новым, и многие новые требования к динамичности берут свое начало в недостигнутых целях предыдущих попыток. Разработка программного обеспечения является эволюционным процессом.

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

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

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

Определение терминов

В данной статье мы используем следующие определения:

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

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

Рисунок 1. Политики и правила как бизнес-директивы
Рисунок 1. Политики и правила как бизнес-директивы
Рисунок 1. Политики и правила как бизнес-директивы

Мотивация

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

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

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

Для начала сформулируем ряд положений:

  1. Компания устанавливает набор бизнес-рекомендаций и управляет своими ресурсами в жизненном цикле руководства бизнесом. В такой бизнес-среде формирование хорошего руководства включает в себя определение набора политик, а также набора правил для реализации динамичности.
  2. Динамичность, предусмотренная выражением некоторых бизнес-требований в виде политик, проявляется себя при изменении условий, в которых действует бизнес. Можно определить набор рекомендаций, отражающих некоторый диапазон бизнес-условий. Если эти бизнес-политики удается идентифицировать и затем регулировать при изменении бизнес-условий, это позволяет сделать выполнение конкретных бизнес-правил более динамичным и более адаптированным к изменениям в рамках данного диапазона политик.
  3. Бизнес-политика может иметь свой собственный жизненный цикл изменений, что позволяет бизнесу развиваться или изменять диапазон своего поведения в рамках существующей зоны комфорта бизнес-процессов, основываясь на отслеживании возможностей при небольших изменениях бизнес-условий. В зависимости от степени развитости организации в плане использования технологии имеются места, где автоматизация оперативных процессов бизнеса (ИТ) посредством оценки и выполнения правил может также обеспечить строгий контроль бизнеса.
  4. Наличие комплекса взаимодополняющих технологий во всей организации (т.е. в бизнес-приложениях и ИТ-процессах) позволяет реализовать бизнес-политики в оперативном процессе и обеспечить эффективный баланс требований бизнеса и ИТ в обеспечении требуемого или соответствующего нормативам поведения.
  5. Управление совокупной стратегией для бизнес-правил и бизнес-политик должно допускать определение ряда гибких бизнес-активов (поддерживаемых как политиками, так и правилами), которые можно изменять (под соответствующим контролем) по мере изменений условий бизнеса. Динамичное управление может потребовать раздельных, но скоординированных жизненных циклов руководства бизнес-политиками и бизнесом, а хорошо спроектированная инфраструктура обеспечивает множество преимуществ, таких как лучшее соответствие задачам бизнеса, меньшее время окупаемости и количество изменений, меньшая стоимость изменений, большие возможности управления для бизнес-пользователей.
  6. По мере создания бизнес-правил и бизнес-политик компании сталкиваются с неизбежной необходимостью стандартизации своих собственных рабочих политик (т.е. политик управления доступом) и рабочих правил (т.е. соглашений об уровне сервиса), чтобы поддерживать и координировать операционные активы правил и политик так же эффективно, как осуществляется управление бизнес-активами.

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

Уровни абстракции в политиках и правилах

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

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

Рисунок 2. Различные типы бизнес-директив и политик с целями и задачами
Рисунок 2. Различные типы бизнес-директив и политик с целями и задачами
Рисунок 2. Различные типы бизнес-директив и политик с целями и задачами

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

Движение сверху вниз – бизнес-уровень

Бизнес-директивы и цели

Как только организация принимает решение автоматизировать свои бизнес-процессы, первым действием является сбор бизнес-требований в виде набора бизнес-директив. Бизнес-директивы содержат набор целей для реализации и набор бизнес-показателей для измерения результатов и сравнения с целями. Для их представления существуют различные методологии, но группа OMG определила ряд моделей и методик, которые мы интерпретировали и применили для декомпозиции общего набора элементов, обычно востребованных организациями при поиске решений для работы с бизнес-политиками и бизнес-правилами. Полная информация приведена в документах OMG Business Motivation Model (http://www.omg.org/spec/BMM/1.0/ – а здесь мы ссылаемся на них лишь для демонстрации того, что существуют общие пути сбора и выражения бизнес-целей и задач).

Бизнес-директивы, бизнес-политики и бизнес-правила

На концептуальном уровне разработанная OMG "Модель мотивации бизнеса" (Business Motivation Model – BMM) предоставляет способ исследования взаимосвязи между правилами и политиками в контексте более крупной концептуальной интегрированной среды, предназначенной для описания того, как организовывается бизнес-деятельность и как принимаются решения. В этом смысле она отражает некоторые принципы руководства (Governance).

  • В модели BMM делается попытка понять "устремления бизнеса (концепцию - Vision), его планы действий (миссию - Mission), детализацию концепции в цели (Goal) и задачи (Objective), идентификацию Стратегий (Strategy) для достижения целей и идентификацию тактик (Tactics) для выполнения задач".

Директивы могут состоять из некоторой комбинации бизнес-политик и бизнес-правил. Документы OMG сравнивают и сопоставляют их. Мы подвели итоги этого сравнения:

  • Бизнес-политики:
    • Управляются под руководством представителей бизнеса.
    • Бизнес-политика руководит бизнес-процессом.
    • Бизнес-политики могут выражаться на естественном языке, который может быть неоднозначен.
    • Из-за неоднозначности естественного языка бизнес-политики часто не применимы на практике напрямую и требуют интерпретации.
  • Бизнес-правила:
    • Управляются под руководством представителей бизнеса.
    • Бизнес-правило выполняет действие в рамках бизнес-процесса.
    • Бизнес-правила выражаются однозначно в терминах стандартного бизнес-словаря (standard business vocabulary – SBVR).
    • Бизнес-правила (поскольку они выражаются в терминах конкретного SBVR) применимы напрямую, так как отражают конкретные бизнес-действия и активы со специфичными согласованными определениями и действиями.

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

Рисунок 3. Жизненный цикл бизнес-директив
Рисунок 3. Жизненный цикл  бизнес-директив
Рисунок 3. Жизненный цикл бизнес-директив

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

В качестве простого примера применения подобной методики можно привести общую бизнес-директиву, например, закон против отмывания денег (Anti-Money Laundering – AML). Когда этот закон был принят, бизнес-деятельность в финансовом секторе уже велась. Компании не имели иного выбора, кроме как изменить свою общую стратегию так, чтобы соответствовать этому новому закону, что во многих случаях означало добавление новых бизнес-процессов, бизнес-политик и бизнес-правил для реализации и обеспечения выполнения закона AML. Это часто включало в себя добавление новых бизнес-задач и показателей для аудита или перенаправление имеющихся методик аудита. Типичная бизнес-директива, касающаяся AML, может выражать некоторое общее утверждение, например: финансовая организация не должна принимать платежи, которые могут поставить ее и ее владельцев в условия, когда возможно применение штрафов и уголовных наказаний.

Если мы посмотрим, как разложить этот пример AML-директивы в набор конкретных бизнес-политик и бизнес-правил, то с самого начала заметим, что бизнес-директиву можно выразить как бизнес-политику или бизнес-правило, но естественнее всего выразить ее как набор бизнес-политик.

Бизнес-политики, поддерживающие эту директиву, могли бы выглядеть так: "агенты и сотрудники должны всегда знать источник денежных средств клиента, используемых для оплаты" или "банк не будет принимать регулярные платежи с использованием кассовых чеков, денежных переводов, банковских чеков и дорожных чеков на сумму 10000 долларов и более".

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

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

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

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

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

Листинг 2. Директива о кредите, выраженная в виде правила в понятиях бизнес-словаря
Когда один из отчетов о кредитоспособности имеет рейтинг ниже 500,
занести должника в черный список.

Если клиент находится в черном списке, прекратить с ним отношения 
и отправить ему объяснение причин.

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

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

Бизнес-цели, задачи и результаты

На концептуальном уровне модель OMG Business Motivation Model (BMM) также предоставляет структуру для сбора и отслеживания бизнес-результатов, соответствующих бизнес-директивам. BMM признает, что там, где намечается реализовать бизнес-директивы, можно также использовать различные стратегии для отслеживания бизнес-результатов.

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

Бизнес-результаты или показатели могут быть как качественные, так и количественные.

  • Бизнес-цели представляют собой заявление об ожидаемом состоянии или положении бизнеса, если бизнес-директивы дали ожидаемый результат. Бизнес-цели обычно определяются качественно и предусматривают длительное время на выполнение данного изменения.
    • Бизнес-цель – перевод всех систем на использование нового AML-процесса на протяжении следующего года.
    • Бизнес-цель – гарантирование защиты персональной идентификационной информации.
  • Бизнес-задачи определяются как детальные показатели производительности в конкретных контрольных точках для выполнения бизнес-директивы. Они обычно количественные и имеют очень точные временные рамки, в которых должны быть выполнены. Часто они могут определяться как ключевые индикаторы производительности (KPI) или критические факторы успешности (Critical Success Factors – CSF).
    • Бизнес-задача – за первый месяц использования нового AML-процесса ожидается выполнение 10000 AML-проверок. Для измерения выполнения AML-проверок можно было бы на ежемесячной основе определять KPI и собирать сведения о процентном соотношении идентифицированных проблем.
    • В обеспечение выполнения PCI – гарантировать выполнение должной проверки посредством отслеживания неудачных попыток регистрации в системе, а также определения количества нормальных попыток и количества попыток атак на систему.

Архитектурный уровень

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

Работая с приведенным выше примером, разработчик архитектуры может определить, что бизнес-директива (т.е. AML) должна применяться для "кассиров". Директива предполагает, что внутри банка есть роль "кассир", и что эту роль выполняют люди. Обеспечение динамичности бизнес-процессов означает, что в архитектуре можно распознать задания для пользователя (human task) и автоматизированные задания. В составе архитектуры может иметься определение задания "кассир", но для новой директивы роль может потребовать изменения. Например, задания могут меняться с задания для пользователя на автоматизированный поток работ. На архитектурном уровне важно рассмотреть каждую директиву и на основе ряда критериев решить, выражать ли ее как политику и как ее выразить так, чтобы обеспечить выполнение этой политики. Разработчики архитектуры могут понять, что идентификация того, кто является "кассиром" с точки зрения бизнеса, может не только потребовать новой связанной бизнес-политики (как идентифицировать, кто является кассиром для бизнеса), но и включить определение этой бизнес-роли в оперативные средства развертывания пользователей, где компоненты управления пользователями устанавливают соответствующую оперативную политику управления доступом (т.е. кассиры имеют доступ к банковским транзакциям). Установка оперативных политик защиты, подобных такой политике для кассира, не является уникальным явлением, и могут потребоваться различные модели руководства, чтобы различными способами гарантировать идентификацию людей при обращении к любому типу данных, размещенных в любом бизнес-активе (бизнес-политика).

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

На архитектурном уровне может поддерживаться и другая директива выделения займов путем определения нового общего архитектурного сервиса, способного предоставлять кредитные баллы. Для поддержки сбора и повторного использования общих исполнимых элементов может понадобиться использование технологии BRMS (Business Rule Management System – система управления бизнес-правилами). В зависимости от степени детализации бизнес-словаря правило может быть точным вычислением или выражением условий для удовлетворения или отклонения заявки о займе или определения сроков и условий займа. Такое разграничение является одной из задач разработчиков архитектуры, когда они конкретизируют бизнес-цели и бизнес-задачи. Важно помнить, что при выборе этих архитектурных решений по-прежнему остается необходимость сверяться с бизнес-директивами и бизнес-политиками. Разработчики архитектуры определяют, какие показатели можно будет собрать и где они будут сопоставляться для того, чтобы элементы управления во время исполнения предоставили бизнес-клиенту соответствующие бизнес-данные.

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

Такое разнообразие вариантов показывает, почему важно рассматривать политики и правила как часть экосистемы динамичности, в которой важным бизнес-требованием является сбор директив и обеспечение отслеживаемости применения бизнес-политики. Организовываются ли задания для пользователей в поток работ (например, BPEL for People) или же бизнес-процессы автоматизируются в BPM-пакетах, стратегия обеспечения выполнения бизнес-политик подкрепляется использованием механизмов правил и систем управления политиками. После того как набор бизнес-директив сформирован и бизнес-требования к динамичности собраны, архитектурный уровень несет ответственность за сбор вариантов реализации. Варианта, подходящего для всех случаев, не существует. Бизнес-аналитики, разработчики архитектуры и ИТ-персонал должны принять коллективное решение, основанное на ценности для бизнеса и затратах.

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

Пример директивы о противодействии отмыванию денег (anti money laundering – AML):
финансовая организация не должна принимать платежи, которые могут поставить ее
и ее владельцев в условия, когда возможно применение криминальных штрафов
и наказаний.

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

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

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

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

Разработчик архитектуры может начать процесс уточнения бизнес-директив, используя классификацию и субклассификации, определенные в экосистеме бизнес-правил. Двумя обычно используемыми подтипами являются: структурные типы (Structural) и поведенческие (Behavioral) или оперативные (Operational) типы.

Рисунок 4. Бизнес-директивы – подтипы бизнес-правил
Рисунок 4. Бизнес-директивы – подтипы бизнес-правил

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

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

Рисунок 5. Декомпозиция поведенческих правил
Рисунок 5. Декомпозиция поведенческих правил
Рисунок 5. Декомпозиция поведенческих правил

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

Ограничения (Constraints) – это нечто необходимое, то, что должно быть сделано обязательно. Ограничение может явно использовать слово "ТРЕБУЕТСЯ", либо быть менее явным, например "необходимо, чтобы" (и обычно реализуется обязательно).

Рекомендации (Guidelines) предупреждают о нежелательных обстоятельствах (и часто транслируются в предупреждающие сообщения).

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

Решения (Decisions) – это подтип, в котором с помощью математических формул из существующих данных создается новая информация.

ECA, Event Condition Action (действие условия события) – это специфический шаблон правила, где условие вычисляется при обнаружении события. Большинство ECA-правил используют временные операторы для поиска событий, связанных с их временем создания или возникновения. Формулирование правила "Отфильтровать события с данным символическим именем за последние х секунд и объединить с вычисленным значением показателя value = price * volume" потребовало бы специального выражения, и механизму правил во время исполнения потребовался бы сохраняющий состояние (statefull) механизм скользящего временного окна для поддержки выполнения этого выражения. Фиксация семантик временных условий является очень важной задачей аналитика правил на этапе анализа.

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

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

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

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

Оперативный уровень

На рисунке 3 показано, что кроме жизненного цикла между бизнес-уровнем и архитектурным уровнем существует жизненный цикл между архитектурным и оперативным уровнем. Все стороны должны понимать, что часто требуется еще одна итерация для уточнения бизнес-директив до уровня оперативных действий. Мы также исходим из того, что информационная технология (ИТ) – это бизнес-функция, и часто оперативная среда будет иметь свои собственные ограничения бизнес-политики, которые архитектура должна учитывать. Заявленные бизнес-директивы, собранные в приведенных выше примерах, можно рассматривать как отражение точки зрения одного направления бизнеса (Line of Business – LOB) или группы LOB. Имеются и другие бизнес-директивы, выразить и контролировать которые может потребовать руководитель службы безопасности или руководитель службы информации.

Например, разработчики архитектуры, проектирующие решение, должны знать о существовании и степени детализации оперативных точек принятия стратегических решений (policy decision points – PDP) или точек обеспечения выполнения политик (policy enforcement points – PEP), чтобы спроектированное решение соответствовало диапазону управления, обеспечиваемому оперативными политиками. Если имеющаяся оперативная среда не может обеспечить выполнение политик, предлагаемых разработчиками архитектуры (посредством точек разработки политик – Policy Authoring Point), они должны вместе с ИТ-специалистами обеспечить исполняемость этих новых директив. Организации часто делегируют ИТ-службе ответственность за выбор того, где и как делать реализовать политики для нескольких LOB (в целях их согласованности и оптимизации). Типичным примером является политика защиты сообщений, которую часто нужно применять последовательно и в конкретной точке оперативной инфраструктуры, например, в демилитаризованной зоне. На ограничения оперативных политик часто влияет тип оборудования, обеспечивающего выполнение политики, или общие директивы защиты сети.

Ожидается, что делегированные ИТ-службе бизнес-директивы гарантируют, что политики, выполняемые в демилитаризованной зоне, фактически реализуют бизнес-директивы, изначально выраженные бизнес-политиками, хотя достигаться эта цель может многими способами, в том числе и использованием правил. Поэтому на рисунке 3 показано, что процесс уточнения политик и правил ВКЛЮЧАЕТ "круговые" (round tripping) оперативные измерения для предоставления бизнес-пользователям сопоставления оперативных и бизнес-показателей. Правила могут использоваться и в ИТ-, и в LOB-приложениях, и после внедрения оптимальных архитектурных методик и практики повторного использования разработчики архитектуры могут создать общую структуру, удовлетворяющую обоим наборам требований.

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

Пример архитектуры обеспечения выполнения оперативной политики для управления защитой показан ниже на рисунке.

Рисунок 6. Обеспечение выполнения оперативной политики
Рисунок 6. Обеспечение выполнения оперативной политики
Рисунок 6. Обеспечение выполнения оперативной политики

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

Если продолжить нашу интерпретацию принципов BMM, сбор бизнес-директив (согласно BMM) также включает в себя сбор угроз и возможностей (Threats and Opportunities), а, кроме того, сбор стратегий и тактик (Strategies and Tactics), обычно на архитектурном уровне.

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

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

Причина передачи этой ответственности разработчикам архитектуры заключается в том, что оценка должна выполняться в контексте различных архитектурных стилей (например, SOA) и учитывать передовые методики применения реализаций правил (например, в дизайне сервисов, в выборе сервисов, в координации сервисов) и механизмы обеспечения выполнения политик. Архитектурные стили имеют также свои собственные передовые методики для таких аспектов, как применение пакетов управления бизнес-процессами (BPM) для решения проблем эффективности бизнес-процессов (т.е. путем идентификации "кто участник?", "когда они должны участвовать?", "что они должны делать?"). BPM-пакеты могут поддерживать как автоматизированных участников, так и участников-пользователей. Говоря коротко, бизнес-логика, реализуемая в BPM, связана с человеком, заданием и данными для обработки в задании. Во время принятия решения о том, какие люди могут выполнять те или иные задачи, большинство организаций группируют людей по функциональным "ролям", так что разработчики архитектуры должны работать как с бизнес-владельцами определений ролей, так и с оперативными владельцами заданий, распределяемых пользователям. Часто критерий выполнения человеком задания связан с ролями, которые ему назначены, и большинство организаций выражают их как бизнес-политики, включающие в себя временное назначение роли индивидууму (например, в случае каникул) или позволяющие одному человеку дать задание для выполнения другому человеку (делегирование). Система BPM может быть дополнена системой управления бизнес-правилами (BRMS), которая дополняет BPM-задание вопросом "почему?": почему оно ведет себя таким образом, почему принято такое решение. Разработчики архитектуры могут побудить бизнес-аналитиков использовать BRMS для поддержки изменения правил путем использования предопределенных структур с целью определения факторов динамичности бизнеса в структурированной форме (например, выражение If then else или таблица решений, поток правил, дерево решений, функция, шаблон правила) для использования в наборе бизнес-процессов простых шаблонов развертывания, логических заключений или сопоставления с шаблонами.

Заключение

Использование политик и правил для обеспечения выполнения выбранных бизнес-стратегий и тактик и мониторинга бизнес-целей дает ряд преимуществ для бизнеса с точки зрения уменьшения затрат и способности адаптироваться к краткосрочным и долгосрочным изменениям. Достижение больших результатов при неизменном бюджете и расширение возможностей бизнес-пользователей – весьма позитивный шаг в согласовании интересов ИТ и бизнеса.

Ключевые моменты:

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

Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=644398
ArticleTitle=Политики и правила – повышение динамичности бизнеса: Часть 1. Поддержка динамичности бизнеса
publish-date=04042011