Dynamics NAV, a beautiful structure
This topic has the danger of becoming an overly technical one, so I will attempt in this blog post to focus on the benefits from a high level design perspective. Hopefully everyone can understand why structure is so important.
In my math days I was fascinated with the topic of abstract algebra. A lot of that subject has to do with the structure of things. For example abstract algebra could attempt to describe the possible variations of a snowflakes and crystals. Many of the results are very beautiful and reminds us that mathematics and art can be very close subjects.
When we look at a software system as big as a regular ERP, it does have a clearly defined structure. If you are a technical person who has worked with the system for a while, you will soon realize whether the structure is nice to work with or not.
As a user you might be able to go on with your daily activities whether the structure is bad or not. It comes into play when the system needs to be modified. A poorly structured system is going to be hard to change and will pose a high risk of behaving abnormally. In a well-designed system, the modification will seem natural and flow right with the rest of the system. Dynamics NAV has an excellent structure and it is the reason why still today I find it very rewarding to work with. The structure has remained similar since its original version. It has been evolved through modern technology and the structure extended with functionality, but the core structural principles have always remained intact.
Dynamics NAV goes even so far as to preserve the elegant structure at the cost of the user experience. For example, on a sales order we have the field “document no.” and “external document no.” The “document no.” refers to the sales order number, but the “external document no.” refers to the customer’s purchase order number. So why not call it customer’s purchase order number? The reason is because the designers of the system were adamant about maintaining the structure as abstract and symmetrical. Once the user gets it, then learning the rest of the system becomes easier and things seem to make sense, wherever they are. Basically, “external document no.” works on pretty much all documents. Sales Order, Purchase Order, Sales Cr. Memo, Sales Return Order, and most other documents all have external document number. The meaning is different based on context. That’s an example of an abstraction.
You can also find nice symmetry. For example if you turn the sales process around, you get the purchase process. Almost all functions of the sales process can be inversed to get the purchase functions. The code and the structure behind it is setup in a similar fashion. The sales and purchase process hangs together by the things being traded, such as inventory, resources, etc. If you look closely, you will see that NAV replicates symmetry almost everywhere, except in the resources. You can sell resources but not buy them. The idea is that the definition of a resource is something the company owns and is paid for through expenses or fixed assets. However, if you want to extend the system to allow purchasing of resources, generating the code is extremely natural, since the symmetry is clear on all aspects.
People often talk about some systems being easier to modify than others. I think this is often mistakenly attributed to the programming language being easy or the programmer has access to more tools. The reality often is that the system is basically better designed, which therefore makes it easier to work with and modify.
Consultants working in the field have to understand this structure and leverage that it is there. Not doing your homework on the structure, is like driving a Ferrari and never getting out of first gear.