ofdax: Dynamics AX 7 Codebase Architecture

[Oleksandr]

Цитата:

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

Вообще - я думаю что для микрософта первые года два DAX в Cloud будут шоком. Очень они много нового и интересного узнают о том как на самом деле делаются проекты, за что на самом деле клиент платит партнеру, много ли клиентов готовы переносить данные в облако и действительно ли клиенты готовы оплачивать накладные расходы на ведение разработки 'по правильному'. Это уже не говоря про ценовую политику и другие чисто коммерческие вещи.
В общем - Микрософт следует своему знаменитому корпоративному лозунгу "Слабоумие и отвага"...

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

[Oleksandr]

Цитата:

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

Слои остались, но не уверен, что в клауде это разрешат делать, в on prem скорее всего будет

Никаких ограничений на использование слоев нет, более того, кодов доступа тоже нет. Возможно, пока...

[trud]

Цитата:

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

Он как-то упустил из виду что подготовка такого кода намного дороже и не всякий клиент согласен и способен платить разницу.
Сложно продать BMW, когда клиент хочет автоваз.

Ну как раз основная идея что для клиента это все будет намного проще
Т.е. представьте идею – вам нужно решение, например для склада. Вы заходите в каталог решений Azure, выбираете нужное решение(ну или вообще стандарт) и уже через несколько часов у вас разворачивается решение доступное по URL. Далее в LCS вы отмечаете нужные вам бизнес-процессы, сразу получается список шаблонов для начальных данных, которые нужно заполнить и загрузить в систему чтобы начать работать. В то же время ваши пользователи используя таск гайды по данным бизнес-процессам смогут сразу начать работу или обучение в системе. Платите вы от 50-200 долларов за человеко-месяц. Нужно больше или меньше пользователей – просто добавляете, не думая о конфигурациях, аосах, SQL и прочих вещах, которые большинству пользователей то не очень интересны. Т.е. это все довольно круто в концепции
Но тут опять же надо смотреть детали реализации 

[Logger]

А на чем в этой схеме заработает консалтинг ?

[sukhanchik]

Цитата:

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

А на чем в этой схеме заработает консалтинг ?

Я так понимаю - процесс движется к идее, заложенной в MS Dynamics CRM, MS Office, MS Windows. Следующим напрашивающимся шагом будет закрытие исходного кода (сейчас делаются все шаги к тому, чтобы простимулировать разработчиков максимально не трогать штатный код) и останутся dll-ки, к которым можно будет писать свои add-оны.
Ведь по большому счету никто же не посягает на исходные коды Excel, Word - все ими пользуются и пишут в отдельных случаях макросы (=add-оны).
Тот же Excel имеет набор пакетов расширений (Пакет анализа, поиск решения и т.д.). И также этими инструментами (Office, Windows) клиенты пользуются для бизнеса. И даже есть Project, который рассчитывает проекты и ему все верят - что задачи надо делать именно в том порядке, в котором он рассчитал. И никто не просит "подправить формулу для моего проекта, т.к. он супериндивиуален".

В этом ключе - все действия MS разумны и логичны. Dynamics будет в роли "мегакалькулятора" и в рамках этой роли конечно логично предъявлять жесткие требования к качеству реализации кода. Документацию напишут - тут вопрос за MS-ом, но после 2012 уже так приятно стало смотреть MSDN (Technet) и знать, что там скорее всего есть ответ.

Единственное, в чем пока остается неясность - так это в популяризации Dynamics. Конкуренция все-таки так или иначе на рынке ERP-систем присутствует и с российским менталитетом "мегакалькулятор" может на российском рынке проигрывать либо неконкуретной любимой программе бухгалтера , либо какой-нибудь немецкой программе, в которую легче внести изменения . Конечно если только не применить демпинг.
Без популяризации будут золотыми специалисты по системе, да и их будет не хватать.

Консалтинг здесь будет зарабатывать видимо "ассортиментом решений Microsoft". Т.е. где-то сваять программку на C#, где-то сделать add-on для Dynamics AX/CRM/..., MS Office - в общем - всем понемножку. Опять-таки - партнеры не будут узконаправленными, а будут работать по всей линейке продуктов MS, что снова хорошо ложится в стратегию MS-а в целом

