Почему люди хотят внедрить у себя SOA и действительно ли им это нужно?

«Когда речь заходит о SOA, я всегда задаю один и тот же вопрос: как вы думаете, чем руководствуется любое мало-мальски приличное предприятие при внедрении какой бы то ни было технологии или архитектуры? Ответ, как обычно, состоит из стандартного набора фраз: большая возможность повторного использования кода, доступность.… Однако истинная причина заключается вовсе не в технологиях, которые обещают столько преимуществ. Что я вижу своими глазами – так это то, что на самом деле SOA (впрочем, как и любая другая прогрессивная ИТ-технология) внедряется на предприятиях в сугубо личных целях, а именно – для удовлетворения своих сугубо личных карьеристских устремлений, и это ни коим образом не связано с желанием преобразить работу предприятия». Такой взгляд на проблему внедрения SOA сложился у Якова Фейна, управляющего компанией Farata Systems, занимающейся консалтингом, обучением и поставкой программных продуктов. По его мнению, если вы решили внедрить у себя SOA, то это еще вовсе не значит, что она вам действительно нужна на данный момент. Во многих случаях это действительно так. Давайте разберёмся, почему могло сложиться подобное мнение, и есть ли в нем доля правды, ведь в любых точках зрения, как правило, присутствует рациональное зерно.

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

SOA-инициативы, идущие снизу

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

SOA-инициативы, идущие сверхуЭто более сложный случай. На конференцию сходил не какой-нибудь архитектор, а сам директор по информационным технологиям. Наслушавшись речей энергичного оратора, столь красноречиво расписавшего все мыслимые и немыслимые преимущества, которые только способна дать нам SOA, он приходит на работу… Подчинённые не имеют ничего против, они тоже рьяные карьеристы, у них свои цели…

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

Все сотрудники ИТ-отдела будут трудиться, не покладая рук и засучив рукава, изо всех сил пытаясь уложиться в сжатые сроки. И снова мы забываем о библии разработчиков программного обеспечения, о знаменитой книге Брукса “The Mythical Man-Month”, ставшей уже притчей во языцех.

Один из ее постулатов гласит, что омлет, который пообещали подать к столу через две минуты, может быть действительно подан через две минуты. Однако, если омлет так и не подали к столу через две минуты, у посетителя есть только две альтернативы: подождать еще или есть сырой омлет. У повара есть другая альтернатива – сделать огонь побольше. Увы, после этого омлет почти всегда безвозвратно испорчен: он местами сырой, а местами подгоревший.

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

Готовность предприятия к переходу на SOA

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

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

Итак, вы ощущаете потребность перевести ваше предприятие на SOA. Однако не стоит спешить; Яков Фейн советует оценить степень зрелости вашего предприятия, т.е. уровень его готовности к этому шагу. Для этого спросите себя, готова ли ваша организация к подобным переменам? Располагает ли она компетентными специалистами в данной области? Подготовлена ли инфраструктура предприятия к внедрению SOA? Поинтересуйтесь соглашением об уровне сервиса и протоколом SDLC. Какую методологию вы планируете применять для идентификации сервисов? Много ли у вас «обернутых» приложений-посредников? Вы знаете, как «обертывать» ваши CICS-приложения в Web-сервисы, но готовы ли ваши разработчики к переобучению? Как у вас обстоят дела с управлением?

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

Прежде всего, необходимо привлечь специалиста (предпочтительно, стороннего консультанта), который бы проанализировал инфраструктуру вашего предприятия и оценил степень готовности вашего предприятия к переходу на SOA. Это должен быть объективный и честный анализ, выполненный специалистом или группой специалистов, на основе которого вы сможете судить, действительно ли внедрение SOA – это оптимальный выбор для вашей организации на данный момент? Оценка степени готовности предприятия к переходу на SOA – это действительно очень важный момент.

Технические преимущества, которые дает SOA

