The future of Dynamics NAV – the debate continues

So the debate about the usefulness of Dynamics NAV's new extensions continues, I've been away for a couple of weeks (with the geek hell of very intermittent wifi) and have returned to find that even the press has picked up on the debate. Have to say that I'm still convinced that they are a good thing and having had some time with no distractions to think through why, I'll try to articulate the reasons. Best get a coffee first though – this goes on for a bit!

I'll start by saying that Dynamics NAV is a product that I totally believe in, it's been my life for twenty years, I've made a good amount of money from it and more importantly it's given me unbelievable job satisfaction. Some of the projects I've used it in have transformed the businesses they were for, nothing beats the buzz of watching a solution you've designed and created, enable massive success. And that success is normal, its just how long it takes to get there.

Good but standard is not good enough – hence we often need customisation

But if I'm honest, since day one, Dynamics NAV has been a great  product for developers as much as the organisations using it. If you could write some code or find your way around its object designer, then you'd love it. If you didn't then it's maddeningly, frustratingly close to perfection.

If you know a man or woman that has the necessary skills, then they become essential to your operation. You will need them, ideally almost daily, not just for the original project but for its entire life. Your system will be tweaked, amended and extended so that parts of it won't be recognised as NAV. It becomes if you're not careful, you'll have difficulty understanding 'what standard NAV actually is' after a couple of years.

NAV was a product that was, and arguably to a lesser extent still is, not perfect but you can fix it relatively quickly if you know what you're doing.

Microsoft with successive innovations like the page design function available to end users in the role tailored client, have improved things but it's still not perfect. A simple example is what if the column you want to show is not available to select in that page design? Back to object designer again I'm afraid.

Microsoft's motivation originally was, I believe, to make upgrading affordable if not simple and easy. They achieved that objective for me, it's now as easy as upgrading an ERP system can be.

You have an ongoing need for a guru

But to successfully implement Dynamics NAV you still indisputably need a 'NAV expert'. That's great for me, that's why I could relax and enjoy my holiday on my yacht, bought and paid for by my Dynamics NAV skills, the last couple of weeks.

But it restricts the market to a small minority of companies who can afford those of us in that expert category. And the more popular the product the more those experts cost given the laws of supply and demand.

Even worse that high demand and pay, driven by more and more highly visible success stories has attracted some real chancers to our world. They want the money but don't have the experience and that has led to some implementations that frankly are an embarrassment to our community. It's been a gold rush situation for as long as I can remember now.

The number of time I've had to 'rescue' clients from poor, bad or even diabolical solutions that have cost them massive amounts in lost business and reputation is far too frequent. Most of these have happened because the consultants and developers have said yes to client requests they should have resisted, it's just lack of experience, but it's hard to say no if you can't explain why.

The same changes requested over and over

And even more frustratingly is that 95% of those changes are requests I've seen many times. In most instances glaring (to end users) gaps in Microsoft's standard solution that everyone wants 'fixed'. Don't most specification reviews start with the client saying "why isn't this standard?"

So addressing that particular conundrum while I'm here, why don't Microsoft fix them? Well for every change they make, they get a barrage of criticism from proportion of 120 thousand plus companies already using the product. Organisations and partners who have built their solutions around that particular quirk.

It makes it much easier to introduce new stuff rather than fix what's already there. They occasionally do it but for the last ten years it's been the platform that's been the prime focus not redesigning functionality. The simplification agenda now under way is changing that but it's going to take a while and I question when it will get to complex areas like item tracking for example.

So with the assumption that there is not going to be a radical step change in what we get from Microsoft how can we start to deliver NAV to more companies, at an affordable cost and acceptable risk with the experts we have today?

Extensions make NAV affordable for everyone

So I see extensions as the answer to this. Twelve months ago it was a vision but today its becoming reality for me. The team I work with have embraced extensions and now have a whole bunch ready to go. It's taken effort and time to move from a project to product mind-set but I really believe we are getting there.

And what that means is that a couple of days before I went away, I could do a presales demo to a perspective client that we prepared in a couple of hours. That presentation included eight of our extensions (or packaged solutions that will be extensions when 2017 comes out) plus two from third parties. Three years ago I would have spent days constructing that demo, now thanks to extensions, delta packages and powershell its minutes before I'm working on constructing the data setup I need to show.

