Комментарии 7
Огромная работа. Поставил за нее плюсы, но во многом не согласен.
Тема важная, поскольку считаю, что за интегрированными системами будущее. Времена больших ERP, где автоматизируются все функции в одной системе проходят. А если выбираешь лучшее решение отдельно для каждой функции, то интеграция должна быть действительно хорошо работающей.
Но не согласен я с подходом основанным на лечении симптомов.
Будет эффективнее находить ключевые проблемы, базовые причины проблем, которые на поверхности повседневной практики.
Например. Контрагенты, договоры, валюти и пр. — это просто таблицы в базе данных, хранящие набор признаков, которые используются в других таблицах, типа «проводки». Кстити Учетные счета — это тоже просто таблица. Если в двух системах есть таблица с функцией хранения реестра Контрагентов, то при консолидации будут проблемы. Но такие же проблемы будут с любыми другими справочными таблицами в базе данных.
Решение будет также одно. Например, мы предпочитаем урегулировать все несоответствия через таблицу «Правила соответствия» где просто указываются синонимы из разных баз и эта таблица учитывается при взаимодействии данных по алгоритмам. Но часто встречаю попытки сделать в холдингах единые справочники (по мне дак очень плохая идея).
Но больше всего в вопросах интеграции меня беспокоят закрытые базы данных. Разработчики считают что в структуре их баз прям вот ценность и делают так, что интегрироваться можно через их, зачастую очень кривое, API, без нормальной документации и с очень урезанными возможностями. Если базы открытые и могут запросами общаться друг с другом, то меньше проблем.
Когда Вы пишите вот прямо по конкретностям, но это становится учебником, который никто не читает. Для меня вопрос мега актуальный, но признаюсь честно, с третьего абзаца уже пошла диагональ.
Тема важная, поскольку считаю, что за интегрированными системами будущее. Времена больших ERP, где автоматизируются все функции в одной системе проходят. А если выбираешь лучшее решение отдельно для каждой функции, то интеграция должна быть действительно хорошо работающей.
Но не согласен я с подходом основанным на лечении симптомов.
Будет эффективнее находить ключевые проблемы, базовые причины проблем, которые на поверхности повседневной практики.
Например. Контрагенты, договоры, валюти и пр. — это просто таблицы в базе данных, хранящие набор признаков, которые используются в других таблицах, типа «проводки». Кстити Учетные счета — это тоже просто таблица. Если в двух системах есть таблица с функцией хранения реестра Контрагентов, то при консолидации будут проблемы. Но такие же проблемы будут с любыми другими справочными таблицами в базе данных.
Решение будет также одно. Например, мы предпочитаем урегулировать все несоответствия через таблицу «Правила соответствия» где просто указываются синонимы из разных баз и эта таблица учитывается при взаимодействии данных по алгоритмам. Но часто встречаю попытки сделать в холдингах единые справочники (по мне дак очень плохая идея).
Но больше всего в вопросах интеграции меня беспокоят закрытые базы данных. Разработчики считают что в структуре их баз прям вот ценность и делают так, что интегрироваться можно через их, зачастую очень кривое, API, без нормальной документации и с очень урезанными возможностями. Если базы открытые и могут запросами общаться друг с другом, то меньше проблем.
Когда Вы пишите вот прямо по конкретностям, но это становится учебником, который никто не читает. Для меня вопрос мега актуальный, но признаюсь честно, с третьего абзаца уже пошла диагональ.
Спасибо за комментарий. Потому что тема важная и сложная, и такие обсуждения дают новые грани понимания.
Да, время больших ERP точно в прошлом, да и самих ERP больше нет, все решения от одного вендора (как SAP) — просто множество модулей, просто там проблемы интеграции как-то решил вендор — и не всегда хорошо. И в практической работе мы вписываемся в тот исторически сложившийся IT-ландшафт, который есть.
Он — разный, в одних ландшафтах есть централизованное ведение справочников в одной системе, в других — есть попытка для каждого справочника определить одну мастер-систему, выделив Каталог товаров отдельно, а справочник контрагентов — отдельно, в третьих — в каждой системе свои справочники. Это As Is. И еще есть разное представление о To Be, может быть идти проект внедрения MDM (Master Data Management), часто многолетний, может идти проект внедрения CRM с решением «и всех клиентов перенесем туда, это будет главная система» и так далее. То есть везде по-разному. И в чем я точно уверен — это что это разнообразие точно будет, а вопросы развития надо решать «по месту», идеальной картины — нет, и у всех решений есть свои недостатки.
Я согласен с вами, единый MDM — не слишком хорошая идея, потому что он часто становится узким горлом в развитии. Мастер-система для каждого справочника разбивается о подробности следующего уровня, в части ведения контрагентов — клиенты и контрагенты разных типов и, особенно, договора с ними, требуют разного описания в разных системах, а один может быть во многих ролях и тут начинаются проблемы с определением мастер-системы.
Главная проблема — когда из-за ограничений в одной системе один партнер (ЮЛ) зарегистрирован несколько раз, например, потому что нет балансов расчета по разным договорам, или нельзя указать несколько валют расчета по сделкам, или предполагается, что партнер не может быть одновременно покупателем и поставщиком, а при этом в другой системе то же самое ЮЛ должно быть зарегистрировано в единственном экземпляре, иначе становятся невозможными взаимные зачеты требований-обязательств или ведение лимитов по рискам. То есть рассыпаются синонимы. Клиенты и контрагенты — самое частое, я сталкивался со случаями, когда заводили дубли в справочнике валют :) И вот я не представляю, как тут написать учебник о правильной штуке?
А с базой данных вопрос очень простой. Если там — только хранилка, логика в других местах, и именно они обеспечивают согласованность, то чтобы писать напрямую в БД надо очень хорошо знать эту логику и соблюдать ограничения целостности, иначе можно с легкостью нарушить ограничения целостности и система будет неверно работать. А API при этом — да, кривое. На чтение, обычно, проще, тут мы упираемся тупо в вопросы нагрузки.
А так же в вопросы развития системы — потому что таблицы ведь не статичны, меняются, а вечную обратную совместимость поддерживать непросто. И наиболее тяжелый вопрос — когда один объект развалили на две, например, был у контрагента расчетный счет, а теперь их может быть много, при этом другим системам по-прежнему нужен один. Вот и делают промежуточные view в надежде решить проблему.
Вообще в нынешней эпохе микросервисов и множественности баз данных, в том числе в одной системе, которые вовсе не обязательно реляционные, вопрос об организации хранения становится самостоятельным и сложным.
Я тут хочу спросить, а что именно вы предлагаете? Например, для контрагентов — легче обсуждать на конкретном примере. Единую таблицу и прямой доступ к БД? Или центральную систему, в которой собраны таблицы из всех систем и есть таблица соответствия между ними? А в чем отличия этого решения от единой системы справочников?
Да, время больших ERP точно в прошлом, да и самих ERP больше нет, все решения от одного вендора (как SAP) — просто множество модулей, просто там проблемы интеграции как-то решил вендор — и не всегда хорошо. И в практической работе мы вписываемся в тот исторически сложившийся IT-ландшафт, который есть.
Он — разный, в одних ландшафтах есть централизованное ведение справочников в одной системе, в других — есть попытка для каждого справочника определить одну мастер-систему, выделив Каталог товаров отдельно, а справочник контрагентов — отдельно, в третьих — в каждой системе свои справочники. Это As Is. И еще есть разное представление о To Be, может быть идти проект внедрения MDM (Master Data Management), часто многолетний, может идти проект внедрения CRM с решением «и всех клиентов перенесем туда, это будет главная система» и так далее. То есть везде по-разному. И в чем я точно уверен — это что это разнообразие точно будет, а вопросы развития надо решать «по месту», идеальной картины — нет, и у всех решений есть свои недостатки.
Я согласен с вами, единый MDM — не слишком хорошая идея, потому что он часто становится узким горлом в развитии. Мастер-система для каждого справочника разбивается о подробности следующего уровня, в части ведения контрагентов — клиенты и контрагенты разных типов и, особенно, договора с ними, требуют разного описания в разных системах, а один может быть во многих ролях и тут начинаются проблемы с определением мастер-системы.
Главная проблема — когда из-за ограничений в одной системе один партнер (ЮЛ) зарегистрирован несколько раз, например, потому что нет балансов расчета по разным договорам, или нельзя указать несколько валют расчета по сделкам, или предполагается, что партнер не может быть одновременно покупателем и поставщиком, а при этом в другой системе то же самое ЮЛ должно быть зарегистрировано в единственном экземпляре, иначе становятся невозможными взаимные зачеты требований-обязательств или ведение лимитов по рискам. То есть рассыпаются синонимы. Клиенты и контрагенты — самое частое, я сталкивался со случаями, когда заводили дубли в справочнике валют :) И вот я не представляю, как тут написать учебник о правильной штуке?
А с базой данных вопрос очень простой. Если там — только хранилка, логика в других местах, и именно они обеспечивают согласованность, то чтобы писать напрямую в БД надо очень хорошо знать эту логику и соблюдать ограничения целостности, иначе можно с легкостью нарушить ограничения целостности и система будет неверно работать. А API при этом — да, кривое. На чтение, обычно, проще, тут мы упираемся тупо в вопросы нагрузки.
А так же в вопросы развития системы — потому что таблицы ведь не статичны, меняются, а вечную обратную совместимость поддерживать непросто. И наиболее тяжелый вопрос — когда один объект развалили на две, например, был у контрагента расчетный счет, а теперь их может быть много, при этом другим системам по-прежнему нужен один. Вот и делают промежуточные view в надежде решить проблему.
Вообще в нынешней эпохе микросервисов и множественности баз данных, в том числе в одной системе, которые вовсе не обязательно реляционные, вопрос об организации хранения становится самостоятельным и сложным.
Я тут хочу спросить, а что именно вы предлагаете? Например, для контрагентов — легче обсуждать на конкретном примере. Единую таблицу и прямой доступ к БД? Или центральную систему, в которой собраны таблицы из всех систем и есть таблица соответствия между ними? А в чем отличия этого решения от единой системы справочников?
По контрагентам — очень хороший пример, но встают следующие вопросы:
1. Кто в таком случае должен вести справочники/правила соотвествия? Не будет ли это попыткой решить недостатки архитектуры одной системы (или архитектуры в целом) неоправданным усложнонением?
2. Кто будет отвечать за объект за разные части которого отвечают разные системы? Больше похоже на то, что это все же разные но взаимосвязанные объекты
2. Что делать если интегрируется коробочное решение, доработка которого невозможна или нежелательна? Реализовывать некую прокси, которая будет в этом ELT выполнять функцию трансформации? или полноценный ETL?
3. Какие еще есть решения кроме MDM и справочников соотвествия?
1. Кто в таком случае должен вести справочники/правила соотвествия? Не будет ли это попыткой решить недостатки архитектуры одной системы (или архитектуры в целом) неоправданным усложнонением?
2. Кто будет отвечать за объект за разные части которого отвечают разные системы? Больше похоже на то, что это все же разные но взаимосвязанные объекты
2. Что делать если интегрируется коробочное решение, доработка которого невозможна или нежелательна? Реализовывать некую прокси, которая будет в этом ELT выполнять функцию трансформации? или полноценный ETL?
3. Какие еще есть решения кроме MDM и справочников соотвествия?
По моему опыту, все эти вопросы решаются ситуативно. Есть некоторый парк легаси-систем, в которых исторически сложилось ведение клиентов и контрагентов, и при внедрении новой системе ставится задача — как ее вписать в сложившийся ландшафт. Ответы — различны, зависят от места системы. Иногда она объявляется мастером по ведению некоторой части справочников или даже всех, для клиентов и контрагентов так часто поступают при внедрении CRM, а не только МДМ. В других случаях она будет ведомой и получает справочники по интеграции.
Самое главное тут — прописать картину ответственности по совокупности систем. В хороших компаниях за этим следят, но в большинстве тут печалька — потому что специалисты разделены по системам, и каждый знает только про свое…
А коробку интегрируем как можем, все зависит от объема необходимого преобразований…
Я понимаю, что ответ формальный в стиле «все сложно», но реально общего решения нет.
Самое главное тут — прописать картину ответственности по совокупности систем. В хороших компаниях за этим следят, но в большинстве тут печалька — потому что специалисты разделены по системам, и каждый знает только про свое…
А коробку интегрируем как можем, все зависит от объема необходимого преобразований…
Я понимаю, что ответ формальный в стиле «все сложно», но реально общего решения нет.
Разумеется архитектору на одном решении фиксироваться не стоит, но для команд должны быть прописаны четкие правила для как минимум для 80% случаев. Если такие правила не установлены, обязательно найдутся люди, решающие свои задачи за чужой счет (и не важно «лапки» у них или они «равнее» всех). Особенно в больших холдингах. Я это вижу сплошь и рядом.
Я не верю в регламенты. Сколько не прописывай отвественность — крайним, как в поговорке становится или стрелочник или последний или вообще никто. Отвественность должна ественно проистекать из построенного процесса. Кто виноват — источник и никаких других вариантов.
Возвращаясь к моему вопросу, может быть вы дополните список, который я сформулировал для себя:
1. MDM + создание связанных сущностей типа Контрагент и Юрик со ссылкой на первого при необходимости.
2. Справочники/правила соотвествия.
3. Создание прокси-сервисов, которые как бы предоставляют стандартный интерфейс для легаси и коробочных систем.
4. Полноценное ETL решение, перенаправляющее и приобразующее сущности по необходимости на лету.
P.S. Еще не надо забывыть, что инвестируя в разработку стейкхолдер держит в голове потенциальную возможнось продавать результат в виде коробок, SaaS или PaaS. Как полностью так и покомпонентно. По-этому полностью ксатомные интеграции изнутри отдельных сервисов — на мой взгляд недопустимы.
Я не верю в регламенты. Сколько не прописывай отвественность — крайним, как в поговорке становится или стрелочник или последний или вообще никто. Отвественность должна ественно проистекать из построенного процесса. Кто виноват — источник и никаких других вариантов.
Возвращаясь к моему вопросу, может быть вы дополните список, который я сформулировал для себя:
1. MDM + создание связанных сущностей типа Контрагент и Юрик со ссылкой на первого при необходимости.
2. Справочники/правила соотвествия.
3. Создание прокси-сервисов, которые как бы предоставляют стандартный интерфейс для легаси и коробочных систем.
4. Полноценное ETL решение, перенаправляющее и приобразующее сущности по необходимости на лету.
P.S. Еще не надо забывыть, что инвестируя в разработку стейкхолдер держит в голове потенциальную возможнось продавать результат в виде коробок, SaaS или PaaS. Как полностью так и покомпонентно. По-этому полностью ксатомные интеграции изнутри отдельных сервисов — на мой взгляд недопустимы.
Я тут не очень понимаю, к решению какой именно задачи такой список вариантов? Задача ведения справочника контрагентов компании? Или любых справочных данных (НСИ)? Или задача интеграции новой системы в существующий ландшафт и определение принципов ведения справочника контрагентов/всех справочников. То есть разные пункты в моем представлении — разнозначимы, применимы для разных задач. И я не всегда понимаю, какой вы вкладываете смысл, например, в «Справочники/правила соответствия» — потому что вижу разные варианты.
Что касается инвеста в разработку — то есть заказная разработка для крупных компаний в области их сложных собственных процессов, которые заведомо обобщаются и не продаются. Тут фишка в том, что на большом масштабе деятельности возникает более глубокое разделение труда, специализация сотрудников, в том числе и при обработке особых случаев в процессах, которые в более мелких компаниях выполняются «на руках». У меня преимущественный опыт именно в этих проектах.
Что касается инвеста в разработку — то есть заказная разработка для крупных компаний в области их сложных собственных процессов, которые заведомо обобщаются и не продаются. Тут фишка в том, что на большом масштабе деятельности возникает более глубокое разделение труда, специализация сотрудников, в том числе и при обработке особых случаев в процессах, которые в более мелких компаниях выполняются «на руках». У меня преимущественный опыт именно в этих проектах.
Задача — цифровизация немаленькой группы компаний. Масштаб и интенсивность деятельности — обязывают.
Имеется множество как микросервисов, так и монолитов, не считая коробок, партнерских и легаси систем. В этих системах практически нет данных, которые не нужны другим (точнее людям в других системах и сервисах). По сути все — MDM. Все данные во всех системах становятся Master (контрагенты, сотрудники, учетки, номенклатуры, документы, товары, продажи и т.д.). Естественно в этом богатстве есть данные, которые меняются реже и нуждаются в отдельном процессе заведения — одни вынесены в НСИ системы, но грань эта призрачна (этакий градиент).
Будучи пущенной на самотек такая архитектура интеграций превращается не в набор продуманных решений оправданной в каждом конкретном случае. А набор реализаций, которые на момент разработки показались самыми удобными для разработчиков. Подрядчики задачи интеграции решают по остаточному признаку — бизнес вообще это с трудом понимает. Все это усугубляется зоопарком стеков и разнородностью компетенций разработчиков. Ну и никакой админки в таких случаях для решения проблем быть не может.
Собственно в моем (возможно искаженном) понимании решение состоит в том, что бы как минимум четко зафиксировать правила взаимодействия, что бы новые интеграции происходили просто и понятно.
Варианты одного из таких правил — Как оперировать сущностями если они отличаются в разных системах я и предложил в предыдущем комментарии.
По второму пункту. Справочники соответствия и справочники правил соответствия — это данные о том как объекты одних систем соотносятся со справочниками других. Такое на мой взгляд допускается в том случае когда мы пытаемся сопоставить смежные области, например перечень услуг показываемый клиентам и деятельность регулируемую государством. Но никак не в контрагентах, которых в наших масштабах и так немало, а если будут еще и справочники соответствия — вообще туши свет.
Что касается третьего — вопрос продажи в конечном счете поднимается всегда. Какой бы крупной/мелкой не была организация. Лишних денег не бывает. Тем более в кризис. Чаще не целиком, а отдельными решениями — по-этому и важно строить архитектуру так, что бы любой компонент мог быть заменен. И не важно по необходимости или при продаже и развертывании в урезанном окружении. Продают конечно те системы, работа в которых характеризуется не глубиной разделения труда а его количеством. В крупных конторах работает с системой 10 человек в мелкой — 1. Это не отменяет потребность в ней для этого одного человека. Наличие же понятного интерфейса интеграции сделает линейку продуктов более привлекательной и повысит шанс что приобретая одно решение клиент будет приобретать и другие.
Имеется множество как микросервисов, так и монолитов, не считая коробок, партнерских и легаси систем. В этих системах практически нет данных, которые не нужны другим (точнее людям в других системах и сервисах). По сути все — MDM. Все данные во всех системах становятся Master (контрагенты, сотрудники, учетки, номенклатуры, документы, товары, продажи и т.д.). Естественно в этом богатстве есть данные, которые меняются реже и нуждаются в отдельном процессе заведения — одни вынесены в НСИ системы, но грань эта призрачна (этакий градиент).
Будучи пущенной на самотек такая архитектура интеграций превращается не в набор продуманных решений оправданной в каждом конкретном случае. А набор реализаций, которые на момент разработки показались самыми удобными для разработчиков. Подрядчики задачи интеграции решают по остаточному признаку — бизнес вообще это с трудом понимает. Все это усугубляется зоопарком стеков и разнородностью компетенций разработчиков. Ну и никакой админки в таких случаях для решения проблем быть не может.
Собственно в моем (возможно искаженном) понимании решение состоит в том, что бы как минимум четко зафиксировать правила взаимодействия, что бы новые интеграции происходили просто и понятно.
Варианты одного из таких правил — Как оперировать сущностями если они отличаются в разных системах я и предложил в предыдущем комментарии.
По второму пункту. Справочники соответствия и справочники правил соответствия — это данные о том как объекты одних систем соотносятся со справочниками других. Такое на мой взгляд допускается в том случае когда мы пытаемся сопоставить смежные области, например перечень услуг показываемый клиентам и деятельность регулируемую государством. Но никак не в контрагентах, которых в наших масштабах и так немало, а если будут еще и справочники соответствия — вообще туши свет.
Что касается третьего — вопрос продажи в конечном счете поднимается всегда. Какой бы крупной/мелкой не была организация. Лишних денег не бывает. Тем более в кризис. Чаще не целиком, а отдельными решениями — по-этому и важно строить архитектуру так, что бы любой компонент мог быть заменен. И не важно по необходимости или при продаже и развертывании в урезанном окружении. Продают конечно те системы, работа в которых характеризуется не глубиной разделения труда а его количеством. В крупных конторах работает с системой 10 человек в мелкой — 1. Это не отменяет потребность в ней для этого одного человека. Наличие же понятного интерфейса интеграции сделает линейку продуктов более привлекательной и повысит шанс что приобретая одно решение клиент будет приобретать и другие.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как сделать хорошую интеграцию? Часть 1