Skip to main content
Version: 12

ADOGRC Hardware/Software Requirements

ADOGRC Specific Extensions to the Hardware/Software Requirements

Introduction

The hardware and software requirements outlined in this document are required to operate ADOGRC of the BOC Group. They are an extension to the Hardware and Software Requirements of ADONIS and as such, apply on top of them.

The system requirements described in this document are provided to define a baseline for the successful operation of ADOGRC. Validating the exact system sizing based on the target scenario is strongly recommended before any production deployment.

Supported Scenarios

Prior to the start of all projects it is strongly recommended to evaluate the size of the scenario and the required systems with your BOC contact in order to avoid restrictions and limitations due to underestimated sizing.

How to Estimate the Size of the ADOGRC Scenario

Below you find a few guidelines to help you estimate the size of the ADOGRC in order to plan for the hardware requirements:

Risks, Risk Assessments
  • Maximum number of Risks and Risk Assessments managed within ADOGRC.
  • Frequency and distribution of changes to the master data and assessment of risks.
    Example: How many risks will be assessed on a monthly basis?
  • Load spikes when a very large number of assessments are all due on the same date.
    Example: All risk assessments start on September 1st.
Controls, Control Tests, Control Executions
  • Maximum number of Controls, Control Tests and Control Executions managed within ADOGRC.
  • Average number of Controls, Control Tests and Control Executions assigned to a specific user.
  • Frequency and distribution of changes to master data, tests and execution of controls.
    Example: How many controls are tested on a monthly basis?
  • Load spikes when a very large number of tests are all due on the same date.
    Example: All control tests start on March 1st.
Users, Roles
  • Number of users with access to ADOGRC components.
  • Expected number of concurrent users in the ADOGRC components.
  • Average number of ADOGRC related objects assigned to a specific user.
  • Maximum number of ADOGRC related objects assigned to a specific user.

Based on the criteria as outlined above, you can compare your estimates with the two examples in the following section to determine the projected size of your scenario. An example of hardware requirements for a typical ADOGRC scenario is outlined in the section Hardware Recommendations.

ADOGRC Scenarios and Sizes

The following examples outline a typical and a larged ADOGRC scenario. It consists of ADONIS content, like models and processes, and ADOGRC content. Risks, Risk Assessments, Controls, Control Executions, Control Testings and Initiatives are here collectively referred to as ADOGRC objects even though they can of course be used in ADONIS content as well.


ADOGRC Standard Scenario

This example describes a typical ADOGRC scenario which should fit most customer environments.

Number of ADOGRC objects
  • between 4000 and 8000 ADOGRC objects
Number of users participating in ADOGRC workflows
  • about 50 to 100 ADOGRC "Contributor" users
  • there is a maximum of 10 to 15 concurrent ADOGRC "Contributor" users
System load due to common workflow deadlines
  • Deadlines for assessments and reviews are distributed across multiple phases throughout the year to avoid excessive load spikes on certain dates.

ADOGRC Scenario with High Maturity

This example describes an ADOGRC scenario with high maturity as found in large companies with lots of active users.

Number of ADOGRC objects
  • between 15000 and 20000 ADOGRC objects
Number of users participating in ADOGRC workflows
  • about 100 to 300 ADOGRC "Contributor" users
  • there is a maximum of 30 to 40 concurrent ADOGRC "Contributor" users
System load due to common workflow deadlines
  • Deadlines for assessments and reviews are distributed across multiple phases throughout the year to avoid excessive load spikes on certain dates.

Installation Options

note

For a deployment of ADOGRC, setting up a load-balanced configuration with at least two aworker instances is required. One of the aworker instances will be used by the ADOGRC Scheduler component for recurring operational tasks. For more information, please refer to ADONIS Hardware/Software requirements Installation Option 3 (Load Balancing)

Software Requirements

For ADOGRC, the regular ADONIS Software Requirements apply but with the extensions and constraints outlined in this chapter.

Database Server (may be located on a different server)

note

Due to restrictions on functionality and performance, the Microsoft SQL Server "Express Edition" is not supported by ADOGRC

caution

For additional security, we recommend to encrypt the database, e.g. via Transparent Data Encryption (TDE) in case of Microsoft SQL Server or similar mechanisms in other database systems.

Server Component ADONIS Web Server

Java Memory Settings Addition: The following Java VM memory settings must be set for the servlet container (e.g. Tomcat):

Maximum Memory heap size (JVM parameter -Xmx) must be set to at least 3072 MB. Recommended are 4096 MB or higher.

Maximum Size for Email Notifications The file adoxx_web.properties contains the setting for mail.max_mail_size which is 50 kB by default. This size allows for up to 100 object links in a notification email. In case of more objects in a notification, thisvalue should be increased by 50 kB per 100 objects (e.g. for 300 object links in a notification email the maximum size should be set to 150 kB)

For the various third-party software packages mentioned in the sections above and in the ADONIS Software Requirements, please also take into consideration the hardware and software requirements and recommendations the individual vendors provide.

Hardware Recommendations

For ADOGRC, the regular ADONIS software requirements apply but with the extensions and constraints outlined in this chapter.

ADONIS Web Client

Screen resolution As the ADOGRC scenario offers dashboards presenting a lot of vital information (e.g. listing all risks of an operation and their most important characteristics) and charts, a screen resolution of 1920 x 1080 or higher is recommended.