And it addressed all the points our discovery showed they needed, in way that the prospective client could actually see, rather than have to conceptualise and then have to pay us lots of money to construct. Much better chance of another NAV customer now isn't there?

So I'm going to observe that if I was a sole NAV developer working for just one or two major clients then I wouldn't be interested in Extensions or the philosophy they promote. The overhead of packaging individual bits of functionality is not worth it in this environment.

So Extensions are not perfect (yet) but they have lots of potential and will be increasingly significant from where I stand.

When will this become reality and what are the hurdles?

Not everyone sees it from my viewpoint though and these are people I respect. Why do you need to skill up and start building extensions now? Why not see if the issues get addressed and start using them then?

Well at the danger of putting you off even more, extensions need a change it mind-set and that's not an overnight thing to achieve especially if you have a team that needs to change with you. I work in a partner with about one hundred people including thirty odd NAV developers, as one of the cheerleaders for Extensions do I have everyone on board yet? – no, still a few laggards I'm afraid.

We've had to first get our heads round the capabilities and best practise for developing with Extensions. Learning what you can do with events and how to structure things to mean we can use them exclusively has resulted in changes to our standard patterns that we've been using for decades.

Then we've had to review the design of all our standard solutions to rebuild them around events and extensions and make as many as possible 'zero impact'. Now as where I'm the solution architect I want a full justification as to why we should modify any standard Microsoft code.

Then we've had to change our consulting teams to check the Extensions list first to see if we've done it before writing up another change request. When its an extension that requires changing they have to submit a product request and ideally get it added to and monitored through the product backlog.

And that's when they are working with clients that are on 2016 or shortly 2017. While we have progressed to 70% of our customers on 2013+ which is a lot better than most partners I believe, we still have to keep happy clients who have so far refused to move from classic and switching back and forth makes adapting the new ways of thinking harder.

What I'm trying to get across here is that it's not an overnight process and if you don't start soon then you might be exposed. Obviously if you work for a UK partner please, ignore it all and bury your head in the sand!

For everyone else – changing mid-set takes time so go to Directions and Tech-Days with an open mind and forget the world you've known. I'll lay odd that if you do that you'll spot the possibilities.

Taking the points in Mark Brummell's blog 'why extensions will fail to upgrade too….' in turn

Scenario 1 – Changes to Document Approval

So Mark describes a situation where document approvals have been extended and then the customer upgrades to 2016 and finds that approvals have been redesigned to work with the new workflow features, much better it's is too.

So why is this affected by Extensions. We had customers who have had the challengue who didn't use extensions. Your back to what I mentioned earlier about Microsoft not being able to change anything here.

And a lot of the customers who needed document approvals customising have been able to work with the new workflow based approvals so the customisation has been removed.

And those that haven't we have taken the opportunity to redesign the option they wanted to be triggered by an event meaning that future upgrades should simply be a matter testing. Unless of course Microsoft change the core application again – but that is a problem for all developers and an argument for not upgrading at all. Look back through this blog to see what I think of that option.

Scenario 2 – Workflow

So this describes a situation where you have a custom workflow solution and then Microsoft introduce one with 2016 – you now have two workflow solutions.

Again why do extensions change this? In fact, if my custom workflow was an extension I could use powershell to uninstall it in one command so if I wanted to revert to standard then I'd be better off.

The idea that if Microsoft have a standard solution you should use it is a good one but that doesn't preclude you having an advanced or specific third party solution in the same area as well.

The best example of this is interfaces to Excel, there is a standard Excel add-on tool but the most common third party add-on, Jet Reports competes very successfully with that and beats it hand down.

In my view having a customisation or extension that replaces standard functions is perfectly valid but when Microsoft change that standard you should re-evaluate and reach the right conclusion for you.

Scenario 3 – Attributes

So Item Attributes are coming to NAV 2017 and very good they are too. Yes, this is a solution we have developed many times, in fact it was one of those 'standard solutions' I added to that demo.

We are already refactoring our 2017 Extensions to take account of the new standard item attributes, they will be ready for the release.

Those upgrades include a routine that populates the standard item attribute tables from our previous custom ones. As creating that data is a long and painful process the customers who use that upgrade will have a head start using that new feature throughout the application as its pretty useless without comprehensive data.

