Inside project “Madeira” | Why extensions will fail to upgrade too…

If there is one thing I learned from my previous blog post is that a catchy title works. Eventhough it’s early August I have had a lot of emails and comments on my last blog “Dynamics NAV is Dead! Long live Dynamics NAV!“.

Why? People seem to sometimes only read the title, or half the title. Someone sent me a message on LinkedIn asking what to do now that NAV is dead.

NAV is far from dead and what I wanted to “achieve” with my blog is to alert people that NAV is changing, like James Crowter is mentioning in his last blog. “The answer is extensions, now what’s the question”.

Microsoft seems to be thinking that Extensions are the golden bullet to all the challenges we have with NAV. This idea is wrong.

What are extensions again?

Extensions are a new technology based on two other relatively new ideas namely Delta files and Events. Delta files were introduced in NAV2013R2 (backported from NAV2015) and Events are introduced in NAV2016 inspired on Hooks.

The reasoning behind Extensions is ease of upgrade. For the last couple of years Microsoft has been hearing complaints from customers that upgrading NAV is hard and sometimes the ROI is negative.

Why is that? Because we have to move from classic to role trailored and forms have to be transformed to pages, reports to RDLC and all the users have to learn a new UI.

How is extensions going to make that easier? As if we are going to make this journey again? I hope not!

Examples

Let me give you four reasons why extensions are not going to make upgrade easier.

Scenario 1. – Changes to Document Approval

A user has requested a change to document approvals. Some fields were added to table 453 – Approval Code and they are shipped as an extension.

Microsoft releases NAV 2016 and the customer wants to upgrade. They expect an easy upgrade since they listened to the marketing story and had their partners ship the solution as an extension.

When they try to run the upgrade they get an error message “Table 453” no longer exist and the extension has to be refactored.

Scenario 2. – Workflow

A user is running NAV 2015 with Workflow as an add-on. Let’s asume that this is running as an extension using the new rules of prefixing. Now the customer wants to upgrade.

The upgrade runs fine because there are no conflicts because of the prefixing. Now the customer starts using NAV2016 but they find out NAV2016 has workflow out of the box. Now they have two workflow solutions.

Scenario 3. – Attributes

A user wants to upgrade from NAV2016 to NAV2017. Right now they have a solution that allows them to have item attributes and this is an extension.

In NAV 2017 we get them in standard NAV. I think you get where I want to go

Scenario 4. – New Client

This scenario is more science fiction than the first 3, but the main reason customers are complaining about upgrades is moving from classic to RTC. Let’s say we make that move again? Let’s asume Microsoft decides to discontinue RDLC and move to Word only. Just an example here, no announcement.

If I have extensions using RDLC they would no longer work on the new version.

So now what?

I don’t know. All I want to say is don’t drink to much of the marketing cool-aid. If we want to make upgrades easier all we need is Delta files and good education. We will always have conflicts. Who cares, as long as the conflict is easy to solve. This is why we have Hooks. We don’t need Events.

Extensions will work with Dynamics 365

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.

Extensions are counter productive

When used instead of fobs for traditional NAV development Extensions are counter productive for three reasons

  1. They require longer upgrade time with each version because of the way they are engineered.
  2. Once deployed in a production database they cannot be changed. Each change require a data upgrade.
  3. They are not open code. The source code is protected which disables customers to move from one partner to another.

Extensions, Extensions, and more Extensions

One thing I noticed when looking at the NAVTechDays agenda is that there are two sessions about Office 365 and two sessions about Extensions. To me that looks a little overkill since NAVTechDays was always focussed also on traditional NAV and not so much influenced by the Microsoft marketing machine.

When asked Luc van Dyck replied the reasoning behind this was Microsoft and the fact that he was told that in the future, customisations should be shipped as Extensions.

Well, I sure hope this will not be the case.

 

Advertisements

9 thoughts on “Inside project “Madeira” | Why extensions will fail to upgrade too…

  1. So how do you customize an extension? Events?
    Or does Microsoft think all the ISVs do a much better job than they do at handling every single possibility?
    Maybe they should cut a deal with Universal Studios and include a magic wand with every system?

    Liked by 1 person

  2. Mark – lets take two prominent NA examples – Lanham and Serenic. Everybody customizes them. If they turn their products into extensions, then we need a way to add specific needs that are not covered. Since standard NAV cannot handle everything, it would be unfair to expect the ISVs to handle everything.
    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.
    Plus MS still needs to solve naming conventions and maximum record sizes.

    Liked by 1 person

    1. Dave, I agree. Don’t shoot the messenger. Lets both be happy that Microsoft is going to let NAV is what it is and ignore the marketing messaging around Extensions.

      What I WILL DO! I wil tell the end users at NAVUG Summit NOT to accept extensions from their partners. If they run NAV single tenant they should get fobs.

      Open Code!

      Liked by 1 person

    1. To avoid duplicate names when using multiple extensions every partner has to prefix their objects. Very silly workaround. I am pretty sure I discussed that when we had the class at your company when we went over merging code unit 2. 😎

      Like

      1. I’m not saying you didn’t, but then none of us remembers it 😉
        It is not mentioned here either https://msdn.microsoft.com/en-us/library/ee414213(v=nav.90).aspx

        As you might remember, then we are quite fond of prefixes and use it for all our variables and functions. This also reduces merge issues, and makes “our” stuff easy to recognize.

        Almost everybody in the NAV community seems to hate prefixes, so I was looking forward for it to be the new best practice 🙂

        We have also considered doing it for object names and field names, but so far we are not doing that. If for some strange reason we ever feel like making a real Extension, then we might have to.

        Like

  3. Extensions are intriguing but have a long way to go. I view the initial release as the equivalent of NAV 2009 RTC…very limited and not quite ready for market. The increased capabilities around Extensions in NAV 2017 are the equivalent of NAV 2009 R2…a better release, but still not full-featured and leaving a lot to be desired. 2-3 versions down the road if extensions are able to handle ALL changes to NAV (adding page actions with C/AL code, modifying base code, etc.) then i’ll get on board. I realize modifying base code is not the goal of extensions…but if you need to change the way a core function works as part of your product/customization, you can’t just subscribe to an event to add incremental code.

    Guess we’ll see where it goes…

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s