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

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

В 2002 году, когда компания TrueCredit, входящая в состав агентства контроля за кредитами TransUnion, приступила к развертыванию корпоративного портала, понятие сервисно-ориентированной архитектуры еще не было таким популярным как сегодня. Директор ИТ-службы TrueCredit Скотт Метцгер ставил перед собой достаточно простые цели: определить бизнес-процессы и функции ИТ, которые должны поддерживаться порталом, и выделить повторно используемые компоненты, позволяющие ускорить разработку и уменьшить ее стоимость.

Однако вскоре Метцгер понял, что открывается прекрасная возможность для составления схемы наиболее важных бизнес-процессов компании и создания архитектуры, обеспечивающей упрощение разработки и модификации приложений, которые будут поддерживать эти процессы в соответствии с изменением потребностей бизнеса. «Назовите это SOA или как-то еще, но для меня лично сдвиг в сознании, который произошел с началом проектирования портала, стал поворотным этапом в развитии связей между ИТ и бизнесом, — вспоминает Метцгер. — Сегодня у нас с бизнесом установились гораздо более тесные отношения. Это отличный способ унификации организации». Совместный опрос, проведенный в марте редакциями журналов CIO и Computerworld, показал, что в 77% компаний одна из основных целей внедрения SOA заключается в повышении гибкости ведения бизнеса.

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

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

Ориентация на процессы, а не на какую-то конкретную технологию — вот что позволяет SOA на практике обеспечивать согласованность между ИТ и бизнесом. Но вместе с тем перед директором ИТ-службы возникают и новые вопросы, связанные с возможностями ИТ в хронически отстающих областях: в сфере управления процессами и архитектурном планировании. Аналогичное давление испытывают и все его подчиненные. Короче говоря, руководители ИТ-служб, рассчитывающие внедрить SOA так, как они привыкли внедрять другие технологии, рискуют остаться ни с чем.

Задача 1: Внедряйте постепенно, но держите в голове долгосрочный план

При внедрении SOA на получение конечного результата уходят годы. Вот почему респонденты опроса, проведенного редакцией журналов CIO и Computerworld, назвали переход на SOA и удовлетворение текущих потребностей бизнеса главной своей задачей (63%).

«Хитрость здесь заключается в том, чтобы не развертывать архитектуру SOA целиком сразу, поскольку к тому времени, как большая часть предварительных работ будет выполнена, потребности бизнеса могут измениться, и внедренные системы устареют», — пояснила Роджерс. Создавать архитектуру и внедрять конкретные службы следует поэтапно, сосредоточившись на какой-то одной прикладной области или выбирая проект в зависимости от того, насколько срочно он нужен бизнесу. «Архитектуру можно выстраивать постепенно», — считает технический директор муниципалитета округа Колумбия Сюзанна Пек. В 1999 году в рамках подготовки к построению новой SOA Пек приступила к объединению 370 унаследованных систем в девять функциональных групп. Группы включали как новый код, так и интерфейсы к унаследованному коду на основе Web-сервисов, а также новые составные приложения.

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

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

«Готовьтесь к тому, что на анализ бизнес-процессов и архитектуры у вас уйдет примерно год, — предупреждает Метцгер. — Но дополнительные временные затраты впоследствии окупятся сторицей». Сегодня цикл разработки новых служб в компании TrueCredit укладывается в шесть недель. В муниципалитете округа Колумбия на внедрение сервисов уходит в среднем порядка 12 недель (на развертывание более сложных сервисов приходится тратить от четырех до шести месяцев).

Задача 2: Серьезно подойдите к управлению

Поскольку SOA ориентирована в первую очередь на создание и управление ИТ-процедурами, поддерживающими бизнес-процессы, вопросам управления отводится здесь критически важная роль. «Поставщики ПО всегда занимались созданием приложений, но сейчас таковые составляют часть единого сборочного процесса, — отметил научный директор компании AMR Research по управлению ИТ Дэннис Гоэн. — Причем проектирование должно осуществляться стандартным образом, а это раздражает разработчиков». «SOA в значительной степени отбирает нити управления у индивидуальных разработчиков, поэтому вы рискуете встретить серьезное сопротивление», — подчеркнул директор ИТ-службы компании Sony Pictures Entertainment Джон Стаббс. Усилия Sony Pictures, направленные на формирование SOA, привели к созданию общей службы управления лицензированием прав на показ фильмов и телевизионных программ, используемой представителями сразу нескольких направлений бизнеса, в том числе подразделениями продаж DVD и организации театральных спектаклей, объединяющих в общей сложности 39 подразделений (в том числе юридическую и маркетинговую службы). Сейчас ИТ-группа применяет архитектуру SOA для развертывания общих Web-сервисов, связанных с выполнением процессов SAP Financials, в частности, с управлением дебиторской задолженностью.

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

