суббота, Декабрь 02, 2006
SOA и бизнес
Предметное обсуждение SOA началось и по-русски. Сколько ни пишут журналы на эту тему, дискуссии никак не получается. И только с появлением ITBlogs.ru наметилась радующая тенденция.
Внести ясность, которой пока так не хватает в обсуждении этой темы, попытался Влад Боркус. Как он правильно заметил, большая часть рассуждений на ITBlogs (и не только), так или иначе связанных с SOA, фокусировалась на Web-сервисах. С этим мнением я согласен, но добавлю, что "фундаметальный изъян" выходит за обозначенные рамки. Одно то, что мы только и придумываем, как сущности какие согласовать, да в какие системы их таквоткнуть внедрить, чтобы целостность была гарантирована и т. п., уводит нас немного в сторону от предмета обсуждения (хотя способы и даже стандарты протоколов синхронизации состояния бизнес-процессов и соответствующих систем существуют). Чтобы к дискуссии о возможном техническом оснащении SOA подойти с общим ее пониманием, целесообразно рассмотреть сервисную ориентацию несколько шире.
Много раньше я порассуждал о разнице в моделировании объектов и сервисов, столкнувшись с несовершенством моделей программирования сервисов на самых популярных платформах. С их подходом действительно можно быстро наладить базовый Web-сервисный RPC, особенно не задумываясь об архитектуре целого решения, корректности интерфейсов, да и о сервисной ориентации вообще. IMHO это крайне странный подход, если осуществляется в рамках SOA, поскольку потребность в SOA возникает совершенно с других позиций, и первые шаги должны быть осуществлены именно в сфере проектирования.
Необходимо определиться с принципами выделения сервисов, с их функциональными границами, максимально привязывая их к границам соответствующих бизнес-единиц. Я предпочитаю думать о провайдере сервиса не как о системе (CRM, ERP и т.п.), а как о соответствующей этому сервису бизнес-единице (произвольно малой или большой). Именно она предоставляет сервис, потенциально реализованный при помощи некой системы или совокупности систем.
Делая провайдером не систему, а бизнес, задача согласования информационной архитектуры выводится на тот уровень, на котором она теоретически решаема -- на уровень бизнеса. Мы уже говорили о том, что семантика идентичных сущностей в разных системах то и дело оказывается несогласуемой и, как следствие, информационное взаимодействие затрудняется. Согласование семантики сущностей, как и бизнес-процессов в целом, является делом бизнеса, а не IT, и ошибка, соответственно никак не в технологиях. <update>SOA позволяет корректно вернуть эту задачу бизнесу и получить результат, допускающий техническую реализацию. Сервисная ориентация способствует конструктивному участию IT в оптимизации бизнес-процессов и получении результата, допускающего техническую реализацию.</update> Сервис (в этом контексте его еще называют "бизнес-сервис") является той самой промежуточной конструкцией соответствия (alignment'а) бизнеса и IT.
Во всей этой истории он играет роль интерфейса бизнес-процесса, упрятанного в "черный ящик" соответствующей бизнес-единицы. "Посветив фонариком" внутрь этого ящика, можно увидеть там продолжение SOA, но это вовсе не обязательно. IMHO ценность SOA увеличивается при движении вверх от меньшего к большему (от цеха к заводу, от филиала к банку и т. п.). Оптимальная архитектура более нижнего уровня зависит от наследия и прочих условий конкретного бизнеса. Подход "черного ящика" позволяет (но не обязывает) делегировать принятие решений на тот уровень, на котором они с большей вероятностью будут оптимальны. Возможность такого рода делегирования основана на применения контрактов сервисов с параллельным разграничением соответствующих зон ответственности.
Примечательно, что характер информационных обменов на более высоких уровнях может принципиально отличаться от обменов на более низких уровнях. Так наверху взаимодействия все больше односторонние, несущие информацию о бизнес-событии (заказ, поставка и т.п.). Такие сообщения влияют на состояния активных бизнес-процессов и инициируют новые, потенциально координирующие комплексную реакцию разных организационных единиц. Эти события порождают другие сообщения, спускающиеся на более низкие уровни архитектуры, в конечном счете достигая учетные системы в виде вызовов типа запрос-ответ.
Такой двойственный характер информационного обмена в SOA служит постоянным источником противоречий, устранить которые можно только установив границы, помимо функциональных, между асинхронными бизнес-взаимодействиями верхних уровней и преимущественно синхронными сопутствующими IT-взаимодействиями более низких уровней. Лишь на самом низком уровне SOA мы приходим к т. н. "мелкозернистым" (fine-grained) сервисам, которые через RPC-вызовы включаются в бизнес-процессы для хранения и передачи состояния между ними (т.е. для осуществления учетной функции). Основная же область рассмотрения SOA лежит выше.
Внести ясность, которой пока так не хватает в обсуждении этой темы, попытался Влад Боркус. Как он правильно заметил, большая часть рассуждений на ITBlogs (и не только), так или иначе связанных с SOA, фокусировалась на Web-сервисах. С этим мнением я согласен, но добавлю, что "фундаметальный изъян" выходит за обозначенные рамки. Одно то, что мы только и придумываем, как сущности какие согласовать, да в какие системы их так
Много раньше я порассуждал о разнице в моделировании объектов и сервисов, столкнувшись с несовершенством моделей программирования сервисов на самых популярных платформах. С их подходом действительно можно быстро наладить базовый Web-сервисный RPC, особенно не задумываясь об архитектуре целого решения, корректности интерфейсов, да и о сервисной ориентации вообще. IMHO это крайне странный подход, если осуществляется в рамках SOA, поскольку потребность в SOA возникает совершенно с других позиций, и первые шаги должны быть осуществлены именно в сфере проектирования.
Необходимо определиться с принципами выделения сервисов, с их функциональными границами, максимально привязывая их к границам соответствующих бизнес-единиц. Я предпочитаю думать о провайдере сервиса не как о системе (CRM, ERP и т.п.), а как о соответствующей этому сервису бизнес-единице (произвольно малой или большой). Именно она предоставляет сервис, потенциально реализованный при помощи некой системы или совокупности систем.
Делая провайдером не систему, а бизнес, задача согласования информационной архитектуры выводится на тот уровень, на котором она теоретически решаема -- на уровень бизнеса. Мы уже говорили о том, что семантика идентичных сущностей в разных системах то и дело оказывается несогласуемой и, как следствие, информационное взаимодействие затрудняется. Согласование семантики сущностей, как и бизнес-процессов в целом, является делом бизнеса, а не IT, и ошибка, соответственно никак не в технологиях. <update>
Во всей этой истории он играет роль интерфейса бизнес-процесса, упрятанного в "черный ящик" соответствующей бизнес-единицы. "Посветив фонариком" внутрь этого ящика, можно увидеть там продолжение SOA, но это вовсе не обязательно. IMHO ценность SOA увеличивается при движении вверх от меньшего к большему (от цеха к заводу, от филиала к банку и т. п.). Оптимальная архитектура более нижнего уровня зависит от наследия и прочих условий конкретного бизнеса. Подход "черного ящика" позволяет (но не обязывает) делегировать принятие решений на тот уровень, на котором они с большей вероятностью будут оптимальны. Возможность такого рода делегирования основана на применения контрактов сервисов с параллельным разграничением соответствующих зон ответственности.
Примечательно, что характер информационных обменов на более высоких уровнях может принципиально отличаться от обменов на более низких уровнях. Так наверху взаимодействия все больше односторонние, несущие информацию о бизнес-событии (заказ, поставка и т.п.). Такие сообщения влияют на состояния активных бизнес-процессов и инициируют новые, потенциально координирующие комплексную реакцию разных организационных единиц. Эти события порождают другие сообщения, спускающиеся на более низкие уровни архитектуры, в конечном счете достигая учетные системы в виде вызовов типа запрос-ответ.
Такой двойственный характер информационного обмена в SOA служит постоянным источником противоречий, устранить которые можно только установив границы, помимо функциональных, между асинхронными бизнес-взаимодействиями верхних уровней и преимущественно синхронными сопутствующими IT-взаимодействиями более низких уровней. Лишь на самом низком уровне SOA мы приходим к т. н. "мелкозернистым" (fine-grained) сервисам, которые через RPC-вызовы включаются в бизнес-процессы для хранения и передачи состояния между ними (т.е. для осуществления учетной функции). Основная же область рассмотрения SOA лежит выше.
technorati tags: soa
Комментарии:
Ссылки на это сообщение:
<< Главная страница
Какая основная функция IT отдела или стороннего интегратора или консультанта? На мой взгляд – это обход всех отделов и заинтересованных лиц (а иногда и незаинтересованных), сбор информации кому-что надо, утрясание всех нестыкующихся требований (а они всегда не стыкуются). Иногда в процессе выяснения всего этого происходит смена бизнес процессов. Сама система, ее архитектура, все это выбирается на основе выясненных требований. Т.е. система, а тем более реализация, немного "вторичны".
Что же предлагается сейчас? Чтобы всем этим занимался бизнес? "Согласование семантики сущностей, как и бизнес-процессов в целом, является делом бизнеса, а не IT, и ошибка, соответственно никак не в технологиях. SOA позволяет корректно вернуть эту задачу бизнесу и получить результат, допускающий техническую реализацию."
Кого конкретно в бизнесе планируется привлекать? Кто должен принести IT-кам на блюдечке с голубой каемочкой все то, что раньше было основной ответственностью IT?
Никто не говорит что бизнес не должен участвовать в построении системы, но IT отдел является в этом главным, и насколько хорошо он умеет разбираться в бизнес процессах настолько хороша будет система.
Сейчас IT отрасль старается все больше привлекать заказчика и перекладывать на заказчика ответственность. Должны быть границы этого привлечения. Заказчик не может собираться на Agile летучки полным составом Chief officer-ов. Точно так же как не может предоставить сам все схемы утрясенных и непротиворечивых взаимосвязей частей своего бизнеса.
SOA – интересный подход, но он имеет очень много ограничений. Причем проблемы реализации сильно второстепенны. Основное - заказчик должен быть очень хорошо технически подготовлен. Причем не какое то конкретное лицо, а все начальники всех отделов. Второе – у заказчика должен быть единый центр принятия решения, т.е. фактически отдел, дублирующий функции IT отдела (в его старом понимании) по стандартизации процессов. Третье – все участвующие в процессе должны быть очень заинтересованы в конечном результате.
На мой взгляд, SOA подходит для автоматизации IT-ми себя же, а так же для разработки конечнопользовательских сервисов и линеек приложений (где, фактически, IT компания выступает в качестве заказчика для себя же). Возможно еще автоматизация небольших компаний, держащихся на одном явном лидере, который знает все и вся внутри своей компании. В крупных компаниях подобный подход неплодотворен, imho, т.к. людям на местах не выгодна полная интеграция и открытость, т.к. за ними следуют контроль, которого все стараются избежать. А, кроме того, далеко не у всех ответственных хватит навыков в подробном построении взаимосвязей своего отдела с окружающими. Эти люди должны выступать в роли технологов, а не в роли архитекторов и аналитиков.
Что же предлагается сейчас? Чтобы всем этим занимался бизнес? "Согласование семантики сущностей, как и бизнес-процессов в целом, является делом бизнеса, а не IT, и ошибка, соответственно никак не в технологиях. SOA позволяет корректно вернуть эту задачу бизнесу и получить результат, допускающий техническую реализацию."
Кого конкретно в бизнесе планируется привлекать? Кто должен принести IT-кам на блюдечке с голубой каемочкой все то, что раньше было основной ответственностью IT?
Никто не говорит что бизнес не должен участвовать в построении системы, но IT отдел является в этом главным, и насколько хорошо он умеет разбираться в бизнес процессах настолько хороша будет система.
Сейчас IT отрасль старается все больше привлекать заказчика и перекладывать на заказчика ответственность. Должны быть границы этого привлечения. Заказчик не может собираться на Agile летучки полным составом Chief officer-ов. Точно так же как не может предоставить сам все схемы утрясенных и непротиворечивых взаимосвязей частей своего бизнеса.
SOA – интересный подход, но он имеет очень много ограничений. Причем проблемы реализации сильно второстепенны. Основное - заказчик должен быть очень хорошо технически подготовлен. Причем не какое то конкретное лицо, а все начальники всех отделов. Второе – у заказчика должен быть единый центр принятия решения, т.е. фактически отдел, дублирующий функции IT отдела (в его старом понимании) по стандартизации процессов. Третье – все участвующие в процессе должны быть очень заинтересованы в конечном результате.
На мой взгляд, SOA подходит для автоматизации IT-ми себя же, а так же для разработки конечнопользовательских сервисов и линеек приложений (где, фактически, IT компания выступает в качестве заказчика для себя же). Возможно еще автоматизация небольших компаний, держащихся на одном явном лидере, который знает все и вся внутри своей компании. В крупных компаниях подобный подход неплодотворен, imho, т.к. людям на местах не выгодна полная интеграция и открытость, т.к. за ними следуют контроль, которого все стараются избежать. А, кроме того, далеко не у всех ответственных хватит навыков в подробном построении взаимосвязей своего отдела с окружающими. Эти люди должны выступать в роли технологов, а не в роли архитекторов и аналитиков.
" SOA позволяет корректно вернуть эту задачу бизнесу и получить результат, допускающий техническую реализацию"
Сказано!
Т.е. опять решается вопрос как сказать бизнесу: "сам дурак". Мол, вот когда сделаете нам бизнес, который будет удобен для автоматизации - тогда мы этим и займемся.
Не, с таким настроением ты слона не продашь
(с) бизнесмен
Докладываю, что у бизнеса отнюдь нет потребности, чтобы ему вернули задачу, корректно или нет. И в таком ключе с ним конструктивного диалога не получится. И, если суть SOA в этом - то это мертвое движение, ибо оно начинается с в корне неверной с точки зрения потребителя (бизнеса) посылки: "Ты, де, для начала себя в порядок приведи". Слышали. Знаем. Не работает.
Сказано!
Т.е. опять решается вопрос как сказать бизнесу: "сам дурак". Мол, вот когда сделаете нам бизнес, который будет удобен для автоматизации - тогда мы этим и займемся.
Не, с таким настроением ты слона не продашь
(с) бизнесмен
Докладываю, что у бизнеса отнюдь нет потребности, чтобы ему вернули задачу, корректно или нет. И в таком ключе с ним конструктивного диалога не получится. И, если суть SOA в этом - то это мертвое движение, ибо оно начинается с в корне неверной с точки зрения потребителя (бизнеса) посылки: "Ты, де, для начала себя в порядок приведи". Слышали. Знаем. Не работает.
Перефразирую "SOA позволяет корректно вернуть эту задачу бизнесу...":
Сервисная ориентация способствует конструктивному участию IT в оптимизации бизнес-процессов и в получении результата, допускающего техническую реализацию.
Сервисная ориентация способствует конструктивному участию IT в оптимизации бизнес-процессов и в получении результата, допускающего техническую реализацию.
:-)
А что, она, эта ориентация, раньше деструктивной была? Хотя, пожалуй, временами и была. К тому же ничего конструктивного в предложении: "вернуть задачу бизнесу на доработку" не вижу. Да и нового тоже. Это уже многократно пройденый этап, зачем повторять его на новом уровне?
А что, она, эта ориентация, раньше деструктивной была? Хотя, пожалуй, временами и была. К тому же ничего конструктивного в предложении: "вернуть задачу бизнесу на доработку" не вижу. Да и нового тоже. Это уже многократно пройденый этап, зачем повторять его на новом уровне?
Изначальный текст был немного грубоват. Поясню: я не хотел сказать, что SOA позволяет продолжить выяснять "кто дурак". Совсем наоборот, добавление сервисного слоя (в концептуальном, а не чисто технологическом смысле) способствует пониманию между IT и бизнесом, так как сближает понятийную базу обеих сторон. В некоторой степени преодолевается разрыв, существующий между языком бизнес-процессов и языком информационных систем, и заполняется этот гэп понятием бизнес-сервиса.
На этом фоне не совсем ясно, на каком основании сделан вывод о том, что "заказчик должен быть очень хорошо технически подготовлен". Что касается перекладывания на него ответственности IT, это тоже IMHO не совсем так. Пол беды, когда хаос только в IT -- с этим еще IT может бороться. Хуже, если хаос в бизнес-процессах, потому что в этом случае IT может только помогать бизнесу наводить порядок. Опять же, сервисная ориентация может быть применима в отдельных случаях (не будучи панацеей).
На этом фоне не совсем ясно, на каком основании сделан вывод о том, что "заказчик должен быть очень хорошо технически подготовлен". Что касается перекладывания на него ответственности IT, это тоже IMHO не совсем так. Пол беды, когда хаос только в IT -- с этим еще IT может бороться. Хуже, если хаос в бизнес-процессах, потому что в этом случае IT может только помогать бизнесу наводить порядок. Опять же, сервисная ориентация может быть применима в отдельных случаях (не будучи панацеей).
Даниил, дело в крупных компаниях, которые живут не 5-10 лет при одном руководителе (когда руководитель хотя бы примерно представляет как все работает), а 100 с лишним лет и не единожды сменяли не только руководство, но и условия "окружающей среды". В таких компаниях никто не знает как работает все. Есть отдельные люди, которые представляют как работает их конкретный, очень маленький, кусочек. Причем никто уже и не помнит почему здесь делалось так, а не иначе. Просто делалось и все (как в истории Tolik-а про обезьян). И когда IT компания приходит автоматизировать такую фирму ее основная функция – вытащить из всех знания по крупицам и собрать их воедино.
В крупных компаниях "бизнес" - это не одно лицо, а очень много разных людей с разными интересами, причем эти интересы противоречат друг другу. Это основная проблема почему бизнес не может сам внутри себя выработать структуру хотя бы текущих бизнес процессов (ведь где-то что-то идет за нал, где-то кто-то упрощает себе жизнь игнорируя предписания сверху, а где то предписаний нет и никогда не было, и в одном конце страны работают так, а в другом совсем иначе, и каждый считает что он прав т.к. делает это уже 10 лет и все работает). IT компания (или отдел) в данном случае являются независимыми и могут вытащить все эти взаимосвязи и противоречия и поставить эти вопросы перед конкретными людьми, чтобы они выбрали единственно правильное решение.
И последнее – почему заказчик должен быть очень хорошо технически подготовлен. Потому что, чтобы разобраться во всем этом надо уметь строить модели собирая информацию по кусочкам. Надо уметь или строить UseCase-ы или владеть BPWin-ом. Просто в голове такой объем данных никто унести не может.
Я считаю что UML и, в основном, диаграммы UseCase-ов это революция в проектировании. После их появления проектирование стало превращаться из искусства в ремесло, т.е. не зная предметной области, но зная как правильно строить UseCase-ы можно обойти всех ответственных за отдельные направления и получить проект системы.
Причем, кстати, то, что получится с помощью UseCase-ов будет фактически сервисно-ориентировано!
Но сами ответственные не знают UseCase-ов, у них нет механизма, с помощью которого они построят все бизнес процессы. У них вообще нет навыков построения бизнес-процессов. Они просто пришли на свое место и работают так, как работали их предшественники.
В крупных компаниях "бизнес" - это не одно лицо, а очень много разных людей с разными интересами, причем эти интересы противоречат друг другу. Это основная проблема почему бизнес не может сам внутри себя выработать структуру хотя бы текущих бизнес процессов (ведь где-то что-то идет за нал, где-то кто-то упрощает себе жизнь игнорируя предписания сверху, а где то предписаний нет и никогда не было, и в одном конце страны работают так, а в другом совсем иначе, и каждый считает что он прав т.к. делает это уже 10 лет и все работает). IT компания (или отдел) в данном случае являются независимыми и могут вытащить все эти взаимосвязи и противоречия и поставить эти вопросы перед конкретными людьми, чтобы они выбрали единственно правильное решение.
И последнее – почему заказчик должен быть очень хорошо технически подготовлен. Потому что, чтобы разобраться во всем этом надо уметь строить модели собирая информацию по кусочкам. Надо уметь или строить UseCase-ы или владеть BPWin-ом. Просто в голове такой объем данных никто унести не может.
Я считаю что UML и, в основном, диаграммы UseCase-ов это революция в проектировании. После их появления проектирование стало превращаться из искусства в ремесло, т.е. не зная предметной области, но зная как правильно строить UseCase-ы можно обойти всех ответственных за отдельные направления и получить проект системы.
Причем, кстати, то, что получится с помощью UseCase-ов будет фактически сервисно-ориентировано!
Но сами ответственные не знают UseCase-ов, у них нет механизма, с помощью которого они построят все бизнес процессы. У них вообще нет навыков построения бизнес-процессов. Они просто пришли на свое место и работают так, как работали их предшественники.
Складывается впечатление, что мы говорим о разных вещах. Use case -- механизм кодификации функциональных требований к системе, ее поведению. Сервис -- механизм реализации принципа separation of concerns, ничего не говорящий о внутреннем устройстве скрывающегося за ним бизнес-процесса. Как следствие, принципы сервисной ориентации распространяются в первую очередь на сферу взаимодействия, и крупные компании, тем более имеющие многолетнюю историю, и являются наиболее вероятными адептами SOA. Для них ответ на вопрос "как?" в масштабе всей организации получить проблематично. SOA позволяет заменить этот вопрос на "что?", а на "как?" отвечать по отдельности в более узких рамках, разделенных интерфейсами. При этом, как ни крути, IT самостоятельно не может ответить ни на тот, ни на другой вопрос.
Несомненно, когда «ответ на вопрос "как?" в масштабе всей организации получить проблематично», гораздо проще реализовывать систему кусочками. Я то, как раз, с этим не спорю. Это гораздо удобнее и дешевле. Но это не дает преимущества для бизнеса. Какую задачу ставит перед собой IT отдел или сторонняя компания начиная разработку и внедрение IT системы? Просто текущие процессы и взаимосвязи положить на новую IT систему? Сейчас все крупные компании уже давным давно автоматизированы, и если уж внедрять новую систему, то ее нужно делать лучше, а значит, оптимизировать бизнес процессы. А это значит, что надо размотать клубок текущих взаимосвязей.
На верно, мы на эту проблему с разных точек зрения смотрим. С точки зрения дешевизны, простоты и скорости внедрения наборные системы несомненно выигрывают. Но с точки зрения долгоиграющей выгоды для крупного бизнеса они, скорее, вредны, т.к. не заставляют его совершенствоваться, а консервируют, а со временем, и размножают проблемы и нестыковки.
На верно, мы на эту проблему с разных точек зрения смотрим. С точки зрения дешевизны, простоты и скорости внедрения наборные системы несомненно выигрывают. Но с точки зрения долгоиграющей выгоды для крупного бизнеса они, скорее, вредны, т.к. не заставляют его совершенствоваться, а консервируют, а со временем, и размножают проблемы и нестыковки.
А UseCase-ы всплыли т.к., imho, на текущий момент это самый удобный механизм по распутыванию клубков взимосвязей. Когда мы видим кто и что хочет от системы мы можем решать как ее реализовывать.
Т.е. мы сначала выясняем ответ на вопрос "что?", а на основе полученной информации решаем "как?". Причем для того что-бы это увидеть хватает довольно малой детализации.
Если нарисовалась структура с явным выделением отдельных компонентов, то систему можно и на основе сервисов собирать.
Т.е. мы сначала выясняем ответ на вопрос "что?", а на основе полученной информации решаем "как?". Причем для того что-бы это увидеть хватает довольно малой детализации.
Если нарисовалась структура с явным выделением отдельных компонентов, то систему можно и на основе сервисов собирать.
2 копейки добавлю: веб-сервисы вообще-то не только RPC бывают. И для SOA документы более чем полезны
Abava blog
Abava blog
Elena, с этим набором тезисов я согласен. Только учитывая, что "все крупные компании уже давным давно автоматизированы" монолитную систему внедрять некуда. Приходится постепенно развивать то, что есть.
Abava, дискуссия на сайте ITBlogs.ru рассматривала Web-сервисы именно как механизм RPC, причем в контексте SOA. Для SOA же более актуальны "документальные" (Web-)сервисы, в чем и состоит не нашедшая отклика значительная часть моего повествования.
Даниил, рекомендую почитать http://msdn2.microsoft.com/en-us/library/aa479343.aspx как пример похожего взгляда на SOA
Отправить комментарий
Ссылки на это сообщение:
<< Главная страница
LinkedIn
vCard
Лента
