Directions EMEA 2019 Afterthoughts

It seems that when my blog posts appear some people hold their breath. Don’t worry, that won’t be nessesairy this time.

I am at the Vienna airport and just wanted to write some thoughts I have after the event.

When I look at 2.500 people wondering around I don’t see a community. I see individuals. We call it a community because we share the love of a product but we need to move to the next level of community.

Business Central Wave II is the first version of Navision without C/Side and a windows client after it was introduced in 1995. For almost 25 years C/Side made our carreers.

A lot has happened in 25 years and most solutions grew out to be monolyths. Not because you cannot write clean decoupled code in C/Side but because we lack knowledge and discipline.

Now with Extensions and AppSource we have a chance to start over, to do it in a better way. But it does not look like we are doing that.

Why did the concept of extensions see the light of day? Because it allows Microsoft a platform that allows Business Central to connect to AppSource. AppSource allows everyone in the world to find your solution without you doing much marketing effort.

This means we now have a platform to share repeatable small modules. But this is not what is happening.

Partners that did everything themselves in C/Side that led to solutions with thousands of objects that nobody understands anymore are still looking to convert these solutions to AL rather than looking at that is out there and reuse existing apps.

I’ve even heard that partners are now merging AL code because they modify the base app.

THIS IS HORRIBLE!

Giving up C/Side is only worth doing if we get back the repeatability of small reusable components with clear interfaces.

WE NEED TO BE A COMMUNITY THAT SHARES!

Start sharing IP! Don’t re-invent the wheel because you had to do this in C/Side. In Business Central having 10 ISV solutions in one database is a piece of cake.

This is my biggest takeaway.

The second thing that was interesting for me was having a conversation with Microsoft. I cannot remember having conversations like I did in the past few days with them in years.

We talked about the refactoring and challenges in the future. We agree that breaking changes should never happen again and still we need to continue breaking up the base app into smaller pieces.

For this to happen and to avoid future frustration they’ve invited me back to visit Lyngby every now and then in an informal role. I’ve agreed to try that and let’s see what will happen here.

I’ve also pushed Microsoft to have better involvement of MVP’s in the next interations. This group of people can give good feedback and seem to have been forgotten in the last 6 to 12 months.

The future is uncertain and a lot of decisions need to be made. The road is not paved, The road in many cases has to be created using heavy machinery.

Yet Business Central remains the BEST flexible cloud ERP product. The webclient team did a great job making this client on-par with the Windows client in the best way possible. Web development is so much more difficult than the old Win32 UI.

See you at NAVTechDays? Find me at the ForNAV or Global Mediator booth.

2 thoughts on “Directions EMEA 2019 Afterthoughts

  1. Gerd Hübner

    Many valuable thoughts, again, though in some aspects I cannot agree with you, Mark.
    You said, that many or even most solutions grew out to be monolyths. But what about the so called “Standard NAV”? Hasn’t it become a monster, too, with several generations of developers having build another oriel here and another balcony there? I remember, that in ancient days it was not impossible to completely understand the posting routines, e. g., but nowadays, I tried to comprehend the inventory adjustment code with no luck. Recently, in order to implement a harmless sounding code change (allow negative inventory for components while posting a production order), led to a major clusterf**k with overflowing unit costs and I couldn’t even find the reason for this in the code. So the main task would have been to revise and supplement the “Standard”, instead of just translate it one to one from C/AL to AL. Another example is the unfortunate implementation of item tracking. Each time, you want to record a lot no. or serial no., you have to open another table, though 99 % of all customers and business transactions only need one lot no. per document line. The main problem is not the more laborious designing or the limitations of extensions or the switch of the programming language, but the drawbacks of the “Standard” and these cannot be cured by apps.
    Let me still say another word with respect to the “Apps”, whose wheels should not be reinvented. I would agree, if those apps could be seamlessly implemented and were easily customizable. But in praxis those “Apps” (in former days they were called “AddOns”) are neither perfect nor can be made perfect, because if you want to make money with your “App”, you will not set the “ShowMyCode” property to ‘Yes’, and so the main purpose of making an app is long-term customer retention, instead of benefitting the community.

    Like

    Reply
    1. Mark Brummel Post author

      All I can say is that I sat down with MSFT to express the need to continue to clean up the monolyth. In order to do this they first need to move certain parts of the application into modules without breaking them. After that they can be replaced.

      Item Tracking and Item Costing are horrible and not to be customized.

      Like

      Reply

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.