Updates to the conceptual model to separate app operator and developer roles

1.purpose_and_goals.md

@@ -6,12 +6,15 @@ For example, a contemporary cloud application may be composed of dozens of micro
 
 This specification provides a description of such applications, where the description is aimed at separating the concerns of developers from the concerns of operators. Furthermore, it suggests patterns and processes for managing such applications. The specification describes a model for cloud native (i.e. highly distributed) cloud applications, encompassing public cloud technologies, on-prem solutions, and IoT/edge technologies. By specifying a common model, this specification provides a foundation for multiple implementations of a shared description of cloud native applications.
 
-This open specification defines:
+This open specification defines the following model:
 
-- __Component schematics__, where developers declare the operational characteristics of the code they deliver _in infrastructure neutral terms_.
-- __Application scopes__, a way to group components into loosely coupled applications with common characteristics.
+![Conceptual Model Diagram](./assets/conceptual-model-diagram.png)
+
+- __Component__, where developers declare the operational characteristics of the code they deliver _in infrastructure neutral terms_.
+- __Scopes__, a way to loosely couple components into groups with common characteristics.
+- __Applications__, where developers group components together into a single, deployable unit and specifies cross-component info, such as health scopes.
 - __Traits__ for assigning operational features to instances of components.
-- __Application configuration__, defines a deployment of components, their traits, and application scopes.
+- __Application configuration__, defines a configuration of an application, its traits, and additional scopes, such as network scopes.
 - __Workload types and configurations__, which describe the underlying runtime for a particular workload, as well as exposing per-application configuration.
 
 Additional goals of the specification are to:

2.overview_and_terminology.md

@@ -6,9 +6,9 @@ This section provides an overview of the specification and the terminology. It b
 
 As a foundation for the specification, the following roles are defined. These are extracted from a combination of user stories, research, and user input. While this is not an exhaustive list of possible roles, these are the roles identified as the primary targets for this specification.
 
-- __Developers__ deliver business value in the form of code. While they should understand the operational characteristics of the code they deliver, they are unconcerned with _how_ operational requirements are fulfilled. For instance, a developer may be aware that their code writes data to a specific path on a file system, but need not concern themselves with what kind of volume (disk) is mounted to that path or how that dependency is fulfilled.
+- __Developers__ deliver business value in the form of code. While they should understand the operational characteristics of the code they deliver, they are unconcerned with _how_ operational requirements are fulfilled. For instance, a developer may be aware that their code writes data to a specific path on a file system, but need not concern themselves with what kind of volume (disk) is mounted to that path or how that dependency is fulfilled. This role includes the responsibilities of application architect.
 
-- __Application operators__ deliver business value by configuring, installing, and managing components and/or applications such as updating, scaling, auto recovery, etc. Unlike developers and application composers, operators are concerned with _how_ a component or application's operational requirements are fulfilled. For instance, if a developer has declared that a component writes data to a specific path on a file system, an operator may concern themselves with mounting an appropriate volume to that path.
+- __Application operators__ deliver business value by configuring, installing, and managing components and/or applications such as updating, scaling, auto recovery, etc. Unlike developers, operators are concerned with _how_ a component or application's operational requirements are fulfilled. For instance, if a developer has declared that a component writes data to a specific path on a file system, an operator may concern themselves with mounting an appropriate volume to that path.
 
 - __Infrastructure operators__ deliver value by managing low-level infrastructural components. This may range from managing the physical hardware in an on-premises network to directly managing cloud service offerings in a public cloud. Infrastructure operators are less concerned with the particular configuration needs of _an application_, focusing instead on the big picture of how an enterprise's overall infrastructure is managed. For example, an infrastructure operator may manage the underlying storage offerings that are used for provisioning persistent storage.
 
@@ -18,15 +18,18 @@ In many organizations, some individuals may fulfill more than one of the above r
 
 This specification proposes a model that defines cloud native applications as follows:
 
-> A cloud native application is a collection of interrelated, but discrete _components_ (services, tasks, workers) that, when coupled with configuration and instantiated in a suitable runtime, together accomplish a unified functional purpose.
+> A cloud native application is a collection of interrelated, but discrete _components_ (services, tasks, workers) that are grouped as an _application_.  This _application_ is combined with a configuration and instantiated in a suitable runtime to accomplish a unified functional purpose.
 
 The application model defines the following:
 
- - _Components_ represents a runnable unit, together with a description (schematic).
+![Conceptual Model Diagram](./assets/conceptual-model-diagram.png)
+
+ - _Components_ represent runnable units, together with a description (schematic).
  - _Workload types_ identify the different workloads that a component can execute.
+ - An _application_ is a group of _Components_ that represents a deployable unit of functionality.
  - _Traits_ are overlays that augment a component with additional operations-specific features. Traits represent operator concerns, not developer concerns.
- - _Application scopes_ represent application boundaries by grouping components with common properties or dependencies.
- - An _application configuration_ describes a set of component instances, their traits, and the application scopes in which they are placed, combined with configuration parameters and metadata.
+ - _Scopes_ represent application boundaries by grouping components with common properties or dependencies.
+ - An _application configuration_ describes an application's traits, and the application scopes in which they are placed, combined with configuration parameters and metadata.
 
 Thus, an _application_ is a collection of _components_ with a set of operational traits and scoped together into one or more application boundaries. 
 
@@ -122,7 +125,7 @@ A component schematic is composed of the following pieces of information:
 - Metadata: Information _about_ the component, primarily directed toward the user
 - Resource requirements: The additional minimum needs that must be satisfied in order for the component to be executed. For example, minimum memory, CPU, and filesystem mounts
 - Parameters: The parameters that can be adjusted for specific runtime configuration
-- Containers: A list of the runnable pieces (OCI images, functions, etc.) used by this component. All built-in component workload types have at least one associated container
+- Workload: A list of the runnable pieces (OCI images, functions, etc.) used by this component. The initial version will only support container workloads.
 
 ### Workloads and Workload Types
 
@@ -143,7 +146,7 @@ A trait is described as:
 
 ### Application Configuration
 
-An application configuration is a resource that declares how an application (described as an application schematic and component schematics) can be instantiated and configured, including which parameter overrides and add-on traits.
+An application configuration is a resource that declares how an application can be instantiated and configured, including which parameter overrides and add-on traits.
 
 An application configuration has the following parts:
 
@@ -154,7 +157,7 @@ An application configuration has the following parts:
 
 ## Representing Hydra Objects as Schematics
 
-The Hydra specification represents Hydra schematics (components, trait definitions, application configurations, etc.) as _schematics_. A schematic is a structured document that provides a declaration of an object or an object's desired state. Throughout this specification, schematics are represented in [YAML]() formatting. However, nothing in this specification forecloses the possibility of representing schematics as JSON documents or other similarly structured textual or binary representations.
+The Hydra specification represents Hydra schematics (components, applications, trait definitions, application configurations, etc.) as _schematics_. A schematic is a structured document that provides a declaration of an object or an object's desired state. Throughout this specification, schematics are represented in [YAML]() formatting. However, nothing in this specification forecloses the possibility of representing schematics as JSON documents or other similarly structured textual or binary representations.
 
 ### The Structure of a Schematic