There are many articles on Habré about who a systems analyst is. With the basic definition of a profession, everything is clear. But I want to talk about the delineation of powers in teams with a different set of roles. Depending on the situation, the boundaries of the responsibilities of a systems analyst become blurred, requiring additional knowledge. I would like to share my observations about which of this knowledge makes analytics more in demand in the labor market.
The specific responsibilities and workflows in which the systems analyst is involved depend significantly on the internal structure of the company. As a starting point, I propose to take my current role in the team.
At Maxilect, the systems analyst primarily focuses on technical tasks. He understands a little program code, can write basic SQL queries on his own, understands and applies various principles of building application architecture, as well as their interaction. Knows how to work and design web services and queues (MQ). But he doesn’t have to deal with business analysis.
The team receives tasks from the business that answer the question: “What needs to be done”. And the systems analyst decides “How the team implements it”. When working through the task in detail, the systems analyst can discuss the intermediate option with the developer or discuss something with the architect. But it is he who decides which web services we will call, how to process the received data and what improvements are needed for this. Organizes discussion with third-party teams, if required. In fact, the role of the systems analyst here is close to the canonical one.
But Maxilect is not my first job. Throughout my career, I have seen different realizations of this role. I saw companies that, in order to save money, are trying to hang the system analysis function on developers. But personally, I adhere to the principle that everyone should mind their own business. The developer is better off focusing on the code, while the analyst provides insight into the requirements.
In real teams, the functions of a systems analyst are blurred. The smaller the project and the company, the more there are. An analyst can teach, test, and conduct a demo, and even fly on business trips for implementation (if this implies the nature of the product being developed), thus invading the territory of related specialists.
Disclaimer about Juniors, Midles and Seniors
Of course, the scale of the impact on the project depends on the level of training of the analyst himself. Jun, with his basic understanding of requirements collection theory and business processes, is unlikely to be trusted by anyone to close two or three roles alone. He would dive into the principles of the system, and master the tools from Word to UML or some Balsamiq.
After a couple of years of work, the first encounters with microservices, REST, SOAP, etc. the specialist will turn into a middle person who will be able to solve problems on his own. And from that moment on, he will be able to master related roles, continuing to delve into the details of his profession. The senior level with his many years of experience, basic skills of an architect, understanding of integration services or the ability to cut monoliths, as well as experience in managing a team, he will most likely achieve by combining several directions.
It is possible that it is precisely the combination that gives this impetus to development. But the division into levels is so conditional that further I will not focus on how related roles are related to it.
Let’s talk about which directions for analytics are opened more often.
Analyst and Business
According to my observations, most often a systems analyst has to close the functions of a business analyst.
Both the system analyst and the business analyst are links in the chain between the customer and the developer. The first is a little towards the technical side, the second is towards the business. The line between them is very thin, so the roles are often confused. And in small projects, these roles are usually filled by one person. If we are not talking about a large-scale project, then one head is enough to understand business processes and keep in mind the architecture of the system – to know what is where and what changes need to be made in order to implement new requirements.
I noticed that of these two roles in vacancies, companies often write “systems analyst”, suggesting combinations in the text description of the position or between the lines. It seems to me that a business analyst is a rarer narrow specialist that not every company can and wants to afford. So, by closing both roles, you become a more versatile specialist who finds it easier to find a job.
But the absence of a business analyst on a project does not always guarantee that it will be necessary to combine. It – the sphere is developing dynamically and new related professions appear in it. For 3-4 years, not many people have heard of the product owner role, but now the product owner role is more and more in demand. And I have already come across teams more than once where the PO determines which business tasks will be included in the sprint scope and which will not. In a sense, in addition to performing his main functions, the product owner is integrated into the development chain instead of a business analyst, interacting with both the customer and the system analyst.
Do I need to test?
The systems analyst must have a good understanding of the system and its functions. As he is guided by the customer’s requirements, I increasingly see analysts being involved in testing. I myself test individual modules of the system on the current project. Testers, on the other hand, focus on the larger parts of the problem.
I came across a request for testing by system analysts a couple of years ago. But then I did not see such items in job descriptions. Now on personnel portals they already openly write that a systems analyst applying for a vacancy must write test cases and check them himself.
Systems analyst vs architect
The systems analyst is not an architect, but often he has to close this role at least partially, although in my opinion this is wrong.
An architect is an important and necessary specialist, but usually they are looking for him for large projects, where architectural flaws can literally bury a good solution. If the architect is present on the project, the systems analyst has to work closely with him, especially during the onboarding period.
When a project does without an architect, its functions are divided between other team members, for example, the tech lead, the product owner, and sometimes the systems analyst himself (I have seen this kind of work for three on one of my former projects). This is not a common or correct practice. But one way or another, a systems analyst will still have to understand architecture, understand which technology is responsible for what.
The need to study the architecture of the project entails many requirements. You need to be able to work with integration services – to understand what to transfer where to combine two systems, what an integration bus is and how it works. You need to understand how a message will get from one system to another, and what will happen in this case, which means you need to know how queues work (RabbitMQ, Kafka). It is necessary to work with databases.
A systems analyst does not need to be able to design all this, but it is necessary to follow the technologies, understand why and in what situations they are used.
Will the lead leave the analyst?
It is worth following the trends in management. Analysts are often put on the role of leads – they say, they understand the project well, they know how to communicate with the business. In my opinion, this is not always a justified step. Leadership is more of a managerial job that takes a lot of time. This is primarily the distribution of tasks received from above between the middle and juniors in your team. It seems to me that this work is easier to entrust to the project manager or product owner – that’s how I’m used to working. A strong analyst can focus directly on his work. But for some, the transition from systems analyst to leads is a good step in a career, for which it is better to prepare in advance, studying the specifics of team work, differences in approaches to development (this is already about Agile, Scrum, Kanban).
Instead of a conclusion, I would like to note that the role of a systems analyst is extremely important for a project. But you cannot write a list of necessary and sufficient skills for her. In this area, knowledge is never superfluous. Coding experience, the ability to write queries in the database, and general ideas about the area in which the project is being developed can be useful. All this makes the system analyst more in demand in the labor market.
The author of the article: Leila Kadyrova, Maksilekt.