Category Archives: NAV2017

There is a lot of talk about NAV and “Open Source” these days. Lots of the talk is related to the new Extension model that Microsoft Dynamics 365 and Dynamics NAV 2016/2017 shares.

Let’s first get a few definitions in place:

“Open Source” – A piece of software where the source code is available to view and perhaps modify, but the original owner still controls vital aspects of the software.

“Free Software” – A piece of software where the source code is available for anybody to use, modify, give away, do anything you want, apart from taking ownership of the software.

“Object” – Every piece in NAV/365 is an object. That can translate to a table, a UI page, a report or other internal pieces. Each Object has an ID and the NAV/365 license defines access to the Object.

“Business Logic” – The part of NAV that is built with Objects. This is the customer table, the general journal, the sales invoice posting routine.

“Runtime” – The system that actually runs on the computers, the runtime executes the objects and makes it all comes to life.

The source code for the business logic in Dynamics NAV is available for those who has a license to that. There are several levels of source access:

Customers can access partial sources if they have designer access to reports and pages

Customers can access most sources if they have brought the “big” designer license.

Partners have access nearly everything if they have a partner license.

ISVs have access to their own “area” and can decide who (other partners) can access their objects.

That is neither open source or free software. This is privileged access to part of the source code of a closed sourced application. And the privileged is only “given” to the select few that either buy access or through employment at a NAV partner.

So stop calling it Open Source, please 🙂

There are even plenty of NAV pieces that has never been “open sourced” to anybody outside Microsoft. That includes the development environment, the runtime, the different add-ins, add-ons, ADCS, Toolbars, portals etc.

But from a practical perspective, the amount of source code access in NAV has historical been more than enough to give NAV its unique ability to be transformed into 1000s of industry solutions. And this has been a huge factor in making NAV the big success it is today, because, for many years, NAV lacked in functionality but made that up by being customizable.

Looking in from other software development platforms, the first question we are asked is: Why is source code access necessary for this? If we look at DotNet, COM Objects or other ways of building software, customization can be performed without accessing and recompiling the original code?

The answer is found the programming model, NAVs two main issues:

NAV has (until 2016) been missing an extension framework, meaning that there has never been an official way to trigger custom code from the standard application.

NAV does not have an “official” API layer. There is no well defined public interface to NAV processes.

With NAV 2016 we got events that can be used for triggering custom code, and with NAV 2017, we have most of the trigger points that were missing in NAV 2016. Triggers can only be accessed from NAV code; there is no abstract public API layer giving us the ability to trigger NAV business logic from external code. In the old days, we had a library called C/Front which gave us database access to the native database but no business logic, and now we have web service access, but that only give us access to data a limited set of business logic.

So the solution has always been, to dig into the source, and modify NAV to fit the current customer’s requirements.

Wielding this sword has proven a powerful weapon for many NAV developers, a good NAV developer is well traversed in the source of the standard application and can make very cools customizations in a short time frame.

Losing the “Open Source” aspect of NAV, could easily sound as you have to return the sword to Microsoft and be left with a dull little dagger that can’t even glow in the dark when there are orcs around.

But wait? Are you losing anything? Some NAV developers are worried that they will lose the ability to fix bugs in the core product, which in fairness, used to be an awesome power often wielded ten years ago. But with the rapid CU’ing going on, most bugs that I have discovered turned out to be fixed already looking at the latest CU’s change log or they turned out to be bugs in the runtime environment that I never had access to fix anyway.

The current problem with extensions is that they are objects, but do not expose an API, does not give any public interface, they just sit there in the runtime like a ghost. You can’t address them from code in any way. But the new development environment shown at Directions seems to solve this. I cannot wait for the preview at Christmas!

So, going to a “closed source, open model” world, what do I need to serve my customers?

I need access to view and address the model, the same we today can view and reference the public interface of a .NET assembly.
I need a way to modify the standard application behavior, adjust the UI, update the database schema and add my own business logic.

As part of the change log for the Microsoft Dynamics NAV Windows Phone client a small, but important message, has surfaced:

NOTIFICATION: With the introduction of Windows 10 Mobile, we will be discontinuing support for Windows Phone 8.1 in an upcoming update during early 2017.

Is this a problem? It could be. I’m certain Microsoft has some telemetry to back up their decision, but many businesses are using Windows Phones, and several models did not get the Windows 10 Mobile update, the Lumia 1020 is just one examples of phones that are left on Windows Phone 8.1

Is this a good thing? Hopefully, because NAV support on Windows 10 Mobile for Continuum is still lacking, and at present, that is the (single) biggest feature on Windows 10 Mobile, the feature that the entire platform is riding on. And having a Microsoft core offering not supporting it, is “less” than optimal.

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.