Первопричиной поиска нового подхода к задаче интеграции в корпоративных информационных системах вызван, в сущности, одной причиной: определенной неудовлетворенностью, присутствующей в ИТ-секторе, результатами от применения стратегии "монолитной" информатизации. Другими словами - максимальной реализации требуемого от КИС функционала в рамках одной системы. Символом "де-факто" такой стратегии стали приложения класса ERP.
Note: Тем, у кого "все получилось" с ERP - мои искренние поздравления. Однако эта тема, скорей всего, Вам будет не интересна. Еще раз - мои поздравления, но если остаетесь, воздержитесь, по возможности, от неаргументированных заявлений вида "ERP forewer"...

В качестве альтернативы "монолитной" стратегии предлагается рассмотреть стратегию проектирования архитектуры КИС изначально учитывающую потребность в интеграции. Принципиальной особенностью данной стратегии будет помещение всех интеграционных задач в единый "центр интеграции", что позволит избежать проблем с интеграцией по принципу "каждый-с-каждым" и сетевых связей ы КИС. В качестве метода предлагается рассмотреть метод интеграции на уровне данных (Enterprise Information Integration EII, с некоторыми изменениями и дополнениями), таким образом данный центр будет функционировать на базе СУБД. Обмен совместно используемыми данными будет проходить через общую базу "центра интеграции", где будут осуществлятся необходимые преобразования (используя, в частности, методы интеграции, такие как карты преобразований данных и описание объектов интеграции в виде обобщенных и производных представлений).

Потенциальные выгоды подобной стратегии:
- возможность использования приложений с более "узкой" функциональностью в целом, но с большей гибкостью(производительностью, низкой стоимостью - в зависимости от приоритетов, определенных на этапе выбора каждого решения) в сравнении с многофункциональными системами;
- более эффективное, в зависимости от приоритетов - по скорости и/или стоимости обработки, совместное использование данных;
- большие возможности по созданию оптимального баланса между собственными, унасдежованными и сторонними разработками;

В прикрепленном файле - несколько более подробное (но все равно - урезанное) изложение данного вопроса.

PS. А внедрение ERP может и не означать "конец истории" проблем с интеграцией в каждом конкретном случае...

Guest_12345А Вы не хотите более подробно описать область применения предложений. Т.е. сказать, что изначально рассматривается предприятие со сложившейся структурой, направлением деятельности и перечнем продуктов. Что оно и далее всегда будет жтим заниматься и ничем другим.

Мне представляется, что собственно область деятельности предприятия не столь важна - по причине того, что условие можно сформулировать на другом уровне абстракции, но более точно. Предлагаемая стратегия ориентирована на предприятия, с высокой степенью совместного использования данных на различных этапах (в различных подпроцессах) общего процесса деятельности(бизнес-активности) предприятия. Достаточно нейтральный пример - справочник клиентов. Когда данные о клиенте нужны и в фининсово-бухгалтерских операциях, и в количественном учете, будь-то отгрузки/поставки или учет услуг, и на корпоративном/клиентском портале, и мало-ли где еще. Похожая ситуация возможна и с платежными документами и с другими "информационными объектами".
Тут важно понимать еще и такие особенности:
- каждому подпроцессу требуется свой собственный срез информации о совместно используемом объекте - кому-то достаточно наименования, кому-то нужны еще и банковские реквизиты, а какие-нибудь маркетиоды и вовсе собирают и привязывают к клиенту кучу собственной, никому кроме них не нужной, информации;
- набор функционала в каждом отдельном подпроцессе либо настолько обширен, что представляется целесообразным выделение его в самостоятельную подсистему (специализированнное ПО), либо действия выполняемые в определенном подпроцессе достаточно специфичны а информационные результаты имеют ограниченное применение внутри КИС в целом (малое количество сотрудников выполняет некие специфические операции), что также приводит к использованию специфического (узкоспециализированного) ПО;
При возможности определения подобных критериев собственно направление деятельности представляется не столь уже важным - специалист в своей предметной области сможет оценить, насколько данные особенности актуальны для его задач.

Guest_12345
Или Вы рассматриваете вариант абстрактного производства/продажи/предоставления услуг. Что у Вас сегодня - медицинское учреждение, а завтра будем выплавлять чугун, а потом это перестроим в ресторан и т.д.

Выплавлять чугун в операционной я полагаю не стоит, но стоит помнить о таких "сущностях" как холдинги, где набор "интересов" бывает достаточно причудливым. Да еще и имеет свойство менятся время от времени.
Ну и такие события как слияния/поглощения (не имея ввиду отъем бизнеса бандитами для последующей перепродажи,но именно объединение/присоединение бизнес-структур, в ситуациях, когда каждая из вовлеченных сторон имеет собственные ИТ-системы и по каким-то причинам нельзя провести замену(вытеснение) одной из систем)

