February 25, 2009, 3:45 PM — When designing data architectures, you can easily end up with different databases or even different database tables containing the same or similar data. This has been the root of many well documented data maintenance and quality issues that helped establish data normalization as widely accepted data modeling best practice. On a fundamental level, the aim of data normalization is to reduce data redundancy to whatever extent possible. This forces any applications that need to use a specific type of data to access it in one location. Therefore, by eliminating data redundancy, data normalization also promotes data reuse.
Reusability is, of course, also a primary goal of service-orientation. So much so that one of its eight principles (the Service Reusability principle) is dedicated solely to enabling this quality in services. Service Normalization is one of many patterns that support service reusability, but its goals go beyond that. Like data normalization, the Service Normalization pattern is intent on reducing redundancy and waste in order to avoid the governance burden associated with having to maintain and synchronize similar or duplicate bodies of service logic.
To accomplish this, Service Normalization essentially draws lines in the sand that establish the boundaries of services so that they do not overlap. Unlike data normalization, Service Normalization is not limited to data. Its primary concern is the normalization of functional service boundaries. Therefore, you will usually find yourself applying this pattern during the service modeling stages, when services are first conceptualized.