Service Normalization Pattern
Encyclopedia
Service Normalization is a design pattern
, applied within the service-orientation
design paradigm
, whose application ensures that services that are part of the same service inventory do not contain any redundant functionality. 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 design pattern provides guidelines for creating service inventories that contain streamlined services without any functional duplication. By creating normalized services, the purpose of the service also becomes clearer to its potential consumers.
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 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 service delivery process where the service delivery process can start once sufficient services have been modeled without waiting to create a full service inventory 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.
Design pattern (computer science)
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that...
, applied within the service-orientation
Service-orientation
Service-orientation is a design paradigm to build computer software in the form of services. Like other design paradigms , service-orientation provides a governing approach to automate business logic as distributed systems...
design paradigm
Design paradigm
The term Design paradigm derives from the rather ambiguous idea of paradigm originating in Sociology of Science, which carries at least two main meanings:...
, whose application ensures that services that are part of the same service inventory do not contain any redundant functionality. This design pattern emphasizes on creating normalized services
Database normalization
In the design of a relational database management system , the process of organizing data to minimize redundancy is called normalization. The goal of database normalization is to decompose relations with anomalies in order to produce smaller, well-structured relations...
, 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.
Rationale
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 design pattern provides guidelines for creating service inventories that contain streamlined services without any functional duplication. By creating normalized services, the purpose of the service also becomes clearer to its potential consumers.
Usage
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:
- Decompose the business process into individual steps that falls within the boundary of a specific service inventory.
- Assign each step to an individual function of a service
- Make sure that the above functionality is not already provided by some other service.
- Even if a service provides part of the new required functionality, instead of creating altogether a new service, the new functionality needs to be added to the existing service as long as the functional context of the functionality being added matches with the existing service’s functional context.
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
SOA Governance
SOA governance is a concept used for activities related to exercising control over services in a service-oriented architecture . SOA governance can be seen as a subset of IT governance which itself is a subset of corporate governance. The focus is on those resources to be leveraged for SOA to...
overhead of the service inventory. The application of this design pattern further supports the application of the Logic Centralization
Logic Centralization Pattern
Logic Centralization is a design pattern, applied within the service-orientation design paradigm, whose application aims to increase the reusability potential of agnostic logic by ensuring that services do not contain redundant agnostic logic and that any reusable logic should only be represented...
and the Service Refactoring
Service Refactoring
Within the service-orientation design paradigm, Service Refactoring is a design pattern, which is applied to an existing service so that either the service logic or its implementation can be changed without affecting the service consumers.-Rationale:...
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.
Considerations
The application of this design pattern requires following a top-down service delivery 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 service delivery process where the service delivery process can start once sufficient services have been modeled without waiting to create a full service inventory 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.