If you have IP for Microsoft Dynamics NAV in C/Side your are either in the process of moving it to AL and Business Central or you are busy finding a buyer for your company. Both seem to be very valid options these days.
When you talk to the engineers who are busy executing this task the number one question on their mind, once they got their stuff decoupled from BassApp, is how to break up their extension in multiple apps.
Breaking up as a goal
I was one of the first to blog about the Business Central BaseApp being a monolith application and I have a strong opinion on how to solve it. The new Enum and Interface is the key to solving that puzzle. I’ll get back to that later in this blog.
I get much inspiration for my opinion from following Uncle Bob Martin and reflecting his idea’s to our framework.
This tweet of him caught my attention.
This tweet circled be back to my opinion that just because something was built in C/Side does not make it a monolith. Even if it has many objects.
The ForNAV Report Pack we publish on AppSource has a few hundred files and we’ve divided them into three Apps; Core, Report Pack and Report Pack Test.
Technically we could have taken it even further. Like for example the MICR Check Report for the North American market could have been it’s own App.
Quickly after breaking up our App we learned that working in different Apps is very hard, especially in a small team and my colleague Jacob came up with the idea to make them back into one App during development and then “PowerShell” them into seperate Apps before we publish. Again, more for another blog.
When I did the challenge from Michael Megel yesterday I took decoupling into the extreme with making the al.address pattern depend on the al.masterdata.person and the al.entitystate depend on al.masterdata.product.
Truth is that you can take decoupling and dependencies into the extreme. You’ll end up in a dependency hell.
How and When to Break Up
This may sounds strange, but this decision is more in the hands of your marketing department than in your development team.
Rule #1 – If you want to sell it seperately it needs to be a seperate App.
Cannot make that one simpler than it is.
Rule #2 – Create your own System App with reusable components
Microsoft experimented with making micro extensions, however they suffered from the same issues we had in terms of manageability. You can still make each module have it’s own folder and even check if it compiles separately by giving each module it’s own app.json file.
Rule #3 – Add Reusable code to Microsoft’s System App
This should be Rule #1 actually. As Bugsy said in the NAVTechDays keynote you can submit modules to the Microsoft System App and have everyone share the same code
Rule #4 – Keep it together if it belongs together
Microsofts BaseApp has over 6000 objects and the compiler chews through it with relative ease. It’s bigger than it could be because we lack some features in our language to make it smaller. This results in a lot of cloning of both code and metadata.
If you have a vertical solution you should not be scared if you end up with a core module that has several hundred objects of maybe even slightly more than one thousand.
The compiler wil manage and you can have multiple developers work on features using git with branches.
Rule #5 – Move Interfaces into dependent apps
Most partners I worked with in moving to AL had an endless number of interfaces in their solution. Basically everything they cooked over the years for projects was added to the solution in case they ever need it again.
Move this into small Apps with a clear, reusable interface. Leverage the power of Event Publishers with using an Argument table as a strong contract.
This way you only need to install them at implementations where you really need them.
What makes BaseApp a Monolith?
If you can make decoupled code in C/Side, then why is the BaseApp so hard to work with?
It seems that optionfields that make Business Central so flexible are the achilles’ heel which is why Microsoft is working on the Enum and Interfaces.
Just the Enum was not enough, this would leave the case statement as a problem.
So that’s it?
No, not quite, but it would be a major step in breaking up the BaseApp without breaking changes. Another feature we need which may prove itself even harder to implement is extendable flowfields.
Proof of Concept?
If you look at how Business Central was built we can probably break it up the same we it grew. Move modules that were added later into dependent extensions.
Microsoft asked me to do a proof of concept but I doubt if I will have time to do that. We meet in January and breaking up BaseApp is on top of the agenda.
Maybe a few members of the community can work on this together? Many hands make light work.
The goal would be to move a module like Fixed Asset, Service Management or Production to a dependant app without breaking changes (or keep it within certain limits).
Who is up for it?
Marije Brummel Blog | Business Central, Azure and more... 
Actually I would say that Fixed Assets should be one of the easy ones – since Microsoft decided to talk about splitting up the Base Application i’ve been expecting to see Fixed Assets as the first one, Service as the second and Manufactoring as the Third. So I guess You and I are on the same page on this matter.
My guess would be that FA could be done in probably two days time.
LikeLike