Coding the Architecture - The Pragmatic Java Architect sessions in London

Re: The Pragmatic Java Architect sessions in London

Stephen Tjasink — Fri, 27 Apr 2007 15:41:24 GMT

I started writing a comment and it turned into an essay, so I blogged it here

I started off just summarising the main points that I felt came out of the sessions themselves, which I think boil down to:

Having somebody who plays the role of the architect is important to successful project delivery
A good architect is usually someone who has already been a relatively senior developer.
An architect should still get time to do development.
Successful implementation of an architecture can depend on whether or not the architect is part of the team on an ongoing basis.

There are of course many reasons for and results of these, which is what caused me to expand them so much.

Does anyone who was at one or more of the sessions agree / disagree with these? It might just have been my group that thought these and the other group thought something else.

As I said in my blog entry, I have in retrospect found it quite interesting that most of the discussion was about points such as those rather than specifically about Java architectures.

Re: The Pragmatic Java Architect sessions in London

Kola — Tue, 03 Apr 2007 00:09:45 GMT

I think you absolutely do need someone/some team/some organisation playing the role of architect on a system. I've blogged my thoughts on this here:

As to why do people become architects - I'm guessing there are a number of less cynical reasons - perhaps for the challenge, perhaps simply because a position becomes available. For me it was the frustration of working on systems which had a feeling of being a mixed bag of different ideas and techniques to solve the same problem.

I haven't come across any architects that don't code - I certainly would expect architects to still be involved to some degree in coding whether it's simply prototyping or working on core parts of the system which utilise new technologies/apis and need to be integrated/tested to mitigate any risks.

Re: The Pragmatic Java Architect sessions in London

Kevin Seal — Sun, 01 Apr 2007 12:02:18 GMT

It's interesting that you refer to needing "the role of an architect". I would say that you'll always have architecture. What's important is whether it's the right architecture; that suggests the role of an architect. There is no implication that this need be an individual, a former team lead or outside the team - that is often imposed by corporate structure.

There are efficiencies with having the architect as the implementor but you also run the risk of the architecture becoming "inbred" and unimaginative. You continue to play to your strengths, or worse, your mistakes that noone picked up on. Your example of the implementor picking up on duplication seems unlikely - I can see this sort of situation having been farmed out to three separate development teams. Only someone outside the development teams would have picked it up! If you've got a bad architect then of course this might happen - but you might just as easily have a bad developer! In any case, I would advise against unilateral action by removing duplication without consultation - it might be in there for good reason.

Developers involved in sales? Sure - the sales effort often requires proof of concept and prototype work to be undertaken. Developers as salespeople? Not so sure - it's a different skillset altogether. That doesn't mean that there aren't developers with those skills but I notice you didn't suggest that salespeople become developers during the good times - is the relationship between their skills really asymmetrical? ;)

Finally, do people choose to become architects because they can't (or don't want to) code? In truth, I suspect some do. Beware the "Architects Don't Code" anti-pattern! I can't imagine how an architect will produce (or review) a production-quality spike architecture if they don't code well!