One of the common themes I heard during NAEM’s EHS MIS Workshop last March was the question, “Was this configured or customized?”
While presenting to her peers, Patty Miceli used an analogy to describe the philosophy on software customization that her team practiced during the implementation:
“Customization is like shopping at Niemen Marcus. It’s fun to walk by and look in the windows and maybe even go inside and look around. But my experience (and my husband) always tells me to put that credit card away and keep walking.”
Following this anecdote, along with the chuckling, I noticed a lot of head nodding around the room. In presentations thereafter, someone in the crowd invariably raised their hand and asked if the system (or a specific feature) was configured or customized. It was clear the general audience accepted this as an important question, and it also seemed generally accepted that “configuration” was the right answer.
But I had to wonder, does everyone truly understand this technical distinction?
I was surprised that this question was never raised or discussed. If that is because everyone understands this distinction, do we all accept the same definitions and differentiators? Is there a common understanding of the specific pros and cons of each approach? Is everyone who asks this basic question able to drill down to specific questions that reveal to what extent a system would need to be configured and customized to meet their objectives? Because without this understanding, the basic question is arguably a vague one open to much interpretation.
These uncertainties led me to a discussion with our Chief Architect, Jack Jones, and some of our customers who were in attendance at the workshop. We decided to write a white paper to outline the facts as well as our perspective on the subject.
In a nutshell, yes, the generally accepted rule is to avoid customization. This will keep your implementation simple, your costs down, and your upgrade path unconstrained. However, there are certain circumstances in which some level of customization may not necessarily be the wrong answer. If customization is determined to be necessary or add sufficient value, the key is to understand how it is managed within the infrastructure of the core system, and exactly what the implications and risks are for implementation, maintenance and support.
What are your experiences with customizing or configuring software to fit your needs? Any lessons you think could be valuable to those going through the selection or implementation process today?