Сервис-ориентированная архитектура не просто наступает - она уже здесь. С вероятностью 99% SOA уже просочилась в вашу компанию независимо от выбранного вами пути. Ведь сегодня практически любая технология строится на основе SOA.

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

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

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

«Вопросы повторного использования постоянно находятся в центре внимания ИТ-директоров в США, но практически не беспокоят ИТ-руководителей организаций в Южной Америке, Южной Африке, на Ближнем Востоке и в Азиатско-Тихоокеанском регионе, — заметил Френк Кенни, научный директор компании Gartner Research. — За пределами США речь идет в основном не о сокращении расходов на зарплату персоналу ИТ-службы, которые и так минимальны, а о том, чтобы извлечь максимальную выгоду из имеющихся компонентов, процессов и людей, включая даже унаследованные активы. Если здесь говорят о необходимости повторного использования, то там — о бизнес-процессах. Однако на самом деле интерес представляет сочетание бизнес-процессов и повторного использования».

Возможно, это и так, но, тем не менее, повторное использование по-прежнему остается важной частью данного симбиоза. Возникает вопрос: каким образом от расплывчатых планов перейти к практическому объединению столь разных и неоднородных элементов? «Общее правило состоит в том, что для получения максимальной выгоды необходимо добиваться повторного использования тех служб, которые ваши программисты задействовали сразу в нескольких приложениях, — советует Джулия Крейг, старший аналитик ассоциации Enterprise Management Associates (EMA). — Рекомендуется выбрать лучшего архитектора SOA из тех, что удалось найти, и возложить на него принятие соответствующих решений». Подобно опытному организатору свадьбы, архитектор SOA способен сгладить ваши ошибки и просчеты. В этом случае основные мероприятия пройдут относительно безболезненно, главным образом благодаря исключению любых непредвиденных и нежелательных сюрпризов.

«По мере того как корпоративная программа SOA приобретает все более отчетливые очертания, количество осложнений возрастает, поскольку концепция повторного использования не была своевременно и достаточно проработана, — констатирует Сантош Моханти, возглавляющий направление Global Technology Excellence в компании Tata Consulting Service (TCS), которая является ведущим поставщиком консультационных услуг по вопросам SOA. — Разработка механизма управления SOA предполагает определение политик и процедур, регламентирующих управление владением службами, порядок взаимодействия служб, повторное использование компонентов и количественную оценку показателей времени проектирования и выполнения, а также времени на внесение изменений. Все это позволит предприятиям эффективно управлять любыми перерасходами и создаст гарантии того, что программа SOA находится под контролем».

Предположим, у вас возникнет желание взять на себя вопросы повторного использования или вам захочется контролировать действия своего архитектора SOA с привлечением других грамотных специалистов. С чего следует начать?

Начните с определения преимуществ и недостатков SOA в целом. «Проектирование любого программного обеспечения (не только SOA) — это всегда компромисс между возможностями дальнейшей поддержки и развития, производительностью, снижением уровня рисков и стоимостью, — пояснила Крейг. — Повторное использование компонентов позволяет сократить затраты и получить дополнительные преимущества, поскольку вы обращаетесь к уже протестированным и доказавшим свою работоспособность службам, вместо того чтобы каждый раз писать что-то новое. В этом случае значительно меньшее число компонентов потребуют поддержки, что в свою очередь тоже приведет к сокращению затрат.

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

На следующем этапе определяется, какие компоненты имеет смысл использовать повторно в первую очередь. Учтите, что необязательно проделывать сразу все одним махом.

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

Понятно, что, когда ребенок учится ходить, очень важно придерживаться правильных установок. Так какую ногу и куда следует ставить?

По мнению Сандры Роджерс, директора направления SOA, Web Services, and Integration Research компании IDC, основой для повторного использования компонентов является наличие «инфраструктурных и технологических служб, информационных служб или служб обработки данных, а также общих функциональных процедур».

Многие организации начинают обычно с инфраструктурных или технологических служб (обеспечивающих, в частности, безопасность, мониторинг и аудит), с тем чтобы освободить разработчиков бизнес-приложений от рутинной работы и позволить им сосредоточиться на проектировании компонентов, несущих в себе добавленную стоимость. Это помогает также добиться согласованности с корпоративными протоколами и сформировать среду для эффективной корректировки имеющихся процедур. «Кроме того, такой подход создает дополнительные условия для повторного использования служб за счет поддержки более безопасной и управляемой среды, — пояснила Роджерс. — К другим ключевым областям повторного использования относятся сферы, обеспечивающие общее информационное представление. К примеру, получение контактной информации о клиенте является процедурой, которая повсеместно применяется в биллинговых системах, в области продаж, поддержки клиентов, обработки заказов и т.д.».

Подобный переход способствует тому, что все процедуры получают одну и ту же прошедшую проверку и подтвержденную информацию. Огромным подспорьем может стать создание фонда служб обработки данных. «Предприятия, развивающие так называемые mashup-приложения, получают, помимо всего прочего, еще и формализованные специализированные представления», — подчеркнула Роджерс.

Общее повышение эффективности зависит и от решения других задач (связанных, например, с обработкой заказов или проверкой соответствия процедур предъявляемым к ним требованиям), особенно если в этом процессе принимают участие независимые компании. «В данном случае отдельные подразделения освобождаются от поддержки систем, выполняющих соответствующие стандартные процедуры», — отметила Роджерс.

По сути, повторное использование предполагает, что все находящиеся в совместной эксплуатации элементы и службы доступны для применения и изучения, пользуются доверием и обладают достаточной масштабируемостью для удовлетворения растущего спроса. «Если организации намерены внедрять повторно и совместно используемые службы в масштабах всего предприятия, нужно решать соответствующие вопросы, а также обеспечить необходимую их поддержку и финансирование», — предупредила Роджерс.

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

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

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

«Статичные отношения не могут рассматриваться в качестве допустимого варианта в условиях, когда вам необходимо постоянно проявлять гибкость и маневренность, продвигаясь вперед в русле Internet, cloud и других модных современных тенденций», — резюмировал с усмешкой Стронг.

Pam Baker. Best reuse plays in SOA. CIO.com. 08/04/2008