The Wave is growing
I’ve highlighted Google Wave before, but now it has been launched to a large number of beta users, more and more people are exploring just what it can do. Here is a wonderful demonstration of Google Wave for Tarantino fans (not for the faint hearted!):
Goodbye Visio?
A warm welcome to Creately, an online competitor to Visio. It looks nice, with good collaboration features and an underlying data model that has me thinking about its potential as a real modelling tool. Of course, I’d also like to see an Archimate template here too. Watch the video to get an idea of what it can do.
Service Architecture Review Method – a prezi
I’ve enthused about Prezi before, and with an upcoming conference presentation on service architecture reviews, what better opportunity to try it out for real.
My experience? Prezi seems easy to use, once you get used to the different menu / control navigation. But you realise quickly that with a virtual, infinite, blank sheet of paper, and no Powerpoint template behind which you can hide, you have to really think about the concepts you want to convey, and how they relate to each other.
The result is that you come out with a better understanding of your subject than you started with. Whether it also produces a good presentation remains an open question. For my first serious attempt, you can take a look below (you’ll have to guess the words I will use to accompany it).
IESS Geneva on Prezi
Are you a tweetotaller?
At last someone has expressed just what I feel about Twitter. Thank you Devin Coldewey.
(this post is less than 140 characters!)
Architecture Reviews, Requirements and Quality Attributes
The ONS architecture review method has been in use for a couple of years, and while it hasn’t worked flawlessly, it does seem to they way we think at ONS better than ATAM. I presented a paper that describes the method, and the differences from ATAM at the UNECE MSIS conference in Oslo in May this year (you can see both the paper and the presentation here).
I’ve been looking more closely at models of quality attributes, and suspect that the ONS method could come a bit closer to ATAM that we originally thought. ISO/IEC 9126-1 contains a very nice model of quality attributes (pretty good summary here), which it more correctly calls characteristics. It is hierarchical, with just six main characteristics (functionality, reliability, usability, efficiency, maintainability and portability), which are further subdivided into a total of 27 sub-characteristics.
The ONS method makes the connection between quality attributes and requirements via Matrix 1, but the connection is too weak. Recent architecture reviews have proved somewhat unsatisfactory, and I suspect that the root cause is incomplete and poorly specified requirements. By the time you get to the review, no method is going to rescue that situation unless you avoid all references to the requirements and do the risk / trade-off analysis directly against the quality attributes – but then there is the danger that the evaluation criteria are effectively based on a different set of requirements than those created through business analysis, and on which the solution options were based.
So, how to improve the quality of the requirements? I suggest that the quality attributes need to have a much stronger influence on the requirements – influencing the people describing the requirements, and the analysts looking for them (if no-one mentions maintainability during business analyst interviews, it is hardly surprising if it is not among the requirements).
Perhaps this is just the traditional complaint of the architect – “don’t ignore the NFRs” – but I think we should look for a much tighter linkage between requirements and ISO 9126-1, and perhaps develop the stakeholder model around the quality attribute model so that it is quite clear that those who have to run, manage and maintain the system, and those determining corporate strategy, are just as likely to have requirements of the system, as those who are going to use it.
Maybe then, when we reach the architecture review, we will have a set of requirements that is better aligned to the key quality attributes, and the review can be better focused on risks and trade-offs.