Computerworld, США
Последняя архитектурная революция, потрясшая мир ИТ, связана с сервисно-ориентированной архитектурой (SOA). С одной стороны, менеджеры по ИТ с энтузиазмом воспринимают ее возможности, но с другой — не скрывают своих опасений по поводу этой новой идеологии и того влияния, которое она может оказать на работу компании. Ниже описаны четыре простых шага, сделав которые можно перейти к SOA, избежав потрясений и излишних сложностей
Очень немногие подразделения, занимающиеся информационными технологиями, имеют монолитную внутреннюю организацию. Компании используют множество разнообразных технологий и систем для поддержки сложных бизнес-операций. Например, могут использовать PeopleSoft для финансовых операций, пакетные приложения — для прогнозирования и планирования, создавать специализированные приложения для продаж и закупок, а также поддерживать несколько унаследованных систем для управления информацией о клиентах.
При столь большом количестве применяемых систем, интеграция становится воистину монументальной задачей.
Попросите десятерых руководителей отделов ИТ назвать самую серьезную проблему, с которой им приходилось сталкиваться, и девять из них, скорее всего, назовут интеграцию.
Интеграция гетерогенных систем, которые изначально не были предназначены для работы друг с другом, — очень дорогостоящий и сложный процесс.
Цель сервисно-ориентированной архитектуры — поддержка интеграции. Этого можно добиться за счет проектирования архитектуры, способной интегрировать разнородные, гетерогенные приложения с минимальной избыточностью и максимальной гибкостью.
Полностью разработанная и реализованная SOA позволит снизить расходы на ИТ и принести существенную пользу бизнесу, поскольку она дает возможность поддерживать гибкость, повторное использование и общекорпоративную интеграцию.
Определение SOA
Если вы реализуете сервисно-ориентированную архитектуру, то в первую очередь следует помнить, что в подразделении ИТ вашей организации должны четко понимать, что это такое.
Спросите у пяти специалистов по информационным технологиям, что именно называют сервисно-ориентированной архитектурой, и скорее всего, вы услышите пять разных ответов. Это происходит потому, что такие архитектуры очень быстро развиваются.
В отрасли ИТ сегодня не существует единого, общепринятого определения SOA, и в этом нет ничего страшного. Но крайне важно, чтобы все специалисты подразделения ИТ точно знали, что именно понимают под SOA в вашей организации.
Я рекомендую изучить соответствующую литературу по SOA и выработать определение, которое актуально для вашей организации. Кроме того, целесообразно проконсультироваться с экспертами по той предметной области, в которой вы работаете, чтобы определить архитектуру с учетом уникальных требований вашей компании.
SOA обладает достаточной гибкостью для того, чтобы ее можно было использовать при решении самых разных задач, возникающих в процессе интеграции.
Самое главное — ваша компания должна иметь свое собственное определение сервисно-ориентированной архитектуры. Каждый сотрудник отдела ИТ должен понимать это определение, полностью поддерживать новую парадигму и использовать все необходимые ресурсы для того, чтобы воплотить ее в жизнь.
Обучение персонала
Для многих компаний реализация SOA означает отказ от традиционных архитектур, основанных на тесно взаимосвязанных интерфейсах приложений. Как следствие, такой переход может потребовать активного и серьезного изучения концепции SOA. Упростить этот процесс могут соответствующие теоретические и практические занятия.
Я рекомендую подход к обучению по принципу «сверху — вниз».
В первую очередь необходимо ознакомить высшее руководство компании с фундаментальными принципами SOA и теми преимуществами, которые дает ее реализация.
Это крайне важно. Если директор информационной службы не способен понять базовые методологии и цели этой архитектуры, тогда он не сможет ее поддерживать.
Как только вы проинформировали высшее руководство, следует заняться обучением менеджеров более низких уровней. Они должны не только понять общие цели и философию SOA, но и на практике изучить детали сервисно-ориентированной архитектуры и выяснить, как она будет реализовываться.
Наконец, предоставьте своим сотрудникам возможность изучить детали создания и внедрения SOA.
Такое многоуровневое обучение требует освещения конкретных технологий, необходимых для поддержания перехода компании на сервисно-ориентированную архитектуру. Все это предполагает тщательное и длительное обучение.
Помните о том, что на первом этапе обучение может не дать убедительных результатов. Концепции SOA многим специалистам по ИТ, привыкшим к другим архитектурным моделям, могут показаться чужеродными.
Осознать новую парадигму зачастую непросто. Восприятие мира большинством людей ограничено определенными рамками. Когда новая теория не укладывается в эти рамки, она вызывает у людей отторжение, поскольку не совсем согласуется с тем, во что они верят.
Переход к новой парадигме требует убежденности руководства в правильности выбранного решения и серьезного процесса обучения. Не стоит впадать в уныние. Сотрудников можно научить, чему я сам был свидетелем. Придерживайтесь своей цели, и вы обязательно увидите результаты.
Создание управляющего комитета
Конечная цель SOA — формирование гибкой архитектуры, в которой могли бы быть интегрированы разнородные, гетерогенные приложения с помощью общего интерфейса.
Добиться этого можно за счет проектирования и разработки не зависящих от приложений сервисов, к которым можно обращаться и которыми можно обмениваться в пределах всей организации.
Только управляющий комитет способен гарантировать достижение общекорпоративных целей при разделении приложений и создании повторно используемых сервисов. Некоторые теоретики и практики называют такой комитет центром компетенции по вопросам интеграции (Integration Competency Center, ICC).
При создании ICC необходимо обратить внимание на ряд основных моментов. В комитете должны быть представлены все подразделения организации, как специалисты по бизнесу, так и профессионалы, занимающиеся информационными технологиями.
Помните, что требуется преодолеть изолированность систем и повысить уровень повторного использования активов, которыми располагает предприятие.
Этого можно добиться только при адекватном представительстве всех корпоративных подразделений, то есть формировании системы «сдержек и противовесов».
Выбирайте в комитет самых лучших и ярких сотрудников, и убедитесь, что они обладают необходимыми знаниями и являются активными сторонниками SOA.
Скорее всего, это будут очень занятые люди, поэтому не допускайте, чтобы работа в комитете стала для них «дополнением к другим служебным обязанностям». Высшее руководство компании должно понимать важность участия всех членов в работе комитета и быть готовым к тому, что придется перераспределить рабочую нагрузку так, чтобы эта деятельность стала приоритетной.
Думайте о большом, начинайте с малого
Последнее и самое важное: не стоит с самого начала слишком усердствовать при реализации SOA. Процесс внедрения может оказаться достаточно длительным.
История свидетельствует, что в сфере информационных технологий подход «большого взрыва» редко себя оправдывает.
Небольшие постепенные изменения сулят больше шансов на успех, поскольку они более управляемы.
К счастью, инкрементальный подход как нельзя лучше подходит для реализации SOA, поскольку эта архитектура позволяет компании реализовывать по одному сервису за один раз.
Для начала выберите относительно небольшую функцию, которая предполагает незначительный риск, но при этом достаточно важна для компании.
Возможно, лучше всего начать с извлечения из множества систем клиентской информации и ее консолидации.
Создайте сервис для реализации этой функциональности, который необходим для поддержки всей организации в целом (например, больше чем для одного приложения).
Затем начинайте удалять эту функциональность из различных систем, которые используют взаимнооднозначный интерфейс (точка — точка), и переориентируйте их на новый, разделяемый сервис.
Такой подход позволит организации опробовать новую методику и, в случае необходимости, изменить ее прежде, чем приступать к реализации масштабных сервисов вроде модернизации финансовых приложений, с тем, чтобы в этих приложениях использовался единый интерфейс. Кроме того, это позволит судить о готовности компании к реализации SOA и использованию ее в качестве новой архитектурной модели.
Что такое SOA? Вспомните eBay
Чтобы лучше разобраться в том, что такое сервисно-ориентированная архитектура, обратимся, например, к eBay. Тысячи людей ежедневно посещают сайт интерактивного аукциона компании eBay, рассчитывая заключить выгодные сделки на товары, предлагаемые энергичными продавцами. По-существу, eBay действует как посредник, предоставляя интегрированную службу, которая связывает покупателей и продавцов с помощью единого интерфейса.
Причин столь значительного успеха eBay несколько. Во-первых, этим сайтом удобно пользоваться. Не нужно много времени и сил на то, чтобы открыть счет для покупки и продажи. Во-вторых, это место, где могут работать как продавцы, так и покупатели. К примеру, покупатель может изучить предложения по самым разным продуктам в одном месте. В-третьих, это очень гибкий механизм. Покупатель может действовать как продавец, не открывая для этого множество разных счетов. В-четвертых, eBay предлагает все виды сервисов, изолируя покупателей и продавцов от того, что происходит за кулисами.
Если вы разобрались в этих базовых механизмах eBay, вы прекрасно разберетесь и в том, как работает сервисно-ориентированная архитектура.
Воспринимайте приложения, имеющиеся в вашей компании, как покупателей и продавцов на eBay. Одни приложения предоставляют информацию (продавцы), а другие выступают в роли ее потребителя (покупатели). Эти роли могут меняться в зависимости от контекста транзакции. Одно приложение-потребитель может столь же легко быть поставщиком для другого приложения-потребителя.
Обеспечивать работоспособность всей этой конструкции должен единый, опирающийся на стандарты, интерфейс (аналогичный Web-сайту компании eBay), с помощью которого все приложения, и потребители, и поставщики, обращаются к брокеру транзакций. Они взаимодействуют посредством передачи сообщений, поддерживаемых повторно используемыми сервисами внутри единого интерфейса, а не с помощью жестко привязанного программного обеспечения, поддерживающего двусторонние взаимосвязи.
Каким бы примитивным ни показалось вам это описание, но по сути именно так функционирует сервисно-ориентированная архитектура.