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... :(

Wednesday, March 16, 2011

Published the Context Normalization Standardization pattern candidate

Hi all,

I just posted the pattern candidate for (Process) context normalization standardization.

If you have done this before and agree this is a good approach to solve cross-company process and technology alignment, please testify on the web site using the candidate pattern feedback form.



Friday, February 18, 2011

Agnostic/non-agnostic revisited

I got the feedback that the previous article I wrote on what agnostic/non-agnostic is was too complex. So I am revisiting the subject to make sure that I explain a lot simpler than in the post I described last year.

To explain as easily as possible what agnostic/non-agnostic is:
  • agnostic services are not aware of the context in which they are being called, nor are they aware of how the service is implemented, which platform, technology etc.
  • non-agnostic services can have one or more forms of coupling or context (ie. process functional context).
Result of these two statements is that agnostic services have more reuse potential than non-agnostic services.

An example of the difference can be identified by discussing a "PrintInvoice" service capability.

This is a service capability which can be described as the logic exposed to print an invoice. When trying to classify the service it is pretty obvious that this is a non-agnostic service, as it has capabilities to print invoices and nothing else.

When applying the principles of service design, we should give a service a defined logical (functional) boundary, which defines the context in which the service operates.

When redesigning the implementation of this service, we could split the service into two services:
  • Print
  • Invoice

These are two agnostic services: print service capabilities are bothered with the capability to print "stuff" and Invoice service capabilities deal with invoice related "stuff".

Having made this separation, I just lost my capability to print invoices. To resolve this problem I can create a third service which combines the two services in one service capability which can deal with the mechanics of printing invoices, which results in the following service-inventory:

As you can see the agnostic services are being composed by the non-agnostic PrintInvoice service. This allows for the invoice and the print service to be used for other purposes, of which I have depicted a few potential examples below:

As we can see, it's the agnostic services which are being reused, not the non-agnostic services.

If this separation of concerns would not have been applied, instead of ie. reusing the print functionality, for the printletter functionality, the printing part would have been redeveloped and tailored for the printing of letters. This would have created some unnecessary/redundant/duplicate logic.

The current PrintService would take any range of different document types that it would support. This would greatly enhance the reusability of the agnostic print service.

Wednesday, February 2, 2011

Published Rule Layers candidate pattern

Hi all,

I just published the Rule Layers candidate pattern. I'm looking for people to testify that they have applied this pattern to get it promoted from the candidate to the pattern status. Check it out here at

- Roger

Monday, January 17, 2011

Published Rules Normalization candidate pattern

Hi all,

I just published the Rules Normalization candidate pattern. I'm looking for people to testify that they have applied this pattern to get it promoted from the candidate to the pattern status. Check it out here at

- Roger

Sunday, January 9, 2011

Make sure it's not too CLOUDy...

This post addresses some of the concerns that companies might have when dealing with cloud services in general, specifically when dealing with sensitive data in a hosted environment. Where cloud computing in intended to increase the quality of service, the quality of "privacy" is not a generally recognized factor when services are hosted. The environment naturally protects its applications because that's what the hosting environments provide.

With cloud computing, the deal changes with respect to traditional hosted services in ie. a colocated hosting environment for which you know where it is hosted. When services are hosted in a cloud, ie. the service's storage resource is hosted in redundant locations, you can not be sure with a (public) cloud where a service or its resources are hosted. In fact, some of the more innovative cloud service providers have dynamically hosted resources in 'cooler' locations on the planet to save cost by requiring less power for cooling. This means that the services are hosted across multiple continents and in many countries, which naturally leads to the conclusion: what happens with my customer data, what happens with my client data?

Businesses or governments storing data in a cloud may inherently be exposing the data into countries which have different privacy policies or legislation than required for their purpose. For example, if data of a European company is stored outside the European Union, which means that data of customers may not be protected by the privacy laws of Europe.

In the example, a cloud consumer should stick to cloud providers for which he knows the privacy policy, and for which the hosting environments are only located in Europe. Alternatively a cloud consumer should build a private cloud or use a community cloud which has controlled access.

Similar approaches apply for different reasons and for different countries, but the essence stays the same: make sure it's not too cloudy...