GK
Если ЕА не знает как тот или иной компонент (квадратик) отображается на бизнес (на конкретный продукт/стейкхолдера) то значит он чем-то не тем занимается. И ещё конечно есть общее хозяйство.
Size: a a a
2019 November 10
SB
Это извечное противостояние, консалтеры пишут талмуды, а их на полку определяют. Потому что еа - исключительно внутренняя компетенция
Ну я-то практикующий, много лет, был разный опыт и даже будучи консалтером — практикую.
Бывало так, что 0 из 20 знают кто такой Фаулер, EAI, DDD.
При том, что в командах люди вовсю практикуют это.
Бывало так, что 0 из 20 знают кто такой Фаулер, EAI, DDD.
При том, что в командах люди вовсю практикуют это.
GK
Sergey Baranov
Где иногда прям шквал непонимания. «Как это дублировать данные?»
Тяжёлый случай и "общий" к сожалению.
GK
Sergey Baranov
Ну я-то практикующий, много лет, был разный опыт и даже будучи консалтером — практикую.
Бывало так, что 0 из 20 знают кто такой Фаулер, EAI, DDD.
При том, что в командах люди вовсю практикуют это.
Бывало так, что 0 из 20 знают кто такой Фаулер, EAI, DDD.
При том, что в командах люди вовсю практикуют это.
Известны случаи когда ЕА из внедренцев "вырастают". Разговор в лифте: "хватит внедрять, пора стрелочки рисовать".
EN
Sergey Baranov
Ну я-то практикующий, много лет, был разный опыт и даже будучи консалтером — практикую.
Бывало так, что 0 из 20 знают кто такой Фаулер, EAI, DDD.
При том, что в командах люди вовсю практикуют это.
Бывало так, что 0 из 20 знают кто такой Фаулер, EAI, DDD.
При том, что в командах люди вовсю практикуют это.
Ну Мб на уровне еа другие принципы/ Паттерны нужны?
EN
Соа то они слышали?
SB
Соа то они слышали?
Не все. Ну то есть на уровне «инеграция через ESB»
GK
Вообще-то сейчас нужно эти вещи понимать. DDD и микросервисы, иначе действительно не понятно, как это данные дублировать.
SB
Еще раз — это не все, но уже прям стало в глаза бросаться 🙂
EN
Для этого можно делать мини курс для топов, лишняя копейка консалтеру
SB
Для этого можно делать мини курс для топов, лишняя копейка консалтеру
Согласен, что это один из вариантов, но мне кажется, что проблема глубже. Где-то пропущено целое звено в получении информации, что ли.
EN
В ЕА могут с разных сторон придти наверное, не обязательно споткнутся об ддд по пути
GK
Есть хронические случаи, поможет только повышение
SB
В ЕА могут с разных сторон придти наверное, не обязательно споткнутся об ддд по пути
Разумеется. Но что еще есть из общепринятого и действительно рабочего для моделирования предметной области? То есть это как-бы уже best practice, разве нет? По крайней мере на текущий момент.
EN
Я встречал много людей, которые про солид и грасп не слышали, но когда просишь рассказать как они проектируют, то делают ровно как нужно, по логике. Так что не обязательно термины знать, считаю. Главное чтобы человек хороший был)
EN
Хотя общий словарь конечно полезен
SB
Я встречал много людей, которые про солид и грасп не слышали, но когда просишь рассказать как они проектируют, то делают ровно как нужно, по логике. Так что не обязательно термины знать, считаю. Главное чтобы человек хороший был)
Термины нам нужны, чтобы общаться друг с другом, передавать и развивать идеи, продолжать их 🙂
SB
Так или иначе, будто мы немного обошли стороной EA 🙂 Вроде и бизнес затянули в определенную гибкость с потоками создания ценности, продуктовым мышлением и т.д. Разрабочтки вовсю пожинают плоды технологических революций. А связующее звено немного консервативит.
Мне было бы интересно посмотреть на EA, построенную вокруг Value Stream’ов (к которой сам не прикладывал руку). В целом EA может отражать реальность и быть согласованной с потоками создания ценности и без знания терминов и это ок.
Есть другая боль, что нередко это приводит к осознанию того, что нужно менять структуру компании 🙂
Мне было бы интересно посмотреть на EA, построенную вокруг Value Stream’ов (к которой сам не прикладывал руку). В целом EA может отражать реальность и быть согласованной с потоками создания ценности и без знания терминов и это ок.
Есть другая боль, что нередко это приводит к осознанию того, что нужно менять структуру компании 🙂
EN
С этим уже никто не спорит. Интересный вывод, что в некоторых случаях изменить оргструктуру оказывается проще, чем софт
MS
Sergey Baranov
Столкнулся с, на мой взгляд, глобальным препятствием к движению к решениям со слабыми зависимостями на уровне организаций (крупных).
Интересно, что это ентерпайз архитекторы (конечно, не все).
Сложность вот в чем:
1. У EA авторитет и право принимать решения
2. Многие вообще забыли о разработке
При этом
1. Часто не имеют опыта в событийных архитектурах и
2. Моделировании предметной области (настоящем моделировании с контекстами)
Что вытекает в сильное противоречие между EA и разработкой:
1. Стрелочки между квадратиками не имеют смысла. Имеют смысл события, а EA часто не понимаю как это моделировать
2. Модель предметной области компании с контекстами становится первичнее систем квадратиков на диаграммах, но тогда проектирование становится не просто расстановкой квадратиков, а единым источником правды становятся события не ERP/CRM, бизнес-события.
И вот как проектировать в таких условиях, в моей практике, подтверждаемой раз за разом, лучше понимают разработчики, знакомые с современными паттернами и технологиями, но у них нет права голоса, а олдскул EA все сильнее затягивают компании обратно в сильные связи и синхронное взаимодействие и выбор консерватиных решений даже при желании руководства, условно, попробовать микросервисы и событийки.
Кто еще наблюдал такое? Или это мое когнитивное искажение?
Интересно, что это ентерпайз архитекторы (конечно, не все).
Сложность вот в чем:
1. У EA авторитет и право принимать решения
2. Многие вообще забыли о разработке
При этом
1. Часто не имеют опыта в событийных архитектурах и
2. Моделировании предметной области (настоящем моделировании с контекстами)
Что вытекает в сильное противоречие между EA и разработкой:
1. Стрелочки между квадратиками не имеют смысла. Имеют смысл события, а EA часто не понимаю как это моделировать
2. Модель предметной области компании с контекстами становится первичнее систем квадратиков на диаграммах, но тогда проектирование становится не просто расстановкой квадратиков, а единым источником правды становятся события не ERP/CRM, бизнес-события.
И вот как проектировать в таких условиях, в моей практике, подтверждаемой раз за разом, лучше понимают разработчики, знакомые с современными паттернами и технологиями, но у них нет права голоса, а олдскул EA все сильнее затягивают компании обратно в сильные связи и синхронное взаимодействие и выбор консерватиных решений даже при желании руководства, условно, попробовать микросервисы и событийки.
Кто еще наблюдал такое? Или это мое когнитивное искажение?
Если EA сделал морду кирпичом втирает что-то про единый справочник или консолидацию данных, то это не значит, что через 15 минут в соседней перегворке он будет воспевать CQRS и ES. Позиция EA в значительной степени управленческая и "челночная дипломатия" - одна из её компетенций. Одним словом, если с нашей точки зрения EA тупит, то скорее всего мы просто неправильно понимаем его настоящие мотивы