I was pondering what certain "roles" within software companies should actually mean. I think it's a grey area, though I'm not sure it even matters really. Here's a few that I encounter fairly often and how I interpret them. I have also written them up in terms of my perceived "pecking order" with a.n.organisation.
Please feel free to post other ones and/or your interpretations. Which one of these is closest to your title? Do you feel you meet my description? If not, is your description appropriate to the role you actually do, not just the name?
Quite rare these days, I feel, but if someone had this role I would say that they basically just wrote code. No design or interpretation, they take a spec and make it work. They would most likely contribute to a piece of software, but not be directly responsible for the final deliverable, that being handled by someone more senior.
Like the programmer, but able to take requirements and assess the feasibility of what is required then create a spec and basically code it up.
('Software' | specialisation) Developer
(e.g. Software Developer, Java Developer, Senior Java Developer, etc)
Like the analyst programmer, however, a developer would be able to produce the final deployable result. They may also be required to contribute to estimates and mentor more junior members of the team. The design output from a developer is most likely minimal. After the spec, they code.
The senior version may manage a small team of other developers, delegating tasks throughout the project lifecycle. They would no doubt have a hand in the planning of the project's deliverables and milestones.
('Software' | specialisation) Engineer
A specialist version of the Developer that will also produce high quality software design documentation to a level and detail in which it can be understood by other members of the team. An engineer may also be required to capture requirements, performance analysis, high level design and detailed design.
The senior version is similar to the "Senior" Developer in that they will be leading small teams, mentoring, delegating work, contributing to project plans and so on.
I'd like to think this is where I am at now.
Technical Architect (TA)
My feeling here is that there's quite a bit of overlap between this role and Engineer role. The major difference is that the TA probably won't touch any code unless absolutely necessary. They may be involved in the design of the architecture for multiple projects at the same. The role is primarily a documentation creation and work validation role, they would most likely make the biggest contribution a software architecture document, for instance. In an organisation with a TA and Senior Engineers, these roles would probably work together with the TA delegating the responsibility of delegating tasks to the Software Engineer.
Solutions Architect (SA)
My view of what the SA should be is that of someone who is ultimately responsible and accountable for one or more projects. The SA collates all the information about the final solution; deployment environments, software versions, managing non-functional requirements and so on. It is also their responsibility to validate the technical architecture of the software solution, though not necessarily to have a hand in designing it. They will typically add all the guff to the software archiecture document that is not actually to do with the software, you know, the stuff that everyone skips and just makes the 30 page succint document 120 pages.
While the role is perceived as "higher" than that of a TA, the SAs I have met have usually been less technically competant than the senior developers/engineers on the team. A good SA should be able to bridge the gaps between the technical people, business people, project management and quality assurance. They are natural leaders and amicable.