You Say Integration, I say Automation. You Say Customization, I Say Configuration....
Before we call the whole thing off, we just need to make sure we both have the same definition for the words or concepts we are using when we talk about Microsoft Dynamics projects.
Integration versus Automation
After I wrote the post “Save Money by Doing Your Own Integrations to Dynamics GP” I got into a bit of a twitter debate with fellow Dynamics MVP about the concept of “integrations.” The debate actually resulted in a from Steve.
Finally I realized that we were using the same word to describe two different things.
When Steve "builds an integration" he is actually biting into the code, hooking his product directly into Dynamics GP. He's using tools like Dexterity and the .NET Interop to affect how core GP functionality works or to actually build products that become part of Dynamics GP experience for the end users.
When I "build an integration" I am using tools like to move data into, out of, or around within Dynamics to help remove manual work from a process.
In retrospect, I believe that Steve’s definition of Integration is more correct. What he does truly is integration. He is integrating his software with Dynamics GP. What I am doing is better labelled automation. I'm moving data between systems, or around within a system, and manipulating it in such a way that it makes the process that I'm trying to affect more efficient.
But I’m not going to rewrite that post! If you go read it after reading this, just change the word integration to automation in your head.
Customization versus Configuration
The issue of semantics came up again while I was on site recently with a customer. They wanted a “vanilla system with no customization”. But does that mean the same thing to them as it does to me?
Not so long ago, I had viewed any alteration to how my ERP looked or worked as a customization. But by that definition, using Modifier to change the label on a field or VBA to verify that a date is within an acceptable range would be considered customization. Come to that, using tools like or fall under that definition of customization.
My perceptions changed several years ago, when my manager asked me to reimplement Dynamics GP internally without customizing it. Anyone who knows me, or who read that previous chapter on what I thought customization was, should be able to imagine the look I gave him. When we got to the first field name that I needed to change, I smugly stared at him and said “told you so.” Of course, that was based on a flawed definition.
A customization happens when you change some core way that the software works. This invariably means opening up the code. When guys like Steve work with customers to change some key element of GP, they are in fact customizing the software for that customer. In this case, they are using integration to change the user experience for one specific GP implementation - not to build a product that they will resell.
Changing a label, or adding a little VBA validation to a field isn’t customization. It is better labelled as configuration. Adding entire windows and business logic via Extender is configuration too. There’s no code in this. They key is that you can do all of these things without altering the basic functionality of the ERP. This also makes the development lifecycle dramatically different, requiring much less vigour in the validation phase.
So when the customer said, “I want a vanilla install, I don't want any customization," I needed to ask more questions. Does that also include programmatic configuration where I am using modifier/VBA or Extender to enhance what GP is doing without altering how GP works?
My point is that definitions really matter. We need to make sure we are all speaking the same language when we use words. When you tell your partner you want a vanilla install, make sure you don’t inadvertently rule out configurations too.
So let’s call the calling off off, and just make sure that we are all on the same page, defining the same concepts the same way. That is how we will have more successful Microsoft Dynamics ERP projects together!
If you are evaluating a new accounting system, and want to talk about Dynamics GP or Dynamics 365, contact us at 844-BRIWARE or rod@briwaresolutions.com.
By Briware Solutions,
Follow me on Twitter:
Very creative link to Gershwin and a insightful post Rod! And I agree with you, and of course Steve too!