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".

Think like an architect

Fri, 13 Jul 2007 09:08:00 GMT

IBM recently updated their Software Architect Kit and one of the articles it links to is entitled Evolution of Developer Skills Is Essential for Job Survival, which states that developers need to raise their game if they are to survive in the constantly changing IT industry. That's fair enough, the industry is evolving and we all need to evolve with it. Personally, I'm not convinced that the industry will evolve exactly how the author thinks it will, where traditional coding will become a thing of the past, replaced by SOA and abstract modelling techniques (e.g. MDA). There are some very bold statements in the article, but the one that struck me the most is as follows.

Since architects model and do not write code, modelling tools teach you to work and think like an architect.

I think you know my thoughts on this, although I do agree with the part that talks about modelling. Somebody once told me that the key characteristic of a good architect is the ability to think in an abstract way. You can also think of it as the ability to not get caught up in the details all of the time. To some degree, modelling allows you to escape from the detail and see the bigger picture, irrespective of whether you choose a "model everything" or "model just enough" approach and irrespective of whether you use a tool or a whiteboard.

While you might not agree with the views being put forward in the article, it's worth a read because it presents something that will be new to a lot of people. At the end of the day though, architecture is about abstraction, not modelling.

Coding the Architecture - modelling tag

Modelling Process and Staleness

Think like an architect