Category Archives: Agile & Architecture

A little while back I was approached by EITA Global, a global provider of on-line training, and we have now agreed that I should present for them a webinar entitled "Agile Architects, and Agile Architecture". The current plan is for this run on 8th April. I’ll keep you all posted with any changes.

As part of my preparation, I decided to do a literature scan to see how this topic may have moved on since the last time I did some significant work on it, a couple of years ago. I have to say that based on my initial research I’m not that impressed… I don’t know whether to be flattered or slightly perturbed that AgileArchitect.org comes up squarely at the top of a Google search. There are a few decent web articles around, although most are several years old and I’d seen them before. The Google search also turns up several dead links.

Amazon turned up a couple of loosely-related books, and the most obvious candidate appeared to be "Lean Architecture: for Agile Software Development" by James O. Coplien and Gertrud Bj�rnvig. I’ve now read a couple of chapters, but my first impression is not very favourable. I may be rushing to judgement, in which case I’ll apologise later, but the book seems to somehow equate "architecture" with "code structure" with "project structure", which isn’t right at all, missing a number of the most important dimensions of any true architecture.

This led me to ask myself a very basic question. "What do I mean by ‘Agile Architecture’?". In Coplien and Bj�rnvig’s book they seem to answer "an architecture which facilitates agile development". That may be one definition, but it isn’t mine.

I think the confusion arises from the difference between "agile" applied to a process (e.g. software development), and applied to a product. In the former case, the Agile Manifesto undoubtedly applies. In the latter, I’m not so sure. I think that for a product, and especially its architecture, the primary meaning of "agile" must be "able to respond to change". The larger the change which can be handled quickly and cheaply, the more agile the architecture. An architecture which has been built in a beautifully run agile project but which needs new code the first time a business rule changes is fragile, not agile. The system which can absorb major changes in the business rules without a single line of code is genuinely agile. The integration architecture which allows multi-million pound system A to be upgraded with no impact on adjacent multi-million pound system B, or which allows the company to be restructured just by re-configuring its services, is the most agile of all.

I’m slightly worried that "agile" may have become a "reserved word", and this "architecture in the large" definition may run counter to accepted practice. Is that right, or am I reading too much into a few examples?

Or Have Microsoft Lost Their Mojo?

I like colour. I see in colour, dream in colour and have a rich colour vocabulary which drives much of my photographic style (see Seeing in Black and White). It’s also an important part of how I work – colour can be a powerful “dimension” in the visualisation of information. The human eye and brain are remarkably good at processing and using colour signals, whether it’s a highlighted line of text on screen, or a flashing blue light in traffic.

Now I acknowledge that this isn’t universal. As a designer you have to cater for a significant proportion of users (about 8% of males) who have poorer colour vision, and especially in mobile systems there will be times when ambient lighting conditions reduce effective colour saturation to a point where it doesn’t work. The traditional way to deal with this is to combine colour with another signal, such as shape – green tick vs red cross, for example. Then each user can use the signal which works best for them.

Microsoft used to get this. Their software was frequently a model of usability, and exploited colour, shape and shading to both guide the user, and allow the user to better manage their data. Icons could be rapidly located by colour as much as by detail. Data items of a particular status would “leap out” from a forest of those without the status marking. Office 2003 introduced follow-up flags for both OneNote and Outlook, which proved to be a great way to identify and retrieve key items in large lists. These supported both colour and shape or text as “identifying dimensions”.

Then sometime in the late noughties, Microsoft lost their way. Office 2010 has abandoned colour as a navigational tool. Tools, icons and the dividers between sections of the screen are all subtle shades or pale pastels, making them very difficult to visually distinguish, particularly in poor lighting conditions. Icons are no longer clearly distinguishable. However the worst regression is in respect of Outlook’s follow-up flags, which now actively disable the use of colour via a tyranically imposed colour scheme consisting of “multiple shades of puce”, rendering them completely useless for their original purpose.

This rant had been brewing for some time as I try to get to grips with Office 2010 and its inexplicable abandonment of many well-established user interface standards at the cost of enormous frustration for long-standing users. What tipped me over the edge was the announcement last week of Microsoft’s new Windows logo. Gone are the cheerful primary colours, and the careful shading which made later versions pop out of the screen with real depth. In their place is a plain white cross on a muddy blue background. Useless!

Now I suppose there might be people who think that this reduced colour palette is somehow “cool” or “elegant”. They’re probably the same group who think that it’s appropriate to model fashion on anorexic teenagers rather than real women. In both cases they’ve clearly lost track of who their real customers are, who has to get real utility from their work.

I’m not against change, and I accept that high-resolution graphics allows more subtle designs that we were previously used to. However, this rush to abandon colour in user interfaces and branding robs us of an important dimension. We absolutely do have to make sure that designs are also usable for users and in conditions where colour may not work, but we must not throw away or disable powerful tools which have real value to the majority of us. Microsoft should know better.

I don’t think the reason why the British travel infrastructure copes so badly with problems is actually down to a fundamental lack of capability or investment. The real problem is that the operators lack sufficient planning, and/or imagination, and/or flexibility to shift their services to alternative patterns better matched to changing circumstances. The only “plan B” seems to be “run what’s left of plan A and apologise”.

