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

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

Руководитель ИТ-службы Федерального агентства по страхованию депозитов (Federal Deposit Insurance, FDIC) Майк Бартелл знал, что ему поручен проект, который или вознесет его вверх, или положит конец его карьере. Речь шла об изменении способов контроля федерального правительства над денежными операциями между банками США, мониторинга финансовой отчетности и сбора статистики, характеризующей уровень соблюдения требований нормативных актов. Все это должно было способствовать оздоровлению денежной системы США.

Все три участвовавших в этом проекте агентства — FDIC, Совет федеральной резервной системы (Federal Reserve Board) и Управление контролера денежного обращения (Office of the Comptroller of the Currency) — имели в своем распоряжении целый ряд систем для управления различными процессами. На протяжении нескольких лет эти системы стыковались друг с другом, превратившись в конечном итоге в невероятно жесткую структуру. Задача заключалась в том, чтобы перестроить существующие системы и получить значительно более гибкую совокупность согласованных друг с другом повторно используемых компонентов в рамках сервис-ориентированной архитектуры (Service-oriented architecture, SOA). Проект, реализация которого началась в 2003 году и продолжается по сей день, весьма сложен с технической точки зрения и представляет такую ценность для бизнеса, что уже был отмечен целым рядом премий. Не обошла его стороной и премия CIO 100.

Однако амбиции всегда сопряжены с риском. Возможности повышения с помощью SOA эффективности разработки программного обеспечения и гибкости бизнес-процессов так и останутся нереализованными, если вы не научитесь грамотно управлять архитектурой ПО, а также процессами его проектирования и развертывания на основе передового опыта, накопленного представителями отрасли ИТ. «Организацию управления мы с самого начала считали одной из основных задач», — пояснил Бартелл. Для налаживания сотрудничества и эффективной координации своих действий три агентства — при посредничестве Федерального совета по проверке финансовых институтов (Federal Financial Institutions Examination Council, FFIEC) — оформили письменные договоренности о принятии единого набора управляющих компонентов. Под соглашением поставили свои подписи руководители всех трех агентств. «Документ, регламентирующий процедуру управления, во многом помог нам достаточно быстро выработать общую позицию при принятии ключевых решений, а также определить бизнес-функции и конечные цели проекта», — добавил Бартелл.

Ставки при организации управления SOA оказываются гораздо выше по сравнению с традиционной разработкой программного обеспечения, потому что SOA привязывает разработку непосредственно к бизнес-операциям. В рамках SOA программные компоненты являются отражением конкретных функций бизнеса (например, задач «проверки кредитоспособности» или «поиска клиентских записей»), которые могут смешиваться с бизнес-процессами и потоками работ. Хорошее управление SOA предполагает тщательное продумывание всех возможных последствий подобного взаимодействия с последующим определением процедуры управления компонентами. В эпоху SOA плохо управляемая архитектура программного обеспечения в конечном итоге трансформируется в плохо управляемый бизнес. «Управлению в SOA придается такое большое значение, потому что нам приходится систематизировать бизнес-службы, — заметила президент консультационной компании Hurwitz & Associates Джудит Хервиц. — Речь идет о преобразованиях как в сфере бизнеса, так и в области информационных технологий». Руководители ИТ-служб, которые рассчитывают добиться успеха с SOA, должны согласовать план управления еще до того, как разработчики представят первый сервис. Ведь сервисы эти будут играть критически важную роль в определении курса дальнейшего развития наиболее значимых бизнес-процессов компании. Отсутствие четких перспектив порождает дополнительные сложности и мешает добиваться той гибкости и оперативности, которая сегодня отличает бизнес-процессы, поддерживаемые современными информационными технологиями.

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

Управление начинается с процесса

Большинство усилий, направленных на построение SOA, начинаются с формирования одного и того же подхода к управлению: для того, чтобы добиться понимания ключевых бизнес-процессов, создания сервисов, обеспечивающих их выполнение, и грамотного использования базовой архитектуры, создается объединенная группа, в состав которой входят представители основных подразделений и ИТ-службы. Все пять лауреатов премии CIO 100 — FFIEC, Hygeia, ING Group, KnowledgeBase Marketing и MoneyGram International — с самого начала исповедовали именно такой подход к управлению. В ходе реализации проекта, который и принес организации FFIEC звание лауреата этой премии, ее представители развернули ряд сервисов, занимающихся приемкой и осуществлением управления квартальными финансовыми отчетами — так называемыми «отчетами о финансовом состоянии и доходах» — всех институтов FDIC. Данная информация изучалась и анализировалась тремя агентствами FFIEC, у каждого из которых имелись собственные системы, реализующие различные бизнес-процессы и использующие разные стандарты представления данных. В процессе совместной деятельности эти агентства определили общие бизнес-процессы, в том числе и связанные с управлением информацией о финансовых отчетах. На базе этих сервисов агентства построили комплексные совместно используемые приложения, что помогло сократить сроки устранения дублирования ресурсов, конфликтов приложений и ошибок при проведении анализа. Формирование централизованной комиссии по надзору за архитектурой помогло создать условия для обеспечения соответствия всех новых и перестраиваемых приложений SOA.

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

