Wednesday, December 06, 2006

И снова о SOA

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

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

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

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

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

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

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

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


3 comments:

Sergey Rozovik said...

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

Sergey Rozovik said...

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

Elena Makurochkina said...

To Sergey Rozovik
"есть тысячи COM компонент, но ни один из них не повернется язык назвать сервисом"
Имелся ввиду не только COM. COM это совсем уж внутренняя реализация.
Довольно часто при проектировании системы становится видно что отдельные куски бизнес процессов можно накрыть уже существующими системами. Это было раньше, это делается и сейчас. Просто сейчас это тоже стали называть SOA. Поэтому я и говорю что с этой точки зрения SOA – buzzword.
"В крупных корпорациях обычно работают десятки систем. каждая из которых "накрывает" свой бизнес процесс или группу процессов."... "небольшие интеграционные усилия, направленные на увязку систем в контексте глобальных бизнес процессов компании, позволяют получить быстрый и зримый эффект."
Тут вопрос как делается увязка. Если просто взять и подлатать дыры это, конечно, даст эффект, но не будет прогресса. Если в компании используются разные системы, это значит (в подавляющем большинстве случаев), что проектировались и внедрялись они независимо друг от друга и дублирование и несогласованность данных там наличествует не только на технологическом уровне системы, но и на уровне бизнес процессов. Для того чтобы был прогресс перед тем как латать дыры надо разобраться с взаимосвязями и процессами работы компании сейчас и понять направление в котором надо развиваться далее. После такого разбора увязка текущих систем воспринимается как временная мера.
Здесь уже есть довольно подробно мое мнение по поводу корпоративной ипостаси SOA.