I feel like I have finally have enough experience under my belt to confirm what I always felt in my gut from my first day as a professional software developer: we are doing this all wrong. What do you mean? Why does it suck? Have a better idea?
Let's start there! Rather than have a long and heated discussion on how every dev shop is doing it, let's just talk about how I think things should work.
Let's lose the term developer, dba, sysadmin, "full-stack" whatever ... let's just say what we are, engineers. We are all responsible for everything and if we are not we're doing it wrong. No one should be hyper-specialized and everyone should capable of solving any problem in a given domain.
All engineers should work in pairs. In my tenure even the best engineer follows the 80/20 rule, 80% gold, 20% sh... When you pair this goes up to 99/1. Pair members should work well together.
All large systems should be designed at most by one pair of engineers, let's call them solution engineers. They take in the requirements and they alone come up with the data flows, interfaces, SLAs, and NOTHING ELSE. This of course would be reviewed by all engineers involved so they can give input and iterate but ultimately the solution engineer's say is final. They also pick the engineers and divide the project into discrete components for said engineer pairs. There should not be more than 2-4 pairs for a solution or it's too complicated and your clients won't use/understand half of it.
The reason the solution engineers give nothing more than described above is because there are 2 things humans are terrible at: scale/scope and decision by committee. The only real solution that ever works is: set clear goals and let people achieve those goals how they deem fit. The solutions engineers give the framework (and maybe implementation suggestions: nosql here, a queue over there, etc) but the engineer pairs makes all decisions within their component as long as they follow the well defined contract set forth by the solution engineers. They also should feel compelled to review with colleagues, but they make the final calls. The case for any changes to flows, interfaces, or SLAs needs to be made to the solutions engineers with concrete data.
All of this should happen in an agile fashion with the solution engineers getting a few weeks head start on the other engineers.
How does this scale you ask? I kinda answered above: IT DOESN'T. We suck at scaling and if you need to make something that big it's over-complicated or should be broken up. If something requires multiple groups described above, then no more than 2-4 solution engineer pairs should be working together to solve problems across the group. Larger than this you are talking about different divisions within your company and they should not have much communication beyond published standards and apis.
These pairs and groups of pairs can be moved around as needed. However, people should be dedicated for the life of a component. You can trade but you can't move people off of things when they are "complete" to work on the new thing. If you want to expand or develop some new thing: hire more people, if you can't hire then make your products more successful, if you can't make them more successful then close up shop or your customers will do it for you.
What about support? You don't "support" applications. They are either in active development or you shutter them. If something does not require 100% time of at least 1 pair of engineers you should probably sunset that thing because no one is going to be happy with it very soon.
Management and Product can remain in their traditional roles. The exception is that the folks managing engineers have NO technical input. I think design teams could benefit from something similar.
This isn't to say you cannot succeed in other models. It's just that I have seen many other models and believe this one wastes the least time and money. As a side benefit the autonomy provided boosts creativity and engineer happiness.