I'm doing some departmental re-org stuff at the moment and its made me really believe in the difference between the service and its interface. Way back in 2000 I worked on a project and developed a framework (who didn't in 2000) that allowed you to have multiple different interfaces on the same back-end service. The reason for this was that different clients needed to see different subsets of capabilities and rather than showing everyone a great big interface with everything on it, which would be complicated, it seemed simpler to just separate the interface from the service.
Doing the business bit has made me really strongly realise how important it is to keep them apart. Right now I've effectively got four different groups who need to interface to this one business service.
Now the core of the service is the same for everyone, they all want basically the same thing. The difference comes in exactly how they want to interact with it and the specifics of the capabilities that they will use. This means four independent sets of external KPIs (remember to always think of the consumer when designing service descriptions) and four semi-independent sets of capabilities. By semi-independent I mean that they are in fact strongly linked but the mode of interaction is slightly different in each case.
Now if you were building the code for this you might be thinking of four independent services that shared information together. The problem is that this means that you have disjoint processes as the reality is that one of the major KPIs for the service is that you are linking properly with all the other groups.
Sometimes you will build the interface as just that, an interface, other times it will be a lightweight façade that might do some process or data manipulation work, on a very few occasions it might be something heavier weight but still using the same underlying base service.
The other technical view would be the "sod the users" and just have one interface. The trouble is that this just means that it will be rubbish to use for everyone and it will in fact be harder to manage because that doesn't represent the way that the world actually operates.
So what I've got is a service description that describes what the service does and then I'm building four service interfaces (which are to all intents and purposes service descriptions) on how it will interact and be measured by the four external parties. This means that from a catalogue perspective I have five services, from a consumer perspective they are all getting the service that they want and from my perspective I'm getting the consistent management and centralised governance that I need.
Everyone ends up happy and the amount of duplicated work is reduced. So keep your interfaces independent of your service.