Customizability vs. Configurability
We started out with a neat schedule. 6 Months, revamp the entire system. Everything will be up and running by October. But, then changes happened. A team member got pulled-out, new tasks come in, and what makes matters worse, we now have changes in the direction of the business development that changes how we design the system.
The previous system design was meant for high-customizability across multiple deployments where each deployment is a customized system, i.e. I've identified possible points of customizations and have taken them out so developers need not search through tonnes of code just to find that one liner that he has to customize.
The new system design is meant to be for high-configurability across multiple deployments where every deployment is actually the same system - just the configurations are different.
The business motivations and even implications of the two systems differ. High-customizable systems are meant to get the biggest buck for the bang. We go out and tell clients "we'll do everything you want us to as long as you pay." This translates to high development costs and requiring at least a team to maintain the system for as long as
that one client remains your client.
High-configurable systems are meant to get the biggest bang for the buck. We go out and tell clients that we have a product, that they can use what we have if they want to, if they need more, too bad. Lower costs for us, lower costs for the clients, and since we have one system for all clients, we don't have to bleed ourselves dry in maintaining a different system for every client.
High-customizable systems are perfect for market with big players with complex needs and also the money to get customized solutions. We won't mind having high development costs because the maintenance fees for this behemoth of customized systems are very profitable. For some large IT consulting companies (I won't mention any names), this is their livelihood. Imagine a 7 digit implementation fees and the 10 to 15% annual maintenance fees for as long as your client is in business. That's good money.
High-configurable systems are better suited for markets with many small-medium sized players whose needs are not complex enough to warrant a customized solution - any thing that works would be good enough for them. Money isn't made from maintenance. Money is made from selling quality products to as many of these guys as possible, and making sure they keep buying your product upgrades.
How you sell these systems differ too. When you sell things that are custom-tailored, whether it's a suite, a plate of fried rice, or a health insurance claims processing system, you don't go out showing "the real thing"; instead, you go around carrying a catalogue of what you can build. Tailors have their own big black book of fashion, restaurants have menus, and we have our HTML prototypes. And since we have not sown, cooked, or programmed what we wish to sell, most of time, energy, resources is spent on gathering requirements, whether it is measuring your clients torso size, asking whether he wants his chicken spicy, or whether he wants the button on the top of the screen instead of at the bottom.
Selling highly-configurable products is a different ball-game. You already have the real-thing. So instead of going around carrying a catalogue or a menu, you go around showing what you have in the form of a live demo, or even a scaled-down version of the real thing which your client can download and play around with. Time and resources won't be spent on gathering requirements, but instead will be spent on showing your clients that what they need can be done on your system.
Most software systems start out as highly-customizable systems, then they slowly evolve into highly-configurable systems. The reason being that only after you gather enough knowledge about your clients and enough experience in solving their specific problems that you can confidently build a product that is generic enough to solve everyone's
common problems.
Okay, enough rambling from me for this morning. Gotta get back to work.
The previous system design was meant for high-customizability across multiple deployments where each deployment is a customized system, i.e. I've identified possible points of customizations and have taken them out so developers need not search through tonnes of code just to find that one liner that he has to customize.
The new system design is meant to be for high-configurability across multiple deployments where every deployment is actually the same system - just the configurations are different.
The business motivations and even implications of the two systems differ. High-customizable systems are meant to get the biggest buck for the bang. We go out and tell clients "we'll do everything you want us to as long as you pay." This translates to high development costs and requiring at least a team to maintain the system for as long as
that one client remains your client.
High-configurable systems are meant to get the biggest bang for the buck. We go out and tell clients that we have a product, that they can use what we have if they want to, if they need more, too bad. Lower costs for us, lower costs for the clients, and since we have one system for all clients, we don't have to bleed ourselves dry in maintaining a different system for every client.
High-customizable systems are perfect for market with big players with complex needs and also the money to get customized solutions. We won't mind having high development costs because the maintenance fees for this behemoth of customized systems are very profitable. For some large IT consulting companies (I won't mention any names), this is their livelihood. Imagine a 7 digit implementation fees and the 10 to 15% annual maintenance fees for as long as your client is in business. That's good money.
High-configurable systems are better suited for markets with many small-medium sized players whose needs are not complex enough to warrant a customized solution - any thing that works would be good enough for them. Money isn't made from maintenance. Money is made from selling quality products to as many of these guys as possible, and making sure they keep buying your product upgrades.
How you sell these systems differ too. When you sell things that are custom-tailored, whether it's a suite, a plate of fried rice, or a health insurance claims processing system, you don't go out showing "the real thing"; instead, you go around carrying a catalogue of what you can build. Tailors have their own big black book of fashion, restaurants have menus, and we have our HTML prototypes. And since we have not sown, cooked, or programmed what we wish to sell, most of time, energy, resources is spent on gathering requirements, whether it is measuring your clients torso size, asking whether he wants his chicken spicy, or whether he wants the button on the top of the screen instead of at the bottom.
Selling highly-configurable products is a different ball-game. You already have the real-thing. So instead of going around carrying a catalogue or a menu, you go around showing what you have in the form of a live demo, or even a scaled-down version of the real thing which your client can download and play around with. Time and resources won't be spent on gathering requirements, but instead will be spent on showing your clients that what they need can be done on your system.
Most software systems start out as highly-customizable systems, then they slowly evolve into highly-configurable systems. The reason being that only after you gather enough knowledge about your clients and enough experience in solving their specific problems that you can confidently build a product that is generic enough to solve everyone's
common problems.
Okay, enough rambling from me for this morning. Gotta get back to work.
posted by JPG at
10:24
0 Comments:
Post a Comment
<< Home