Содержание


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

Часть 2. Демонстрация преимуществ использования политик и правил

Comments

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

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

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

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

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

Введение

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

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

Обзор

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

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

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

В некоторых случаях, при использовании системы Business Rules Management System (BRMS), решение может предоставить правила управления жизненным циклом в сочетании с улучшенными инструментальными средствами для реализации сложных правил, что может облегчить реализацию показателей для анализа производительности политик и правил в аналитических решениях. Возьмем рассмотренный ранее пример директивы о противодействии отмыванию денег (anti money laundering – AML): финансовое учреждение не должно принимать платежи, которые могут поставить ее и ее владельцев в условия, когда возможно применение криминальных штрафов и наказаний. Ясно, что AML существует только там, где имеет место процесс открытия счетов (Account Opening) финансовых фирм. Всегда, когда процесс, его ограничения и рекомендации встраиваются в неизменяемое приложение, наличие динамичного BPM-процесса либо динамичного рабочего процесса процесс будет влиять на решения о том, как наилучшим образом удовлетворить специфические требования бизнеса. В случае с AML ожидается, что эта оценка будет основываться на информации о новом клиенте, собранной при конкретных проверках нового пользователя, и на проводимых им транзакциях. Выбор того, какую часть процесса существующего приложения можно выделить из основной задачи в отдельное вычислительное правило, которое затем будет возвращать результаты обратно в процесс, зависит от многих бизнес-факторов. Если динамичность встроена в процесс разработки, после открытия счетов можно добавлять дополнительные политики и правила на основе новых транзакционных событий для дальнейшего уточнения анализа и выяснения, наблюдаются ли для счета подозрительные транзакции, которые могут поставить финансовую организацию под подозрение в нарушении AML, и инициировать действия по расследованию и формированию отчета.

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

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

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

  • Модель использования 1. C чего начать? Модульность основана на идентификации общих элементов.
  • Модель использования 2. Как обеспечить выполнение имеющейся политики?
  • Модель использования 3. Как адаптироваться к изменениям, появляющимся в дальнейшем?
  • Модель использования 4. Как быстрее приступить к развертыванию?
  • Модель использования 5. Достижение переломного момента – оптимизация с BRMS.
  • Модель использования 6. Достижение согласованности – как разрешить регламентированные отраслевые политики и правила.

Модель использования 1. Идентификация обычно используемых элементов и шаблонов

Во многих случаях одна бизнес-политика может выражаться сложным набором правил. Модульность типов и подтипов правил позволяет выразить бизнес-политику в виде структурных бизнес-правил и поведенческих бизнес-правил. Хорошая структура правил позволяет повторно использовать элементы правил в бизнесе. Например:

  • Организационные характеристики, когда клиенты бизнес-сервисов могут быть сгруппированы по категориям "золотой", "серебряный", "бронзовый", - это хороший пример повторно используемого бизнес-правила, если можно извлечь критерий определения данного состояния. Если бизнес-процесс является согласованным, определение правила идентификации "золотого" клиента может использоваться повторно для обеспечения выполнения многих разных бизнес-политик.
  • Поведенческие характеристики, такие как ограничения (Constraints), например, кредитные лимиты, и рекомендации (Guidelines) – например, предупреждения о низком уровне счета, - могут в сочетании с другой информацией или другими бизнес-правилами использоваться для принятия динамических решений во время выполнения. Бизнес-правило может обеспечивать выполнение бизнес-политики для разрешения увеличения кредитной линии в рамках определенного набора ограничений (например, расширить кредит, если на текущем счету имеется мало средств, а на сберегательном счету – больше 50000). Определение "мало" может реализовываться бизнес-правилом.

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

  • Кандидаты для поведенческого подтипа Event Condition Action (действие условия события) идентифицируют поведенческие шаблоны событий.
    • Определяйте не только шаблон событий, но и действие, которое нужно предпринимать на его основе.
  • Кандидаты для поведенческого подтипа Process flow (поток процесса) обрабатывают функции и решения в определенном порядке и подразумевают активизацию соответствующего действия для каждой функции в процессе.
    • Определяйте частоту изменений потока процесса и все ограничения.
  • Кандидаты для поведенческих подтипов Computational (вычислительный) или Decision (решение) принимают входные данные и возвращают результат.
    • Определите дискретные правила с изменяющимися уровнями сложности и динамичности изменения правил или потока правил, а затем скомпонуйте решение.

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

  • Шаблон, в котором события (Events) и решения (Decisions) могут использоваться совместно для реализации бизнес-директив.
    Там, где обрабатываются события и обнаруживается специфичный шаблон событий (но до какого-либо действия), следует принять бизнес-решение по определению самого подходящего действия или невыполнению действия вообще (например, транзакции по кредитной карте при выявлении потенциального мошенничества).
  • Шаблон, в котором поток процесса (Process flow) и решения (Decisions) могут использоваться совместно для реализации бизнес-директив.
    В потоке процесса для определенного действия в потоке может понадобиться вычислительное решение, а там, где имеется несколько ветвлений в потоке, возможно, потребуется принять решение для выбора ветви (например, вычислить окончательную цену, включающую несколько единиц товаров, налоги и расходы на упаковку и пересылку).
  • Шаблон, в котором поток процесса (Process flow) и мониторы производительности, бизнес-аналитику (Business Analytics) или информационную панель KPI (KPI Dashboard), можно использовать совместно для реализации бизнес-директив и измерения бизнес-результатов. Определяются ключевые индикаторы производительности процесса и пороговые значения для нормального и отклоняющегося поведения (например, измерение ежедневного производства продукции и сравнение с запланированным).
