Зачем мне SOA?

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

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

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

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

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