[Link]

Цитата:

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

Следующим напрашивающимся шагом будет закрытие исходного кода (сейчас делаются все шаги к тому, чтобы простимулировать разработчиков максимально не трогать штатный код) и останутся dll-ки, к которым можно будет писать свои add-оны.

Т.е. внести изменение в стандартную форму n будет нельзя, но можно будет сделать свою очень похожую форму m с нужным функционалом. Тогда уже проще свою ЕРП писать с домино и куртизанками. Если следовать идее закрытия кода, разве код который хотели закрыть еще не закрыли, есть же много системного кода. А кастомный код и так можно писать только на верхних слоях. Так что логика не понятна.

[gl00mie]

Цитата:

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

Ну как раз основная идея что для клиента это все будет намного проще
Т.е. представьте идею – вам нужно решение, например для склада. Вы заходите в каталог решений Azure, выбираете нужное решение(ну или вообще стандарт) и уже через несколько часов у вас разворачивается решение доступное по URL. Далее в LCS вы отмечаете нужные вам бизнес-процессы, сразу получается список шаблонов для начальных данных, которые нужно заполнить и загрузить в систему чтобы начать работать.

Давайте разберем по пунктам:

• Для склада такое, может, и прокатит - там бизнес-процессов меньше пары десятков. Это если тупо склад, а не какой-нить 3PL-оператор.
• "Тупо склад" с 15-ю бизнес-процессами - это ведь отнюдь не уровень среднего и крупного бизнеса, куда метит Dynamics AX, потому что там уже бизнес-процессов - под сотню, а то и более. Все их настроить и связать между собой с помощью шаблонов начальных данных? Что-то сомнительно.
• Настроить ERP-систему пригоршней галочек - это, по-моему, утопия. Помнится, у локализаторов была такая затея - сделать некий мастер, который на основе демо-базы как набора шаблонов и каких-то галочек вроде как перельет в пустую базу нужное подмножество настроек, и получится готовая к употреблению система. Однако, идея в итоге заглохла: думается, с разрастанием функционала комбинаторная сложность такой задачи свела на нет все попытки ее автоматизации.

Цитата:

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

Я так понимаю - процесс движется к идее, заложенной в MS Dynamics CRM, MS Office, MS Windows.

По-моему, в перечисленных системах заложены 3 совершенно разные идеи

• MS Windows - это платформа для запуска приложений, которая, во-первых, сама по себе нафиг никому не нужна, во-вторых, она в целом ряде сценариев избыточна, требуя слишком много ресурсов и внимания для обслуживания самой себя (в т.ч. пресловутого накатывания заплаток и связанных с этим перезагрузок). Последние затеи типа Nano Server доказывают, что там не то что дописывать - в пору выкидывать лишнее.
• MS Office - чудесный пакет, который установлен, наверно, практически у всех, но он реализует сравнительно небольшое число совершенно типовых сценариев использования, стабильных и неизменных на протяжении десятилетий и, кроме прочего, не зависящих от местного законодательства или иных особенностей. Максимум, где-то пишут слева направо, а где-то - справа налево. Как по мне, развитие функционала Ms Office остановилось на версии 2010, дальше пошли рюшечки и портирование на другие платформы.
• А вот Dynamics CRM - отдельная тема...

Цитата:

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

Следующим напрашивающимся шагом будет закрытие исходного кода (сейчас делаются все шаги к тому, чтобы простимулировать разработчиков максимально не трогать штатный код) и останутся dll-ки, к которым можно будет писать свои add-оны. Ведь по большому счету никто же не посягает на исходные коды Excel, Word - все ими пользуются и пишут в отдельных случаях макросы (=add-оны).

