If you have been in a team in which members are separated into dedicated roles such as Back-end, Front-end, BA, SA, Infra, etc., I believe you have encountered an awkward situation where a task has popped up that does not fit fully into the responsibility of a role, and the relevant team members each stays silent to the question "who should do this task?" (in the sense that asks for the role's responsibility for now and in future), driving the team into a political dimension.
Why is it that hard to answer? Because the question itself indicates that the team members have a mismatch in their mindset about the working environment. Imagine, in your home, have you ever ask your family members who should be responsible for the housework?. Who should change the bin bag? Who should do the laundry? Is it your mom? Then why can't it be dad, or YOU? Imagine mom is coming home and see a mountain of dishes waiting to be washed while you and dad are playing a video game because you think it is your mom's responsibility to wash the dishes. This is a common political conflict in many families and its result can be serious to the level of divorce.
I am not an expert to say, but from my observation, I think people tend to model their work environment like a factory and expect that each kind of work has to be responsible by a specific role or department. It may work fine if your company is a big software house that can hire any number of employees, I don't know. But in a small software development team, I think it is more appropriate to think our environment is like a home in contrast with a factory. For a home, every part of it is ours, not someone's specifically. During the electricity outage, it may be your dad to fix it as he knows the most at the time but it does not mean you can go playing with your dog and never learn anything more about the electricity in your house.
I used to be in a team with no clear roles and responsibilities. Everyone on the team just did anything to deliver the software program. It was a mess and everyone had burnout. At the time I think it is because we don't have a good process.
But now I have an experience with an attempt to "factorylize" a software development team, I have changed my mind. I think "architecture" is the key, not the "process". A process creates silos and politics because it focuses on "who". Architecture, on the other hand, focuses on the "how" and "where". In a house with good architecture, everyone knows to cook in the kitchen, to sleep in the bedroom. When an outage occurs, people know where to look and fix it. Software development can be a mess not because it lacks process, but it has no clear architecture for how and where to do stuff. When the architecture is clear, anyone regardless of role can achieve their goal by utilizing the architecture.