customisation & total cost of ownership for multi-tenant systems
TRANSCRIPT
Customisation &Total Cost of Ownership For Multi-tenant systems
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
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
Comparison to multi-instance systemsMulti-Tenant Multi-Instance
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
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
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.
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
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
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
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
Charging models
SeparateCustom
deployment
Pointcustomisation
Generic feature development
TCO
# of features
Projection of TCO changes using different approaches
Charging for separate custom deployment
▪ Take existing projections for ongoing maintenance and change costs for all tenants
▪ Double it. At least.
▪ Add your margin
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
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.
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.
We help companies of all sizes with their most challengingbusiness change, product development and public cloud needs.
https://www.isotoma.com