Digital Asset Management Multitenancy that’s Manageable

Picturepark was designed to support multiple groups of users, so it enables you to offer multitenant digital asset management services that are secure, reliable and easy to manage

To be able to provide secure, easy-to-manage digital asset management services to multiple stakeholders, either multitenancy partitioning or multi-instance deployment is required. Picturepark is among only a few DAM systems that offer both. (And both at the same time too.) Collectively, we refer to these options as offering multi-stakeholder support.

Without true support for multiple stakeholders, your administration tasks will become unduly complicated and time consuming. Worse, the integrity of your DAM can be easily compromised by simple errors made by users or inexperienced administrators.

Note: Picturepark Regional Clouds are made possible because of the multi-stakeholder support that’s built into the product.

How do you Know if you Need Multitenant DAM?

Below are the most common situations in which native support for multiple stakeholders is required.

Scenario 1: The DAM will be used to manage different metadata or assets for multiple departments

This is a typical requirement of multi-national corporate or university environments. For example, your Tokyo office will have its own assets and it will want to manage its own metadata too. Meanwhile, your European offices don’t need those Japanese-language assets and they don’t want to find them when searching for their own.

In Higher Education environments, each school and department can have their own collections. In some cases, those assets and metadata should be shared across campus to faculty, staff, students and more. But when it comes to protecting research, it’s important that content be hidden, even from “friendly” allies, like the eager folks in Public Relations.

Scenario 2: The DAM will be used to manage assets for multiple clients

Agencies that work with multiple clients want a single location from which all those digital assets are managed. File servers don’t work well for this purpose because (among other reasons) they don’t provide the guest access that’s required for client reviews and approvals.

Single-tenant DAMs that rely on roles for user separation are also dangerous for this purpose because a simple (and easy-to-make) permissions mistake could make the production assets of Apple available to the employees of Samsung.

Scenario 3: The DAM will be used to resell DAM services

When selling DAM as a service, you’ll likely need to be able to monitor the bandwidth and storage use on a per-customer basis. This is the foundation upon which many Cloud services are billed and it also enables you to better anticipate future hardware needs.

In addition, you’ll be obligated to honor the service-level agreements (SLA) you have with your customers, some of whom might have different requirements. Without true multi-stakeholder support, this would virtually impossible to manage.

Finally, when it comes to managing digital assets and metadata for customers that are paying you, you can’t afford any type of security breach—even if it is the result of a simple, honest mistake.

DAMs Based on Roles aren’t Suitable for Multitenant Deployment

Virtually all enterprise digital asset management systems offer roles (groups) and departments into which users can be organized for easier administration. Roles are great when different groups of users must have different permissions on the same digital assets and metadata. But you’ll need more than roles and departmental administrators if you plan to provide DAM services to multiple organizations, or even multiple departments within a single organization that need to manage their own collections.

Here are some points to remember about DAMs that don’t offer true multitenant support:

• Roles govern access to assets but they don’t provide a virtual partition between stakeholders. Without this extra safeguard, a simple permissions mishap can reveal assets to users who shouldn’t see them.
• In roles-based DAMs, departmental administrators can see activity logs for users in other departments, which isn’t acceptable in a true multitenant system. You don’t want the administrator for Client A to be able to see the what the users of Client B have been doing.
• Roles-based DAMs typically don’t offer support for multiple taxonomies. This means a single taxonomy tree must be subdivided using permissions, which is cumbersome and prone to error.
• Only a true multitenant system will be able to show you how much storage and system use can be attributed to each tenant. You’ll need this information for billing and planning system expansions.

Multitenant vs. Multi-instance

In addition to the roles-based permissions management found on other DAMs, Picturepark offers true multitenant partitioning and multi-instance deployment. Though either option can be suitable for managing the digital asset management needs of multiple stakeholders, the differences between each option are important to understand.

Multitenant partitioning means a single Picturepark database is divided between stakeholders (left). With multi-instance deployment (right), each customer has its own database. Each instance can then optionally be used to offer multitenant partitioning to build private Clouds.

Multitenant partitioning

Multitenant partitioning (MTP) describes dividing a single Picturepark instance among multiple stakeholders. The important distinction between MTP and roles-based permissions is that MTP acts like a virtual partition that lies between the different tenants of the system. Roles-based permissions, on the other hand, are simply a means for determining which users can see or access individual assets within the DAM.

With MTP, for example, when users from Tenant A connect to Picturepark, they see only their assets, as you’d expect. But in addition, they see their own taxonomies and metadata schemas too. And when viewing system activity widgets, they see only the activities of their own users. When Tenant A administrators view user shares and statistics, they see only those associated with their own users. In other words, Tenant A’s Picturepark experience is one of total isolation from other users of the system.

