SOA - Dealing with Consumers Requirements

Services are created to be consumed. In case a Service isn't good enough (does not provide enough value), It fails on Its primary reason to exist. This makes sense for most of the companies I know and It is not different when talking about SOA. The goal of this post isn't advocate about SOA itself or disvantages/advantages of this Architectural Style. The idea  is highlight the consequences of drive Services requirements based only on consumers needs.

What is a Service?

It is a high level abstractions exposed as a business functionality to be consumed. By mentioning "high level abstraction", I mean, It should shape a business functionality as It really is (how It behaves). Low level details like  protocols, security, infrastructure, specific data consumer structures should  be out of the scope here.
Some of the ideas behind this definition are:

1. If business change, Service needs to change quickly - The advantage of dealing with high level business abstractions is because Service will need to change only the when business behaviour changess and not other layers. By avoiding introducing low level details on the Service design, you'll be able to respond quickly to business changes than doing the opposite.
2. Stay aligned with Business Strategies - That means, if companies wants to be able to consider expose business functionality for different consumers/medias/plataforms or compose several services to create  new business functionality, for instance, Service design should support It.

Dealing with Consumers Requirements

During the development life cycle, there will be cases where might be easier accommodate modifications on Services side in order to attend specifc consumer needs. By following this approach, you are creating a coupling on the Services design that isn't desirable. Services may looses It's capacity to quickly respond to changes without affect It's consumers.

Consider  a Sales Service that returns alls sales for a given Customer. Lets say there is a consumer (an UI) that needs display the sales in a specific order, different than the one returned by the Sales Service. For the UI point of view, would be easier have the sales returned on the order It needs. It may advocates the Service is much closer to the data. So ordering information there would be faster than iterating the sales  again on  the UI side and order the data as It needs.  

But now, lets consider the same services needs to be consumed by another API. What about this API needs the same information in a different order than UI?  

See, consumers driven  decisions increases the coupling by making Services harder to change without breaking other consumers. Services loose the capacity to quickly respond to business changes on these cases

Conclusion

The "sorting" example may looks a bit silly, maybe yes.. but consequences are the same when changing contract data structures/behaviour just to make consumer's life easier. So, be cautious when dealing with consumers driven requirements.  To avoid It, make your services Consumers Agnostic by avoiding  consumer specific requirements fall into the your Service design.