Philippe Kruchten interview: Telecom-architecture connection & level of architecture abstraction
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.