Контр-пример: Dynamics Enterprise POS поставляется с частично закрытым кодом, и это приносит огромное количество проблем на проектах внедрения, при этом в Modern POS уже открыто все. А мотивы максимально не трогать штатный код могут быть иными: каждый, кто ставил обновления для стандартного приложения Аксапты, видел, как ради копеечного исправления в обновление по зависимостям тянутся тонны других изменений. Накатывать такие исправления неудобно, небезопасно, трудоемко, но логика тут тоже есть: раз имеется зависимость, то изменение одного из компонент "по умолчанию" влияет на все связанные, поэтому изменения должны поставляться общим большим пакетом. Так что и кастомизации, меняющие что-то в штатном коде, должны по зависимостям включать в себя тонны связанного кода. Отсюда - мораль: надо уменьшить число зависимостей и по возможности запретить напрямую менять штатный код, чтобы кастомизации было удобнее, безопаснее и менее трудоемко накатывать.

Цитата:

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

Единственное, в чем пока остается неясность - так это в популяризации Dynamics. Конкуренция все-таки так или иначе на рынке ERP-систем присутствует и с российским менталитетом "мегакалькулятор" может на российском рынке проигрывать либо неконкуретной любимой программе бухгалтера , либо какой-нибудь немецкой программе, в которую легче внести изменения

По-моему, движение в сторону настройки галочками и невозможности менять стандартное приложение (только лепить что-то сбоку) как раз приведет Dynamics AX в сторону того же SAP с его узкими специалистами по отдельным модулям и их бесчисленным настроечным галочкам. Какая уж там настройка через LCS, да еще и силами самих клиентов!

Цитата:

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

Консалтинг здесь будет зарабатывать видимо "ассортиментом решений Microsoft". Т.е. где-то сваять программку на C#, где-то сделать add-on для Dynamics AX/CRM/..., MS Office - в общем - всем понемножку. Опять-таки - партнеры не будут узконаправленными, а будут работать по всей линейке продуктов MS, что снова хорошо ложится в стратегию MS-а в целом

По-моему, нормально зарабатывать, занимаясь всем понемножку, малореально, потому что если будет небольшое число "специалистов широкого профиля", то они глубоко не будут разбираются ни в чем и вынуждены будут конкурировать со "студентами-недоучками", а если будет толпа узких специалистов, то у них будет эпизодическая, очень неравномерная загрузка. Специалист либо должен быть загружен по 8 часов 5 дней в неделю, либо его услуги будут космически дороги, либо он будет прозябать и уйдет в другие технологии/отрасли. А кроме того, вендор вроде как смотрит на ситуацию иначе: вертикальная специализация, а не горизонтальная "всеядность" и затыкание щелей на стыках различных продуктов. В конце концов, клиентам не нужен "ассортимент решений Microsoft", им нужно решение их проблем в их конкретной отрасли за приемлемые деньги, а уж будет ли решение основано на одном монолитном продукте или целом стеке технологий и каких-то микросервисов - дело десятое.

[mazzy]

Цитата:

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

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

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

Идея заглохла из-за того, что очень быстро прошла мода на "мы знаем нашего клиента". После нее стало модно добавлять и развивать функционал. Невзирая ни на что. Так проще получить высокие KPI. А российскому офису дали карт-бланш на разработку. Из-за которой, с свою очередь локализация ax7 выйдет позже всех.

[Alex_KD]

Цитата:

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

Следующим напрашивающимся шагом будет закрытие исходного кода (сейчас делаются все шаги к тому, чтобы простимулировать разработчиков максимально не трогать штатный код)

Сейчас делаются все шаги к тому, чтобы апгрейд был максимально безболезненный.
О закрытии кода никто не говорит.

Смотрите на Customization: Overlayering and extensions
и на Model split

[sukhanchik]

Для начала скажу, что я высказал гипотезу, которая вполне может быть и ошибочна. Собственно - цель высказывания гипотезы и было обсуждение - насколько она жизнеспособна. Я вполне могу и ошибаться. И был бы рад прийти к любому единому пониманию.

Цитата:

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

Т.е. внести изменение в стандартную форму n будет нельзя, но можно будет сделать свою очень похожую форму m с нужным функционалом. Тогда уже проще свою ЕРП писать с домино и куртизанками. Если следовать идее закрытия кода, разве код который хотели закрыть еще не закрыли, есть же много системного кода. А кастомный код и так можно писать только на верхних слоях. Так что логика не понятна.

