Perhaps, but once you start generalising there are lots of grey areas and overlapping possibilities, which I suppose is my main point here. For example, say yo

Perhaps, but once you start generalising there are lots of grey areas and overlapping possibilities, which I suppose is my main point here. For example, say you're working on a web app that controls some device. On the back end, you might not be talking to a database, at least not in the sense of SQL or NoSQL we usually mean in the context of web apps. Maybe instead you're integrating with some internal API that controls the hardware. In that situation, maybe you're exposing that internal functionality to the front-end web app via some HTTP-based API, which might be substantial but is mostly a wrapper for the internal functionality with things like security incorporated. Who should be responsible for that middle layer? Do you have a separate person/team whose responsibility is just to bridge between the front-end code and the internal API? Should the person/team responsible for the front-end also be responsible for the HTTP-based API it talks to, and hand off to some other person/team who work on the hardware-facing code behind the internal API? Should the internal team also be responsible for the HTTP-based API? I don't think there are any "right" answers in a situation like this. You probably have people with front-end skills. You probably have people with low-level hardware hacking skills. Some or all of those people might also have back-end skills. You've certainly got three distinct but related areas here. Depending on the project and the mix of people you have available, there are several potential ways to handle this situation that might be effective.