Yesterday Microsoft has officially presented the Business Central Universal Code initiative ( http://aka.ms/BCUniversalcode). For more details about this initiative, I suggest to read Waldo’s post here or my old post on Simplanova’s blog here.
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 the Microsoft’s base application. In all my trainings about AL I never show how to modify the base application, simply because it should not be done.
So, question is: why partners are worried for this initiative? Do you really have so much 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 favour 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 on creating Saas-compliant extensions for their on-premise customers?
We’ve done a quick research on the partner’s ecosystem in the last months, and these seems 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 to 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 start 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 to 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 done externally with serverless services like Azure Functions or Logic Apps or Web Jobs.
- Business Central Job scheduler should have only tasks that pertains 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! Are 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 stuffs in general.
There are not too much obstacles to remove 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.
I’m absolutely curios to know your point of view, so feel free to share your comments, your experiences or your pains.
Stefano Demiliani 
Fully agree. Make all your BC implementations cloud ready is a challenge on one side but it is also a chance on the other side. I’m really looking forward to move non-business processes like data exchange to Azure functions or Logic Apps. Now is the time to do a redesign but not only in the way we code but also in the way we think. I still often hear the argument that keeping all your code in BC makes your live easier. I think this is true in some ways but it is for sure not the correct approach for modern ERP implementations.
LikeLiked by 1 person
Reblogged this on ERP and BI.
LikeLike
Stefano you might be right, but why do you want/need to force customers and partners to do it your way?
If you are right then customers and developers will do it your way, because it is cheaper and/or easier for them.
But it seems there are many people that are not of you opinion.
In my opinion we have also to split up the points Cloud and development, because these two points do not really depend on each other. I think there would be much more customers in the cloud if we had the full functionality and possibilities of f.e. NAV2018 available in there. And do not tell me that would not be possible with an adequate design.
To your points:
Skills-> We needed also in NAV skills outside NAV if we had to talk to external services. But we were able to handle much of the requirements in NAV, without needing an external service to store a file or print a document. So all the possibilities we have now in BC should be possible, but we should be able to do basic functionality without having a skilled Cloud Architect.
And BTW-> The more skills you need, the more skilled employees you need, or you have lesser people with lesser specific skills if you haven’t enough money available.
Costs-> One of the points you mentioned above was unpredictable costs. I think this is true, because we need to many services and skills (a skilled Cloud Architect wants his money) we continuously because we need keep track that all the services we need to use are available or need to be updated. This also are costs we have to calculate and that someone has to pay for. As we do not know what challenges we have to expect (License costs, functionality like new pricing) in the future the costs for the cloud are unpredictable.
Stability and Maintenance-> I have learned in my long development career that things that aren’t there, normally do not produce errors, or in other words: keep it small and simple. I just spent several days in connecting a WEB-Shop to a NAV- System (there would be no difference in BC). We had five persons that were involved, one for NAV, one for the NAV-interface in Magento, the Magento provider, the firewall- admin, and also the shop developer who designed the shop content. Everyone was a skilled person in his job, but that took much time to sort out every bug and issue on the way to a running system.
You also have to keep track of every service you use for every update, otherwise an update may kill the functionality you provided as we had just last week where someone update a mime- component on the cloud server that broke the mail- service from BC in that area.
LikeLike
While I agree with you on the aspect that partners should not modify the base app, this is unfortunately at this point a utopian idea. The partners that struggle with this are most likely the ones that have a highly customized and modified base application which grew over decades.
Extracting that to an extension would require a complete rebuild of the application in order to remove it from the base application.
And we’re not talking about a few hundred objects but thousands, sometimes tenthousands. Extracting 10 000 objects that are highly integrated with each other and the base application is not something to be dealt with on the fly.
Microsoft is doing all they can at the moment to ease this extraction from the base app by adding lots of events partners can use to execute their code in the base app, but is still a long way to go.
While this is possible with a lot of work, Microsoft forces partners to publish these modified base applications as an embed app to the cloud without offering a proper way to migrate your tables from this embed app to your own extensions piece by piece.
In other words: once your objects are in the embed app, you currently have no way to move them to an extension but to obsolete them and create them with a new id in your extension while migrating all the data.
So it is at this point not possible to move from a customized base app to extensions step by step.
They course Microsoft has chosen here forces partners to completely rebuild their app before migrating to the cloud or suffer lots of dead tables with data that needs migration.
Please don’t get me wrong. I’m totally on your side that everything that gets newly developed should have the cloud as scope. But to convert a highly customized base app to extensions is not something to be solved by saying “this is bad practice and should not be done”
LikeLike
I think this will also be an utopian idea in the future. Think about an example like you need an additional field “Description 3” that has to be included in all tables using the description fields. ( An requirement of several of our customers)
What do you think would this mean to BC if you need to trigger an event every time a description is assigned?
I think we will have at the end an event trigger calling software that is able to do some slow ERP- functionality, if there are new events for every new business case/requirement we need to implement in BC.
If there is no review on the current strategy. we will see that these heavy solutions will leave BC or the market, because the effort and costs they have to spent in BC is in no relation to the revenue they can earn. But this will become a problem for BC in the future, because these heavy customized solutions are currently the “cash cows” of BC. These solutions are often large installations, if they leave there will be less license fees that are needed to do further development on BC. And i don’t think that SMB’s will compensate this loss, because every customer has it’s specific issues regardless if there are 10 or 100 users, but you have to fix them for every customer separately. And i also think that there are several solutions for SMB’s that do a better job than BC is able to do. (think about the NAV Entrepeneur (non) success story)
LikeLike
Appreciate a lot your comments and opinions guys. We’re not totally aligned on some topics but sharing opinions was the goal of this post 🙂
LikeLike
Why writing web API calls in BC extension is bad ?
LikeLike
It’s not bad in general. You can absolutely do that. But I think it’s not always the right approach to do, it depends a lot on the business case. Handling complex protocols in AL is not always possible for example. And handling external calls that can take lots of minutes to complete is not the best choice in terms of scalability and performances (you load the service tier).
LikeLike