Configuration and Customization: Enemies or Brothers in Arms?
Author: Satsang Randhelia
Recently I bought a Trek 4500 MTB. As I saw it being put together I couldn’t help but draw a parallel with how we assist our clients implement service management tools. The mechanic started with fitting the basic parts like tyres, pedals, and handle bar etc on the frame, he then adjusted the brake wires, derailleur and the saddle post for my safe and comfortable riding. (Likewise we put together the available modules of the ITSM tool and use their features to support the client’s business requirements. We call it tool configuration). Since I planned to ride mostly on the road, the mechanic suggested replacing the default thick tyres with thinner slick tyres. (Likewise we suggest code modifications in existing modules of the ITSM tools. We call it tool customization)
Back to business, in the ITSM world so much has been talked about the benefits of configuration over customization that the latter has almost become a curse. While there is no denying the fact that in comparison,
- Configuration is economical in terms of both time and money
- Configuration can be done with relative ease, sometimes by the customers themselves
- Configuration enables a simpler and cheaper upgrade path in most cases
Does that make it simple enough to praise configuration as a "gallant hero" that can win your war and discard customization a "nasty villain" that can defeat you? Analyze this.
As in the bicycle world I'd love to buy a ready-to-use bike, so in the ITSM world the clients would love to get a fully configurable tool. However, as Eric Cooper says, even in the best case scenario a tool can only meet 80% of the requirements through configuration. The remaining requirements are to be met through customization.
Let us try to see what really drives customization?
For starters it could be the choice of the tool itself. Jayson says, “I’ve seen many clients use their incident management modules to double up for change management or service request management.“ Now this calls for a lot of customization.
Another reason could be that either the tools or the client’s ITSM processes are not mature enough. In either case the tool needs to be customized and mapped to the prevailing processes. (However over the years both the tools as well as clients’ ITSM processes are getting aligned to industry best practices so this category of customizations will reduce over time)
Yet another reason lies in the emergence of new unsupported requirements owing to the changing business environment, regulatory and statutory norms etc. The tool vendors try to play cat and mouse, but the business requirements keep up the pace and are always 2 steps ahead of what the tools can offer.
Yet, another reason lies in the uniqueness of every business. While there are a set of common best practices applicable across organizations, every business is different and has special requirements (e.g. additional fields in request forms, number of approval stages based on risk level etc) that cannot be fulfilled just by configuring a generic tool.
Shraddha in her blog talks about a couple of other organization specific reasons that drive tool customization.
Until all such reasons cease to exist, configuration alone will not be able to fulfill the business requirements and customization will continue to come to the rescue in bridging the gap.
Though customization may not be as elegant in terms of cost, time and future readiness, it is more powerful and can achieve more than configuration alone. The problem arises only when customization is being touted in place of configuration. This happens when the available features of the tool are not properly understood by the implementers.
Hence, it is not a question of “A v/s B”. Both are merely means to a common goal. Both have unique capabilities and none alone can fulfill all your needs. The essence lies in the decision of using the right means at the right time, and it’s something like A -> B.
So if someone asks me “how should I approach fitting a bike?” I’d say
- Step 1: Choose the right bike, if you plan to ride on the road, pick a road bike and do not use your MTB to double up as a road bike.
- Step 2: Get it fitted by an expert mechanic who knows exactly what to adjust and what to replace.
- Step 3: Allow the expert to first exhaust all configurations like fixing, adjusting, fine-tuning etc of existing parts.
- Step 4: Accept customization suggestions like parts modification or replacement in the end to cover the last mile of your unique riding needs.
And probably one could use the same advice for ITSM tools implementation 
Comments
Satsang - I'm honored that you thought enough about my article to quote me, but unfortunately you didn't get it quite right. Your qoute of me was "Eric Cooper says, even in the best case scenario a tool can only meet 80% of the requirements through configuration. The remaining requirements are to be met through customization." What I actually said was "The best case scenario is that the software you purchase will only meet 80% of your requirements and that the other 20% will have to be achieved through some sort of customization, modification, or configuration. In some instances the gap could be much greater." Enterprise Software: Knowing the Real Difference Between Customization vs. Configuration
The point I was trying to make is that when it comes to enterprise level software, out-of-the-box functionality is unlikely to ever meeting 100% of your business requirements. The rest must come either via customization of the code or configuration of the software.
You're absolutely right that customization can be very powerful. With custom code you can build an application that 100% meets the customer's requirements. All of the shiny cool features that the business might want can be programmed in. However, there's a trade-off. Custom code can not normally be upgraded without significant time and cost. One major document control application that my previous company had purchased was like this. In order to meet all of their requirements, the vendor had to modify the base code - despite all of IT's warnings, they decidede to purchase it anyway. A few years later my company wanted to upgrade to the latest version. "Sure, we can do that" the vendor said "for 1 million dollars". And that figure isn't a joke - that's what the quote was.
So the bottom line comes down to cost/benefit. If through configuration you can not achieve what you're looking for, then A) you've either chosen the wrong software app; B) you'll need to change your requirements to accommodated the app or; C) you'll need to accept customizations and all that that entails.
Posted by: Eric Cooper | January 18, 2010 12:41 PM
Thanks Satsang for quoting my points related to Customization needs, into your blog. The blog very rightly points out the need of both configuration as well as customization in any tool environment. The real challenge with a highly customized environment is maintaining and porting these customization during a software upgrade.
I agree with your view point, with whole service management industry maturing over a period, the need for customization might gradually come down. Thats when alone configuartion could give the expected benefits, untill than both configuration and customization are brothers in arms.
Posted by: Shraddha Tilloo | January 20, 2010 04:19 AM
Dear Eric,
It made my day to see yours as the first comment on my blog. Thanks a lot!
What you refer to as purchased software (out-of-box), configuration, modification and customization, I refer to as just configuration and customization for the sake of simplicity. Also I believe there is no such thing like out-of-box software usage.
In my previous role I worked as a tools implementer and implemented Microsoft Commerce Server for a large US Chemicals Company. From that experience I realized that any out-of-box software can be used only after proper modules integration, adding business data and rules etc which I collectively refer to as software configuration. I consider out-of-box software and configuration in one bucket and modification and customization in another.
So while I have different buckets than your, I quoted you in this context to drive the point that out-of-box software and its configuration cannot meet all the business requirements.
It is not a surprise to hear what happened with the document control application in your previous company. It is a classic case of the customization horror stories that I've talked about in my blog. In retrospect what do you think were the reasons? Was the choice of application right? Did the implementers have enough knowledge of the tool? Were all configuration options exhausted before customization? If the answer to any of these is a No then you'd agree that customization was a wrong means used at a wrong place.
The key message I wish to convey is that
A) Customizations cannot be avoided
B) Software Implementation should follow a sequential method (as laid out in the last part of the blog).
Once the point of customization is reached, I agree to you that it comes down to the cost/benefit analysis. I'd take it further by saying that instead of considering the one-time cost, the lifetime cost of customization (including the upgrade cost guestimate) should be considered against the benefits achieved.
So the sequence now becomes
Step 1: Choose right software
Step 2: Choose right implementer
Step 3: Exhaust all configuration options
Step 4: Conduct lifetime cost/benefit analysis for customization
Step 5: Implement positive value customizations and discard the rest
Eric - Thanks again for enriching my post.
Posted by: Satsang Randhelia | January 20, 2010 06:27 AM