Centralized approach

Even if you are not a train lover like me you are probably aware that railway systems are regulated by signals. The most common (and old) is the fixed block system: the track is divided into a number of blocks and will only allow a train into a block if the next block is cleared. With this approach the intelligence is in the system (see the signal control board below):
Signal control board

The train only needs to stop if it is facing a red signal, proceed if it is facing a green signal:

fixed_block_system

Train waiting at a red Signal (Screenshot from openttd)

Local intelligence

The centralized approach has some advantages: it is simpler to monitor and troubleshoot, but it has one major drawback: it has a lot of overhead and doesn’t scale well. That’s why in the DLR in London they opted for a moving block system.

dlr

With this system each train has enough intelligence to continually calculate its own position and transmit it, along with speed, direction and other onboard status data, to the wayside systems. This allows the following:

  • trains can travel at a closer distance from one another, it is possible to have more frequent services;
  • the capacity of the line is increased;
  • the train manager is not necessary anymore, there is enough real time and accurate information in the system for the train to self regulate its journey

There is much more to it, but you get the gist of the concept: this approach allows for much more capacity and performance with lower cost of infrastructure. When I think of a transport system that has embraced agility DLR always comes to my mind.

The migration to distributed systems

There are many examples of complex network of services that are migrating from a centralized approach to a distributed ones, energy suppliers just to name one. Distributed systems scale better, are more resilient and cope better with the needs of today’s complex service networks.

Agility and self organizing teams

This is why in the 12 Principles of the Agile Manifesto we can read:

The best architectures, requirements, and designs emerge from self-organizing teams.

Self Organizing team

Picture of a team of people hugging indoors

The leadership is also decentralized and turned into a more fluid one, leveraging the concept of the servant leader. This is because in the development team the developers and hands on people have the more updated and reliable information about the system. Of course they need to be sharing their “onboard data” with the other team members and the system in general, that’s why in the Agile community we value transparency and visualization of data so much.

This is the approach that allows teams to be flexible, adapt promptly to external factors and avoid bottlenecks and delays. Self organizing teams also allow scaling without making the hierarchy of the organization too complex (the controller, the controller of the controller and so on).

Wrapping up

Metaphors always have limitations, but they can be useful to remember an abstract concept and link it to something familiar, in this case with something I love, trains :-). I hope you found this analogy useful, I’d love to hear your opinion in the comments.