ESB не решает волшебным образом задачи интеграции. Те же адаптеры разрабатываются и исполняются в среде ESB.
Из-за того, что ESB становится узким местом (ёмкость команды интеграции) в деливери, продуктам/системам всё-равно приходится разрабатывать адаптеры либо "в обход" ESB, либо к сервисам на ESB
Немного в сторону. Продуктовые команды всегда (почти) обходят узкие места, потому что им нужно делать бизнес. Но делается это часто с помощью костылей.
ESB неизбежно становится узким местом в деливери, а часто ещё и узким местом в производительности.
Централизованный подход к интеграции (на базе ESB) может неплохо работать при "плановой экономике", то есть при "социализме". Там где есть пятилетки (релизы раз квартал) и не очень считают деньги.
Esb мы внедряем для замены старых интегрционных решений (общее дупло в базе данных и т.п.). Руководители хотят финэфект от внедрения... Вот видимо не только мы это посчитать не можем. Похоже его просто нет, только на долгосрочную перспективу при замене одной системы на другую
Esb мы внедряем для замены старых интегрционных решений (общее дупло в базе данных и т.п.). Руководители хотят финэфект от внедрения... Вот видимо не только мы это посчитать не можем. Похоже его просто нет, только на долгосрочную перспективу при замене одной системы на другую
Посчитайте стоимость разработки новых систем/сервисов (включая аналитику, проектирование, все доработки смежных систем итп) с шиной и без
Для этого можно грубо взять план-график (лучше факт) по разработке и внедрению чего-либо без шины и в нём для каждого куска работы экспертно прикинуть, быстрее или медленнее этот кусок работы будет делаться с шиной
Скорее всего должна сильно сократится аналитика (например выяснение, откуда взять информацию, как склеить и куда засунуть), умеренно разработка интеграций и незначительно архитектура