Scenario 4 – Microsoft discontinuing RDLC for Word only

Sorry Mark but that's total speculation and I for one would be leading the protests. Why would the NAV team forgo the benefits of Microsoft's standard report writing tool for is work processing tool?

I'm looking forward to them enabling some the new features that have been added to RDLC in the SQL 2016 release. Yes, that will mean we need to test and maybe even adjust the RDLC reports when we get there but that's the price of progress I guess. As long as it's not the start again situations we had with 2009/2013 that is!

Carrying on to some of Marks other issues.

Longer upgrade times – so you need to uninstall your extension before you can install and the new version. Yes, this is a pain if you just want to change a small detail, so much harder than importing one object in a fob especially if it's a page or report with no data implications.

But this is not something you have developed specifically for this customer in the last ten minutes. The historic mind-set of try it and if its wrong, fix it needs to die with extensions. You build your extension, test the hell out of it, for every scenario you can think of. Ideally you do this with an automated test set. When it passes perfectly, you release it and ONLY then does it go near customers' databases.

That means that the chances of issues are so much lower, it must be right first time every time! Are you really saying Mark that as a community we cannot produce perfect or at least good enough solutions before the customer highlights the faults for us?

Extrapolate that and you're at a place where you only need to upgrade either the extension when there is a new release from either the extension publisher or Microsoft. Yes, the data migration is a pain and needs to be speeded up or optimised, its one of my top asks for Microsoft to look at.

Extensions are not open code – true enough and a real pity. I understand that some ISV's want to protect their IP but that's not unique to Extensions. In fact, as of now I have developer rights on my licence to a lot of existing ISV solutions from the likes of Continia, Agiles, To-Increase, Schouw & Jet. All of them seem to have one or two codeunits that I cannot edit to protect their IP and we have lived with that for years. Is the whole extension that much more of an issue and should I be changing it anyway if I want it upgradable?

Will moving to extensions really be that much of a pain? Well let's think through two common scenarios and see what's involved.

Scenario 1: Cosmetic changes

So say I want to add a field to a page and put a new report on a toolbar of that page and that page is part of an extension. The core object designer cannot see extensions so I'm stuffed right?

Well Marko Perisic demoed a new development environment at WWPC in July (so it must be out of NDA) which allowed you do just that within the RTC client itself. Significant because that's an environment that understands the extensions installed unlike the classic based object designer.

In fact, Marko contended it was so simple that an end user could do the 'cosmetic changes' required and then package up those changes into an Extension and publish it directly to Appsource with a dependency on the original extension.

Now end users publishing this kind of change to Appsource is a step too far for me, you'll clog it up with lots of 'good ideas' that will mean it's impossible to find anything.

I think this shows that Microsoft are aware of the limitations of extensions currently and working hard to fix them. Should you therefore wait till every last problem is solved or climb on board now?

Scenario 2: Major Enhancements

The second scenario is that I want to add some significant extra function to extend an Extension. It's very likely that many users of extensions will want something specific to them right? After all that's the NAV way, you get your 100% fit by adding that last 5% yourself. At the very least traditional NAV users will avoid any solution that doesn't allow this.

So if you take the premise that the only customisations that will be packaged as Extensions will be products in Appsource (I'm with Mark here, why would you do this last step if you don't need to) then they should not try to accommodate every last request of every last client. That way leads to the over complex unfocused vertical solutions all experienced NAV consultants have come across till now whose implementation is significantly compromised by functions they don't even need.

What those 'product extensions' should do is have a reasonably comprehensive list of events included. Customising your extensions should then be about subscribing to those events in a new extension that you layer on top of the product extension.

My team have already used this technique to great effect. Where we would have had to branch our product development to match a specific client's requirement, we've been able to create a function in a codeunit which subscribes to an event in our 'product extension' and then we can upgrade our product extension at will without having to worry about the customisation unless we change that event which we will try our level best not to do.

Summary of my conclusions

  • Extensions are not perfect but they have significant potential
  • Over time they will affect almost every NAV implementation
  • The adaption with be slow at first but will rapidly increase over next three years
  • If you don't start changing mind set now you might be too late
  • There is a significant opportunity for the brave & adventurous