Почему не стоит бояться ABAPа

Часто слышу про такую фантазию как zero-abap project. Проекты, где нет АБАПа. Почему все заказчики так его бояться и почему в России без него нельзя запустить проект? Основной аргумент заказчика обычно таков, что при использовании абапа нельзя нормально обновлять систему, что это влечет к увеличению стоимость сопровождения и бла-бла-бла. Интересно, а изменение схемы, кадровых мероприятий, использования OM объектов не влечет к тем же проблемам? ABAP он хотя бы изолирован от всего остального, его видно издалека, а изменения в настройках системы обычно без стакана чая не разберешь. Особенно, когда приходит нота с необходимостью внести изменения в стандартную схему, которую ты уже похоронил, а тут надо разобраться какие операции вносить, а какие не нужно.

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

 

Почему не стоит бояться ABAPа: 1 комментарий

  1. Calm

    >> и почему в России без него нельзя запустить проект?
    Интересно, а где-то не в России можно без абапа?

Добавить комментарий