Why best practices for Per Tenant Extensions?

About a month or so ago I did (or try to do) a webinar about best practices for Per Tenant Extensions. I was unhappy about the result but I guess the story should be told and I did promise to get back to you and finish it.

Well, I did and I am getting ready to start sharing what I think a “perfect” per-tenant extension should look like and as always I am looking for feedback and some interactive discussion.

Why just Per Tenant Extensions?

I believe we lost track of what we are good at as a community. I mean that in several ways but for this blog I will stick to Per Tenant Extensions.

Since we got AppSource a few years ago our community started partying away on it. This resulted in a whopping 1.800 apps for Business Central today.

Don’t get me wrong, I love AppSource and just like you I am proud of my contributions. However I do believe 1.800 apps is a bit much for our community.

This is most easily explained with an example.

Banking

If you search for the word “banking” you’ll find 162 apps of which most target the EU market where banking is “standardized” for many years.

What does this cost?

Making an App popup on AppSource is not as difficult as it was 5 years ago but it still requires a lot of work and most often it is done by senior engineers. Something we don’t have a lot of. As a community we have a strong resource constraint.

Although AppSource was intended to fix this issue, it looks like it did the oposite and with all partners making their own apps instead of cross selling others we are busier than ever keeping up apearances.

How does having Best Practices fix that?

In our business, perception is everything. In the eyes of the community and our customers customizations have gotten a bad reputation. However, putting something on AppSource and then selling it only to a few, or your own customers does not make your software into a product. In fact, it is as easy to break the upgrade via AppSource as it is with a Per Tenant App. From that perspective most of what I will try to share will cross apply.

And what changed since C/Side exactly?

Most of how we coded in C/Side with the “Design Patterns” in the past works just as it did today and I won’t go into this to much. We did however get things like Extention objects for Tables, Pages and Reports that we did not have before and even more interesting, enums and interfaces. This is something I will write a few words about.

Dependencies

This is probably the most interesting topic to talk about and I have an interesting standpoint that I will be curious to get your opinion on.

About being proud and arrogant…

In any line of business where creativity is a big part of the process people are proud of what they do. But pride can seem like arrogancy when being looked at in another perspective. In the Business Central community we are specialists in not willing to share.

I believe we can kill two birds with one stone. If we stop flooding AppSource with Apps that nobody except your company is using we can start using these resources for real customer projects.

If we do these (bespoke) projects with proper best practices we can make Business Central and AppSource back to what they should be. Efficient and the best customizable ERP system that exists.

Folder Structure & Dependencies

Keep an eye open next week or the week after for the first part of the best practices. I will start with talking about the folder structure and probably something about dependencies.

Marije