Microsoft have now introduced Dynamics 365, part of it built on the foundation and technology of Dynamics NAV.
Dynamics 365 (Business Edition), even though it shares the entire tech stack from NAV, is a different beast. One of the main advantages of NAV is the “open source” model. Open source in quotes because in reality, partners have only had access to the business logic code in NAV – nothing more. NAV’s strength have been the partners ability to transform the ERP package into specialized solutions for a wide range of industries. From the small simple customization of a report, to the standard go-to solution for a entire industry.
In the center of all this, is the “NAV Developer” (A chameleon with many titles: consultants, architects etc..) who knows how to wield this powerful tool, knows where to change the builtin business logic in NAV to fit new processes and knows how to extend the base system with new methods and data models. The “NAV Developer” have this single tool in his/her toolkit and can wield almost any solution from that.
This is the way it has been since August 1990. For the last 26 years, developers have used incarnations of the same tool and for the last 20 years the environment they have worked within have looked almost the same (the first 6 year was in the character based Navision 3.XX).
In a hosted cloud environment, Microsoft cannot have 1000’s of NAV Developers adding code in random places, while trying make sure that in this multi-tenant setup, a single tenant cannot bring others tenants down with funky code and at the same time, making sure that the system is fully upgradable.
So “Extensions” where born, as a way to add a modification to a single tenant, without messing with the base system, and with the ability to isolate a modification.
With NAV2016 we got the first incarnation of Extensions, a simple way to modify the system and comply to the requirements of the cloud. The NAV2016 extensions, from my point of view, was a proof-of-concept, that extensions could work, but not really usable due to missing object types, no way to setup non-tenant kept information, missing debugging functionality and a unclear model for “inter-extension” interaction. But still a proof-on-concept, it was possible to extend the system without modifying the base system.
In NAV2017 the extension model from 2016 was completed with support for missing objects and some of the other shortcomings. Extensions are now live in Project Madeira, aka. Dynamics 365 Business Edition.
So now extensions are real, and the only way to get modifications, or perhaps we should call them add-ons, to Dynamics 365. Because we cannot just modify D365, the only way forward is add-ons (in the technical form of extensions). But we can make good add-ons, get them certified and sell them in AppSource.
AppSource is the new marketplace where extensions for Dynamics products are sold. If you are a Dynamics 365 customer, this is a comparable process to buying an App for a phone, find it in the store and install directly.
This will represent a change in the way that a NAV Developer has to look at his job. Some will look upon this as a treat, will all the existing NAV customers migrate over to Dynamics 365 and leave the old-fasion NAV developer behind? Or will the existing OnPrem customers stay with the product we have today?
Microsoft have tried to be very clear on this. They have an “AND” strategy, both OnPrem and the cloud. The confusing part, right now, is that NAV2017 and Dynamics 365 share so much code and functionality, that it can be hard to set them apart. To make it even more confusing, NAV2017 is going to be shipped with a handful of extensions, the same extensions that are available for Dynamics 365.
NAV2017 and Dynamics 365 are however two different things, two different market strategies and cater to two different customer types. I’m pretty sure, that Dynamics 365 will take some of the current sales of NAV2017, but that will be the entry level customers that never get any modifications inside NAV anyway, they will surely be better served by Dynamics 365.
So what is the future for the current NAV Developers and NAV businesses?
For starter, you can pretend that nothing has changed, continue to sell OnPrem NAV2017, continue to develop custom solutions like we have done for the last 26 years, it is all possible with NAV2017, Dynamics 365 does not change any of this.
You can also begin to look at the possibilities that Dynamics 365 offers a NAV Developer. You already know the application, you know specific industries and you have spend multiple years being an expert in implementing customers processes and wishes into NAV.
Take all that knowledge, and get it into AppSource, figure out, how you can transform your industry insider knowledge into something that can be sold on AppSource. Start small, look at the pieces in your solution, figure out if smaller parts can be standalone extensions that can be sold to a larger audience.
Here is the big change, you have to approach design differently when the entire NAV application is no longer your canvas. You cannot just modify any piece of code, those days are over (Even in OnPrem that should never be done).
- You must use events.
- You must design your solution around core NAV instead of modifying the guts of NAV.
- You must use external web services to handle stuff where you normally would use the DotNet framework
- You must preserve NAV’s way of doing business
This might require some rethinking, but hey, that’s what you’re good at, right?
I think the future is bright for NAV Developers, lots of new possibilities are coming with Dynamics 365. NAV have moved even closer into the core offerings from Microsoft and will continue to receive even more attention. And remember, what we’re seeing right now, is not the end, it’s the beginning of something new.
See you out there!