GoBeerМожет быть я не совсем верно понял тему, но чем неустраивает EDI?
Если обощенно (об этом сказано в прикрепленном к изначальному сообщению файле) то ситуация примерно такова:
- с одной стороны, предположительно имеются достаточно серьезные предпосылки для активного пользования интеграцией;
- с другой стороны - особой активности (не смотря на обилее решений) в данном секторе незамечено, интеграция "каждый-с-каждым" по прежнему доминирует (обходясь, зачастую, вообще без специализированных инструментов);
В связи с подобным состоянием дел проделан анализ методов интеграции, применяемых в КИС, сделаны некоторые выводы и предложен вариант решения. Вариант, который потенциально должен давать преимущества в описанных условиях.

АБ Можно задать детский вопрос: а кому собственно предлагается? Может быть те, кто разрабатывают что-то для себя, и способны рассмотреть альтернативную архитектуру, но крупные независимые производители софта способны воспринять какую-то идею в этой области только в том случае, если у нее есть шанс набрать критическую массу сторонников. Какой смысл принимать какую-то (пусть даже самую лучшую в техническом отношении) стратегию интеграции, если никто кроме тебя ее брать на вооружение не собирается? С кем будем интегрироваться-то?!

А пока и предлагать особо нечего - одна голая идея. Можно обозначить ее, идею, и как попытку существенно снизить затраты на интеграцию. А насчет смысла... все когда-то делается в первый раз
АБ
На вебсервисы и SOA с этой точки зрения можно положиться.

Я не критикую SOA и другие методы, я констатирую факт - есть методы интеграции (много и разных), но нет их активного использования.

АБС логической точки зрения SOA -- это не обмен сообщениями, а удаленный вызов процедур.

Который так же отличается от использования средств обработки данных принятых в СУБД. Это одно из рабочих предположений - интеграцию не используют в силу, скажем так, "неудобности" существующих интеграционных инструментов.

guest_20040621Понятно, что стратегически это нафиг никому из софтописателей не нужно. ;)

Кроме софтописателей (если понимать под этим разработчиков того или иного прикладного ПО) есть еще масса людей, которым вопросы интеграции все равно решать приходится - используют они какие-либо инструменты для этого или нет. Да и многим софтописателям (точнее - людям, которые их "писанину" "двигают на рынок) приходится регулярно отвечать на вопрос: "Какие средства интеграции поддерживает ваша система(приложение) ?"

WJТри разных приложения переслали в ядро данные об одном и том же объекте. Причем, данные противоречивые. Каков регламент обмена с основной СУБД, приоритеты и возможность запросов на корректность данных?
Встречный вопрос: что понимать под "противоречивостью" данных ?
Регламент обмена с основной СУБД будет определятся возможностями и потребностями СУБД,приложений и информационной системы в целом. Для изменения основной базы можно предусмотреть различные механизмы. На вскидку, как минимум два:
- триггер в "интеграционной" БД и какое-либо действие с удаленной БД;
- тот-же триггер, но в удаленную БД передаются не сами изменения на только "уведомление" о произошедших изменениях (асинхронный механизм);
С корректностью не ясно, что имеется ввиду. Стандартные средства СУБД по обеспечению целостности данных плюс контроль прав доступа кажутся недостаточными механизмами ?

АБ
Ну что, будем продолжать упражняться в прыжках в ширину? :)
Это такая болезнь - в любой вопрос влазить с предложением посмотреть на BPM ?

guest_20040621Это игла и для покупателя, и для вендора, и для интегратора.
Когда Gartner сообщит, что за прошедший год никаких других систем, кроме ERP, не внедрялось - я подумаю над Вашими рассуждениями, не раньше.

2 WJ
Прежде чем продолжить, давайте сначала проясним такой вопрос - Вы предлагаете контрагентов заводить в нескольких системах паралельно ?

WJДавайте рассмотрим разные варианты.
Три системы имеют свои справочники и до недавнего момента работали автономно. Что мы можем им предложить?

Мы им можем предложить, по сути, два варианта:
- определить, кто будет "писатель" и кто "читатели" - кто отвественен за ведение какого справочника. Тот, кто обладает максимум информации о клиентах, становится отвественным за клиента, кто работает с поступающими платежами - отвечает за информацию о платежах и т.д.
- более сложный вариант первого случая, когда распределяются не только объекты но и их атрибуты (в начале говорилось, если помните, что объект существует в виде обобщенного представления и производных), в этом случае каждый получает права на ведение своей группы атрибутов, в соответствии с собственным производным представлением.
Как в подобную схему встроить репликацию мастер-мастер, я если честно еще не думал. Буду признателен за пример когда такая репликация будет нужна.

WJ(Я хочу предупредить сразу, что отношусь к числу приверженцев BPM, но если это слово здесь запрещено, то я предпочитаю сразу отправиться вслед за Garya и АБ)
Говорить никому не запрещается, особенно если по теме дискуссии и аргументированно. А то я так и не добился ответов на большинство своих вопросов к сторониикам BPM в паралельной ветке...