I keep hearing about the "Architect" title in larger software corporations, and am interested to know what they do and how they get it done.
Is it their job to prepare visual diagrams outlining the functioning of the software? and what programs do they use to aid their design? Like Class Designing?
Do they design at a higher level and get others (Developers) to write code in a way that a machine can execute? Or do they get into the details of the implementation?
If a person can build a shed without a blueprint, it doesn't mean they can, or should build a house without a blueprint.
Architects see what you need now, what you mean when you say what you need, and design a software strategy that will give you what you need today, and a home that you can grow into (and from) in the future. Architects who are familiar with construction succeed more often, in software, Architects who can code, and have done so at a high level (but may not on a day to day basis) can help lay the foundation for other developers to succeed together.
The tools involved in Software design so are largely like pencils, erasers and rulers. It's what you draw with the pencil that is more important than the tools.
An architect's role is to be able to pull together, and keep together a project that is designed from the very high level right down to the nuts and bolts where attention to detail needs to be remembered. They will be experts on finding the exceptions, holes and things that will be unsustainable or prone to breaking in a software's design and remedying them before its even begun ensuring a higher degree of success.
That being said, for the SA I do, I use tools like OmniGraffle, Balsamiq, some UML stuff, and a lot of graphing paper and whiteboards. My goal in designing is to synthesize the complicated into something simple, effective and usable by everyone.
My goal is to understand the needs of my clients better than they understand them, to the point that I can help them have the realizations they are looking for the next "leap".
Being an architect for solving people's problems means dealing with a lot of them, from a lot of angles, and finding the common patterns in everyone's requests.
As will all job titles, it's very subjective and will vary between companies.
Having said that, here's my view on it...
A Software Architect works with the Business Analyst to convert the Business Requirements and Functional Specifications into a Technical Specification which the developers can work from.
Architecture is about designing & planning the best way to build something, and whilst this can be considered high-level, it still benefits from correct knowledge of lower-level things, and may require getting into specific details in some situations.
What tools they use will depend on how their mind works.
My old man called himself a Software Architect when he was working at a large enterprisey group a few years ago. (Now he's gone over to shudder consulting.) So I'm only saying this from an observational POV...
He seemed to be the one who liaised with the pre-sales team to gather requirements and organise the spec.
He also, as you guessed, drew (in UML) the overarching plan for the system - although I'm not sure what software he used for that.
AFAIK, he didn't do very much actual programming. He did oversee a team of programmers though (in conjunction with a lead dev) and could code pretty well himself, so it wouldn't surprise me if he mucked in if he was needed.
Like I said, these are just observations. Each organisation probably has a different idea too. But I hope it's useful.
I guess the answer you get will differ where you ask it.
Where I work the architect is responsibe for the following:
The tools used would include
My company produces software components. As such, my role as architect is to
I would remark that it also depends of the software that it has to be developed and project length.
It could also depends from which kind of production process you are using.
Program they could use is visual architect, star uml.
I think to make some project planning it helps with mainteinance as well
Bit late in the game, but have you looked at
note the process which the company employs may decide the tools used IE RUP will recommend using Rational Rose.
These tools will not just do class diagrams, they will allow for the capture of the business processes, Logical Model, Design Model, Use Case, Deployment model etc
An eye opener for me was to look at the "4+1" modelling, google "4+1 RUP" and have a read.
I'm new to this world, however this is a quick overview of my observations.