GrC Maintenance

The Operations team performs regular maintenance work on the infrastructure and application. This covers both production and non-production environments.

Maintenance types:

• Monthly regular maintenance
• Platform and application upgrades
• Zero-downtime activities
• Maintenance on customer requests
• Emergency maintenance

The service manager notifies the customer in advance of upcoming maintenance. The above maintenance activities are considered planned downtimes under the BMC Helix Availability Policy and Service Level Agreement (SLA).

Monthly regular maintenance

Materna is responsible for patching and all other maintenance of the underlying infrastructure. Monthly maintenance may include the following, exemplary activities:

• Updates to the underlying infrastructure, including database, network components and virtual hosts
• Migrations and upgrades to the infrastructure

Regular maintenance may occur in a monthly push to proactively apply server, backup, and security activities. Maintenance is typically performed according to the following schedule: 

Environment	Schedule
Non-Production (Development and QA)	Every second Tuesday of a month after 05:00 pm (UCT)
Production	Every second Thursday of a month after 08:00 pm (UCT)

These upgrades will be processed as a standard change and the customer will be informed by a regular appointment. Any deviations from this procedure will be communicated separately by Materna in advance.

Standard monthly maintenance windows in production last a maximum of 4 hours, with the aim of causing no downtime (zero downtime). While most maintenance does not require downtime, upgrades to infrastructure and shared services may require restarts of servers / containers within this window. 

Upgrades of BMC Helix platform and applications

In addition to maintaining the infrastructure components used, Materna also carries out upgrades of the BMC Helix platform and applications used. 

The platform and application upgrades are designed as zero-downtime-upgrades where full functionality for end-users is given throughout the upgrade period. There might appear some small limitations and operations to be avoided during the upgrade caused by the application: Zero-downtime upgrade for BMC Helix Innovation Suite and applications.

The customer is responsible for testing his application including his customizations on the non-productive systems within a maximum timeframe of 4 weeks. If necessary, the customer is also responsible for modifying his customizations in this period to be compliant to new application version.

Platform upgrades

The upgrade of the platform will be planned by Materna and announced 7 days in advance for non-prod and for production systems since these upgrades have no effect on customer’s applications. Platform upgrades are always rolled-out before application upgrades.

Application Upgrades

The non-productive systems and productive systems are always upgraded separately. The application upgrades of non-production systems will be announced in 7 days in advanced by Materna.

BMC Helix version concurrency

It is ensured that all services are on the latest generally available release. Materna implements new GA releases within 3 months of notification by BMC Helix.

Zero-downtime activities

Regular work is carried out on the infrastructure that is typically subject to a zero downtime policy. The availability of the service is given during the work, but there is still a very low risk of short interruptions during the maintenance. The customer is informed about this work in advance. Any anticipated risk time will be disclosed in the customer notification.

Maintenance on customer request

The services provided to the customer are proactively updated and maintained by Materna Operations.  However, customers can request dedicated upgrades or hotfixes. These are to be coordinated together with the service manager who is responsible for the service.

Emergency maintenance

Emergency changes are required to address a current outage situation in a customer's environment or to prevent an impending outage or security incident. Notifications will be sent to customers on short notice and as soon as possible.

Customization staging

This section is relevant for subscribers of:

• BMC Helix IT Service Management
• BMC Helix Business Workflows (Innovation Suite)

BMC Helix for German Regulated Cloud gives the customer full admin access to the Development Remedy ARS system. Adjustments / customizations can be carried out on the DEV environment. The possibilities include both forms and workflow. New integrations can also be developed and tested on this environment. Loading data from new sources is another use case that can be performed in the Development environment.

The best practices of the manufacturer BMC Software must be adhered to when making adjustments, so that no situation can arise in which the entire system loses its upgrade capability.

The QA and PROD environments are so-called "controlled environments". Here, admin access is reserved for the Materna Operations team.

Once the customer has completed a customization, he can package it using standard Remedy ARS tools (Development Studio, ARExport, Deployment Manager), document it and make it available to the Materna Operations team. This is a standard request for change. The Operations team validates the package and performs the transport to the QA system.

Tests can be performed on the QA system by the customer and other parties. These are usually referred to as User Acceptance Tests (UAT). Once the tests are complete, the customer can request the transport to PROD from the Materna Operations team. Again, this is a standard request for change. The Operations team performs the transport to the PROD system.

R: Responsible; A: Accountable; C: Consulted; I: Informed

Activity	Environment	Customer *	Materna
Development (forms, workflows, integrations, data loads)	Development	R, A
Packaging, documentation	Development	R, A	C, I
Request: Staging QA	Development	R, A	I
Verification of customization (upgrade capability)	Development	A	R
Implementation staging	Quality Assurance	I, A	R
Execution of tests and acceptance QA	Quality Assurance	R, A	I
Request: Staging PROD	Quality Assurance	R, A	I
Implementation staging	PROD	A	R
Execution of tests and acceptance PROD		R, A	I