Well, to come up with the applications, you just have to go back to the original rationale to use computers: to automate the generation of some kind of answer t

Well, to come up with the applications, you just have to go back to the original rationale to use computers: to automate the generation of some kind of answer to a question. The automation should be either equal to or higher quality than a manual alternative, or so much faster and cheaper that lower quality is acceptable. When we look at that in terms of service interfaces, it's an attempt to black-box some part of answer generation, to say "this other party will do that"...which means that it's orthogonal to the answer itself. The most direct way to get good answers would be to already know them, and everything else, like the question you ask of an interface, is secondary. Interfaces tend to be a point of friction to accessing answers because they have to assume in some sense that you know what you want to ask and how you want to phrase it. If you got the right answer from asking the wrong question you'd be extremely pleased but also confused. So it helps to establish concretely what kinds of questions are asked for each application, and turn those into interface specs. That's where a lot of the design challenge is - capturing the question/answer cycle succinctly, without overgeneralizing.