Service vs. Function part II

I just came up with a pretty good explanation of the difference between a service and a function, to clarify on a recent post. It kind of explains why it is difficult to reach an agreement, since people are discussing on different levels. So, watch this: Suppose that you’re a consultant, and you have a contract to perform a certain task, with certain deliverables and other agreements on what’s included. Then the service is the contract, and what you actually do is the function. This works for software services as well as for services of an enterprise that are comprised not only of software, but also of people and organizations.

Advertisement

How to Agree on the Difference between a Service and a Function

In this post, I’ll establish exactly what’s the difference between a service (SOA parlance) and a function. Just joking, no, I won’t. I participated in an animated discussion today about the topic, and the discussion just went on and on. The participants were very bright people, and everyone was right in some way. We just couldn’t move the discussion forward! (Although some progress was made; I admit that.)

So at first, I thought that I’d better write a post to settle the issue. But soon, I realized that then I’d just take my part in the “I know best” game, so I simply skip that, and attack the more abstract problem of how such a problem should be addressed. That is, if you have a disagreement about a concept, and everyone is talking about it from different positions of understanding, and with different levels of abstraction in their understanding, and varying confidence in themselves, how would you settle the discussion with everyone reasonably satisfied?

I’m afraid I don’t have a complete solution to that, so I’ll try to outline some ingredients.

• Try to make everyone listen and understand the others’ points of view.
• Try to make everyone understand the structure of the others’ model of the concept.
• Try to see what differs between those views, and those structures.
• Then argue in a structured way using that knowledge, for example, argue on compatible levels of abstraction, and on compatible scenarios.

Is this possible at all? Any better ideas for getting to consensus on important concepts?

Maybe Edward de Bono‘s Six Thinking Hats could help?

The context in this case is modelling an enterprise using the MODAF modelling framework, which is nice in itself. But since it’s very strict in how things should be modelled, it seems that it’s even harder to make people agree on how to model things.