SOA Is Not Dead - Deutsche Bahn (DB) Is Highly Decoupled, HA, Service Oriented and Implementation Agnostic

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:
  1. 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 :-)
  2. The interface (=phone) is very generic. Everything is replacable - even the telephone-device.
  3. 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.
  4. 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
  5. 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
  6. 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.


Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition

airhacks.fm the podcast:

Stay in touch: airhacks.news.

Comments:

You missed one point. The two clerks where even able to negotiate the details of the protocol. A really advanced SOA implementation. We don't expect anything less from the DB

Posted by Jens Schauder on April 16, 2010 at 01:41 PM CEST #

We can also note a most impressive implementation of the service abstraction and autonomy principles: not only hide the services their logic from the outside world - they also have control over the logic they encapsulate (as the answer of the clerk clearly reveals).

Posted by Matthias Paul Scholz on April 16, 2010 at 03:07 PM CEST #

Please note the flexible aspect orientation of the design: the clerk can leverage each and every waiting period to inject arbitrary marketing pitches for Fan BahnCards, rental cars or DB iPhone apps. :)

Posted by 188.101.212.39 on April 16, 2010 at 03:36 PM CEST #

Great analogy! I really like it!
Recently I started posting interestnig analogies I found on the web on blog.ygolana.com. I thought it could be a good idea to create a place where people can share useful analogies such as yours.

Posted by Peter on May 24, 2010 at 03:16 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
realworldpatterns.com
...the last 150 posts
...the last 10 comments
License