Business Central Universal Code initiative: are you really so surprised?

Microsoft has officially presented the Business Central Universal Code initiative. For more details about this initiative, I suggest reading my post on Simplanova’s blog.

In summary, with this new offering, selling what is called “non-universal code” (alias extensions not targeted to work online) to new Business Central on-premise customers might require to license two additional modules from 2022 onwards (names of these modules are subject to change):

• Module “Implemented code is not in extensions”: if implemented partner code includes base application modifications, this module must be licensed.
• Module “Implemented code is not cloud-optimized”: if the implemented extensions have target = OnPrem, this module must be licensed.

The non-universal code fees have a per full user (Premium or Essential) price with a per-year fee starting from 2023.

The announced timeline is the following:

During the presentation, I saw lots of partners raising questions (good!) and also raising their level of concerns. What personally is a surprise for me is seeing so many partners in that call that also in 2022 are selling extensions targeted to on-premise (target = OnPrem in app.json).

When I wrote my first book about AL programming (published in August 2018, so more than 3 years ago) one of the recommendations on that book was to always write extensions that target the cloud environment and never modify Microsoft’s base application. In all my training about AL, I never show how to modify the base application, simply because it should not be done.

So, the question is: why partners are worried about this initiative? Do you really have so many extensions that are not SaaS-compliant? If the answer is yes, have you checked your solution design carefully?

In my group I have defined a rule 3 years ago: if an extension cannot be published on SaaS, it never exists also for an on-premise customer. This rule should be strictly applied by everyone I think.

Microsoft is talking only about fees to pay and modules to license if you’re not SaaS-compliant, but honestly, I’m in favor of a more drastic choice: starting from year X, the target parameter in app.json must be cloud-only or your app cannot be installed in new Business Central releases. We need to have one codebase for every platform!

Saying that (these are obviously my personal opinions, I know that many of you disagree), why partners have problems creating Saas-compliant extensions for their on-premise customers?

We’ve done quick research on the partner’s ecosystem in the last months, and there seem to be the main obstacles:

After seeing these results, my first thought was: there is a lack of knowledge about the cloud world! And I suggest you think about this. Traditionally, partners that work in the Dynamics ERP field (Navision, Dynamics NAV) have lots of great consultants and great ERP developers. But now, in the Business Central era, you absolutely need to start thinking also out of the ERP box and you also need to acquire other skills.

Fully embracing the cloud is not equal to starting using Business Central online with some AL extensions. You’re not creating a really strong cloud-based solution if your ERP does everything inside the box (http calls, scheduled tasks for integrations, Power Automate for automating some processes).

If you want to really embrace the cloud, you need to start thinking about your ERP not as a single solution, but as a piece of a more complex solution that spans between different cloud services.

Just to give some more practical examples: I cannot consider a great cloud-based Business Central solution a solution that:

• has all non-business processes coded in AL
• Files are stored inside the ERP
• integrations are done via AL, xmlports, http calls from AL
• Job scheduler is full of integration tasks
• Power Automate is the only orchestration engine for workflows

A modern cloud-based Business Central solution should have:

• AL extensions for handling business processes
• Files stored in the cloud (Azure Storage for example)
• Complex integrations are done externally with serverless services like Azure Functions, Logic Apps, or Web Jobs.
• Business Central Job scheduler should have only tasks that pertain to the ERP. For integrations, create scheduled tasks externally.
• Serverless workflows are a key part of a cloud-based architecture. Start using them. But remember that Power Automate is not the solution for complex tasks or for integration tasks. You should rely on it only for user-centric tasks.

Then, there’s another crucial point: COST! Lots of partners are worried about cloud costs. Are there cloud costs? YES! Does cloud costs so high? It depends!

What does that mean “it depends”? It depends on the cloud solution you’re using and on the cloud architecture that you’ve used. Storing a file can have different costs accordingly to the service used. Using a cloud database can have different costs accordingly to the tier used. A workflow can have different costs (and performances) accordingly to the technology used and connectors used.

Costs of these things are not high, we need to say that, but having a good and skilled cloud architect could help a lot.

So… why this post? Because I’m thinking… and I’m thinking if the Business Central partner’s community really needs to know always only AL stuffs or if they really need to know more Azure stuff in general.

There are not too many obstacles to removing Target = OnPrem for your extensions. Obviously, you need to rethink some things, but that’s possible… just start using cloud services also if you’re working with Business Central on-premise.

The original post can be found here.