| Archiving | Removing of data from source system after those data were stored (Saved) into an Archive (for later restore). Compare to "Purging". Several technical principles for archiving and many tools based on those priniciples are available, but today's real challenge is the specification WHICH data need to be archived and retained for how long, and which data must be purged and are not allowed to be archived because of privacy protection laws. These issues are addressed in our Template Archiving and Purging Requirements |
|---|
| asl | Application Service Library. A method for application management developed by http://www.aslfoundation.org
|
|---|
| Availability | describes the time when a service is available for usage. If planned outages (maintenance windows) are counted as Downtime or not when calculating the achived availability depends on the SLA.
|
|---|
| Backup | Process of saving (storing) data to alternative media, so that those data can be restored in case that they get lost on the primary location. A working (and restore-tested) backup is absolutely necessary and mandatory, but does not necessarily provide the capability to restore and recover in case of a disaster. Several technologies for backup and recovery and many products are available, but the challenge is to define and agree with the backup team on the most suitable backup level. This is addressed in Operations Level Agreement (OLA) for Backup and Recovery (Backup SLA). |
|---|
| Business Continuity |
All means which ensure that critical and vital business functions can continue even in case of a disaster. |
|---|
| Continous Availability | is even more then just
High Availability! In case of "High Availability" planned downtime for upgrades is still allowed, "Continous Availability" requires "rolling upgrades" without need for shutdown.
|
|---|
| Disaster Recovery (DR) |
Covers the technical aspect of the broader term Business Continuity (BC).
A broad range of different technologies and tools for Disaster Recovery is available,
the challenge is the
Selection of the most suitable technology for the individual case.
|
|---|
| High Availability | provides avaiability even if one component fails. This is achieved by redundant components, e.g. Standby Databases which allow a failover if the primary database is not available.
Note that in case of "High Availability" planned downtime for upgrades is still allowed. If even this planned downtime is not
acceptable, then the next level of "Continous Availability" is required. |
|---|
| | |
|---|
| Purging | Removing (deleting) of data WITHOUT storing (saving) them into another location or system. Purged data cannot be restored! |
|---|
| Reconciliation | Comparing data on both side of an interface to validate that data were correctly and completely transferred. It is highly recommended that for all interfaces automated reconciliations are implemented. As auditors will very likely execute such reconciliations during the audit, regular reconciliations executed by application management or operations team and corrections in case that differences are detected, will reduce the likelyhood that auditors will detect missing or duplicate data. |
|---|
| Robustness |
The feature that an application does not run into serious problems or even crash at slightest disturbance or deviation from normal operations. Robustness is an important design principle and in most cases robustness can't be easily added afterwards. Therefore it is of high importance to pay attention to robustness requirements when defining the non-functional requirements!
Selected examples for Robustness Requirements
|
|---|
| Standby Database |
A copy of production database which is permanent synchronized (on commit, but also with a few hour delay). Purpose of a Standby Database is to become the "Primary Database" if the original database is not available. There exist several different ways to implement a Standby Database, those concepts are explained and compared in Selecting the right type of standby database |
|---|
| | |
|---|
