{"id":42005,"date":"2015-07-23T10:00:38","date_gmt":"2015-07-23T07:00:38","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=42005"},"modified":"2015-07-30T09:58:18","modified_gmt":"2015-07-30T06:58:18","slug":"how-to-develop-a-highly-customizable-product","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2015\/07\/how-to-develop-a-highly-customizable-product.html","title":{"rendered":"How to Develop a Highly Customizable Product"},"content":{"rendered":"

Have you ever heard: ‘We really like your product\u2026except for a few minor details.’? And then the CIO rolls out a list of additional ‘must have’ requirements, hundreds of them, to add to your amazing product. Have you ever heard, or even said: ‘Team, we are about to sign up a highly-profitable contract but\u2026’? And then the customer\u2019s wish list for additional functionality becomes a headache for developers.<\/p>\n

\"wooden-puzzle\"<\/a>So, how can the product be kept a step away from the potentially dangerous ideas of your customers, yet still satisfy them? How can it be possible to maintain the highest levels of performance for a product technically designed to function in a particular way, but now with a layer of numerous add-ins? How much of a challenge will be created by the fundamental need to provide unfailing and outstanding support to the developed solution?<\/p>\n

In the commercial world, product customization is an increasingly desirable requirement and a number of common practices have evolved in response to this customer need. Below you can find an overview of the typical approaches; if you are already familiar with them then you are welcome to scroll down straight to \u2018The Extensions Approach<\/strong>\u2019 paragraph and learn how we resolve these challenges in what we think is a more efficient way.<\/p>\n

All in One<\/h2>\n

The most straightforward and obvious solution to customization is to implement everything required in one core product and then employ the \u2018feature toggle<\/a>\u2019 technique to match the requirements of each particular customer.<\/p>\n

The main advantage of the All in One approach is keeping the monolithic product, which appears to be a good way for certain types of products which generally cover business requirements without the need for extensive customization.<\/p>\n

The natural limitation of this approach is hidden in the \u2018not much customization required\u2019 assumption. Often, a product development starts with this belief, but after a number of deliveries you realize the true scale of how much customer-specific functionality is required. It\u2019s not uncommon to be caught on the horns of a dilemma; refuse custom development and potentially lose customers, or turn the source code into a garbage can<\/strong> with single-customer-specific features which are likely to be useless for the majority of end-users.<\/p>\n

Which option would you choose? Obviously, choosing between a rock and a hard place is not the way to success.<\/p>\n

Summary:<\/u> The All in One approach can be an appropriate choice only if you are sure that rare and limited customizations will be required. Otherwise, you\u2019ll be faced by the choice between manageable and supportable product vs. customer satisfaction. Let me quote Jerry Garcia, who said: \u2018Constantly choosing the lesser of two evils is still choosing evil\u2019.<\/em><\/p>\n

Branching<\/h2>\n

If significant customization is the \u2018must have\u2019 part of a delivery then the All in One<\/strong> technique cannot be employed. There is another straightforward approach – branching<\/strong>. You simply branch the product codebase and change whatever in isolation.<\/p>\n

Comparing Branching <\/strong>with All in One<\/strong>, the biggest advantage is that there are no limitations applicable to the scope of customization. You use separate branches to meet the specific requirements of different customers and avoid mixing all features in the same codebase.<\/p>\n

However, there is a flip side of it that can become a dead end in terms of product evolution. Obviously, the product branch is the main development space: Most of the bugfixes, improvements, new functionality first get pushed to the product. Thus, frequent merging is required to keep all the customized branches synchronised with the core product. Merge is a simple operation as long as the original product source code has not been affected by the customized branch, otherwise it becomes extremely time consuming and can lead to unavoidable regression bugs.<\/p>\n

This approach can still work if you are limited to a very few customized branches. However, as the number of delivered instances grows, the likelihood of facing the \u2018torture by merge\u2019 becomes imminent.<\/p>\n

Summary:<\/u><\/em> The Branching<\/strong> approach is undoubtedly very flexible and straightforward \u2013 any part of a product can be modified. However, the post-delivery stage is potentially very laborious, becoming more difficult over time and it is very unlikely to result in delivering a significant number of manageable customized branches.<\/em><\/p>\n

The Entity-Attribute-Value Model<\/h2>\n

The Entity-Attribute-Value Model<\/a> (aka object\u2013attribute\u2013value model, vertical database model and open schema) is a well-known and widely-used data model. EAV enables dynamic entity attributes support and is typically used in parallel with the standard relational model.<\/p>\n

From productization point of view the main advantage of using EAV is that you can deliver a product \u2018as is\u2019 and then adjust the data model by adding required attributes at runtime, keeping the source code clean.<\/p>\n

As ever, there is a downside:<\/p>\n