How To, Part I | Breaking a Monolyth

I often wonder how I find myself in situations like this. On my day off I find myself behind my desk doing something which is not my responsibility, nor am I getting paid to do it.

If you say A, you also have to be willing to say B and C. This is what my parents told me when I was young so when I promissed Bugsy and Jesper to look into making the Business Central Base Application smaller I decided I may as well make it into a decent project.

7 Comments

  1. davmac1 says:

    Commissions is much smaller, but should be a separate app as well so it can be replaced easily.
    Look forward to hearing more about this project.
    Didn’t Bill Gates originally think that we needed a standard G/L that many other apps could use?

    Like

  2. How do you solve the issue that there are extensions that are overlapping, like extended text management. that allows to handle texts per document type (in separate tables) or commissions which which may be used from service and sales.
    Does this mean, that we need additional or different apps for every of the separate (base) app module- combination?
    Where does this end, if you split up base app into multiple apps?

    Like

    1. Mark Brummel says:

      Hans, instead of complaining about problems, can you please make a suggestion of how you would solve this? You are a smart man and very experienced so offcourse you are right. But being right doesn’t solve the problem.

      Like

      1. Mark, one suggestion i made was to cleanup the whole solution. This would reduce the specific dependencies and events (for example: Calculating VAT in 100 different ways, is not a good idea. If all data going trough “VAT Amount Line”- functions needs only to extend VAT-Amount Line, not Service or whatever)
        But that’s not a real solution.
        To be honest, there is no solution with this design. And not understanding this, is like to explain how to ride a dead horse.
        Before i would start any new design, i would first of all do some base investigation.
        I think there is a complete redesign required from Cloud through AL to the client.
        May be i am old fashioned, but the old C/SIDE design solved more of the real requirements than the new design.
        There is no real solution to install apps without solving the dependencies to other extensions. The only way to solve the customers requirement to have a persistant solution, is to create a complete solution package containing all required modules integrated with each other. (f.e. a special module searching for item numbers should be integrated in every installed module that uses item numbers).
        In my opinion Microsoft should give the solution back to the partners and provide only core services in the Cloud like database, servicetier and webserver. Then partners are able to create a complete persistent solution, they are responsible for. The user experience would be better and there should be only tested updates not every month, to reduce the fear of the users for the next update probably stopping or changing their work. These updates should only be done if required.
        Then i would stop the “agile development” of the solution. ERP has to many dependencies as that your are able to create an easy modification without creating unusable nonsense (f.e. item availability by unit of measure in BC 15.2)
        Getting the developers in Copenhagen, or where else, out of their ivory tower to the real users would also be a good idea. This was the way how NAV was created and enhanced. The early developers talked to the users or had own experience in the business, before they wrote code or made a database design. This experience is currently missing.
        At the end we will see that we don’t need any new design. There shuld be an evolution, but this would require first of all to understand the how and more important WHY of old the way. But this takes time and could not be done in a 14 day sprrint.
        AL is only easy to handle if you are creating your own new apps, but maintenance, support and councurrent development is creepy. Maintenenace takes more time, because you have to check every month if code changes are breaking your solution. This was easy in C/AL where you can see where your code is involved by changes.
        With the events, you have to check if a code change affects an event- call or requires a new event you will get next update. If an event-call is affected, you have to check if you subscribed the event, but you don’t see that in AL. In C/AL compare, you saw your function call that has to be modifed or inserted.
        Also concurrent development was much easier in C/SIDE. You created a project- database at the customer, and changed the objects as required in both addons, and at least a compile all did it. Now you have to create several apps, github versions and depending apps and republish them. if there are cross dependencies in the project, which is normal, this would become realy difficult.
        In development i sometimes have to try out new functionality to check if it works. This took minutes in C/AL. Now i can’t think about how long it takes to republish all the depending apps.

        Support: In over 90% of all support cases i have, i need a debugger to trap the error message the call stack and the data. And then it takes minutes to solve the issue, because the problem is clear. You can object that tests would be required, to check dependencies. That’s true, but an overlapping control in a report, a misspelled word in translation, or an error because of wrong data is not trapped by any test. And if you are working in production- or online business, every minute counts. Telling the customer: “We did not promise any reaction time for a solution” is only the answer for the first time, where a small bug takes minimum a half day to solve in cloud. But the second time the customer will tell you that he did not buy the right solution.

        BTW: Did you solve the enum- issue with the fixed assets.

        Like

      2. The only solution i currently know is not to break up BassApp. But that means slow develpoment.
        My solution would be a solution you would/can not accept: Use C/AL. There you don’t have the problem with with the large base-app in most cases.
        And a real usefull solution requires also C/AL: Conditional Compile. If whole source is uploaded into the tennant, and compiler is also integrated, you are able to compile an object after a module is installed. Then you are able to use a compiler directive like “#IFEXIST(OBJECT::”WhatEver”)…#END” and a property at variables or functions “IgnoreIfNotExist”=True.
        But conditonal compile also requires also a large amount of tests, because you have to test also every combination of installed apps.
        BTW: The problem why breaking up the base app is not a good idea, is the same why breaking up large ISV- solutions is not a good idea. They have to many dependenies through the modules.

        Like

Leave a Comment

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.