Personalized Community is here!
Quickly customize your community to find the content you seek.
Check out the latest Business Central updates!Learn about the key capabilities and features of Dynamics 365 Business Central and experience some of the new features.
Download overview guide | Watch Business Central video
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
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.
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…
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…).
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 … :-/.
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:
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 ..
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:
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?
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!
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” ;-).
Business Applications communities