Onboarding documentation update for CLI

Change-Id: I1d4d0111063ea62c3759aa9b7232998b70229644
Issue-ID: DCAEGEN2-350
Signed-off-by: Ralph Knag <rhknag@research.att.com>

2 files changed, 8 insertions, 4 deletions

diff --git a/platformdoc/docs/architecture/service-discovery.md b/platformdoc/docs/architecture/service-discovery.md
index 25d69fcf..9831efcf 100644
--- a/platformdoc/docs/architecture/service-discovery.md
+++ b/platformdoc/docs/architecture/service-discovery.md
@@ -2,7 +2,7 @@
 
 Service discovery is an architecture pattern used for components (micro-services) to locate each other.  The DCAE platform uses [server-side discovery](http://microservices.io/patterns/server-side-discovery.html) and is using [Consul](https://www.consul.io/) as the service registry solution.
 
-## Service registration
+## Service Registration
 
 All components are required to register with Consul in order to be discovered.  There are two methods of registration: self and 3rd party.  The DCAE platform uses 3rd party registration which means components don't actually make the registration calls but defers that responsibility to a platform service.
 
diff --git a/platformdoc/docs/architecture/services.md b/platformdoc/docs/architecture/services.md
index 985953c3..f17f563b 100644
--- a/platformdoc/docs/architecture/services.md
+++ b/platformdoc/docs/architecture/services.md
@@ -1,7 +1,11 @@
 # 'Services' Overview 
 
-DCAE Services run on the DCAE platform. A service performs either monitors the virtualized network services or does analytics. A service is composed of one or more components, and performs a business need.
+DCAE Services run on the DCAE platform. A service either monitors the virtualized network services or does analytics. A service is composed of one or more components, and performs a business need.
 
 Services are created in a 'Service Design and Creation' tool called 'Service Assurance Flow Designer' by a Service Designer. This is done by 
-* 1. 'compose'ing a service from the available SDC catalog components (actually from the TOSCA models representing the components), then
-* 2. 'submit'ing the service, which generates a Cloudify blueprint, is then automatically uploaded to INVENTORY,  and then deployed by DEPLOYMENT HANDLER (once a DTI Event is triggered for the service). It should be noted that some service flows, specifally 'closed-loop' flows,  are not initiated by DTI, but are done by CLAMP. 
+
+* 'compose'ing a service from the available SDC catalog components (actually from the TOSCA models representing the components), then
+* 'submit'ing the service, which generates a Cloudify blueprint, which is then automatically uploaded to INVENTORY, and then deployed by DEPLOYMENT HANDLER (and CLOUDIFY) (once a DTI Event is triggered for the service). It should be noted that some service flows, specifally 'closed-loop' flows,  are not initiated by DTI, but are done by CLAMP. 
+
+Only a few services are supported in SDC so far, and therefore steps above are done manually by the Onboarding Team for most services.
+