Figure CP.01 - Configuration Spec and Configuration

A Configuration may contain one or more parts (which is realized by using the Atomic/Composite pattern, but it is represented as a single entity - ConfigurationRelationship), and each part may contain zero or more fields. Each field may have attributes that are statically or dynamically defined. Some of these fields have fixed values, while others provide values from which a choice or choices can be made (e.g., using the EntitySpec/Entity and/or CharacteristicSpec/CharacteristicValue patterns).<br/>The SID framework has defined both a Service Configuration ABE as well as a Resource Configuration ABE. There are eTOM L2 core processes that deal with configuring services (Service Configuration & Activation) and provisioning resources (Resource Provisioning), as well as TAM applications that support these processes and ABEs. The purpose of this document is to define these two key concepts from these ABEs, and describe how they can be used to aid in the configuration process. There is also a Product Configuration ABE that has been added to the SID framework that is included in this guide book and the model. <br/><b>Introduction and Motivation</b><br/>The configuration of products, services and resources may consist of a number of very complex processes. An approach to reducing the complex of the configuration process is to identify common patterns that can be re-used. To that end, this document and the associated business agreement (mentioned previously) sets out to identify common re-usable patterns in the area of product, service and resource configuration.  These are modeled within the Configuration and Profiling ABE in the Common Business Entities domain. <br/>It is envisioned that SID implementers will begin to use the Service Configuration ABE as an alternative to Resource Facing Service Specification and Resource Facing Service ABEs.  The reason is that the Service Configuration ABE provides a more complete model that represents how services are configured.  However, the current Resource Facing Service ABEs will not be removed from the model to preserve backward compatibility and to not impact conformance to them.<br/><br/>A Configuration (also referred to as a Profile) defines how a Resource, Service, or Product operates or functions. A Configuration may contain one or more parts (which is realized by using the Atomic/Composite pattern, but it is represented as a single entity - ConfigurationRelationship), and each part may contain zero or more fields. Each field may have attributes that are statically or dynamically defined. Some of these fields have fixed values, while others provide values from which a choice or choices can be made (e.g., using the EntitySpec/Entity and/or CharacteristicSpec/CharacteristicValue patterns).<br/>Starting from the right-side of the figure:<br/><ul>
<li>The Resource, Service and Product classes are as defined in the SID model.</li></ul>
<ul>
<li>The associated configuration objects are used to define additional properties (attributes) of the associated entity. For example, consider an Equipment instance (a Resource). The intrinsic properties of the Equipment instance (perhaps but not necessarily common to all Equipment instances) are defined in the Resource itself. Additional properties (which may not be common to all Equipment instances) are provided in one or one Resource Configuration instances.</li></ul>
<ul>
<li>It is possible to relate one instance of Configuration to several others via the ConfigRelationship. This is useful when configuring complex (aggregate) entities. For example, to configure a circuit pack, one may also need to configure the various ports supported by the circuit pack and in turn, the connection termination points supported by the ports.</li></ul>
On the left-side of the figure, there are various Configuration Specifications that correspond to the various Configuration classes on the right-side of the figure. This is the typical EntitySpecification/Entity pattern already present in the SID model but now applied to a particular kind of Entity, i.e., a Configuration.  The EntitySpecification represents the definition of an entity. The idea is that the various ResourceConfigSpec instances are reusable across many instances of Resource.<br/>