A few of us were sat in the pub the other night and started discussing the difference between a lead developer and an architect. Specifically, we were trying to get to the bottom of when it feels right to call yourself an architect.
My first take on this was experience and confidence. I think the key thing that differentiates an architect from a lead developer is experience. That is, experience across many systems and many different types of solutions. Where confidence comes into play is that you need to feel confident in your experience to feel comfortable to call yourself an architect. What do you think? Let's try to continue this online.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.
You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.
First of all, wanted to say how much I enjoy your blog.
How about..when the buck stops with you?!
If you have the ultimate responsibility and accountability for technical decisions, then that has got to be a pretty good indicator.
It's a question of leadership, of sticking your neck out and being the person people turn to when pointy questions are asked such as:
These are the sorts of things that a lead developer would shy away from, or respond to with unintelligible or blame-shifting answers. Of course, a bad architect will be guilty of that as well.
The above doesn't always apply when you have architects parachuted in during the project inception and moving on to the next green field before the impact of their decisons are fully understood.
I honestly believe that an important part of being a architect is about hanging around long enough to understand the repercussions of your choices and learning from them. I don't care if you've had 20 3 month engagements across 15 different industries.
I think this is one reason why we suffer from lingering suspicion and cynicism around the word 'architect' and are still, in the year 2006, having conversations along the lines of 'so, what's an architect, *really*?'
Cheers,
MikeMike 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.
I guess one reason that they don't push back on the software industry is that the Architect's Act is (presumably) in place to prevent unlicensed design and construction of buildings. The use of the term isn't particularly ambiguous in the software industry (although the header image for this site might contradict that!).
Indeed, the Architects Registration Board are aware of the issue and seem to take a sensible approach to regulation.
In particular, the Board is aware of widespread use within the computer and IT industry of the word “architect” being incorporated into certain job descriptions, eg. “Systems Architect” or “Software Architect”. While such use may be a technical breach of the Act, the reason for and intention of continued regulation of title is principally to ensure that consumers of architects’ services are guaranteed a certain standard and quality of work.
It was never the intention of the Act to regulate the title for its own sake. The Board therefore takes a pragmatic view, and accepts that the use of the word “architect” causes no concern when used in a context which is clearly not related to the design and construction of buildings.
Equivalent laws outside the UK sometimes qualify it by saying that the use of the term is only restricted within the construction industry.
Incidentally, the UK is less restrictive with the term "Doctor", its use extending to academia.
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.
Here is what i think architecture should be able to do:
1> Develop Solution by selecting the right technology, keeping in mind the business goals
2> Layout the roadmap to deliver the solution to the customer
3> Understand non-functional requirement and accordingly makes suitable trade-off while designing on how different component meets the functional requirement
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?
I don't think I presented my point very well at all in my comment above...
You're right that proof of concept and spike architectures are an important part of the architect's role and that the ability to write production-quality code is crucial. I was simply trying (and failing) to capture how I noticed a strong difference between being a lead developer and being an architect - and, for me, that was through being placed on a project where contributing to the source repository was not possible. Definitely wouldn't recommend it but would recommend thinking about how you would solve your problems if you couldn't just code your way out of them.
So I strongly agree with you!
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
You should call yourself an architect when you are licensed by a government agency to design buildings and spaces in order to protect and benefit the health, safety, and welfare of people who use them. Just like you wouldn't call yourself an "M.D." or a "lawyer" or a "professional engineer" or a "CPA" if you weren't appropriately trained and licensed, so it should go with the title "architect".
Architects (real ones that is) appreciate the title-envy, but we're finding that everyone wants to be the architect of something these days be it public policy, war, criminal actions - or software!
Software designers (creators, developers, coordinators, team leaders, gurus - whatever) should find another title to limit confusion and dilution and differentiate themselves from the art and science of creating safe and aesthetically beneficial buildings and spaces.
Go to www.aia.org to find out more about us.
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.