И снова о SOA

Так что же такое SOA. Сервисно-ориентированная архитектура. Вроде бы очень говорящее словосочетание. Но большинство копий в обсуждениях на ITBlogs поломались, по моему, о слово архитектура (не то, чтобы слово архитектура встречалось часто, но смысл баталий именно вокруг этого).

Что имеется ввиду? Я вижу 2 варианта и они очень разные.

• Архитектура как подход к проектированию системы
• Архитектура как подход технической реализации.

С точки зрения SOA как технической реализации, система проектируется как раньше, и реализуется как набор отдельных компонентов (они же сервисы). В данном случае, как мне кажется, SOA – это buzzword. Раньше это называлось модулями и интеграцией отдельных систем. Т.е. и раньше можно было взять системы разных производителей (если это было оправдано) и интегрировать их у себя. Система при этом не становится наборной, она остается единой, но собранной из отдельных модулей. Сейчас такие системы называют SOA. Почему? Просто потому что модный термин?

С точки зрения SOA как подхода к проектированию, получается наборная, постоянно модифицирующаяся, система – т.е. выявляется проблема, для ее решения делается сервис, выявляется другая проблема, для ее решения еще сервис. Сервисы друг для друга – черные ящики. Это очень облегчает проектирование системы. Тут самое сложное заложить основу взаимодействия сервисов. Механизмы взаимодействия сервисов хорошо описал Влад Боркус (плюс к посту есть не менее ценные комментарии).

Подобный подход в проектировании системы удобен

• Для сервисов, рассчитанных на конечного пользователя, когда каждый следующий сервис решает еще одну проблему пользователя и интегрирован с предыдущими сервисами. В основном это web сервисы, но могут быть и desktop приложения, дополняющие друг друга.
• Для небольших мобильных компаний, сфера деятельности которых позволяет быстро подстраиваться под изменяющуюся ситуацию. Таким компаниям не нужны крупные ERP, им нужны сервисы, которые можно быстро ввести в строй и начать использовать и так же быстро от них отказаться. Эти компании, в первую очередь, сам же IT сектор, а далее практически весь непроизводственный бизнес (услуги, торговля). Но, в любом случае остается ограничение по размеру компании (по количеству людей). Каким бы простым сервис ни был нужно время на обучение сотрудников, а с внедрением, растянутым на длительное время, теряются вышеописанные плюсы.

Есть ситуации, на мой взгляд, когда подобный подход к архитектуре категорически вреден. Это системы крупных корпораций со сложными, запутанными взаимосвязями. В этом случае, конечно, проще делать сервисы под отдельные части бизнеса, но правильнее делать единую систему. Это сложнее. Для этого придется распутать весь клубок бизнес процессов и утрясти все нестыковки. Но без этого вообще не имеет смысла браться за систему т.к. оставшийся бардак в бизнес процессах не даст выигрыша бизнесу. Кардинально отличающийся взгляд на эту проблему здесь, у Даниила Фейгина.