Open Group IT4IT Reference Architecture Fulfillment Execution Component

​Purpose

The Fulfillment Execution functional component orchestrates the delivery of the various requests amongst (one or more) fulfillment engines in order to deliver the IT service. Fulfillers may be systems that perform actions directly, or engage other systems in order to perform actions. They may also include external providers. In order to be able to engage the fulfillers, the Fulfillment Execution functional component needs to:

• Manage a registry of the available fulfillers. This registry captures:
• What each fulfiller does (capabilities)
• How to engage each fulfiller (where they are located and how to invoke them)
• Take the bound Service Catalog Entry and generate both the relevant Fulfillment Requests in order to realize/fulfill the originating consumer request and the Desired Service Model data object which represents the Service Model in its pre-configured or consumer configured state.
• Update the IT asset inventory as they are ordered.
• Request standard changes and update the Configuration Management functional component (if needed) on delivery of components.
• Maintain visibility into supplier capacity levels and raise alerts if capacity appears to be insufficient for immediate demand.
  

The Fulfillment Execution functional component can be used via two paradigms:

• Consumer-driven – In this paradigm a consumer request results in a bound Service Catalog Entry which is broken down into the necessary Fulfillment Requests needed to fulfill the originating request.
• Direct access (without a Service Catalog Entry) – In cases in which there aren’t sufficient catalog entries to describe the fulfillment and no entries are planned to be created, the Fulfillment Execution functional component is directly engaged by the Release Composition functional component (R2D Value Stream). The Release Composition functional component needs to provide enough information in order for the Fulfillment Execution functional component to create the Fulfillment Request(s) necessary to perform the actions needed.
  

• Shall select the appropriate fulfillment mechanism.
• Shall coordinate if multiple fulfillment mechanisms are needed and manage the dependencies required to fulfill the IT service request.
• Shall provide the Subscription status to the Request Rationalization functional component.
• Shall create the Actual Service CIs within the Configuration Management functional component.
• May create an RFC associated with the service instantiation that is created within the Change Control functional component (D2C Value Stream). The RFC type, standard or normal, is determined within the Change Control functional component.
• Can create a new service monitor or modify an existing one for the service provided in the Request as part of fulfillment.
• Can create/route a Request to an external service provider to fulfill part or all of the service.
• Can request IT assets necessary for fulfillment (such as licenses). This also enables the tracking of assets being requested or procured and links them with the services that require them.
• Can trigger deployment engines to enable fulfillment of the service.