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

По мере того как технологии и практика применения SOA всё активнее демонстрируют свою полезность для бизнеса и привлекают всё более пристальное внимание ИТ-директоров и руководителей компаний, расширяется и число ИТ-специалистов, которым только предстоит ступить “на территорию SOA”. По данным AMR Research, только за прошлый год масштабы применения SOA увеличились на 100%. Аналитическая компания Gartner считает, что к 2010 г. свыше 80% крупных новых систем будет строиться по крайней мере на частичном использовании SOA.

Организациям с распределенной и динамической ИТ-инфраструктурой SOA сулит особые преимущества.

“Мы используем SOA, чтобы производить необходимые изменения, ничего при этом не разрушая”, — констатирует старший аналитик и управляющий партнер компании ZapThink Рональд Шмелзер.

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

“Иногда люди, слышавшие о SOA и понимающие в самом общем виде, что это нечто важное, начинают думать примерно так: “Ладно, придется этим заняться. Запланируем на будущий год”. Они втягиваются в процесс реализации SOA и обнаруживают, что в отрасли существуют совершенно различные ее трактовки. После чего у них возникает вопрос: а что же такое SOA в нашем конкретном случае? — рассуждает Хеффнер. — Требуется время, чтобы освоиться с этой архитектурой”.

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

1. Помните, что это архитектура.

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

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

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

2. Не путайте SOA с Web-сервисами.

Этот тезис следует из пункта 1. Сейчас многие организации, похоже, придерживаются ошибочного мнения, будто сервисно-ориентированная архитектура напрямую связана с Web-сервисами. А в действительности, как считает Шмелзер, SOA имеет отношение к любым видам сервисов, существующим на предприятии. Организации, допускающие подобную ошибку, лишают сервисно-ориентированную архитектуру таких важных качеств, как масштабируемость, гибкость и охват предприятия в целом.

“За деревьями иногда не видят леса. Запомните: вы вполне можете реализовать сервисно-ориентированную архитектуру, не используя Web-сервисы. Более того, собрав в одном месте все Web-сервисы, вы не построите сервисно-ориентированную архитектуру, — добавил он. — Это все равно, что свалить доски в кучу и назвать ее домом”.

3. На первом месте функции, а не продукты.

Как Шмелзер, так и Хеффнер настойчиво подчеркивают, что один из самых простых способов развеять ваши связанные с SOA надежды заключается в том, чтобы начать проектирование не с того конца.

“Люди, переворачивающие всё с ног на голову, рассуждают так: “Ах, мне нужна SOA. Поэтому позвольте мне приобрести решение корпорации EMC. А затем разрешите прикинуть, какие необходимо создать сервисы. После этого дайте мне возможность выяснить, какая потребуется архитектура”, — иронизирует Шмелзер. — Прежде чем приступать к созданию сервисов, подумайте, как они будут использоваться. Ведь их можно построить сотней различных способов”.

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

4. Не пытайтесь сделать сервисно-ориентированным всё подряд.

Не каждое корпоративное приложение подходит для сервисно-ориентированной архитектуры, так что не стремитесь внедрять ее повсеместно, рекомендует Шмелзер.

“Если вы применяете SOA там, где ничего не меняется, то вы без каких-либо веских оснований вносите в систему вариативность, попутно снижая ее эффективность”, — считает он.

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

“Задайтесь вопросом, будет ли данный процесс когда-нибудь меняться. А если его придется корректировать, то в какую сумму вам это обойдется и насколько усложнит систему, — предлагает Шмелзер. — Если ответ положительный, то здесь возможна сервисная ориентация”.

5. SOA следует развивать поэтапно.

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

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

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

“Сосредоточьте внимание на том, что вам непосредственно требуется для создания решений на базе SOA, которые вы собираетесь воплотить в жизнь в ближайшем будущем, — рекомендует Хеффнер. — Если вы не выполните краткосрочные планы, то долгосрочных просто не будет, потому что вы не получите необходимых средств”.

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

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

“Чтобы оптимальным образом сбалансировать ближайшие и отдаленные задачи, рассматривайте текущие технические требования в контексте долговременных целей создания платформы SOA, — настаивает Хеффнер. — Кроме того, попытайтесь найти нечто, что вы можете сделать и оплатить в рамках текущего проекта. Помните, что мало кому удается единовременно получать крупные суммы на развитие инфраструктуры и тратить их в свое удовольствие на приобретении самых разных новых продуктов, необходимых для платформы SOA”.

7. С самого начала обеспечьте безопасность архитектуры.

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

“Если у вас имеется набор сервисов и каждому сотруднику разрешено создать любой сервис, а потом кто угодно имеет возможность связать эти сервисы между собой, значит, дела могут пойти совершенно непредсказуемым образом”, — предупреждает Шмелзер.

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

“Они рассуждают так: “Вообще-то мне не нужны средства администрирования, поскольку я собираюсь создать лишь один-два сервиса, которые будут использоваться только в данной конкретной среде, а поэтому обойдемся без них”, — говорит Шмелзер. — Подобное оправдание имеет смысл только в случае, если вы не планируете использовать эти сервисы для решения реальных задач. А если так, то зачем вам вообще за них браться? Коль применяться они не будут, то нечего их и создавать”.

Чтобы избежать хаоса, утверждает он, следует с самого начала уделять внимание вопросам администрирования и безопасности.

“Если администрирование налажено, это является гарантией того, что люди не будут создавать несовместимые или избыточные сервисы, — считает Шмелзер. — Но еще важнее, что они не станут объединять сервисы, которые не должны объединяться, поскольку это запрещается политикой компании. Или когда включение сервиса в некую промышленную КИС резко увеличивает нагрузку и она начинает превышать возможности инфраструктуры. Администрирование играет в таких случаях роль полицейского”.

8. Учтите, что SOA еще будет меняться.

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

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

9. Подталкивайте производителей к более выгодным моделям инвестирования.

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

“Я бы побуждал вендоров к тому, чтобы модели инвестирования в платформу SOA и управления бизнесом на этой платформе в большей степени согласовывались между собой. — советует он. — Вы можете поставить производителя перед фактом: «В краткосрочной перспективе я надеюсь получить такие-то преимущества для своего бизнеса. Мне нужна такая модель инвестирования, при которой затраты не будут превышать отдачу от них, иначе я не смогу ничего у вас купить»”.

10. Найдите вендора, готового стать вашим партнером.

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

“Заявите им: “Мы надолго связываем себя с вашим продуктом, но сегодня он нам нужен только в такой вполне определенной конфигурации. Сейчас мы заплатим за него столько-то. По мере наращивания масштабов использования мы заплатим столько-то, а когда наша система охватит предприятие целиком, то столько-то”, — советует Хеффнер. — Договоритесь обо всем этом заранее, чтобы вендор мог видеть перспективу. И тогда он действительно будет заботиться о достижении ожидаемых вами результатов, чтобы вы впоследствии заключали с ним сделки, необходимые для расширения системы. Всё зависит от того, насколько творчески вы подойдете к переговорам и насколько верно оцените уступчивость производителя”.