Mike raises some excellent points so perhaps I'll continue the theme of when you can't call yourself an architect...

Since my post about first experiences of being an architect, as opposed to a lead developer, I've tended to think of the difference in terms of code (the clue's in the job titles!). Therefore I'd probably say you can't call yourself an architect until you've done a project without writing a line of code*! I found it fascinating to see how my thinking changed when I couldn't defer the research or design to the construction phase of the project. If you can't code your way out of trouble anymore you try to spot it in advance.

There's also a duty to the technology as well as the team. Perhaps you can't be an architect until you've selected a technology you know nothing about and lumbered somebody else with developing using it (but stayed on the project)! This means doing your research and supporting the development team despite being no more familiar with it than they are.

I guess this all boils down to more or less the same points that Simon mentions... experience and confidence. Experience lets you trust your instincts when in unfamiliar territory. If you're to make a detour through an unfamiliar technology then confidence is also required.

Perhaps I'd use a stronger word - something like "audacity". As Mike says, when the buck stops with you and the best technology choice isn't your forte it takes a degree of audacity to go ahead anyway. This isn't synonymous with being cavalier - your experience and hard work will get the job done in the best way, not necessarily the easiest way.

* I'm not advocating the "Architects Don't Code" anti-pattern, merely that there's valuable insight to be gained from having this safety net removed and drawing a slightly wider line between being a lead developer and an architect.

Just an aside - I can see Kevin's response to my post, but I can't see my own post? The page itself says there's only 1 comment..

Excellent point about not doing the coding any more. I think this is healthy, despite popular opinion otherwise. I believe that one of the most important 'customers' that a software architect has are the developers - their requirements must be addressed just like any other. This is where the stereotypical 'ivory tower' architectures hit problems, and why a solid background in development is so important.

This doesn't mean you have to be in the thick of it coding new features and bug fixes yourself. You can get just as much, if not more, feedback by watching someone else. You don't do usability testing by using something yourself - why should a software architecture be any different?

Ultimately, you have to learn to let go and this can be a deceptively hard thing to do; especially if you've spiked the initial implementation, the detail-obsessive side of any good developer can kick in!

That attention to detail is a valuable trait, as it keeps you honest, but staying focused at that level is unhealthy, and it'll make other people think you don't trust them.

Yes, there's a mentoring aspect, but that's no different to a lead deveoper, so it's not relevant to a discussion of 'distinguishing features'.

Phrases like 'audacity', 'confidence', 'go ahead anyway' etc - I think these are all different ways of describing leadership. You certainly need experience, depth and breadth of knowledge, etc to provide effective leadership - but plenty of developers out there have that depth of experience; that does not automatically make them good architects.

Is. . . when can an architect call herself a developer??????

Im writing a paper, on the architects role, and im going down that risky road, saying that i feel architecture is basically now part of a new kind of production line. . .

Pragmatic and Peter Keating. An architect for the people and developers. It an architecture for the society, and a FICKLE society at that.

Regarding the '...not writing a single line of code...' argument; I would tend to disagree with this to an extent.

I reckon that part of an architects job is developing rapid 'proof of concept' apps/solutions to aid the 'buy-in'  from developers and stakeholders.

Does anybody else have any strong views on this?

Hi, I am am also a strong believer in architects who can code. You won't get credibility from the development team (and often the develpoment manager, who can be the 'gatekeeper') without that. 

I also work in an environment where it's hard for me to directly make changes to trunk - there's a rigorous process to be followed, which I don't have the bandwidth to pursue for each of the things I want to happen. Initially this was very frustrating, but it has turned out to be beneficial! It has forced me to step back from the IDE, think harder about 'socialising' what I want to achieve, explaining the design, reviewing the code changes and generally getting more people involved with architectural issues and thinking.

By being obliged to push this out to others, it forces me to be a better communicator, think more carefully about the impact of changes on delivery schedules, customer constraints and all the other messy things that don't exist in an ivory tower. The developers know what's going on because they help make it happen, which makes them much more likely to stick with it and evangelise it amongst the team.

Cheers
Mike

No complaints here - a valid point about regulation of title in the US. As you'll see from my previous post, the ARB (www.arb.org.uk) is a little more pragmatic about matters in the UK, simply requiring disambiguation when using the title.

I'm not sure if it qualifies as title envy or just plain metaphor. It is (as even the AIA concede), a valid use of English to use "architect" to describe anyone involved in design and planning, albeit of questionable (and state-dependent) legality to do so in the US when referring to a job title. The software industry is full of metaphor (Microsoft Windows isn't actually made of glass as it turns out), perhaps due to its recency or since it derived from branches of engineering or maybe due to software itself being a metaphor. Perhaps over time the industry will develop its own titles as the discipline achieves some of the rigour of building construction.

That said, I hope most people recognise and adhere to the regulation of the architect title in the US and don't mean to belittle the effort that goes into becoming qualified and registered as such.