Principle: Every application creates and monitors its own backups
Statement:
Every application in production requires its own backup. The creation of the backup is monitored and alerts are triggered in case of failure (see Logging). A recovery plan exists and has been tested at least once. Ideally, such a test takes place once a year.
Reason:
Most applications store data that changes during runtime and is an important part of the application. Since this data can be lost for various reasons, and this makes the application's functionality difficult or even impossible, a functioning backup and recovery process is needed.
Implications:
The backup process requires a concept about which parts of the application must be part of the backup, how frequently backups should be made, how long they should be kept, in what format, and how many copies of the backups must be maintained. Both data protection and storage space play a role in these considerations.
Principle: Software Containerization
Statement:
The application's software should be developed and deployed in a container.
Reason:
Containerization enables software and its dependencies to be isolated. This has many advantages, including integration into DevOps workflows, resulting in more efficient software development and deployment.
Implications:
Containerization requires developers to have additional knowledge and routines.
Principle: Email Sending via myclimate Microsoft Exchange
Statement:
All applications that send emails on behalf of myclimate do so through a specially configured email address and Microsoft Exchange via SMTP.
Reason:
myclimate's Microsoft Exchange Server can send authorized emails on behalf of myclimate and is subject to the required data protection regulations. No additional costs are incurred.
Implications:
Setting up such an account must be done through the myclimate IT operations provider and requires additional information:
- The account should be used for SMTP sending
- Multi-factor authentication must be disabled
- The requirement for regular password renewal must be disabled
Principle: APIs to "Surrounding Systems"
Statement:
When integrating other systems, APIs should be provided in such a way that similar tasks can be accomplished with a single API.
Reason:
This ensures that not every new application requires the introduction of many new APIs.
Implications:
Generalized APIs should be provided between core systems (PRIMA, Registry, etc.) and digital offerings. The initial creation of a generalized API may be complex. It must be able to grow with its requirements, and existing APIs must be actively maintained. Furthermore, the APIs must be well documented. The savings result from the lower number of APIs to operate and easier further development.
Principle: Continuous Maintenance and Support
Statement:
Software applications require continuous maintenance and support - independent of further feature development.
Reason:
To maintain long-term operability and a good security level, a software application and the server it runs on need regular updates. Security updates require special attention. This applies even if an application is not being further developed in terms of content.
Implications:
Resources must be continuously planned for infrastructure updates and software updates.
Principle: One "myclimate" Account for our (external) clients in the Digital Space
Statement:
All "digital" customer offerings from myclimate use the same authorization component (Microsoft Entra)
Reason:
Different accounts for the same company create uncertainty for the customer and prevent later integration of services.
Implications:
Requirements must be considered mandatory when introducing new solutions.
Principle: Multiple Active Environments in the Development Process
Statement:
Every application that is already in productive use provides an additional environment for development and testing purposes.
Reason:
A staging environment or a preview app enables the client to test and approve newly developed features and fixed bugs. This constitutes an important step in quality assurance. Potential errors are identified early and are not carried over into live operations.
Implications:
An additional environment involves a multi-stage deployment process and higher server costs. Depending on the underlying databases, the setup may also require agreements on the status and potential update process of the data between the different environments. The data in the staging environment must be anonymized.
Dependencies between different applications may only exist within the same environment. (This means: a staging version of one application can only access data from the staging version of another application, to prevent accidental manipulation of production data during the testing process.)
Principle: Uptime Monitoring for Quality Assurance
Statement:
Uptime monitoring provides information about the unavailability of the application and enables swift intervention.
Reason:
Quality commitments regarding software availability require uptime monitoring. The unavailability of an application can have various causes. Being informed that an application is unavailable is the starting point for investigating the root causes and preventing prolonged downtime.
Implications:
There are paid services that enable uptime monitoring (e.g., Honeybadger).