This document outlines the architecture of the Digizuite Digital Asset Management (DAM) software-as-a-service solution.

TOPOLOGY

The solution is hosted in Azure data centers serving all customers from a centralized locations. Initially, there is a data center in the European Union and in North America. These centers allow for very low latency in serving data to customers and meeting data handling requirements (not allowing data to be stored outside regions).

Additional data centers are planned as the customer base and their locations expand. The data centers have the same internal architecture, and there are no functional differences. 

Enterprise Architecture

The DAM serves as a central component within the customer's enterprise, supporting technologies commonly referred to as the MarTech stack. This is accomplished by adopting a composable architecture based on managed APIs and microservices.

The UI integrated into the DAM solution is built upon managed APIs and microservices, following an API-first paradigm. These APIs facilitate operations such as finding assets, retrieving asset metadata, uploading assets, setting metadata, accessing versions, workflows, users, etc. Essentially, any data manipulable through the Media Manager can be handled via these APIs.

Integration Toolbox

The various integrations rely on a common API. To expedite integration processes and reduce the total cost of ownership, a toolbox is available, including:

• Embedded UI:
  A lightweight DAM UI component designed for embedding in connected solutions. Users can find, download, and upload assets by specifying only the URL to the UI. The UI manages integration with the DAM through the API, enforcing SSO login, security rights, mandatory data, formats, metadata, etc.

• Automation Web Hooks:
  Configurable event-based hooks calling out to external services. A powerful tool for rapidly and securely setting up integration endpoints.

• SDK/API:
  The managed APIs and accompanying SDK enable external systems to call into the DAM. The toolbox is supported by "extracted" API documentation and example code and projects with best practices, accelerating integrations and ensuring their correctness. The APIs are modern Rest based end-points consuming and returning JSON.

Media Manager

The DAM's UI component is a "one-page app" that loads once and subsequently calls the API in the backend solution. The UI is accessible and can be branded to a high degree to meet the look and feel requirements of customers. It is role-based, allowing certain users to access more functionality and data than others. Superusers can make configuration changes, creatives can upload, share, and annotate assets, while others can only view the data. Login is done via the customer's identity provider (SSO), enforcing strict control by the customer's IT departments and reducing complexity for daily users.

Logic

The logic layer in the system manages numerous individual services and connects the API to the repositories. It is based on proven third-party components for handling images, videos, database layers, job queuing, logging, analytics, etc.

Managed Repositories

All data is stored in managed repositories, accessible solely via the APIs and the system's logic. No direct access is granted to the database or assets. The repositories are encrypted at rest and in transit. All persisted data is strictly handled per customer in individual instances—each customer has its own database, asset storage location, etc.

• RDMS:
  Metadata and configuration are persisted in a relational database in Azure.

• Asset Storage:
  Assets are stored in a dynamic data repository in Azure, allowing storage to grow and shrink on the fly, eliminating hard limits in the solution.

• Search:
  Search is hosted and managed by Elasticsearch Cloud, an industry leader that combines extensive functionality with performance and reliability.

• Queuing:
  The job system includes a queue hosted as a service in the solution, temporarily storing jobs in Azure for resilience.

• Analytics:
  Telemetry data is continually added to an insights RDMS hosted in Timescale Cloud.

• Logs:
  Monitoring, metrics, and logs are added to a Grafana Cloud instance. The separation of production and monitoring ensures that alarms are raised even in the unlikely event that the Microsoft Azure cloud is not responding.

• Backup:
  Persistent original data is backed-up and stored according to the back-up policy.

Network

To enhance the performance, security, and reliability of the DAM’s internet services, traffic is directed through Cloudflare, introducing:

• DNS services

• Load balancing

• SSL/TLS encryption

• CDN (from version 5.10)

• DDoS protection (from version 5.10)

• WAF (Web Application Firewall) (from version 5.10)

Within Azure, traffic is managed by a component called Traefik, which provides additional services to address the internal performance of the Kubernetes container orchestration.

Container Deployment and Data Isolation

The Digizuite DAM employs an enterprise-multitenant paradigm where solutions for multiple customers are hosted in the same datacenter and orchestrated using the same Kubernetes infrastructure.

Data

Customer data is however strictly separated in storage, as well as in API, services, logic, code, and configuration. In the Kubernetes setup, this results in each tenant having dedicated container instances (pods), and each tenant can be upgraded individually. This flexibility supports enterprises with "code freeze" policies, ensuring that no system updates occur, especially close to critical events such as Black Friday or annual reporting.

Deployment

Infrastructure and deployment of new containers are handled through a dashboard based on Pulumi. This allows for instant or scheduled release cycles, adhering to service windows and, to a limited extent, individual customer preferences. Deployments are audited, and developers have no direct contact with the running instances, as all deployments are based on the build pipeline defined at Digizuite.

Customer deployments are highly efficient, usually involving only pointing each customer to the updated containers. Occasionally, a deployment may impact the database schema, requiring the RDMS to be touched. In such cases, the deployment triggers a backup as an integrated part of the upgrade.

References

Security

Refer to the security policy for details on the security setup. Link

Quality

Refer to the quality policy for details on the quality. Link