Если провести инвентаризацию всех приложений, функционирующих в крупной организации, и обмена данными между ними, получится довольно сложная схема. Приложение А передаёт данные приложению Б. Хорошо, если приложение А способно передавать те же данные еще и приложениям В и Г. Однако это требует некоторого преобразования данных. Для этого сотрудникам вашего ИТ-отдела нужно просто создать и развернуть новые ETL-процессы (процессы, с помощью которых осуществляется извлечение, загрузка и преобразование данных), которые сделают возможным обмен данными между приложениями А и В, А и Г.

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

Конечно, “После” на этой схеме выглядит гораздо проще, чем “До”. Однако сами посудите, во сколько вашей фирме обойдётся воплощение этой схемы в жизнь? Не будет ли гораздо дешевле и проще написать новый ETL-скрипт для каждой новой пары приложений, чем приобрести сервис, который можно многократно использовать, по-крайней мере, на данный момент?

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

ESB-инфраструктура

Корпоративная сервисная шина (ESB) предполагает наличие централизованного отдела, сотрудники которого обладают соответствующими умениями и навыками. То, каким образом он будет финансироваться, - это уже другой вопрос: на это будет выделяться либо часть бюджета каждого проекта, либо это будет внутренний консалтинг, либо и то, и другое. Решать вам. Необходимо также соглашение об уровне сервиса, которое будет являться залогом того, что требования приложений, использующихся всеми отделами, своевременно удовлетворяются. Следует чётко определить уровень качества сервисов (будет ли сервис функционировать круглосуточно, или же вы зададите определённые временные рамки его функционирования – опять же, решать вам).

Не стоит забывать и об обновлении и поддержке версий сервисов. Это совсем не то же самое, что обновление и поддержка версий приложений. Дело в том, что некоторых клиентов, например, вполне удовлетворяет версия 3.2, а других – нет. Так что вам придётся поддерживать как версию 3.2, так, скажем, и версию 3.3.

И снова вернёмся к вопросу о человеческом факторе. Вы уверены, что у вас хорошие отношения с командой, занимающейся вопросами ESB? Личные отношения не менее, а, может быть, и более важны, чем банальные соглашения об уровне сервиса. Кстати, у Иван Иваныча, который возглавляет отдел по разработке ESB, тоже свои амбиции и весьма субъективные цели.

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

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

Вам также придётся повысить уровень своей квалификации, потратить время на собственное обучение и на подготовку данных к преобразованию в другой формат, необходимый для их функционирования в условиях новой ESB-инфраструктуры. Необходимо будет задать верный формат для ввода и вывода данных для каждого нового приложения, а также задокументировать его в соответствии с процессом SDLC (разработка и поддерживание жизненного цикла систем), используемым в вашей организации. Насколько быстро ваша команда разработчиков инфраструктуры сможет написать и протестировать скрипт преобразования данных для вашего приложения-получателя?

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

Внедрять SOA или не внедрять

Все вышесказанное вовсе не означает, что вам надо отказаться от идеи внедрения SOA. Просто Яков Фейн советует как следует подготовиться к этому серьёзному шагу, ведь вам, определённо, придётся начинать с «нуля», а автоматизацию работы предприятия нельзя строить на пустом месте.

Знакомы ли вы с приведённой ниже диаграммой?

Можно сравнивнить попытки внедрить SOA поспешно и на пустом месте с попыткой Наполеона завоевать Москву. Приведённый рисунок – не что иное как карта, отражающая запланированные Наполеоном действия: коричневым показана численность армии Наполеона на пути к Москве, а черным – на пути из Москвы. Толщина линий говорит сама за себя. Отступление Наполеона было обречено на провал в условиях сильнейших морозов, отсутствия пастбищ для лошадей и т.д.

Фейн призывает не повторять ошибку Наполеона и не начинать SOA-проект без надлежащей подготовки.

Осчастливить корпоративных пользователей

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

Думаете, им все равно, какой архитектурой вы пользуетесь для передачи им данных? А вот и нет. Они обязательно спросят: «Хорошо, мы инвестируем часть своих средств и ресурсов в ваш SOA-проект на 1 год. Изменится ли стиль ведения нашего бизнеса за этот год? Предоставите ли вы нам большее количество аналитических данных в более удобной форме? Станет ли деятельность наших торговых агентов по работе с клиентами более успешной и эффективной и увеличатся ли объёмы наших продаж?»

