About upcoming future of Dynamics NAV

Hello Friends,

I want to share something interesting about Dynamics NAV future and our role in upcoming year.

Microsoft is preparing two new product releases related to Dynamics NAV in late 2016: NAV 2017 and the Financials portion of Dynamics 365 for Business (that's the SMB option, currently in preview as Project Madeira). The two products will offer similar financial management capabilities, based on core NAV, but they will also differ in many ways, from pricing and licensing to deployment options to depth of functionality.

NAV 2017 and Dynamics 365 Business Financials will also share another important detail: their support for the extensions framework. For Dynamics 365, which is a pure SaaS offering, extensions will be the only way to add custom capabilities. But for NAV 2017, which carries forward legacy customization options, the growing focus on extensions is shaking up the partner ecosystem as the community debates the business and technical implications, as well as what the shift in focus will mean for the product's future competiveness.

Extensions are "the current hot topic/disagreement in the NAV world," says James Crowter, a Microsoft MVP and managing director of Technology Management, a UK-based Microsoft partner (who answered questions for MSDW via email). In a recent blog post, he explored reasons why extensions mark a turning point in NAV's history, including how they will move the product past its legacy licensing model that has hobbled the product, its partners, and its customers in recent years.

Partners get familiar extensions

As we reported in May, Microsoft is advising developers that its extensions framework will eventually become the predominant way to deliver approved add-ons and customizations.

With extensions, the developer doesn't modify Dynamics NAV code. Instead, the extension hooks into NAV or Dynamics 365 in standard ways. Data is passed to the extension, which can then manipulate it and pass it back. The model is dependent on the events and triggers Microsoft has provided. Once an extension is published to a server, it can be made available to one or more NAV tenants with a bit of PowerShell code.

With the autumn 2016 conference season nearing, some Dynamics NAV experts are now sharing their views on the latest guidance on extensions and its impact on the products. Crowter wrote in his recent blog post:

"Now our experience is that, almost anything is possible in an extension once you get your head around how you can use even just the system events that are already there. Its takes a different thought process and might result in more lines of code than if you had just inserted in the standard object, but the upside is a level of upgradability and portability that is the utopia we've been longing for.

What is clear is that zero impact to standard objects should become the standard default way of working."

Microsoft MVP and veteran NAV developer and trainer Mark Brummel, has also been sharing his thoughts on extensions and his broader outlook on the future of NAV in relation to Dynamics 365. His writings suggest a sense of resignation that NAV's momentum is waning, with Microsoft transferring its energy to Dynamics 365. He wrote last week:

"NAV lives because of this shared platform but Microsoft invests in it because of Dynamics 365, not because they believe in NAV. We simply don't grow fast enough."

Upgrade impact

On upgrades, Brummel has already outlined reasons why extensions are not a silver bullet. He offers "four reasons why extensions are not going to make upgrade easier," that include a range of scenarios where committing to an extension in one version of NAV will create headaches later on.

"I don't see how Microsoft can have every ISV move to extensions only. I think extensions are only good for smaller add-ons, where you get only the delivered features, and people can live with it," he wrote later in the comments in response to readers.

Crowter also acknowledges the potential limitations of this model. He told us:

"Don't get me wrong, it has the potential to cause all sort of issues from a data integrity and support perspective. Where I as a partner could restrict the range of add-ons my support team are asked about, that's not going to be as easy in the future. Even after it's uninstalled, what damage might it have done to my key data and how can that be repaired?"

The future of customizing and extending NAV

We know from blog posts and from discussions with ISVs that the roll-out of solutions built on the extensions framework is well underway. Early participants have had to agree to strict R&D deadlines and commitments - and NDAs.

Microsoft wants to begin offering sophisticated ISV solutions with extensions - not just light functions - in time for both the Dynamics 365 and NAV 2017 releases. The goal is to show customers, partners, and the larger SMB ERP marketplace that this model is right for both products' futures.

To paraphrase a manager at one ISV that has been an early adopter, extensions are "definitely the way forward" with regard to the cloud. Microsoft expects the approach will standardize solutions and boost interoperability.

And while the extensions model creates closed solutions, there is at least one project underway to existing NAV customers using traditional NAV customization techniques (in which the source code is available). Microsoft MVP Erik Hougaard introduced the NAVY package manager (the name is a play on "NAVX", Microsoft's name for the official extensions framework) in late 2015 as an alternative to extensions. While it is not intended for production use, it appears to have caught the interest other NAV experts and could see continued community development.

A new and customer-friendly licensing scheme

Crowter argues that NAV's antiquated licensing scheme, which has focused on an add-on's access to NAV objects, has frequently curtailed the efforts of customers and partners that wanted to deploy add-ons. Just getting to the point of testing an ISV solution for NAV today, he explains, is a slow and potentially expensive process with many authorization steps, manual interventions, and negotiations between customer, VAR, and ISV.

Extensions, he believes, will address this headache by decoupling custom features from the object model once and for all. Directing his argument at those who don't yet believe in the extensions model, he wrote:

"I'm also betting that you don't understand that the average end user is frustrated with both the cost and process of getting a developer to customize their system for them and don't believe they will prefer to pick a standard app from a list that they can install in their test company and try out in minutes.

"It hasn't even crossed your mind that the fact they can uninstall the extension as easily as they installed it is going to make them much more willing to try it out? What's the risk if they can try it on their test system first and uninstall it in seconds?"

But Brummel cautions extensions will not address the needs of traditional NAV customers who, he says, do not want cookie-cutter software:

"The way Dynamics 365 is shipping will make extensions work. It's a long story and worth another blog but the combination works. Problem is that Dynamics 365 is serving a different kind of customer. Not the type of customer with a request for bespoke software but a customer that wants an easy cloud solution that has some vertical specific capabilities."

He goes even farther, taking something of a principled stand in favor of traditional NAV customization:

"Let's both be happy that Microsoft is going to let NAV [be] what it is and ignore the marketing messaging around extensions. What I WILL DO! I will tell the end users at NAVUG Summit NOT to accept extensions from their partners. If they run NAV single tenant they should get fobs."

"Fob" is shorthand for Financials Object. It is the old approach from Navision Financials that provides file format to ship raw source code modifications. Because this approach includes source code, it means a customer can invest in customization developed by one partner, then have it serviced by another partner later since the source code is accessible.

By contrast, extensions are closed. "They are not open code. The source code is protected which disables customers to move from one partner to another," Brummel writes.

At least some of Brummel's readers back him up. "Couldn't agree more - extensions are useless for existing NAV customers," one person wrote in support.

How will extensions impact NAV VARs?

So, is the extensions framework a great achievement in simplification and improved customer experience? Does it spell the end of NAV as we know it?

NAV partners have traditionally built their businesses around time and materials consulting, much of which focused on customizing NAV with changes to the database tables and pages. With that approach becoming less favorable, customers that move to NAV 2016 and future releases must decide if the benefits of full source code control outweigh the simplicity of the extensions model.

Crowter outlined for MSDW the general approach a Project Madeira/Dynamics 365 customer uses to add an ISV solution via the extensions framework and Microsoft AppSource:

1. The client already has a license that can run them
2. There are no objects to merge
3. On Project Madeira they select it in the store, click a few agreements and five minutes later it's ready to try
4. If it all goes wrong you can reverse the solution out in minute
5. The client's partner doesn't have to do anything

And he does not believe this approach will be limited to Dynamics 365. His firm, Technology Management, understands this firsthand as one of only a few today that have had their apps on AppSource since the launch. He told us:

"What's the betting Microsoft will extend AppSource to talk to on premise NAV installs with 2017? There is no technical reason why it won't just work. The license will not be an issue either because of the way Microsoft are authorizing AppSource-focused development projects."

But will engagements that include low-friction installation of pre-built add-ons also be economically viable for partners? For Crowter, the more important question seems to be whether NAV can remain competitive without them. He wrote:

"I really hope the Dynamics NAV community embraces these changes. Bluntly we are playing catch up in this area with the likes of Netsuite and Salesforce. Anyone who doesn't think they are serious competitors obviously missed the $9.4bn paid by Oracle to acquire Netsuite."

For those wondering what Microsoft and the NAV community think about extensions, there are several in-person events coming up where they can hear more and debate the topic. NAV Directions North America and EMEA are coming up soon, as is NAVUG Summit, where partners and users ought to be hearing a lot more about the updates Microsoft has planned.