Не... все гораздо проще. Запрет доступа к исходному коду не означает запрет изменения формы. Давайте вспомним, как нам предлагается изменение таблицы в АХ 7 - исходную таблицу мы не трогаем, но создаем к ней расширение. Таблица одна, но она состоит из исходной таблицы и расширения. Т.е. если в АХ 8 (9, 10, ...) закрыть доступ к исходному коду, но оставить "наружный интерфейс" - то в общем-то ничего не изменится по сравнению с АХ 7. Все также мы будем создавать расширения.
Более того - недавно belugin в теме обсуждения того, что некоторые методы надо было бы сделать не protected / private, а public - писал, что нехорошо смешивать детали реализации с интерфейсом реализации. Из этого следует, что MS не поощряет изменение штатного кода, который в т.ч. скрыт в private-методах.

Цитата:

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

По-моему, в перечисленных системах заложены 3 совершенно разные идеи

• MS Windows - это платформа для запуска приложений, которая, во-первых, сама по себе нафиг никому не нужна, во-вторых, она в целом ряде сценариев избыточна, требуя слишком много ресурсов и внимания для обслуживания самой себя (в т.ч. пресловутого накатывания заплаток и связанных с этим перезагрузок). Последние затеи типа Nano Server доказывают, что там не то что дописывать - в пору выкидывать лишнее.
• MS Office - чудесный пакет, который установлен, наверно, практически у всех, но он реализует сравнительно небольшое число совершенно типовых сценариев использования, стабильных и неизменных на протяжении десятилетий и, кроме прочего, не зависящих от местного законодательства или иных особенностей. Максимум, где-то пишут слева направо, а где-то - справа налево. Как по мне, развитие функционала Ms Office остановилось на версии 2010, дальше пошли рюшечки и портирование на другие платформы.
• А вот Dynamics CRM - отдельная тема...

Контр-пример: Dynamics Enterprise POS поставляется с частично закрытым кодом, и это приносит огромное количество проблем на проектах внедрения, при этом в Modern POS уже открыто все. А мотивы максимально не трогать штатный код могут быть иными: каждый, кто ставил обновления для стандартного приложения Аксапты, видел, как ради копеечного исправления в обновление по зависимостям тянутся тонны других изменений.

По поводу систем: Это смотря с какой стороны смотреть на идеи. Берем Windows и Linux. В Linux код относительно Windows открыт. Вопрос: Какую легче систему апгрейдить? Ответ: Windows, т.к. там просто надо заменить dll-ки, да в реестр внести изменения (я конечно утрирую, но в целом - заменить dll-ки проще, чем исходный код).
Берем Office. Ему условно нет альтернативы (выпускаемые аналогичные пакеты - также с закрытым кодом. Возможно о каком-нибудь Open Office я и не знаю, но если там код открыт - было бы интересно также сравнить). В результате - к Office есть 100500 расширений / надстроек / кирпичиков кода / идей, как его "разнообразить" в работе.
Dynamics CRM - это тоже система, к которой дописываются расширения.

Цитата:

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

Сейчас делаются все шаги к тому, чтобы апгрейд был максимально безболезненный.
О закрытии кода никто не говорит.

"Сегодня делаются все шаги к тому, чтобы все платили реальные тарифы за ЖКХ, РЖД, ... Увеличиваются пособия, чтобы повышение тарифов было максимально безболезненно. О повышении цен в магазинах и разгоне инфляции никто не говорит"
А если серьезно - сейчас делаются все шаги, чтобы разработчикам можно было бы не править исходный код, а можно было бы обходиться расширениями.
И как только MS наберет статистику, что потребности в модификации исходного кода нет - достаточно представить только интефейсы реализации - будет большой соблазн со стороны MS превратить исходный код в dll-ки и поставлять только эти dll-ки. И в этом плане AX превратится в CRM или в Office. Это как необходимость отладки на рабочем приложении. "За последние 15 лет я не сталкивался с необходимостью отладки на рабочем приложении" (с) с конференции. Все говорят, что это моветон и т.д. Но ... не верю я, что никто хотя бы раз не сталкивался с необходимостью посидеть в отладчике на рабочем приложении.

Т.е. сегодня никто не говорит. Может и завтра никто не скажет. Но послезавтра могут и заикнуться. Это же сильно упрощает обновление

