"Нужна возможность замены любых классов и методов целиком" Снизит ли это трудоемкость в долгосрочной перспективе?

[mazzy]

Цитата:

Сообщение от fed

Заметное число клиентов не сможет внедрить систему, в которой запрещена ЗАМЕНА стандартной логики тем или иным методом.

Почему? Они тупые? (С)

Я бы сформулировал так:
ЕСЛИ, из-за запрета замены стандартной логики, ТСО вырастет настолько, что станет неприемлемым для клиента (либо у клиента столько денег нет, либо на рынке есть конкурирующий продукт с существенно меньшим TCO),
ТО клиент просто не станет внедрять систему.

Цитата:

Сообщение от fed

Как в этом случае TCO посчитать ?

в этом случае достаточно констатации, что TCO будет неподъемной для целевой аудитории или существенно выше, чем у конкурентов.

Цитата:

Сообщение от fed

Сформулируем конкретный пример: в DAX2012 внедрили с overlayering. Чистая TCO за 5 лет - X. В D365FO внедрить не смогли в принципе (просто остановили проект после прототипирования). Как сравнимые TCO посчитать ?

Дык, нет внедрения - нет владения.
нет владения - нет доходов от продажи у вендора.
нету ручек - нет конфетки.
https://www.youtube.com/watch?v=7KyZJ3xrreA

TCO - не единственный показатель )))

[fed]

Цитата:

Сообщение от mazzy

Почему? Они тупые? (С)

Я бы сформулировал так:
ЕСЛИ, из-за запрета замены стандартной логики, ТСО вырастет настолько, что станет неприемлемым для клиента (либо у клиента столько денег нет, либо на рынке есть конкурирующий продукт с существенно меньшим TCO),
ТО клиент просто не станет внедрять систему.

Так тут и стоит проблема: Обычно клиент требует замены стандартной логики, потому что риски и косты замены бизнес-процессов очень тяжело оценить. А риски и косты разработки - не очень. То есть - по разработке можно раза в 2-3 ошибится в оценке в худшем случае, а при смене бизнес-процессов - эдак раз в 30-50
Поэтом и дорабатывают так много...

[ax_mct]

Цитата:

Сообщение от mazzy

Почему? Они тупые? (С)

Большинству типичных клиентов AX - TCO это прежде всего вопрос нахождения надежного Партнера которому можно доверять. Затем возможности самой системы.
И только после этого - стоимость. Это только вендор думает что TCO на первом месте.

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

В Java и PHP это делается через конфигурационные файлы *.xml на уровне конкретных фрэймворков. По сути AX/D365FO тот самый фрэймворк и есть и с учетом того что уже есть через метаданные это действительно проще.

Но это не избавляет от (функциональных) конфликтов при обновлениях и раз так то проще использовать слои. Все что нужно вендору - это разные режимы и настройки продукта относительно обновлений и overlayering которые определяет сам клиент/партнер.