ArchSpot

Philippe Kruchten’s keynote talk from the SATURN conference has been posted at the SEI. His slides are worth taking a look at: moderate in the agile-architecture debate but full of real ideas, not just best hopes of compromise.

The slides include his 4-color backlog idea, where user-visible features, bugs, technical debt, and hidden architectural features are all on the backlog. I like this idea a lot because it helps reveal dependencies, as in “we cannot build that user story until this architectural feature is in place (or this technical debt is removed)”.

Olaf Zimmerman has contributed a helpful new definition of a Service Oriented Architecture (SOA) in his PhD thesis. (Warning: the first pages of the thesis are in German, then it switches to English). He defines SOA, from an architectural design perspective, as the use of four patterns:

• Service consumer-provider contract
• Enterprise service bus
• Service composition
• Service registry

This definition is interesting because it is testable wrt existing applications and because it is defined in terms of lower-level patterns.

In a presentation at QCon London, Alex Buckley discusses the optimizations in the Java Virtual Machine that allow it to run code fast, how it is unsuited to non-Java languages, and the proposed invokedynamic instruction that will help. It is an interesting tour of how VM’s work.

InfoQ video and slides. The video is about 60 minutes long. And no, he does not commit to when these features might be released in Java SE.

InfoQ has posted an interview with Philippe Kruchten from SDC. In it, he talks about agile, architecture, and process among other topics. Here are some bits I found interesting with some commentary.

“I [Philippe Kruchten] worked for IBM, actually a very brief time, I then did a bit of research at the French Institute of Telecommunication, learnt more software there and also I went to Alcatel, where I learnt a lot because it was the beginning of using computers and especially large networks of microcomputers to punctual telephone switchers and all kind of things in telecommunication.”

I was part of the OOPSLA workshop on agile and architecture hosted by Dennis Mancl. One interesting observation was how many of the participants had a telecommunications background (I am guilty). We speculated that perhaps this was due to the rigid requirements imposed by regulators, for example, dialtone must commence within 40ms or 99.996% uptime. Things like that are difficult to design and build, which marinates software engineers in a certain approach to problem solving. An approach that is different from “How can I get this Drupal-based website up and running?” where you are pretty sure it will work and you have read reports of others using it to support X web hits per second.