Layering vs. Extensions: what are they and how are they different?
In a review of Dynamics 365 Extensions, it’s important to begin by becoming familiar with the most recent version product names. In this article, we are specifically referring to Dynamics 365 for Finance and Operations – Enterprise Edition, which was previously called Dynamics AX. The next version released after Dynamics AX 2012 was Dynamics AX 7 which was then rebranded as
With the evolution of Microsoft Dynamics through these versions over the past five years, significant milestones have been achieved and the development platform is no exception. We’ll dive more deeply into these changes and discuss the benefits that your organization can reap by using the latest development tools to
The Dynamics AX user community is very familiar with the customization concept called layering. While there are several key benefits of layering, the three types of cost - time, expense and risk - cannot be overlooked. The next generation of customization, known as Extensions, now available for Dynamics 365 for Finance and Operations – Enterprise Edition, replaces layering as the environment that developers can now use to extend the core functionality.
In a future article, we will provide more detail on the Extension model and how it overcomes some of the challenges faced by organizations using the layering model with Dynamics AX.
How did layering work in Dynamics AX?
The concept of over-layering meant that third-party software companies and value-added resellers could also take the Microsoft code and change it to do whatever the customer needed. The code was not as freely available as Open Source; but, for a fee, both developers and
For example, let’s consider a sales order object, which contains tables, classes, and methods. Developers could take the code from Microsoft for these objects and insert their code directly into the relevant area of the object’s code - you could interrupt it, shut it down, or extend it to take any action that was required to meet the customer’s business logic.
The ‘layers’ were segregated into the following levels:
- System layer – Microsoft Dynamics AX code.
- ISV layer – Approved Microsoft software vendors could modify System layer in the ISV layer.
- VAR layer – Implementers could modify both the ISV and the System layer in the VAR layer of code.
- Customer layer – Developers from the customer’s organization could modify code from all three layers above to meet the needs of their business.
This model gave customers enormous flexibility by allowing them to make changes to any of these layers. All layers in the model are visible with the code, with the highest layer as the one being executed. This layering concept gave the customer the ability to ensure the system behaved in exactly the manner that was required.
But these benefits came at a cost …
While all of this flexibility sounds good, there was a problem, and a very costly one at that. Companies that customized the code in their layers extensively got ‘version locked.' This means that they were not able to upgrade to the latest version of the ERP software without spending a huge amount of time and money on development resources to bring all of their customizations up-to-date.
If Microsoft issued a
For example, companies using an ISV layer could not accept any updates from the system layer until the ISV had made the investment to analyze, refactor and reprogram their code to work with the Microsoft update in the system layer. Each layer owner is required to determine where all the conflicts may exist and update the code to ensure that it functions correctly across all the layers.
The costs of this process should not be underestimated.
It’s expensive. The development/testing process and the process of putting new code into production can be extremely high. Additional developers and consultants are required to ensure that all of the code is updated and working seamlessly with every other part. Often, these ‘mini-implementation’ costs are only adding a series of patches to the solution with no additional value-added functionality to drive a positive ROI.
It takes time. Ensuring all the layers are updated can take a considerable amount of time as each layer has an owner who may not make the changes in a timely manner.
It’s risky. A customer using an ISV application in which the ISV is not adequately resourced to make the required changes to their code adds risk to your business, as no changes can be made until the ISV layer is updated. This is especially risky for mission-critical functionality.
In summary, the layering model worked well for the implementation and management of customizations, but maintaining them and moving them to a newer version was expensive, time-consuming, and risky. The implementation of updates or patches became their own mini implementations which resulted in companies becoming version-locked very quickly.
While the Dynamics AX community has lived with these challenges for about 15 years, the launch of Dynamics 365 brings a new model for customizations, called Extensions, to
The Extensions model enables any organization to customize the functionality of Dynamics 365 by creating side Extensions and thereby making no changes to the core system code. This new model avoids version-locking and allows organizations to remain current on their Dynamics 365 version without having to invest in significant development and consultancy resources.
In a future article, we will discuss the details of the Extensions model in more depth. For more information on getting started with Dynamics 365 for Finance and Operations, don’t hesitate to