Dec 14, 2018
I was recently at Extreme365 in Austin, I even had a role in Keynote! One of the sessions was a "Fireside Chat" with the Bizapps product team. Aside from there not actually being a fire that I could see, there was some great conversation. Ryan Jones, who works with Charles Lamanna on the platform team, said something that stuck in my head.
When asked about what ISVs can do better in working with Microsoft and AppSource, Ryan said Microsoft focuses on five things.
Depending on whether you are "Build", "Extend" or "Connect", these may have slightly different meanings to you. If you don't know what Build, Extend or Connect are, read this post. Let's dive in a little deeper on these five things.
Like I said, this seem like a twofer, and really feels more like a Connect track issue more than the others. If you have an external service that your solution connects to D365, then obviously you will want to make sure you have provided for redundancy in the event something happens, so your users are not suddenly without your wonderful value-add. In addition, you will need to stay on top of changes to Microsoft's end of the platform, to make sure your solution continues to connect, day in and day out, to delight your customers.
For a Connect ISV, you need to make sure you have enough capacity to scale and handle whatever may come your way, without bringing your solution, or D365 to a crawl. For all ISVs this is an important consideration. Poor performance can come from many different things, but the result is that your customers suffer with a bad experience. In addition, poor performing code could put unnecessary strain and cost on Microsoft's end, which may cause you to be removed from their Christmas Card list. Microsoft recently launched the Solution Checker to help you identify performance issues. You can read about it here.
We know that Microsoft is maniacal about security. It is a competitive advantage that they do not plan to put at risk. ISVs are a weak spot in their defense. I have seen apps in AppSource, that request you provide tenant admin credentials into a form displayed in an iframe. Seriously! Microsoft has started to focus on this "hole" more, and I expect that to tighten up significantly. It is not enough for them to waive responsibility for your app, they need to ensure that your app is not creating a security doorway.
There are certain ISV apps that continuously generate support issues for Microsoft. You do not want yours to be on that list. If it is, you already know it. Deprecated code is probably the main driver of lack of supportability. Fortunately the Solution Checker and AppSource Pre-Certification tools are here to help you identify these issues. Many of these issues will also cause performance issues, so you should fix them. Microsoft has not yet launched a tool to automatically fix your crappy code, so for the foreseeable future, you will need to crack it open and do it yourself.
This one is getting tougher to keep up with. Things you built a particular way, only a year ago, are not necessarily the most efficient way to do that task today. Some thing that you wrote 500 lines of code to do, might be accomplished with a checkbox today. This is particularly true for legacy ISVs. If you have not touched your solution in the last 6 months, you are already out of sync. And we both know, many of you have not touched your solutions in years. If you did, it was just patching it up to keep working, so today you have a real house of cards. Efficiency is not even a consideration.
Up until now, Microsoft has been more than forgiving of ISVs and Customer solutions that fail on one or more of the above five items. But that is neither scalable, or supportable as we rapidly move towards a single version of the product. Microsoft has tried the Carrot approach, and that has worked for a portion of you, but now it is time to switch to the Stick. I expect Microsoft to get much more aggressive around solutions complying with these five things soon. Consider yourself warned.