Writing sustainable Code in AX Part I

I have long wanted to post something on this subject as it is the most often repeated question from customers.

There are two main schools of thought :

1. Do as little development as possible, and stick to the standard functionality.

2. Start adapting Dynamics Ax as needed.

The first options seems to be the most intuitively correct option, there is only one issue with this option, that is that Ax in it's standard inception is not well suited to almost any business that is contemplating implementing Ax.

I have participated in a large number of implementations of Ax and have only ever seen one succesfully toe the line, and that is the reference customer that Damgaard used to use in Denmark that is situated in very close proximity to the development center. Where the management had decided to follow the line in order to be beta customer all along the line, and have done so AFAIK to this day.

Aside from this one customer I have not met any that have really toed the line in this respect though most actually profess wanting to do so, but as the product is designed to be built on rather than be followed it is hard to do so.

If you want to use an analogy that is easy to understand both Dynamics Nav and Dynamics Ax are a bit like another famous Danish product which some of us have played with in our infancy, Lego. Both systems have been built to be modified, they provide the basic building blocks and trace a map of what the business processes could be like, a set of building instructions if you like and thereafter you are given the opportunity to adapt this map to your business.

If you take most other systems they are more built along the lines of a prefabricated model train track set, you can choose at each intersection which way to send the train but you cannot change easily where the interchanges are nor what they govern. I will name no names ;-). And if you want to change your track layout you have to start major civil works in order to adapt the wanted layout to the landscape, and in most cases that has consequences further down the line.

In my view after having worked with both Dynamics Ax, Dynamics Nav, XAL, and other predecessors for over 20 years, it is best not to do either.

Option 1 of doing no dev negates the competitive advantage provided by the fact of choosing a flexible ERP system designed to be flexible, option 2 of doing all kinds of development as required usually winds up in excessive upgrade costs.

The art of being a good implementer of this product lies then in balancing the two options just right in order to acheive an implementation that is as I called it in the title sustainable.

I have been trying to establish a set of guidelines in this regard the problem is of course that as with any good compromise it should be flexible and adapted to the situation.

As an example, in general terms it is not good to change the central data model in the application as those kind of changes may necessitate extensive work in the future during upgrades. However take the case of a medicinal company that needs extensive tracking and needs to use its inventory in a very specific sequence and to transfer Use by date information throughout. In their case not making changes to the central data model is stupid as the changes necessary can be handled much more easily by doing so than by not doing so.

There are off course many such examples, anyhow I have to get back to my day job I will detail more in my next posting on the subject. And look forward to any comments.


/Sven