I’m becoming increasingly frustrated with some day to day technology, and I’m not alone. When you live with technology day in, day out, what it does well becomes taken for granted. What it does badly becomes its defining features. If the annoyances are too great or numerous you will seek a replacement, or even give up entirely. This article explores my own tales of woe with that most commonplace of technology, the mobile phone…
Author Archives: Andrew
Annoyance-Based Technology Selection
Review: Crash and Burn
By The Decoders
Enjoyable, even if I'm not the target demographic!
I’ll admit up front that I’m probably not the target generation for The Decoders’ music – I know Jon via his mum, and my reference points for music of this style are probably a bit old-fashioned to some ears. That said, I’ve enjoyed "Cellophane Veil" enormously, and I wish the Decoders every success with it.
If I had to sum up the style in a single word, it would have to be "Mod". The band’s influences seem to be drawn largely from the great tradition of guitar-based London bands such as the early Who and the Jam, although some of the vocal harmonies put me most strongly in mind of Secret Affair (without the sax, of course!)
The music ranges from rock to ballad, but with a common sound courtesy of Blake Feehan’s crisp vocals, and, in many cases, a driving rhythm guitar. Most of the tracks work well, but my personal preference are the tighter, upbeat, "bouncy" numbers. If I had to pick a favourite it would be Plastic Lullaby, but the opening track, Crash and Burn, runs it a close second.
The musicianship of all three Decoders is excellent. Jon Flint’s drums are spot on, and I’ve already mentioned Blake’s tight, melodic vocals, but these two would be nowhere without Martin Lister, who apart from a guest appearances on a couple of tracks plays all the other instruments, including bass and lead guitars, as well as occasional keyboards and additional vocals. The drawback, if there is one, is that it is impossible for the band to recreate this multi-handed approach in live performance, unless they recruit some extra musicians. However, having seen them as a three-hander live I have to admit that they manage the difficult feat surprisingly well!
The inventive lyrics vary to fit the songs, from "angry young man" political commentary to balladic love song. I wouldn’t claim to understand them all, but I particularly enjoyed the humorous observation of how what a man wants in a woman changes over time, in Plastic Lullaby.
As I said, I wish The Decoders every success. Keep up the good work!
Enterprise Architecture Conference 2006 – My Paper
I’ve just spent three enjoyable days at the 2006 Enterprise Architecture Conference in London. IRM did their usual excellent job of making it run like clockwork, and my good friend Sally Bean helped them develop an interesting and varied programme. To my mind the best speakers were Jeff Scott, and Chris Wilson of BP. Another encouraging sign was the presence of a great many International delegates.
I presented a paper on Agile Architecture. If you regularly read my work you’ll recognise many of the ideas, but I’ve managed to bring them all together for the first time. You can download my slides and script here.
What was very interesting was how the thrust of the material has changed from a few years ago. No-one was claiming that a given framework, process or toolset can solve EA problems. At the risk of being uncharitable I thought John Zachman’s ideas sounded very tired, and there was almost no mention of alternative frameworks such as TOGAF. I may have self-selected by not attending any vendor sessions, but there was also no promotion of tools or technology. A common view was that EA, SOA and many supporting concepts are currently entering the trough of the hype cycle.
Instead the focus was largely on people-related problems and approaches. The labels varied, but several speakers introduced ideas familiar to agile architects. Maybe we’re doing something right after all.
You Need Architects…
Just in case you haven’t already seen it….
Why you need architects, in song and dance.
Enjoy!
Best Practices in Test Automation
I am looking for one of my clients into how costs can be reduced, or quality increased, by increasing the extent to which testing is automated.
As a first step, I am trying to develop a comprehensive list of test automation “best practices”, grouped roughly by life-cycle (or iteration) stage. I’m trying to find practices which are broadly independent of specific methods and technologies, although obviously tool support may vary depending on the chosen technology.
This article is my first draft of such a list.
I’d welcome suggestions from my readers if you think there are any omissions (or if you substantially disagree with anything I’ve included).
Thanks
Andrew
The Agile Architect at EAC 2006
If anyone is interested in hearing more about my views on architecture, and how agile methods apply to the work of the architect, please sign up for the 2006 Enterprise Architecture Conference in London in June.
I’m presenting a paper entitled “The Agile Architect”. This focuses on both how agile projects can have a strong architecture, and how architects can learn and benefit from agile approaches. I take a rather different approach to some recent papers with a similar title (e.g. at this week’s otherwise excellent Microsoft Architecture Insight conference), which suggest that agile projects can “do away with the architect”.
I look forwards to seeing you there.
Andrew
Who Are the Architects?
There’s a perennial discussion in architecture forums like the WWISA about the role of the architect, and the discussion regularly degenerates into a debate between the broad and narrow views of what the architect does.
But I’m not sure that’s the key question. I think the right question is “Who are the architects?”
Somehow, a number of tasks must be discharged, but how varies from project to project. In the last year I’ve had a modest building project which tells an interesting story about how different people contribute to “the architecture”. Read more here…
Happy New Year!
Apologies to regular readers who wondered if I’d fallen off the planet. It’s been a busy second half of 2005, and I haven’t managed to do much reading or writing for a few months. However, with the builders gone and a very difficult year over, hopefully things will get back to more nearly normal!
Sorry, there’s no Coppertrees Calendar for 2006 – another casualty of our very busy 2005. Hopefully it will make a return in 2007.I’m currently working on a new paper, looking at the different ways of modelling dependencies in software. I’m hoping it’s possible to merge some of the matrix-based techniques with pattern-based approaches – watch this space for more details.A very Happy New Year to all my readers. Here’s hoping that we’ll all have a slightly easier 2006.
An Agile Architecture War Story
I don’t really believe in a common architectural process. As the author of a successful project management book, and recent articles on data architecture methods, I probably shouldn’t say this, but to paraphrase a famous quote, “When I hear ‘process’, I reach for my gun!”
This is a story of a project I worked upon which followed an informal, agile process, but delivered a successful architecture. Hopefully it serves to support my assertion that agile can have an architecture, but needs an agile architect.
Modelling Data Mapping – A Challenge
Almost all integration projects contain one or more transformations (sometimes called “mappings”) between two different structures holding equivalent data (for example the order tables in the database, and the order XML message). We know how to model the individual static data structures in various ways, but the most common approach is to represent each by a UML class model, and there are established conventions for how to do this for different data sources.
However, UML doesn’t help when it comes to the transformations themselves, and typically the detail has to be captured either in code, or a proprietary format. Most good integration tools provide some sort of “visual mapping tool”, where the developer drags and drops to create links between representations of the two structures, usually imported directly from their physical schemas. Here’s an example using SeeBeyond. Altova provide a good stand-alone data mapping tool called Mapforce – here’s an example showing it in use. The problem is that these tools work directly with the physical structure, and don’t export the mapping information in a reusable format, so that information is completely disconnected from the UML analysis or design models.
I have experimented with trying to represent mapping information in a UML model, but so far without much success. The best solution I’ve found so far is to use some sort of “pseudo code” (it could be OCL, pseudo-Java, pseudo-VB or anything similar). For example, we could easily annotate the model with code fragments such as:
Database.order_table.order_no = Message.Header.OrderNo
(where each element refers to a UML Package.Class.Attribute combination).
The problems are that it’s not clear where to put this annotation, most UML modelling tools won’t help generate it, and there’s no graphical representation. Ultimately, writing pseudo-code like this is probably not much better than abandoning the model and moving straight to using your integration tool.
My question is: does anybody know a better way? Has anybody found a good way of representing mapping information in UML? And if so, is there any good tool support?
If you know, please send me a message.
Review – A Short History of Nearly Everything
I’ve just posted my review of Bill Bryson’s “A Short History of Nearly Everthing”. I found it an excellent holiday read, athough a general science book with almost no illustrations or equations took a bit of getting used to. For more, please read my full review.
Review: A Short History of Nearly Everything
By Bill Bryson
Science for the verbally-minded
This is a remarkable book in two ways. It’s a very clear, comprehensive summary and explanation of our current understanding across a wide range of scientific subjects. It’s also the only science book I’ve ever read with almost no illustrations or equations.
In his introduction Bryson complains that he could not get interested in science at school because all the text books were dull. Admittedly I’m a few years younger, which might make a difference, but I was exposed from an early age to a vast array of well-written and beautifully-illustrated books on a range of science subjects. The conclusion is simple: unlike most who get interested in science, Bill Bryson is one of those people whose thinking is almost entirely verbal in nature, and he’s written a book for those of the same persuasion. And he’s done a very good job of it.