Коллектив авторов - Свод знаний по управлению бизнес-процессами - BPM CBOK 3.0

Как и BPMS, EA имеет дело с процессными моделями, при этом они отражают взгляд, отсутствующий в BPMS: связь приложений с шагами процессов и друг с другом и потоки данных между приложениями.

Примечание:к взгляду на организацию от бизнеса программное обеспечение EA добавляет взгляд от технологий.

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

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

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

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

Машины бизнес-правил [206] Rules engines . – Прим. пер. обеспечивают выявление, описание и оптимизацию технологических и бизнес-правил. Также они предоставляют репозиторий, с помощью которого правила сопоставляются друг с другом на предмет конфликтов в определении или в контексте, обеспечивая тем самым их качество и отсутствие дублирования. Для сегодняшних движков характерен технический уклон, и их использование требует обучения и компетенции в технологиях.

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

Обычно каждое правило можно отнести к одной из следующих категорий:

• правила функционирования бизнеса;

• правила принятия решений;

• правила последовательности действий;

• процедурные правила и политики;

• правила использования/защиты данных;

• правила разграничения доступа;

• правила мониторинга и отчетности;

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

• юридические правила;

• финансовые правила;

• правила мониторинга и измерений;

• нормативные правила.

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

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