diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
index 8bdb96cd1948..a56531ab02df 100644
--- a/_topic_maps/_topic_map.yml
+++ b/_topic_maps/_topic_map.yml
@@ -58,6 +58,8 @@ Name: Architecture
 Dir: architecture
 Distros: openshift-enterprise,openshift-origin,openshift-online
 Topics:
+- Name: Architecture overview
+  File: index
 - Name: Product architecture
   File: architecture
 - Name: Installation and update
diff --git a/architecture/index.adoc b/architecture/index.adoc
new file mode 100644
index 000000000000..f67c94cab7a9
--- /dev/null
+++ b/architecture/index.adoc
@@ -0,0 +1,70 @@
+[id="architecture-overview"]
+= Architecture overview
+include::modules/common-attributes.adoc[]
+:context: architecture-overview
+
+toc::[]
+
+{product-title} is a cloud-based Kubernetes container platform.
+The foundation of {product-title} is based on Kubernetes and therefore shares the same technology.
+To learn more about {product-title} and Kubernetes, see xref:../architecture/architecture.adoc#architecture[product architecture].
+
+[id="about-installation-and-updates"]
+== About installation and updates
+
+As a cluster administrator, you can use the {product-title} xref:../architecture/architecture-installation.adoc#architecture-installation[installation program] to install and deploy a cluster by using one of the following methods:
+
+** Installer-provisioned infrastructure
+** User-provisioned infrastructure 
+
+[id="about-control-planes"]
+== About the control plane
+
+The xref:../architecture/control-plane.adoc#control-plane[control plane] manages the worker nodes and the pods in your cluster. You can configure nodes with the use of machine config pools (MCPs).
+MCPs are groups of machines, such as control plane components or user workloads, that are based on the resources that they handle.
+{product-title} assigns different roles to hosts. These roles define the function of a machine in a cluster.
+The cluster contains definitions for the standard control plane and worker role types.
+
+You can use Operators to package, deploy, and manage services on the control plane.
+Operators are important components in {product-title} because they provide the following services:
+
+* Perform health checks
+* Provide ways to watch applications
+* Manage over-the-air updates
+* Ensure applications stay in the specified state
+
+[id="about-containerized-applications-for-developers"]
+== About containerized applications for developers
+
+As a developer, you can use different tools, methods, and formats to xref:../architecture/understanding-development.adoc#understanding-development[develop your containerized application] based on your unique requirements, for example:
+
+* Use various build-tool, base-image, and registry options to build a simple container application.
+* Use supporting components such as OperatorHub and templates to develop your application.
+* Package and deploy your application as an Operator.
+
+You can also create a Kubernetes manifest and store it in a Git repository.
+Kubernetes works on basic units called pods. A pod is a single instance of a running process in your cluster. Pods can contain one or more containers.
+You can create a service by grouping a set of pods and their access policies.
+Services provide permanent internal IP addresses and host names for other applications to use as pods are created and destroyed. Kubernetes defines workloads based on the type of your application.
+
+[id="coreos-and-ignition"]
+== About {op-system-first} and Ignition
+
+As a cluster administrator, you can perform the following {op-system-first} tasks:
+
+** Learn about the next generation of xref:../architecture/architecture-rhcos.adoc#architecture-rhcos[single-purpose container operating system technology].
+** Choose how to configure {op-system-first}
+** Choose how to deploy {op-system-first}:
+*** Installer-provisioned deployment
+*** User-provisioned deployment
+
+The {product-title} installation program creates the Ignition configuration files that you need to deploy your cluster.
+{op-system-first} uses Ignition during the initial configuration to perform common disk tasks, such as partitioning, formatting, writing files, and configuring users.
+During the first boot, Ignition reads its configuration from the installation media or the location that you specify and applies the configuration to the machines.
+
+You can learn how xref:../architecture/architecture-rhcos.adoc#architecture-rhcos[Ignition works], the process for a {op-system-first} machine in an {product-title} cluster, view Ignition configuration files, and change Ignition configuration after an installation.
+
+[id="about-admission-plug-ins"]
+== About admission plug-ins
+You can use xref:../architecture/admission-plug-ins.adoc#admission-plug-ins[admission plug-ins] to regulate how {product-title} functions. After a resource request is authenticated and authorized, admission plug-ins intercept the resource request to the master API to validate resource requests and to ensure that scaling policies are adhered to.
+Admission plug-ins are used to enforce security policies, resource limitations, or configuration requirements.