Kinetic Data s Multi-Tenancy Strategy

Transcription

1 Kinetic Data s Multi-Tenancy Strategy How Kinetic Request and Kinetic Task address the requirements of a Multi-Tenant deployment The need to be able to provide secure but effective solutions to a multi-tenanted service request implementation is building with the increased focus of (software-as-a-service) SaaS and cloud solutions. Kinetic Data has an architectural and security model that enables this type of deployment while still ensuring that the applications are easily configured and deployed without sacrificing security and integrity. Multi-tenancy Background Multi-tenancy refers to a principle in software architecture wherein a single instance of the software runs on a server, serving multiple client organizations (tenants). Wikipedia Multi-tenant applications have evolved from and combine some characteristics of three types of services: n From the 1960s, companies rented space and processing power on mainframe computers (time-sharing) to reduce computing expenses. Often they also reused existing applications, with simply a separate entry field on the logon screen to specify their customer account ID. On the basis of this ID, the mainframe accounting department could then charge the individual customers for (Central Processing Unit) CPU, memory and disk/tape usage actually incurred. n From the 1990s, traditional application service providers (ASPs) hosted (thenexisting) applications on behalf of their customers. Depending on the limitation of the underlying application, ASPs were forced to host applications on separate machines (if multiple instances of the applications could not be executed in the same physical machine) or as separate processes. Multi-tenant applications represent a more mature architecture that enables a similar service with lower operational cost. n Popular consumer-oriented web applications (such as Hotmail) were functionally designed as a single application instance that serves all customers, while isolating each user s data from other users. Multi-tenant applications represent a natural evolution from this model, offering additional customization to a group of users within the same client organization. 235 East Sixth St., Ste. 400B, Saint Paul, MN I I p. 1

2 Customization Multi-tenant applications are typically required to provide a high degree of customization to support each target organization s needs. Customization typically includes the following aspects: n Branding: allowing each organization to customize the look and feel of the application to match their organization branding (often referred to as a distinct skin ). n Workflow: accommodating differences in workflow to be used by a wide range of potential customers. n Extensions to the data model: supporting an extensible data model to give customers the ability to customize the data elements managed by the application to meet their specific needs. n Access control: letting each client s organization independently customize access rights and restrictions for each user. Security Of major concern in any multi-tenant environment are the twin aspects of data security and isolation of processes. For multi-tenant environments that share the application among independent tenants (i.e., that is not within divisions of the same tenant), security of data and processes is essential. A subcategory of multi-tenancy exists mainly within the IT service management sector which organizations, for example, IT service providers will set up a multi-tenant environment that allows a top-level entity the service provider to look down to the data and processes of the tenants, while preventing the tenants from seeing the other s data or processes. The most used strategies for maintaining security and isolation of data is row-level security. This can also be combined with other strategies such as query qualification to further restrict access to data from within the tenant or to allow some limited access across tenants. 235 East Sixth St., Ste. 400B, Saint Paul, MN I I p. 2

3 Kinetic Request/Kinetic Task and Multi-tenancy General Strategy Kinetic Data has adopted a strategy that achieves the requirements of true multitenancy as defined above to include: n Unique Branding for each tenant n Accommodating differences in workflow or processes per tenant n Extensions to the data model for each tenant n Access control by tenants Kinetic Request/Kinetic Task Architecture Kinetic Request and Kinetic Task are polymorphic, metadata-driven applications. In a metadata-driven application, there is a clear separation of the compiled runtime engine, application data, the metadata that describes the base functionality of an application, and the metadata that corresponds to each tenant s data and customizations. These distinct boundaries make it possible to independently update the engine, modify the core application, or customize tenant-specific components, with virtually no risk of one affecting the others. The outward-facing application can be described as polymorphic, in that it is driven by metadata rather than hard-coded and thereby able to be different in its function and display according to the metadata that configures the application. The Kinetic Data architecture follows these principles. Tenant-specific metadata defines display, functionality and processes for individual tenants. Common metadata defines common display, functionality and processes for all tenants. Request data is stored in a common-data structure with security and isolation maintained through row-level security and query qualification given security from each tenant down to specific group and user levels. 235 East Sixth St., Ste. 400B, Saint Paul, MN I I p. 3

