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

4 Comments

  1. Thanks Marije, I always love reading your posts.
    In many ways I see the “stubborness” in me also. But also I think this is slowly but surely fading away.
    We (speaking from a partner) have many cases where we in the NAV world had made customizations needed by our customers. When they upgrade Online/Saas we at least try to find appsource alternatives, and we have found some in many cases as well. I’m happy if I can find another reliable solution. That relieves us from having to support customized code.

    But I think it sometimes is a challenge and takes time to find reliable appsource apps. In the end we have to support our clients any way in their use. The fact that many appsource apps are made by companies we have never heard of is also a challenge, we don’t know if its reputable company/partner/isv or a one-person company that maybe doesn’t exist a year later.

    Another challenge I think with appsource apps vs. what we had before, is that we can’t see source code anymore. We have for example worked over 10 years with one ISV solution but now that they published their appsource app it is more like a black box, trying to find a way to make small adjustments (extension) for our clients is much more difficult.

    Like you I also think 1800 apps is overkill for our market right now. But I guess that comes when you have two alternatives, per-tenant-extension or appsource. I would like to have something in between. We as a partner have our “solutions” we install to most of our customers. We don’t necessarily want to put them on appsource for the whole world, but I would like to have that conveniance to know where its installed and make upgrades easier.

    Like

  2. Well I think MS pushed to it by not allowing CFMD object number ranges in PTE. And wasn’t there plans to charge for PTE objects at some point?

    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.