Philippe Kruchten interview: Telecom-architecture connection & level of architecture abstraction

Apr 22, 2010 | George Fairbanks

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.

“There are many projects out there, probably 80-85% of the software
development projects — there is an architecture is in place on day
one, when you start the project all the big choices have been made,
language, platform, framework – you name it. The concerns about
architecture are probably only applicable to a small fraction of
software development projects out there.”

The architecture community has a bit of a problem in that we (or some
subset of “we”) claim too many issues as architectural. I agree with
Philippe’s comment, and probably with his 80-85% estimate, but note
how he’s implicitly categorizing many decisions that must be made
after “day one” as design decisions. The reason I point this out is
that I think many folks see the architecture community drawing
diagrams in UML that cover processes, classes, etc. and assume that we
all believe architecture always goes down this deep into the detailed
design/implementation.

What is closer to the truth is that there are a bunch of important
decisions that have architectural impact, but these decisions are not
always at the level of the most abstract boxes (components, nodes,
etc.). Those decisions can tentacle down into low-level details such
as protocols and memory allocation strategies. Consequently,
architects draw some detailed diagrams to work on the design of these
issues or to communicate them. But in general the architecture
decisions are not at the level of methods and classes.

About

George Fairbanks is a software developer, designer, and architect living in New York city

Contact

gf-web@georgefairbanks.com
124 W 60th St #37L
New York, NY 10023
+1-303-834-7760 (Recruiters: Please do not call)
Twitter: @GHFairbanks