AL BaseApp Customization: “because you can doesn’t mean you should”

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” ;-).