Апологеты сервисно-ориентированной архитектуры (Service-Oriented Architecture, SOA) заслуживают медали за то, что отстояли ее оригинальность в ходе самых длительных в истории техники атак. Едва были отбиты попытки представить SOA как всего лишь несколько подновленную идею модульного программирования, популярного в 1970-е гг., как пришлось доказывать, что она не сводится к упаковке метаданных в контейнеры XML для последующей передачи по протоколу SOAP (Simple Object Access Protocol).
Как только ее не называли! А преисполненные восторгов публикации грозили окончательно похоронить идею SOA. Тем не менее концепция компьютерных сервисов, которые компонуются вместе и предоставляются пользователю в виде бизнес-стратегии, выжила по очень простой причине: эта идея имеет смысл. Почему бы вместо того, чтобы рассматривать каждое направление бизнеса в качестве площадки для длительной разработки приложения, не воспользоваться тем, что у вас уже имеется и что предлагают другие? Соберите приложение из фрагментов (при этом не важно, какое оборудование есть у компании) и занимайтесь непосредственно бизнесом.
Ниже перечисляются пять шагов, которые необходимо предпринять, чтобы любая компания, большая или маленькая, могла воспользоваться SOA.
1. Управление (governance). Виртуализированные аппаратные системы нуждаются в мощных инструментах управления, позволяющих предотвратить скатывание к компьютерному хаосу. Нечто подобное можно сказать и о сервисах. Поэтому я бы рекомендовал всем компаниям, планирующим широко применять SOA, начинать с организации управления.
Приложения, созданные на основе внутренних и внешних сервисов, будут порождать колоссальный объем данных, к которым нужно организовать доступ, над которыми надо производить действия и которыми следует обмениваться. Если ваши приложения слабо связаны, это не значит, будто они должны плохо контролироваться.
2. Безопасность. Если вы создаете бизнес-процесс, в котором используются конфиденциальные сведения о клиентах, то вы отвечаете за сохранность этих данных. Когда в данном процессе используются ресурсы, находящиеся за пределами вашей компании, вы должны быть абсолютно уверены в надежности принятых мер безопасности и в правильном распределении ответственности.
3. Бизнес-процесс. С годами разработчики приложений начинают понимать, что к несчастью для них условия проведения бизнес-операций отнюдь не являются четко заданными раз и навсегда. Приложение, которое вы тщательно моделировали три года назад, оказывается очень далеким от сегодняшней практики бизнеса. Следующий этап в развитии сервисно-ориентированных архитектур — это создание сервисов, способных действовать и трансформироваться в реальном времени, чтобы отражать истинный характер бизнес-операций.
Аналитики из компании Gartner и некоторые другие пытаются ввести для обозначения этого нового поколения сервисов термин “SOA 2.0”. Хоть я и избегаю обозначать что бы то ни было цифрами 2.0, нужно, конечно, найти какой-то способ охарактеризовать сервисы, которые развиваются вместе с бизнесом.
4. Определение экономического эффекта SOA. Концепция SOA имеет смысл с разных точек зрения. Вы можете повторно использовать фрагменты оплачиваемых или арендуемых вами сервисов вместо того, чтобы создавать все с нуля. Вы можете подсчитать, сколько вы сейчас платите за разработку бизнес-приложений, и задаться вопросом, почему из этих приложений нельзя извлечь больше пользы.
Почему бы не использовать эти сервисы многократно внутри компании для создания новых приложений? А может быть, стоит сдать эти сервисы в аренду внешним заказчикам? Довольно трудно определить экономический эффект с учетом полного жизненного цикла приложения. Но такие подсчеты способствовали бы распространению SOA.
5. Изучайте язык бизнеса. Технические специалисты по сервисно-ориентированным архитектурам говорят на одном языке, а руководители бизнес-подразделений используют язык бизнеса и не имеют (да и не должны иметь) представления о таких концепциях, как BPEL, SOA, SOAP или композитные приложения. Они видят, что экономические индикаторы свидетельствуют о скором окончании нынешнего спада, и хотят, чтобы их компания была готова к возобновлению бизнеса.
Если вы собираетесь внедрять SOA в своей компании, вам необходимо изучить язык бизнеса. Попробуйте провести посвященную преимуществам сервисно-ориентированных архитектур презентацию от начала до конца, ни разу не воспользовавшись аббревиатурой SOA. Любыми способами избегайте обсуждения подробностей технических стандартов. Вместо этого постарайтесь понять ту сферу бизнеса, в которой вы трудитесь, и объяснить, как вы можете при помощи SOA заставить компанию работать быстрее, более разумно и с меньшими издержками.
