There are many terms used within the software industry to describe roles that people perform. All of these roles contribute in some shape or form to produce and deliver software to a target audience.
Many of the terms used are arbitrarily assigned by organisations as they suit, and do not necessarily conform to any agreed to and understood definition. In fact, if you were to look these terms up in an attempt to define each you will find a varying array of explanations.
Perhaps the only thing that people can agree on is that within the software industry these terms exist, and individuals perform roles attributed to these terms.
You might ask; why the confusion? After all, other industries have similar terms and within these industries, each has a well-understood meaning. An architect of a building is well understood. A construction engineer is common within the construction industry. Designers can be found producing clothing products. Market analysts will give you insight into the trading market.
So surely, the IT industry has a clear demarcation for these roles. Well, first off, my examples above all come from different industries. Secondly, the examples given allow a little insight into the issue here.
Some of the examples are mathematically based and with that the ability to prove the result. An engineer of a steel bridge can calculate stresses and strains. It is a very black and white exercise.
Other examples are more creatively based, where two solutions can both be correct but also very different from each other. Two designers who are given the task of designing a winter coat can both come up with valid options and both be very different. One is not necessarily better than the other, just different.
The IT industry, in its attempt to be taken seriously and to fall into the sciences where it belongs, feels it needs to be able to measure things and have a correct method for achieving a task. These thoughts lead to labels such as engineer and architect. Others, who look at usability and interacting with users see the task as more artistic and creative. This type of thinking gives us designers and analysts.
In the end, what we have ended up with is a mashup (sorry for the populist reference) where one role intersects with another. The result is confusion of what a specific role means or at least confusion in the general market place. Within an organisation, they know what they mean, and they know how they view the world. If you want to know what they are thinking, then look at the vacancies they have and see how they list the tasks for that role.
That said, everyone has an opinion about things and on job roles within the IT industry is mine:
- Coder
Someone who has a specific task to perform in code which they are responsible for writing, testing and delivering as part of a bigger item software. - Programmer
See coder - Software developer
See coder - Software Architect
Someone, who when presented with a full set of requirements can look at how the problem should be deconstructed into component parts. It is these parts which can be distrusted to the team. Looks at how to solve the problem efficiently using code. - Software Engineer
Someone who designs a software solution to a technical challenge usually including writing the code, testing and delivering as a library. This may be things such as search algorithms, handling binary trees or sort algorithms. - Software Designer
Someone who looks at the software requirements and decides how to solve the challenges using software. This may be implementing business workflow or presenting an intuitive user interface to a phone app. Very much like an Architect but with more of a business and user focus. - Software Analyst
Someone who understands software applications in detail and knows what questions need to be asked in order to fully understand what the software must do. Typically, these questions are around how business and users will interact with the software. - Business Analyst
Someone who has a deep understanding of the business domain. They understand the challenges and opportunities for the business and can clearly articulate, usually in writing. Has much in common with a Software Analyst but a different perspective. - Project Manager
Responsible for coordinating information and activities between the many parties involved in producing complex solutions - System Architect
Similar to a Software Architect but concerned with the complete solution which also includes hardware, certification, integration with 3rd party systems. - System Designer
Has a focus much like a software designer and like the System Architect is concerned with the complete solution. - System Engineer
Like a Software Engineer but systems tend to have more challenges in the performance arena and with scalability. The challenges tend to be more varied.
Now, this is an opinion. Some may agree and some may not. What I hope it does demonstrate is that there are many ways to look at producing software and all of them are important and worthy of consideration. Where you choose to put your focus will depend on what you value the most. At the end of the day you can call your roles what you will – what’s important is what you actually do!