Multi-instance

Multi-instance DAM is similar in concept to multi-tenant DAM, but it provides each stakeholder with its own discrete instance of the DAM software. Contrast this to multi-tenant DAM in which virtual partitions of a single instance are assigned to each stakeholder. All instances are managed from a single overlying software interface and control console. This enables the DAM service provider to make global configuration changes, and to manage software updates for each instance from a single location. Multi-instance DAM offers benefits not available to the stakeholders of a multi-tenant system, including having one database per stakeholder, which ensures absolute security; dedicating hardware resources, such as processing power or storage, which means that Stakeholder A can be paying for processing power that Stakeholder B doesn't require (or want to pay for); better reliability assurances because the actions of Stakeholder A do not affect the actions of Stakeholder B (if one instance crashes or is misconfigured, it will not likely affect other instances.) In addition, hosting providers can more easily define service-level agreements (SLA) that meet the requirement of diverse customers. Multi-instance DAM can be less desirable than multi-tenant DAM in cases where some resources should be shared between stakeholders. For example, logos, policy documents, branding and other things that would be useful across an entire organization would have to be manually copied between each instance in a multi-instance configuration. By contrast, rights/permissions settings could be adjusted to make these resources available across a multi-tenant system. If a DAM supports both multi-tenancy and multi-instance deployment, it should be possible to cascade tenancies through a hierarchical combination of instances that each include tenancies.

Multi-instance DAM is similar in concept to multi-tenant DAM, but it provides each stakeholder with its own discrete instance of the DAM software. Contrast this to multi-tenant DAM in which virtual partitions of a single instance are assigned to each stakeholder. All instances are managed from a single overlying software interface and control console. This enables the DAM service provider to make global configuration changes, and to manage software updates for each instance from a single location. Multi-instance DAM offers benefits not available to the stakeholders of a multi-tenant system, including: * One database per stakeholder, which ensures absolute security * Dedicated hardware resources, which means that Stakeholder A can be paying for processing power that Stakeholder B doesn't require (or want to pay for) * Better reliability assurances because the actions of Stakeholder A do not affect the actions of Stakeholder B (if one instance crashes or is misconfigured, it will not likely affect other instances.) In addition, hosting providers can more easily define service-level agreements that meet the requirement of diverse customers. Multi-instance DAM can be less desirable than multi-tenant DAM in cases where some resources should be shared between stakeholders. For example, logos, policy documents, branding and other things that would be useful across an entire organization would have to be manually copied between each instance in a multi-instance configuration. By contrast, rights/permissions settings could be adjusted to make these resources available across a multi-tenant system. If a DAM supports both multi-tenancy and multi-instance deployment, it should be possible to cascade tenancies through a hierarchical combination of instances that each include tenancies.