Service-Oriented Enterprise Architecture (SOEA)

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

Проблема в том, что пытаясь использовать SOA как инструмент согласования ИТ и бизнеса, ИТ-специалисты остались в своем мире технологий. Начиная разговор о SOA с бизнес-руководством они быстро сползают в специфику реализации и интеграции систем. А бизнесу это, по большому счету, неинтересно. Совсем. Бизнес хочет получить результат. За определенное время, в рамках соответствующего бюджета, с определенным качеством. Всё. Какие Web-сервисы? Какие шины? Какие компоненты?... Классическая подмена информационных технологий чистыми технологиями.

С моей точки зрения, SOA - не о компонентах, шинах и Web-сервисах. Это все - частные инструменты реализации архитектурного подхода к использованию технологий, одним из которых является SOA. Внедрить SOA нельзя. Так же, как нельзя внедрить middleware, сервер приложений, ITIL или PMBOK. Это все инструменты достижения цели. SOA - архитектурный и даже, в определенном плане, методологический инструмент рещения задач, стоящих перед ИТ.

Но каковы бизнес-задачи, стоящие перед ИТ? Что заставляет ИТ-индустрию создавать такие инструменты как SOA? Таких задач перед ИТ, по большому счету, три:

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

К сожалению, ИТ чаще всего фокусируется только на первой задаче. Ко второй задаче ИТ чаще всего подходит реактивно, реагируя на сумасшедшие на первый взгляд “хотелки” бизнеса, но так или иначе справляется с этим. А вот третья задача хорошо если “схлопывается” до сбора требований или описания бизнес-процессов, но к сожалению редко когда включает в реальной жизни полноценный анализ и модернизацию сквозных процессов операционной деятельности. Максимум до чего доходят руки – до процессов самого ИТ-подразделения, благо COBIT и ITIL уже аккумулировали соответствующие подходы. Но вот что интересно, берем понятия сервиса, ИТ-сервиса и бизнес-сервиса в ITIL v3:

• Service
  A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.
  
  
• IT Service
  A Service provided to one or more Customers by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the Customer's Business Processes. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Level Agreement.

• Business Service
  1. An IT Service that directly supports a Business Process, as opposed to an Infrastructure Service which is used internally by the IT Service Provider and is not usually visible to the Business.
  2. The term Business Service is also used to mean a Service that is delivered to Business Customers by Business Units. For example delivery of financial services to Customers of a bank, or goods to the Customers of a retail store. Successful delivery of Business Services often depends on one or more IT Services.

Смотрим на определение бизнес-сервиса. А вот тут как раз “засада”. С одной стороны, это называется Business Service. С другой – определяется как IT Service (точгда чем он отличается от бизнес-сервиса? Еще одной прослойкой архитектурного пирога?). Проблема заключается в том, что корни ITIL лежат в IT Operations - деятельности по эксплуатации информационных систем и, чего уж греха таить - в первую очередь оборудования и инфраструктуры. Давайте абстрагируемся от ИТ и от первого варианта определения бизнес-сервиса, предлагаемого ITIL v3. Возьмем его второй вариант. И те же E-mail или видеоконференц-связь рассматриваем как доступные бизнес-пользователям бизнес-сервисы, предоставляемые ИТ-подразделением, наравное с тем как тем же пользователям предоставляются соответствующие финансовые сервисы (начисление зарплаты, производимое бухгалтерий) и т.п.. Все сразу встает на свои места. Тогда первый вариант определения необходимо либо отбрасывать, либо интерпретировать как бизнес-сервис, предоставляемый IT, наравне с бизнес-сервисами HR, финансового подразделения, отдела продаж и т.п. Т.е. IT Service в ITIL является на самом деле подмножеством бизнес-сервсов. Проблема ITIL заключается в том (и это видно например по обсуждению в его третьей версии и SOA и Enterprise Architecture), что в большинстве случаев при постановке ITSM-процессов в ИТ-департаментах, создании каталога услуг, бизнес-сервисы интепретируются в соответствии с первым вариантом определения, а не со вторым, ограничиваясь только ИТ и, концентрируясь на системах и инфраструктуре, что естественно, так как речь идет об IT Operartions.

Забудем об IT Operations, но вспомним о разработчиках. Они привыкли мыслить в терминах систем и интерфейсов (конечно, а данном случае имеются в виду API, а не user interface). И используя понятие сервиса, разработчики понимают под ним интерфейс, удовлетворяющий определенным правилам единого описания (по-сути контракта) и технологического (программного) обращения к нему. В таком контексте система несет определенный функционал, а интерфейс системы определяет сервис, предоставляемый системой по автоматизации определенных бизнес-процессов, в рамках соответствующего соглашения - контракта. Тут и возникают ESB, EDA, asynchronous messaging, Web-services (как одна из возможных технологий стандартизации доступа к интерфейсам) и т.п. Но является ли такой вариант интерпретации бизнес-сервисом? Нет. Понятен ли он бизнесу? Категорически нет. Обсуждая SOA, под сервисом в большинстве случаев понимается технологический интерфейс доступа к функциональности системы, а не бизнес-сервис, предоставляемый структурным подразделением или организационной единицей бизнес-пользователям. Вот здесь и лежат корни проблемы превращения SOA в buzzword, описанной в самом начале.

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

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

Можно возразить, что SOA как раз о технологиях. Но тогда может не стоит приплетать сюда бизнес и логично опустить бизнес риторику? И честно поставить SOA в один ряд с OOP, AOP, DCE и другими чисто ИТ-шными понятиями.

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

Собственно, в результате такого рода анализа я и пришел к тому, что называю

SOEA – Service-Oriented Enterprise Architecture

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

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

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

Элементы SOEA
(кликните для загрузки диаграммы)

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

Модель SOEA
(кликните для загрузки диаграммы)

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

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

Реализация бизнес-сервисов и автоматизация выполняемых ими бизнес-процессов обеспечивается функциональными системами.

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

Интеграционная модель в SOEA
(кликните для загрузки диаграммы)

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