update README.adoc

README.adoc

@@ -2,13 +2,13 @@
 
 This is one of the backend services that push data to the documentation repository.
 
-The `build` of this service includes a test that generates a `.json` file for the central link:https://github.com/automatic-architecture-documentation/documentation[documentation repository].
+The `build` of this service includes tests that generates various JSON file for the central link:https://github.com/automatic-architecture-documentation/documentation[documentation repository].
 
 == How Does It Work?
 
-The principle is relatively straightforward: _gather data during testing / building and combine this data in a Gradle task._
+The principle is relatively straightforward: _gather data during testing / building and combine this data in a Gradle task to get a unified description of an application's component._
 
-The application's description is explicitly defined in a test, allowing for the generation of all hard-coded descriptions from one place: link:src/test/kotlin/application/ArchitectureDocumentationTests.kt[ArchitectureDocumentationTests]
+The application's main description is explicitly defined in a test, allowing for the generation of all hard-coded descriptions from one place: link:src/test/kotlin/application/ArchitectureDocumentationTests.kt[ArchitectureDocumentationTests]
 
 The _dependencies_ of this application are generated by the tests of the classes that serve as proxies for these dependencies.
 For example,
@@ -27,8 +27,9 @@ For those not utilizing PACT, dependents can be manually specified, akin to the
 
 All collected data is stored in JSON format within the `build/architecture-documentation` folder.
 
-During the Gradle `build`, this data is processed by a custom task designed to generate the comprehensive application description JSON file.
-This file is then uploaded to the documentation repository.
+During the CI-build of the `master` branch, the generated files are collected, and processed using a shared GitHub action of the central documentation repository.
+This allows us to change anything we want regarding the handling / combination of the data without having to update all relevant component repositories.
+The only changes that need to be synchronized with the component repositories  are changes to the data models.
 
 == Future Improvements
 
@@ -37,6 +38,7 @@ There are several possible sources of data, to make the generated application de
 
 * We could involve parts of the application configuration to enrich the data about 3rd party systems (e.g. hostnames).
 * For databases, we could include the type of SQL database based on the used JDBC driver.
+* For databases, we could determine and include the description of tables, columns, indices and other relevant parts.
 * For NoSQL databases, we could detect which ones are used based on dependencies and configuration properties.
 * For messaging, we could include the used topics / queue names as well as routing keys.