SDC is the OpenECOMP visual modeling and design tool. It creates internal metadata that describes assets used by all OpenECOMP components, both at design time and run time.
SDC manages four levels of assets:
- Resource: a fundamental capability, implemented either entirely in software, or as software that interacts with a hardware device. Each Resource is a combination of one or more Virtual Function Components (VFCs), along with all the information necessary to instantiate, update, delete, and manage the Resource. A Resource also includes license-related information. There are three kinds of Resource:
- Infrastructure (the Cloud resources, e.g., Compute, Storage)
- Network (network connectivity functions & elements); example: a Virtual Network Function (VNF)
- Application (features and capabilities of a software application); example: a load-balancing function
- Service: a well formed object comprising one or more Resources. Service Designers create Services from Resources, and include all of the information about the Service needed to instantiate, update, delete, and manage the Service
- Product: includes one or more Services packaged with commercialization attributes for customer ordering, billing, and issue resolution. Products are created by Product Managers, and can have one or more "category" attributes assigned by Product Strategists.
- Offer: bundling of Products with specific Marketing configurations for selling to customers
The key output of SDC is a set of models containing descriptions of asset capabilities and instructions to manage them. These models are stored in the SDC Master Reference Catalog for the entire enterprise to use.
There are four major components of SDC:
- The Catalog is the repository for assets at the Resource, Service and Product levels. Assets are added to the Catalog using the Design Studio.
- The Design Studio is used to create, modify, and add Resource, Service, and Product definitions in the Catalog.
- The Certification Studio, available in a future release, is used to test new assets at all levels. It will be used for sandbox experimentation, and will include support for automated testing.
- The Distribution Studio is used to deploy certified assets. From the Distribution studio, new Product assets, including their underlying Resources and Services, are deployed into lab environments for testing purposes, and into production after certification is complete. In a future release, there will be a way to export Product information to external Business Support Systems for customer ordering and billing.
<<TODO: the following paragraph requires expert review; for example, are Heat Templates really Information Artifacts rather than Deployment Artifacts?>>
The definitions of assets include Information Artifacts and Deployment Artifacts. Information Artifacts provide all of the information that anyone viewing the Resource/Service/Product would need to understand what the asset does, how it works, how to create an instance of it in the network, and how to support it once it is deployed. Deployment Artifacts provide the information files, instruction files, templates, or executable files needed to create an instance of the asset in the network. Deployment Artifacts can include Heat Templates for cloud infrastructure creation, YANG XML files for state data manipulated by the Network Configuration Protocol, TOSCA for specifying cloud infrastructure, or BPMN/BPEL for specifying business processes and the interconnections in a service-oriented architecture).
See the <<DocRef: SDC Demo Guide >> for how to onboard a Virtual Network Function, using SDC.