As a means of comparison, consider a standard Gmail account. Though all Gmail accounts are run from the same Gmail server software, the virtual partitioning built into the system ensures that your email doesn’t show up in the mail box of another user. Picturepark’s multitenant partitioning is similar.

To make the permissions management of multiple tenants easier, Picturepark “super” administrators (you) can impersonate any user from any tenancy to experience Picturepark exactly how that user experiences it. You can use this feature when creating new users or user accounts to ensure permissions are properly set. Impersonating a user or role is also a wonderful way to make user support more efficient.

The super (root) administrator of a partitioned Picturepark can see the assets, metadata, activities and statistics of all tenants. (Being able to isolate per-tenant statistics is a fundamental requirement of usage-based billing.) Tenant administrators, on the other hand, can impersonate and see assets, metadata and activity logs for only their own users

Multi-instance deployment

Taking the multi-stakeholder capabilities of multitenant partitioning a (big) step further, multi-instance deployment (MID) describes giving stakeholders their own discrete Picturepark instances, each with its own database. The primary advantage of MID is that even a massive permissions or group assignment mistake won’t result in a cross-customer security breach because there are no shared resources between the systems.

MID is the mode in which Picturepark operates its own Cloud Suisse software-as-a-service (SaaS) to provide Cloud DAM to customers. It enables us to provide customers with a level of security that satisfies virtually all corporate requirements, and it enables us to offer SLAs that reflect different needs and contractual obligations.

In order to manage all those different instances, Picturepark provides the Global Manager, which is a browser-based tool that comes standard with all installed (on-premise) Pictureparks. Using the Global Manager, Picturepark super administrators can manage Picturepark’s connection to available hardware (nodes and clusters), backup and clone current Picturepark instances, provision new instances, adjust some global instance settings, and more.

The Global Manager is like “command central” for a farm of one or more Picturepark instances.

Worth noting is that individual Picturepark instances operating under the multi-instance deployment model can each be partitioned, as described above. So, for example, a single Global Manager could be used to manage, say, 100 Picturepark instances that are each used to provide partitioned DAM services to 10 clients, resulting in DAM services for 1,000 different stakeholders.

Choosing the Right Option

When deciding between multitenant partitioning and multi-instance deployment, here are few of the most common considerations to keep in mind.

• Multitenant partitioning is most popular when supporting agency clients or multiple departments from the same organization. In these cases, your tenants aren’t likely paying for DAM services, so there’s less need for the added advantages of multi-instance deployment.
• Multitenant partitioning enables you to share resources across tenants. For example, you might want to to make corporate logos and policy documents accessible to every tenant, while other assets remain tenant-specific. You might also want all or some of a central taxonomy to be shared among tenants. With multi-instance deployment, there is no sharing of any resource between instances, making it less desirable for collaborative environments.
• It costs less to add a tenant than it does a new instance. Because each Picturepark instance is a complete Picturepark license, the cost of deploying multiple instances is higher. Tenant partitions, by contrast, fall under the license of the “mother” Picturepark and are therefore priced differently.[/list_item]
• Multi-instance deployment enables you to more easily offer different service-level agreements (SLAs). This becomes important when offering DAM services to larger organizations. In many cases, these organizations will require specific changes to your standard SLA. You might be able to honor those differences only by offering discrete instances of the software.
• When absolute cross-customer security is required, the discrete databases offered by multi-instance deployment become more valuable. Each Picturepark instance is a completely separate piece of software, so a user from Tenant A would have no way to access anything in the instance of Tenant B without having a specific login to that system.
• Multi-instance deployment enables you to determine hardware processing priorities. This means you can configure your system to ensure that periods of peak usage are less likely to affect performance for your “Premium” customers.
• Multi-instance deployment enables you to schedule maintenance around customer schedules. This means you can take one customer’s Picturepark offline without affecting access to others. Larger production environments will appreciate being able to choose when system maintenance is performed.
• Multi-instance deployment can be better for API access. If you’ll be offering customers access to the Picturepark Web Services API for the purposes of integrating with their other business systems, multi-instance deployment is preferable because you don’t risk affecting the usability of other tenants while testing.
• Easy upgrades across the entire system. Though it might seem as though each instance in a multi-instance deployment must be upgraded individually, this isn’t the case. Because Picturepark was designed for multi-stakeholder support, either multi-tenant or multi-instance systems can be upgraded in a single step.

Regardless of which option you choose with Picturepark, you can switch to the other at any time. So while it’s important to understand the differences up front, it’s good to know there are no wrong answers, because today’s needs might not reflect tomorrow’s growth.