SOA: Сервис-ориентированная архитектура ... бизнеса!

Слишком часто, если не сказать, что в подавляющем большинстве случаев, в той или иной степени публичные обсуждения (в блогах, на конференциях, в web-форумах) или презентации (производителей, интеграторов) SOA фокусируются на технологических аспектах - ESB, адаптеры/коннекторы, платформенные решения (.NET, J2EE) и, конечно, продуктах. Проблема в том, что при таком взгляде не менее часто "за деревьями не видно леса".

Собственно о каком "лесе" идет речь? Это концепция выделения бизнес-сервисов, в первую очередь. Оценка их значимости для функциональных подразделений организации, как следствие - их приоритезация. Только после проведения такой работы можно говорить о возможной SOA-стратегии (а это именно стратегия, так как речь идет о комплексной задаче, причем - масштабов предприятия) и о возможном успехе ее реализации. По институтским годам вспоминается пресловутая аббревиатура НиДУ - Необходимое и Достаточное Условие. Определение бизнес-сервисов, как мне кажется, может (в подавляющем большинстве случаев) рассматриваться как необходимая составляющая реализации SOA. И именно с получения понимания о бизнес-потребностях (Business Case) и их значимости (потенциальном ROI - Return On Investment) начинается работа в рамках SOA-инициативы. Здесь не могу не привести ссылку на презентацию Дэвида Линтикума, которую он делал на OMG SOA Information Day - в ней, как раз, рассматриваются важные шаги для успешного построения SOA. Вообще-то, мы получем многостороннюю задачу - это и взгляд IT Governance с формированием и управлением ИТ-портфелем, это и business reengineering, направленный на совершенствование не только бизнес-процессов, но и организационной структуры, а, зачастую, методов управления. (я уже отмечал эти моменты раньше). Построение SOA не является технической инициативой - это полноценный бизнес-проект, с привлечением ИТ в качестве активного игрока, влияющего на изменения бизнеса. Успех его, как любого другого бизнес-проекта, обуславливается вовлечением менеджеров высшего звена, не только подписывающих бюджет, но принимающих или как минимум влияющих на принятие стратегических бизнес-решений.

Вопрос бюджетирования, связанного с построением SOA начинается он с вопроса - считать (рассматривать, а, соответственно, "считать" уже в смысле денег) ли "внедрение SOA" (на первый взгляд, звучит так же размыто и криво как "внедрение ИКТ") самостоятельным проектом или "растворять" соответствующие затраты в других, как тактических, так и стратегических проектах. Если бизнесу удалось правильно продать концепцию SOA, как инструмент повышения эффективности бизнеса - тогда это, конечно, отдельная строка бюджета. А если не удалось .... можно ли говорить о SOA? Может быть, вся деятельность так и останется частным (пусть и несколько миллионным) проектом. А может и приведет к новой итерации процесса продажи бизнесу инструмента решения его потребностей.

Вы уже, наверняка, заметили, что "внедрение SOA" я использовал в кавычках, а построение SOA - как есть. Построение SOA есть построение сервис-ориентированной архитектуры бизнеса, в которой под сервисами понимаются самодостаточные функции повторно используемые различными LoB бизнеса (Line of Business). Вот здесь я хотел бы привести два масштабных примера разработки концепции SOA как бизнес-архитектуры:

1. FEA Consolidated Reference Model созданная в рамках развития US Federal Enterprise Architecture (FEA)
Именно в этом документе определяются бизнес-сервисы "Service for Citizens Business Area" (см. стр.26 документа - Figure 8 с таким же названием). Вот это и есть тот пример выделения бизнес-сервисов по функциональным областям/LoB, если таковые термины можно использовать в применении к сервисам, предоставляемым государством своим гражданам. Здесь не лишне кажется процитировать позиционирование FEA:

"A BUSINESS-DRIVEN APPROACH
In contrast to many failed “architecture” efforts in the past, the FEA is entirely business-driven. Its foundation is the Business Reference Model, which describes the government’s Lines of Business and its services. This business-based foundation provides a common framework for improvement in a variety of key areas such as:

• Budget Allocation
• Information Sharing
• Performance Measurement
• Budget / Performance Integration
• Cross-Agency Collaboration
• E-Government
• Component-Based Architectures "
  

На какие документы, связанные с обсуждаемым вопросом, стоит обратить внимание:

• FEA Practice Guidance. December 2006.
  
• Services and Components Based Architectures. A Strategic Guide for Implementing Distributed and Reusable Components and Services in the Federal Government. Executive Strategy. Last Updated: January 31st, 2006
• Service Component Reference Model (SRM)

2. UK-инициатива: Transformational Government. Enabled by Technology.

Первичная идентификация сервисов, в том числе "повторно используемых" присутствует в документе "Enterprise Architecture for UK Government. An overview of the process and deliverables for Release 1" (см. стр.8 - раздел Business Functional Areas View), разработанном Chief Technology Officer (CTO) Council.
...

Конечно, масштабы конкретной SOA-инициативы должны соответствовать размерам бизнеса и учитывать степень влияния ИТ на его жизнеспособность. В этом плане мне очень понравилась заметка "Little SOA vs. Big SOA".

Логично сказать - да, все это может быть и красиво, но в России .... (см.например, мнение Евгения Чичваркина "Мужская консультация" в его колонке в журнале "Секрет Фирмы") Насколько в действительности готовы российские бизнесы и их ИТ-подразделения к такому взгляду? Для ответа на этот вопрос прокрутите последние важные обсуждения в своем собственном ИТ департаменте, а когда будет минутка - почитайте стенограмму и комментарии к круглому столу "Конструктор для бизнеса" на iOne.

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