The Microsoft Dynamics 365 Business Central community has been on a rapid journey over the last few years. Events, Extensions, automated testing, SaaS, AL, and VSCode are just some of the topics that have forced a whole different level of reskilling on users, partners, and ISVs. Usually, we become aware of the change one year and then by the following it becomes mainstream and critical to our success.

My bet would be that 2020 is the year that DevOps for Business Central goes from an excellent idea to the mainstream. I simply cannot see how we are going to continually certify current compatibility for the hundreds of ISV solutions (likely to be thousands by the end of 2020) and hundreds of thousands of per-tenant extensions using the old fashioned manual test and deploy method.

It's costing Microsoft a fortune

I'm putting my money on it this year because Microsoft is getting increasingly frustrated that its SaaS ERP platform is being run like thousands of on-premises systems. Both ISV and per-tenant extensions are continually and repeatedly blocking Microsoft's upgrade process, forcing the Business Central systems team to run an ever-increasing number of concurrent platform versions because of a few tenants stuck on each. This situation isn't viable as Business Central scales ever larger. Imagine the howl that would go up if something they were doing was costing us thousands a week. Isn't it fair then, when the reverse is true, they coax us to do something better?

Expect Microsoft to get harsher in applying the rules: 90 days past the launch of the new updates and your tenant will be upgraded without your failing extensions, even in your production instance. Tough if you haven't got it sorted by then; you should have. That condition is in your terms of service, so why should Microsoft be penalised because a few customers haven't fulfilled their side of the agreement?

It's poor customer service

Most clients selected SaaS with the expectation that upgrades would be regular and automated; it's a significant part of the attraction. They've experienced it with Windows and with Office 365, now they want the same with their ERP.

I'm with you when you say that ERP is a different game; technical issues have the ability to completely stop a business, with massive cost, reputation damage, and trauma to the users when it goes wrong. Not even close to the same league as 'I can't send an email'.

That's where DevOps and automation come in

All of this is why we need to put measures in place to make sure that the worst-case doesn't happen. If Business Central is to scale to the level that most partners and ISVs need, it won't be with an army of developers and QA engineers, it will be thanks to DevOps.    

Don't get me wrong, you still need people to monitor the process and fix the failures, but you'll get the notice of potential failures without the Business Central users seeing a blip.

The bonus is that your in-demand developers can focus on writing code rather than creating environments and deploying extensions. Everyone else gets what they need in terms of testing and validation while freeing the development team to stay on task.

ISVs need to support DevOps

Currently, I don't know an ISV that is publishing apps that include automated tests, and that's going to have to change. How can I, as a VAR, build a per-tenant extension with a dependency on an ISV app and ensure I haven't broken that app if I cannot run the tests to prove otherwise? You have to write tests to get your app into AppSource, right? How about making them available, at least to your authorised partners so that those partners can include them in their DevOps runs on behalf of their clients?

ISVs also need to make sure their solutions can be safely extended and that those extensions can be maintained. Until Microsoft facilitates scripted download from AppSource of the test-inclusive version of the app, the ISVs will need to publish tests on their partner portals.

It cannot be free

A properly run continuous DevOps process incurs processor and storage costs even if it never reveals a failure that needs fixing, so partners need to evolve their service offerings to cover those costs. From my perspective, it's a replacement for the infrastructure and SQL support we have provided for on-premises installations.

Right now you can estimate what pure DevOps will cost to run, but it's hard to predict the cost of fixing the failures, which is what the client wants included in their monthly fee. That's determined by the breaking changes that come through in any update cycle, and who knows what that will be? I guess we VARs are all taking the same approach of allowing for a certain amount of DevOps expense per client that might, with the benefit of hindsight, prove too high or low.

Part of your standard service package

What's certain is that a market norm has not yet been established. I continue to have conversations with prospective clients in which I explain why DevOps is needed and why it's worth paying for when competitors have left it off their proposal entirely.

The reality, I tell them, is that they will end up doing it. If we as partners haven't set the expectations regarding the cost, we are either going to be out of pocket or facing an unhappy client who might take their subscription to someone more transparent. Neither of those options looks attractive to me. I hope our community is honest and upfront enough to start including DevOps as standard in the monthly charge.

It's not as hard as it seems

You don't have to create everything from scratch. We did that initially, and our ISV organization is still using that. But for the client and project teams, we've brought in the core solution from a company run by one of my fellow MVPs. Connecting that into our existing client management tools has taken some effort, but I'd prefer to do that work while we have hundreds of per-tenant extensions out there rather than wait till it's thousands.

After all, we sell process automation and efficiency to our clients daily. Pretty poor show if we reject it ourselves, isn't it?

A SaaS ERP platform can't scale when partners treat it like thousands of on-premises systems.