When working with Extensions I would not recommend working with Xliff files unless you design for AppSource. Otherwise CaptionML will work fine for Per-Tenant projects.
Unfortunately for me, I am... (Continue reading)

Let’s start diving into working with Extensions in Real Life. I have a lot to blog about and at first I thought I would blog about a very small extension but I’m sure you’ve all seen that.
Let’s start... (Continue reading)

A little over a week ago I attended the Dutch Dynamics Community again, for the first time in a while. It was good to catch up and exchange news with peers in my network.
“You’ve been quiet Mark!” is... (Continue reading)

Red and Bundle
As you know we have been happily developing extensions for a while now. Every once in a while I blog about some stuff I found out recently but it is mostly smooth sailing at the moment... (Continue reading)

Today I wanted to extend a Role Center with a Page Extension and I noticed Microsoft has updated terminology.
HomeItems = Embedding
To add a list to the Home Items you must use Embedding.
Other... (Continue reading)

Is Microsoft Dynamics 365 Business Central the Navision Road to the Future?

Yes! The short answer is yes and if you don’t care about details you can close the browser window or delete the email.

I’ll elaborate on the Yes, but there is also a “Yes, but not if…” that I will share with you.

Why Yes?

ERP is dead and there is a good reason why Microsoft has chosen to change the positioning of the NAV product. The name Business Center is a brilliant name.

I’ve been working with NAV for more than 20 years. As long as I remember upgrading has always been hard. Microsoft has also acknowledged this and came up with a couple of solutions of which the most important one is Extensions.

It’s a mistake to think that Extensions is the solution to upgrade problems. From an engineering perspective it might be a solution to eliminate the challenge of merging source codes. It does however introduce a new challenge that in my opinion is overlooked completely by the NAV team. It creates dependencies and makes it much harder for the NAV team to change the architecture of the product.

In the object-oriented world they realized a long time ago that creating dependencies is wrong and it’s one of the reasons Dependency Inversion is so important. AL, the programming language for Extensions for Business Central is not object oriented and I’ll discuss that in the “Yes, but not if” part of this article.

If you spend most of your time at end users instead of developing software in a basement you’ll realize that upgrades are hard because of the fundamental principle of ERP. Everyone in the company is using the same system. Therefor if you upgrade everyone in the company has to use a new system. This is very hard to manage, especially if you have multiple locations.

We invented ERP in the 1980ies because exchanging data was very hard. The internet was not yet public property and where data was exchanged it was asynchronous and you always had to try and catch exceptions if both software’s had changed the same records.

As Michael Nielsen said in our NAV TechDays presentation, this problem has never been solved and will never be solved.

To make upgrades easier again we must go back to decoupled solutions that share the same data-source. For Microsoft that will be the Common Data Model with Common Data Services. You can build any solution on top of that and it means that every department in your organization can upgrade their subsystem at any given point in time. The business applications are decoupled from the data storage so the data storage can also be replaced at any time as long as the interface is respected. This makes it easy to move back and forth from on-premise to cloud and hybrid.

The solution to easy upgrades is not extensions, it’s the API that Microsoft introduced in beta with NAV 2018. It’s a wonderful piece of engineering that I immediately decided to embrace and have running in a real-life scenario.

The current generation of CFO’s and CIO’s might be somewhat conservative but as soon as millennials take over we will see increased adoption of this technology.

Personally, I am part of the intermediate generation. Being born in 1976 I am old enough to have seen color TV, cassette tapes and VCR change the way we live, yet I am young enough to have internet and email since my second job. (I started working when I was 18.)

With a solid API and Extension model Microsoft Dynamics 365 Business Central is ready for this new generation of business decision makes. If Microsoft decides to close access to the (NAV) source code it will allow them to start cleaning up their legacy code much faster or maybe just replace it all together with something new. As long as the API and Extension model is respected Microsoft can do whatever they want. Who cares.

I remember vividly that the final conclusion we had with the Partner Ready Software initiative that in a cloud world clean code is no longer important. As long as your API is stable and Dependency Inversion is respected clean code is only important for the team writing the software, but no longer for the connecting ecosystem.

After that we broke up, got into a huge fight and I founded NAV Skills to continue evangelizing clean code principles as I believe they are fundamental for the success of a software solution.

The API will be the reason of the succes of Business Central. Not Extensions.

This concludes the Yes part and here we can start on the “But…” section which is quite a bit more uglier to read and I am probably not going to make a lot of new friends writing it.