Nov 13, 2008

Usage scenarios for vendor products

Often a vendor software package we buy doesn't exactly meet our needs, so we want to alter it's behavior. This can be done in following ways with these advantages/disadvantages and preference...



OUT-OF-BOX FEATURES (functionality provided in vendor's base product as-is or with configuration changes)

Effort required: None

Vendor support:
Yes

Maintenance costs:
None

Preference:
High

Comments
- Simple product upgrades
- Applications bolted onto the vendor product pose lower migration costs than customizations to the vendor product itself

BUILD CUSTOM FUNCTIONALITY USING VENDOR PRODUCT API (extend product functionality using vendor published and supported API)

Effort required: Low - Medium

Vendor support:
Yes (API)

Maintenance costs:
Medium

Preference:
Medium

Comments

- Simple product upgrades (upgrades don't impact enhancements as vendor APIs don't change, hence custom code written using vendor API works with product upgrade. So no need to change our code as functionality won't break)
- Customizations outside of the system source code pose limited migration costs because minimal development is required with every upgrade

CUSTOMIZE VENDOR PRODUCT (outside API) i.e. change in vendor's base product

Effort required: High

Vendor support:
No

Maintenance costs:
High

Preference: None, as vendor product customizations lead to -
(1) against our core design principles
(2) long-term issues with support and maintenance
(3) incompatibility with vendor upgrades
(4) potential delays in releasing the product due to unforeseen issues with custom code and standard code integration

Comments
- Risky/time consuming product upgrades because customizations can break
- Requires significant analysis and testing and potentially recoding to upgrade
- Support issues due to non-standard nature of the product
- Customizations don't work properly with upgrades -Once product code is changed (even slightly) the product no longer can be upgraded without losing those customizations. So we might face a no-win choice: If we want to upgrade, we have to forgo all the customizations that made the product fit our specific needs. Thus customizations leave our systems badly compromised

1 comment:

  1. Mark reminded me to finish a decision tree we started earlier this year to help answer sponsor questions like -

    - Okay, I understand customization is bad. Is it worth doing this extension, that extension and sometimes even a small set of customizations? Remember large number of customizations aren't good either...

    I'll discuss it in upcoming posts...

    ReplyDelete