About Conceptual Model Entities

A conceptual model includes the following entities that you configure to support the behavior for a specific domain:

• Customer facing services, which represent your services from a customer perspective. See "About Customer Facing Services" for more information.

• Resource facing services, which represent a technical view of a service. See "About Resource Facing Services" for more information.

• Resources, which represent the entities that are required to configure the service. See "About Resources" for more information.

• Products, which represent your commercial products. See "About Products" for more information.

• Locations, which represent physical locations. For example, in a Broadband service, the DSL RFS for a DSL service can be associated with a location to represent the address of the customer.

• Service actions, which are requests to update the design of a customer facing service, a resource facing service, or a resource. See "About Conceptual Model Actions" for more information.

• Technical actions, which are requests to downstream delivery systems to make changes in the network (the downstream delivery systems are represented by an application role). Technical actions are associated with resource facing services or resources. See "About Conceptual Model Actions" for more information.

• Action parameter bindings, which enable you to:

  • Identify the conceptual model entities, such as a resource or a resource facing service, that contribute to the creation of technical actions.

  • Bind the attributes defined for a conceptual model entity or the entity itself (the source data) to parameters defined for technical actions (the target data).

  See "About Action Parameter Bindings" for more information.

• Domains, which are groups of entities and actions that you can use to organize and filter conceptual models. See "About Domains" for more information.

The following conceptual model entities help to define the model infrastructure and rarely require updates. You can extend these entities to meet the requirements of a specific deployment:

• Application roles, which represent types of downstream delivery systems that are responsible for specific types of delivery, such as activation, supply chain management, work force management, and so forth.

  See "About Application Roles" for more information.

• Functional areas, which are the logical layers of an installation and can be commercial, service, and technical layers. These layers are supported by an Order and Service Management order type or by an external order management system. See "About Functional Areas" for more information.

• Provider functions, which are processing components that perform a defined set of tasks based on their role in a solution. Design Studio includes the configuration for some provider functions, such as Calculate Service Order, Design and Assign, Calculate Technical Order, and Activation. See "About Provider Functions" for more information.

• Fulfillment patterns, which determine the high-level functions that are required to process an action or conceptual model entities. Fulfillment patterns include any number of fulfillment functions. See "About Fulfillment Patterns" for more information.

• Fulfillment functions, which represent the work to be performed against an action. Fulfillment functions can be augmented with conditions to determine whether the function is to be performed against an action. See "About Fulfillment Functions" for more information.