Calculating the appropriate cost model for customisations in multi-tenant applications can be difficult. These slides describe what multi-tenant means, how it compares to other options and then walks through options for how to approach a charging model with an individual tenant who requests customisations.

1. Customisation &
Total Cost of Ownership
For Multi-tenant systems

2. What is a multi-tenant system?
“The term "software multitenancy" refers to a software architecture in which a
single instance of software runs on a server and serves multiple tenants.
A tenant is a group of users who share a common access with specific
privileges to the software instance.”
-- Wikipedia

3. What is software Total Cost of Ownership?
Software ownership adds many liabilities over the entire lifecycle:
▪ Costs for enhancements and fixes required to support changing
business environment
▪ Costs for testing and deploying these changes
▪ First-line support costs: documentation, compliance, training of new
staff, handling user errors, access roster management
▪ Second-line support costs: Ongoing support and management of
production and pre-production environments

4. Comparison to multi-instance systems
Multi-Tenant Multi-Instance

5. Why multi-tenancy
▪ Reduced cost at scale: costs scale with number of active users,
not number of tenants
▪ Reduced maintenance costs: one set of hardware to manage,
maintain and update
▪ Reduced ongoing development costs: one codebase to test

6. Why multi-instance
▪ More straightforward security model: one set of equipment per
tenant
▪ Facilitates customisation per-tenant: separate codebases can be
used if needed
▪ Lower initial development cost: significant upfront cost of multi-
tenancy infrastructure

7. Customisation & Configuration
Configuration: enabling different software parameters on a per-tenant
basis to deliver a different experience or feature set to the users.
Customisation: developing bespoke features for individual tenants.

8. Approaches to customisation
1. Develop entirely new branch of software, deploy to entirely new
hardware → separate custom deployment
2. Develop generic new features with appropriate feature flags and
configuration parameters → generic feature development
3. Develop custom code just for a single tenant and hide it behind a
feature flag → point customisation

9. Separate custom deployment
▪ Allows any form of customisation that is technically possible
▪ Create entirely new code branch and entirely new set of environments
▪ Exponential increase to TCO:
▫ More hardware
▫ Changes need to be merged to both branches
▫ Doubles testing requirements
▫ Doubles deployment costs
▫ Doubles support costs
▫ Changing shared data and content can get very painful

10. Generic feature development
▪ Developing generically useful feature is more expensive and takes
longer (could be e.g. 2x as long)
▪ Requires thought and design and may not be possible if feature
truly is tenant-specific
▪ However features now available to all tenants if they want them, so
increases software value
▪ Slower increase to TCO:
▫ Increases testing costs in line with normal feature development
▫ Increases future enhancement costs in line with normal feature
development

11. Point customisation
▪ Hide custom code behind a feature flag
▪ Moderate increase to TCO:
▫ Increases ongoing change costs
▫ Increases ongoing testing costs - sets of tests now need to be
retested for each new customisation, and combinations of them
▫ Does not require entirely new set of hardware environments
▫ Still only one deployment per change
▫ Future changes do not need to be merged twice

12. Charging models

13. Separate
Custom
deployment
Point
customisation
Generic feature
development
TCO
# of features
Projection of TCO changes using different approaches

14. Charging for separate custom deployment
▪ Take existing projections for ongoing maintenance and change
costs for all tenants
▪ Double it. At least.
▪ Add your margin

15. Charging for generic feature development
▪ Design the generic feature
▪ Confirm with customer that it satisfies their needs
▪ Develop a fixed-price style charge. This means:
▫ Detailed design
▫ Detailed estimation
▫ 50% cost overrun buffer
▪ Recommend ignore TCO change in costing: should be
accomodated by ongoing support model

16. Charging for point customisation
▪ Develop a fixed-price style charge. This means:
▫ Detailed design
▫ Detailed estimation
▫ 50% cost overrun buffer
▪ Add TCO charge. Suggest 3 year horizon for “total”. Ask QA team
for an estimate of increased regression test cost. Multiply by 36, for
one regression per month. So if it adds one day to a regression,
then charge the additional 36 days. Could add substantially more.

17. Summary
Conversion to multi-instance: avoid at all costs. Maintain coherent
single platform with defined mission. If necessary spin off new services
to deal with truly unique new features.
Conversion to configuration: use wherever possible. Apply thought and
design to how new requirements can be applied to existing and future
customers. Maintain coherent mission.
Point customisation: Only use where necessary. Charge realistically.

18. We help companies of all sizes with their most challenging
business change, product development and public cloud needs.
https://www.isotoma.com
hello@isotoma.com