Take, for example, South West Trains, who run commuter services to the South West of London. There are two main lines out from Waterloo via Guildford and Woking, but also a number of parallel minor lines, like the secondary line to Guildford which runs past my house.

When North Surrey got a foot of snow for the first time in 30 years in February 2009, it was clear that no trains were going to run on any of these lines for a couple of days, but only a relatively short stretch of the lines was blocked. It was still possible, for example, to get from Surbiton (about 10 miles nearer to London than my home) to Waterloo.

I had to attend a course in London, and the roads were becoming passable, so I dug the car out and drove to Surbiton. It rapidly became clear that everyone else had had the same idea. How had SWT reacted? By running the same four commuter services an hour from Surbiton. These were, of course, enormously overcrowded and slow. What about the other trains which would, for example, have usually been running the express services carrying the rest of the traffic? These were nowhere to be seen, presumably sat in a siding near Waterloo. Would it have been beyond the wit of man to press some of these into use as additional shuttle services to carry the excess traffic from those stations which were accessible? Apparently so.

Last night, I got caught again. I got to Waterloo at 10:30 pm to see a blank indicator board. The cause of the trouble was signalling problems in turn due to cable theft at Woking. Now I don’t blame the rail companies for that, and I hope the perpetrators are found, hung, drawn and transported to South Georgia, but I do think the train companies’ response is inadequate.

True to form, they had reverted to “what’s left of plan A”, running a tiny number of overcrowded and delayed services under manual signalling procedures. Now theoretically my line should not have been affected. Not only should I have been able to get home, but my line is perfectly capable of carrying some additional “relief” traffic, as it does when there is planned engineering work on the main lines. (About once a month the 8 commuter services per hour are joined by about 20 express and freight services, and when planned that seems to work fine.) With a bit of ingenuity you could even alert taxi drivers at the intermediate stops to the sudden need for their services, at profitable late night rates.

Is that what happened? I should coco. Instead not even the regular services to my home station appeared to be running. I ended up on one of the overcrowded trains to Surbiton, and finished my day with a £40 cab ride.

Why is this so difficult for the train companies to get right? In both of these cases there was no fundamental problem with the remaining infrastructure or rolling stock. In both cases they even have a model for the alternative schedule. For last night it’s in a file marked “Saturday service with engineering work at Woking”. Staff flexibility might be the problem, but that must be resolvable, maybe via higher overtime rates?

There’s also an architectural lesson here. I design computer systems and networks. My clients run national power networks. In both cases the customers expect those systems and networks to be resilient, and to cope with growing demand without wholesale replacement. It’s not always possible to justify dedicated “DR” capacity, so you have to get inventive with alternative configurations of the capacity you do have, and then run tests and introduce clever asset monitoring and management practices to make sure those configurations can be used safely.

If we can do it, why can’t the transport operators?

– Posted using BlogPress from my iPad

Location:Cobham,United Kingdom

Halfway through, and this is shaping up to be the best EAC I have attended for a while.

I was umming and aahing about whether to attend yesterday’s seminar sessions, and couldn’t make up my mind which to join. In the end I made up my mind about the morning session while having a cup of coffee on the way, when I recognised one of the speakers, Lawrence Helm, as having given an excellent presentation a couple of years ago on NASA’s knowledge management problems. This time he and his colleague Robert Stauffer were talking about NASA’s adoption of Capability Modelling, and how they have put it to use supporting some very high level decisions about NASA’s future shape.

This was another stimulating session, and really benefitted from the extra space from making it a half-day session. Lawrence and Robert actually ran out of time, which was probably a testament to the depth of the material and the discussions it engendered.

The principle of relating capabilities to strategic objectives was not new to me, although the NASA examples certainly were. What did surprise me was the level of detail required for capability definitions in that environment. For example, the launch capabilities relate specifically to certain target longitudes and temperature ranges, and could not be moved to a location outside those ranges (for example Korou or Baikonur) without re-engineering the rocket platforms.

The afternoon session was also a bit random, as I got confused between Mike Rosen’s half-day seminar and his separate one hour talk for which I had the slides. Not a problem, the half day session on case study methods was very educational. The example, of how Wells Fargo created a federated model to integrate their various systems under a common customer model was interesting, and plays nicely into my EAI talk tomorrow. Like a good sermon, I didn’t learn much new, but I felt thoroughly validated that Wells Fargo did what I would have recommended, and succeeded with it. We had a very robust discussion on the importance of stable service interfaces, so hopefully that will drum up some support for my talk.

You get a very good class of attendee at these sessions. Alec Sharp joined the NASA session, and John Zachman joined the afternoon session, although he didn’t participate much.

Thursday’s highlights have probably been the two keynotes: this morning on how different companies have developed different strategies to come through and out of the recession, and this afternoon on “how to think like a CEO” and get your messages across to senior managers. However, there was also an excellent talk this morning by David Tollow on how EA feeds management and planning of long term outsourcing deals, from the supplier’s viewpoint. Very relevant to many of us in the current day and age.

Just to make things interesting, Sally has asked me to swap slots with someone else tomorrow, so my talk which was carefully trimmed to the constraints of the last slot on Friday will now be at 10 am. This may or may not be a good thing.

Wish me luck!

– Posted using BlogPress from my iPad

Location:Portman Towers,Paddington,United Kingdom