Service normalization pattern
For example, the automation of two different business processes, by two different teams, which need to exchange messages with the same legacy system may end up in two different versions of a wrapper service that are created to enable exchange of messages with the services.
In order to create service models, following activities need to be performed: The same process needs to be applied to each business process that falls within the boundaries of the service inventory.
The application of this design pattern requires following a top–down service delivery[7] process, which requires considerable upfront analysis before any actual services are delivered.
This requires extra resources both in terms of man-hours as well as time.
An ongoing governance of existing normalized services is required as more and more business processes are automated.
In the absence of a service inventory blueprint, the automation of Business Process 2 resulted in the creation of the red service which shares most of its functionality with the red service created earlier while automating Business Process 1.
The creation of a service inventory blueprint results in the merger of the two red services into one red service and any functionality not falling within the context of the red service is added to the new orange service.