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.