4 This architecture allows changes to the request forms and portals (user interfaces), Kinetic tasks including approvals and task trees for each tenant without affecting other tenants. Isolation is achieved at the tenant level while still allowing the overall administrator the ability to manage and configure the Kinetic environment. As a result, each tenant can have unique branding, processes, portals, and forms that are specific to the tenant s requirements and processes, while the administrators can leverage the advanced design, development, and configuration functionality of the Kinetic environment. Kinetic Request/Kinetic Task and BMC Remedy The current versions Kinetic Request and Kinetic Task use BMC Remedy as the data store for all Kinetic metadata and transaction data. BMC Remedy multi-tenancy is well covered in a number of documents issued by BMC 1. BMC implements multi-tenant data segregation through a row-level security model. Row-level locking is set at the company level for BMC Remedy (IT Service Management) ITSM, forms. All child records inherit the tenants of the parents associated with them. 2 Company A Unrestricted Access Company B In brief, BMC Remedy utilizes row-level locking through a field in tables that contains the unique ID of the company. Any record created by a user in a table that has this field (field 112) is set by the BMC Remedy system to the ID of the user s company upon its creation. As a result, query, view, and modify access to records is restricted by the BMC Remedy system to only those records of the user s designated company or companies. BMC Remedy enables users within a multi-tenancy environment to be members of one or many companies or to have unrestricted access across all companies. 1 BMC Remedy IT Service Management Concepts Guide Oct BMC Remedy IT Service Management 7.0 Guide to Multi-Tenancy Dec East Sixth St., Ste. 400B, Saint Paul, MN I I p. 4

5 As Kinetic Request and Kinetic Task use the core BMC Remedy data structure to store tenant and application metadata, as well as data submitted as part of a request and/or task process, within a multi-tenanted environment, field 112 will be populated with the ID of the company of the user and as a result access will be restricted to those users with a company membership that allows access to those records. Kinetic Request/Kinetic Task extends beyond BMC Remedy multi-tenancy Kinetic Request/Kinetic Task extends the standard BMC Remedy multi-tenancy model with its polymorphic application architecture. Unlike other request management applications, Kinetic Request supports unique service items, request portals/catalogs and task/approval processes that are unique to each company in a multi-tenancy environment. The configuration of the request and catalog instances is easily achieved through cloning or templating. As a result, for a service provider, the process of creating a customized request management instance for a new client is a matter of selecting the service items that will be made available to the new client and using Kinetic utilities, such as KURL or Request Template, to export and import processes. All aspects of a service item or catalog, including tasks and integrations, can be easily and quickly replicated and configured to the client s unique requirements and processes. The security access model is also extended within each company segment within the multi-tenanted environment. Service items and catalogs can be made public, private, or only available for management, viewing, or submitting through group and user permissions. In this way, the configuration, management and submission of requests are controlled in a granular way. For example, an HR department may have control and management of a service item and another group of users may be able to work on the fulfillment of the request while allowing members of a particular division to submit requests for that item all based on group-access and user-access permissions. Another advantage of the polymorphic architecture of the Kinetic Request is the ability to brand all levels of the application from catalog and portal through to individual service items. This has been found to be an essential requirement of individual companies and in many instances, divisions of companies in a multi-tenancy environment. 235 East Sixth St., Ste. 400B, Saint Paul, MN I I p. 5

6 Kinetic Request/Kinetic Task Implementation Models Company-Specific Model Uniquely branded catalogs and portals can be configured for each company in a multi-tenancy environment without affecting the branding or processes of any other company in the same BMC Remedy instance. Kinetic Task enables company-specific approval and fulfillment processes to be associated with a particular company without any change to the core BMC Remedy workflow that may affect other companies. 235 East Sixth St., Ste. 400B, Saint Paul, MN I I p. 6

7 Shared Model If required, companies in a multi-tenancy environment can configure catalogs, portals and service items to be shared among them, while still maintaining the row-level security of the multi-tenant environment. In this model, while service items are shared among companies, access to the data that is submitted and the tickets created is controlled by the core BMC Remedy multi-tenancy rules. 235 East Sixth St., Ste. 400B, Saint Paul, MN I I p. 7

8 Blended Model A combination of both the company-specific and shared models can be configured where common service items can be shared among companies, while retaining companyspecific service items for each company. Again, access to the data that is submitted and the tickets created is controlled by the core BMC Remedy multi-tenancy rules. In this model, unique branding and task processing can still be achieved through custom styling and task management based on the company or group membership of the users. In Conclusion, Advantages of Kinetic Request/Kinetic Task Multi-tenancy Include: n Flexible deployment model n Customized (User Interface) UI for each company n Choice of unique or shared service items or a combination thereof n Data integrity and segmentation n Isolation of (User Interface) UI, and workflow processes n Configure for each tenant without global effects n Configure unique processes (approvals, tasks, integrations) for each tenant 235 East Sixth St., Ste. 400B, Saint Paul, MN I I p. 8