Friday, March 19, 2010

Services in real life: Traffic Management Service: How Granularity affects service behaviour and efficiency

SOA Service concepts can be found in real life too. Some time ago, outside my office, road workers were replacing and reprogramming the traffic lights at a roundabout. When I saw the result of what they were doing I realized that the traffic light services and corresponding traffic management system can illustrate how a (SOA) service approach affects many of the service orientation design principles.

My office in Maastricht, Netherlands

For years I have watched the traffic light sequence outside my office. When walking across the street I did not need to press the button for pedestrians because I knew the sequence of the traffic lights by heart. I also remember that at any given time, only one lane of cars would be allowed and one group of pedestrians would be allowed to cross. Also, all traffic must stop before a new configuration was activated. This had resulted in small traffic jams all centered around this roundabout during busy hours and at times of sudden bursts of traffic.

Take a look at this street plan:
The roundabout

The actual situation is a bit more complex with bus and cab lanes, bicycle roads etc. but for illustrating this schematic should suffice. It's a Dutch roundabout so the traffic moves counterclockwise as indicated. (The dark surface in the top right corner is part of my office :))

  • A ... E are the car traffic lights. 
  • R ... X are pedestrian crossing traffic lights 

The old situation as mentioned, would be that at any given time, only one lane can drive the roundabout. ie. lights ABF is green, or CFE etc. Also, the pedestrian lights would only be green at one street at a time, ie. RS, TU, or VWX. Sometimes, all traffic has to stop in order to allow pedestrians to cross. This describes a very inflexible way of managing traffic. The reason for allowing all traffic to pass from a certain point of view, was optimisation: if a traffic stream is moving, make sure all of it moves. Because no real-time feedback was given to the system, the system would be in a certain configuration for a long period of time. This same configuration would be applied over and over again, endlessly without any change due to traffic load or time of day. Because the system is not interlinked with the rest of the infrastructure in the neighborhood, it was an optimized system from the local perspective, but not at all optimized to operate in the bigger picture. This is a typical example of a situation where optimization on micro level is counter-productive on macro level.

Assuming the TMS would be an SOA Service, the following observations can be made:
  • Autonomy of a certain traffic light was poor as it would only be allowed to operate in specific sequences of configurations 
  • A "Stop all" configuration was necessary between all configuration changes. This restricted the maximum switching frequency 
  • Granularity of the service composition (TLS) was poor as complete road paths would be switched at any given time, not individual lanes or lights. 
Overall throughput would be low because of the dead time in the 'stop all' configuration and the time when a specific configuration was active with no or a low volume of cars present. After replacing the lights, a number of important improvements were made:
  1. the system would allow partial pedestrian crossings (ie. only T or U instead of 'all or nothing') 
  2. the system would allow for individual control of two lanes at the same insertion point (ie. one lane for straight ahead and one for right turn) 
  3. the system would measure traffic load to accommodate for bursts in traffic coming from a certain direction 
  4. the system would be linked into the network of traffic lights in the surrounding infrastructure a 'green wave' to allow for traffic to leave the part of town fairly unhindered by the network of traffic lights. 
Because the granularity is increased (smaller parts which are individually configurable) the system allows for greater controllability:
  • optimized configurations are possible to allow for the throughput of traffic stressed lanes 
  • empty lanes do not unnecessarily get 'green' time 
  • special configuration sequences are allowed for busy hour traffic flow improvement 
  • pedestrians can be allowed to cross half of the lane without impacting the flow of traffic in that lane; shortly after the pedestrians are allowed to cross half-way, the remaining part is given a green light. 
  • timing the macro-level optimized configurations with the rest of the surrounding infrastructures' traffic lights. 
When making the analogy to service orientation, we see that the same concepts apply:

The overall road infrastructure can be considered a service inventory: all relevant infrastructure elements are managed in the same (domain) service inventory. We are assuming a domain service inventory here as all service configurations are probably limited to a certain geographic area in town. Potentially other service inventories exist with different rules, principles and configurations to manage different kinds of traffic.

Traffic Orchestration and Traffic Management services

