⛹🏾 ⬇️ ⏭️ Business analyst and systems analyst in IT. Sorted out the grades 🙆🏼 🦃 📞

Problem

Some of my friends, colleagues, managers, eycharov, representatives of the "business" in their heads formed a confusion between the types of analysts. The concept of “analyst” is used for completely different professions - business analyst (BA), system analyst (SA), data analyst, UX analyst, information security analyst, business process analyst and 5-10 others, all these species have a lot of differences. Now about the specific two, the most confused, but very different in domestic IT realities.

Who will benefit from this article:

To	how
Analyst and colleagues	— , , . — , , . : xml- , -.
HR	, , . «, ». : java, .
	Target the selection and distribution of resources that are ready to perform a specific combination of work responsibilities, improve communication in teams. Example: For a position that requires maximum communication and flexibility, a “techie” is selected without a desire to develop such skills.

In general, “Happiness for all, for nothing”

Assumptions

This article talks more about IT.

The "distilled" value of posts is considered. In real life, especially in teams that develop T-shaped skills (an employee’s competency development model from related professions), it’s more complicated and confusing, but if your analyst is not many-sided Janus, then the transition between different responsibilities is not an easy task.

Main part

Communicating with BA and CA from companies and projects of various sizes, I saw a discord in concepts that creates controversy. As it usually happens, the lack of generally accepted terminology interferes with the distribution of tasks and responsibilities in the project between those who are able to fulfill them with the greatest efficiency. In order to appeal to an objective source in these disputes, I decided to look for opinions on the net.

I share the results of my searches.

Business analysis and system analysis in IT are sets of practices, methods and tasks that simplify the development of information systems necessary to solve the business goals of organizations. The confusion between these two concepts exists not only in the domestic environment, so:

https://en.wikipedia.org/wiki/Systems_analyst :

A systems analyst is typically confined to an assigned or given system and will often work in conjunction with a business analyst. These roles, although having some overlap, are not the same.

As sources that could establish the “dividing line” between the SA and the BA, I tried to use the BA knowledge codes, generally accepted professional literature, regulatory documents and articles on various resources. I could not find a clearly articulated division. And that's why:

, , — , . « », ( ), .
( / . ., BABOK, ., PMI Guide to business analysis . .), . , - -, . , . . -, « , , , , . , , , , - ». . PMI IIBA «system analyst» , «business analyst» .
( ) , . , — . — , , , . — , , , , , .

In this situation, I offer my vision, based on the experience in Russian IT companies both on the part of the customer and on the part of the contractor in the development of information systems. This approach has helped in the work of the author Alan Vongsavanh, which studied the literature and the results of several interviews and gathered a list of the basic skills that make up the lion's share of the routine activities of the BA and CA (the bulk of the working time):

* Foreign sources use the more appropriate terms “technology focused” and “business focused”.

Where:

Identification of requirements	the process of determining requirements from various sources through interviews, seminars, task analysis, workflows and documents and other methods
Business knowledge	, , -
	.
	-
	,

	,
	( )
	knowledge of technologies, programming, creation and configuration of databases and other technical aspects, standards and rules for designing solutions

Together, these actions allow you to form a complete cycle of requirements analysis, bringing it from the customer to the developer, and after that - bringing the finished product from the development team to the customer. Such interaction easily falls on the frameworks, for example, this is how it looks in the V-Model, waterfall model or flexible methodologies:

Why such a separation

The skills required by BA and CA are top-level similar, but the devil is in the details. A system analyst needs much more practical technical skills for a full-fledged activity, he is much closer to a group of technical specialists and should better understand their language (without this it is difficult to achieve respect in the team, which means it is impossible to transmit your vision). BA in IT is more configured to communicate with business, its task is to determine the need (pain), find, formulate and propose a solution to the problem of the business customer using IT systems, in some way to "sell" this solution. The proximity and understanding of the user helps the BA to more effectively prioritize tasks, describe non-functional requirements and limitations in a particular case.

Moreover, BA has inherent excessive requirements for the system, it thinks in business goals and should not be constrained by the capabilities of technology, which is unacceptable for a CA. Sometimes such excessive BA requirements help to find truly breakthrough solutions.

There are limitations, however. For BA, this is the scope of a domain or a studied industry (for example: in-depth knowledge of banking rules), for BA, this is a technology and system (for example: outstanding experience with oracle products). These restrictions can be an obstacle in the transition between teams, projects and companies, but can be quickly eliminated if desired and with the help of colleagues.

Almost always, the analyst in the team plays both roles to a greater or lesser extent (therefore, I would like to avoid disputes about combining “and we have BA also a virologist”). In some cases, analysts may not be needed; in some cases, one specialist can fully perform both roles. This does not violate the rules, but indicates a combination of roles, the level of maturity and value of a particular specialist. In the case of an experienced employee, this is quite normal, but the junior BA vacancy with knowledge of SQL, JS and API on a well-known site looks strange.

https://en.wikipedia.org/wiki/Systems_analyst :

Some dedicated professionals possess practical knowledge in both areas (business and systems analysis) and manage to successfully combine both of these occupations, effectively blurring the line between business analyst and systems analyst.

Abstract example:

Ivan - BA company "Contractor".
Eva is a system analyst at Executor.
The company "Customer" needs a major revision of the existing system.

In this situation, the tasks of Ivan (BA): to identify the functional and non-functional requirements of the Customer and the Contractor, to eliminate the contradictions between the interested parties to determine an acceptable solution, to create prototypes, to interact with the customer during the development process, to carry out a demo display and acceptance of work. Doing all this together with Eve.

Eve's tasks (CA): to design the revision in the optimal way, describe its impact on the system, limitations and possible improvements, create a specification, decompose and transfer the tasks to the development, and monitor their timely implementation in accordance with the requirements. To do all this together with Ivan.

Instead of output

From each iron, one can hear that over time, the complexity of business problems and their IT solutions increases exponentially. Along with this, the technology stack is developing intensively and extensively, in breadth and in depth. Choosing the right composition of technologies can provide breakthrough competitive advantages, but it can also be destructive, often the choice is made for years to come, putting developers in a narrow framework.

The current situation requires IT analysts (1) to have a deep knowledge of the subject area of the business, features of internal processes, the external environment and trends, (2) not less deep knowledge of technologies, often their practical use.

You can be an idealist, look for a genius and demand from him a high understanding of various, if not polar, areas of knowledge. You can go down to earth and understand that such a duality of duties is likely to lead to a fakap in both directions. Sitting on two chairs is not a good practice.

If the complexity of the project requires BA and CA, first you need to form a concept of what level of business knowledge and technical features is needed from a specialist and translate it into a published vacancy, an interview and testing strategy. One always wants “one size fits all”, but we live in real life, where it will more likely complicate the search and increase the price of attracting a “multi-tool”.

To colleagues who have found themselves or are planning to work in BA or CA, I advise you to carry out the same procedure and honestly understand for yourself whether you want (1) to search for the seed of truth in often defy algorithms and logic, constantly changing business or (2) to research and design complex confusing but interesting systems. This will help shorten the path to the selected peak and reduce the discomfort of being out of place in the pursuit of a “beautiful position”.

Appendix

Well, Glavred, is it now clearer? =)

Business analyst and systems analyst in IT. Sorted out the grades