Одной из причудливых особенностей ИТ-отрасли является наша любовь к трехбуквенным аббревиатурам (three letter acronym, TLA). Есть очень умные маркетологи, выжимающие из новых трехбуквенных сочетаний максимум возможного. Они воплощают мечты и надежды всей ИТ-отрасли в притягательном наборе букв, которые так мощно и убедительно смотрятся на слайде PowerPoint. Одним из последних достижений маркетологов как раз и является SOA, или сервис-ориентированная архитектура, если вам это больше нравится. На протяжении нескольких лет SOA повсеместно продвигалась как универсальное средство от многих проблем, с которыми приходится сталкиваться отрасли — особенно если речь заходила о снижении затрат и повышении маневренности. Аналитики, поставщики и конечные пользователи — все вдруг преисполнились энтузиазма. Аналитики Butler Group, к примеру, утверждают, что только 3% организаций отвергли SOA. А недавний опрос, который был проведен системным интегратором Griffiths Waite, назвавшим 2008 год критически важным для реализации проектов SOA, показал, что 15% организаций уже внедрили у себя сервис-ориентированную архитектуру, а 38% встали на этот путь. Оставшиеся 47% пока предпочитают сохранять роль наблюдателя, но в сложившейся ситуации, по мнению аналитиков Giffiths Waite, уже в ближайшее время они «приступят к выработке стратегии и планированию».

Вместе с тем, несмотря на впечатляющий рост, на фоне новостей о первых неудачах на фронте SOA начинают все громче звучать и скептические голоса. Энн Томас Мейнс, вице-президент и научный директор Burton Group, недавно решила поднять в своем блоге тему внедрения корпоративной сервис-ориентированной архитектуры. И вот что она пишет: «Бесконечные интервью меня уже у томили… стало ясно: в большинстве организаций SOA не работает». Несмотря на «потрясающе красивые» инфраструктуры SOA, разрабатываемые компаниями, их инициативы SOA «неизменно стопорятся». Технические специалисты просто не могут продать SOA представителям основного бизнеса. Они до сих пор вынуждены проводить демонстрации, поясняющие выгоду, которую вся эта инфраструктура принесет бизнесу. Технические специалисты не в состоянии объяснить в бизнес-подразделениях, зачем нужно что-то улучшать, внедряя практику совместного использования и взаимодействия. А ведь это те самые фундаментальные культурные перемены, которые необходимы для успешного внедрения SOA. Как заметил один из собеседников Мейнс, «альтруизм не может быть корпоративной стратегией».

Мейнс подняла очень важный вопрос: мы можем предлагать бизнесу такое количество технологий (и трехбуквенных аббревиатур), какое захотим, но технологии сами по себе не гарантируют появления бизнес-ориентированных решений. Реальная опасность заключается в том, что, если при реализации инициатив SOA нам не удастся достичь целей, о которых год или полтора тому назад кричали аршинные заголовки на слайдах PowerPoint, начнется мощная обратная реакция. Отношение к SOA как к «простому и очевидному» мгновенно трансформируется в вопрос: «Ну и что?»

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

Возьмем, к примеру, железнодорожное предприятие, у которого имеется три системы резервирования билетов: одна предназначена для организации самообслуживания через Web, другая эксплуатируется персоналом на станциях, а третья служит для поддержки заказов по телефону. Решив перераспределить функции приложений и преобразовать их в корпоративные «службы», компания использовала подход SOA. К сожалению, впоследствии обнаружилось, что у каждого приложения имеется собственная база данных и каждая из этих баз претендует на собственную версию истины. И если служба технической поддержки персонала на станциях обновляет сведения об имеющихся местах каждые 10 минут, то телефонное приложение реплицирует информацию с часовым интервалом, а Web-приложение выполняет эту операцию только раз в день. В результате данные о наличии свободных мест зависят от того, какое приложение вы используете, а между приложениями и системой управления резервированием возникают разночтения.

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

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

Каким же образом, наблюдая за реализациями инициатив SOA или только приступая к работе над соответствующим проектом, избежать в дальнейшем вопроса: «Ну и для чего нужна эта SOA?»

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

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

Пожалуй, трудно сформулировать все это лаконичнее, чем сделал Дана Гарднер в 2006 году: «Не пытайтесь ставить телегу SOA впереди лошади метаданных, с тем чтобы не допустить роковую ошибку с точки зрения инвестиций в информационные ресурсы. Такой подход поможет вашей архитектуре вывести эффективность процедур на максимальный уровень и добиться коммерциализации знаний, воспользовавшись плодами тяжелой работы по управлению и оптимизации данных».

Тони Сиэлз — технический директор компании Celona Technologies, специализирующейся на технологии переноса информации третьего поколения

Tony Sceales. How to avoid your SOA initiative becoming a big «So What?»