Server Component ADONIS Web Server

RAM size Addition: for ADOGRC increased requirements apply

  • a minimum of 4096 MB is required by ADONIS on an Apache Tomcat web server deployment
  • recommended are 6144 MB or higher (more then 4096 MB of RAM requires a 64-bit operating system)
  • additional resources according to the size of the environment (see the examples for ADOGRC scenarios)

Number of CPU cores (physical or virtual) Addition: increased CPU requirements for ADOGRC

  • one additional CPU core is required by the ADOGRC Scheduler component
  • minimum of 4 CPU cores in total are required

Server Component ADONIS Application Server

ADOGRC Scheduler Addition: increased hardware requirements for the ADOGRC Scheduler component which performs recurring operational tasks in the background

  • one additional *aworker* instance is required for the ADOGRC Scheduler component. This increases the RAM and CPU requirements as described below.

RAM size Addition: increased RAM requirements for ADOGRC

  • a minimum of 6144 MB is required (more than 4096 MB of RAM rquires a 64-bit operating system)
  • recommended are 8192 MB or higher
  • additional resources according to the size of the environment (see the examples for ADOGRC scenarios)

Number of CPU cores (physical or virtual) Addition: increased CPU requirements for ADOGRC

  • one additional CPU core is required
  • a minimum of 4 CPU cores is required in total

Database Server (may be located on a different server)

Hard Disk Capacity Several of the components of ADOGRC support the upload of external documents, e.g. protocols for control executions. These documents are stored safely in the database and therefore require additional hard disk space for the database files.

Bandwidth Requirements

There are no changes to the requirements as described in the respective ADONIS Hardware/Software requirements section.

Authentication Mechanisms of the ADONIS Web Client

There are no changes to the requirements as described in the respective ADONIS Hardware/Software requirements section.

Server Hardware Recommendations

Based on a typical scenario (for examples, please see ADOGRC Scenarios and Sizes, this table below outlines the hardware requirements for servers in an ADONIS with ADOGRC deployment. If your scenario deviates significantly from the example below, please consult your BOC key account manager at BOC.

This scenario extends the ADONIS Load-Balanced scenario with 4,000 ADOGRC objects and with a maximum of 10 concurrent ADOGRC users.

  • The base scenario includes a model repository of 1,000 models with a medium average model size (up to 40 objects and relations per model).
  • In addition, the scenario contains 4,000 ADOGRC objects (such as Risks, Controls, Risk Assessments, Control Tests and Control Executions).
  • There is a maximum of 20 concurrent users of which a maximum of 10 users are concurrent ADOGRC users.
note

Please note that load balancing is currently only supported at the level of the ADONIS Application Server. Load Balancing is NOT supported at the level of the ADONIS Web Server.

Number of CPU cores (physical or virtual)
  • ADONIS Web Server: 6 CPU cores total
  • ADONIS Application Server: 6 CPU cores total, 4 *aworker* instances
RAM
  • ADONIS Web Server: 6 GB RAM total
  • ADONIS Application Server: 8 GB RAM total
Hard Disk Capacity
  • ADONIS Web Server: 1 GB total
  • ADONIS Application Server: 4 GB total
  • Database Server: 2 GB total and additional space for uploaded documents (e.g. protocols of control executions)

Required Permissions

There are no changes to the requirements as described in the respective ADONIS Hardware/Software requirements section.

Required Permissions - Citrix Server

There are no changes to the requirements as described in the respective ADONIS Hardware/Software requirements section.

Backup and Restore

The BOC Management Office tools (ADONIS, ADOIT & ADOGRC) store data in a relational database. To protect the data in case of unintended deletion or modification as well as in a disaster recovery scenario when productive data sets are lost or corrupted, we recommend that all clients set up a robust and automated backup and restore procedure.

Please note that BOC does not maintain or provide any means for an automated backup within its tools - the client is responsible that reliable backups of data and software are performed on a regular basis and comply with the needs, rules and regulations of the given scenario (e.g. legal requirements).

Manual Backup

For details on how to manually Create a Manual Backup and Restore a Manual Backup, please refer to the respective sections in the ADONIS Administration manual.

Database Backup

Based on best practices, we recommend the following backup strategy. Please note, that depending on regulatory or business needs this strategy will have to be adapted to your individual scenario. At the start of a backup strategy it is necessary to execute a restore test to verify that backups can be fully restored.

Full Backups (entire database and external content)
  • Automated
  • Weekly
Incremental Backups
  • Automated
  • Daily
Retention
  • Based on legal requirements / audit requirements
  • As risks and controls often are subject to an annual review cycle, backups should be retained for at least 1 year.
RPO (Recovery Point Objective)
  • 24 h
RTO (Recovery Time Objective)
  • According to standard SLA (Service Level Agreement) for critical hotline incidents
Restore TypeFull database restore, either
  • in-place (not recommended) or
  • in a separate location (recommended)
Monitoring
  • Success messages and error logs
  • Plausibility checks of the backup sets (e.g. file size)
Encryption
  • We recommend both transport encryption as well as encrypted storage of backup sets with proper role-based access control in place.
  • Note: Backups of encrypted databases (e.g. TDE) will need the original encryption keys to restore