What does it take to be a great Software Architect?

Well it is a person who is ultimately responsible for the Software Architecture.
That's good enough- Right?
Well no - we've got a bit of a circular definition here - what is Software Architecture?
Now we've asked probably the hardest question in the software world? Why? Because
no two people can seem to agree.

But back to a Software Architects - what defines a good (or great) one?

KEY STRENGTHS AND ATTRIBUTES OF AN ARCHITECT
Knowledge
The architect has a lot of knowledge (and experience) vis-a-vis

• The business domain (hey what is a "Mutual Fund"?)
• The business users (do they want the system bug-free or fast but can tolerate bugs?)
• The technology platform (J2EE/.Net / Database / OS etc.)
• Design knowledge (what works and what doesn't - e.g. why asynchronous systems scale better etc.)
• Programming Knowledge (APIs etc.)

A Learner & Opportunist

The only way you got to have so much knowledge is by making time to learn. Great architects are great "sponges" with great memory and powers of assimilation. They can look at a new piece of knowledge (e.g. a new API), understand what it does, how it fits and 18 months later will remember to use it when the opportunity arises. You don't need to remember the API exactly but knowing there's one out there is a great tool. You can have all the knowledge in the world but it ain't worth a damn if it's never used! :-)

Great Communicator
- Listens - Understands how key (often high-level) business requirements lead to key (again high-level) technical choices. Connects the dots on those "unsaid" requirements that are often some of the most important.
- Teases out other requirements - the "fuzzy" ones like availability, scalability, reliability etc.
- Speaks the language - not only of developers, not only of users but also project managers

Technical Leader
- A leader in the sense of making decisions and ensuring things get done (right) but also a leader in the sense of empowering other people to make decisions and a mentor to help others make better decisions. The latter is more important, I think, as otherwise the Architect becomes a bottleneck (trust me I've learned this one through painful experience)

- Motivator - a leader should be able to motivate and inspire others, to gain buy in from folks and ensure that each person is getting the challenge they want but in line with ensuring the end goal is still being addressed.

- Enabler - if the teams needs a tool the Architect will build it themselves or have it purchased

- Defines Processes & criteria - how are files checked in and checked out - which changes are risky and which are not and when should they be integrated?

- Leadership involves so many other important traits I can't cover them here

Problem Solver
- Ultimately the architect will have the "buck stop" at their desk - they've got to be able to solve problems (or help others solve them) regardless of where it exists - client, database, middle tier, network etc. etc.

Mr. Compromise
- The architect has to be technically smart enough to know what can be done, what is the "right" way to do it (assuming lots of time / resources) and finally what is the right thing to do under given current requirements, time and resources.
- The architect must be a really good negotiator but can't let the project get stuck - decisions need to be made
- This also means the Architect doesn't try to avoid conflict - sometimes in the best interests of the team and the project, an assertive (but not aggressive) stance is warranted. If the architect has really good listening and negotiation skills often this results in a "win-win" for all parties.

What they don't do (or at least can't afford to do)

Isolate themselves - you can't get stuck in an office or cube - your value add is "out there" - see Communicating, Leading and Learning

Fail to delegate - Look at the list above of things it takes to be great. You can't do that if you are also doing lots of little things - writing small components, handling programming decisions that a senior developer could just as easily handle. Delegate to others on the team and watch them grow and learn - not only will this save you time and effort, it helps the other developers to become more.

Repeat Mistakes - You simply can't afford to do this - it's a career killer

Blame - Most people know anyway, it serves no good to the teamor the project to lay blame. Try to have compassion, learn from it and move on.

Ignore Politics - Some places have more than others - and if you ignore it - it's another career killer - have a read of the book Career Warfare by David D'Alessandro for good ways to combat and win. Alternatively as Sun Tzu might say sometimes the best way is win involves not fighting at all - find a place with very little politics (every place has some) and build your career there.

Links
What it takes to be a great enterprise architect

Characteristics of a software architect

The Role of the Architect

Things to do in Denver when you're an architect

What are the duties of a Chief Software Architect?

Great mistakes in Technical Leadership