[gl00mie]

Цитата:

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

По поводу систем: Это смотря с какой стороны смотреть на идеи. Берем Windows и Linux. В Linux код относительно Windows открыт. Вопрос: Какую легче систему апгрейдить? Ответ: Windows, т.к. там просто надо заменить dll-ки, да в реестр внести изменения (я конечно утрирую, но в целом - заменить dll-ки проще, чем исходный код).

Неправильный ответ: тупой заменой dll-ек мы получим знаменитый виндовый DLL Hell. В Windows легче ставить заплатки за счет поддержки установки side-by-side (SxS), когда в системе одновременно присутствуют разные версии одних и тех же dll-ек (в т.ч. управляемых сборок), необходимые для разных приложений или сервисов. В такой системе, как Аксапта, очевидно, эта аналогия не работает, потому что одновременная работа нескольких версий расчета цен/скидок или разноски журналов никому не нужна - максимум может быть несколько версий презентационной логики.

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

Неправильный ответ: тупой заменой dll-ек мы получим знаменитый виндовый DLL Hell. В Windows легче ставить заплатки за счет поддержки установки side-by-side (SxS), когда в системе одновременно присутствуют разные версии одних и тех же dll-ек (в т.ч. управляемых сборок), необходимые для разных приложений или сервисов. В такой системе, как Аксапта, очевидно, эта аналогия не работает, потому что одновременная работа нескольких версий расчета цен/скидок или разноски журналов никому не нужна - максимум может быть несколько версий презентационной логики.

Ээээ... Я не раскрыл мысль о количестве dll-лек. DLL Hell возникает при большом количестве dll-лек разных версий. Я предполагал, что их будет очень мало - вплоть до одной единственной. В АХ 2012 ведь по сути так оно и есть. Какие бы обновления не выпускались - в конечном счете все равно требуется пересобрать итоговый CIL, т.е. итоговую dll-ку.

Допустим, выпустил MS систему RTM-версии, состоящий из одной мега-dll-ки. Затем решил переделать механизм Dimensions. Переделал - выпустил фикс системы - выпустил эту новую мега-dll-ку. Изменились интерфейсы реализации - партнеры поставили этот апдейт, подкрутили у себя свой код своих расширений в связи с этим; как-то решили проблему обновления данных (вот этот вопрос кстати пока еще слабо проработан. Если приложение без кастомизации - вопросов нет - контрольный список все делает. А если с кастомизацией, то по идее партнеры должны также расширять контрольный список уже своими скриптами - но ... кто это делает в реале?). В результате - все обновились на эту новую мега-dll-ку и все счастливы . Знание исходного кода dll-ки не потребовалось.

Конечно, если dll-лек несколько - то проблемой совместимости нужно озадачиваться. И тут нам приходит на помощь расширения (packages) в АХ 7, которые контролируют зависимость объектов. Т.е. какие-то совсем независимые конструкции можно выделить в отдельные dll-ки, но уж зависимые - никак нельзя.

Цитата:

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

Но мне лично кажется, что пройдут годы, прежде чем такой рефакторинг будет реализован - если вообще будет, потому что приоритеты у вендора и KPI у его сотрудников могут оказаться совершенно иными.

Ну человеческий фактор никто не отменял. Но ... кто до выхода 2012 еще мог подумать, что в АХ 7 клиента Windows выкинут "в топку" и все уйдет в Visual Studio (примеры можно еще попридумывать)? Т.е. тоже казалось - что пройдут годы и все такое... Поэтому - будет на то воля - процесс ускорят. Не будет воли - не ускорят .
Но развитие событий в ключе возможного закрытия исходного кода - я бы не исключал. Безусловно - с кучей оговорок.

В общем - поживем-увидим. Спасибо за интересное обсуждение.

[imir]

Цитата:

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

MS Dynamics CRM
Ведь по большому счету никто же не посягает на исходные коды Excel,

Еще как посягают, просто через сташный геморой с "дизасемблированием" и пересборкой, по крайней мере в шарике так.

[Ivanhoe]

Не вижу принципиальной сложности первести на html клиент или разработку в visual studio.

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