SOA + RIA

Для того чтобы привлечь конечного пользователя, нам никак нельзя не учитывать его интересы и уровень его осведомленности. В качестве примера рассмотрим iPod. Много ли людей знают название бренда-конкурента? А что вы предпочитаете: iPod от компании Apple или Zune от Microsoft? Zune отличается несколько большей функциональностью, но iPod симпатичнее и обладает более удобным пользовательским интерфейсом. Люди готовы сегодня же расстаться с 600$ ради того, чтобы купить новинку от Apple под названием iPhone, хотя это всего лишь обычный телефон с возможностью выхода в Интернет и имеющий небольшой встроенный дисковый накопитель для хранения музыки. Ничего особо нового в мире сервисных технологий. Однако крайне положительное отношение потребителей к этому бренду и его популярность заставляют людей желать приобрести именно этот телефон.

То же самое можно сказать и о SOA. Люди любят красивые безделицы, это касается не только технологических новинок, но и программных интерфейсов. SOA будет намного легче предлагать потребителю и реализовывать, если клиентские приложения будут иметь удобный, привлекательный и простой в использовании интерфейс. Так, например, финансовому аналитику вашей компании непременно захочется приобрести графический пользовательский интерфейс с анимированными диаграммами и графиками, облегчающими процесс сравнения эффективности работы двух взаимных фондов. Такой интерфейс будет необычайно востребован среди аналитиков. Конечно, за вами остаётся целый фронт работ, связанных с программированием сервисов, которые будут получать и передавать данные, однако хороший уровень представления вашей архитектуры – уже добрая половина дела, это очень важно. Так что когда вы создаёте или модернизируете приложение, думайте не только о мощных мультипроцессорных серверах, многопоточности и ESB. Учитывайте мнение и предпочтения пользователей. Информируйте пользователей и формируйте у них положительное отношение к вашим SOA-технологиям. Пусть они слышат о них дома, на работе, за рулем. Ваше приложение должно быть лёгким в управлении и отзывчивым, совсем не таким как приложения десятилетней давности на основе Visual Basic и PowerBuilder.

RIA

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

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

В середине 90-х огромную популярность приобрёл Интернет. Люди получили возможность обращаться к множеству удалённых сервисов через красиво и удобно оформленные страницы и получать оттуда самую разнообразную информацию. С точки зрения графического пользовательского интерфейса это был своеобразный регресс, поскольку Web-страницы, по сути, выступали в роли все той же пресловутой ЭВМ, только вместо черного экрана с зелеными буквами был цветной фон со статическими изображениями и теми же самыми текстовыми полями, кнопками и простейшими HTML-таблицами.

И вот теперь мы имеем дело с графическими пользовательскими интерфейсами, эволюционировавшими до вида RIA-приложений. RIA – это не обычные постраничные Web-сайты, а полноценные и легко контролируемые развёртываемые приложения с большими функциональными возможностями, в том числе аудио и видео, состояние которого можно сохранять в его клиентской части. Эти приложения не нужно устанавливать, они попадают в персональный компьютер пользователя непосредственно через Интернет.

На сегодняшний день приложения RIA создаются с помощью Adobe Flex или AJAX. Уже этом году появится новинка Silverlight от Microsoft, а в 2008 г. Sun Microsystems собирается предложить нам новое решение на основе JavaFX RIA. Также для создания RIA-приложений можно использовать OpenLaszlo. Эти, а также многие другие средства можно использовать для создания RIA-приложений. Ведущие компании предпочитают привлекать для этого профессионалов в области дизайна и разработки этих Web-приложений нового поколения.

Итак, если вы архитектор, занимающийся SOA-проектом, не зацикливайтесь на серверах, кластерах и распределённых вычислениях. Лучше подумайте о бизнес-пользователях. Предложите им что-нибудь привлекательное, и они, несомненно, оценят и поддержат вашу инициативу по внедрению SOA, которую воспримут с таким же энтузиазмом, как если бы это был плейер iPod или телефон iPhone. SOA необходимо заслужить доверие и уважение у клиента. Не недооценивайте человеческий фактор!

По материалам сайта soa.sys-con.com

Комментарии