The future of Dynamics AX - part II

This is the second part of my blogpost regarding the future of Dynamics AX.

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. 

Some cons:

• 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)

As the solution grows in size and complexity it has to be questioned whether the pros outweighs the cons or vice versa.

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. 

The future of Dynamics AX?

As I am getting ready for my vacation later this week I decided to invest a bit of time starting up my blog again.

For those who may have read some of my previuos blog posts through my employment at Microsoft, TIA and ScanJour, this time around I will try to take a broader and more personal approach to blogging.

Although I am now in a position as Head of Product Development at EG A/S this blog will represent my personal opinions and viewpoints. I will still try concentrate on the professional aspects of my job and life (all the rest I guess is more appropriate for Facebook...)

For this first post I am asking a fairly broad question which I think is highly interesting these days. I will not claim to know a lot about all of the ERP's of this world, my primary experience being with Dynamics AX. However, I do think the future of Dynamics AX the coming few years are about to change significantly. Obviuosly - it's hard to try predict the future. Accidently, I stumbled across an artice from 2009, which claimed that the traditional ERP approach is dead (http://www.infoworld.com/d/applications/future-erp-why-big-erp-approach-dead-047).

For all of us working with ERP, we know the last 4 years have shown that it was hardly the truth - so what will be different the next 4 years? Well, I do not believe ERP will be dead, but I do believe the business model around implementing and deploying ERP systems will change significantly. I have three claims which I believe support this,

First claim: Customization is going away

Ouch - being employed at a company which makes it's living partly by implementing and customizing ERP's this is a tough thing to realize. And of course this will not happen tomorrow. But it is my true believe that the level of customization which have happened to ERP's such as Dynamics AX over the last decade will vanish during the next decade.

Reasons:

• Standardization
  Dynamics AX now contains so much functionality that enough is enough. Most companies could choose to "live" with the standard solution and instead get the benefits of continuous improvements without the upgrade nightmare.
• Accessibility
  In order for the systems to be accessible across geographies and different user groups (roles) the architecture of Dynamics AX need to be changed drastically. The three-tier architecture implemented in the beginning of the 00's is not how you would do it today. The best way to achieve this is making the functionality available through a thin client web based experience. The optimal way to achieve this is a cloud based deployment. Microsoft is probably working on this already, and it will mean a lot to the customization capabilities of the solution (as in "they will not be there")
• Competencies
  It is my impression that the average age of people working with Dynamics AX implementations are increasing. Or in other words, those who have worked with this product since we invented it in the mid 90's will continue, but what is the incentive for young people to enter the business? I predict that there will be a significant lack of AX skilled resources in the near future. Simply because the original technology of AX is begining to show sign of age.
• Cost reductions
  Companies are beginning to realize that having their own iron in the basement and the people above them to service it may not be sufficiently cost efficient. Especially in the mid-market it is problematic for companies to keep staff with the competencies needed to support the traditional on-premise solutions. Thus, solutions will slowly move to the cloud.
• Upgrades are becoming too costly
  As Microsoft continues to speed up the release cycles and amount of innovation put into the solution, it's getting harder and harder to keep up for partners and customers. The trick will be to isolate customizations as much as possible from the standard solution in order to upgrade them swiftly at a low cost. This means customizations will gradually change into add-on integrations instead only leveraging (more stable) API's.

To be continued in following posts...
Second claim: All-in-one (single instance) is NOT the future
Third claim: Users expect more