Skip to content

Architecture of CCH Tagetik

Databases of Tagetik

A single installation consists of:

  • a central database (repository) for the management of users and allocated user roles. The roles define the activities that a user can perform in Tagetik.
  • one or more application databases, which store the data and dimensions of the data model and, which can be used to manage the application processes.

Application process

Each application process represents a business cycle (budget, actual, forecast etc.) with a start date and an end date. Each application process has the following characteristics:

  • it can have a single deadline, or intermediate deadlines
  • it can be repeated at various intervals (monthly, quarterly, half-yearly or annually)
  • it can work on the whole data model or on part of it

Each application process is defined by the following elements:

  • a set of entities
  • a process and activity workflow
  • a process data model
  • a time perimeter
  • data entry and report forms
  • calculation logics
  • diagnostic logics

IMPORTANT: various application processes (budget, actual, forecast and consolidated) can be managed on the same application database.

Using a single application database is particularly helpful when the data model has the following characteristics:

  • it is common to the different processes
  • it is managed by the same administrator users

Types of application architecture

Different application architectures can be created, to give the system administrators different levels of freedom in constructing the data model and calculation logics.

Administration of the data model and fully-centralised calculation logics

This architecture has the following characteristics:

  • a single application database on which multiple processes can be managed (e.g. budget, actual, forecast)
  • all administrator users work on the same application database and on the same database throughout all processes (each one works on their own data), and they share the data model and calculation logics
  • each administrator user can have different rights to the process (the set of rules to be used, editable data and available data entry forms etc.).

This solution avoids the need to transfer or synchronise data between the various application databases. By contrast, managing user rights and specific features and/or peculiarities of individual companies is onerous and complex.

Administration of data model and distributed calculation logics

This architecture has the following characteristics:

  • multiple application databases, each of which has a different data model on which multiple processes can be managed (e.g. budget, actual, forecast)
  • each administrator user has different rights on different application/processes databases

This solution offers complete freedom in customising the data model and calculation logics. By contrast, this requires transferring/synchronising data between application databases which can be very onerous.

Other than these two types, intermediate architectures can also be created for specific requirements.