Who does what? Responsibilities?

The project can’t start if it is not known who does what.

A list of tasks which defines who performs which task in the Setup and the Run phase.

The list should not be different from one Customer to the next but it should still be discussed and agreed with Them.

There are many constellations of this but there is no alternative to a good RACI matrix.

What does the Customer offer to run Unique on?

Unique currently runs primarily off docker images, so the customer should be able to run container images.

Refer to Technical Concepts for an overview how Unique runs.

Concise formulation, how the customer will run our images.

Unique primarily runs on Kubernetes. The customer must offer that or we talk a completely other strategy.

It is possible to run Unique without containers but the effort is exponentially huge. Customers demanding this must pay double extra and the timeline gets significantly longer from their end as they need to provide all infrastructure manually.

Refer to Infrastructure requirements to see which services all must then be maintained manually.

What IDP (Identity Provider) will be used.

Unique can (for chat) attach all IDPs that Zitadel supports, which one that is must be clarified beforehand.

Clear selection of the IDP and specs, how Unique will connect to said IDP.

currently none

What on-premise connectors are needed and what are their respective tools versions?

Unique must adapt the connectors to the right tool. If a customer uses Data-Center Confluence 7.9.9.1 it might not be the same as Data-Center Confluence 8.6.3.4.

Thus we must know, which connectors are needed and what version they use.

Concise list of

Tool, Version

as well as specs, how each of them will be reached from Unique

currently none

What local storage is provided?

We need to store files that users or connectors upload somewhere. This storage must be S3 compatible and somewhere offered on-premise.

Description and specs from the Customer, what storage it is and how our services will access it.

currently none

What LLM and Embeddings models will be provided?

To embed and chat, we need at least 1 LLM and 1 embedding model offered by the Client.

Description and specs from the Customer on how the API contract looks and how Unique will be able to reach it.

Note that most certainly, this will spawn a product team ticket to implement said API contract into our code.

They trust the some cloud provider enough and use a somewhere hosted model.

Product adaption

Requirements engineer, plan and implement all necessary changes to run Unique in this specific customers landscape.

New versions of Unique product that support new means of connecting to resources that customers provide.

Initial Deliveries Customer

Define and support the Customer (they are charged a packaged fee for it) in providing all the necessary infrastructure, documents and processes.

The Customer also must setup operational components like a proper log drain, audit logs for all administrative actions from their side, a secure storage for application audit logs as well as monitoring and alerting solutions.

The Customers side (the receiving side) is prepared and ready to receive Uniques initial deliveries and knows how to apply them inside their premises.

Initial Deliveries Unique

Agree with the Customer and elaborate, how Unique provides the initial version as well as how Unique supports the customer in setting it up the first time.

The Customer is well aware what they get, when they get it and what they will have to do with it.

Regular Deliveries Unique

Agree with the Customer and elaborate, how Unique ships new versions, their configuration and the matching release notes.

The Customer knows and can apply the regular changes. They know where to find the lastet version of Unique and how to apply it to their landscape.

Process & Controls

We evolve our product daily. But they Customer doesn’t and won’t update it every day 10 times.

CI/CDICR process

It must be defined and worked out, how the providing side (Unique) and the receiving side (Customer) work together in which rhythm. This definition is fairly easy. Unique provides new versions weekly but the Customer can install them whenever they please.

Controls and Change Management

But, it is to be clarified how the Customers controls can be satisfied (audit). They want to know what we changed, who allowed it, who approved it and why we changed it.

Monitoring, Investigations and Triage

An on-premise deployment is out of reach for Unique, it is the idea of the on-premise solution. So it must be defined:

• How will the Customer monitor the solution or lets say “Second Level Support Alert” Unique if somethings wrong

• How will Unique support given that we can not reach the environment

• How will Unique perform investigations and how will it be monetarily regulated

• How will the whole support process look, for incidents as well as for bugs

Agreement with the customer on how Unique satisfies all the requirements.

Unique can't do a special treatment of every customer so our process, tooling and docmentation must be expanded and evolved with every customer to accommodate them all in one.

3 days, product experiences downtime

yes

depends, minutes to hours

yes

minutes

no

depends, hours to days, defined by how wrong it was and how much falsely scoped data we have

yes

hours, may lead to degradation if not planned correct

yes

hours, may lead to degradation if not planned correct

yes

See Parent