Wednesday, April 20, 2011

Coupling processes loose - a mess if not done right

Another great example how processes can sometimes be coupled in such a way that you can create a mess for the people in the process (tight coupling):

As posted in my previous post, I am using a chip-card for the Dutch Public Transport. This card acts as a travel pass and allows loading products onto it which act as tickets for public transport. More information can be found here.

One of the ways for travelling with the card is by loading credit products onto the card which act as a virtual wallet. You can do this manually, or you can load a product onto it which behaves in such a way that if your credit on the card drops below a certain threshold, it automatically does a debit transaction on your bank account and recharges the travel card. For this to work you need to purchase the product online and link it to the bank account of your choice.

I had almost activated the product on my card until I noticed the following phrase in the description of the product: "Always make sure sufficient money is in your bank account. If we cannot obtain the money from your account the card will be blocked. Unblocking the card can be done at a service desk."

Now here's the problem: two processes exist which are mixed incorrectly here:
- travel authorization
- debit transactions

Specifically the scenario when travelling with insufficient credit on the card and a low bank account balance causes issues: why would anyone want to block the entire travel card if I had insufficient balance?

There are a number of reasons why this is wrong and additionally there is one specific reason why this is fundamentally wrong:

- Travelling is registered/credit is consumed by checking in and out of the travel registration system by keeping the card close to a registration point (the card uses near-field-communication to communicate with the travel management system
- Insufficient credit for this travel does not mean that there is insufficient credit for all travel. It should be sufficient to deny check-in for this travel only.
- Insufficient bank balance still allows me to recharge the card from another bank account - so why block the entire card?

Fundamentally wrong:
- Many train stations and most bus stations do not have a service desk. To get to one I would need to travel!? Blocking the card does effectively restrict me from getting to a service desk.

What is documented here is an unnecessarily tight coupling between two distinctly different processes with distinctly different purposes. A better solution would have been to check at every check-in time anew whether or not I had to recharge the card. If the bank account balance was insufficient I would be denied that particular check-in.

Needless to say I did not activate that auto-recharge-card-credit-product on my card. You never know what happens and I do not intend to get stuck in the middle of nowhere just because an architect made a mistake (imho) by tightly coupling two disparate processes and by doing so shuts me down completely (travel-wise).

Wonder how long this situation will exist now that the government and the transportation companies are trying to get rid of the paper travel tickets...

- Roger

Friday, April 1, 2011

Transportation service compared to SOA service (over)specialization

Sometimes service over-specialization can truly hinder reuse in a sense that multiple implementations of similar logic are necessary to achieve the same functional goal for another purpose (agnostic).

I live in the Netherlands where recently an electronic public transportation ticket system was introduced to manage travel tickets electronically. A chip card with NFC is used to 'carry' digital tickets while travelling. You could see the travel pass as a digital purse in which you can keep single/return trips, monthly and yearly subscriptions as well as some money to use while travelling.

Now I'm new to this system and finally I decided to try the 'ticket recharged' way of travelling: the public transportation chip card instead of a paper ticket.

In order to be able to travel, I need to meet a number of preconditions:
1. I need a (personalized) travel card - this is the actual chip card with NFC communications
2. I need to put money on it
3. I need to activate "travel" on it with the appropriate transportation company.

Ad 1): I already had the card a little while, so I did not need to worry about it: precondition 1 is met.
Ad 2): For charging the card with money intended for travelling, a two-step approach must be followed:
a. Purchase travel credit - this would perform a direct debit on my bank account
b. Load the credit product onto the card

Ad 3): Similar two-step approach:
a. Order the "travel by virtual travel money" product with the dutch railway company
b. Load the product onto the card that allows using the credit on the card if available

Step 2a can be done via the public transportation chip card web site
Step 3a can be done via the dutch railways web site

So now I needed to find an NFC charging point so I found one of the terminals for public transportation at the train station.

Now here's the problem:
The machine to load products onto the card would only allow me to find the pending product for step 3a. This  means I can load the product to spend the virtual money with, but I cannot find the product that represents the virtual money I had ordered to spend in the first place.........?

So the "Load product" service on the terminal was only able to load travel products but no credit products. What was wrong with building a load "product"???

I ended up finding another machine outside the railway station to load the money product onto the chip card...

So I had to load products in two physically separate (and distant!) places...

Typical example of a non-agnostic service... :(