A few months ago, I blogged about a new initiative from Microsoft: Microsoft Dynamics 365 Business Central Publisher program.
At Directions EMEA, we got more insights to the program.
There is still the same focus and intention – but with a different approach and name. I’d like to go more into details on that, as it simply gives me an opportunity to say “I told you so” a number of times 🤪.
The initiative is only there to make the Business Central community perform better in terms of creating future-proof solutions .. ANYWHERE. We’re not talking “ISV” or “Product” or “PTE” only. We’re in fact talking about ALL of them. All inclusive – isn’t that what it’s all about these days ;-).
So, we’re talking about anything that will be developed for Business Central, needs to meet a certain standard. And that standard is actually quite obvious: whenever your solution can live in the cloud, you meet that minimum requirement.
The Business Central Universal Code initiative
You can find everything you need to know about the initiative here: http://aka.ms/BCUniversalcode. But let me give you a few shout outs of what I think is important.
The goal, as I said, is to encourage partners to develop and resell Business Central offerings that can live in the cloud. If they do, they most probably will also work OnPrem (I actually haven’t seen any cloud-ready solution that doesn’t work OnPrem 🤔). Remember “cloud first”? It comes down to that. It obviously has a lot of benefits:
- It can be implemented anywhere (online, PTE, OnPrem, hosted environments, …)
- You can list it to AppSource to extend your sales force / reach ..
- You are more encourage to use the power of the cloud services
- Your step to the cloud will be easier (if ever)
How will Microsoft do this? Well, from CY2022, new OnPrem licensing modules come into place. As such, we’ll get two new modules:
- Module “Implemented code is not in extensions” – necessary for code customized base apps (yikes…).
- Module “Implemented code is not cloud-optimized” – code is in extensions, but that code could only work OnPrem.
As such, for us, partners, to implement extensions that has code that would only work OnPrem – from that moment, we’ll have to buy a license. The fees for that license is a per user per year fee, that increases every single year.
Important: this won’t affect customers who licensed BC OnPrem before April 1, 2022!
So, what is the term “Universal Code” all about. Well, simply said:
- You’ll have to go FULL extensions (no code customized baseapp)
- You’ll have to go for code that does not require OnPrem scope.
That basically means: any extension that you create, you need to set the “Target” in the app.json to “Cloud”:
And this means: your code needs to be able to live in the cloud and OnPrem – hence, it needs to be “Universal” 😉. In my opinion, “Universal Code” perfectly describes the initiative! Whoever came up with that – well done! 👍
However, you’ll see, if you’re not used to that, it might come with some challenges as well.
What are the things you’ll need to take into account?
From the top of my head, there are a number of things that won’t work anymore, or can be challenging when you would make them work in the cloud, like:
- .Net Interop: you should not be using any dotnet-type. You have your own dlls? Then you might want to look into rebuilding them to Azure Functions? Or some WebAPI? Or .. ?
- File operations, especially in an automated process. Can you use a file service like Azure Blob Storage in stead?
- Print operations
- Direct SQL Server access
- .Net control addins
In many of these situations, you’ll have to go for a service-based solution: a set of API’s that you can call from BC that can replace the intended functionality. Or a set of APIs in BC, that can be called from outside BC.
Like what we did in the company is create a “FileAPI” that we can put on some server OnPrem, which makes it possible to Pull/Put files on a local network. I must say, this was very useful a year ago, as customers requested to have file-based integrations in place and such (which I very much hate .. but anyway ..), but now we see more and more a move to also cloud-services for file storage, like Azure Blob Storage .. which makes all the sense in the world ;-).
What’s different with the “Publisher Program”?
Well, while the “Publisher Program” was targeted towards ISV’s, and very hard to actually monitor, this new “Universal Code” initiative (which replaces the Publisher Program) is targeted towards everyone (Implementers, ISVs, … anyone who codes) and very simple to monitor (through the OnPrem licenses).
Of course it is important that the right mentality is being executed here. As for many partners, customers are buying and paying the license, and obviously, if you would now like to implement an OnPrem only ISV product, you’ll have to sell that license. If a partner is OK that its customer is overpaying for an app that actually isn’t worth it – well, that says a lot about such a partner.
Let it be clear: this initiative is not intended for Microsoft to earn one single dime on these new modules. The fees are not there for Microsoft’s profits. They are there to encourage us on the right path. Even more: they are successful if they don’t sell one single instance of it.
My take on this
I was not surprised about the Publisher Program, as I’m not surprised about this one. In fact, me personally, I find this program making much more sense, as it also targets PTE (aka customer customizations), not just ISV’s.
And, here comes my “I told you so” 🤪
For years I have been advocating against anything not future proof.
I have spoken very hard against any kind of hybrid approach: To Hybrid or Not To Hybrid (waldo.be)
I have spoken very hard against the code customized base app: AL BaseApp Customization: “because you can doesn’t mean you should” (waldo.be)
I even dedicated a blogpost on the fact that one day, we might expect this kind of initiative by Microsoft. Back in 2019, I mentioned a piece on a slide that kind of fully describes this initiative: “In the future, on-premises will follow the cloud rules” (waldo.be)
And .. I’m eating my own dog food! From the very first extension, that we created +3 years ago – from internal app to any PTE for customers (now +150 apps) – every.single.app has the target set to cloud. Not because Microsoft required it – just because it’s one of the ways for us to make sure that the solution that we foresee for the customer is as future proof as at all possible. Sure, we have had to find solutions for stuff that we weren’t used to, but there ARE solutions. Sometimes you really need to rethink everything – but again – there ARE solutions. Always.
So, if you ask me – do I support this initiative? Well – heck yes! It’s aiming for what we (my company) have been breathing for many years already! So I know it’s possible. There are solutions for any challenge. And if you don’t see them – look further. If you still don’t see them – let somebody else look at it from a fresh vantage point.
This blogpost should by no means be an official description or announcement of the initiative. You have Microsoft for that. And it’s Microsoft that is doing a session next month about this initiative:
When? January 11, 2022 | 08:00 – 09:00 CET (Central European Time) / 06:00 PM – 07:00 PM AEST (AUS Eastern Standard Time)
Where to register? DKWC045 Universal Code Initiative (microsoftevents.com)
As said, this “Universal Code” initiative is aiming for better solutions: to extensions, that has code that can live anywhere (especially on the cloud).
That made me think: may be it’s interesting to describe some guidelines that makes sense in this perspective. Well, you might or might not be aware of the recent initiative that me and my companions have started: ALGuidelines.Dev . Why not describe a series of guidelines on how to “think cloud-ready” or how to solve a certain challenges that come with universal coding? Well – if you have ideas, proposals, questions, feedback – we very much like to hear! Just create an issue on the alguidelines-github and get the conversation started ;-).
While I was writing this post, there were a few questions that popped up in my head that I think you could have at this moment. So to conclude this post – let’s ask ourselves..
What if the ISV doesn’t comply with Universal Code?
If you implement an ISV product on your OnPrem customer that has OnPrem-only code, then you WILL need that new license to be able to run the code of that product. My opinion: look for another ISV product. As simple as that.
If you implement an ISV product that has a code customized baseapp – well, then I guess you’re in a whole other dimension of crap (sorry, I have no other word). Quite honestly, “code customized baseapp” has never had the intention to be released as products for OnPrem customers. It was a “step” towards the embed program (now MegaApp). But a code customized baseapp that you get from your ISV, and need to localize and deploy and maintain to your customers? No. That has never been a good idea. I would simply refuse.
So, if an ISV does NOT comply with the simple rules of the cloud – then I’d have a serious talk with them, to say the least.
Does this mean I HAVE to put all my apps on AppSource?
No. If you’re an ISV, I can only advice you to distribute your apps through AppSource. It’s possible to do OnPrem AND SaaS business with very much the same apps. You don’t HAVE to go AppSource, but if you don’t, I’m quite convinced that some day, you’ll regret.
If you’re not planning AppSource, then please, make sure you comply with AppSource anyway. It is a darn difficult process to (for example) start to rename all your objects because you didn’t register the affix, or to rebuild your code because it happens to have target set to OnPrem, or.. .
Is PTE (Per Tenant Extension) dead?
Most definitely not. You can do customer development for both SaaS and OnPrem. In my opinion, there shouldn’t be any kind of difference. In fact, developers on our end mostly don’t have a clue if the customer is Onprem of not. They shouldn’t care – the same rules apply for any customers .. ONPrem or SaaS.
It’s just – make sure whenever you develop for a customer, that you’re also able to support them going forward. In the cloud this is an obvious requirement (as every customer is upgraded every month), but I would apply the same for OnPrem as well.
Hi, I think Microsoft should first handle all their own ‘OnPrem’ stuff before charging extra money for customers who don’t do that.. There are still a lot of ‘OnPrem’ only in the Microsoft base app. As a small example there are a lot of Scope(‘OnPrem’) and also they use a lot of DotNet. Just have a look at codeunit 1297 “Http Web Request Mgt.” as an example.
Thanks for your feedback.
I think that comparing us with MS is wrong. MS is in another place: they build the core product, they will not depend on anything but themselves, they can not afford to use “dangerous” .Net libraries .. and quite honestly, since they host the platform, for them, it’s OnPrem – as it’s their premises. They don’t have the same challenges as we do (but completely other ones, believe you me). So comparing ourselves with Microsoft is wrong, imho.
Besides that – what would be gain with MS completely removing the OnPrem stuff? How would we benefit from that?
Just my 0.02€
I totally agree with the push to make everything cloud ready, and I love what MS is doing with all the related Azure services but saying that MS doesn’t earn from it it’s a bit untrue imho.
Take as an example a simple file transfer via FTP/SFTP since a lot of 3rd party systems still rely on it. And yes I know they should use APIs instead, but that’s the reality we live in. Now either the customer pays the new extra license to use a dotnet library with an on-prem extension to handle it or they need to pay for azure functions and so on.
So yes MS earn in either case, at the end of the day it’s an extra cost for something that should in theory be free.
Of course we can argue that a simple azure functions to handle SFTP transfer cost almost nothing per operation, but add a few of those 3rd party integrations and those numbers can easily add up and at the same time it increase the complexity of the solution.
I think before pushing this hard for 100% cloud compatibility MS should probably considering providing a wider range of dotnet wrapped objects that covers the most common business like file transfers and so on.
I can only support this ;-).
Totally agree on this statement Daniele :
“I think before pushing this hard for 100% cloud compatibility MS should probably considering providing a wider range of dotnet wrapped objects that covers the most common business like file transfers and so on.”
…if MS could share some roadmap on this crucial topics ?