Рисунок 1. Основные подтипы поведенческих бизнес-правил
Рисунок 1. Основные подтипы поведенческих бизнес-правил
Рисунок 1. Основные подтипы поведенческих бизнес-правил

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

  • Решения Event Condition Action (событие-условие-действие). Ожидается частое добавление новых событий, изменение и добавление шаблонов событий. Зачастую такие решения являются детерминистскими в способе обработки бизнес-политик и бизнес-правил. Такие решения часто обрабатывают большие объемы событий и имеют требования к производительности, предполагающие конкретный архитектурный шаблон для решений обработки бизнес-событий (Business Event Processing – BEP).
  • Решения с потоком процессов могут быть статичными или весьма динамичными по природе. Их можно классифицировать 4 способами:
    1. Приложения с фиксированным потоком процессов и статическими ограничениями, требующими изменений конфигурации в приложении, которые, в свою очередь, потребуют перезапуска для вступления новых изменений в силу.
    2. Приложения или программное обеспечение промежуточного уровня, обрабатывающие потоки сообщений или данных и позволяющие реализовать улучшенную динамичность выполнения изменений в потоке посредством инструментальных средств динамичной разработки. Развязывание потока и функций улучшает динамичность и уменьшает количество необходимых изменений.
    3. Определяя полностью отдельный от приложений и сервисов уровень организации взаимодействия процессов с четко определенными интерфейсами, использующими стандартные протоколы и интерфейсы для повторного использования и активизации, мы переходим на новый уровень динамичности. Такие решения называются BPM-решениями (Business Process Management – управление бизнес-процессами).
    4. Процесс, способный динамически настраивать функции потока и сервисы, активизируемые на базе политик и правил, основанных на содержимом, контексте, предоставленном процессу, и каналах, по которым процесс активизируется, использует для принятия решений технологию типа Inference (логическое заключение).
  • Вычислительные поведенческие правила или правила решений можно классифицировать на три категории:
    1. Детерминистские решения, где правила могут описываться в конструкциях "if then", таблицах решений или деревьях решений. Задается определенный детерминистский способ обработки правил.
    2. Динамические решения, где может быть определено много правил, однако порядок их применения является динамичным, поскольку соответствующие правила выбираются динамически механизмом логических заключений на основе содержимого и контекста входных данных.
    3. Оптимизационные решения, основанные на вычислениях, используются для определения оптимальных значений ограничений ресурсов на основе пакета смоделированных сценариев или реальной хронологической информации.
  • Решения для бизнес-аналитики и информационных панелей KPI применяются для идентификации и доступа к бизнес-информации, связанной с конкретными бизнес-целями и подробными задачами, необходимыми для измерения производительности.
    • Детализированные запросы для консолидации данных из нескольких источников в полезную бизнес-информацию при помощи решений бизнес-аналитики или информационных панелей (Dashboards).
    • Решения для информационных панелей KPI, которые принимают события из решений, реализующих действия, условия и события, потоки процесса и решения, и сопоставляют их с предопределенными KPI.

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

Рисунок 2. Детальные ИТ-реализации
Рисунок 2. Детальные ИТ-реализации
Рисунок 2. Детальные ИТ-реализации

Модель использования 2. Локализованные и централизованные политики и точки обеспечения выполнения политик

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

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

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

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

Оптимальной методикой практически во всех случаях является уменьшение объема и обеспечение управляемости для общих данных и бизнес-логики, используемых в нескольких точках обеспечения выполнения. Преимущества централизованных точек принятия решений таковы:

  1. Можно унифицированным способом обеспечить отслеживаемость и возможность проведения аудита.
  2. Облегчается проведение аудита при использовании централизованной системы сбора данных и отчетности для аудита, поскольку легче гарантировать согласованное внедрение изменений, когда имеется общий набор данных аудита для просмотра и отслеживания бизнес-аналитиками.
  3. Управляемость – при определении централизованной распределенной модели важно определить согласованную модель жизненного цикла для запросов изменений, тестирования, создания версий, развертывания и удаления старых версий.

