Интеграция - использовать стандарт или писать на коленке ?

[Maxim Gorbunov]

Цитата:

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

Если Biztalk не используется, то и AIF идет в топку.

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

Да, я соглашусь, бывает, что AIF используют неправильно и совсем не для того, для чего он предназначен. Соглашусь и с тем, что документации катастрофически мало. Но, как и любой фреймворк, он хотя бы делает попытку дисциплинировать и ограничить полёт фантазии программиста.

Цитата:

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

Кроме того - клиентам не очень-то легко продать идеи стоимости поддержки проекта в долгосрочной перспективе. Идея потратить лишние человеко-недели на добавление поддержки AIF для новых полей в ключевых таблицах, настройку AIF, обучение админови тп - и все ради каких-то сниженных затрат в пятилетней перспективе - она не всегда найдет особую поддержку клиента. Клиентский ПМ обычно мыслит границами проекта (его все равно после завершения проекта переведут куда-то, а то и повысят). За бюджет проекта он отвечает, за бюджет последющей поддержки - нет.

Клиентские ПМ, в большинстве своём, вполне адекватные люди. Просто надо разговаривать с ними и объяснять такие вещи на доступном языке, без лишних технических или маркетинговых подробностей. Мне встречалось немало ПМ, для которых одно упоминание о том, что мы используем стандартный функционал по максимуму, являлось достаточных обоснованием дополнительных административных затрат на настройку и обучение. Просто они уже понабивали себе шишек, поддерживая другие (совсем необязательно это должна быть Аксапта) кастомные решения. Больше того, многие проекты внедрения Аксапты как раз и начинались для того, чтобы такие решения заменить и стандартизировать процесс.

Цитата:

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

Просто потому что AIF изначально over-engineered и попытки его расширить грязными руками разработчика типичного уровня безграмотности приводят к чудовищным результатам. В то же время тот же разработчик в состоянии написать примитивный импорт примитивных производственных заказов через ODBC и в его коде можно разобраться за пару часов времени. Этот код тоже не фонтан, но в связи с его примитивностью его вполне можно починить.

То есть, из-за безграмотности типичного разработчика ты предлагаешь выкинуть фреймворк? Ну, так мы можем далеко уйти. Типичному безграмотному разработчику, возможно, будет тяжело разобраться с разноской инвойсов по продажам, но уж с записью данных напрямую в таблицы он как-нибудь разберётся. Разрешим ему писать в таблицы?