The Production functional block is the one that is in charge of service management. Namely, the products offered in Core Commerce Management are built using the Customer Facing Services (CFSs) which are exposed by the Production functional block. The CFSs, on the other hand, are built within Production using Resource Facing Services (RFSs) and Resource Functions (RFs).
Using the exposed APIs of this functional block, the Core commerce management can ask for the fulfilment of services that compose a given ordered product, or the Engagement management block can forward a user request for changing an existing service. The main functionalities of the Production block include all activities related to the end-to-end service and resource lifecycle management including, in the case of multi-domain service partnering, actions that may span across multiple organisations that are part of the ecosystem. The Production block is also responsible for the service development, infrastructure deployment, operations management, usage and performance management, workforce management, resource provisioning, service and resources catalogues and inventories, etc.
The main SPA components fall into the Production functional block following the ODA orchestration layering principles with service orchestration, resource orchestration and technical domains. Each of the components is exposed via a corresponding TMForum Open API. The service orchestration layer components include the main service-oriented processes in the orchestrator and all service-related components such as service ordering, service inventory that stores all service instances, service testing and service-related fault management.
The service ordering component is implemented together with the product ordering component using the free, open-source version of OTRS, where different order types are stored in different queues and references are created between related tickets.
Similar implementation is done for the ticketing related to problem management and fault management, where in the case of fault management the ticket creation is based on an alarm raised by a service monitoring system.
The service test component is used to perform regular tests of the service. In addition, the service test component can be used to perform a pre-release check before informing the user that anorder is feasible. This regular testing may be integrated with an external system for performance management.
There is also an implementation of a policy engine that acts as a service qualification component, where, based on the defined rules, the engine checks if a service with the requested parameters can be ordered or otherwise managed by the requesting user.
Although in the figure the orchestrator is mapped only to the production service orchestration layer, some of the processes belong to the Core Commerce functional block, while others are part of the resource orchestration layer. At the moment, all processes defined in the orchestrator are completely automated, no human intervention is needed other than the initial request trigger. However, in case it is necessary, the orchestrator also supports partial automation, involving multiple human actions during the process.
The resource orchestration layer also includes an in-house implementation of a resource inventory that contains the logical abstract representation of all resources that are managed by the system. The referencing between the service and resource inventory enables continuous tracking of the resource usage and all service/resource dependencies. This inventory must be treated as a single source of truth inventory so that the information is consistent across the system and the orchestration processes can be implemented in a fully automated fashion.