Смотря, что считать удачным или неудачным.

Ну вы же даёте оценку - хотя бы это

Видимо я чем-то задел EA. Давайте перейдем от проблем с процессами к более конкретным вопросам архитектуры

Видимо тебя чем то задели ea.

«Вы хотите поговорить об этом?»

Есть объективные причины для полного отказа от архитектурного стиля диктуемого SOA ESB в пользу микросервисов. Это первое. Есть серьезные вопросы к позиции EA как таковой. Это второе. Больше ничего

В моем опыте так оно и живет (если нет "психиатрических больниц") до уровня Ent Arch. На уровне Ent arch - видел по-разному (в зависимости от Заказчика и специфики проекта). Причем последний год я ровно на примере ГИП это и рассказываю)

Т.е. если я правильно понял - дальше идет двойка - "продавец СЕО" и "ЕА - СТО". Так? Не ошибаюсь?

Не знаю, что подразумевается под SOA ESB в Вашем призыве, но мне кажется крайне наивным считать, что из-за того, что в головах у топов (промытых ушлыми продажниками поставщиков) или у ЕА (которые тоже могут быть промыты теми же продажниками) SOA КАК БУДТО БЫ ассоциируется с ESB-ориентированными продуктами, SOA - плохо и некошерно, а микросервисы - манна небесная. В конце концов вендоры и поставщики тоже умеют чувствовать тренды рынка не хуже нас всех, и они сейчас спешно переобуваются в полете, выпуская продукты под названием Microservice Suite и тому подобное. Когда эта КОНКРЕТНАЯ реализация, возможно, не самая удачная или используемая не самым корректным образом, тоже кого-то не устроит, все будут говорить о закате микросервисов?

Начну еще 1 холивор: я наоборот считаю что это - очень важно. Вложение денег в обертки с единственной целью - разделение отвественности считаю оправданным. Где есть разделение ответственности и четкие правила игры легче создать доверие. Считаю, что главное в организации (не ИТ-организации) на уровне ЛПР - доверие. Они за доверие очень дорого платить готовы.

Есть проблемы, которые бесспорно лучше решать с помощью  MS, есть те, где MS никак не годится. Тоже со старым Soa.

Поддержу

Всякому инструменту, стратегии, подходу - своё применение

Предлагаю повернуть обсуждение немного в другое русло. А можно узнать конкретные проблемы, связанные  с использованием ESB-продуктов в контексте стиля SOA? Просто в референсной архитектуре SOA про шины нет ни слова, речь идет об оркестровке и реализации бизнес-процесса (через BPMS или на базе ESB, как делают многие - неважно), но если говорить о реализации этой части через ESB - чем по-вашему это плохо? Просто интересны доводы. Возможно, выше уже было, но я потерялся в куче сообщений, если честно.

Почитайте часть обсуждения которая начинается 23 мая. Суть в том, что микросервисы позволяют эффективнее достигать целей, которые ставятся перед SOA.

Но при это пока нельзя судить, так как нет примеров применения MS в кровавом энтерпрайзе :)

юбер

Можно попробовать оттолкнуться от некой гипотетической картины. Предположим, есть некий банк. В банке много унаследованных решений, разные бизнес домены, совершенно разные стейкхолдеры. Какие-то домены развиваются быстро, у них "живые" стейхолдеры постоянно генерируют поток требований, но есть и другие домены, которые относительно статичны. Также есть можество унаследованных решенй, которые так просто не вынести. Отсюда, какие-то решения, для которых критично TTM, разумно реализовать в соотв. с MSA, а где-то выгодно вообще исп. 3 Tire в виде монолита. При этом, ESB так или иначе нужна для интеграции.

Отдельные примеры есть. Нет примеров полного перехода Enterprise на MSA. Так или иначе такие примеры скоро появятся. Это вопрос выживания. Те же розничные банки испытывают огромное давление со стороны интернет-компаний.  Если ничего не изменятся, то вскоре прежние игроки просто покинут рынок

Думаю, в среднесрочной перспективе мы будем наблюдать Mixed архитектуру, см. выше.