The traffic management service (TMS) consists of a collection of coordinated traffic light services (TLS) each representing an individual traffic light. The traffic lights themselves are the smallest configurable service available (they can be configured red, amber or green). This is the defined service granularity (*) for this roundabout.

Because the granularity is better, more complex, optimized service compositions can be created.

The inter-intersection "infrastructure level" synchronization would probably be implemented as a service orchestration (**), the intersection or roundabout level light configurations as service compositions, managed by another service composition controlling when a certain configuration is necessary, based upon the input it receives from sensors in the road.

(*) A note on service granularity: there is no 'rulebook' on service granularity. The 'appropriate' level of service granularity depends on many factors. Any smaller configurable service components, like on LED level - ie. a green, red or amber light consists of approx. 350 LEDs - would probably result in management chaos, as each LED must be individually controlled to comprise a certain configured color of traffic light. Any larger service components than traffic-light level granularity would probably result in the same situation which we had in the 'old traffic light' setup where ie. all traffic must stop to allow pedestrians to cross the roundabout at configuration TU, a case of poor service autonomy.

Conclusion: Because all traffic lights can be controlled individually the autonomy and composability of the services are higher when compared to the old setup.

(**) Note: The example mentions orchestration, although the term choreography would probably be better suitable here. The orchestrated individual parts (TMS) have a certain amount of autonomy not controllable from the orchestration level. 'Despite' the orchestration level, the TMS can allow other traffic to cross the roundabouts or intersections as well, to service other consumers to using the service, even during busy times.

In the light of this post, I would like to encourage everyone to see how service orientation and real-world examples are really not that far apart. Whether it be a traffic light service or a service based economy, numerous similarities can be found. No, I'm not implying this applies at all times, but.... try :)
TOS-->TMS: Orchestrate intersections note right of TOS: Traffic Orchestration Service:\nControls all intersections\nin a part of town note right of TMS: Traffic Management Service:\ncontrols at the intersection level TMS-->TLS: Control Service Compositions TLS-->TLS: Red(), Amber() or Green() note right of TLS: Traffic Light Services:\ncontrols at individual\ntraffic light level opt note right of TMS: one for every extra\ntraffic light in a composition TMS-->TLS: Control Service Compositions TLS-->TLS: Red(), Amber() or Green() end

Working on a few new posts

Just a small status update. As I have returned home from my travels I'm working on a few new posts and also a series of posts on defining/creating of a SOA Reference Architecture. Shortly you should see a post about service granularity and service orchestration/composition, as well as my thoughts on the SOA Manifesto as I had promised in one of my earlier posts.

Thursday, March 18, 2010


Well this is it! Finally all my bags are packed. Clothes for tomorrow are ready and I packed an extra bottle of water to go... Boy this has really been a travel of contrasts. It is trips like these which really make one appreciate what he's got back home, in more ways than just one!

Also I learned a great deal of respect for these people who sometimes are months away from their family for a "short trip". Let me tell you it's heartbreaking when your son does not want to speak to you on the phone because he feels this is not the real thing, not good enough. "No I don't want to speak to papa on the phone - papa just has to come home!"...

Regarding work, this was a very successful trip. We cleared a lot of issues and identified opportunities for improvements. Our to-do list for the High-Level SOA Architecture are longer than ever! Also we have learned that it is good to meet the teams face-to-face. This way, the customer has a face and can explain why we do the things we do. Finally we got a chance to make the team really feel appreciated.

Tomorrow I am returning home via Dubai and Düsseldorf. I am soooo longing for a 'normal' dutch home-made sandwich :). Don't get me wrong - I really loved whatever it is I ate (cannot remember the names) - the food was really great. But sometimes it just the good old Home-Sweet-Home.

Friday, March 12, 2010

Chennai - the team

Salaam namaste,

It's Friday and almost the last working day in India and today we met with the team again. We took a picture of as many as would fit in the small room we've been working in most of the time.

Part of our team in Chennai

This week we again had very productive sessions on projects, programs, SOA reference architecture (main focus of this visit), productivity, (continuous) improvement and lots of other topics. These are long days and very exhausting, however they are also very rewarding. We got a chance to finally thank the team and discuss face to face what's on their minds. 
Team, just one message to you all: Shukria!

