Service normalization is a design pattern, applied within the service-orientation design paradigm, whose application ensures that services[1] that are part of the same service inventory[2] do not contain any redundant functionality.[3] This design pattern emphasizes on creating normalized services, much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.
When different teams are delivering multiple services as part of automating various business processes, there is a possibility that some of these services might end up having duplicate functionality. 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. This overlap in functionality can lead to other problems including which service to be advertised as the official service for the provision of a particular functionality and maintenance of redundant services as they can easily get out of alignment.
In order to deliver services, as part of the same service inventory, that are free of any duplicate functionality, the functional boundary of each service needs to be carefully established so that it is not in conflict with any other service. The Service Normalization[4] design pattern provides guidelines for creating service inventories that contain streamlined services without any functional duplication.[5] By creating normalized services, the purpose of the service also becomes clearer to its potential consumers.[6]
The application of this design pattern requires knowledge about the functional contexts of all the services because only then it can be guaranteed that the services do not contain any overlapping functionality. This is achieved by creating service models i.e. services without any actual service contracts but having high level details about the kind of functionality that they would be providing. 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.
By following the guidelines of the service normalization design pattern, the total number of services within the service inventory would also decrease. This is because the development of redundant services is avoided, which further helps in decreasing the governance overhead of the service inventory. The application of this design pattern further supports the application of the logic centralization and the service refactoring design patterns. This is because the services do not contain any redundant functionality and hence it is easy to retain logic that does not relate to a particular business process in a single service and to evolve a service without breaking any dependencies.
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. This could be addressed by the adoption of meet-in-the-middle[8] service delivery process where the service delivery process can start once sufficient services have been modeled without waiting to create a full service inventory[9] blueprint.
An ongoing governance of existing normalized services is required as more and more business processes are automated. This is because the automation of new business processes might result in adding functionality to the existing normalized services and to make sure that these services remain normalized, rest of the services need to be analyzed.