Summary
Using an event graph can help us understand relative connectivity in a decentralized network of event-based applications.
Reading this piece on DebtRank (see also the original study) got me thinking about how we understand decentralized systems.
Humans aren't good are understanding decentralized systems even though many of our most effective and scalable institutions (e.g. cities, the Internet, etc.) are decentralized. We tend to build centralized, hierarchical solutions for most things because we understand them better.
Google's pagerank is a remarkable tool for understanding relative connectedness and relevance of nodes on the Web. Similarly, DebtRank is a measure of the relative importance banks to the overall operation of the decentralized financial system.
Part of my interest is born out of my work for the past five years building event-based systems. Event-based systems are more decentralized than corresponding request-response systems and consequently can be more difficult to understand and analyze. In Chapter 12 of The Live Web, I build a blogging system from four different rulesets that cooperate in a loosely coupled manner. For example, we add the ability to automatically tweet the latest blog post by simply installing a new ruleset with changing any of the others.
The event graph for the blogging app is shown below (click to enlarge). In the event graph rules are rectangles and events are ovals.
Like pagerank or DebtRank, we can get a metric about the rules and events by measuring inbound and outbound arrows. For example, the show_home rule sees three events (blog_ready, web:hash_change, and web:click) and raises two (container_ready and need_blog_data). The blog_ready event is raised by two rules (show_new_article and init_html) and listened for by only one (show_home). In contrast, the send_tweet rule listens for a single event and raises none.
In a personal cloud, events can be seen outside of the rulesets that make up a particular application (like the blogging application shown above). There's no reason, as an example, that other rules making up other applications or services can't listen for a new_article_available event. The handle_submit rule doesn't have to be changed to accommodate listeners of the events it raises. They are simply put on the event bus of the personal cloud.
Seeing the event graph and thinking of it in terms of connectivity like pagerank does shows us rules and events that are particularly important to the operation of a particular personal cloud. The show_home rule is more critical to the operation of the blogging system than the send_tweet rule.