Задача 3: Переосмыслите свое отношение к персоналу

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

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

Задача 4: Применяйте принципы SOA к вашим данным

«Зачастую на начальном этапе проектирования SOA недостаточно внимания уделяется представлению данных (а не только функциональности приложений) в виде сервисов. В рамках SOA множество сервисов, связанных с массой приложений, можно объединять для эффективной реализации бизнес-процессов. Если каждый из сервисов обращается к разным источникам данных или использует одни и те же источники, но разными способами, результаты, вполне возможно, окажутся далеки от ожидаемых.

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

Итоговое вознаграждение: Реальная согласованность между бизнесом и ИТ

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

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

Galen Gruman. SOA?s True Challenge - It Ain?t Technology. CIO Magazine. May 1, 2006

Фундамент технологии SOA

Сервисно-ориентированная архитектура (service-oriented architecture, SOA) не ограничивается исключительно рамками технологий, однако последние могут помочь в развертывании SOA. «Сегодня потребителям доступна масса хороших продуктов, но в целом, рынок только начинает входить в период зрелости», — отметил старший аналитик компании ZapThenk Рон Шмельцер. Вот почему работа систем, поддерживающих SOA, сейчас во многом зависит от команды, которая хорошо знает, какие имеющиеся службы могут быть использованы в новом проекте. Тем не менее, существует целый ряд развивающихся технологий, которые призваны упростить процедуру внедрения архитектуры SOA.

  1. Корпоративная сервисная шина (enterprise service bus, ESB). Разновидность сервера приложений или платформы EAI. Шина ESB отвечает за организацию связей между сервисами, а также обеспечивает взаимодействие с пользователем и источниками данных. «В современном мире SOA в значительной степени ориентирована на сообщения», — поясняет Сандра Роджерс, программный директор по вопросам SOA, Web-сервисов и интеграции компании IDC. На некоторых крупных предприятиях соответствующие системы будут разворачиваться независимо от других, большинству же придется обновлять свои средства автоматизации, чтобы они соответствовали существующим стандартам, а компания имела возможность выйти за рамки обычной передачи данных и интеграции приложений.
  2. Реестр или хранилище служб. Система, построенная на основе базы данных, следит за наличием сервисных компонентов, допускающих повторное использование, и предоставляет информацию о доступных службах бизнес-аналитикам и внешним партнерам. «Доступ к реестру нашей системы, к примеру, можно получить через Web, — сообщает менеджер по архитектуре Sprint Business Services Виджей Мусувати. — Это упрощает использование необходимых сервисов». В отличие от традиционной базы данных в реестре должен храниться контекст сервиса, в котором посредством метаданных определяется, когда и каким образом эту службу следует использовать.
  3. Главные системы управления данными и репозитарии метаданных. Эти категории продуктов помогают компаниям перейти к распределенному и смешанному управлению данными. Такая же схема управления будет применяться при организации управления бизнес-логикой через сервис SOA. Так гарантируется одинаковая интерпретация данных всеми использующими их службами и исключается возможность появления неверного представления, которое способно разрушить результаты, выдаваемые сервисами в процессе обработки или генерации информации.
  4. Управление пользовательским интерфейсом. «Через несколько лет все основные разработки будут связаны с пользовательским интерфейсом, — считает Роджерс. — По мере увеличения числа сервисов, используемых повсеместно, начиная от Web-порталов и заканчивая офисными инструментальными средствами, фактически все программные компоненты превращаются в поставщика или потребителя таких сервисов. А управление объединяющим пользовательским интерфейсом потребует применения сервисно-ориентированного подхода. Развитие технологии asynchronous Java and XML (Ajax) — важное, но не единственное условие для широкого распространения SOA».