With the release of Dynamics NAV 2017 and Dynamics 365 for Financials (which is technically NAV2017), the buzz word in the Dynamics NAV development community is the development function called Extensions.
What are Extensions?
Extensions is a way for NAV Developers to put modifications in your live environment without modifying your core NAV system.
How Does it Work?
The extension basically implements the code on the Service Tier instead of the NAV development environment. The clients connects to NAV using the service tier, this is how you see your NAV in whatever state it’s in.
Implementing the code directly in the service tier means that you won’t see any of the modifications if you go into the NAV development environment. You can only see the new tables created and table field changes if you look into the SQL tables directly.
Why is the Development Community Buzzing About This?
I honestly don’t know. I think the hype of Microsoft releasing something new have people gagaing and swept up into the hype.
I remember when Microsoft first announced the idea of multi-tenant for NAV services. Even though people didn’t fully understand it and it didn’t apply to 99% of the NAV population, the community still tauted like it was something that was the second coming. But… That’s hype and marketing for you.
At its current state, the NAV Extension will benefit partners and ISV in that they can quickly take their code and implement it on customer sites. In addition, it gives partners, ISVs, and independent NAV developers to protect their code from everyone else that does not have the “source code”.
For customers, the benefit is that the partners won’t charge too much for putting modifications that they’ve developed for other customers. They will now have a wide range of solutions that are developed in extensions they can essentially “bolt on”.
Lastly, it’s the only way to get your IP (intellectual property) on the Microsoft AppSource.
Why it’s a Weapon of Mass Destruction for a Company?
Notice the statement I made above:
It gives partners, ISVs, and independent NAV developers to protect their code from everyone else that does not have the “source code”
By implementing the code on directly on the service tier, nobody in the world will be able to modify what the original developer has done. The code that your partner/ISV/internal developer has put in is effectively sealed off from the rest of the world.
This means that if you are, for whatever reason, unhappy with your partner/ISV/internal developer, you better make sure, as a company, you have the original source code on which they built their extensions on.
Playing the devil’s advocate and assuming the worst scenarios with extensions
If you have a NAV or ISV partner that delivered their modifications to you as extensions and they provide terrible service and lacks basic knowledge of the product. If you want to ask another NAV partner or a freelancer to come in and help you, you will need the blessing of your previous NAV partner and pray that they are cooperative in provide the source codes.
If you purchased an ISV for your business, however, there are still some missing features on the ISV that you need your partner to add. Your partner will be unable to help you. You will need to reply in the ISV to re-release the extension for you.
If you have your own internal NAV developer on staff. If you need to terminate his employment for whatever reason, it’s very possible he/she can take the source code with them and leave you high and dry. No partner can come to your aide and you essentially have to live with what you have.
Even now, if you purchase an add-on in the 30 million object ranges, you’re effectively held prisoner by your ISV or the partner. There are special ways to “hack” the 30 million object ranges within SQL, but it’s usually messy and will incur a lot of additional expense on your part.
However, with Extensions at it’s current form, it will be impossible for any NAV developer to come help you if you do not have the original source code for the extensions.
Dynamics NAV (Navision) has always been an open source software. Implementing a structure where you effectively seal off the code is troubling.
It seems like before you do any kind of Extensions development with your partner or customer, you will need to lawyer up first. And as we all know, once you get lawyers into the mix, it just goes downhill from there.