Что же все-таки такое SOA?!
Прочитал замечательный тред "SOА – это круто! Но не очень понятно…", инициированный Андреем Колесовым. На самом деле давно уже и самому неймется вставить свои 2c на эту тему ;)
Я уже писал, что SOA в отличие от ESB, EAI, etc. изначально предполагает, что S=Service в SOA не только и не столько технологический, сколько бизнес-сервис. Самодостаточность, заменяемость и/или повторная используемость технологического сервиса, лишь вытекает бизнес-сервиса. Именно бизнес-сервис первичен. Таким образом, в SOA стоит выделить первый уровень - бизнес-архитектуры. Поэтому, так часто в контексте SOA мы говорим о BPM, явно или неявно подразумевая новую реинкарнацию концепции реинжиниринга бизнес-процессов, введенной в обиход Маклом Хаммером и Джемсом Чампи в начале 90-х и качественно повлиявшего на культуру управления и организационую структуру многих компаний и организаций (см. перевод их книги на русский язык"Реинжиниринг корпорации. Манифест революции в бизнесе.").
EDA (Event-driven architecture), ESB, BPEL определяют правила игры на уровне прикладной архитектуры, обеспечивая заменяемость и повторную используемость служб (читай, приложений и систем, обладающих соответствующими well-defined интерфейсами и их поведением, задаваемым BPEL). Наличие ESB не говорит о наличии SOA. Об этом, например, пишет Стив Джонс из CapGemini и один из участников авторского коллектива OASIS SOA Reference Model , чью новую книгу "Enterprise SOA Adoption Strategies. Using SOA to deliver IT to the businesss" крайне рекомендую для прочтения (благо в электронном виде она находится в свободном доступе).
Ну а использование WebServices, того или иного варианта MoM (Sun, IBM, MS, Tibco, Systinet, etc) или других асинхронных технологий - вопрос уровня технологической архитектуры.
Проблема "идентификации" SOA (так ярко), как мне кажется, связана с попыткой обсуждения архитектуры сразу на нескольких уровнях и в отрыве от бизнес-процессов.
А вот к вопросу, почему о SOA часто говорят как чуть ли не о панацее согласования бизнеса и ИТ, я позволю себе привести цитату (стр.109 указанной выше книги) от авторов концепции реинжиниринга бизнес-процессов: "Большинство компаний совершают одну принципиальную ошибку в отношении технологий: они рассмативают их через призму существующих процессов. Компании спрашивают: "Как эти новые технологические возможности могут улучшить и оптимизировать текущую работу?" Но вместо этого они должны спрашивать: "Что новое могут позволить нам делать технологии?" В отличие от автоматизации суть реинжиниринга - в новаторстве, в использовании новейших технологических возможностей для достижения совершенно новых целей. Один из самых сложных элементов реинжиниринга - умение найти новые, незакомые возможности технологии."
В большой степени, SOA можно и даже необходимо рассматривать как инструмент, направленный на обеспечение реинжиниринга. Обратите внимание, что существует даже такое понятие как SOA Governance, являющемся продолжением IT Governance и составной частью корпоративного руководства (Corporate Governance). В процессе реализации SOA, среди стейкхолдеров всегда есть представители бизнес-доменов/LoB (Line of Business), вплоть до прописывания их в соответствующих RACI chart.
Именно контекст бизнеса, бизнес-архитектура и является принципиальным аспектом SOA, отличающим SOA от той или иной архитектуры итеграции. Более того, SOA - архитектурный стиль, одной из принципиальных черт которого является отражение реальных бизнес-процессов, как это определяет The Open Group.
Забывая о первичности бизнес-процессов, мы просто теряем контекст и, соответственно, новизну. А в остальном - ну, действительно, совершено ничего нового ;-)
Я уже писал, что SOA в отличие от ESB, EAI, etc. изначально предполагает, что S=Service в SOA не только и не столько технологический, сколько бизнес-сервис. Самодостаточность, заменяемость и/или повторная используемость технологического сервиса, лишь вытекает бизнес-сервиса. Именно бизнес-сервис первичен. Таким образом, в SOA стоит выделить первый уровень - бизнес-архитектуры. Поэтому, так часто в контексте SOA мы говорим о BPM, явно или неявно подразумевая новую реинкарнацию концепции реинжиниринга бизнес-процессов, введенной в обиход Маклом Хаммером и Джемсом Чампи в начале 90-х и качественно повлиявшего на культуру управления и организационую структуру многих компаний и организаций (см. перевод их книги на русский язык"Реинжиниринг корпорации. Манифест революции в бизнесе.").
EDA (Event-driven architecture), ESB, BPEL определяют правила игры на уровне прикладной архитектуры, обеспечивая заменяемость и повторную используемость служб (читай, приложений и систем, обладающих соответствующими well-defined интерфейсами и их поведением, задаваемым BPEL). Наличие ESB не говорит о наличии SOA. Об этом, например, пишет Стив Джонс из CapGemini и один из участников авторского коллектива OASIS SOA Reference Model , чью новую книгу "Enterprise SOA Adoption Strategies. Using SOA to deliver IT to the businesss" крайне рекомендую для прочтения (благо в электронном виде она находится в свободном доступе).
Ну а использование WebServices, того или иного варианта MoM (Sun, IBM, MS, Tibco, Systinet, etc) или других асинхронных технологий - вопрос уровня технологической архитектуры.
Проблема "идентификации" SOA (так ярко), как мне кажется, связана с попыткой обсуждения архитектуры сразу на нескольких уровнях и в отрыве от бизнес-процессов.
А вот к вопросу, почему о SOA часто говорят как чуть ли не о панацее согласования бизнеса и ИТ, я позволю себе привести цитату (стр.109 указанной выше книги) от авторов концепции реинжиниринга бизнес-процессов: "Большинство компаний совершают одну принципиальную ошибку в отношении технологий: они рассмативают их через призму существующих процессов. Компании спрашивают: "Как эти новые технологические возможности могут улучшить и оптимизировать текущую работу?" Но вместо этого они должны спрашивать: "Что новое могут позволить нам делать технологии?" В отличие от автоматизации суть реинжиниринга - в новаторстве, в использовании новейших технологических возможностей для достижения совершенно новых целей. Один из самых сложных элементов реинжиниринга - умение найти новые, незакомые возможности технологии."
В большой степени, SOA можно и даже необходимо рассматривать как инструмент, направленный на обеспечение реинжиниринга. Обратите внимание, что существует даже такое понятие как SOA Governance, являющемся продолжением IT Governance и составной частью корпоративного руководства (Corporate Governance). В процессе реализации SOA, среди стейкхолдеров всегда есть представители бизнес-доменов/LoB (Line of Business), вплоть до прописывания их в соответствующих RACI chart.
Именно контекст бизнеса, бизнес-архитектура и является принципиальным аспектом SOA, отличающим SOA от той или иной архитектуры итеграции. Более того, SOA - архитектурный стиль, одной из принципиальных черт которого является отражение реальных бизнес-процессов, как это определяет The Open Group.
Забывая о первичности бизнес-процессов, мы просто теряем контекст и, соответственно, новизну. А в остальном - ну, действительно, совершено ничего нового ;-)
Ярлыки: Business-IT Alignment, Enterprise Architecture, SOA
Автор: Сергей Орлик в
20.11.06
Комментарии: 0