Wednesday, March 10, 2010

Arriving in Chennai

Just arrived in Chennai and already had my first conference call - I guess work at home continues while we travel :)
Boy is this area hot - it was 35 in Bengaluru but the air was quite dry so the heat was bearable. Here in Chennai, it's 'only' 32 but as it's located at the Indian Ocean the air is very humid. When I got out of the airport I was wet all over my body in an instant!
I like the cabs! These I would usually see in movies only. Lacking airco, seat-belts or any kind of comfort they really have a certain charm.

Tuesday, March 9, 2010

Leaving for Chennai

Our engagement in the Bengaluru area is coming to an end. Thanks to Babu, Raj, Arun and Madhu for hosting us. These were great sessions and we had good progress. Tomorrow I'm travelling on to Chennai where I will be continuing the visit to the Indian offshore offices.

Sunday, March 7, 2010

Follow the process and thinking outside the current constraints

Today I am the second day in India. The hotel is really great!

While here, I have encountered a few great examples of how people can become stuck in processes and how continuous process improvement as well as better exception/compensation handling could have helped.

A lady arrives early from the airport and the staff had just begun clearing up the breakfast buffet. Everything was still there so there should not have been a problem. Unfortunately, because the staff to clean this up had already entered the breakfast room they apparently could not stop the process and the lady could not get anything to eat ; so much for hospitality in the hospitality business...
- later I have asked the staff about the how and why and the explanation was fairly simple: "this is how we have agreed to work sir. We first warn everyone in the room that we are about to close the buffet, and when everyone has indicated they are all fine with this we can start the cleanup procedure". Apparently the procedure does not cope with people who arrive to the room when they have finished asking around....

Anyway to cut a long story short, I found out that the improvement process is typically: when a customer complains and the number of complaints in a certain period becomes too high, the process can be changed to compensate for the increased number of incidents. Despite all good intentions, I believe there is just not enough room for common sense or for improvement suggestions triggered by the people who are in the process themselves.

Extending this, an analogy can be found in (IT) processes. Very often I encounter that "we all" work according to procedures and we can hardly accommodate for anything that is not covered in these procedures. Also in IT, common sense often simply not used as we have proven time after time that we cannot accommodate for this in our procedures. Apparently, thinking outside the current constraints is still hard to do. We do everything by the book and still the customer is not happy :(


Today it's Sunday and I'm working in the hotel room but I'd like to share a few photos I took yesterday on my first day in India.

Ganesha, remover of obstacles, aka Godess of Luck

Lord Shiva, aka the destroyer of evil
and follower of Ganesha

Unfortunately only a few hours are available for sightseeing to not many pictures.

Saturday, March 6, 2010


This morning at 9am local time I arrived safely in Bangalore, India. Funny to see yourself being filmed with an IR camera. My temperature was OK :). I cannot sleep in planes but I saw a couple of nice movies "Twilight" and "New Moon Saga" both were ok but had very sudden endings; the plot was not really properly ended and they were bad cliffhangers. By the time I arrived at the hotel around 10.30am, I had gotten over my tiredness and could start with a normal day with breakfast. At the time of writing this it's about 8pm in the evening and I guess it's more than time for another shower and get something to eat; I'm starving... Keep you posted...

Thursday, March 4, 2010

End of my Egypt Visit

So unfortunately my visit to Egypt has come to an end.

Roger @ Sphinx

I met nice and friendly people and we had a very productive week. It was way too short for the agenda and also for meeting these fine collegues. Now I will get a good night of sleep. Fortunately, some time was available to visit the pyramids and other fun stuff late after work. Oh and Egypt has nice food: Fool, Kosheri and Molockheya are great to eat. Tomorrow you should find me in the Egyptian Museum in Cairo and in the evening I will leave for Dubai and Bangalore. Shokran likum for taking care of me this week and hi to Ahmed, Ahmed, Hani, Heba, Islam, Wael and of course Hoda, Nadine and Mona!

- Tesba7 3ala 7'eer!

View from Al Azhar park on old Islamic Cairo - city of 1000 mosques