Modelling Process and Staleness

Fri, 09 Mar 2012 16:39:00 GMT

I went to some excellent talks last night at the LJC night at QCon. Gil Tene of Azul systems and Adrian Cockroft of Netflix both gave enlightening and useful talks. The talk "Modelling Process" by the creator of Clojure, Rich Hickey, was especially interesting to me as it touched on several important themes.

Rich talked (amongst other things) about how processes 'perceive' data values and never the actual value. He compared the way processor and memory caches work to the delay that a person gets when listening or watching a distant event due to sound and light waves taking time to travel.

I think this is a very important point. I would say that ALL data is stale as you only ever see a value at a point of time in the past. Now this may not matter at all for some data (the data may not actually be changing) or it can be incredibly important (real time prices for trading systems). How stale the data is before you process it will also vary greatly - from users sending in changes to their information via hand-written forms to electronic sensors with a direct connection.

Rich's point (and I hope I'm not misrepresenting him here) was that it's OK in most instances to send an immutable copy of required data to processes rather than insist that they always use the 'real' value in memory. This helps avoid locking and contention. In fact the consumers of the information may see a much more realistic value as they are not waiting behind 30 other consumers who are taking it in turns to lock, read and use.

Understanding your staleness requirements can lead to different architectural decisions.

His presentation is worth a read and I really liked his "Epochal Time Model".

Start with the big picture

Wed, 18 Nov 2009 08:05:57 GMT

One of the hardest things about the software architecture role is being asked to come up with a software architecture when all you're given is a set of requirements and a blank piece of paper. It's certainly one of the most fun parts of the role, but it can be a daunting prospect trying to figure out where to start and what to do. Many software teams dive straight into the code and this can initially be very productive but many teams soon start to venture down the slippery slope of constant refactoring while they try to find a design that works. Often, a little forethought is all that's needed to get the architecture definition process heading in the right direction. So where do you start?

Read the full essay...

Coding the Architecture - process tag

Modelling Process and Staleness

Start with the big picture