How Extensions overcomes the costs of layered modifications
Microsoft’s Dynamics 365 for Finance and Operations is cloud-native ERP. As with any cloud-based service or application, the benefit for enterprises is that they can pay for and use only the services they need and avoid making investments in hardware, infrastructure, and ongoing maintenance that are required to make the software run effectively.
Successful implementations of cloud-native solutions, however, require that companies remain current on the technology, including new development platforms.
The Dynamics AX community is very familiar with the customization concept called layering. While there are several key benefits of layering, the three primary costs of time, expense, and risks cannot be overlooked. In a previous article, we reviewed these challenges in detail. The primary result of the layering model was that many companies became ‘version-locked’ into old versions of Dynamics AX because the customizations they had deployed were too costly to update.
To make Dynamics 365 running on Microsoft Azure a reality, Microsoft made significant changes to the customization methodology to support regular product updates. Hence, a new generation of how customizations would be handled was required. In this article, we dive deeper into Extensions, which is the new customization platform for – Enterprise Edition.
What are the changes between Dynamics AX 2012 and Dynamics 365?
While there have been changes in the Dynamics 365 user interface, the business logic and table structure had initially remained unchanged. The most significant changes are ‘in the plumbing’ on the backend. The entire development platform and operating environment with Azure have changed dramatically to deliver on the goal of a .
In the previous versions of Dynamics AX, we had System, ISV, VAR and Customer layers that made up the development environment, but in the new world of extensions, we now have:
- Foundation - the core code base that ties everything together. This code is universal across everything.
- Platform – the code here is tied into the other parts of the Microsoft platform, such as Azure. As an example, the platform layer will be updated frequently to ensure that any changes to Azure and other components of the platform are in alignment.
- Application – this is where the code that drives features and functions, such as purchasing logic, sales logic, or finance logic, lives. This code will get updated a few times per year. Some of the updates will be simple patches and others will offer new and meaningful functional enhancements.
As a cloud service provider, Microsoft is also responsible for hosting your solution and providing you with these updates on-demand. Since Microsoft can’t manage the maintenance of all the derivative customizations that every company is making and maintain their SLA-backed accountability to deliver the system management and service uptime, they require their clients to make the updates more frequently than in the past.
To achieve the goal of customers being current on the Microsoft code base, Microsoft introduced the Extensions model for customizations.
The Extensions model requires no changes to the core Microsoft code.
The Layering development paradigm goes away as it was causing customers to be version-locked. With Extensions, customers are not modifying code at the object layer; rather, code is created ‘off to the side’ and hooking back as an extension of the code, triggered by events.
For example, consider a sales order object. Suppose we wanted to change the method of calculating the sales price. In the layered model, we would have modified the Microsoft code to change how the price is calculated. With Extensions, no changes to the core code are required. Instead, an event activates code on the side which may turn off part of the Microsoft code and activate the to calculate the sales price in accordance with the business rules.
One of the primary differences between the two models – layering and extensions – is that now we also have a framework that allows implementation partners to tie their enhancements to the Microsoft Extension model. For example, when Microsoft makes a change to the underlying code base, if the event that triggered the Extension is still available in the system, the customized code will not be affected by any new code that Microsoft adds to the core code base. Microsoft even provides developers and implementation partners the tools to check if any of the events that they’ve added extensions to have been updated.
While a good development/test and roll out to production regimen is still a need for companies with Dynamics 365 Extensions, the days of re-coding in a sandbox for weeks and months are no longer required to ensure that all pieces of code are working seamlessly together. Instead, running an Extensions tool will check which events are affected and highlight code which may be affected. You should still do acceptance testing but the risk of significant conflicts is now the exception when it used to be the rule.
The risks associated with taking an update from Microsoft or creating your own are significantly reduced. If all owners in the application layer follow the same guidelines in modifying extensions to the code base, companies should not find themselves version-locked as they previously did with the layering model. Moreover, customers should vet their partners and ISVs for their support of this development methodology.
Another benefit of the cloud is that Microsoft has invested to create a marketplace of third-party applications for Dynamics 365 and Azure, called . On AppSource, you can search for both rich applications that provide solutions for complex business processes or find small add-on’s or enhancements. The extension model creates an easy to support architecture that should see a marked increase small non-invasive value adds to the Dynamics 365 ecosystem. Developers can create these small, reusable solutions and add them to the app store to provide additional value to users instead of having each company build these customizations independently for their own system. This gives enterprises a lot of options for these lightweight, smaller enhancements specific to one task or process rather than having to invest in large applications that may be too complex for their needs. The cloud means that companies can pick and choose what they need, when they need it. With AppSource, you also have a curated marketplace where you can trust that Microsoft enforces the coding standards that support this new paradigm.
Research shows that are also far lower for organizations that maintain current versions of applications. The extensions model significantly reduces the risks in upgrading to current technology, which is often more secure and uses computing resources more efficiently.
Microsoft is doing everything they can on the platform side to make staying up-to-date a low-risk proposition, preventing stagnation in your business processes hampered by ‘the system’.
In summary, this new era of Extensions for Dynamics 365 is truly a breakthrough for developers and users. Extensions reduces the expense that was required to customize the applications and maintain updates and upgrades. AppSource also provides companies with a marketplace of enhancements and apps from third parties that provide choices and flexibility in tailoring Dynamics 365 to meet specific business requirements.
Western Computer is helping many customers get started using the Extension model and the best-in-class solutions for their industry on AppSource.
For more information on getting started with Dynamics 365 for Finance and Operations, don’t hesitate to of Microsoft Dynamics experts.
