Концепция SOA – технология, архитектура или нечто большее?
Моя сравнительно недавняя заметка в Connect (#6'08):
Update (18.01.09): некоторая детализация затронутых в заметке идей - в следующем посте.
Update (18.01.09): некоторая детализация затронутых в заметке идей - в следующем посте.
Ярлыки: Business-IT Alignment, Enterprise Architecture, SOA
Комментарии: 8:
Странная статья. Что автор хотел сказать, в чем цель ее написания?
По существу:
- "Business Process Management (управление бизнес-процессами), явно или неявно подразумевая реинкарнацию концепции реинжиниринга бизнес-процессов". Между BPM и BPR много различий. С не меньшим успехом можно выводить корни BPM из TQM.
- "В большой степени SOA можно и даже необходимо рассматривать как инструмент, который помогает обеспечить реинжиниринг не в рамках процесса прорисовки бизнес-процессов, а с точки зрения создания их целостной картины и соответствующего технологического обеспечения единого и интегрированного ландшафта приложений и систем." Принципиальное отличие современного понимания управления бизнес-процессами (a-la BPM) от реинжиниринга - управление изменяющимися бизнес-процессами (ключевые слова: agility, real-time enterprise). Не было бы этого требования - не были бы востребованы ни BPM, ни SOA. Но автор не говорит об этом ни слова.
- "Можно сказать, что с точки зрения формулируемых целей в SOA нет ничего нового по сравнению с традиционной концепцией EAI (Enterprise Application Integration). Единственное отличие – использование терминов не приложений, а бизнес-процессов, которые этими приложениями автоматизируются." SOA отличается от традиционного EAI слабой связностью и ставкой на открытые стандарты.
А где определение бизнес-сервиса, на котором вы строите все свои рассуждения?
Как бизнес-сервис соотносится с бизнес-процессами, бизнес-операциями и прочими "бизнес-*" терминами?
Как идентифицировать бизнес-сервисы, чтобы на их основе строить SOA?
Ну с бизнес-сервисами все более-менее понятно, это не автор их придумал. Существует референтная модель SOA из трех уровней. Снизу верх (в вольном изложении):
1) Data-services - грубо говоря, обертка вокруг таблиц баз данных.
2) Business services - нетривиальные бизнес-объекты и их бизнес-логика.
3) Process services - комбинация бизнес-сервисов для обслуживания определенного шага конкрентного бизнес-процесса.
> Ну с бизнес-сервисами все более-менее понятно, это не автор их придумал. Существует референтная модель SOA из трех уровней. Снизу верх (в вольном изложении):
1) Data-services - грубо говоря, обертка вокруг таблиц баз данных.
2) Business services - нетривиальные бизнес-объекты и их бизнес-логика.
3) Process services - комбинация бизнес-сервисов для обслуживания определенного шага конкрентного бизнес-процесса.
Референтных моделей можно придумать миллион и все они будут разными.
Ни про дата-сервисы, ни про процесс-сервисы у автора в статье нет упоминания.
Бизнес-объекты и их бизнес-логика -- это, по-вашему, бизнес-сервисы?
Ниразу не слышал, чтобы в бизнесе использовали понятие "бизнес логики". Понятие "бизнес-логики" используется у разработчиков, которые как раз работают с теми самыми технологиями, от которых автор пытается в этой статье отвлечь внимание читателя.
Так что все мои вопросы остаются в силе и очень хочется услышать комментарии Сергея по этому поводу.
>> Референтных моделей можно придумать миллион и все они будут разными.
Я лично в литературе встречал только эту. Буду признателен, если вы приведите альтернативную модель. Пусть не миллион, но хотя бы одну.
>> Бизнес-объекты и их бизнес-логика -- это, по-вашему, бизнес-сервисы?
Естественно, бизнес-сервисы - это не сами объекты, а интерфейсы к ним.
>> Ниразу не слышал, чтобы в бизнесе использовали понятие "бизнес логики".
Конечно. Только при чем тут бизнес? В бизнесе о SOA не говорят, считая это чисто ИТ-шными делами; бизнес-процессы - другое дело.
> Я лично в литературе встречал только эту. Буду признателен, если вы приведите альтернативную модель. Пусть не миллион, но хотя бы одну.
Я встречал много моделей: от SoftwareAG, от SAP, у меня есть своя модель, но дело не в ней.
>> Бизнес-объекты и их бизнес-логика -- это, по-вашему, бизнес-сервисы?
> Естественно, бизнес-сервисы - это не сами объекты, а интерфейсы к ним.
Мой бизнес заключается в производстве и продаже картонных коробок, о каких интерфейсах и объектах речь?
>> Ниразу не слышал, чтобы в бизнесе использовали понятие "бизнес логики".
> Конечно. Только при чем тут бизнес? В бизнесе о SOA не говорят, считая это чисто ИТ-шными делами; бизнес-процессы - другое дело.
Именно в бизнесе о SOA и надо говорить, и статья как раз это и подчеркивает.
> Именно в бизнесе о SOA и надо говорить, и статья как раз это и подчеркивает.
Именно эта рекомендация и вызывает сильные сомнения.
Бизнес хорошо понимает, когда с ним говоришь о конкурентоспособности. Спускаясь вниз по иерархии целей, можно говорить о влиянии на конкурентоспособность бизнес-процессов компании. Спускаясь еще на ступеньку ниже - о необходимости быстрой адаптации процессов компании к изменяющимся условиям. И только еще уровнем ниже появляется SOA как средство достижения такой адаптации. Но к этому моменту бизнес уже теряет интерес к разговору, справедливо относясь к SOA как к деталям реализации.
Поэтому хороший совет - "Если хочешь продать бизнесу SOA, не произноси слово SOA".
А о чем же тогда с бизнесом говорить? Проблема в том, что большинство ИТ-людей не способны говорить ни о конкурентоспособности, ни о процессах. И в результате получается, что ИТ не способен поддержать разговор на темы интересные бизнесу, и наоборот.
Вопрос: кто должен сделать шаг навстречу в этой ситуации, бизнес или ИТ? Автор стать видимо считает, что бизнес. Я не согласен.
Коллеги,
большое спасибо за крайне интересные комментарии. Надеюсь, мой следующий пост в какой-то степени ответит на поставленные вопросы.
P.S. кто должен сделать шаг навстречу в этой ситуации, бизнес или ИТ? - я считаю, что ИТ, но оперируя такими понятиями как бизнес-процесс, бизнес-сервис, организационная структура, информация и т.п. Упуская вопрос бизнес-целей и инноваций, ИТ будет скучен бизнесу. Говоря о системах и инфраструктуре не только в терминах затрат - будет не понят и, как результат ИТ будет продолжать восприниматься только как косты.
P.P.S. Вы редко услышите это от консультантов, но есть некоторые интересные факты:
1. Любой консультант на уровне рефлексов разрывается между двумя желаниями - сохранить свое know-how и вместе с тем, продвинуть его на рынок.
С другой стороны,
2. я не знаю консультантов, которые не компилировали бы существующие знания и подходы.
так что если где-то детализации не хватает - см.1, но это не всегда является причиной, а в этом блоге - и подавно :)
Отправить комментарий
Подпишитесь на каналы Комментарии к сообщению [Atom]
<< Главная страница