Disclaimers

Phase Key Bullets

Dependencies

Each phase depends on results of the previous phase even when unlisted under pre-requisites explicitly.

Hardware cost

All Azure costs are directly paid by the customer as all resources run in their tenant / Microsoft Customer Agreement / Enterprise enrollment.

Timeline

The timelines referenced in this page heavily depend on the following:

• the availability of full time employees on the clients side in order to support the endeavour (at least 60% suitable FTE are required to drive an ambitious timeline)

• the availability of Unique employees

• the availability, support and agreement of central teams of the client, named examples could be

  • IT Security

  • IT Architecture or Engineering

  • Financial Operations

  • Compliance or Legal

• All estimations are non-binding, and the effort is highly dependent on security requirements, processes, and permissions of the client. The overall duration for the setup of the CMT with the standard model should be min. 3-6 months to ensure all permissions can be granted and the setup is compliant and governed.

Some estimations for times or phases can be found in boxes like these

Overview

Standard model

Unique has a standard model to run Customer Managed Tenants including the following principles:

• Unique regularly releases new bundles (see Release Process).

• Unique has no access to the customers environment and thus cannot directly see the running resources and workloads.

• The customer/client sets up and runs the product themselves potentially with advisory/consulting.

• The customer educates and maintains a 1^st Level Application Support which can contact or escalate incidents to Unique Enterprise Support.

• Uniques 2^nd or 3^rd level support might request logs, telemetry, further insights or screen-sharing sessions to investigate the issues.

This model has crystallised out with multiple FSI clients and is thus the most compliant and recommended way. Clients may opt for Variants as described below.

Variant(s)

If the standard, recommended scheme above is not chosen, there exist many variants that can only be determined when spending multiple iterations with the client determining the responsibilities.

Since the variants raise the complexity excessively, its deviations are maintained in Deviations from the Common Model.

The phases below are valid in regard to the Standard Model.

PREPARE

Client Activities

• Prepares Azure tenant according to the https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/515833884.

• Might already provision all Azure Entra and ARM resources required to accommodate Unique either with the provided bundle or by other means.

Unique Activities

• Initially provides a Release Process bundle which contains terraform code that can provision all needed resources to accommodate Unique.

• Advise the client where desired or needed (on a daily rate) including the following:

  • Advisory for the prerequisites.

  • Advisory on the deployment of the Unique landing zone content.

SET UP

Out of scope

• Client-specific customisations and enhancements for the whole bundle (e.g. private API Gateway compatibility or change to the AI model usage etc.).
  If any customizations/enhancements are needed it will be charged additionally and has an impact on the timeline. Findings for this should have been already made in the PREPARE phase using the https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/515833884.

Prerequisites

Fulfilled, checked or mitigated https://unique-ch.atlassian.net/wiki/spaces/PUB/pages/515833884 and potentially already first resources provisioned.

Client Activities

• Client installs bundle

  • Azure Resources (overlaps fluently with Prepares last step, some resources might have been provisioned to PoC the setup)

  • Supporting Services and their configuration (helm charts and helmfiles)

  • Unique product and its configuration

Unique Activities

• Naturally provides a newerRelease Process bundle as some time might have passed since the PREPARE

• Advisory on the deployment of Unique Product and support services.

• Consulting for the just installed supporting services.

• Consulting for SSO configurations.

• Consulting for the Unique Product and its first setup (including assistants or other features).

RUN

Out Of Scope

• If Unique has no access to the environment, investigations on the tenant itself by Unique employees are inherently impossible and the client must provide logs, telemetry or requested screenshots or screen sharings to help resolve an issue. The client must reserve capacity internally for this maybe as part of the 1^st Level (Application) Support.

• Unique commits to resolving bugs within the Unique product. Configuration bugs as in “the reference architecture was wrong” are taken into account and ported into the documentation but won’t be actively fixed by Unique. This is a customer managed tenant so the client in the end manages the infrastructure. Unique can advise at a rate and in that case co-learn for future Reference Architecture.

• Unique only provides bug fixes in the latest Unique version or the newest bundles respectively. Hotfixes are not supported as they are not needed. If Unique and clients stick to a proper staged rollout process, DEV and/or QA systems must find breaking bugs before large user bases are affected. In case a breaking bug was introduced, the client must roll back the last release and wait for the next release that contains a fix.
  Unique on the other hand, if such a case of occurs of course highly prioritises to fix such an issue in the next release!

Prerequisites

Completed SET UP phase.

Client Activities

• Installs provided bundle regularly.

  • Unique can and will not force the client to update in a Unique-dictated rythm.

  • But Unique only fixes application bugs in the latest releases version (see Out Of Scope).

• Triages incidents internally with 1^st Level Support that was built up in SET UP.

• Provides all necessary insights to Unique as far as applicable to investigate issues.

Unique Activities

• Provides new bundles as defined in Release Process.

• Triages and investigates support tickets handed in by client.

• Provides fixes for bugs.

• Advises on configuration mistakes of resources or workloads at a rate.