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

SOA изначально предполагает, что сервис является не только и не столько технологическим, сколько бизнес-сервисом. Самодостаточность, заменяемость и/или повторная используемость технологического сервиса лишь вытекают из сути бизнес-сервиса. Первичен именно бизнес-сервис. С другой стороны, что есть бизнес-сервис, если он не связан с бизнес-процессами? Поэтому часто в контексте SOA мы упоминаем Business Process Management (управление бизнес-процессами), явно или неявно подразумевая реинкарнацию концепции реинжиниринга бизнес-процессов, введенной в обиход Майклом Хаммером и Джеймсом Чампи в начале 90-х и повлиявшей на культуру управления и организационную структуру многих компаний.
Проблема «идентификации» SOA, на мой взгляд, связана с попыткой обсуждения архитектуры сразу на нескольких уровнях и/или фокусирования только на технологической составляющей в отрыве от бизнес-процессов и наоборот.
В большой степени SOA можно и даже необходимо рассматривать как инструмент, который помогает обеспечить реинжиниринг не в рамках процесса прорисовки бизнес-процессов, а с точки зрения создания их целостной картины и соответствующего технологического обеспечения единого и интегрированного ландшафта приложений и систем. Cуществует даже такое понятие, как SOA Governance, которое является продолжением стратегического управления или руководства ИТ (IT Governance).
Именно контекст бизнеса и бизнес-сервисы являются принципиальным аспектом SOA, отличающим ее от просто технологической архитектуры интеграции. Более того, SOA – архитектурный стиль, одна из принципиальных черт которого – отражение реальных бизнес-процессов, как это определяет The Open Group (http://www.opengroup.org). SOA по своей сути не зависит от конкретных технологий, используемых при построении прикладной инфраструктуры.
Можно сказать, что с точки зрения формулируемых целей в SOA нет ничего нового по сравнению с традиционной концепцией EAI (Enterprise Application Integration). Единственное отличие – использование терминов не приложений, а бизнес-процессов, которые этими приложениями автоматизируются. Глубокое заблуждение думать иначе, отсюда и катастрофически широко распространенная «болезнь» говорить о SOA только в терминах технологий.
Логично, что анализ бизнес-целей, идентификация и приоритизация бизнес-сервисов, установление связей между ними в виде бизнес-процессов – все это лежит в основе построения SOA как следующего шага в согласовании бизнеса и ИТ после определения BSA – Business Services Architec-ture. В совокупности и BSA, и SOA составляют основу корпоративной архитектуры (Enterprise Architecture – EA). При этом необходимо понимать, что они не определяют ее полностью, так как есть архитектура данных, инфраструктура и многие другие не только ИТ-аспекты. Какова же роль SOA в стратегии организации прикладных систем как отражения бизнес-сервисов в общей EA? Одна из ведущих. Можно сказать, что SOA становится неотъемлемой частью представления корпоративной архитектуры предприятия, которая, в свою очередь, охватывает и организационную составляющую, и базовую инфраструктуру (сети, центры обработки данных, средства хранения и доступа и т. п.), и многие другие аспекты планирования.