Вот мы и нашли этих 43 AX7 клиентов? Или это не AX7/D365?

[fed]

Предположу, что очень скоро, чуваки которые придумали extensions и model lock с удивлением узнают что попытка залочить прикладные модели выносит с рынка 90% вертикальных решений и 99% внедрений.
Ну то есть - это они в правильную сторону двигаются, только им надо было СНАЧАЛА очень капитально подумать на тему какого фундаментального функционала не хватает в прикладном ядре (ну например - absorption costing, или какого-то расширяемого API для распределения себестоимости сопродуктов), потом этот функционал написать, потом поставить там в правильных местах возможность расширений и только потом уже двигать в народные массы свою extension story. Но похоже что команда, которая за ядро и среду разработки отвечает - она совсем не в курсе состояния дел в прикладном функционале и вообще практик внедрения...

[mazzy]

Цитата:

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

Предположу, что очень скоро, чуваки которые придумали extensions и model lock с удивлением узнают что попытка залочить прикладные модели выносит с рынка 90% вертикальных решений и 99% внедрений.

нет, конечно.

extensions = plugins. подход отлично работает в огромном числе продуктов.
этот форум работает с плагинами, far, notepad++, vim, visual studio и т.п...

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

[gl00mie]

Цитата:

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

extensions = plugins. подход отлично работает в огромном числе продуктов.
этот форум работает с плагинами, far, notepad++, vim, visual studio и т.п...

Подход отлично работает в тех продуктах, которые изначально разрабатывались с учетом использования плагинов, и то... Какой-нить ePOS в R2 из-за своих зацементированных в ядре интерфейсов для простейших случаев позволяет писать плагины, а чуть что сложнее - уже всё: либо отказывайся от своей затеи, либо декомпилируй и пересобирай ядро.

Цитата:

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

Цитата:

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

они в правильную сторону двигаются, только им надо было СНАЧАЛА очень капитально подумать на тему какого фундаментального функционала не хватает в прикладном ядре, потом этот функционал написать, потом поставить там в правильных местах возможность расширений и только потом уже двигать в народные массы свою extension story.

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

У меня лично ощущение, что эти два сообщения - об одном и том же.

Цитата:

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

Цитата:

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

Предположу, что очень скоро, чуваки которые придумали extensions и model lock с удивлением узнают что попытка залочить прикладные модели выносит с рынка 90% вертикальных решений и 99% внедрений.

нет, конечно.

Если ставить телегу впереди лошади и закручивать гайки прежде, чем предусмотреть специальные точки расширения прикладной логики, то - да, конечно

[fed]

Цитата:

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

нет, конечно.

extensions = plugins. подход отлично работает в огромном числе продуктов.
этот форум работает с плагинами, far, notepad++, vim, visual studio и т.п...

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

Да - какая-то часть вертикальных решений на рынке - это по факту плагины. Живет себе какое-то решение для рисования диаграм ганта или архива документов, живет в отдельных классах и со всем остальным интегрируется на уровне 10-20-30 строчек, вставленных в какие-то стандартные методы и опять-таки - 10-20-30 новых полей, вставленных в стандартные таблицы. Вполне могу поверить, что такие решения можно перевести на механизм extensions.
Тем не менее - если мы говорим о рынке отраслевых вертикальных решений (независимо от того - это действительно отчуждаемые вертикальные решения или просто коллекции наработок) - большая часть из них была построена на идее перекрытия стандартной функциональности. Причем как ты очень хорошо понимаешь, делалось это не по злой воле внедренцев, а просто в связи с отсутствием в стандарте кучи функциональности, типичной для данной отрасли.
Теперь рассмотрим дальнейшие действия микрософт:
1. Они могут закрыть overlayering как класс (возможно - от балды навставлял точек расширения в стандартные прикладные классы). В этом случае, на первых же проектах, по итогам анализа партнеры начнут сообщать клиентам о том что в новой версии их бизнес-процессы не представляется возможным покрыть; Возможность серьезной доработки отрублена, а стандартной фунции для данного процесса - нету. После этого клиент с большой вероятностью бодро откажется от подписки на D365, спишет затраты на анализ в убытки и пойдет внедрять САП. Действительно - преимущество облачных технологий - можно в любой момент остановить проект, списав в убытки только небольшие понесенные затраты. Ну и партнеры само собой будут тоже плавно мигрировать в САП. Ведь если разработка по факту запрещена, то лучше использовать систему с более богатым базовым функционалом.
2. Они могут оставить overlayering. Но только в этом случае - у обычных партнеров (не тех кто плагины пишет), сразу возникнет вопрос: А зачем нам вообще париться с extensions ? Все равно большая часть нашего функционала в них не укладывается, и все равно после апгрейда приходится мерджится. А после этого встанет другой вопрос - а если все равно приходится мерджится, то зачем они платформенные модели заблокировали ? Зачем табу на overlayering объявляли ?

[mazzy]

Цитата:

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

///живет в отдельных классах и со всем остальным интегрируется на уровне 10-20-30 строчек, вставленных в какие-то стандартные методы и опять-таки - 10-20-30 новых полей, вставленных в стандартные таблицы...

ну... мне кажется, что ты упускаешь одну главную вещь:

с точки зрения Майкрософт, Dynamics - это 5 (пять) разных продуктов.
это не одна аксапта, а 5 (пять) продуктов.
все из них имеют дублирующий функционал - расчет налогов, печать документов и т.п.

и с точки зрения любого руководителя в Майкрософт, затраты на почти любое телодвижение в dynamics нужно тут же умножать минимум на 5.

