Now that the NDA on Business Central Wave II has been lifted and the DVD preview is released partners got time to look at the code Microsoft has refactored.
The reactions vary from being marketing correct to more realistic.
I have a strong opinion about what Microsoft did, and especially how they did it.
First of all, I agree that it’s a great idea to split NAV up into modules and I also agree that the architecture has to be modernised in more than one way.
But that does not mean it has to be with breaking changes and most of all, it did not have to happen in Visual Studio Code with Extensions.
Microsoft is years, maybe a decade too late with starting this project. To write decoupled code you don’t need extensions and you don’t need a fancy code editor. You need discipline and consistency. Especially the latter seems to be where Microsoft is totally off these days moving away from patterns in a horrible way. (But that’s a different blog.)
As I suggested in many presentations Microsoft should have added Table Extensions and Page Extensions to C/Side. They should have also added a column to the Object table called “module”. The compile should have been enhanced checking if modules would compile on their own.
With these simple changes modularity would have been possible a long time ago and the ecosystem would have been used to it.
Let’s not look back, but let’s look forward, let’s see how it is posible to prevent programmers who take a dependency from being forced to refactor their code.
The problem Microsoft has now managed to place themselves into is that extensions on AppSource cannot be compatible with both Wave I and Wave II. This means tenants cannot be upgraded until partners are ready with the refactoring, which is a lot of work.
It get’s more difficult with per-tenant extensions. To upgrade the code a partner has to compile against Docker or the installed DVD, but how does the customer test against their own data?
Does the customer get to upgrade a sandbox? And if yes, how many times?
Things that are broken are primarily renamed codeunits and functions that changed signature.
A simple example is the function to read the contents of a zipfile that changed from a temptable to a list of text.
To prevent breaking this Microsoft’s AL team introduced overloading. This allows to create a new and improved version while keeping the old one and mark it to be obsolete in the future.
The same can be done with new codeunits. Just leave the old ones there. Point them to the new code if you want to.
BUT MAKE SURE EXTENSIONS CAN EASILY COMPILE AGAINST AT LEAST TO AJACENT VERSIONS!!!!!
This way of moving API releated code has been normal in all frameworks for decades. Why can a huge company like Microsoft no do this with Business Central? I just cannot get my head around it.
I know it’s cool to be an MVP. I’ve been an MVP for 11 years, traveled the world and it gave me opportunities I could have never dreamed about. That does not mean you cannot have your own opinion and it does not mean you always have to agree with what Microsoft does.
It’s going to be interesting to see what happens in the future. I am in favor of continuing to break the functional app into pieces with contracts. I will explain how I would try to do this.
My favorite example is Fixed Assets. Did you ever try and see what happens if you remove the 56xx objects from C/Side?
Large parts of the application will no longer compile. Codeunits like 12, 80, 90 and tables like 37, 39 and 81.
To prevent this you’ld have to implement event publishers and introduce enumerations. This will allow to move code that has dependencies to it’s own module.
This needs to be done without changing any of the functionality and then taken into production. Only after a succesful launch without changing the functionality one can consider changes.
But, the changes should then be done to a new app while leaving the old one intact.
This is probably not something you would want to do with Fixed Assets, but with Production, Warehouse Management or Inventory it makes more sense. Especially Warehousing is in a horrible state because it’s hard to extend. It was never designed for extensibility.
It does not have to be when the old module can be replaced with a new module.
Maybe I am just dreaming or over simplifying things but I think it’s realistic to say that with the introduction of the system app Microsoft could have been more careful, take more patience and allow a more phased approach.
After all we are talking about a business solution that is critical to the companies using it. Microsoft made a strong promise about upgradability that can and should be kept.
Partners have the responsibility to be more critical to their software vendor. Don’t just take things for granted – ask questions, be critical, be very critical, and come up with constructive examples and ideas where things need to be improved
Just my 0.02$.