The message should have gotten through load and clear by now, customisation of Dynamics 365 for Operations (AX7) should, wherever possible, be done using Extensions. Your development team should have seen this being hammered home by Microsoft and the D365 community over the past months and especially since Microsoft told us that the Application Suite will be sealed by spring 2018. So how do you stop your development team from falling back on old habits by using their tried and test over layering techniques?
If, like many development teams, you have developers that have been X++ developers for a number of years then there’s certainly a danger that old habits will die hard. We are all creatures of habit and it is sometimes hard to get new techniques adopted, especially when the means to apply them in some situations isn’t immediately obvious. It is so much easier to just do as we have always done then to find ways to implement the same feature using an unfamiliar approach.
With Application Foundation already sealed against over layering and Application Suite soon to follow, it should be clear what the direction that Microsoft are going in. It may be that a completely sealed application is a few years away but, in my view, it is definitely on the horizon. With that in mind, building any solution now that uses over layering techniques ought to be done with extreme care and only as a last resort…possibly even not at all. Every time you over layer you risk building something that cannot be upgraded and you don’t want to be around when you have to explain that to your customer.
You can’t do that any more
At Technical Conference this year, one presenter talking about the sealing of Application Suite said we had three options when hitting a situation where we needed to customise using over layering because the Extensions story wasn’t yet complete enough.
- Talk to Microsoft about the situation and get them to change the underlying application to provide an Extension hook that you can use
- Redesign your solution so that you do not need to over layer
- Accept that you cannot build the solution that your customer wants
That last point seems crazy. One of the great things about the AX platform has always been that you could build almost anything with it and we’re all well used to this. The idea that we might have to say “sorry but you can’t have that feature” just doesn’t sit well but it most definitely is something that the community will have to get used to.
So how do we adapt to this monumental change? How do we start to make the use of Extension techniques our first and, perhaps, only means of customising the application?
The answer has to lie in not accepting anything but Extensions in your solution and to robustly challenge every use of over layering. You need an Extensions Gatekeeper role in your development team whose job it is to protect the code you produce from habitual over layering. You’ll want this person to be someone that is enthused by the idea of Extensions, who understands that it’s the key to upgradeable code and who has the imagination to find alternative ways to implement over layered solutions. Change your processes so that every use of over layering must be approved by the Extensions Gatekeeper and keep a log of each instance where over layering is approved so that you’ll know where your future upgrade problems might come from.
Your Gatekeeper will need the authority to push for solution redesign when the existing design cannot be implemented without over layering. There may be times when you choose not to redesign but such choices need to be taken with eyes wide open throughout your implementation team.
Adjusting to the Extension model is going to take time but the sooner we embrace it the easier the adjustment will be.