Wednesday 21 December 2011

Multi-tenancy design choices

As a general observation , many if not all of the telecoms standards and to a large extent service management and cloud computing reference standards do not address multiplexing and multiplicity of architecture abstraction very well. In short, they don’t recognize multi-tenancy architectures as a strong pattern in deployment design or operation. This is symptomatic of using earlier ontologies that restrict the design to business process and service information payload examples that abstract message and interaction tiers but not the underlying architecture instantiations. These matters are often abstracted as schema taxonomies for multiple entity users, but this obfuscates the underlying source and target architectures which may be single tenant. This is a challenge to existing architectures where multi-tenant architectures have been developed.
• Configuration control is multi-tenant
• Resource allocation and balancing is multi-tenancy
• Scalable extensions is based on a multi-tenancy usage model
• Service management is recognizing multi-tenancy version states
• Abstraction of service management and service control from tenant using the service
• Security policy management at individual , group and entity level may support multi-tenancy service abstraction
• Ability to extend or remove new or existing tenants that are new or existing legal contract entities (enable growth or change market service)
Avoiding these design states may be difficult if the underlying operating system and architecture prevents shared service tenancy between BSS and OSS. An example of this maybe iOS5 which though m=not held as a example of multiple tenancy can be described as a OS design that abstracted the common resource management functions over those that are resource consumers or providers of the services that operating in the environment. In this case environment management has been abstracted to enable cross tenancy support.
Going forward, multi-tenancy choices may be necessary to prevent restrictions in growth and agility of platform, OS and the wider adoption and phenomenon of smart apps, devices and services to meet the new customer and communities demands of the future.