Breaking up BaseApp | Business Central

Social media is fantastic and it can be used in many different ways. Where most people are mostly consumers others use it to ask questions. Some share knowledge and experience and gain loyal followers. This is pure awesomeness and mostly rewarded with the Microsoft MVP award for those who don’t give up.

Drive Change

Very few succeed in using social media to drive change. Those who do are known by many such as Elon Musk and Greta Thunberg.

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.

Our Test

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.

Both Ends

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.

Join Us

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.

13 thoughts on “Breaking up BaseApp | Business Central

  1. jeppebylov

    Hi Mark,

    This sounds super interesting. I think there’s so much potential in this than we’ve actually ever thought of.
    Think about the implications of having a small BaseApp and then just shopping whatever extensions you need in the marketplace.
    So many customers have experienced frustration with way too many actions, menus, fields, etc.
    A small BaseApp could potentially make the product much more attractive for small businesses, that might specialize in one specific module.

    Have you thought of what it would take to extract the Jobs module out of the BaseApp?
    Would love to be a part of this.

    Liked by 1 person

    Reply
    1. Mark Brummel Post author

      Job module is too complicated while the base app is as big as today. Once base app is smaller this is next. However if you want to give it a try it would be interesting. Send me your email and we’ll discuss further.

      Like

      Reply
  2. Hans H. Fiddelke

    I would by interested too.

    The first thing i would do, is doing a ruthless cleanup of the base- app.
    There are so many functionalities, which are three or more times in the solution, everyone with another bug.
    I think this would reduce the base app by 10% or more.

    Then i would change to a more usefull (object)- model that reduces this “functionality” above, by putting the function where it is used (Like SalesHeader.Post(Ship,Invoice,”Posting Date”,”Document Date”), which may call CU80 in background, but the entry point should be in SalesHeader).
    This would also allow an easier extendability, because we do not need a seprate event for every function that implements the same functionality.
    After this is done, my next step would be creating a more layered model (similar to the OSI-Model). (the system app is a start of this)

    But first of all we need a TESTED solution that allows concurrent apps accessing/extending the same global data, like extending SalesLine.Type or changing OnValidates, OnLookups which is required from some addons and their business cases.
    And if there is not a solution for that, the whole project is dead, because in my opinion, we haven’t seen the heavy addons here. So we did not see the real problems.

    Like

    Reply
      1. Hans H. Fiddelke

        That Fixed assets is almost finished sounds great.
        Can you explain how the “Fixed Assets” are removed from the various lookups in Sales Line, Gen. Jnl. Line, or how it is integrated as extension in all the (Test)-reports whithout any code change?

        Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.