Monthly Archives: July 2020

Why DevOps for Business Central is the responsibility of Microsoft, not the customer!

I’ll start with saying that I’m not writing this blog to pick a fight or another online debate. I’m tired of getting the feeling that I’m talking into a brick wall not being heard and understood.

I stopped reading most of the blogs and newsletters from MVP’s and from MSDynamicsWorld.com. I find them desturbingly sales oriented, egocentric and political.

Today I was cleaning up my outlook folder for unimportant email when this article caught my eye and I could not resist opening it.

https://msdynamicsworld.com/story/devops-becomes-mandatory-dynamics-365-business-central

I wanted to spend a few moments of my day off to respond to this article and why the statement is wrong.

James is making a statement that if you are a VAR and you have per-tenant extensions you should have DevOps in place to catch if that per-tenant extension is broken.

This may be true with the service that Microsoft provides today, but it does not allign with the orriginal idea of AppSource and Extensions.

The orriginal idea when Extensions and AppSource where “invented” was that the responsibility of notifying breaking changes to partners and customers would be with Microsoft, not with the VAR.

When a programmer at Microsoft checks in code and it is accepted by the code cops and procedures in place, the idea was that a script would be executed against all apps on AppSource and Per-Tenant extensions.

When a programmer at Microsoft makes a changes that breaks an extension the change needs to be actively refused and the programmer needs to implement it in a non breaking way.

If this is not possible Microsoft should actively work with the ISV and VAR/Customer to make sure that all parties are informed of the change. If the change cannot be implemented in such a way that the owner of the extension is forced to rewrite the code Microsoft should compensate.

Remember that customers can expect from a company like Microsoft to provide a cloud solution that is robust and does not break all the time.

The fact that Microsoft decided to make the old Navision code the source of Business Central without refactoring it into microservices cannot be waved away at the expense of customers and VAR’s.

Please enjoy the rest of your day. Comments on this blog are disabled.

About ISV’s, Being Stubborn and Flexibility

Let’s start with a short story.

The year is 2014 and the world was spinning as it did until March this year with mass tourism and in person events.

With the release of NAV 2013R2 and later 2015 our community was just starting to embrace the three tier concept and the Role Tailored Client. Nobody had heard of events or extensions. The economy is booming and everyone is busy not worrying about the future.

In that year I first did a small project for Datamasons to connect their EDI solution to Dynamics NAV using Web Services. Lateron I would do a similar project helping the folks of Dynamics TMS connecting their solution to NAV using an architecture that was as decoupled as possible and easy to upgrade.

When these ISV’s asked me to publicly endorse their solutions I told them that I would endorse the decoupled architecture and promote the idea of using best of bread solutions that interface with NAV rather than doing everything in NAV & C/Side.

This was not the first time I called the wrathfulness of an ISV in our ecosystem to turn against me but it was the first time it went quite big and ugly.

It happed at the NAVUG summit and it created some tention around the event for those involved.

The reason for writing this blog now and reflecting against something that happened five years ago is that this week several events happened that made me think about that NAVUG event several times.

If Your Only Tool Is a Hammer Then Every Problem Looks Like a Nail

I would repeat myself too much if I would start talking again about C/Side and the habbit of our community to use it as a single tool to solve all problems. It’s in-line with the ERP heritage from the late 1980’s and 1990’s when interfacing essentially was non existing, the internet had yet to be invented/adopted and infrastructure was hard to maintain and share.

The large ISV solutions that we have in our ecosystem are all born in the same era and back in the days these were founded by young people (most often or always guys) in their garage working long hours to establish their brand.

Today most of them are in their 50’s or early 60’s worrying more about their legacy than they do about the future.

Back then I was just a bit too young to join that party which leaves in in the middle with no legacy to worry about and an open mind into the future.

It’s a cloud-connected world

Today we live in a connected world in which it has never been easier to open your application and share data and processes accross platforms and geography.

Microsoft did a fantastic job with Azure on the one side as the leading cloud platform for serverless applications and Business Cental and the PowerPlatform/CDS as cloud ready frameworks to build system applications.

With Business Central it has never been easier to design an open architecture that allows you as an ISV to keep your solution small and manageable while allowing your partners to handle edge cases by subscribing to events or exchanging data using the API.

The Problem

For some reason, and I don’t really understand why, it looks like the larger ISV’s are not open to use this opportunity.

Many ISV’s have monolith applications that require “fob” files with thousands of objects to be inserted into your system. The reason for these monolith applications is the fact that they all try to solve all problems with the same software.

This is no longer nessesairy in the cloud world where you can break your application into multiple smaller components to start with, but you can also leverage the Azure stack to move parts of your application to Power Platform/CDS or even Cosmos, Docker, Microservice API’s etc.

The Solution

Time. That’s the only answer I can think of.

Given enough time we will see what happens and who winns.

If I had to place a bet I would avoid the majority of the horizonal solutions on AppSource that have a tight connection to AL.

Instead I would bet on those that have a decoupled architecture and allow their software to be seamlessly connected into anything that understands Odata Query Language and HTML5.