Sometimes I get the remark that I’m not sceptical enough, but mostly too positive towards whatever Microsoft does … well – I have been very happy with the product, the progress, the evolution and the revolution.
For all of you with that opinion about me – let me make you happy. You might have figured from my previous post that there is one topic that doesn’t make me particularly happy: “Code Customizing the AL BaseApp”. The one thing I’m very opposed against – even more than dreadful properties like “ApplicationArea” and “ShowMandatory” ;-). “Code Customizing the AL BaseApp” is an ability for partners that Microsoft is working on – you can read more here in a recent blogpost from Freddy.
Let me try to explain …
Since NAV2016, we have seen a move to a new development model: extensions: an ability for us to change the product, without having a footprint in the base app. This comes with many advantages, like upgradability and maintainability. Whoever has been doing upgrades the classic way knows that this is not easy. Extensions gives us the possibility to create and change the software, and still being able to implement “continuous upgradability”. Theoretically, at least ;-). Now, about 3 years later, we even have a new development language (AL) that fully implements that development model (extensions).
However – the new development model implements limitations we are not used to: we were able to change whatever we want, and with extensions, we are only able to extend what Microsoft allows us to extend. The more time passes, the more limitations will disappear, but .. time has to pass, I guess.
Very recent, Microsoft has released what to expect in “2019 Release Wave 2” (which I blogged about, indeed). A big part of it is the ability to customize BaseApp code in AL. In short: in this new fancy development environment (VSCode), we won’t only be able to create and maintain Extensions, but also customizations to the base app. Basically: we will be able to do whatever we have been doing for so many years.
Is this a step forward? May be because of the new fancy development environment? Well – I beg to differ…
Why is Microsoft doing this?
For partners. Microsoft listens to feedback of partners, who convinced Microsoft that there are solutions out there that have been implementing such customizations, that are not (yet?) portable to the new extension-model. And while Microsoft wants to abandon C/SIDE completely in the next release, the only thing they could do is to allow a way to do code customization of the BaseApp in AL.
Can you give me examples?
Well, I mainly hear 3 types of customizations that appear to cause the inability to move completely to extensions (probably there are more…).
- .Net / Client-side resources / …: Custom made dll’s, like reading scales, direct access to SQL Server, ftp, … these kind of fancy things.
- Extending options (enums): like adding a document type, or another line type in a sales document
- Changing Primary keys
If you want to get rid of these, you’ll have to refactor your solution that way you don’t need them anymore. But, with the ability to “code customize the BaseApp in AL”, now you have the choice to NOT refactor, and just take what you did, and migrate that to AL.
What did you do?
Well, in our company, we refactored (and are still refactoring). Our company had to address all of these examples to be able to move to extensions as well. We even take the advise from Microsoft very literally: In the future, on-premises will follow the cloud rules. Basically meaning: apply all the rules like it would run as PerTenantExtension or AppSource – even when you are OnPremise: No .Net, only extensions, … .
Disclaimer: I don’t want to claim we had to face all the challenges out there – I’m just stating we had challenges, and I am very happy we are still able to find solutions to “stick to the rules”, although, many times, a lot of creativity is involved … :-/.
Postponing has consequences
You will be cheaper – and that’s not always a good thing
In my opinion, the ability to customize the AL BaseApp gives the partner the opportunity to NOT take the opportunity to move to extensions. It gives them a (fairly) easy way out. It gives them even a (temporary) competitive advantage against partners that are not taking the easy road, but the less easy (but more future proof) one. Just think of it: if two partners try to help a customer: one will give a quote on migrating him to a code customized but not barely upgradable solution, the other quotes a rewrite and rebuild into extensions … .
Microsoft WANTS us to move to Extensions
And, don’t forget: Microsoft wants us to move to Extensions. Yes, I did mention that twice .. ;-).
Like I will say this again as well: In the future, on-premises will follow the cloud rules“.
Postponing doesn’t mean avoiding …
IF you are moving to code customized AL, you are postponing the inevitable. And in my opinion, that comes with an extra price: the price you pay to implement that code customized AL solution.
Just think of it:
- Do you really think your custom dll will ever be allowed in the cloud? You might have to redefine that solution at some point anyway (like service-oriented architecture)?
- Do you really think they will ever allow to change primary keys? I at least hope not – or I’m not going to trust any app together with mine ;-). Again, you’ll have to do it at some point anyway.. .
- Do you really think that Microsoft will implement the ability to change the options of the BaseApp any time soon? And I’m serious here … . I do believe that enums are great. But extensible enums – you have to foresee that in code and make the code extensible as well on every single place the option (sorry, enum) has been used.. . I don’t see this happening any time soon for baseapp options, to be honest. It’s a huge works, and it breaks a lot. There are other design considerations, like we simply introduced a new boolean (basically .. some more to it though ;-))
Postponing doesn’t make your life easier
I mentioned “upgrading” a few times. I don’t know about you, but we are quite well-organized in terms of upgrading at this point. At least for C/AL. How does it look like in AL? Well, you won’t have the AMU (Application Merge utilities in PowerShell) anymore. So when you would code-customize the BaseApp in AL, you’ll have to rely on DevOps, I’m afraid. I don’t know how it would look in DevOps, to be honest. But I don’t want to figure that out either. I’m done with upgrades. Really. Shouldn’t we invest the time to see how we can refactor, rather than finding yet another way to manage upgrades for our customers? And keep in mind that Microsoft is planning to work on the BaseApp as well – which will not make your upgrades harder than any upgrade before – with different tools … . Sorry, I don’t see this as a step forward ..
Support
For me, this “code customizing AL” is just another development model, similar to the “hybrid” model. And if you don’t know how I feel about hybrid models – just read this 😉 (looks like I did my share of ranting lately ;-)).
Our lives are difficult enough. And if you are not careful, you might end up with having to support:
- Some customers purely in C/AL (well, that’s what we have been doing for so long already .. )
- Some customers purely in AL (with extensions, with dependencies, CI/CD most likely, testability, … )
- Some customers with a product and customizations in C/AL, but some ISV product on AL extensions (do you feel it coming..?-
- Some customers with a product in AL, but customizations in C/AL, just because I wanted to change a primary key
- Some customers with a product in AL, customizations in AL, but code customized .. So not “just” extensions.
…
You feel me? You really think your support-team is going to like this mixture? It would only be a good thing if you hate your support-team ;-). No, seriously, I don’t see how I could make anyone happy internally with this kind of operations.. . Try to explain them how to deploy the C/AL part of an implementation, or how to upgrade the dependent app that is dependent from a code customized database, or how to debug/update/deploy/ … in those different types of implementations, … . We already have all these version of NAV to know, are we really going to implement different development models as well?
It is also good to have the BaseApp code in AL though …
To end with a positive note – we have the code in AL! And I love that. It’s so much easier to find stuff with VSCode. You can search symbols, search text, file names, … I love it! So, for LOOKING at the code, I love it! 🙂
Conclusion
I’m going to end this post here – I have the feeling i have been repeating myself too much already … and I might already have offended some people … if so, sorry, that’s really not my intention. I write this to share my concerns, that’s all. If you have a good reason to go down that route .. than go down that route! Please, by all means, do what you think helps you best! The only thing I try to do here is to make you think twice before you do ;-).
May be the only thing that I wanted to say is: “because you can doesn’t mean you should” ;-).
Loading ...
12 comments
4 pings
Skip to comment form
Well Waldo you are so right.
But isn’t it just a matter of win-win-lose/win beside the ability to correct or improve silly design flaws and limitations from day one of Navigator in example the core finance-accounting part (but again people who knows what can be approved here is getting fewer).
1. Win: Partners will win (or at least survive) and we all know whom and why as you also mentioned (competitive advantages)
2. Win: MS will win (not lose) as they still will sell licenses and not lose customers
3. Lose/Win: Customers will lose the seamless upgrade capabilities (and lose/invest some money on IT-development) but then again win in having a very flexible or dynamic business supporting vertical ERP solution (giving the customer competitive advantages – more important)
But yes I totally agree. It is sad that it is not possible to go all the way yet but I can also see that partners thinking in the right development strategy (making true extension vertical solutions) could win in the long run and then all will win-win-win.
This gives customers/partners the opportunity to migrate to extensions (and NAV 2019) piecemeal instead of everything at once.
For some behemoths, this is the only way they’ll stay on NAV/BC. If they have to do a nearly full rewrite they will be looking VERY a lot harder at the competitors.
Author
Thanks for thos insights, I really appreciate people to take the time to comment. 🙂
Well, I know they’ll HAVE to end up with extension at some point ;-). I think that’s inevitable.
I also expect partners that go for this “code customization” model, that they’ll have to spend time into migration, and setting up a decent development and support (and upgrade?) model for this way of working .. that’ll take quite some time as well .. knowing it won’t last .. .
Waldo, thanks a lot for these interesting news. For me, this is good news!
I do not work for any NSC, but for a company just using Nav (or whatever it is called today). Nav has been our choice, because this was the only ERP system (we found) that could match our extremely individual business model. Now, 18 years later, I was very frustrated about the upcoming restriction, while I absolutely understood the benefits of an unmodified base app.
However, I´m not sitting here to have a good time, but to find solutions for whatever my company want to accomplish in out market segment. Me and my team (and my NSC) can write the perfect type of code, but my company will fail, if we cannot compete in the market.
These days we cann read a lot about indutry 4.0 and how we can individualize out processes and products. In such a world you can only compete with an optimal individual solution, not with “the perfect type of code”.
Yes! We did crazy things during the past 20 years, and we did lots of them within the base code. Everybody did that. Thanks to evangelists like you, we now work on rewriting everything by preparing everything for extensions and the web-frontend, which is really hard … really. My indi code allone has some 400.000 lines of code an definitions + the changes in the base. We have to look at everything and we need to change code that in productive use. However, we see the benefit for the future and try to not touch the base in the future wherever this is possible. However, the day is going to come, where we may need to do a modification in the base so we won´t loose a feature that is indispensible for us.
Our biggest problem at the moment is, that we cannot find a consultant with enough experience with VsCode/AL/JS. For our NSC most of that new technologie is just too new. (Any idea?)
If others don´t understand the new paradigm or are not willing to rewrite everything necessary and possible, that must not become a disadvantage to those, who do understand what has to be done. I´m very glad to hear, that Microsoft has some understanding for that.
As we say in germany “Nie das Kind mit dem Bade ausschütten” (Never throw the baby out with the bath)
Michael Peters
Author
Well said ;-). Thanks!
Any idea for consultant – well, in Germany, you have “Cloud Ready Software”? 😉
“Well, you won’t have the AMU anymore….. …. …. Sorry, I don’t see this as a step forward ..” – Waldo
I could not agree more…!
And this is – apart from the (in my opinion) not earned deprecation of any form of “windows client” (non-web based client) – one of the biggest disadvantages of the new AL world..!
Don’t get me wrong.. I would love to have only customers which can be supported with extensions only.. Yes. Please..!
And if you only have (or accept) that kind of customers I fully agree with the “Follow the cloud rules” principle.. Again.. Yes… Please..!
But is this realistic for all customers? Should every customer be forced to SaaS at one point? Should Saas be able to accommodate every customer at one point? What happend to chosing the best tool / software for a situation? Why “discourage” a matured software concept to “promote” your own preference? Only for your own financial insentive?
Regarding the 3 example you mention for BaseApp customisations.
You know the first reason is valid for a lot of our companies customers, the second and third I would avoid in general. 😉
But the 4th reason you kind of mentioned is never said explicit and out loud.. Let alone valued as it should be.
With extensions you can only EXTEND and not MODIFY… (This would be a breaking change in the Dynamics NAV world)
And yes: “With great power comes great responsibility”
But as an example: A customer of ours uses the dutch functionality to match payments files received from the bank with invoices. In the base functionality a temp table is created with all customer addresses for matching. While it is never used by this customer it would not be possible to skip this step. With the amount of addresses in the database this step takes several minutes. For information never to be used. (And independant of the actual data processed)
Instead of a small, easy maintainable, upgradable and portable modification (thanx to the AMU and Delta’s) we now would have to resort to… … code cloning?! (Upgradable?!)
With similar tools as we now have on C/AL, modifications in the BaseApp would be as small, maintainable, upgradable and portable as in C/AL. It would not seem as rocket science to port this to AL as well. (The basic structures and principals are already available)
But what about all the refactoring you might say? Sure, structures will change, but your footprint in the BaseApp should be reduced to the minimum regardless. Put as much in extensions as possible. But with the right tools those few remaining modified files would be automatically portable and everything could be integrated within CI/CD.
There are a lot of good reasons to move to extensions. And you should.
There are a lot of bad reasons to modify the BassApp. And for those you shouldn’t.
But leave the responsibilty with responsible developers and don’t “force” it by the ecosystem.
Waldo.. A question on a related topic (and maybe a topic for a blog 😉 ).
With the Model.Tools we gained a lot of insight in the Base Code.. We could see changes (field length anyone) and adapt and respond. What is your view on this point in future.. How would we get insight in code changes? How would we know what to change in our code? How would we learn about new “undocumented” features? How would we learn about added options that don’t “break” our test scripts because those are also not aware of these new options?
For me also reasons why I would be a VERY (!) big loss if something along those lines would not be available for AL..
B.t.w. I know we could compare files, but then you would have to manually compare every modification by hand. Same challenge as with upgrading.
With Delta’s you get contextual differences.. Added fields, modified functions, changed parameter sets the lot. This can all be automated and processed so you get an easy overview of the actual descriptive changes between to versions in your mailbox.
Author
Thanks a lot for your insights :-).
This “BaseApp in AL” is already something I’ll need to get used to. Publishers, for example: it was easy to get all publishers from C/AL with the model.tools – but how do I get my publishers when all is AL? :-/.
And indeed – any kind of code analysis.
Well, I know it’s coming. The CodeCop is already using the compiler / model / .. to analyze the code. Something I was told we will be able to do ourselves (may be we are already able to do it – don’t know).
Insight in code changes can/should be done on pullrequest/build-level, no? Where you combine “codeanalysis-code” in your build, right? At least once we’re able to do so ;-).
Static code analysis is one. This will be used by CodeCop. A static piece of code and check if it follows a set of rules.
If we would be able to harness this ourselves would be a first step. (Preferably in a “similar” way as now where we can convert AL files to .Net objects and do our automated magic)
The bigger challenge is analyzing changes. Now we can use Delta’s. In these kinds of analysis we are only interested in contextual (!) changes and want to filter out everything which remained the same. This is actually quite specific for our ecosystem because we are confronted with a externally changed base code every month instead of just our own code. (Nowadays this mostly applies to BaseApp modifications but still)
It’s also not only changes within a build, because OnPremise you will still have the situation where you skip a bunch of Cum. Updates or go to a new major version. So it should be based on the Before / After / Delta principal.
The final step in the automated process would be the application of changes. If that is possible you can automate processes as you can today and we wouldn’t lose all progress of the last 5 years in code management (this used to be one of the agiles heels of the product which is finally fixed). These kind of possibilities are a must in our ecosystem to follow and keep up with all new developments in the product because the repetitive tasks of code analysis (modifications) can be automated and we can focus on building high qualitity added value for our customers instead of constantly getting up to speed without any added business value.
It might make sense to reject the ability to customize the base app for some people, while at the same time it also makes absolutely no sense to kill an ecosystem that has been developing over the last 30 years when you do not have to.
There are ISV and also customer solutions that have been running for many years and closing the base app would just kill some of those without giving them a way out – why would anyone want this? It would not only kill the solution but also burn a lot of money and possibly cost jobs.
Microsoft gives those people enough time to do cleanroom implementations over the next few years while still being able to live off the code-customized solution for the time being. I agree this can only be a short to mid-term solution and people should stay away from customizing the base app in the future. But if you already have a lot of legacy code and – for various reasons – do not want to convert that to extensions, you now have enough time to do things properly without having to throw together a bad design only because MS pulled the carpet under your feet.
Author
Thanks for your view on this. Well, I hope you are right ;-).
Thing is – it’s all so different .. everything: migrating code to AL, setting up a support model, upgrade, maintenance … . It’s not like you will just keep on doing what you did – no – you keep having the same possibilities, but doing it massively different… .
And when you worked through this .. the result is you even don’t have a model that’s going to be supported in the future: extensions.
Hi Waldo,
First of all thank you for your article, really interesting, as always. As far as I understand, the baseApp will be editable, and the changes will be enablesd into a cloud version, am I right?
I understand your concerns about this issue. I’veread this article the day you published it, but it came again to my head because of an issue I’ve found with one customer.
As you probably now, in spain there is an inmediate supply of information on VAT, and there are standard objects in NAV that develop this.
There is a codeunit that creates the XML sent to the service. In the header of the created XML, there are 3 URLs, related to the schema, and validated into the server. But depending on the county, the schema is different. Those URLs are defined in global text constants.
In the onPremise version, we’ve changed the value of those text contants, but of course, in the cloud version, that is not possible. I’m trying to finde the solution tochange those constants, trying to find any event or anything, but I don’t finde the way. That’s way i remember about this article.
Do you think that modifying those constants into the base app will help me with this problerm?
Thank you
[…] think we’ve discussed this in Dev Digest before, but it bears repeating. Just because you can, doesn’t mean you should modify base objects in Dynamics NAV/BC. As Waldo notes in his blog on this topic, with the advent […]
[…] might know my opinion on “code customizing AL” – if not, you can find it in this post. In a way – for me – “code customizing AL is evil” ;-). So .. […]
[…] might know my opinion on “code customizing AL” – if not, you can find it in this post. In a way – for me – “code customizing AL is evil” ;-). So .. […]
[…] might know my opinion on “code customizing AL” – if not, you can find it in this post. In a way – for me – “code customizing AL is evil” ;-). So .. […]