Thursday, February 8, 2018
One of the biggest cost drivers for Partners and their customers, since the introduction of add-ons in the mid-1990’s, has been the cost of managing and upgrading these add-ons in customer solutions to keep up with Microsoft’s numerous releases. This has become an even greater issue with the release of the newest version of Dynamics 365 (NAV / AX).
The primary reasons for this have been:
1. Add-ons would also need to be updated (most of the time provided by the ISVs that build the add-ons).
2. Merging add-ons into the standard application is costly so that the add-ons could work well with the standard code.
3. Exponentially the cost of merging add-ons into a standard Dynamics solution increases with the number of add-ons used, especially when the add-ons would cause changes to the same areas within the standard application.
Solving this limitation has been high on Microsoft R&D’s priority list, not only to cut down the expense of upgrading but also manage the cost of maintaining apps on the Dynamics 365 SMB cloud platform, where customers want to buy multiple apps to use with their Dynamics 365 SMB service. Without a cost-effective answer to this systemic upgrading issues, the cost of upgrading these apps over time would be highly prohibitive.
This was the dawn of Extensions technology – a new way to build apps for the Dynamics business solution products to minimize the cost and effort of maintaining and sustaining “add-on” approach through each new Microsoft release.
The first release, Extension 1.0, came pre-packed with Microsoft Dynamics NAV 2016. Solutions or apps implemented as Extensions are easy to deploy, upgrade and remove. However, Extensions 1.0 came with a price of technical limitations: only tables, pages, and codeunits were available, with most of their properties locked for modifications. You can find more about limitations of extensions for Dynamics NAV 2016 here.
Support for all objects was introduced in NAV 2017, along with the possibility to include additional items, like job queues, web services, permission sets, to NAV extension package, but the approach of creating Extensions from delta files of base and custom NAV code was still quite limited, because most of the properties of objects were locked for modifications.
In December 2016, Microsoft introduced Extensions 2.0 with the new development paradigm of defining an Extension as a delta from the standard NAV solution in the modern development experience of Visual Studio code with the new compiler (after more than 20 years). In my opinion, this looks very promising.
However, there is still much uncertainty in the market about this new technology. At 1ClickFactory, we’ve witnessed ISVs questioning what the requirements are for successfully transitioning to Extensions 2.0. In this blog post, I’ll share our recently gained know-how on Extensions 2.0 from the various Extension development projects that we have worked hard on over the last year.
What are the considerations to make before moving development to Extensions 2.0?
Eliminating modifications from NAV standard code (moving customized code out of standard objects into Events): Now is the time to refactor your current code to Events. With the new Extensions, technology is the future of customizations and currently is under continuous development. 1ClickFactory anticipates the newest Extensions technology will be fully functioning and stable by the end of the first quarter of 2018. Moving code to Events is the most consuming part of moving a Dynamics NAV solution to Extension. By moving your current code to Events now, you can prepare your solution to easily move to Extensions, once the technology is ready. Additionally, the solution becomes significantly more maintainable as all customizations are implemented in custom object range: easier adoption of new NAV releases and no conflicts with standard code customizations of other ISV solutions, because there will be no need to merge your customizations to new version of Dynamics NAV; there will be less time needed to support Dynamics NAV value-added resellers (VARs), as there will be no need to merge your code to customer’s solution.
Deployment: Extensions 2.0 can be deployed on both Dynamics 365 “Tenerife” through AppSource as well as On-Premises (NAV 2018). This means that any efforts and investment made in Dynamics 365 in the Cloud are the same and can be reused On-Premises.
Monetization: Currently, Microsoft does not have a monetization or billing model for Apps that you need to comply with as an ISV. This is good news as it gives you total freedom in how you want to monetize and bill your clients. In the past, you may have billed your Add-on/Extension to .flf file, which allowed to you receive payment from customers through Microsoft. It is not clear if this approach will be still available for On-Premises customers in the future. In turn, the recommendation moving forward is to build your own monetization engine or use a 3rd party monetization provider, like Stripe, to provide a more flexible licensing option in the future.
Modular / Granular: With Extensions 2.0, you can take the opportunity to redesign your solution more granularly. If you have complex functionality, it is advisable to separate basic and advanced functionality to sell to what the customer needs. Implementation can also become more simple, as can maintenance, with a number of smaller apps rather than one large complex application. There is another good reason to build smaller and simpler apps; we believe that the first Dynamics 365 adopters will be smaller customers with simple and basic needs desiring easy to deploy solutions. 1ClickFactory can assist with this solution separation and development granularity if needed.
Listing on Appsource: Having your solution listed on Microsoft AppSource will deliver additional exposure from this popular Microsoft network. This is the perfect spot to showcase your investment into an app(s) with a captive audience to gain you extra visibility in the market.
Business Model: There are numerous considerations to be made in building an appropriate business model for your app(s). Answering these questions will get you started: Do you want to apply a subscription model? Are you renting the software or still selling a license? Will you sell through AppSource, through partners or directly? How much can you charge for the App, if it is on a subscription? What will you do with all the services you normally sell; in a subscription model they have to be embedded to a greater extent? While you are considering all of these things, you also need to think about how to avoid cannibalizing your current business. Given that you are changing technology that draws quite a few questions marks, but this is also a time of advantage for you, as it forces you to consider an adjustment to your business model for the future.
Are there Extensions 2.0 advantages over Add-Ons?
There are number of reasons to transform Add-ons to Extensions. The primary benefit is to make your solution available worldwide as an app on AppSource. For more detailed info please review our blog: Why Transform Add-ons to Extensions for NAV 2017. Extensions make your upgrades and your customers’ lives easier by enabling smooth and regular updates of your solution and annual upgrades of NAV platform to capitalize on new technologies as well as to offer new services to your customers that deliver greater value to them.
If your current revenue is heavily generated from your development services, now is a good time to review and consider your business model moving forward.
What are the next steps with Extensions 2.0?
There are few steps you should undertake to make your transition to Extensions 2.0 smoother:
1. Build a business case. Upgrading to Extensions is a significant move in terms of investment. Therefore, such decision requires thorough analysis of both product and market. You should have answers to such questions as: (1) what is your market opportunity and go to market plan? (2) which market segment (Small Business, Mid-Market or Enterprise) should you focus your App(s) on? (3) should these be split it into different modules? (4) what are the monetization options? (5) What are potential technical challenges?
1ClickFactory can help you answer these questions and prepare for a smooth transition to Extensions. Together we would review all the possible transition models, then show you how to perform the transformation in small steps resulting in a detailed business plan, including rough cost and time estimates.
2. Minimize the gap between your ISV functionality readiness for Extensions 2.0 as much as possible. Prepare your solution for Extensions in parallel to Extensions 2.0 technology development and ensure you move to Extensions 2.0 in time and without any major challenges. The transition to Extensions can be a big investment in budget and time, but if you start now, you can better plan to optimize the level of investment required.
If your current solution is on NAV 2016 or NAV 2017, you can move customizations to Events now. 1ClickFactory can get you ready for this transition by sharing our know-how with your development team. Or we can help you define the scope of the project using an Add-On transition to Extension plan with high-level estimates, stages and timelines. Optionally, such development project could be defined as a split of the work between you, the ISV, and 1ClickFactory, to make sure that the knowledge around Extensions 2.0 is transitioned properly to your team.
3. When Extensions 2.0 is eventually stable and ready, take advantage of it and easily transform your solution.
This is the perfect time to take advantage of new technology. Partners who start working on their Extensions 2.0 App now will be ready to launch together with “Tenerife”, getting the added exposure of have the possibility to be part of what might be one of the larger launches in recent years.
Contact us to discuss your solution transition to Extensions in more detail today.