Эта область сегодня переживает изменения. В прошлом Архитектура предприятия занималась в основном IТ-архитектурой бизнеса. Она предоставляла модели аппаратного и программного обеспечения: операционные системы, промежуточное и инструментальное ПО, а также прикладные системы, особенно в части использования ERP и других больших систем (то есть интегрированных модульных приложений, как, например, информационные системы в здравоохранении). Акцент делался на использовании IТ для решения проблем бизнеса. EA трактовали в основном как моделирование всего бизнеса и поддерживающих IТ-систем и последующее использование IТ для решения проблем бизнеса.
Хотя технологические истоки EA по-прежнему прослеживаются, ее диапазон расширился и стал включать бизнес-вопросы. В моделировании архитектуры центральное место начинают занимать процессные модели. Обычно это взгляд более высокоуровневый по сравнению с BPMS или BPA. Моделирование обычно базируется на одном из двух основных подходов к описанию бизнеса – TOGAF или матрице Захмана[205].
Архитектура предприятия занимается структурой бизнеса, в которую обычно включают бизнес-стратегию, процессы, бизнес– и IТ-инфраструктуру, оргструктуру и культуру. Модели EA могут также включать внешние компоненты, оказывающие воздействие на бизнес.
Как и BPMS, EA имеет дело с процессными моделями, при этом они отражают взгляд, отсутствующий в BPMS: связь приложений с шагами процессов и друг с другом и потоки данных между приложениями.
Хотя программное обеспечение EA в какой-то степени конкурирует с традиционными BPMS, обычно их используют для разных целей. EA плохо подходит для быстрой итерационной разработки, так как обычно в нем отсутствуют имитационное моделирование и возможность декомпозиции процессов на более низкие уровни детализации. Однако возможность связывать аппаратное и программное обеспечение с бизнес-действиями – ценная и уникальная функциональность EA. Наиболее мощные средства EA предоставляют обширную функциональность в части определения требования и управления ими в ходе цикла разработки, генерации кода на одном или нескольких языках программирования, реверс-инжиниринга унаследованных приложений, моделирования баз данных, отладки приложений и т. д. Большинство средств также поддерживают совместную работу с разграничением доступа.
Хотя многие средства EA используют символы BPMN, взаимодействие их с BPMS складывается непросто. Это может быть проблемой, так как означает сосуществование двух наборов моделей, которые легко могут разойтись.
По мере того как корпоративная архитектура становится менее ориентированной на IТ и более ориентированной на бизнес-операции, она начинает вторгаться в область смежных дисциплин бизнес-архитектуры и процессной архитектуры. Как следствие, вероятно возникновение путаницы в ролях и ответственностях. Но сегодня тем не менее существует разница между более физическим взглядом от EA и более концептуальным взглядом от бизнес-архитектуры – каковы наши бизнес-способности и технологические возможности и как они отражают стратегию. В итоге же и там, и там дело сводится к процессам, которые относятся к области процессной архитектуры. В ходе установления границ между этими дисциплинами можно ожидать серьезных потрясений и взаимных проникновений.
10.3.3. Машины бизнес-правил и системы управления бизнес-правилами (BRMS)
Технологические и бизнес-правила определяют, каким образом работа будет выполняться в каждом действии и на каждом шаге потока работ или процесса. Это официально закрепленные знания компании и то, что отличает ее от конкурентов. Они определяют кто, что, когда, почему и как будет делать и как будет осуществляться контроль. С технической точки зрения правила представляют собой логику бизнеса.
Машины бизнес-правил[206] обеспечивают выявление, описание и оптимизацию технологических и бизнес-правил. Также они предоставляют репозиторий, с помощью которого правила сопоставляются друг с другом на предмет конфликтов в определении или в контексте, обеспечивая тем самым их качество и отсутствие дублирования. Для сегодняшних движков характерен технический уклон, и их использование требует обучения и компетенции в технологиях.
На практике правила выглядят как выражения «если – то»: «если» (событие или значение), «то» сделать что-то. Поскольку список вещей, которые надо учитывать при принятии решений, может быть достаточно длинным и сложным, определение правил может оказаться серьезной задачей.
Обычно каждое правило можно отнести к одной из следующих категорий:
• правила функционирования бизнеса;
• правила принятия решений;
• правила последовательности действий;
• процедурные правила и политики;