With Business Central we have a very little ecosystem but we also need to drive change from time to time and most often this change is very slow and requires patience.
We’ve been through a lot of changes and each and every one challenged our legacy. Just to name a few examples: Move from Dos to Windows in 1995. Move to SQL Server, move from Forms to Pages, implementing RDLC, moving from C/AL to AL, going from Windows Client to Web and last but not least the extensions only model.
During all these changes the code of our beloved application has barely changed a bit. If you open the customer table in the old DOS version of Navision you’ll see code that still exists today. This is just a tiny example.
The most important learning that I take from this is that Business Central was born in the cloud when the cloud has yet to be invented. We’ve always been a lo-code environment before this was hip and modern.
Time to change
In essence there is nothing big that I would like to change to Business Central. Nothing that would drastically destroy the main architecture.
However I do think it’s a bit to big and it could be broken up into a few decoupled modules. Fortunately I am not alone in this quest. This is where social media get’s in.
A few weeks ago I’ve done some calls for action telling that I wanted to experiment making the BaseApp smaller starting with some of the edge cases.
The reason why I think it’s good to make BaseApp smaller is to make it easier to understand for new developpers.
We’re trying a few things. One is to make two or three modules into a seperate extension on top of BaseApp. Examples are Service Management, Fixed Assets and Cost Accounting.
Service Management brings challenges to inventory and removing it exactly points out the places where extendability is important.
If we implement events and interfaces/enums at the point where Service Management needs them others can use these points to hook in their apps.
Fixed Assets looks to be a bit more manageable but we’ll hit the interface with Sales and Purchasing. Again, implementing events and interfaces/emums for Fixed Assets will help others plug in modules into these area’s.
Cost Accounting has not been started. This is orriginally a DACH module and more or less stand alone. Curious to see what can of worms we open here.
Lastly one of our team members has a great idea to make Item Tracking more extendable using Argument Tables.
Together with Microsoft
First in Vienna and later at NAVTechDays I talked for a very long time with the engineers at Microsoft and they are open for ideas. I think we both realise that most of the knowledge of BaseApp is in the partner ecosystem and what we need is a manageable bridge between both parties.
This is the challenge I’ve accepted. On top of my “normal” business and my family.
This means the team, now six members, is self managed. We use Microsoft Teams and email to communicate and GitHub to share code.
The process is slow but steady and in January we’ve presenting the first results to Microsoft.
This may just as well be a dead end road but I have high hopes this is not true.
Remember that the modules that I descibe here have been added later to Navision. Had there been extensions back then it would have probably already been loosely coupled.
Microsoft is working very hard from their end to make BaseApp smaller by working more on the generic parts. This is more framework-like work and fits better with the engineering capabilities that Microsoft is good at.
Together we might be able to cut the size in half or maybe two/thirds which would be a great start.
If you think you can handle the responsibility of working in a team that is not micro managed where people work when they have time you can join us.
I think we should not make the experiment bigger than it is. Four branches is enough.
Nobody in the team is an mvp. Just mere mortals trying to see if this might work.