Configuration vs Customization: When and why would I implement each?

by Alan Rencher

​First off, what is a customization and what is a configuration?  A customization is a feature or extension or modification of a software feature that requires custom coding and or some form of implementation.  A configuration is where you use native tools in the system to change it’s behavior or features.  Wait you may be asking, those sound very, very similar.  They are similar.  The key differentiation between a customization and a configuration is this:  Does the work done to enhance the feature or extend it’s capability roll with an upgrade? in other words, when the software vendor releases the next version of the system, does the work you did require work to be done?  If you answer yes, you have a customization!  Congratulations!
There has been a shift in the industry in the last few years. A far-reaching and important shift in how we fundamentally think about software, specifically purchased software.  Software that is purchased tends to be tailored for a very specific purpose.  Think of low-end consumer purchased software, things like Microsoft office products or Apple’s iTunes.  These software suite’s are purchased to fit a very specific need.  Would you ever consider customizing them?  That is, opening up or de-compiling their binary files and inserting your own logic or your own features?  Even if this were something that would be relatively easy to do, nobody in their right mind would try.  AS soon as Microsoft or Apple released a newer version, what would happen to all of your customizations?  That’s correct, they would all break.  This is a simplistic example but a valuable one.  Let’s examine some similar examples in the automotive space.  When you purchase a new car, all manufacturers give you options to configure your new car in many ways.  You can have different kinds of wheels, a more powerful engine, standard versus manual transmissions, paint job, leather seats, etc.  You would never consider purchasing a new car and then adding a new kind of engine that you built yourself.  Or maybe you would?  The photographs above show a standard configured vehicle and a “customized” vehicle.  Perhaps you may want to customize your vehicle.  Once you start those customization, you invalidate your warranty.  Surely you could find technicians and others to help you maintain and enhance your car customizations, it wouldn’t be cheap and it wouldn’t be very fast either and if you were to try and find a new technician to help your customized vehicle, it would take some time for these technicians to “get up to speed” on your customized vehicle.  The overall TCO [total cost of ownership] for the customized car would be far greater than the stock or “configured” car.  Another consideration for these vehicles would be the need for regulatory compliance.  When you purchase a configured vehicle, it comes with the guarantee that it is compliant with all governing bodies.  Some examples may include crash safety, EPA emissions and others.  Can you imagine the cost and time it would take to get these regulatory compliance certifications on your own custom car?
Before you email or message me and complain that the automotive market is different than the software market, let me preemptively say that they are close enough.  I cannot count the number of times I have seen companies and other organizations purchase software and then heavily customize it and then a year or two later openly question why they allowed that to happen?  In the ERP software space this is a rampant problem that has actually put many organization out of business.   Having planned, participated in, executed on several ERP roll-outs and upgrades, I can tell you that customizing software is a bad idea 99.9999% of the time.  In other words, it is always a bad idea.  Your organization is better off writing the software yourself rather than purchasing it and customizing it.
The next question you are asking is pretty logical:  When and how do I help my organization NOT customize?  Enterprise Architecture typically follows a solution pattern like this that helps someone planning or implementing a solution to ask these questions in this order:

Follow the chart above. If it is too small, click on it in a new tab. Notice that the process starts with the “need for a solution” and quickly turns into a requirements and business analysis activity. Once this is completed, the very first thing that should happen is the discussion around whether or not a purchased solution can be found. It is unlikely that an exact 100% requirements match will be found. I have seen this happen once or twice in the hundreds of solutions I have architected and worked on but it is quite rare. In most cases, solutions you purchase and configure will cover 75%-80% of your requirements. When you have this kind of requirements coverage you are on to a good product. If there is not a good solution you can purchase, you still have several options. This is typically what the industry refers to a “product development” or solution implementation. You have many options here: Full-blown software development where you start from scratch and build something ion a 3GL programming language. This is probably a measure of last resort. In this scenario you are doing something that differentiates your business or organization somehow. I will save that topic for another post. If the requirements coverage is low [below 75% or so], you may consider a composite application strategy. What’s that you may be asking?  A composite application is a an application that is really just a custom interface that uses a purchased or packaged system underneath.  The idea behind a composite application is typically to provide a much more simple user interface or to surface the functionality of the underlying system in a channel or way not intended by the original underlying system.  Perhaps Composite Application Strategy deserves it’s own post.  But that is the simple explanation for it.  If a composite application strategy cannot be achieved, you may then start to talk about customizing your purchased system.  When you do customize, make sure you understand that you are making some very, very expensive decisions and you will be paying for these customization every time you upgrade or try and patch you system.  Customizations are a measure of last resort, PERIOD!