Prediction for Dynamics AX: All-in-One (single instance) is NOT the Future
This is the second post in my series regarding the future of Dynamics AX.
The first post can be found here: Prediction For the Future of Dynamics AX: Customization Is Going Away
My second claim: All-in-one (single instance) is NOT the future
For the last 15 years (at least) Dynamics AX has evolved under the mantra “all-in-one” – meaning that all functionality was built in the same codebase and exposed in the same rich client (enterprise portal excluded). Over the last few years there have been some exceptions to this; for instance, the use of Reporting Services for reports, Windows WF for workflow and other core Microsoft technologies, but overall AX is still built as a single ERP with a single codebase on a single database on a single release schedule.
The question is whether this all-in-one approach makes sense for the future. There are certainly a number of pro’s and con’s.
- consistency and quality across application functionality
- predictable release cycle
- known and consistent technology framework
- developer productivity
- consistent user experience.
- unable to release and have customer adoption for new features fast enough
- unable to leverage new technology advances and platforms fast enough (e.g. cloud deployment)
- unable to have separate release cycles for different parts of the solution
- quality issues due to too many ripple effects across the application area
- difficulties keeping the technology platform “fresh” (think MorphX versus TFS)
As the solution grows in size and complexity, the question has to be whether the pro’s outweighs the con’s or vice versa.
Even for Microsoft it seems the size of the code base and business logic and the turn they have taken is impacting their ability to deliver the right quality at the right time. I think the AX 2012 release showed that it has been difficult for them to ensure the right level of quality in all aspects. I am wondering if this could have been managed better had the solution not been all-in-one but a number of independent solutions working together through well-defined API’s. At least, then, customers would have the option of gradually migrating to new versions for part of the suite and not have to go through a big-bang upgrade scenario which impacts on all of their business.
In my current role as head of product development, I am responsible for a (BIG) add-on solution for the Uility business built on AX 2009. What I hear from some customers is a wish to be able to take advantage of new features in different parts of the application at different times. Or in other words, if a Production Manager wants new features in the Production application the CFO may not be interested in upgrading the Financial application – or vice versa. The bigger an ERP solution gets, the bigger the problem. With the current all-in-one solution the entire company has to agree on upgrading to get new features…
I think a better approach for the future is smaller independent application areas capable of being upgraded independently on separate release schedules. I believe it will be very hard but not impossible to achieve this with Dynamics AX. My guess is that Microsoft is heading in this direction – but if so – the end result won’t be the Dynamics AX we know today.
Should you start from scratch building an ERP today, I also think this is the way you would do it – since everything would be built for the cloud there is no way you would want to have to upgrade everything at the same time.
The trick will be not to lose the pro’s listed above while gaining from the con’s. In my head, even for Microsoft, the benefits of the con’s outweighs the cost of ensuring the pro’s.
Source: Flemming Louw-Reimer
Disclaimer: Since I am merely following the evolution of Dynamics AX from a distance and I am not part of Microsoft, all of this is, of course, only speculation in relation to the market of ERP and line of business applications.