Disclaimer: Since I am merely following the evolvement of Dynamics AX from a distance and not part of Microsoft all of this is of course only speculation in relation to the market of ERP and line of business applications.
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 years there has been some expections to this, for instance the use of Reporting Services for reports, Windows WF for workflow and other core Microsoft tecknologies, 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 in the future. There are certainly a number of pro's and con's,
Some pros:
- 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 seperate 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)
Quality issues?
Even for Microsoft it seems the size of the code base and the business logic and the churn we have seen 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 independant 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 having to go through a big-bang upgrade scenario impacting 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 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 broader footprint the 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...
Module granularity
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.
For solutions like the ones we do in EG Utility we have made a bet that this is what will be happening - and by the way, the right way to go. We are developing Zynergy with standard Microsoft technologies (.net, HTML5/Javascript) based on Windows Azure. We believe this will enable our customers to evolve their mission critical utility solutions separately from Dynamics AX whilst maintaining a close and tight integration. For the same reason I believe that in the future AX will be split up under the hood into smaller independent "modules" or application areas working seamlesssly together. Should you start from scratch building an ERP today I also think this is the way you would do it - since everything anyways 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 pros listed above while gaining from the cons. In my head, even for Microsoft, the benefits of the cons outweighs the cost of ensuring the pros.
