10.3.2. Архитектура предприятия (EA)

Потоки работ, потоки данных, использование данных, связь информационных систем с потоками работ

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

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

Хотя технологические истоки EA по-прежнему прослеживаются, ее диапазон расширился и стал включать бизнес-вопросы. В моделировании архитектуры центральное место начинают занимать процессные модели. Обычно это взгляд более высокоуровневый по сравнению с BPMS или BPA. Моделирование обычно базируется на одном из двух основных подходов к описанию бизнеса – TOGAF или матрице Захмана[205].

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

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

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

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

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

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