Add architecture section

Author: GitHub Actions

assemblies/assembly-orchestrator-rhdh.adoc

@@ -27,7 +27,7 @@ To start using Orchestrator in {product-very-short}, you must:
 * Import the Orchestrator software templates into the {product} catalog
 
 // orchestrator architecture
-include::modules/orchestrator/con-supported-architecture-for-orchestrator.adoc[leveloffset=+1]
+include::modules/orchestrator/con-architecture-overview.adoc[leveloffset=+1]
 
 // provisioning plugin dependencies
 include::modules/orchestrator/con-orchestrator-plugin-dependencies-operator.adoc[leveloffset=+1]

modules/orchestrator/con-architecture-overview.adoc

@@ -0,0 +1,39 @@
+:_mod-docs-content-type: CONCEPT
+
+[id="con-architecture-overview.adoc_{context}"]
+= Architecture overview
+
+You can use Orchestrator to design, run, and monitor workflows that automate key tasks. The Orchestrator relies on core components, such as SonataFlow and OpenShift Serverless, to provide the necessary runtime environment and event-driven capabilities needed to power your workflows.
+
+The Orchestrator architecture is composed of the following several integral components, each contributing to the seamless execution and management of workflows:
+
+{product} ({product-very-short}):: Serves as the primary interface. {product-custom-resource-type} fulfills the following roles:
+
+* Orchestrator Plugins: Both frontend and backend present deployed workflows for execution and monitoring.
+* Notifications Plugin: Inform users about workflow events.
+
+OpenShift Serverless Logic Operator:: This controller manages the Sonataflow custom resource (CR), where each CR denotes a deployed workflow.
+
+Sonataflow Runtime/Workflow Application:: Functions as a deployed workflow. Sonataflow Runtime is managed as a Kubernetes (K8s) deployment by the Operator. It operates as an HTTP server catering to requests for executing workflow instances. Within the Orchestrator deployment, each Sonataflow custom resource (CR) corresponds to a singular workflow. However, outside this scope, Sonataflow Runtime can handle multiple workflows. The Orchestrator backend plugin facilitates the interaction with Sonataflow Runtime for workflow execution.
+
+Data Index Service:: Serves as a repository for workflow definitions, instances, and associated jobs. It exposes a GraphQL API used by the Orchestrator backend plugin to retrieve workflow definitions and instances.
+
+Job Service:: Dedicated to orchestrating scheduled tasks for workflows.
+
+OpenShift Serverless:: This operator furnishes serverless capabilities essential for workflow communication. It employs Knative eventing to interface with the Data Index service and uses Knative functions to introduce more intricate logic to workflows.
+
+PostgreSQL Server:: PostgreSQL Server provides a robust and reliable database solution essential for data persistence within the Orchestrator ecosystem. The system uses PostgreSQL Server for storing both Sonataflow information and {product-custom-resource-type} data.
+
+KeyCloak:: KeyCloak is essential for enhancing security measures by being responsible for authentication and security services within applications. KeyCloak must be provisioned externally to manage authentication, as the Orchestrator Operator does not install it.
+
+OpenShift AMQ Streams (Strimzi/Kafka):: This Operator is crucial for ensuring the reliability of the eventing system. It is not presently integrated into the deployment current iteration.
+
+
+The `dynamic-plugins.default.yaml` file includes the following Orchestrator plugin components, but disables them by default:
+
+* `"backstage-plugin-orchestrator"`
+* `"backstage-plugin-orchestrator-backend-dynamic"`
+* `"backstage-plugin-scaffolder-backend-module-orchestrator-dynamic"`
+* `"backstage-plugin-orchestrator-form-widgets"`
+
+To enable these plugins, you must set the `plugins.disabled` parameter to `false`.