One of the most important aspects of understanding the practice of normalizing services is the actual scope or boundary in which the normalization effort is carried out. As we explained in the previous installment in this series, the Domain Inventory pattern enables you to establish multiple collections of independently standardized and governed services within the same IT enterprise. These service inventories (or "continents of services" as they are sometimes referred to) correspond to domains that still allow you to achieve service-orientation goals to a meaningful extent.
A service inventory blueprint is also defined during the analysis and modeling stages and the boundary of a given blueprint typically determines the scope at which Service Normalization is applied. This means that you are allowed to have overlapping service boundaries and redundant service logic, as long as it occurs across domain service inventories (not within a given service inventory).
The rules established by Service Normalization make their way into service modeling processes and overall service delivery methodologies. Avoiding functional overlap becomes a constant consideration and often forms the basis of a dedicated process step (especially for modeling processes that are carried out iteratively). It is also one of those considerations that needs to be tracked and coordinated when you have different teams working in parallel to model services for the same service inventory.
Yet despite best efforts, functional overlap still can happen. Something may get missed within the service inventory blueprint and services with similar capabilities are then inadvertently built. Or, there may even be hard constraints that prevent this pattern from being fully applied, such as when different services need to encapsulate legacy systems that themselves cannot be normalized. In this case, there may be embedded or entrenched logic that unavoidably leads to an extent of redundancy. Then, of course, there is the performance issue. You may run into a situation where delivering fully normalized services will impose unreasonable runtime latency and the only way out of it is to intentionally design some measure of denormalization into the services.