Service mapping can be applied in these business use cases.
Use service mapping to cater for incompatible requirements among different service clients.
Service versioning arises as a natural side-effect of having a service that is used by a number of different service clients. Often, one or more of the organizations or applications that use a service place new requirements on the service. Sometimes, a service can be changed in a way that is fully compatible with an earlier version. In other cases, version compatibility cannot be maintained. For example, a particular service operation might need to return an extra field. This field might be a fundamental requirement for one particular service client, but might not be compatible with existing service clients.
A developer can deal with this simple example by inserting a service map that discards the additional field for those service clients that do not want to use it.
Service maps can transform between the operations and messages that two different interfaces use.
It is common for business-led projects to take a top-down approach to defining the services that they need. Meanwhile, it is also common for IT-owned shared services to be defined based on the requirements of a number of different such business-led projects. These divergent approaches often mean that a component that expects a project-specific interface must use a centrally owned, generic enterprise service. This scenario is often called meet in the middle. The enterprise service does what the project needs, but the service is not in the format that the business interface expects.
A developer can deal with these mismatches of interface by defining a service map that transforms between the operations and the messages that each interface expects.