Первопричиной поиска нового подхода к задаче интеграции в корпоративных информационных системах вызван, в сущности, одной причиной: определенной неудовлетворенностью, присутствующей в ИТ-секторе, результатами от применения стратегии "монолитной" информатизации. Другими словами - максимальной реализации требуемого от КИС функционала в рамках одной системы. Символом "де-факто" такой стратегии стали приложения класса 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 в паралельной ветке...

WJПервый вариант может устроить только не очень активных пользователей, поэтому давайте говорить только о втором.

Так, на всякий случай... Вы не путаете, случайно, обмен иежду приложениями с конкурентной сетевой обработкой внутри приложения ?
WJКаждый ведет свою группу атрибутов. Но СУБД-то три. Полный справочник где хранится?

Если обобщенное представление никем не используется, то, очевидным образом, нигде кроме "центра интеграции" оно и не существует.

WJА то я так и не добился ответов на большинство своих вопросов к сторониикам BPM в паралельной ветке...Может просто плохо искали? Что-то ж Вам ответить пытались;-)[/quot]
Да ничего я не искал - просто читал, что отвечают. Получилось три ответа:
- потому-что
- когда-нибудь пригодится
- XML - это круто
Интересно, дающие такие ответы когда-нибудь писали технико-экономическое обоснование ?

процИнтеграция на уровне данных:
Только чтение:
ничего лучше view пока не придумали. использование функций во view позволяет делать любые преобразования "на лету"
Полный доступ:
1. прямая запись в "чужие" таблицы - используется в простых случаях
2. удаленный вызов "чужих" процедур - задействуется "чужая" бизнес логика - лучший вариант но кто-то должен эти процедуры написать
3. синхронизация изменений по триггерам - похоже на 2 только способ вызова другой
все 3 способа транзакционны и это главное
4. асинхронная синхронизация по сообщениям - возможна но надежность низкая

Совместный доступ к одним и тем же данным разных подсистем регламетируется обычным разграничение доступа каждой подсистемы.

2 проц.
Примерно об этом наборе действий речт и идет. Но, поскольку подразумевается получение в итоге некоторого "инструмента", то предполагается, что "типовые" операции должны быть "скрыты" - например, на уровне описания связей. Что-бы не переписывать каждый раз одно и тоже, заменяя только имена объектов. Ну и всякие мелочи, вроде загрузки-выгрузки данных(для поддержки унаследованных приложений), очереди (иногда без них никак) и пр.

WJВнутри приложения - это было бы слишком просто:) А интеграция на таком уровне, чтобы юзер и не заметил, что он работает в данный момент не с одним приложением, а с другим или с двумя разными? Вы об этом и не мечтаете, да?

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

Если есть приложение использующее обощенное представление (т.е. обощенное представление создано из объекта данного приложения) - там оно и будет храниться. А где, собственно, проблема ?
WJИметь знания и уметь передать знания - это разные науки.
Сей очевидный факт я оспаривать не буду. Только отмечу, что они таки пытались передавать...

MainframeНасколько мне известно реализация пока нет.
По-моему, все-таки есть. И, возможно, не единственное...

Evil_GuestА если посмотреть на эту тему
Тему СОА тут уже обсуждали, в частности, в ходе обсуждения бизнес-процессов. Безусловно, какое-то место для СОА на рынке гарантировано. Сколько это будет в %%, 75 как пишут по Вашей ссылке или более другое значение - время покажет. Удобство - удобством, но при существующей политике той-же SAP никакие сервисы на рынок СМБ ее не выведут - "не по зубам" СМБ решения от SAP.

iscrafmСУБД и есть на сегодня единственная стандартизованная точка соприкосновения.
Ну все... сейчас сторонники XML-интеграции заведут свою шарманку...

АБ"База данных -- а что база данных? Файлы, байты, диски -- везде одно и то же."
У СУБД имеется то, чего нет и пока, IMHO, не предвидится у других систем - язык работы с данными , т.е. SQL. Все остальные вынуждены похвалятся "мощными визуальными средствами"...