В разделе подкастов на ebizQ появилось интересное интервью Michael Stamback, в котором он делится своими взглядами на SOA вообще и на SOA Governance в частности. Интервью доступно в виде аудиозаписи и расшифрованного текста. Вводные фразы и рекламу Oracle мы опустили, а некоторые интересные фрагменты предлагаем вашему вниманию в переводе на русский.

Вначале SOA Governance в основном фокусировалось на UDDI Registry и на том, как с их помощью можно делать то, что называется «управлением во время разработки» (Design-Time Governance). От него откололось то, что называется управлением во время исполнения (Runtime Governance), и есть вендоры, которые до сих пор об этом говорят.

Но потом направление, в котором стали развиваться registry, привело к необходимости repository, а затем захотелось иметь возможность абстрагировать бизнес-политики в нечто, что бы могло исполняться в среде исполнения. Эволюция всего этого пространства была очень интересной.

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

Сегодня область технологии SOA Governance разбивается на четыре разные категории: управление активами, управление потреблением, управление политиками, и еще операционные или времени исполнения мониторинг и управление. И с моей точки зрения, один из важнейших, если не самый важный аспект, необходимый для программы SOA Governance – это управление активами.

Потому что одна из выгод SOA – это гибкость (agility), дающая бизнесу приложения, быстро собираемые из готовых к употреблению сервисов. Но вы не достигнете повторного использования, если вы не видите что у вас есть готового к использованию. И, продолжая эту мысль, вы не можете управлять тем, чего не видите.

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

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

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

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

У вас также может быть набор SLA которые по существу задают гарантированную производительность или пропускную способность, которую вы обеспечиваете данному потребителю данного сервиса. И это последний кусочек SOA – мониторинг и управление.

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

В случае Oracle, мы предлагаем решение SOA Governance, удовлетворяющее всем этим различным критериями. В области управления активами у нас есть Oracle Enterprise Repository и Oracle Service Registry. Они пришли вместе с приобретением BEA, а до BEA они были известны как Flashline.

В области управления политиками и управление потребителями, связанный с потреблением процесс реализован в рамках workflow, встроенного в наш Oracle Enterprise Repository. А управление политиками обеспечивается через продукт Oracle Web Services Manager. И в области мониторинга и управления SOA мы предоставляем пакет SOA management, обеспечивающий видимость показателей времени исполнения.

Но самый большой риск – считать, что продукт или технология governance, которые вы приобрели, решит проблемы governance. Я говорил с множеством заказчиков, которые купили registry, например, девять месяцев назад и сейчас у них в нем девять сервисов.

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

=АБ

Комментарии