Джонатан Хопфнер и Филипп Й. Виндли

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

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

Что действительно не дает покоя руководителям ИТ-отделов, так это мучительный вопрос: «Как заставить всех работать вместе?» Этот вопрос волнует и Майка Роадза, руководителя отдела по разработке унифицированного ПО компании IBM Software Group Asia-Pacific. Он убежден, что SOA лишь на 1% состоит из сервисов и на 99% из грамотного управления. Одним словом, технологии – это самое простое, усилия следует направить на то, чтобы сплотить людей в одну большую рабочую команду и обеспечить бесперебойную совместную работу.

С Майком Роадзом полностью согласен и Иво Тотев, вице-президент и руководитель маркетингового отдела и член совета директоров компании Crossvision product, занимающейся поставками программного обеспечения. Он подчеркивает, что SOA нельзя свести к одним лишь технологиям, хотя, конечно же, многое должно быть сделано на уровне ИТ-отделов, но еще важнее суметь не просто объединить, а установить действительно плодотворное сотрудничество между ИТ- и бизнес-подразделениями. Именно такое, плодотворное, сотрудничество способно сделать бизнес действительно гибким и успешным.

По мнению Джорджа Вонга, главного менеджера и финансового директора компании BEA Systems, точнее, подразделения компании, имеющего дело со странами АСЕАН, внедрение SOA делает бизнес более гибким, наделяя его способностью быстро реагировать на любые изменения конъюнктуры рынка. SOA также вносит фундаментальные изменения в культуру ведения бизнеса. Так что без грамотного управления здесь просто не обойтись.

Для того чтобы управлять действительно грамотно, прежде всего, необходимо понять, что же это значит. Иными словами, нужно разобраться в том, что такое «грамотное управление». Питер Вейлл и Дженни Росс в своей книге IT Governance определяют управление следующим образом: « [управление] заключается в распределении обязанностей, установлении круга ответственности и системы отчетности с целью оптимального использования ИТ.» Анил Джон, корпоративный архитектор лаборатории прикладной физики университета Hopkins University, считает, что управление SOA должно стать логичным продолжением управления ИТ. Ныне существующее управление ИТ включает в себя распределение обязанностей и ответственности, определенные процессы и политики. Все это применимо и к SOA, стирающей границы между отделами.

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

Процесс управления

Итак, как же свести ошибки к минимуму? Как грамотно построить процесс управления и заставить его работать на SOA?

Дуг Гибсон, возглавляющий комитет по вопросам SOA в компании Oracle Asia-Pacific, видит решение проблемы в том, чтобы с самого начала строить процесс управления по модели, наиболее удобной и оптимальной для осуществления SOA-проекта.

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

Управление включает в себя руководство целым рядом структур, задействованных в осуществлении проекта, и предполагает выработку генеральной линии поведения компании. Но Дэн Тернез, технический директор компании Asia-Pacific for TIBCO Software, считает, что нужно, прежде всего, сосредоточиться на процессах, позволяющих контролировать разработку приложений, и на операциях, способных обеспечить многократное использование сервисов. Иначе существует вероятность, что вы потратите больше денег, чем потратили бы на привычное вам традиционное создание приложений и их развертывание.

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

По данным аналитической компании Oracle’s Gibson, концепция SOA должна охватывать несколько важных сфер, таких как управление сервисами на протяжении всего их жизненного цикла, политики по использованию сервисов, контроль за выполнением контрактов или соглашений, заключенных между поставщиками сервисов и конечными пользователями, а также классификация окружающих систем и приложений, содержащих метаданные. SOA поможет вам оптимизировать работу этих сфер. Джордж Вонг настоятельно рекомендует также постараться спрогнозировать, насколько и каким образом окупится внедрение SOA. Это также поможет в деле организации управления. Однако, как отмечает Майк Роадз, это довольно непростая задача.

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

Как повлиять на решение пользователей

Главное в деле внедрения новых политик – не переусердствовать в разъяснениях, дабы не запутать клиентов-потребителей сервисов окончательно и не вызвать в них чувство отторжения идеи SOA. Руководителям проектов следует об этом помнить, поскольку, как утверждают эксперты, потребители сервисов – это основное звено, в котором окупаются любые попытки вовлечения всех структур бизнеса в SOA-проект. Как отмечает Иво Тотев, руководство компаний и пользователей можно расположить к себе, предложив им не грандиозную и малопонятную идею масштабного SOA-проекта, а несколько небольших сервисов, обладающих высоким уровнем внутрикорпоративной прозрачности и предназначенных для решения конкретных бизнес-задач.

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

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

Очень часто в деле управления и проведения политик помогает создание центрального реестра сервисов, где производители и поставщики сервисов могли бы рекламировать свою продукцию, а конечные пользователи, соответственно, могли бы найти сервисы, которые им нужны, а также технические сведения, необходимые для доступа к ним. По данным аналитической компании Oracle’s Gibson, в связи с тем, что SOA – проекты приобретают все большую популярность, наблюдается рост предложения сервисов и, следовательно, возникает все большая необходимость в объединенном каталоге сервисов.

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

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

Однако Дэн Тернез опасается, что подобные меры породят еще больше путаницы и отвлекут внимание компаний от тех ценных преимуществ, которые может дать им использование SOA.

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

По материалам Computerworld Singapore

Комментарии