I know an architect who is developing an enterprise service for the passing of contracts from one system to another, (document metadata, not the image). He knows the needs of the destination system very well, but he defined an interface that is not sufficient to meet the needs.
The interface describes the subset of data that the source system is prepared to send. The source system is new, and will be released in iterations. Eventually, it will send all of the data that the destination system needs.
In the mean time, it will send only a subset.
For some reason, he wants the interface to change with each iteration. And thus, he will create the service repeatedly.
This thinking is typical: define what you need, refactor as you go. The problem is that it ASSUMES that no one else ever needs to call your service or use your service. It assumes that no one else will get to the destination system first. In short, that you know everything.
The justification: we will change the destination system when the source system comes online. Since we will not change it right now, there is no need to model the interface.
What do you think? Should the interface describe all of the data that will eventually be needed, even if neither the source nor destination systems can leverage all of it yet? Should there be a different interface each time the behavior of the destination system changes?