Модель использования 3. Оптимизация жизненного цикла для логики процесса и приложения

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

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

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

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

Рисунок 3. Выделение бизнес-логики из процесса
Рисунок 3. Выделение бизнес-логики из процесса
Рисунок 3. Выделение бизнес-логики из процесса

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

  1. Адаптируемость. Повышается при упрощении процессов, а это, в свою очередь означает, что они реже будут требовать изменений. Небольшие изменения теперь могут быть выполнены во внешней логике принятия решений реализующей ограничение, что позволяет выполнять изменение отдельных политик и правил.
  2. Отслеживаемость. Улучшается на уровне бизнес-политики и правил. Важно отслеживать, какие приложения и процессы активизируют ту или иную бизнес-политику и бизнес-правило, поэтому для общей отслеживаемости необходимы взаимосвязи.
  3. Управляемость. Модели жизненного цикла оптимизируются в соответствии с характером изменений, которых требует бизнес для часто и редко меняющихся активов.
  4. Повторная используемость. Отделяя аспекты, управляемые бизнес-политиками, и аспекты, управляемые бизнес-правилами, от конкретных процессов приложения, можно значительно повысить шансы повторного использования политик и правил в различных приложениях и процессах.

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

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

Модель использования 4. Управление жизненным циклом точек изменчивости бизнеса

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

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

  1. Во время проектирования ИТ-специалисты должны согласиться на реализацию динамичности в приложениях путем определения конкретных свойств и идентификации потенциальных точек обеспечения выполнения политик. Это может помочь обеим сторонам оценить влияние ожидаемых изменений и планировать подобные ситуации. Упреждение изменений и планирование поможет прояснить диапазон отдельных бизнес-политик и семантику бизнес-правил, которые нужно собрать и протестировать в исходном проекте. Правильно спроектированные динамичные бизнес-процессы предоставляют бизнес-агентам возможность выразить набор точек динамичности (agility point) для большинства обычно изменяемых бизнес-значений. Эти бизнес-агенты затем могут быть уполномочены менять оперативные параметры в управляемых границах, которые ИТ-отдел может поддерживать, но за реализацию которых не отвечает.
  2. Для развертываемых решений ИТ-отдел может предоставлять возможность поддерживать эти изменения динамичных свойств бизнес-пользователями (через информационные бизнес-панели и др.) таким образом, чтобы они могли независимо менять бизнес-поток работ (согласованно с общим руководством) и иметь возможность активизировать ИТ-действия (или автоматизированные компоненты) для всех зависимостей, которые требуют переноса запроса в исполняемое развертывание обновленных механизмов бизнес-политик и бизнес-правил (т.е., создавать интегрированный бизнес- и ИТ-поток работ для изменения).

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

Рисунок 4. Управление жизненным циклом точки изменчивости бизнеса
Рисунок 4. Управление жизненным циклом точки изменчивости бизнеса
Рисунок 4. Управление жизненным циклом точки изменчивости бизнеса

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

  1. Адаптируемость. Бизнес-пользователям разрешено выполнять мелкие изменения для поддержки краткосрочных требований, но под строгим руководством ИТ-отдела.
  2. Отслеживаемостью и возможностью проведения аудита можно управлять более централизовано в рамках решения для управления политиками и правилами.
  3. Управляемость. ИТ-отдел разрешает бизнес-пользователям более непосредственно управлять динамичностью наиболее часто меняющихся свойств, что освобождает ИТ от многих задач обслуживания.
  4. Повторная используемость. При использовании переменных для выполнения правил и свойств модель обеспечения выполнения политики и правил с большей вероятностью будет содержать повторно используемые шаблоны для правил и политик, которые можно будет настроить для других сценариев с другими значениями переменных с целью удовлетворения других бизнес-требований.

Модель использования 5. Управление бизнес-политиками, требующими большого набора правил

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

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

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

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

Во втором примере директива бизнес-политики – это выражение, являющееся сочетанием:

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

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