собственно, как мне кажется, отсюда и растут всевозможные extensions и прочие микросервисы.

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

но я не вижу другого вменяемого способа эволюционно что-то сделать в этой ситуации.

опять же! вспомни изменения в интерфейсе. Для некоторых продуктов (в частности для Аксапты) новый интерфейс - дичайший даунгрейд. а для остальных - норм. Зато теперь без специальных усилий не отличить один продукт от другого по внешнему виду. См. Dynamics 365. Без суффикса.

и я полностью согласен с твоей мыслью:

Цитата:

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

только им надо было СНАЧАЛА очень капитально подумать

но также хотел бы вспомнить и процитировать (квадратик - ссылка на оригинальное сообщение):

Цитата:

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

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

Цитата:

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

Сейчас в Майкрософте тоже происходит переключение.
Они сами называют его "цифровой трансформацией"
а у всех остальных называется "переход от монолитного приложения к микросервисам".

Причем про переход от монолита к микросервисам написано очень много.
Майкрософт наступает почти на все грабли, описанные в методических материалах про этот переход.
Майкрософт наступает даже на грабли описанные Джоэлем Спольски в далекие времена зарождения МС Офиса и победы над Lotus 1-2-3...
типично: http://russian.joelonsoftware.com/Ar...LetterIII.html, только нужно перевести не с конкурирующего продукта как в статье, а со своего на свой.

и эта "цифровая трансформация" происходит не только в россии. а по всему миру. И не только с Dynamics продуктами.

Применительно к Dynamics, в принципе, они задумали очень правильные вещи:
= выделить в микросервис расчет потребностей в ТМЦ
= выделить в микросервис расчет денежного покрытия и оценку CashFlow
= выделить в микросервис расчет налогов по законодетельствам разных стран
= выделить в микросервис финансы так, чтобы можно было нанимать внешние компании, которые ведут бухучет
= конечно же выделить в отдельный сервис CRM
= и т.п.

[Logger]

Цитата:

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

Да - какая-то часть вертикальных решений на рынке - это по факту плагины. Живет себе какое-то решение для рисования диаграм ганта или архива документов, живет в отдельных классах и со всем остальным интегрируется на уровне 10-20-30 строчек, вставленных в какие-то стандартные методы и опять-таки - 10-20-30 новых полей, вставленных в стандартные таблицы. Вполне могу поверить, что такие решения можно перевести на механизм extensions.
Тем не менее - если мы говорим о рынке отраслевых вертикальных решений (независимо от того - это действительно отчуждаемые вертикальные решения или просто коллекции наработок) - большая часть из них была построена на идее перекрытия стандартной функциональности. Причем как ты очень хорошо понимаешь, делалось это не по злой воле внедренцев, а просто в связи с отсутствием в стандарте кучи функциональности, типичной для данной отрасли.
Теперь рассмотрим дальнейшие действия микрософт:
1. Они могут закрыть overlayering как класс (возможно - от балды навставлял точек расширения в стандартные прикладные классы). В этом случае, на первых же проектах, по итогам анализа партнеры начнут сообщать клиентам о том что в новой версии их бизнес-процессы не представляется возможным покрыть; Возможность серьезной доработки отрублена, а стандартной фунции для данного процесса - нету. После этого клиент с большой вероятностью бодро откажется от подписки на D365, спишет затраты на анализ в убытки и пойдет внедрять САП. Действительно - преимущество облачных технологий - можно в любой момент остановить проект, списав в убытки только небольшие понесенные затраты. Ну и партнеры само собой будут тоже плавно мигрировать в САП. Ведь если разработка по факту запрещена, то лучше использовать систему с более богатым базовым функционалом.
2. Они могут оставить overlayering. Но только в этом случае - у обычных партнеров (не тех кто плагины пишет), сразу возникнет вопрос: А зачем нам вообще париться с extensions ? Все равно большая часть нашего функционала в них не укладывается, и все равно после апгрейда приходится мерджится. А после этого встанет другой вопрос - а если все равно приходится мерджится, то зачем они платформенные модели заблокировали ? Зачем табу на overlayering объявляли ?

Цитата:

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

Ну похоже что все-таки MS продавили на выпуск чисто on-premise версии (даже не гибридной). И после того как ее продажи пойдут, MS с интересом обнаружит что Azure версия используется в основном для прототипирования и предпродаж (генеря жалкие единицы процентов от выручки). После этого им придется сильно откорректировать свои планы
Я в целом могу поверить что HTML-интерфейс они через пару релизов доведут. Но вот как внедряться, когда каждый разработчик должен кодить и отлаживаться в своей виртуалке и релиз требует остановки сервера - я пока не очень понимаю. (Хотя может народ и привыкнет).
Ну то есть - меня в ax7 напрягает две вещи:
1. Облако. Точнее не облако как таковое, а отсутствие у партнеров и клиентов доступа к инфраструктуре. Дайте мне терминальный доступ к Аксаптовскому серверу в Azure, дайте внедрить, и после того как все внедрено, я даже готов отдать это микрософтовской поддержке (если им так уж хочется).
2. Пугают попытки лочить модели. Причем пугает не то что уже сейчас залочили, а то что могут этот механизм использовать для блокирования прикладных объектов (как бы безумно это не звучало для любого внедренца).
С 1ым пунктом, похоже что микрософт уже понял что пролетел, теперь еще осталось помножить на ноль их блокировки моделей...

Вот недавно попалось интервью Джеффри Сновера
https://habrahabr.ru/article/318462/

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