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 
