Tuesday, November 14, 2017

Why modifying a product at the dexterity level is rarely a good thing

I get requests to customize Dynamics GP and/or Signature all the time.  Over my 17 years of doing this I have tried to pay attention to what works and what doesn't.  Here are my observations:

Above all, keep it simple.  Process trumps code every time.  Many times the process can be simplified and at the same time avoid customization altogether.  Left to their own devices, people tend to complicate processes.  There are many reasons for this, which I will not debate here.  The bottom line is that each business is not as unique as their employees like to think they are.  If hundreds of service companies of a similar size to yours are able to use a piece of software with no modifications, and you think your company absolutely needs that modification, you need to take a hard look at why.

Invariably, there are differences and unique situations that bring about the need for custom code.  In those cases, you should use a minimalist approach, while taking into account long term maintenance.  A customization that you can't afford to maintain over the long haul is not a solution.  The same goes for one that is overly complicated and fragile.

I get a lot of requests where the partner assumes Dexterity is the best fit.  That is almost never the case.  Here is how dexterity mods work:
*** Dynamics GP allows dexterity mods to the core product.  These are called 3rd party products and appear in the dynamics.set file with a number issued by Microsoft.  Signature is basically one great big dexterity mod.
*** Any time Microsoft changes anything about Dynamics GP or the 3rd party that has been modified changes anything (Service packs, version changes, end of year payroll, etc...) the dexterity mods have to be re-evaluated and potentially changed to continue working with the new core Dynamics GP product.  In the case that a dex mod has been done to a 3rd party product, you must wait for the 3rd party dictionary to be re-evaluated, changed, tested, and released.  Then you must start with the new code base and completely re-code the dex mod.
*** The ability of 3rd party dictionaries to talk to each other is limited.

So if you are building a product with functionality that needs to tightly integrate to Dynamics GP, dexterity may be the best solution.  If you are customizing a product, it is always a last resort.


Here are some ways that customizations can be accomplished, and the pro's and cons of each.  I have listed them in order of what is typically lowest cost to highest cost.

Modifier:
This tool is packaged with Dynamics GP and can be used on 3rd party products also.
Pros:
- Relatively cheap to purchase
- With minimal training, one or more of your own employees can make and maintain these types of modifications.
- Visual changes can be made to forms and reports

Cons:
- You can't make any code changes with this
- Report changes are limited

Modifier with VBA:
This tool is packaged with Dynamics GP and can be used on 3rd party products also.
Pros:
- Same as Modifier
- Code can be added
- Long term maintenance costs are low

Cons:
- Although you can easily add code, changing the behavior of the dex code is limited and problematic
- Report changes are limited
- Can be buggy in a multi-user environment

SSRS
Dynamics GP and many 3rd party products have the capability of calling SSRS reports rather than Dexterity reports.  The SSRS report can be customized.
Pros:
- Easy to customize.  Many minor customizations can be done by power users.
- With some care in naming conventions, they can be easy to maintain over time.
- Long term maintenance costs are low.

Cons:
- May need to create a Addin to call a custom SSRS report if the SSRS report does not already exist in the product, or if parameters need to be passed.
- Requires SQL language skills and table structure knowledge to build reports from scratch.


.NET Addins
This tool requires Visual Studio in order to use it.  It can be used on 3rd party products also.  It involves placing custom DLLs in the Addins folder in the GP client.
Pros:
- Robust UI and code ability
- Long term maintenance costs are low.
- Service packs to the product usually require no change at all to the addin
- Can be coded and implemented quickly
- Can easily override and replace most dex logic
- Can easily create entirely new custom windows

Cons:
- Can't override absolutely everything in dex.

Dexterity Mods
This involves creating a custom dexterity dictionary that is added to the dynamics.set file.  The pros and cons below assume you are making changes to a 3rd party.
Pros:
- Can directly and surgically change dexterity code.
- Results in the tightest possible integration to GP.

Cons:
- Difficult or impossible to communicate between 3rd party dictionaries, meaning you have to create a custom version of the 3rd party dictionary in order to make changes.
- Difficult to test and deploy
- Rapidly shrinking pool of proficient dexterity programmers means higher costs and longer wait times.
- Very high long term maintenance costs.  Basically you are re-coding the entire thing each time you do a service pack, meaning you get to pay full price for it over and over as long as you need it.

No comments:

Post a Comment

SQL 2022 TSQL snapshot backups!

  SQL 2022 now actually supports snapshot backups!  More specifically, T-SQL snapshot backups. Of course this is hardware-dependent. Here ...