Выяснилось, к примеру, что около 70% прикладных компонентов, обрабатывающих ипотечную информацию для европейских клиентов, допускают совместное использование. Это помогло компании сэкономить 20 млн. долл. на будущих разработках. (Другие компоненты приложений имели специфические особенности в зависимости от конкретной страны, но интеграция в рамках SOA позволила обеспечить их взаимодействие с общими сервисами.)

Управление SOA не ограничивается только вопросами эффективности и повторного использования. Это еще и мощное средство улучшения бизнес-процессов. При создании системы обработки платежей исполнительный вице-президент и руководитель ИТ-службы компании MoneyGram Дэвид Олбрайт сформировал наблюдательный совет по архитектуре, который рассматривал процессы, выступавшие в качестве кандидатов на вхождение в SOA. Когда в различных сегментах компании группа находила несколько вариантов важного процесса, из них выбирался наилучший, который и реализовывался в виде сервиса Таким образом, в выигрыше оказывалась вся компания. Первый компонент MoneyGram на базе SOA представлял собой повторно используемый сервис, который инициировал перевод платежей. Сервис был интегрирован с проектом AgentConnect (отмеченным впоследствии премией CIO 100), который предоставлял независимым агентам возможность использовать различные платежные сервисы, управляемые платежным механизмом MoneyGram. Осуществлялось это с помощью набора модульных приложений, упростивших процедуру развертывания и интеграции с системами кассовых терминалов агентов.

Репозитарий: ярмарка для сервисов

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

Род Хэмилтон, руководитель ИТ-службы компании Hygeia, предлагающей посреднические услуги в области здравоохранения, недолго думая, решил воспользоваться технологиями wiki (wiki — многопользовательская система, позволяющая нескольким посетителям сайта, обладающим правом доступа, — а иногда правом доступа обладают все посетители сайта, — редактировать контент) и организовал выпуск редактируемого электронного бюллетеня, который должен помочь разработчикам и бизнес-аналитикам следить за доступными им услугами. (Компания была отмечена премией CIO 100 за усилия по созданию стандартных, повторно используемых сервисов для ключевых бизнес-процессов — аутентификации пользователей, обеспечения прохождения документов и управления потоками работ.) Каждый wiki-ресурс содержит информацию об одном или нескольких сервисах. Специалисты по ИТ и сотрудники бизнес-подразделений легко могут обратиться к интересующей их информации и внести в нее свои коррективы, при этом все изменения автоматически протоколируются. Подобный не слишком элегантный подход напоминает создание баз данных при помощи Excel, прибегнуть же к нему пришлось вследствие малочисленности организации — на тот момент количество сотрудников ИТ-службы не превышало 15 человек. Хэмилтон понимает, что репозитарий рано или поздно ему понадобится. Ведь в компании разрабатывается все больше и больше общих сервисов, обеспечивающих реализацию стандартных бизнес-процессов. С их помощью будет осуществляться управление различными формами клиентских транзакций, а также формирование специальных сервисов, помогающих удовлетворить уникальные потребности клиентов.

Все лауреаты премии CIO 100 уделяли самое серьезное внимание строгости архитектуры и процесса разработки: «Для успешного развития SOA до 80% усилий должно быть направлено на изменение способов управления жизненным циклом процесса разработки приложений», — отметил научный директор компании AMR Research по вопросам управления ИТ и SOA Дэннис Гоэн.

Управление данными и безопасность

Еще один ключевой вопрос управления SOA связан с манипулированием данными. Очень важно сформировать и поддер-живать внутри организации стандартную среду обмена данными, с тем чтобы данные использовались так, как положено. Целостность и согласованность данных имеют большое значение для компании KnowledgeBase Marketing, поскольку ее бизнес связан с управлением, объединением, фильтрацией и классификацией клиентских списков. В компании имеется целый ряд систем управления данными, каждая из которых выполняет одни и те же базовые функции — очистку данных, управление списками, сравнение потребителей и анализ данных — присущим только ей образом. Это не позволяет организации эффективно объединять и анализировать маркетинговую информацию, поступающую из различных источников, для удовлетворения конкретных потребностей клиентов. При реализации проекта, которому была присуждена премия CIO 100, специалисты KnowledgeBase заменили множество систем очистки данных единой базовой службой, которая поставлялась с помощью SOA. Сегодня каждое бизнес-подразделение использует один и тот же сервис очистки для всех клиентских данных, что гарантирует получение согласованных результатов. «А сервисная ориентация означает, что, по мере разработки компанией других функций очистки, управления, сравнения и анализа, всем клиентам (которые в общем случае могут поддерживать отношения более чем с одним бизнес-подразделением) будет поставляться согласованная информация», — сообщил старший вице-президент KnowledgeBase Marketing по инфраструктуре Брайан Кемп.

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

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

Эволюционный подход

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

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

Аналогичной точки зрения придерживаются и в лагере KnowledgeBase. «При добавлении новых сервисов следует более глубоко продумывать вопросы управления», — подчеркнул Кемп.

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

GALEN GRUMAN. Services In Sync. CIO MAGAZINE. AUGUST 15, 2006

Основные принципы управления SOA

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

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

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

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

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

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

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