Ценность начала с небольшого решения состоит в том, что вы можете расширять ваши методики обеспечения динамичности по мере роста уверенности в них. Нередко встречаются решения, требующие объединения примеров 1 и 2 одновременно.

  1. Адаптируемость. В обоих примерах наличие группы бизнес-политик, реализованных на платформе, поддерживающей высокую динамичность, является значительным преимуществом и важнейшим шагом как к управляемости бизнеса, так и к реализации динамичности.
  2. Отслеживаемость и возможность проведения аудита рекомендуется реализовать в более централизованно руководимом решении, охватывающем эти модели использования.
  3. Управляемость. При большом количестве взаимосвязанных политик ключевым моментом является наличие платформы для поддержки политик различных типов и нескольких взаимосвязанных политик.
  4. Повторная используемость. Наличие платформы, поддерживающей множество политик и правил и позволяющей использовать их совместно с целью удовлетворения новых специфичных бизнес-требований является значительным шагом вперед.

Модель использования 6. Отраслевые регламентированные политики и правила

По мере глобализации бизнеса и расширения круга партнеров в разных географических регионах увеличивается важность соблюдения межгосударственных и внутригосударственных нормативов. Требования ИТ-интеграции привели к созданию специальных отраслевых стандартов для обеспечения ведения бизнеса стандартными способами, с меньшими затратами на интеграцию и при необходимости лучшими возможностями осуществления аудита. Примером из сферы банковских услуг является обеспечение выполнения политик противодействия отмыванию денежных средств (Anti Money Laundering – AML). Это сложный набор политик, охватывающих многие аспекты, которые реализуются как людьми, так и автоматизированными системами. Еще одним примером может быть закон США "О перемещаемости и подотчетности страхования здоровья" (Health Insurance Portability and Account Act), охватывающий национальные стандарты системы здравоохранения, а также личные права и права на медицинское обслуживание. Область действия этой политики распространяется на политики и правила конфиденциальности, политики и правила системы защиты, правила транзакций и обеспечения выполнения.

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

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

Если выбран последний вариант, например CBS-сервис (Composite Business Service), реализующий HIPAAЮ, то он уже построен на динамичной ИТ-платформе, интегрируемой с другими гетерогенными системами динамичным образом.

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

  1. Адаптируемость. В данной модели использования мы больше фокусируемся на отраслевых стандартах и на том, насколько легко мигрировать на обновленные версии новой бизнес-политики с минимальным влиянием на существующие системы, когда система поддерживает динамичность.
  2. Отслеживаемость и возможность проведения аудита – это ключевой момент. Выбор между двумя решениями должен отражать базовые архитектурные требования к поддержке отслеживания и аудита. Необходимо внимательно сопоставить возможности отслеживаемости пакетированного решения и компонентного решения с бизнес-требованиями.
  3. Управляемость. Если в компании используются гетерогенные решения, оптимальным в большинстве случаев является компонентный подход с добавлением динамичности.
  4. Повторная используемость. Этот пример показывает, что отраслевые группы также должны учитывать потенциал динамичности, поскольку соблюдение специфичных стандартов требуется все чаще.

Заключение

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

Мы рассмотрели следующие основные темы:

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

Мы идентифицировали пять основных ИТ-шаблонов:

  1. Наличие централизовано управляемых репозиториев артефактов и общих форматов для объектов (т.е. защита и аутентификация пользователей, роли и потребители) может помочь выразить политики для этих объектов.
  2. Наличие решения с обработкой событий и сопоставлением с шаблонами может помочь оптимизировать политики, связанные с содержимым и контекстом, а также организовать обеспечение выполнения политик, связанных с событиями.
  3. Применение решений для организации потоков процессов, которые сами являются динамичными, может предоставить потенциальные точки интеграции, где для улучшения динамичности обеспечение выполнения политик можно объединить с такими функциями, как управление последовательностью действий в потоке. Выбор подхода (стандартные приложения, BPM или Dynamic BPM) зависит от бизнес-требований к динамичности.
  4. Там, где необходимы централизованное управление правилами и вычислительные правила, полезна система управления бизнес-правилами (Business Rules Management System) как инструмент, предоставляющий бизнес-пользователям возможность изменять свойства правил, как средство поддержки сложных бизнес-правил и как централизованная точка принятия решений, в которой одна и та же политика/правило может иметь несколько точек выполнения.
  5. Там, где бизнес-логика, инкапсулирующая бизнес-решения и правила, меняется чаще, чем решение с потоком процессов или обработкой событий, создание комбинированных шаблонов с бизнес-решениями и правилами, имеющих свой собственный жизненный цикл, минимизирует общие изменения и повышает динамичность бизнеса.
  6. Там, где бизнес-результаты определены в терминах бизнес-целей и задач, наличие решений, использующих бизнес-аналитику и/или информационные бизнес-панели для измерения производительности, являются ключевым аспектом отслеживания эффективности.

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


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=644965
ArticleTitle=Политики и правила – повышение динамичности бизнеса: Часть 2. Демонстрация преимуществ использования политик и правил
publish-date=04062011