Change your default approach

One of the things that I’ve learned from my experience with customers and partners is that the easiest way is often the go-to way.  Unfortunately, like in many areas of business, the easiest way does not result in the best way.  With D365 though, the easy way often leads to serious problems: performance problems, memory issues, crashes, and other generally terrible things. Microsoft provides many different frameworks and different systems to utilize and build upon for success, but each framework and system comes with complications and challenges.  The resulting gut instinct is to skip the Microsoft complexity and do what seems easy, after all, is all that extra work really necessary? The old saying in programming, “You can have only two things from the list: cheap, good, or quick.” When it comes time to choose, customers almost always pick cheap and quick. This means that the tools that Microsoft provided to help be successful are quickly found to be roadblocks, and a new path is blazed.

Two sides of the development coin

Microsoft is a giant company, but the work is split in teams (to nobody’s surprise).  The size of the teams for D365 projects are often quite smaller, probably smaller than most people think.  Now, what some people probably do not think about is, in my opinion, the best of the best are working on the frameworks and establishing backend systems.  They build the essentials, they build the structures that others can use, these are the The A-team members. Does that mean there are no flaws? Of course not, it’s extremely complicated work, but this is where the time is spent.

The other side of development is the feature work, the new stuff for customers that help continue to evolve the product.  Overall, feature development is check-a-box development. If you don’t know what that means, the higher ups want something and they want it by a certain time, so even if that doesn’t look pretty it is released – box checked.  If you want a recent example look at the Invoice Capture feature. 

Frameworks

If you are new to frameworks, you might be wondering what I mean.  Frameworks are a foundation that you can build upon and use without having to recreate the wheel. Microsoft provides these as a mechanism to reduce the amount of work necessary while providing flexibility to expand areas of the product to meet complex business needs. One example would be DMF, the data migration framework. Microsoft created a way to import and export data using entities where much of the complicated mapping logic is handled in the background. 

D365FO has other frameworks as well, for security, testing, batch, and other areas.  Each framework has its uses and challenges.

Systems

Obviously, system is an extremely broad word, and we could place a lot into that bucket.  The emphasis here is more on systems that aren’t true frameworks but are provided to allow flexibility and quality in what you build.  An example here would be Chain of Command (CoC). It’s not a framework to implement but a system that allows code to be added into key business processes to change the behavior of standard functionality.

Another system here would be field level security.  Microsoft provides a way to implement it, a system to use, and it allows security to be implemented to the field level on the form. While not a true framework, it is there to restrict access to fields on forms for certain security roles. These are the types of systems that I’m thinking about – internal systems that help establish principles and approaches that allow customizations to fit into the rest of the ecosystem seamlessly.

Approaching D365FO Intelligently

The point of the context here is that when choosing a partner, looking for an ISV solution, or simply researching to build your own custom solution, make sure you understand what the proposed solutions.  Generally speaking, the best solutions are going to expand upon what Microsoft has provided.  If a partner is offering their own custom integration solution, be wary.  If the ISV is offering a new way to perform tax outside of the Microsoft tax code, be cautious.  Your custom solution offers a new way to handle printing, think twice.

When working with partners or ISVs, have internal developers review the code if possible.  Look for shortcuts in coding, such as skipping CoC code to inject custom code that does not use Microsoft’s.  If your team identifies those lazy coding practices, run far away from that partner or ISV. See if the partner or ISV is offering a whole new solution because “Microsoft’s solution is clunky.”  I would avoid those who are scared to use what Microsoft has provided or talk about the difficulty of building on what Microsoft provided. While Microsoft might not always provide the easiest frameworks or systems to use, the more a partner or ISV strays from them the more at risk you are of being overcharged for low quality work. 

If you are a customer bringing old AX into D365, look at those customizations and you had and see what you can discard.  The more time you spend building on the new systems and working with the new frameworks, the better your experience is going to be.  Dragging the antiquated code should not be the default, but a choice when it fits within the D365 world nicely.

From experience, most performance issues and crashing AOS issues come from custom code. Reducing the risk of introducing more issues into the system is the main reason the frameworks and systems exist. Microsoft is trying to provide the ability to be successful, even if it takes effort. The further away from the underlying systems Microsoft provided the more room for error is introduced. It can be hard for a customer coming into the process trying to determine if the partner you are considering working with or the ISV you are interested in purchasing is good.  Understanding their philosophy when approaching customizations would be good starting point: are they building on what’s there or are they pitching a new wheel? While you are at, check your philosophy as a customer and determine if you are willing to give your team time to build quality solutions.

Quality comes from building on the foundations that are there.  The foundation does not have to be pretty.  If you are struggling with clunky systems then find ways to improve them, not build new ones.  A partner or ISV should be looking at extending what Microsoft has established and refining it for the needs of customers.  Need more Print Management capabilities? Don’t try to create a new way of printing, instead find ways to extend and enhance the Print Management capabilities (which some ISVs have done).  Problems with the DMF user experience? Then enhance the DMF process and make it better; build on the foundation that is there and improve the experience. Quality takes effort.  Anybody can check a box.

NOTE: I’m approaching this at a high level, a very high level.  This is not a technical analysis of any specific partner or ISV code.  The goal here is simple to highlight the issue and bring general guidance on the issue. There are ALWAYS exceptions.