Answer.

History of the issue:

In classic projects, conflicts often arose between analysts and architects, as well as between systems and business analysts: each attempted to "capture" or, conversely, transfer part of the responsibilities. Clear definition of boundaries became one of the signs of a mature team.

Problem:

The danger lies in the overlap and duplication of work, leading to misunderstandings, loss of responsibility, delays, and in some cases, parallel and contradictory work describing the same part of the system.

Solution:

Define artifacts and end products for each role (for example: a business analyst is responsible for business goals, a systems analyst - for functional specifications, an architect - for architectural solutions)
At the start of the project, conduct workshops/meetings with a clear breakdown of areas of responsibility and agreement on regulatory documents (such as RACI matrices)
It is important to regularly discuss and adjust boundaries as the project develops and the context changes.

Key features:

Transparent distribution of roles and areas of responsibility
Clear definition of artifacts and entry/exit points between them
Constant communication and control of overlaps between tasks

Trick questions.

Should a systems analyst engage in the design of the entire system architecture?

No, the architect is responsible for architectural decisions. The analyst clarifies requirements that the architect can use, but does not design the architecture as a whole.

Can a business analyst directly address describing technical limitations?

Generally, no - the business analyst formulates business requirements. Technical limitations are the area of the systems analyst or architect.

If a task description is received from a business analyst, does the systems analyst need to duplicate the meeting with the business?

No, but the systems analyst must ensure that they understood everything correctly and raise questions in case of discrepancies.

Common mistakes and anti-patterns

Transferring areas of responsibility "by default"
Unclear description of end products (artifacts)
Conflicts due to lack of regular communication between roles

Real-life example

Negative case:

Two teams were simultaneously working on one part of the system: analysts wrote pseudo-architecture, while architects described business processes. As a result, specifications diverged, and implementation was delayed.

Pros:

Attempt to speed up work

Cons:

Duplication, discrepancies in documents, loss of deadlines

Positive case:

A joint workshop at the start, where they agreed on who is responsible for what, documenting the boundaries and overlaps. Subsequently, at each stage, they conducted revisions of these agreements.