UserDocumentation
diff --git a/src/main/asciidoc/architectureDocumentation/architectureDocumentation.adoc b/src/main/asciidoc/architectureDocumentation/architectureDocumentation.adoc
index 6a79087..4bc8af4 100644
--- a/src/main/asciidoc/architectureDocumentation/architectureDocumentation.adoc
+++ b/src/main/asciidoc/architectureDocumentation/architectureDocumentation.adoc
@@ -1,4 +1,4 @@
-////
+////
  *******************************************************************************
  * Copyright (c) 2019 Contributors to the Eclipse Foundation
  *
@@ -29,7 +29,7 @@
 
 === Requirements Overview
 
-Many user modules of an openKONSEQUENZ installion need contact datas for their
+Many user modules of an openKONSEQUENZ installion need contact data for their
 daily business. Furthermore they have to fulfil the regulatory requirement
 of the General Data Protection Regulation (GDPR).
 
@@ -49,17 +49,17 @@
 * *Flexibility* The reference platform shall grant that different systems and modules from different vendors/developers can interact and interoperate, and may be exchanged or recombined.
 * *Availability* All platform modules that are running on the platform can only be as available as the platform same for user modules that are based on platform modules.
 * *Maintainability* (and testability as part of maintainability)  The platform and its platform modules shall be used longer than 15 years.
-* *Integration performance* New implemented functionality of oK own modules and external modules shall be included fast / automatically.
+* *Integration performance* New implemented functionality of oK's own modules and external modules shall be included fast / automatically.
 * *Security* The platform and its modules need to underly security-by-design
 
 The main quality goals of the core module Contact Base Data are:
 
 * *Functionality* The core module must fulfil the functional requirements mentioned in the section before
-* *Ergonomics* The web interface must be realized according to oK-GUI-Styleguide.
+* *Ergonomics* The web interface must be realized according to oK-GUI-styleguide.
 * *Good documentation* (i.e. code and architecture documentation) makes code changes easier and automatic
 tests facilitate rigorous verification.
 * *Modifiability* (and testability as part of modifiability)
-* *Integration performance* The core module must be easy integratable in different production environments.
+* *Integration performance* The core module's integration into different production environments has to be easy.
 
 The following documents contain the quality goals in detail:
 
@@ -69,7 +69,7 @@
 The architecture is based on the AC-Handbook. The quality demands are described in the QC-Handbook.
 Both specifications were fully complied with in the project, so that a high quality is given.
 
-The code quality regarding static code analysis and unit test code coverage on the backend and fronend sides
+The code quality regarding static code analysis and unit test code coverage on the backend and frontend sides
 are ensured by the use of sonarqube. The rule set and the qualtity gate are defined by the default, the
 so called "sonar way".
 
@@ -478,9 +478,9 @@
 
 === Solution Strategy
 
-The module 'Contact Base Data' bases on a three-tier architecture:
+The module 'Contact Base Data' is based on a three-tier architecture:
 
-. *Frontend* - The GUI is implemented as a web-frontend with rich-client functionalities.
+. *Frontend* - The GUI is implemented as a web-frontend with rich-client functionality.
 . *Backend* - The business functionalities are implemented in the backend tier. It provides the business functions via RESTful Webservices.
 . *Database* - The database stores all module specific data.
 
@@ -493,7 +493,7 @@
 
 . *UI* - Represents the graphical user interface and consumes the services from the business logic component via RESTful webservices.
 . *Business Logic* - Realizes the business functionality and the data storage of the module. The
-module itself is split up in several components due to the requirement to use
+module itself is split up into several components due to the requirement to use
 microservices.
 
 .Module components
@@ -542,7 +542,7 @@
 
 ==== ContactBaseDataFE (frontend tier)
 
-The frontend component implements the concept of a single-page application (SPA). The framework used is Angular5.
+The frontend component implements the concept of a single-page application (SPA). The framework used is Angular 8.
 
 It divides the contactBaseDataFE into three layers:
 
@@ -701,7 +701,7 @@
 The component "Flyway" is used to make to distribute structural
 or content related changes to the database.
 
-The database is built out of the scripts in the directory "db/migrations". Every sql
+The database is built out of the scripts in the directory "db/migrations". Every SQL
 script contains the complete db script for the contact base data database (in different versions).
 The highest version number indicates the currently valid script.
 
@@ -719,12 +719,12 @@
 
 This yml-file can be divided into different configuration profiles.
 When starting the backend-service one has the possibility to specify
-the active profile
+the active profile.
 
 * *spring.datasource* configuration section for the database connection
 * *flyway.enabled* If enabled=true then the database migrations
-      will automatically performed when starting the application
-      (this parameter should normally be set to "false"
+      will be performed automatically when starting the application
+      (this parameter should normally be set to "false")
 * *server.max-http-header-size* Maximum size for the http-headers
 * *jwt.tokenHeader* Name of the http-header which carries the authentication-token.
       (should be "Authorization")
@@ -732,9 +732,9 @@
       as Authorization-token. (This won't work for calls to other modules
       like the Auth'n'Auth-Modul, because the token will be out of date)
 * *authNAuthService.ribbon.listOfServers* Here one can configure the base
-     url to the Auth'n'Auth-Service
+     URL to the Auth'n'Auth-service
 * *ldap.enabled* If set to "true" the ldap functionality will be enabled
-* *ldap.scheduling.enabled* (true or false) swtiches the ldap synchronisation on/off
+* *ldap.scheduling.enabled* (true or false) switches the ldap synchronisation on/off
 
 
 === CI- and CD-Components
@@ -759,13 +759,13 @@
 . "SNAPSHOT" or "DEVELOP"
 . "MASTER" or "TRUNC"
 
-The running development is exclusively made on the Snapshot-Branch. Every time
+The running development is exclusively made on the snapshot-branch. Every time
 a developer checks in (pushes) code to the repository, an automatic build
-starts on the hudson ci-server. If the Snapshot-build is successful, then the result
-of that build is directly deployed on the Dev-environment.
+starts on the hudson ci-server. If the snapshot-build is successful, then the result
+of that build is directly deployed on the dev-environment.
 
 At the end of a scrum sprint or when a big user story is realized, all
-the code changes are merged from the *Snapshot*-Branch to the *Trunc*.
+code changes are merged from the *SNAPSHOT*-Branch to the *TRUNC*.
 This automatically triggers the build and the deployment on the
 Q-environment.
 
@@ -790,10 +790,10 @@
 |CNCU|Central Network Control Unit||
 |DAO|Data Access Objects||
 |DTO|Data Transfer Object||
-|DSO|Distribution System Operator|Verteilnetz-betreiber (VNB)|Manages the distribution network for energy, gas or water.
+|DSO|Distribution System Operator|Verteilnetzbetreiber (VNB)|Manages the distribution network for energy, gas or water.
 |EPL|Eclipse Public License||Underlying license model for Eclipse projects like contact-base-data@openK
 |ESB|Enterprise Service Bus||Central instance to exchange data to overcome point-to-point connections.
 |oK|openKONSEQUENZ|openKONSEQUENZ|Name of the consortium of DSOs
 |QC|Quality Committee|Qualitätskomitee|Gives framework and constraints according to quality for oK projects.
-|SCADA|Supervisory Control and Data Acquisition|Netzleitsystem|System, that allows DSOs view/control actual parameters of their power grid.
+|SCADA|Supervisory Control and Data Acquisition|Netzleitsystem|System, that allows DSOs to view/control actual parameters of their power grid.
 |========================================================