Джон Месберг: Однако самое главное в концепции Smart SOA состоит в том, что IBM предлагает простые подходы к решению проблем заказчиков. По мнению Месберга, ИТ-компании часто продвигают слишком сложные, комплексные решения там, где в этом нет никакой необходимости. Джон Месберг комментирует предлагаемые IBM подходы к реализации сервис-ориентированной архитектуры.

- Вы рекомендуете пять «точек входа» в SOA, соответствующих пяти простым способам перехода к сервис-ориентированной архитектуре на предприятии. Почему IBM предлагает именно такие стартовые шаги?

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

Применение этих способов может быть весьма успешным в целом ряде случаев, однако сегодня мы видим, что большинство проектов не занимаются технологиями ради технологий. Это бизнес-проекты, призванные принести реальную коммерческую пользу. Поэтому остальные три «точки входа» — люди, процессы, информация — затрагивают те области, которые связаны с SOA с точки зрения бизнес-руководства. Во-первых, люди. Лидеры бизнеса сегодня стремятся наладить эффективную совместную работу своих сотрудников, причем не только в рамках предприятия, но и за его пределами, в географически распределенном контексте. Далее, процессы — здесь рассматривается все то, что касается моделирования и развертывания гибких адаптируемых бизнес-процессов на предприятии. И, наконец, информация — в этой «точке входа» мы говорим о возможностях совместного использования информации, получения нужных данных в любом месте в любое время.

- Каковы наиболее серьезные препятствия, мешающие компаниям успешно пройти эти «точки входа» в SOA?

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

Еще одна проблема состоит в том, каким образом определять сервис. Скажем, в компании есть финансовый отдел и отдел продаж, и тот и другой хотят получить информацию о клиентах. В обоих случаях мы, казалось бы, должны реализовать один и тот же сервис. Однако, запрашивая информацию о клиентах, разные отделы имеют в виду разные вещи. Финансовому отделу нужны данные о контрактах, оценка кредитоспособности клиента и прочее. А специалистов отдела продаж интересует, например, имя директора, день рождения его жены, чтобы вовремя послать подарок и т. д. Таким образом, хотя с технической точки зрения на высоком уровне абстракции все выглядит одинаково, конкретное наполнение сервиса оказывается совершенно различным.

Третий момент — проблема мастер-данных. В «чистой» SOA, как ее определяют в университетах, работа идет по принципу «запрос-ответ». При этом сервис выглядит как черный ящик, и внешнему миру неизвестно, что происходит внутри него. Сервис должен быть полностью автономным, так чтобы все необходимое для получения ответа определялось запросом. В результате запрос может оказаться очень сложным, содержать огромное количество мастер-данных и т. д. В простых XML-сообщениях трудно отправлять такой объем данных, поэтому в конкретных реализациях помимо обращения к сервису подразумевается направление запроса в базу данных. Таким образом нарушаются базовые принципы классической SOA.

IBM способна предложить решения этих проблем.

- Являются ли эти решения технологическими или включают в себя методологические аспекты?

И то, и другое. Вернемся к примеру двух отделов, запрашивающих информацию о клиентах. При решении этой проблемы необходимо прийти к согласию по поводу терминологии. Можно, конечно, для разных отделов определить разные сервисы получения информации о клиентах, но это приведет к такому объему сервисов, с которым будет очень трудно работать. Необходимо сделать так, чтобы был один сервис, но его практические реализации для разных отделов могли отличаться друг от друга. Для этого нужна единая терминология, соглашения о формате наименований, общие библиотеки. Это методологический аспект решения проблемы, есть и соответствующие технологические механизмы.

- Предложенные пять шагов являются исчерпывающими для успешной реализации SOA? Или для наиболее продвинутых компаний вы можете порекомендовать дополнительные «точки входа»?

Хотя эти пять подходов достаточно широки, нельзя заявлять, что они являются полностью исчерпывающими. Вполне могу представить появление заказчика, который реализует SOA способом, не попадающим ни в одну из перечисленных категорий.

Но я и не хочу сказать, что достаточно выбрать одну из этих пяти «точек входа», и успех вам обеспечен. Существует очень много других факторов, влияющих на реализацию SOA. Важно определить общее направление, но дальше появятся новые варианты выбора. Например, какое программное обеспечение промежуточного слоя использовать? На успех влияют и такие факторы, как эффективность руководства ИТ (IT Governance), приверженность топ-менеджмента компании данному проекту.