I tried to make a sit reservation for an ICE (a nice train - perfectly suitable for hacking or writing). Because I travel a bit, I'm a bahn.comfort customer - its something like frequent flyer.To make the reservation, the DB-clerk ask his colleague to get a phone and called the bahn.comfort line. It took about 5 minutes, because the line was busy. He made the reservation, go an ID and wrote it down on paper. Then he put the ID in his application and printed my tickets. I ask him why he just didn't used the computer - he answered: "Its a premium service - without a call it would be too easy".
Thinking about that from the software perspective - its genius:
- bahn.comfort service is location agnostic: the implementation of the service on the other side (another clerk), could sit whenever he want. I even suspect he was in the same room :-)
- The interface (=phone) is very generic. Everything is replacable - even the telephone-device.
- Built-in throughput throttling: there was only one shared phone used by three clerks (what I observed): the guy (a singleton) on the other side couldn't be overloaded.
- The whole process is highly available: the clerk who called the bahn.comfort service tried to reach someone several times until the eventual success. He also wrote down the ID on paper (this can be considered as TX log or persistent message). Now the clerk itself is replacable, another clerk could just complete the process having the Id
- The whole process is consistent: I stayed in touch with him and could react to any system-exceptions (like busy line). There is no need for rollbacks or compensative transactions, because he could ask me (the end-user) how to further proceed
- Cloud ready: partially it seemed like the clerk tried to reach someone in the clouds :-)
With this genius approach, most of the challenges, described in my How To Kill A SOA Project post are not only addressed, but entirely solved :-)
Now I'm in the ICE - with a ticket bought in highly service oriented way and enjoy the ride.