Simon is a hands-on software architect and a senior consultant at 
The great rate debate
You can't delegate all of your architecture responsibilities
Here's an interesting one for those of you working for a consulting/product/professional services organisation. How many times have you heard the following?
The customer won't pay your architect rate just for you to sit and code all day.
Personally, I've heard this quite a bit. First of all, yes, there's a fair amount of truth and reality here; why should a customer pay architect rates for somebody to sit and code all day? Unless the architect in question has very l33t coding skills, the customer probably shouldn't.
When you hire a software architect, although you're getting somebody that might be a good developer (if they believe in coding the architecture), you're really buying into somebody that can define and deliver an architecture for you. I'm definitely behind the stance that you don't have to give up coding as an architect, but you mustn't forget about your primarily responsibilities either.
If you find yourself spending 100% of your time coding, you've probably forgotten about the other stuff (e.g. architectural conformance, non-functional requirements assurance, quality assurance, etc) and your customer isn't getting what they paid for. You can certainly get your hands dirty as a software architect, but you can't delegate *all* of your architecture responsibilities. If you find yourself in this position, take a step back and look at the bigger picture once in a while.
Re: The great rate debate
Very true!
Beware the converse, however: clients that won't permit you to code and only want you to do "high-value work". Mucking in with development can be an extremely effective way of derisking, defining, enforcing and reviewing the architecture and many architects are extremely adept at it. The "value" of this type of work might be considered very high in the right environment!
Re: The great rate debate
Re: The great rate debate
Strangely enough, I was in a meeting at work today where this discussion came up.
My view (and that of the users and posters on this site in general) is that development is definitely part of keeping in touch with what the team is up to (and therefore how your architecture is being implemented) and therefore invaluable to an architect.
However, you might still end up being assigned tasks as a rank-and-file developer if you are pushed for time, you are on a very small project, or if your managers don't "get it" and don't give you enough time to do the architeture job properly.
In the latter case, you are just doing development that could be done by someone else. And in this case, maybe your rate should be lowered accordingly. The response to this was "well then won't the client complain that they want you at that rate too when you are doing architecture?". My half-facetious, half-serious reply was that the client should be glad that they are getting your 1337 skills at a discount for part of the time.
Certainly an interesting topic, and one that different organisations will address differently, possibly even varying from client to client.
